Shadowrocket 使い方完全ガイド：設定・接続・日常メンテナンス

01 / 入手

App Storeでの正規購入と購入範囲

製品を確認してから購入する

ShadowrocketはAppleプラットフォーム向けの有料クライアントで、App Storeから入手できます。購入前にApp Storeの製品ページを開き、検索結果の名前だけで判断しないでください。デベロッパがShadow Launch Technology Limitedであること、アイコンが当サイトのページ上部にある公式アイコンと一致することを確認し、製品リンクのアプリIDが932747118であることも確認してください。この3点で製品を特定できます。似た名前だけでは確認になりません。詳しくはダウンロードガイドの正規版確認をご覧ください。

App Storeの製品ページでは、価格、互換性、購入条件も確認できます。まずお使いのデバイスが互換性の説明に含まれているかを確認し、次に実際の支払額を確認してください。システム要件と購入条件は、App Storeのページに記載された内容を基準としてください。本ガイドでは主にiPhoneとiPadを扱います。Mac / Apple TVでも同じストアから入手できますが、モバイル端末のボタン位置をそのまま他のデバイスの操作説明とみなさないでください。

クライアントの買い切りと接続情報は別に用意する

クライアントの買い切り購入 ≠ 接続サービスの料金プラン。購入によって得られるのはクライアントの利用権であり、利用可能なサーバーが自動的に用意されるわけではありません。接続には、ご自身で用意したサーバー情報またはサブスクリプションが必要です。これらの情報はご利用のサービス提供元から入手してください。操作前に、情報の種類、対応プロトコル、有効期限を確認しましょう。サーバーアドレスだけでは接続できないことが多く、ポート、認証情報、通信設定も一致している必要があります。

米国ストアの価格は製品ページでご確認ください。ストアの地域ごとに現地通貨で表示され、最終的な金額は購入確認画面で確定します。クライアントの価格を通信サービスの料金と混同したり、ガイドの例から実際の接続条件を推測したりしないでください。当サイトは公式ガイドを提供しており、サーバーサービスは提供していません。サーバーの期限切れ、認証情報の変更、サーバー側のメンテナンスが疑われる場合は、お手元のサービス情報を確認してください。クライアントを再購入しても、これらの問題は解決しません。

インストール後の準備手順

App Storeでの購入後、アプリのダウンロードが完了するまで待ち、デバイスのホーム画面から開きます。アイコンが待機中のままの場合は、まずデバイスのネットワーク、空き容量、ストアの表示を確認してください。この段階では、プロキシ設定のトラブル対処はまだ行わないでください。クライアントはまだネットワーク接続を担っていません。インストールの問題と接続の問題は分けて考えましょう。購入やダウンロード状況については、App Storeで正規版をダウンロードする手順も参考にしてください。

アプリを開く前に、手元の情報を整理し、個別のサーバーリンク、サブスクリプションURL、設定ファイルを区別してください。個別のサーバー情報は1つの接続先を示し、サブスクリプションは複数のサーバー情報を取得・管理するために使います。設定ファイルは主にルールや関連設定を含みます。いずれもテキストやリンクで提供される場合がありますが、用途は異なります。コピーできるからといって、サブスクリプションURLをサーバーアドレス欄に貼り付けたり、設定ファイルをサブスクリプション更新に使ったりしないでください。

購入履歴とローカル設定の違い

機種変更時は、まずApp Storeで購入履歴を確認し、購入時に使用したAppleアカウントでアプリを探してください。再ダウンロードの可否やファミリー共有の適用可否は、App Storeのページに記載された内容を基準としてください。ストアに購入価格が表示される場合は、再購入する前にアカウントと購入済み項目を確認しましょう。アプリを入手する権利と、クライアントに保存されたデータは別のものです。購入済み項目を復元しても、サーバーやルールは復元されません。

そのため、旧デバイスが使えるうちに設定の移行を計画してください。使用中のサブスクリプション名、設定名、必要な設定を記録し、元の情報を安全に保管します。サブスクリプションURLやパスワードは機密情報として扱い、公開メモやスクリーンショットに含めないでください。購入段階の完了は、アプリが正常に開き、正規版であることを確認できた時点です。次にシステムのネットワーク設定を許可し、手元の情報をクライアントに追加します。

02 / 初期設定

初回起動とシステム権限

VPN構成の追加を求めるシステム表示について

初めて接続するとき、ShadowrocketによるVPN構成の追加を許可するよう求められる場合があります。これはクライアントがデバイスのネットワークリクエストを処理するために必要なシステム権限であり、サーバーアカウントではなく、サブスクリプションが有効になった証明でもありません。操作中のクライアントからの表示であることを確認してから、システムの指示に従って認証してください。許可されたことは、システムが該当するネットワーク構成を認めたことを示すだけです。サーバーに接続できるかは、別途確認が必要です。

その場で許可しなかった場合は、クライアントに戻って接続を再度開始し、表示がもう一度出るか確認してください。必要に応じて、システム設定のVPN関連項目で構成の状態を確認します。設定画面の場所や名称はシステムによって異なるため、デバイスの表示に従ってください。一度の確認表示を解決するために、ネットワーク設定をすべてリセットしないでください。まず、権限が未許可なのか、許可済みでも接続に失敗しているのかを切り分けましょう。

Homeで操作対象を確認する

Homeを開いたら、接続スイッチ、Global Routing、Connectivity Test、SERVERリストを確認します。接続スイッチは現在の接続を開始・停止し、Global Routingはリクエストのルーティング方法を決めます。SERVERリストには追加済みのサーバーが表示され、Connectivity Testは接続テストの参考に使います。それぞれ役割が異なります。リストにサーバーがあっても接続中とは限らず、テスト結果が表示されてもルールが想定どおりとは限りません。

SERVERリストが空の場合は、次の章で情報を追加してください。接続スイッチを何度も操作する必要はありません。すでに項目がある場合は、名前、種類、デフォルト選択を確認し、以前の情報を新しく追加したものと取り違えないようにします。画面のレイアウトはデバイスのサイズやアプリの調整によって変わることがあります。本ガイドでは固定座標ではなく、画面上の名称で機能を案内します。各項目の基本説明は、初回起動とHome画面の説明をご覧ください。

操作に必要な追加権限を許可する

Scan QR Codeを使う場合、QRコードの読み取りにはカメラ権限が必要です。写真からQRコードを選ぶ場合は、写真へのアクセスを別途求められることがあります。必要な操作に応じて権限を許可してください。サーバー情報の手入力とQRコードのスキャンは別の入口です。カメラ権限がないからといって、ネットワーク接続の権限も拒否されているわけではありません。読み取りに失敗した場合は、権限、画像の鮮明さ、現在の入口で認識できる情報の種類を順に確認します。

QRコードやクリップボードの内容には、認証情報が含まれている場合があります。操作前に、手元のサービス情報から取得した内容であることを確認してください。読み取り後は、保存する前にインポート内容を確認します。受け取った画像を無条件にインポートしたり、QRコードを含む画面全体を公開したりしないでください。コピー後にインポートの案内が表示されない場合は、情報の種類に応じた追加画面に戻って操作します。案内を表示させようとして異なる内容を何度もコピーすると、情報の出所が分からなくなるおそれがあります。

接続前にシステム側の影響を確認する

デバイスで別のVPN構成が動作している場合は、まず用途と管理上の要件を確認してください。Shadowrocketをテストするときは、ネットワークを制御する対象を一度に1つに絞り、システム状態が頻繁に変わらないようにします。組織の管理下にあるデバイスでは、構成や権限が管理ポリシーによって制限されることがあります。変更できないスイッチやシステム制限の表示がある場合は、クライアントの設定を何度も作り直すのではなく、デバイスの管理要件に従ってください。

また、公衆Wi-Fiに接続するときは、ネットワーク側でログインや確認が必要な場合があります。クライアントの接続を停止し、まずデバイス本来のネットワークでアクセスできることを確認してから設定を始めましょう。システム時刻も正確に保ってください。時刻がずれていると、安全な接続で証明書を正しく判定できないことがあります。初期設定が終わったら、許可済みの権限と未使用の権限を把握しておきます。問題が起きたとき、権限とサーバーのどちらに原因があるかを切り分けやすくなります。

03 / 追加

サーバー、Subscribe、プロトコル設定

情報の種類に合った追加方法を選ぶ

個別のサーバー情報はAdd Serverから手動で入力するか、クライアントが対応する共有情報を使って追加できます。継続的に更新される複数のサーバー情報は、通常Subscribeで管理します。まず受け取った情報の種類を確認し、適切な入口を選んでください。既存のサブスクリプションは、ご利用のサービス提供元から入手します。URL全体に認証情報が含まれることがあります。貼り付ける際は、先頭と末尾、改行を確認し、チャットアプリが付けた句読点がURLの一部にならないようにしてください。

保存後にHomeへ戻り、追加した内容のグループ、名前、サーバーの種類が元の情報と一致するか確認します。項目が表示されるのはクライアントが情報を読み取ったことを示すだけで、サーバー側の認証情報が有効である証明ではありません。追加結果が空の場合は、取得した内容がクライアントで読み取れるサーバー情報なのか、ログイン画面や案内文なのかを確認してください。更新に失敗したとき、同じ名前のサブスクリプションを何度も作って問題を覆い隠さないでください。

プロトコル設定を項目ごとに確認する

プロトコル名によって設定項目の意味は異なります。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardで同じ入力方法を使うことはできません。まず正しい種類を選び、元の情報に従ってアドレス、ポート、プロトコルに必要な認証項目を入力します。名前はローカルで識別するためのラベルにすぎず、名前を変えてもサーバー接続は直りません。一方、ポートや認証情報は通信に直接使われるため、特にコピー時の空白や大文字・小文字に注意して照合してください。

プロトコル	重点確認項目	よくある注意点
Shadowsocks	アドレス、ポート、暗号化方式、パスワード	暗号化方式をサーバー側と一致させる
VMess / VLESS	UUID、通信方式、安全設定	アドレスの置き換えだけで同じ設定になるとは限らない
Trojan / Hysteria2	認証情報、TLS、プロトコル関連項目	証明書名と接続先アドレスが異なる場合がある
WireGuard	鍵、アドレス、Peer、エンドポイント	秘密鍵は機密情報です

TLSを有効にした接続では、Server Nameなどの項目が関係することがあります。入力する接続先アドレスと一致するとは限りません。特定の通信方式を使用する場合は、PathやHostなどもサーバー側の設定に合わせる必要があります。項目名から値を推測せず、不明な情報は元の資料で確認してください。証明書の検証を無効にするのは通常の対処方法ではなく、接続先の本人確認を弱めます。まず名前、システム時刻、情報の有効期限を確認しましょう。

サブスクリプション更新と手動編集を分けて扱う

サブスクリプションを保存したら更新を実行し、サーバー数、名前、グループの変化を確認してください。更新に失敗する原因は、URLの取得、ネットワークアクセス、内容の解析など、特定の段階にある可能性があります。すべてのサーバーが同時に無効になったとは限りません。現在使えるリストを残したうえで、サブスクリプションURLが変更されたか、更新や期限延長が必要か、現在のネットワークで内容を取得できるかを確認します。比較材料を失い、使えていた接続を中断するおそれがあるため、すぐにグループ全体を削除しないでください。

サブスクリプションで管理されるサーバー情報は、次回更新時に再生成または上書きされる場合があります。特定の項目を一時的に確認する場合は、元の値を記録し、サブスクリプション項目の編集がクライアントでどのように扱われるかを把握してください。長期的な修正は、サービス提供元が示す正確な情報に基づいて行い、更新のたびに手作業で直す運用は避けましょう。更新後はデフォルトのサーバーも再確認してください。名前の変更、項目の置き換えや削除によって、以前の選択が影響を受けることがあります。

手動追加、スキャン、重複項目の確認

情報がそろっており、項目ごとに確認したい場合は手動追加が適しています。対応するQRコードがある場合はScan QR Codeを使えます。スキャンは情報の入力方法にすぎず、サーバーの接続性を高めるものではありません。読み取った後は種類と主要項目を確認してから保存・テストしてください。同じ名前に見える項目が複数ある場合は、プロトコル、アドレス、ポートを比較します。名前だけを見てまとめて削除しないでください。通信設定が異なる項目でも、似た名前が付けられている場合があります。

情報の追加後は、内容が明確なサーバーを1つ選んで初回テストを行います。最初から複雑なルールを追加したり、複数のプロトコル設定を一度に変更したりしないでください。「この情報はどの資料から取得したか」「どの項目を最後に確認したか」「なぜデフォルトにしたか」を説明できれば、トラブル対処の準備が整っています。サブスクリプションは情報の管理を担います。実際のリクエストの経路はGlobal Routingと設定で決まり、次の章でそれぞれ説明します。

04 / ルーティング

Global Routingと設定ファイル

Config、Proxy、Directの違い

Global Routingの設定、プロキシ、直接接続は、それぞれConfig、Proxy、Directに対応します。Configは現在の設定に含まれるルールに基づいてリクエストの経路を決めます。Proxyはリクエストをプロキシモードで処理し、Directは直接接続モードで処理します。モードを変えるとルーティングの判断方法が変わりますが、誤った認証情報が自動で修正されるわけではありません。問題が起きた場合は、まず現在のモードを確認してください。ルールによる直接接続を、サーバーの不具合と誤認するのを防げます。

モード	確認ポイント	確認に適した状況
Config	現在の設定、ルールの順序、ポリシー	日常のルーティングとルールの一致確認
Proxy	デフォルトサーバーとリモート接続	ルールの影響を一時的に切り分ける
Direct	現在のネットワーク自体のアクセス状況	直接接続経路との比較に使う。サーバーの利用可能性を示すものではない

トラブル対処では、比較のために一時的にモードを切り替えられますが、切り替える目的を毎回記録してください。Proxyでは使えるのにConfigで問題が起きる場合は、ルールとポリシーを優先して確認します。どちらのモードでも問題が起きる場合は、サーバー、名前解決、現在のネットワークを確認してください。Directで特定の接続先にアクセスできても、その接続先が現在の直接接続経路で到達可能だと分かるだけです。接続先ごとにネットワーク条件は異なるため、1つのページの結果からすべての接続状況を推測することはできません。

設定ファイルのセクションと役割

Config画面では設定ファイルを管理し、Global RoutingのConfigはルーティングモードを示します。名前は似ていますが、操作対象は異なります。設定ファイルにはGeneral、Rule、Hostなどのセクションがあり、全般設定、ルール、ホストのマッピングなどを担います。編集前に、現在実際に使われているファイルを確認し、使用可能なコピーを別途保存してください。ファイルがリストにあるだけでは、接続時に有効な設定とは限りません。

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この例は構造を説明するためのもので、すべてのネットワークに適した完全な設定ではありません。example.comは例示用ドメインです。PROXYはプロキシポリシー、DIRECTは直接接続ポリシーを示します。実際のプロキシ接続先は、現在選択しているサーバーや定義済みのポリシーと合わせて確認してください。検証済みの既存設定は残し、テストが必要な部分だけを変更します。異なる出所の設定ファイルを丸ごと連結すると、セクションの重複やポリシー参照の不整合が生じるため避けてください。

ルールは上から順に照合される

ルールは通常、記述された順に判定されるため、具体的な条件を広範な条件より前に置きます。DOMAINは指定したドメインに一致し、DOMAIN-SUFFIXはドメインのサフィックスに、DOMAIN-KEYWORDはドメイン内のキーワードに一致します。IP-CIDRとIP-CIDR6はアドレス範囲を対象とし、GEOIPはIPアドレスの所在地データベースに基づいて判定します。FINALはそれ以前のルールに一致しないリクエストを処理するため、最後に配置します。前の広範なルールに一致すると、後ろのより具体的なルールは想定どおりに機能しません。

ドメインルールとアドレスルールは、依存する情報が異なります。リクエストがドメイン条件で判定できるかは、クライアントが実際に取得するリクエスト情報によります。アドレスの所在地判定も、サービスの提供地域を示すとは限りません。ドメイン名に特定の語が含まれているからといって、関連するすべてのリクエストに広範なキーワードルールを追加しないでください。1つのページが複数のドメインにアクセスすることがあります。実際の記録に基づいて必要な条件を少しずつ追加し、変更範囲を広げすぎないようにしましょう。

保存結果だけでなく変更後の動作を確認する

保存後、設定が引き続き認識されることを確認し、新しいリクエストを発生させて一致結果を調べます。編集が成功したという表示は、テキストが保存されたことを示すだけです。ルールの適用には、現在有効なファイル、ルーティングモード、リクエストの照合情報も関係します。既存の長時間接続が以前の経路を使い続けることがあるため、確認時はリクエストを新たに発生させてください。変更後に問題が起きた場合は、条件を次々に追加するより、直前に変更したルールを元に戻すほうが原因を特定しやすくなります。

設定ファイルとサブスクリプションは分けて管理します。サブスクリプションはサーバー情報を更新し、設定ファイルはルーティングや関連動作を制御します。ルールで参照するポリシー名には対応する定義が必要です。存在しない名前は、サーバーを増やしても解決しません。意味が分からない設定は、使えるコピーを残してから確認してください。コメントだけを頼りに削除しないでください。具体的な問題についてはトラブル対処を参照できますが、その前に現在のファイル、モード、対象リクエストを記録しておきましょう。

05 / 接続確認

デフォルトサーバー、接続、テスト

条件を明確にしたテストを始める

Homeに戻り、SERVERリストでデフォルトサーバーを確認し、DOTマークが示す項目を確認します。編集画面を開く操作とデフォルトサーバーを選ぶ操作は別です。リスト上の実際の選択状態を確認してください。初回テストでは、情報の出所が明確で、プロトコル設定も確認済みのサーバーを1つ選びます。自動選択の複雑な条件は一時的に無効にしてください。接続状況が変化したとき、ネットワークの変化か選択ロジックの変化かを判断しにくくなります。

次にGlobal Routingを確認し、現在の設定名を記録してから接続スイッチをオンにします。システムからVPN構成の追加を求められた場合は、前述の手順で許可してください。状態が安定してからテストを行い、スイッチをすばやく何度も切り替えないでください。頻繁な再接続は複数回の試行記録を混在させ、システムの状態が更新される前に次の操作を始める原因にもなります。システムに明確なエラーが表示された場合は、文面を記録してから操作を止め、内容を分類してください。

テスト結果を段階ごとに確認する

Connectivity Testは接続状況を判断するための補助機能です。具体的なテスト方法と接続先は、現在のクライアント設定を基準としてください。結果はローカルネットワーク、サーバーの応答、テスト対象、プロトコル条件の影響を受けます。数値が小さくても、すべての通信が正常とは限りません。タイムアウトしても、認証情報が誤っているとは限りません。どのサーバーをどの方法でテストしたのかを確認し、実際のアクセス結果と照らし合わせてください。

確認は3段階で行います。システムが接続を許可すること、クライアントが選択したサーバーと通信できること、対象リクエストが想定したポリシーで応答を受け取ることです。段階ごとに確認すれば、「スイッチがオンになった」だけで成功と判断するのを防げます。接続後、結果を確認しやすい接続先にアクセスし、想定したポリシーが使われているかを調べましょう。次に別の種類のリクエストもテストし、ページのキャッシュによる見かけ上の成功でないことを確認します。

ネットワーク、設定値、ルールの順に切り分ける

接続できない場合は、まずクライアントを停止し、デバイス本来のネットワークが使えるか確認してください。元のネットワークでも問題が起きる場合は、ネットワークへのログイン、電波、ルーターを先に確認します。元のネットワークが正常なら、デフォルトサーバーとプロトコル設定を照合します。アドレスの名前解決、ポートへの到達、認証失敗、証明書の検証失敗は、それぞれ異なる段階の問題です。表示や記録を手がかりに区別し、すべてを「サーバーのタイムアウト」と一括りにしないでください。

次に一時的にモードを切り替え、ルールの影響を切り分けます。同じ接続先へのリクエストがプロキシモードで成功し、Configで失敗する場合は、現在の設定ファイルと一致したポリシーを確認してください。どちらでも失敗する場合は、サーバー情報とネットワーク条件を調べます。変更は一度に1つの項目またはモードに限定し、同じリクエストを再度実行してください。具体的な順序はサーバーのタイムアウトを切り分ける手順も参考になります。原因を調べている間にすべての条件を同時に変えないでください。

接続できるが一部のコンテンツに問題がある場合

ウェブページの本文は表示されるのに、画像、ログイン、その他のリソースが読み込めない場合は、複数のリクエストを分けて確認します。1つのページから複数のドメインに接続し、それぞれ別のルールに一致している場合や、持続接続を使っている場合があります。失敗したリソースのドメイン、適用されたポリシー、エラーが起きた段階を記録してから調整してください。ページのURLだけをルールに追加しても、すべてのリソースの経路が変わるとは限りません。また、すべてのリクエストに同じポリシーを長期間適用するのも避けてください。

特定のアプリだけに問題がある場合は、まずそのアプリとブラウザが同じ接続先にリクエストしているかを比較し、キャッシュ、名前解決、接続の再利用が影響していないか確認します。必要であれば対象のアプリを完全に終了してから再試行し、変更前後の結果を記録してください。安全な接続に関するエラーがある場合は、システム時刻とサーバー名を確認します。一度テストを通すために認証を省略すると、接続で保つべき安全性が損なわれるため避けてください。

テストを終えて通常の状態に戻す

テスト後は、一時的に使用したルーティングモードを日常の設定に戻し、テスト中にデフォルトサーバーが変わっていないことを確認します。使用可能な設定、テスト時のネットワーク、主な結果を記録してください。頻繁に変わる瞬間的な数値を記録する必要はありません。有用な記録は、「どの条件で、どのリクエストが、どのポリシーで成功したか」を示すものです。「接続正常」とだけ書くより、次回の問題と比較しやすくなります。

初回接続の確認には初回接続とConnectivity Testも参考にしてください。トラブル対処を続ける場合は、サーバーの種類、モード、エラー文、再現手順など必要最小限の情報を残します。パスワード、サブスクリプションURL、秘密鍵、共有情報全体は公開しないでください。後でDataを使ってリクエストを確認する場合も、同じように段階を分けて判断します。

06 / 状況確認

Dataの通信量とリクエストの確認

統計値は状況の手がかりであり、結論ではない

Dataでは、クライアントが表示する通信量や接続関連の情報を確認できます。具体的な項目は実際の画面に従ってください。通信量の増加は、該当する集計範囲でデータが通過したことを示しますが、リクエストの完了や、すべての通信が同じ接続先を経由したことを示すものではありません。反対に、目立った変化がなくても、キャッシュ、統計の更新タイミング、リクエスト未実行が原因の場合があります。まず何を観察しているかを明確にし、総量だけで個別のリクエスト結果を判断しないでください。

データを確認する前に、接続が動作中であること、デフォルトサーバーが正しいこと、テスト中に大量のバックグラウンド処理がないことを確認します。写真の同期とウェブページ1つのトラブル対処を同時に行うと、合計通信量を目的の操作に結び付けにくくなります。観察する時間を短くし、再現可能なリクエストを1回だけ実行してから新しい記録を確認しましょう。これにより、「ページ表示」「リクエスト発生」「ポリシー一致」の3つを時系列で関連付けられます。

対象リクエストから適用ポリシーを確認する

クライアントにリクエスト履歴や接続詳細が表示される場合は、まず再現した時刻に該当する記録を探し、確認できるドメイン、アドレス、ポリシー、エラー情報を調べます。プロトコルやリクエストの種類によって表示される情報は異なります。各記録に完全なURLや内容が含まれるとは限りません。記録からアプリ全体の動作を推測するのではなく、リクエストがどこへ向かい、どの条件に一致し、どの段階で止まったかを確認してください。

Configモードでは、特に想定したポリシーと実際のポリシーを照合します。PROXYを想定しているのにDIRECTが適用された場合は、前のルールと現在有効な設定ファイルを確認してください。ポリシーが想定どおりでもリクエストが失敗する場合は、該当サーバーと接続先への到達性を調べます。ルールに一致したことは、経路の選択を示すだけで、接続先サービスが正しく応答したことを示すものではありません。ポリシーの段階と通信の段階を分けると、無駄な設定変更を減らせます。

名前解決、接続確立、データ通信を切り分ける

ドメインへのリクエストでは、通常まず名前解決を行い、選択されたアドレスに接続してからアプリのデータを交換します。名前解決に失敗しているときにパスワードを変えても意味はありません。接続先アドレスが決まっているのに接続を確立できない場合は、ネットワーク、ポート、サーバー側を確認します。接続確立後に安全なハンドシェイクで問題が起きた場合は、証明書名、時刻、関連設定を調べてください。エラー表示は段階によって異なるため、前後の状況と合わせて読み、文面を統一せず原文のまま記録します。

ドメインに複数のアドレスが対応していても、設定の混乱とは限りません。ネットワーク、時刻、地域などに応じて異なる結果を返すサービスがあります。そのため、アドレスルールの一致先も変わる場合があります。まず同じリクエストを再実行して現象を確認し、直接接続とプロキシ経由の名前解決条件を比較してください。検証せずに一度取得したアドレスをHostに固定すると、すぐに適用できなくなったり、新たな問題を招いたりするおそれがあります。

統計の集計範囲とサービス側の記録は異なる

クライアント、デバイスのシステム、サービス側では、統計の集計範囲が異なることがあります。通信方向、接続に伴うデータ、対象時間などが別々に計算されるため、数値が完全に一致するとは限りません。通信量の異常を調べる場合は、まず観察する時間をそろえ、目立ったバックグラウンド処理を停止してから推移を確認します。短時間の差だけで課金エラーと判断したり、合計値をすべてのアプリの完全な利用履歴とみなしたりしないでください。

統計をリセットする前に、比較に必要な結果を保存し、リセットがどの項目に影響するか確認してください。通常、ローカルの表示を消去してもサービス側の利用記録は変わらず、接続の問題も直りません。トラブル対処では、何度も値をリセットして観察するより、特定のリクエストに伴う状態変化のほうが役立ちます。統計の表示が複数ある場合は、まず各表示の名称と集計範囲を確認し、目的に合うものを選びましょう。

記録を共有する前に必要最小限にする

リクエスト記録に、アクセス先、サーバーアドレス、その他の識別情報が含まれる場合があります。書き出しやスクリーンショットの前に表示内容を確認し、問題解決に必要な範囲だけを残してください。サブスクリプションURLのクエリパラメータ、サーバーのパスワード、UUID、秘密鍵は記録と一緒に公開しないでください。QRコードだけの共有でも、接続情報全体を渡すことになる場合があります。名前を隠しただけでは、機密情報を隠したことにはなりません。

トラブル対処用の情報をまとめる際は、再現操作、発生段階、使用プロトコルとポリシーを記載し、認証情報を含まないエラー原文を添えるとよいでしょう。自分用には完全な記録を保管し、他者には必要最小限の部分だけを共有します。問題の原因がサーバー側の設定にあると特定できた場合は、元の情報を確認し、関係のないリクエストを記録し続ける必要はありません。確認を終えたら通常のモードに戻し、テスト用に有効にした追加記録を長期間残さないようにしてください。

07 / 設定

Settingsの主な項目と変更時の注意

まず設定がどの範囲に適用されるか確認する

Settingsの各項目が同じ機能を制御するわけではありません。クライアント全体の動作、接続処理、表示やテストの設定など、項目によって影響範囲が異なります。サーバー編集画面の設定は、1つの項目だけに適用される場合もあります。変更前に適用範囲を見極め、設定ファイルにも関連する動作が定義されていないか確認してください。特定サーバーの通信設定を全体のネットワーク設定と取り違えたり、同じ名前の項目が別の画面でも同じ優先順位だと考えたりしないでください。

この章では用途ごとに設定を説明します。すべてのデバイスで同じ項目が表示されるとは限りません。画面上の名称と利用可能な項目は、現在のクライアントを基準としてください。意味の分からない項目は、現在の値と解決したい問題を記録してから説明を確認しましょう。接続がすでに使える場合は、高度な項目をまとめて有効にするより、初期状態を保つほうが管理しやすいことが多いです。目的のない変更は効果を検証しにくく、問題が起きたときの復元も難しくなります。

手動接続を確認してからOn Demandを設定する

On Demandは、条件に応じて接続関連の動作を開始するために使います。有効にする前に、手動接続と対象リクエストの確認を済ませてください。問題が未解決のまま自動実行すると、状況を把握しにくくなります。関連する設定を開き、有効状態と適用条件をよく確認してから、実際の環境でネットワークを切り替えてテストします。「有効」になっていても、あらゆる状況で接続が維持されるとは限りません。実際の動作はシステム、ネットワーク条件、設定の影響を受けます。

オンデマンド接続をテストするときは、想定どおりに開始する場合と、開始しない場合の両方を確認します。たとえばネットワークを切り替えた後、システムの状態が安定するまで待ってから接続状況とリクエスト結果を確認してください。接続が繰り返される場合はOn Demandを一時的に無効にし、手動で基本接続が使えることを確認してから、起動条件を調べます。管理対象デバイスでは制限も確認し、クライアントの条件とシステムの管理要件が予期しない影響を及ぼさないようにしてください。

再現可能な問題がある場合にDNSを調整する

DNSはドメイン名からアドレスへの名前解決に影響し、一部のルール判定にも関係することがあります。名前解決の段階に問題がある、または結果が想定と異なると確認できた場合に限り、関連設定を変更してください。元の名前解決方式、テスト対象のドメイン、エラーの内容を記録し、一度に1項目だけ変更します。接続トラブルが起きるたびにDNSを最初に切り替えるのは避けてください。ポートの誤り、無効な認証情報、不一致の通信設定は、名前解決方式を変えても直りません。

設定例のdns-server = systemは、システムに関連する名前解決設定を使うことを示します。すべてのネットワークに適するという意味ではありません。別の名前解決方式を使う場合は、アクセス経路と適用条件を理解してください。名前解決サービス自体が、まだ確立していない接続に依存する状態も避ける必要があります。変更後はキャッシュの影響も考慮しながら、新しいリクエストを実行して結果を比較します。テスト後はどの方式を最終的に使うかを明確にし、一時的な変更を積み重ねないでください。

テスト、タイムアウト、ネットワーク切り替え

Connectivity Testの関連設定はテスト方法を決めます。方法を変えると結果を比較しにくくなるため、複数のサーバーを比較する場合は方法と接続先をそろえてください。異なる条件の結果をそのまま順位付けしないようにしましょう。タイムアウトの設定にも妥当な範囲が必要です。短すぎると正常でも遅い応答を失敗と判断し、長すぎると問題の検知が遅れます。結果の見栄えだけを求めて変更するのではなく、現在のネットワークの特性を理解してから調整してください。

ネットワーク切り替え後に一時的な問題が起きた場合は、システムの切り替えが終わるまで待ってから新しいリクエストを実行してください。以前の接続を新しい経路で続けられないことがあり、アプリが自動的に再試行する場合もあります。切り替え時だけ問題が起きる場合は、固定したネットワークで継続的に失敗する場合と分けて記録しましょう。On Demand、デフォルトサーバー、新しいネットワークの利用状況を確認するほうが、設定をすべてリセットするより効果的です。元の安定した設定も保てます。

セキュリティ関連の設定は用途を明確にする

証明書、HTTPS、リクエスト処理に関わる高度な設定は、用途と影響範囲を理解してから変更してください。通常のサーバー追加や初回接続で、追加の証明書操作を一式行う必要はありません。専用機能が必要な場合は設定を別に保存し、その機能の説明に沿って検証してください。テスト条件を日常用の設定に混在させないようにしましょう。接続先の本人確認を弱める変更を行う前に、一般的なトラブル対処として使うのではなく、元の設定情報をもう一度確認してください。

設定変更の記録は、元の値、変更理由、テスト結果、変更を残すかどうかが分かれば十分です。使用可能だった状態に戻せることが、曖昧な記憶よりも重要です。変更で問題が解決しなかった場合は、変更した事実にこだわらず、速やかに元に戻してください。最後に現在の設定、Global Routing、デフォルトサーバーを確認し、実際にアクセスして結果を確かめます。観察可能な結果を確認して設定変更を終えましょう。

08 / メンテナンス

更新、バックアップ、日常のトラブル対処

元に戻せる状態を維持する

日常のメンテナンスで大切なのは、頻繁に変更することではなく、現在なぜ使えているか把握することです。検証済みの設定を1つ保存し、デフォルトサーバー、Global Routing、必要な全体設定を記録します。変更前にはコピーを別に保存し、用途が分かる名前を付けてください。判別しにくい番号を積み重ねる必要はありません。関連する内容を一度に1組だけ変更し、検証してから日常用の設定と入れ替えるか決めます。そうすれば問題発生時に直近の変更を元に戻せます。

バックアップには自分で編集したルールと必要な設定を含めますが、機密情報は別に保護してください。サーバーのパスワード、秘密鍵、サブスクリプションURLを一般的な文書と一緒に公開できる場所へ保存しないでください。クライアントの書き出し、バックアップ、復元機能を使う場合は、どのデータが含まれるかを確認してから、自分で管理できる場所に保存します。バックアップができても、復元できるとは限りません。必要に応じてコピーを使って読み込みを確認し、元の情報も保管してください。

アプリのアップデートとサブスクリプション更新を区別する

アプリのアップデートはApp Storeで行い、サブスクリプションの更新はクライアント内でサーバー情報を管理するものです。両者は独立しています。アプリをアップデートしても期限切れの認証情報は更新されず、サブスクリプションを更新してもApp Storeでの購入状況は変わりません。アプリのアップデート前に重要な設定を保存し、ストアの説明を確認してください。アップデート後は、現在のファイル、デフォルトサーバー、接続状況を確認します。アプリが開くことだけで検証を終えないでください。

サブスクリプションの更新後は、グループ、項目、デフォルト選択を確認してください。サービス側でサーバーが削除されると、そのサーバーに依存していた選択を見直す必要があります。名前が同じでも設定値が変わっていないとは限らないため、問題が起きた場合は手元の情報と照合します。更新に失敗したら使用可能な情報を残し、取得と解析のどちらで失敗したかを判断してから再試行してください。アプリとサブスクリプションの更新を同時に行い、どちらの変更が接続に影響したか分からなくなる状況は避けましょう。

機種変更と再インストールでは3段階で復元する

復元は、まずアプリを入手し、次にサーバー情報を戻し、最後に設定ファイルと設定を復元します。第1段階ではApp Storeの購入済み項目を確認します。第2段階では、ご自身で安全に保管しているサブスクリプションまたはサーバー情報を使います。第3段階ではバックアップを読み込み、適用範囲を確認します。順番に進めれば、アプリは入ったのにサーバーがない、あるいはサーバーは追加できたのにルールが空のままといった事態を防げます。

新しいデバイスでは、システム権限と互換性を改めて確認してください。システム要件はApp Storeのページに記載された内容を基準とします。旧デバイスの権限がすべて移行されるとは限りません。また、購入済み項目の復元はローカルデータの復元とは異なります。復元後は、サーバーを1つ、接続先を1つ選んで確認してから、オンデマンド接続やその他の追加条件を有効にします。移行の検証が終わるまでは旧デバイスを使用可能な状態に保つと、直接比較できます。

すべてをリセットせず、問題が起きた段階を絞り込む

問題が起きたら、接続を開始できない、テストがタイムアウトする、一部のリクエストが失敗する、ルールの経路が想定と異なる、のどれに当たるかをまず記録します。次にネットワーク切り替え、サブスクリプション更新、ルール編集、システム設定変更など、直近の変化を確認してください。変化に直接関係する段階から調べます。すべてをリセットすると手がかりと使用可能な設定を同時に失います。影響を理解し、バックアップがある場合に限って、大きな範囲の復元を検討してください。

続けて確認する場合、購入と復元はダウンロードガイド、基本操作はクイックスタート、よくある問題はトラブル対処をご覧ください。画面上の用語とエラー文を原文のまま記録すると、該当機能を正確に特定しやすくなります。サーバー情報が不足している場合は、手元のサービス情報を確認してください。ルールを何度切り替えても、不足しているプロトコル設定を補うことはできません。

必要最小限の記録で日常点検を行う

メンテナンス記録では、次の4点が分かれば十分です。現在使っている設定ファイル、デフォルトサーバー、直近の変更、検証結果。大量のスクリーンショットを整理せずに保存するより、問題が起きたネットワークと再現手順を記録するほうが役立ちます。解決後は原因と元に戻す方法を記録し、公開用のコピーから認証情報を削除してください。似た問題が再発したときは、前回の変更をすべて繰り返すのではなく、原因が同じかを先に確認できます。

最後に実際の利用状況を確認します。現在のモードが想定どおりで、対象リクエストが完了し、ルールの経路を説明でき、一時的なテスト設定が元に戻っていることを確かめてください。接続できた後に設定を重ねて追加する必要はありません。用途が分からないファイルを増やすより、明確で検証でき、元に戻せる設定を保つほうが管理しやすくなります。この8段階は何度でも活用できます。問題がどの段階にあるかを特定し、入力情報を確認してから、同じリクエストで結果を検証してください。