Shadowrocketの使い方完全ガイド：購入・設定・接続トラブルの解決方法

1. App Storeでの入手と購入確認

まずアプリが正しいことを確認してから、接続に必要な情報を準備します。ShadowrocketはAppleプラットフォーム向けのクローズドソースの有料アプリで、入手先はApp Storeのみです。アプリの購入で得られるのはクライアントの利用権です。お持ちのサブスクリプションやサーバーを利用できるかどうかは、別途確認が必要です。この2つを分けて考えると、インストール後に接続先がなくても購入が無効になったと誤解せずに済み、アカウントの購入問題とネットワーク接続の問題も区別できます。

製品ページで確認する3つの項目

当サイトの正規版の確認方法から製品ページを開き、アプリ名がShadowrocket、デベロッパがShadow Launch Technology Limited、製品ページのURLに含まれるアプリIDが932747118であることを順に確認してください。また、当サイトのページ上部に表示されている公式アプリアイコンとも照合します。検索結果の名前が似ているだけでは確認になりません。同じ製品ページ上で確認を済ませてから、購入ボタン、互換性、アプリの説明を確認してください。

ストアページのアイコン、デベロッパ、アプリIDが製品を見分ける手がかりです。検索順位や名前に含まれる別称だけで判断しないでください。ページに表示されたデベロッパが一致しない場合は、まず確認手順に戻り、その後の権限設定や購入手続きを同じアプリのものとして進めないでください。アプリ名とデベロッパ名は別の項目です。

価格、対応デバイス、購入範囲

Shadowrocketは買い切りです。米国ストアでの価格は約2.99米ドルですが、実際の金額、通貨、税金はApp Storeの表示をご確認ください。購入前に、App Storeで使用するAppleアカウントとストアの国または地域を確認し、購入後はシステムに記録される購入履歴を保管してください。価格は接続品質を示すものではなく、サーバーの有効期限、利用可能な通信量、接続可能な地域を判断する根拠にもなりません。

このマニュアルでは主にiPhone / iPadを扱います。Mac、Apple TV、Apple Visionへの対応は同じ製品ページの互換性欄で確認できます。システム要件と購入の適用範囲は、App Storeの表示をご確認ください。あるデバイスにインストールできたからといって、別のデバイスにも必ず対応するとは限りません。2台目のデバイスで使う前に、デバイスのシステム、アカウントの購入履歴、製品ページの互換性情報をそれぞれ確認してください。

インストール、購入済みアプリの復元、アップデート

購入後、App Storeからアプリをインストールします。再インストールや機種変更の際は、まず購入時のアカウントで購入済み項目を確認し、ストアの案内に従って復元してください。ページに購入金額が表示される場合は、すぐに再購入せず、現在ストアで使用しているアカウント、購入履歴、製品が一致しているかを確認します。ほかのシステムサービスに使うアカウントと、ストアでの購入に使うアカウントが異なる場合があります。実際の購入履歴をご確認ください。

アプリの復元と接続設定の復元は別の作業です。ストアから購入済みアプリを再入手できても、サーバーアドレス、サブスクリプションの内容、現在選択中の設定ファイル、ローカルルールは、元の保存方法に応じて個別に確認してください。再インストールですべての接続情報が復元されるとは限りません。ファミリー共有の対象になるかどうかも、App Storeの表示とアカウントの状況に基づいて判断してください。ほかのアプリの購入経験から推測することはできません。

アップデートもApp Storeから行います。アップデート前に、現在使用しているサーバー、Global Routingの状態、Configファイル名を記録してください。重要なローカル変更は事前にバックアップします。アップデート後は、設定を変更する前に既存の接続を確認しましょう。違いが生じた場合に、情報、ネットワーク、今回の操作のどれが原因か判断しやすくなります。ストアのアップデート履歴で変更内容を確認できます。このマニュアルではアプリのバージョン番号を固定して記載していません。

次の章に進む前に、アプリが正常に起動し、ご自身のサーバー情報またはサブスクリプションを用意できていることを確認してください。購入履歴、デバイスの互換性、アプリのインストールを確認してから、権限設定と情報の追加に進みます。アカウントの復元、購入価格、入手先については、購入済みアプリの復元と価格についてもご覧ください。

2. 初回起動とVPN構成の許可

初回起動時は、まず画面の構成を確認してからシステムの許可を設定します。Homeでは登録済みサーバーの確認、接続先の選択、接続の操作を行います。Configでは設定ファイルを管理します。Dataでは通信量やリクエストを確認します。Settingsではアプリの動作を調整します。デバイスやアプリのアップデートによってレイアウトが変わる場合があるため、古い画面例でのボタン位置ではなく、英語の項目名を目印にしてください。初回接続では、すべての設定を一度に有効にせず、確認可能な基本状態を作ることを目指します。

システムのVPN許可とは

Shadowrocketは接続時に、システムのVPN構成機能を使用します。初めて該当する操作を行うと、VPN構成の追加を許可するよう求められ、デバイスの認証が必要になる場合があります。これはクライアントがシステムのネットワーク経路で動作することを許可するものです。サーバー情報が正しいことや、リモートサービスへのログインが成功したことを確認するものではありません。アプリのインストール、システムの許可、サーバー認証はそれぞれ別の段階です。問題を調べる際は分けて確認してください。

許可する前に、表示がシステムからのものであることと、確認済みのShadowrocketを開いていることを確かめてください。許可したらアプリに戻り、接続状態を確認します。以前に許可をキャンセルした場合は、もう一度接続を開始し、その時点で表示される案内に従ってください。キャンセルを取り消すためにアプリを何度も削除する必要はありません。必要に応じて、システムのSettingsにあるVPN関連の項目で現在の構成を確認します。メニューの階層は、デバイスに表示される内容に従ってください。

初回接続前に確認する基本状態

まず未接続の状態で、デバイスから普段使うウェブサイトにアクセスできるか確認します。Wi-Fiの認証が完了していない、モバイルデータ通信が無効、ネットワークが一時的に切断している、といった状況を除外してください。基本的なウェブページも開けない場合は、まず現在のネットワークを確認します。クライアントは既存のネットワークを使ってサーバーに接続します。VPNのマークが表示されても、ネットワークへの接続や公衆Wi-Fiのログインが自動で完了するわけではありません。

次にHomeに見覚えのあるサーバー項目があるか確認します。リストが空でも、情報の追加がまだ行われていないだけで、インストールに失敗したとは限りません。項目がある場合も、特にデバイスの復元や古いバックアップの読み込み後は、自分の記録に由来する情報か確認してください。まず、必要な情報がそろい用途が明確な項目を1つ選んでテストします。初回接続では、内容が不明な設定を複数同時に使わないでください。

初回テストでは、On Demandが現在どのように設定されているか確認してください。有効になっていると、ネットワーク条件によって再接続が行われ、手動で切断した後の状態が分かりにくくなることがあります。テストの流れを明確にするには、現在の設定を記録してから、自動接続の条件を一時的に無効にします。テスト後に必要な条件を元に戻してください。記録を残さず、すべての自動化設定を変更することは避けましょう。

そのほかの権限は用途に応じて設定する

Scan QR Codeを使うと、カメラの許可を求められる場合があります。手入力や既存のリンクから追加する場合、カメラの許可は接続の前提ではありません。ローカルデバイスへのアクセスを伴う操作では、関連するネットワーク許可がシステムから求められる場合もあります。権限の案内は、直前に実行した操作と結び付けて確認してください。今回の操作に関係しない権限変更を、接続問題全般の解決手順として扱わないでください。

VPN構成の許可は、証明書のインストールを意味しません。通常のサーバー接続でHTTPSの復号化を一律に有効にする必要はありません。設定に証明書、書き換え、その他の高度な処理が含まれる場合は、用途と適用範囲を理解してから個別に検討してください。ウェブページが開けないからといって、すぐに証明書を信頼させたり、初回接続の定番手順として証明書の検証を無効にしたりしないでください。セキュリティ上の前提が変わります。

接続スイッチを入れた直後に切れる場合は、システムの案内が未完了でないかを確認し、次に設定が正しく入力されているかを調べます。スイッチがオンのままウェブページが応答しない場合は、接続確認の章に進んでください。異常が許可の前後どちらで起きたか、接続先へのリクエスト時に起きたかを記録すると、調査範囲を絞れます。スイッチを短時間に何度も切り替えると経過が分かりにくくなります。操作のたびに状態が落ち着くまで待ってから、次の確認を行ってください。

この章の完了条件は、アプリの正当性を確認済みで、基本ネットワークが使え、システムの許可に対応済みで、自動接続の条件が把握できていることです。その後、サーバーまたはサブスクリプションの追加に進みます。最短の手順で操作したい場合は使い方ガイドに戻ってください。追加する項目や設定の関係を確認したい場合は、次の章をご覧ください。

3. 既存のサーバーとサブスクリプションを追加

まず、サーバー項目、サブスクリプション、設定ファイルの違いを確認します。サーバー項目には、特定のリモートサーバーへの接続方法が記されています。サブスクリプションは、複数の項目をまとめて取得・更新するために使います。Configファイルには、主に通信の処理方法と関連パラメータが記されています。これらは組み合わせて使用できますが、互いに代用できるものではありません。リストにサーバーが表示されていても、意図したルールによる振り分けが有効とは限りません。ルールファイルを読み込んでも、利用可能なサーバーが含まれているとは限りません。

Add Serverと手動入力する項目

HomeでAdd Serverを開き、手元の情報と一致するプロトコルを選んでから、項目を1つずつ入力します。プロトコルを間違えると、ほかの項目が似ていても接続できない場合があります。アドレスには資料に記載されたホスト名またはIPアドレスを、ポートには元の値を入力します。通常、アドレス欄にウェブページのパスや説明文は入力しません。管理用ウェブページのアドレスをサーバーアドレスとして使ったり、名前に含まれる数字からポートを推測したりしないでください。

認証項目はプロトコルによって異なります。パスワード、UUID、暗号化方式、鍵は元の情報どおりに入力し、ほかの項目の形式を参考にして補完しないでください。コピー後は先頭と末尾の空白や改行を確認します。ただし、大文字と小文字を変えたり、特殊文字を削除したりしないでください。備考は項目を見分けるためのもので、アドレス、認証情報、通信パラメータの誤りを修正するものではありません。必須項目の情報が不足している場合は、よくある値を何度も試すのではなく、元の情報を確認してください。

情報の種類	主な確認項目	よくある取り違え
Shadowsocks	アドレス、ポート、パスワード、暗号化方式	備考をアドレスとして入力する、または暗号化方式を間違える
VMess / VLESS	UUID、通信方式、設定済みのTLSパラメータ	UUIDだけを入力し、トランスポート層の条件を見落とす
Trojan / Hysteria2	認証情報、TLS、設定済みの通信パラメータ	証明書のドメイン名と接続アドレスを混同する
WireGuard	鍵、アドレス、エンドポイント、ルーティング関連情報	エンドポイントだけをコピーし、設定情報全体を反映しない

TLSを使う場合、接続アドレス、証明書の検証名、通信時のHostやパスがそれぞれ異なる役割を持つことがあります。既存の設定に照らして1つずつ確認してください。値が同じ場合もありますが、常に置き換え可能とは限りません。追加後にハンドシェイクに失敗する場合は、まずこれらの項目がそろっているかを確認し、検証条件をすぐに緩和しないでください。詳細設定が表示されても、すべてのプロトコルで変更が必要という意味ではありません。

Subscribeと一括更新

既存のサブスクリプションは、アプリ内のSubscribe関連の項目から追加し、自分のサブスクリプションURLを省略せずに貼り付けます。URLにはアクセス用の認証情報が含まれる場合があるため、機密情報として扱い、公開スクリーンショットや共有メモに貼り付けないでください。追加前に、空白、改行、日本語の句読点が紛れ込んでいないか確認します。サブスクリプションURLとサーバーアドレスは用途が異なります。URL全体を個別サーバーのアドレス欄に入力しないでください。

サブスクリプションの更新は、サーバー項目の情報を再取得する処理です。既存サービスの利用期限が延長されるわけではありません。更新後は、現在選択中のサーバーが残っているか、名前が変わっていないか、手動の編集内容が新しい情報で上書きされていないかを確認してください。更新に失敗しても既存の項目が残る場合がありますが、残っているからといって設定が有効とは限りません。取得失敗、内容を解析できない問題、サーバーへの接続失敗は、原因も対処方法も異なります。

サブスクリプションが空の場合は、まずURLに抜けがないか確認します。次に、現在のネットワークからサブスクリプションの接続先にアクセスできるかを確認し、アプリの表示内容を確認してください。結果が空だからといって、すぐに古い項目をすべて削除しないでください。比較の基準を失わないよう、必要な情報を先に保存します。同じURLでもネットワークによって結果が異なる場合は、すべてのサーバーが無効と決めつけず、サブスクリプションの取得経路の違いとして記録してください。

QRコードからの追加と追加後の確認

Scan QR Codeで読み込むQRコードには、単一のサーバー情報や別の設定情報が含まれる場合があります。実際の内容は解析結果で確認してください。読み込み前に、自分の記録に由来する情報であることを確認します。追加後は項目を開き、プロトコル、アドレス、ポート、認証情報を確認してください。Import from Cloud JSONなどの項目では、指定された形式の情報を使います。ファイル名や拡張子だけで適用できると判断しないでください。

追加後は、まず項目数と名前が想定どおりかを確認します。次に、使用予定の項目を少なくとも1つ確認し、明示的に選択してから接続をテストします。名前に含まれる地域名は、実際の経路を保証するものではありません。遅延テストの結果も、実際のサービスへのアクセス成功を意味しません。既存項目の選び方については、遅延テストとサーバー選択のメモをご覧ください。

手動での変更を残したい場合は、変更箇所を記録してから、今後もサブスクリプションの内容で上書きするかを決めてください。同じ名前の複数の項目を記録なしに切り替えてテストすると、成功した項目を取り違えるおそれがあります。この章を終えたら、現在使っている項目、その情報の入手元、次回更新で影響を受ける内容を説明できる状態にしておきましょう。

4. Global Routingとルールのマッチング

Global Routingでは、通信全体の処理方法を選択します。Config、Proxy、Directは、それぞれ設定に基づく処理、プロキシ経由、直接接続に相当します。まず全体のモードを正しく選んでから、個別のルールを確認してください。モードがProxyのままルールを変更し、振り分け結果も変わると期待すると、判断を誤ることがあります。サーバー項目は接続方法を設定し、Global Routingは全体のルーティング方法を選択します。両方を明確にする必要があります。

Config、Proxy、Directの違い

画面上の項目	処理の考え方	確認するポイント
Config	現在有効な設定のルールと関連設定に従って処理する	接続先にどのルールが適用され、どのポリシーが使われるか
Proxy	全体としてプロキシ経由で処理する	既存のサーバー経由でリクエストを処理できるか
Direct	全体として直接接続で処理する	現在のネットワークから接続先へ直接接続した場合の状況

3つのモードは経路を比較するためのもので、サーバーが3種類あるわけではありません。切り替えた後は、新しいリクエストを送って再テストしてください。必要に応じて、開いているページを閉じてから開き直します。既存の接続は、新しい選択に自動で切り替わるとは限りません。Directもアプリの接続スイッチをオフにすることとは異なります。システムのトンネルとリクエストの処理方法は別の層です。完全に未接続の基本ネットワークと比較する場合は、接続スイッチの状態を別途記録してください。

Configを使う前に、Configで現在有効なファイル名と内容を確認してください。リストにファイルがあっても、それが現在使用中とは限りません。コピーを編集しても、動作中の設定に反映されるとは限りません。保存し、画面の案内に従って有効にしてから、新しいリクエストで確認してください。似た名前のファイルが複数ある場合は、用途が分かる備考を付けると、変更の反映状況を取り違えにくくなります。

ルールは上から順にマッチし、FINALが最後の受け皿になる

[Rule]セクションのルールは上から順に確認され、最初にマッチしたルールのポリシーが適用されます。そのため、範囲の狭い例外は広いルールより前に置き、最後にフォールバックのルールを配置します。DOMAINは特定のドメインに、DOMAIN-SUFFIXはドメインとそのサブドメインに、DOMAIN-KEYWORDはより広い範囲に適用されます。意図しないドメインにもマッチしないか確認してから使用してください。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system

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

以下はルールの書き方を確認するための例であり、すべての人に適した完全な設定ではありません。PROXYはプロキシ経由、DIRECTは直接接続、REJECTは拒否を意味します。例に含まれるドメインはマッチ方法の説明用で、実際のサービス確認には使えません。FINAL,PROXYは、それまでにマッチしなかった通信のフォールバックです。自分の想定に合うことを確認してから、適切なポリシーを設定してください。

IP-CIDRとIP-CIDR6はIPアドレスの範囲を対象とし、GEOIPはIPアドレスの地域情報に基づいて判定します。ドメインに直接マッチするルールとは、判定の基準が異なります。ドメインへのリクエストには名前解決が関係する場合があります。no-resolveは、そのアドレスルールのためだけにドメインを名前解決するのを避ける指定です。アプリ全体のDNSを無効にする意味ではありません。地域情報だけで個々のリクエストの実際の動作を確認することもできません。

変更は最小限にして、マッチ状況を確認する

特定の接続先を調べる場合は、既存設定のコピーに範囲が明確なルールを追加し、その接続先にマッチする可能性のある広いルールより前に置きます。一度に変更する条件は1つだけにし、保存後、新しいリクエストを送って実際の接続先とポリシーを確認してください。サーバー変更、DNS変更、ルール順の変更を同時に行わないでください。元に戻せても、どの変更が影響したのか分からず、次回の再現が難しくなります。

LAN関連の設定は、実際のネットワーク範囲に照らして判断してください。例に挙げるプライベートアドレス範囲は一部であり、デバイスのネットワークが必ず同じとは限りません。ご自身のネットワーク情報で確認してください。ローカルサービスに接続できない場合は、検出方法、デバイスの権限、ネットワークの分離状況も確認します。1つの直接接続ルールだけで、すべてのローカル通信が復旧すると判断しないでください。

Configモードで正しいファイルが有効になっており、新しいリクエストが実際にルールにマッチした場合に限り、そのルールの効果を評価できます。ルールの並べ方についてはルールの優先順位とFINALのフォールバックをご覧ください。キーワードの意味は用語集で確認できます。

5. 接続と段階ごとの確認

接続は段階ごとに確認します。基本ネットワークが使えること、クライアントの接続が維持されること、サーバー経路が使えること、接続先へのリクエストが想定どおりに処理されることを確認してください。アイコンや単一のテスト値だけでは、これら4段階すべてを判断できません。テスト前に、ネットワーク、選択中のサーバー、Global Routing、Configファイルを記録し、その後は一度に1つの条件だけを変更します。そうすることで、「さっきは動いたのに今は動かない」という状況を、再現可能な具体的条件に置き換えられます。

順番に基本接続テストを行う

まず未接続の状態で普段アクセスできるページを開き、デバイス自体がネットワークにつながっていることを確認します。次に、確認済みのサーバーを選び、Global Routingを明確に設定してから、Homeの接続スイッチをオンにします。状態が安定するまで待ち、未完了のシステムの案内があれば対応してください。接続がすぐに停止した場合は、ウェブページを何度も更新せず、今回の操作で表示された案内やログを確認します。まだ接続先へのアクセス段階に進んでいない可能性があります。

接続が維持されたら、新しいページを開き、用途が明確な接続先を1〜2件テストします。普段利用し、結果を判断しやすいページを選んでください。大量のダウンロードや複数の動画アプリを同時に起動しないでください。まずページ全体を読み込めるか確認し、その後、画像、ログインなどの操作を試します。ページタイトルが表示されても、一部のリソースだけが成功している可能性があります。サービス全体が正常とは限りません。

Configをテストする場合は、接続先に実際に適用されたポリシーを確認します。Proxyをテストする場合は、プロキシ経由の経路を確認していることを明確にします。Directの結果は、現在のネットワークから直接接続した場合の比較として扱います。ある接続先がDirectでは成功し、Proxyでは失敗しても、2つの経路に差があることが分かるだけです。サーバー、認証、名前解決、接続先側の制限を引き続き確認してください。この結果だけで設定項目の誤りと決めつけないでください。

Connectivity Testで分かることと限界

Connectivity Testなどの遅延テストでは、特定の方法で測定した到達性や所要時間を確認できます。具体的なテスト方法と接続先は、アプリの現在の設定によります。数値が返ってもすべてのサービスが使えるとは限らず、タイムアウトしてもすべての接続が失敗しているとは限りません。まずテスト先を確認し、数値と実際のウェブページへのアクセスを合わせて判断してください。異なる方法で得た結果を同じ基準で順位付けしないでください。

遅延が小さいことは、特定のテストにおける往復時間や応答特性を示すにすぎず、継続的な通信速度、接続の安定性、動画の読み込み状況を直接示すものではありません。既存サーバーから選ぶ際は、テスト時刻、ネットワーク環境、実際の用途、プロトコル情報を考慮してください。1回の数値の変化だけで頻繁に切り替えると、既存の通信が中断され、異なるサーバーの結果が記録に混在します。

異常の発生箇所から原因を絞る

症状	最初に確認する項目	次に確認すること
接続スイッチがオンのままにならない	システムの許可、設定の完全性、今回の案内	サーバーへの接続段階に進んでいるか確認する
ドメインに関するリクエストが失敗する	DNS、ドメインの入力、実際の接続先の記録	名前解決の失敗と、解決後の接続失敗を区別する
認証エラーまたはハンドシェイクエラーが発生する	プロトコル、認証情報、TLS、デバイスの時刻	元の情報と照らして項目ごとに確認する
ページの一部のリソースだけが失敗する	リソースのドメイン、適用ルール、拒否ポリシー	アドレス欄だけでなく、失敗したリクエストを確認する

名前解決に異常が見つかっても、すぐにすべてのDNS項目を見慣れないアドレスに変更しないでください。まずドメインが正しいか、基本ネットワークで認証が必要か、失敗の記録がどの段階で止まっているかを確認します。IPアドレスへの直接アクセスは、ドメインへのアクセスと同じではありません。TLS、仮想ホスト、コンテンツ配信がドメイン名に依存する場合があります。IPアドレスで接続できなかったからといって、ドメインの名前解決に問題があるとは限りません。

認証やTLSの異常が発生した場合は、元のサーバー情報に戻り、パスワード、UUID、証明書名、通信パラメータ、デバイスの時刻を確認します。時刻が大きくずれていると、証明書の検証に影響することがあります。情報の誤りを隠すために検証を無効にしたり、すべてのハンドシェイク失敗をネットワーク速度の問題とみなしたりしないでください。サブスクリプションを更新したばかりの場合は、現在の項目が以前テストしたものと同じか特に確認してください。

ネットワークを切り替えた後に問題が起きた場合は、Wi-Fiとモバイルネットワークで同じ短いテストを行い、切り替え前後の結果を記録します。一方のネットワークで失敗し、もう一方で正常なら、基本的な接続経路が異なる可能性があります。比較のため、サーバーと設定は変えないでください。公衆ネットワークへのログインが必要な場合は、先にネットワーク認証を済ませてからクライアントを再接続し、ログイン画面の問題とサーバーの問題を混同しないようにします。

有効な接続テストの記録には、テスト時刻、ネットワークの種類、項目の備考、モード、接続先、表示されたエラーを記載し、認証情報は伏せてください。原因を特定できない場合は、最も明確だった直近の失敗例を残し、Dataで該当リクエストを確認します。記録を消してから思い出そうとしたり、サブスクリプションURL、パスワード、鍵が含まれるログをそのまま公開したりしないでください。

6. Dataで通信量とリクエストを確認

Dataを使うと、「ページに問題がある」という状態を、個々のリクエストや通信量の変化に分けて確認できます。アプリが処理したネットワーク活動の確認に役立ちますが、サービスの失敗原因をすべて自動で説明するものではありません。記録を読む際は、接続先、適用ポリシー、接続状態、通信統計を区別してください。ビューによって表示される項目が異なる場合があります。アプリに表示される内容を確認してください。大量の記録を目的なく見るより、確認したい問題を1つ決めてDataを開くほうが効率的です。

1つの操作から関連するリクエストを探す

確認を始める前に、不要なバックグラウンド通信を止めるか大容量の処理を一時停止し、現在時刻を記録します。その後、対象のアプリで特定のページを開くなど、明確な操作を1つ行ってください。次に、その時刻の前後に追加されたリクエストを確認します。複数のアプリを同時に更新しながら、どの記録が問題に関係するか判断しないでください。1つの操作でも複数ドメインへのリクエストが発生することがあり、バックグラウンドの活動が加わると、特定が難しくなります。

記録が多い場合は、接続先ドメイン、発生時刻、アプリのフィルタ機能を使って範囲を絞ります。まず問題に直接関係するリクエストを探し、その前後の通信も確認してください。ウェブページのアドレス欄に表示されるドメインは入口にすぎず、画像、スクリプト、ログイン、APIが別の接続先を使う場合があります。ページ本体が開いても特定の機能が失敗する場合は、ページを最初に開いた記録だけでなく、その機能を操作した後に追加されたリクエストを確認します。

ルールの適用結果と通信経路を分けて確認する

表示された記録で、接続先にPROXY、DIRECT、REJECTのどれが適用されたかを確認し、自分のルールの想定と照らし合わせます。REJECTになっている場合は、範囲の広すぎるキーワードや既存ルールが原因でないか確認します。DIRECTになっていてプロキシ経由を想定していた場合は、現在のモードと有効なファイルを確認してください。拒否ルールをすべて削除するのではなく、まず範囲の明確な例外で確認してから、元のルールのマッチ範囲を調整するか決めます。

同じページで複数のポリシーが適用されることは、ルールによる振り分けでは正常に起こり得ます。一部のリソースが直接接続され、別のリソースがプロキシ経由でも、直ちに設定の競合とは限りません。重要なのは、意図した選択になっているか、必要な機能が正常に動作するかです。反対に、すべてのリクエストが同じ経路を使っても、ルールが機能していないとは限りません。現在のモード、ルールの範囲、フォールバックの設定によって同じ選択になる場合があります。

アップロードまたはダウンロードのバイト数が表示されても、その範囲でデータ交換が発生したことを示すだけで、サービスが正常に使えたとは限りません。認証失敗のページ、再試行、エラー応答でも通信量は発生します。ログイン、ファイル転送、メディア再生が完了したかを判断するには、サービス画面の結果と関連リクエストを合わせて確認してください。記録上の接続終了は、正常な短時間の通信を示す場合もあります。終了表示だけで障害と判断しないでください。

統計の対象範囲と課金の基準を理解する

Dataの累計値、個別セッションの数値、サービス事業者のアカウントに表示される通信量は、集計基準が異なる場合があります。直接接続の通信が特定のビューに含まれるか、統計の開始時点、プロトコルのオーバーヘッドを含むかは、各ビューの定義に従って確認してください。クライアントに表示される合計をサブスクリプションの残量とみなしたり、1つの累計値からリモートの請求が誤っていると判断したりしないでください。

特定の操作による通信量の変化を調べる場合は、開始値、終了値、テスト時間を記録し、ほかのネットワーク活動をできるだけ減らします。履歴を消去またはリセットする機能を使う前に、何に影響するか確認してください。履歴を削除しても、サーバー認証の問題は直らず、ルールの適用結果も変わらず、リモートの利用可能量も回復しません。変わるのは主にローカルの記録です。問題を調べている間は、役立つサンプルを残してください。

記録を、確認可能な設定変更につなげる

ページ内の画像が読み込めず、ページ本体は正常な場合は、まず画像の接続先を特定し、拒否されたか、別のポリシーが適用されたか確認します。次に、設定ファイルのコピーで、その接続先の処理方法だけを変更し、同じ操作を再度行います。改善した場合は、経路の変更が結果に関係したと考えられます。その後、ルールの範囲が広すぎないか、ほかの接続先に影響しないか確認してください。一時的なテスト設定をそのまま最終設定にしないでください。

記録上は想定どおりのプロキシ経路を通っているのにサービスが失敗する場合は、サーバーへの接続、TLS、接続先からの応答を確認します。すでに正しいルールを何度も変更しないでください。該当するリクエストが見つからない場合は、観察した時刻、フィルタ条件、現在の接続状態を確認します。アプリのキャッシュによって、新しいリクエストが発生していないこともあります。クライアントがそのアプリの通信を処理していないと決めつけず、新しい操作を行ってください。

診断情報をエクスポートまたは共有する前に、サブスクリプションURLのアクセス情報、サーバー認証情報、鍵、不要な個人用接続先を削除してください。役立つ報告には通常、短い時間範囲、明確な接続先、想定したポリシー、実際のエラーがあれば十分です。履歴全体を共有する必要はありません。必要な背景を残しながら機密情報を減らすことで、調査に集中でき、復旧後の結果とも比較しやすくなります。

7. Settings、DNS、On Demand

Settingsの項目は、具体的な目的に合わせて調整してください。自動接続、名前解決、テスト、記録の保持など、何を解決したいか明確にしてから対応する項目を変更します。設定を増やせば接続が安定するとは限りません。自動処理や設定の上書きを重ねると、かえって原因の判断が難しくなります。変更前に現在の正常な状態を記録し、Config由来の値、アプリ設定の値、現在のセッションだけに適用される選択を区別してください。

On Demandの条件と手動スイッチ

On Demandは、設定した条件に応じて接続または切断を行う機能です。サーバーを提供したり、無効な認証情報を修復したりするものではありません。条件にはWi-Fi、モバイルネットワーク、ドメインなどが関係する場合があります。選択できる項目は現在の画面で確認してください。設定前に、手動接続が安定して動作することを確認します。そうしないと、自動化によって同じ失敗が繰り返され、バッテリー消費や記録上のノイズが増えるだけで、根本的な接続問題は解決しません。

Wi-Fiの条件を設定する際は、ネットワーク名と実行する動作が意図どおりか確認します。特に、同じ名前のネットワーク、ネットワークの切り替え、一時的な切断に注意してください。モバイルネットワークの条件では、Wi-Fiから切り替わったときの動作を検討します。ドメイン条件は接続を開始するための条件です。Configでリクエストの経路を決めるルールとは異なります。前者はいつ接続するかを決め、後者は接続後に通信をどう処理するかを決めます。

設定後は、条件に合う場合と合わない場合の両方をテストし、手動で切断した後の動作も確認します。切断後すぐに再接続する場合は、スイッチの故障と考える前に、On Demandが再接続を開始していないか確認してください。テストでは、まず理解しやすい条件を1組だけ設定します。結果を確認してから複雑な条件を追加してください。条件について詳しくはOn Demandの接続条件に関するメモをご覧ください。

DNSと設定の適用範囲

DNSはドメイン名をIPアドレスに変換しますが、名前解決が成功しても接続先に到達できるとは限りません。接続先に到達できても、サービスの認証が成功するとは限りません。ドメインへのアクセスに問題がある場合は、まず名前解決の段階と、その後の接続段階を区別します。アクセスの問題をすべてDNSのせいにしないでください。また、元の値を記録せずに複数のDNS設定を次々と変更しないでください。同じ接続先でもキャッシュ、アドレス、経路が同時に変わり、比較が難しくなります。

設定例のdns-server = systemは、該当するシステムの名前解決設定を使うことを示します。実際の方法は、既存の設定、ネットワーク環境、信頼できる範囲を考慮して決めてください。アプリの設定とConfigファイルの両方に関連項目がある場合は、どちらが有効か確認する必要があります。どこかに値が表示されているだけで、すべてのリクエストにその値が使われるとは限りません。変更後は状態が安定するまで待ち、新しいリクエストで確認してください。

DNSによる名前解決とルーティングの判定は、互いに関係する場合があります。たとえば、アドレスルールにはIPアドレスの情報が必要ですが、ドメインルールはドメイン名を直接判定できます。ネットワークによって名前解決の結果が変わると、最終的な経路も変わる可能性があります。問題を調べる際は、サーバー、設定、接続先を同じに保ち、名前解決の設定を1つずつ比較してください。アドレスルールの追加と名前解決方式の変更を同時に行うと、それぞれの影響を区別できません。

接続テスト、ログ、セキュリティ上の境界

Connectivity Testの接続先や方法を変更できる場合は、変更前後の値を記録してください。方法が異なれば、所要時間を直接比較できません。実際の用途に関係のない接続先を、数値を小さくするために選ばないでください。日常のテストは、既存の項目をさらに確認する必要があるか判断するために使い、最終的には実際のサービスの動作で評価します。テストの頻度が高いほどネットワークリクエストが増えるため、わずかな変動を毎回問題として扱う必要はありません。

ログ関連の設定は、明確な目的がある調査に使います。詳細な記録が必要な場合は適切なレベルを有効にし、問題を再現して必要な箇所を保存したら、日常の設定に戻します。大量のログを長期間保存すると、管理の手間が増え、個人のネットワーク情報も蓄積されます。共有前に機密情報を伏せ、サーバー認証情報、サブスクリプションのアクセス情報、不要な閲覧履歴が含まれていないか確認してください。

TLS検証、証明書、書き換え、その他の高度な処理に関する項目は、説明を個別に確認してください。通常の接続では、検証条件を安易に緩めて利用可能な状態を保とうとしないでください。検証の範囲を変えないと接続できない場合は、サーバー情報、証明書名、時刻の設定を再確認します。用途が分からない項目は、別の設定をまねて次々と有効にするより、現在の動作が確認できている値のままにするほうが管理しやすくなります。

設定の確認では、初回接続、手動での切断、ネットワークの切り替え、デバイスを再び使うときの状態をテストします。特にOn Demandは、現在のWi-Fiで一度テストしただけでは完了とみなせません。動作が安定したら、用途が分かる簡潔な設定記録を保存してください。数値だけでなく目的を記載しておくと、次回の調査で、その項目がなぜ設定されているのか、現在の環境にまだ適しているかを判断できます。

8. 設定のバックアップ、更新、日常のメンテナンス

メンテナンスの目的は、正常に動作する基準状態を保ち、変更のたびに記録を残すことです。クライアントのアップデート、サブスクリプションの更新、ルールの変更、ネットワークの切り替え、アカウントの復元はそれぞれ別の操作です。できるだけ個別に行ってください。複数の変更を一度に行うと、問題が起きたときに原因を特定しにくくなります。日常的にすべての設定をリセットする必要はありません。まず情報を保存し、範囲を絞って小さく検証するほうが、復旧しやすく問題も理解しやすくなります。

元に戻せる基準状態を作る

接続が正常なときに、現在選択中のサーバーの備考、Global Routing、Configファイル名、重要な設定、直近の確認方法を記録します。ローカルで変更した設定はコピーを保存し、用途が分かる名前を付けてください。バックアップではファイルをコピーするだけでなく、復元時にどの内容を有効にすればよいか分かる状態にしておくことも重要です。認証情報を含むデータは管理された場所に保存し、比較しやすくするために公開メモへ貼り付けないでください。

設定ファイルのバックアップ、サブスクリプションURL、サーバー認証情報は、別々の情報として扱ってください。Configファイルを復元しても、ルールだけが戻り、すべてのサーバーが復元されるとは限りません。サブスクリプションURLを保存しても、取得先の内容が常に同じとは限りません。アプリのエクスポートや同期機能を使う場合は、何が含まれるか確認してから2台目のデバイスで動作を確かめてください。エラーが表示されずに読み込めたからといって、元のデバイスの状態がすべて移行されたとは限りません。

サブスクリプションとルールを分けて更新する

サブスクリプションを更新する前に、現在使っている項目と必要なローカル変更を記録します。更新後は、項目が削除、置換、改名されていないか確認してから短いテストを行ってください。サブスクリプションの内容が変わった場合は、古い項目を無理に戻すのではなく、新しい情報を確認します。長期的に手動で維持する内容は、管理方法を明確にし、更新のたびに気付かないまま上書きされないようにしてください。

ルールファイルを更新する場合は、マッチ範囲、ルールの順序、フォールバックのポリシー、新たに追加された高度な処理を確認します。名前に見覚えがあるというだけで、外部から入手した設定をすぐに有効にしないでください。まず自分の用途に関係する部分を読んでください。特に最終ポリシー、拒否ルール、DNS、証明書関連の内容は動作に大きく影響する場合があります。元のファイルを残し、コピーで検証してから置き換えるか決めると、問題が起きたときにすぐ戻せます。

更新後に特定の接続先だけが失敗する場合は、対応するルールと記録を比較します。サーバー設定全体をすぐに元に戻さないでください。反対に、複数の接続先で認証段階の失敗が起きている場合は、ウェブサイトごとに例外を追加するのではなく、サーバー情報を優先して確認します。問題を情報、経路、ルール、サービスの応答に分類しておくと、同じ設定に一時的な修正を積み重ねずに済みます。

機種変更、再インストール、iPadへの移行

デバイスを変更する場合は、まず購入時のアカウントでApp Storeからアプリを再入手し、ご自身の情報を復元します。システム要件と購入の適用範囲は、App Storeの表示をご確認ください。初回起動時には、VPN構成の許可、現在のサーバー、有効なファイルを確認します。購入済みアプリを復元できたからといって、接続確認を省略しないでください。システムのバックアップで一部の状態が保たれる場合がありますが、新しいデバイスの表示とテスト結果に基づいて確認してください。

iPhoneからiPadに移行すると、横向き表示、画面分割、広いレイアウトによって操作場所が変わる場合があります。Home、Config、Data、Settingsなどの項目名を目印にしてください。まず既存のサーバーを1つテストし、その後でルールとオンデマンド条件を順に復元します。2台のデバイスではネットワークや使い方が異なる場合があります。画面の見た目をそろえるために、すべての設定を同じにする必要はありません。詳しくはiPadでの購入済みアプリの復元と画面構成をご覧ください。

問題の記録を残し、連続したリセットを避ける

接続に突然問題が起きた場合は、最後に正常に使えた時点から最初に失敗した時点までに何があったか記録します。サブスクリプションの更新、ネットワークの切り替え、ルールの変更、システム設定の変更がなかったか確認してください。現在のエラー表示と直近のリクエストを残し、既知の基準状態に戻すことを試します。すべての情報をリセットすると、手がかりと正常な設定の両方が失われます。バックアップから復元できると確認でき、より小さい範囲での調査でも解決しない場合に限り、大規模な整理を検討してください。

長期間使っていない項目は、不要であることを確認してから削除できます。ただし、手動の項目とサブスクリプションで管理される項目を区別してください。そうしないと、次回更新時に同じ名前の項目が再び現れることがあります。ルールも定期的に見直し、重複、広すぎるマッチ、不要になった例外がないか確認します。整理は種類ごとに行い、完了後は普段使う接続先をテストしてください。削除件数ではなく、動作が明確になり、復元しやすくなったかを基準にします。

他の人に問題を伝える際は、デバイスの種類、ネットワーク、操作手順、Global Routing、接続先、エラーの種類を示し、サーバー、サブスクリプション、ログの機密情報を伏せてください。項目の意味は用語集で確認できます。初回接続を最初からやり直す場合はクイックガイドをご覧ください。初心者がつまずきやすい操作については初心者向けよくある質問10選をご覧ください。

メンテナンス後は、決まった短いテストを使って、普段使うページ、必要なローカルアクセス、ネットワーク切り替え時の動作を確認し、基準状態の記録を更新します。今後違いが生じた場合は、すべての設定を最初から推測するのではなく、この記録と比較してください。各章は個別に参照できますが、入手、権限、情報、ルーティング、確認、観察の順に進めることをおすすめします。各段階で確認する内容と結果が明確になります。