Shadowrocketのトラブル対処
接続・サブスクリプション・ルール

スイッチがオンにならない：VPNの許可とシステム制限を確認

スイッチがすぐオフに戻る、接続中のまま進まない、アプリが突然終了するのは、それぞれ異なる症状です。まず、問題が発生したタイミングを記録してください。システムの許可画面が出る前か、VPN構成の追加を許可した直後か、特定のサーバーを選んだ後かを確認します。この時点でサブスクリプションをすべて削除したり、接続ボタンを連打したりしないでください。接続をオフにしてシステムの状態が落ち着くまで待ち、通常のブラウザーで、現在のネットワークから普段アクセスできるページを開けるか確認します。基本のネットワークが復旧するまでは、サーバーテストやルール変更を比較しても判断材料になりません。

VPNの許可が完了しているか確認

初回接続時、システムからVPN構成の追加を求められ、端末のパスコードやシステム認証による確認が必要になることがあります。確認画面をキャンセルすると許可は完了しません。アプリ内スイッチが一瞬切り替わっても、システムでの確認の代わりにはなりません。Homeに戻り、もう一度接続を開始して、表示される画面を最後まで確認してください。その後、システムのSettingsでVPNを開き、該当する構成があるか確認します。設定画面の項目名や階層はシステムのバージョンによって異なるため、設定内検索も利用してください。構成があるのに有効にならない場合は、いったん切断します。該当するVPN構成だけを削除して再度許可することを検討し、アプリ内のサーバー情報とConfigは残してください。

端末が会社や学校の管理下にある場合、管理ポリシーによってVPNの追加、ネットワーク拡張機能、バックグラウンド接続が制限されていることがあります。この場合は管理者に確認が必要です。サブスクリプションを再インポートしても、システムのポリシーは変更できません。用途がわからない管理プロファイルは削除しないでください。同じ端末で別のVPN接続や、ローカルVPNを使うネットワークフィルター機能を利用している場合は、まず一方を一時停止してからShadowrocketを単独で起動します。複数のネットワークツールを同時に変更すると、原因を特定しにくくなります。

自動再接続と設定ミスを確認

On Demandが有効だと、手動で切断した後に再接続したり、ネットワークの変化に応じて接続を再試行したりすることがあります。手動接続の一連の動作を確認するため、いったんOn Demandをオフにし、元の条件を記録しておきます。テスト後は設定を戻してください。特定のサーバー情報を選んだときだけスイッチがオフに戻る場合は、Add Serverでアドレス、ポート、プロトコルの必須項目が不足していないか確認します。サブスクリプション名が表示されていても、すべての項目が正しく登録されているとは限りません。インポート時に認識されなかった項目は、利用者が持つ元の情報と一つずつ照合してください。

アプリは正常に起動するのにシステムの許可結果が表示されない場合は、接続をオフにしてアプリを終了し、もう一度起動してください。それでも変化がなければ端末を再起動します。再起動は一時的な拡張機能の状態をリセットするためのもので、設定が正しいことを証明するものではありません。再起動後は、元のサーバー情報だけをテストし、サブスクリプション更新やルール変更を同時に行わないでください。復旧した場合は、次の画面ロックやネットワーク切り替えで再発するか確認します。問題が続く場合は、ストレージ容量、システム制限、現在の設定を確認し、何度も再インストールするのは避けてください。

インストールのブロックと接続の不具合を切り分ける

アプリ自体を起動できない場合は、ネットワークの確認に進む前にインストールの問題を解決してください。ShadowrocketはiPhone、iPad、Mac、Windows、Android、Linuxに対応しています。iPhone / iPad版はApp Storeで$2.99の買い切りです。Mac（Appleシリコン・Intel）、Windows、Android、Linux版は無料です。iPhone / iPadのシステム要件はApp Storeの製品ページを確認してください。その他のプラットフォームのインストーラーは当サイトのダウンロードページから入手でき、ファイルは当サイトの/dl/から提供されます。

デスクトップ版とAndroid版のインストーラーにはコード署名がないため、初回起動時にシステムでブロックされることがあります。ファイルが当サイトから入手したものと確認できたら、WindowsではSmartScreenの「詳細情報」から「実行」を選択します。Macでは「プライバシーとセキュリティ」で今回の起動を許可します。Androidでは、システムの案内に従い、使用するブラウザーまたはファイル管理アプリに不明なアプリのインストールを許可してください。Linuxではファイルのアクセス権とパッケージ形式も確認します。詳しい手順はインストール時のブロック解除方法を参照してください。インストールの問題をルール変更で解決しようとしないでください。

接続後にインターネットを利用できない：トンネル、サーバー、ルーティングを切り分ける

接続表示が正常なのにページを開けない場合は、すべてのリクエストが失敗するのか、一部のドメインだけなのかを確認します。まずShadowrocketをオフにし、普段直接アクセスできるページを開いてください。それでもアクセスできない場合は、ルーター、モバイルデータ、Wi-Fiの認証、システムのプロキシ設定を優先して確認します。ホテルやゲストネットワークでは、ブラウザーでネットワーク認証を済ませる必要があることがあります。先にトンネルを確立すると、認証ページが表示されない場合があります。認証を完了してから接続し、ネットワークへのアクセスが許可されていない状態をサーバーの障害と誤認しないようにしてください。

Global Routingで短時間の比較を行う

基本ネットワークが正常な状態で、利用者が持つ情報がそろったサーバーを一つ選び、同じ接続先、同じネットワークで比較します。Global RoutingのConfig、Proxy、Directは、それぞれ設定に従う経路、プロキシ経由、直接接続に対応します。切り替えは原因の範囲を絞るために行うもので、恒久的な解決策ではありません。切り替え後は毎回リクエストを新しく送信してください。以前のページが既存の接続やキャッシュを使うことがあるため、画面に以前の内容が表示されているかだけでは判断できません。

Directでは通常のページを開けるのにProxyでは同じページが失敗する場合は、サーバーのパラメーターとサーバーから接続先までの経路を確認します。Proxyでは正常でConfigだけ失敗する場合は、有効なConfig、ルールの順序、ポリシー名を確認してください。3つすべて失敗しても、すぐにルールの問題と決めつけず、基本ネットワーク、DNS、システムの接続状態を確認します。サイトによってネットワーク経路ごとにアクセス条件が異なるため、用途の異なるテスト先を少なくとも2つ選び、一つのサイトだけで全トラフィックの状態を判断しないでください。

選択した項目と実際に適用された項目が一致するか確認

Homeで選択したサーバーが、Config内の各ポリシーで最終的に使われるサーバーとは限りません。設定からポリシーグループを参照したり、一部のリクエストをDIRECTやREJECTに振り分けたりできます。リクエスト記録を開き、テストしたドメインを探して、適用されたルールと最終ポリシーを確認してください。新しい記録がまったくない場合は、リクエストを再送信したか、システムが現在のトンネルに接続しているか、テストに使ったアプリが実際にネットワークへアクセスしたかを確認します。記録はあるのにポリシーが違う場合は、サーバーを次々に変更するのではなく、まずルールを修正してください。

Configを確認するときは、まず使用中のファイルを特定し、コピーを編集してください。ルールは通常上から順に照合されるため、具体的なドメインのルールは広範囲のルールより前に置き、FINALは最後の振り分けに使います。以下はルールの順序を示す例です。example.comは例示用ドメインであり、PROXYは実際の設定で有効なポリシーとして解決できる必要があります。このルールだけで既存の設定ファイルを置き換えないでください。また、意味を理解していない広範囲の許可ルールをテスト目的で追加しないでください。

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

エラーが発生した段階に応じて次の確認先を決める

ページにドメイン解決エラーが表示された場合はDNSの項目を確認します。長時間待って接続がタイムアウトする場合は、サーバーのタイムアウトの項目を確認してください。接続確立後に証明書の警告が表示される場合は、システム時刻、接続先のドメイン、サーバー側のTLSパラメーターを確認します。エラーを隠すために証明書検証を無効にしないでください。特定のアプリだけが失敗する場合は、そのアプリのネットワーク権限やログイン状態、サービス自体の稼働状況を確認してから、ブラウザーで同種の接続先と比較します。

復旧したらGlobal Routingを元のモードに戻し、直接接続されるべきリクエストとプロキシ経由になるべきリクエストを一つずつ再確認します。正常だった結果に対応するネットワーク、サーバー、設定名を記録してください。Proxyでしか一時的に使えない場合も、「Proxyは正常、Configは異常」という結果を残して、ルーティングの問題を引き続き調べます。すべてのリクエスト経路を変更するとエラーを回避できることはありますが、原因は解消されません。ルールの適用方法についてはカスタムルールとFINALを参照してください。

サーバーのタイムアウト：アドレス、ポート、ハンドシェイクを確認

タイムアウトは、ある段階の処理が制限時間内に完了しなかったことを示します。サーバーが必ずオフラインとは限りません。Connectivity Testの結果は、テスト方法、接続先、実行時のネットワーク状態によって異なります。特定のテストに成功しても、そのテスト経路が成功したことを示すだけです。実際のWebページではDNS、プロトコル認証、TLS、接続先サイトの応答も関係します。「サーバーにまったく接続できない」と「接続はできるがページが開かない」を分けて記録し、一つの数値だけでアプリ全体の利用可否を判断しないでください。

アドレスとポートが元のままか確認

Add Serverでサーバーアドレス、ポート、プロトコルを確認します。アドレス欄には通常、サーバーのホスト名またはアドレスだけを入力し、Webページのパスや説明文を一緒に貼り付けないでください。ポートは利用者が持つ元の情報と照合し、プロトコル名から推測しないようにします。コピー時に空白、改行、全角記号が混入していないかも確認します。元のアドレスがドメイン名の場合は名前解決できるか、IPv6アドレスの場合は現在のネットワークから到達できるかを確認してください。他のWebページにアクセスできるだけでは、そのアドレスにも到達できるとは限りません。

同じサーバー情報がWi-Fiでは失敗し、モバイルネットワークでは正常な場合、接続ネットワークまたは経路が関係しています。Wi-Fiの認証、ルーターのルール、上流ネットワークへの接続を確認してください。両方のネットワークで失敗しても、利用者が持つ別のサーバー情報では正常なら、元のサーバーとそのパラメーターを優先して確認します。すべてのサーバー情報が突然同時に失敗した場合は、パスワードを一つずつ変更するのではなく、基本ネットワークと共通して使うDNSを確認してください。テストでは毎回、ネットワークかサーバーのどちらか一方だけを変更し、結果を判断しやすくします。

プロトコルのパラメーターは同じ資料から確認

異なるプロトコルの項目を混在させないでください。Shadowsocksでは暗号化方式とパスワード、VMessとVLESSではユーザーIDとトランスポートの設定、TrojanではパスワードとTLS関連の設定を確認します。ユーザーIDやパスワードは一文字違うだけでも認証に失敗することがあります。リンクをインポートした後も、特にエスケープ文字や追加のトランスポートパラメーターを含む場合は、重要な項目が正しく認識されているか確認してください。別のサーバー情報から項目を寄せ集めて、新しい情報を作らないでください。

TLSのServer Nameと接続先アドレスは異なる場合があります。HostとPathもそれぞれ別の役割を持つことがあるため、名前が似ているからといってすべて同じドメインを入力しないでください。システムの日付と時刻も確認します。時刻がずれていると、有効な証明書がまだ有効でない、または期限切れと判定されることがあります。証明書エラーが発生したら、エラーの種類を記録して資料と照合し、不一致の証明書を安易に受け入れないでください。プロトコル設定の正しさと証明書の信頼性は別々の条件です。一方を回避しても、もう一方が正しいことの証明にはなりません。

UDPとネットワーク経路の違いを確認

一部のプロトコルや機能はUDPに依存します。Hysteria2の接続状況は、現在のネットワークでUDPが使えるかどうかに影響されることがあります。WireGuardでは、鍵、アドレス、エンドポイント、ルーティング範囲も正しく設定する必要があります。他のサーバー情報でWebページを開けても、UDP経路が正常とは限りません。特定のプロトコルだけが失敗する場合は、すべてのサーバーを変更するのではなく、そのプロトコルの必須パラメーターとネットワーク条件を確認してください。再現性があり、他の要因を除外できている場合を除き、MTUなどの低レベル設定を安易に変更しないでください。

元のパラメーターに誤りがないのにタイムアウトが続く場合は、利用者が契約しているサービスの管理者に、テスト時刻、接続ネットワーク、失敗した段階、個人情報を伏せたエラー文を伝えてください。サブスクリプションの完全なURL、パスワード、鍵は送信しないでください。以前は接続できていたのに使えなくなった場合は、サーバーアドレス、ポート、認証情報が変更されていないか確認します。管理者の確認後にサーバー情報を更新し、古いパラメーターでの試行を繰り返さないでください。最後に実際のリクエストで復旧を確認し、次回も再現できるテスト手順を記録して、一時的な混雑と継続的な障害を区別できるようにします。

サブスクリプションの更新失敗・一覧が空：取得と解析を分けて確認

サブスクリプションの更新には、サーバーから内容を取得する段階と、その内容をサーバー情報として解析する段階があります。どちらの段階でもエラーが起こり得ます。更新が成功しても一覧が空なら、ネットワークに接続できないとは限りません。既存のサーバー情報を残し、サブスクリプショングループ名、更新前後の項目数、エラーメッセージを記録してください。アプリの買い切り購入は回線プランの購入ではありません。アプリをインストールまたは購入しても、サーバー情報が自動で作成されることはありません。当サイトはサーバー情報やサブスクリプションの提供、販売、推奨を行っていません。この記事では、利用者がすでに持っている情報の確認方法のみを説明します。

コピーした内容がサブスクリプションURLか確認

利用者が契約しているサービスからサブスクリプションURLを再取得し、ログインページ、管理ページ、途中で切れた表示テキストではなく、完全なURLをコピーしたか確認します。URLにクエリパラメーターが含まれている場合、末尾を削除したり特殊文字を全角文字に変えたりすると、意味が変わることがあります。貼り付け後に前後の空白や改行を確認しますが、パラメーターの順序を変えたり内容をデコードしたりしないでください。単一の共有リンクが提供されている場合は、単一のサーバー情報としてインポートし、定期更新が必要なサブスクリプションと混同しないでください。

実際のサブスクリプションURLを検索欄、公開掲示板、オンライン解析サイトに貼り付けないでください。URLに、そのまま使える認証情報が含まれている場合があります。エラーを記録する場合は、プロトコルの種類、匿名化したドメイン、エラーの種類だけを残します。スクリーンショットを共有する前に、QRコード、完全なURL、ユーザー名、サーバーを特定できるメモを隠してください。QRコードとテキストのリンクには同じ権限情報が含まれることがあるため、片方だけ隠しても保護にはなりません。

ネットワークリクエストで内容を取得できたか確認

更新がタイムアウトする場合は、まず現在のネットワークからサブスクリプションのドメインを名前解決できるか確認し、次に取得時に使われる経路を調べます。既存のサーバーが使えず、サブスクリプションの更新にも現在のプロキシ経路が必要な場合、更新できない状態が循環している可能性があります。基本ネットワークが利用可能で、サービスの接続先が許可している場合は、切断後の更新結果を比較してください。利用者が持つ別の利用可能なサーバー情報を使って比較する方法もあります。サブスクリプションは必ずプロキシ経由、または必ず直接接続で取得するとは限りません。実際の経路は接続先への到達性で判断してください。

エラーメッセージにステータスコードが含まれる場合は、意味を切り分けます。認証やアクセス拒否を示す応答では、URLの権限を確認します。リクエスト過多の場合は連続更新をやめてください。サーバー側のエラーは、利用者が契約しているサービスの管理者による対応を待ちます。成功ステータスが返っても、取得した内容がログインページ、認証ページ、一般的な説明ページで、サブスクリプションデータではないことがあります。したがって、ブラウザーでページが表示されても内容が正しい証明にはなりません。ページのテキスト全体をサーバーアドレス欄にコピーしないでください。

一覧が空の場合は解析と表示条件を確認

内容を取得できたのに項目がない場合は、まずHomeの検索条件をクリアして該当するグループを展開し、絞り込みや折りたたみで一覧が空に見えていないか確認します。次に、形式が未対応、項目が不足、内容を認識できないといったエラーがないか確認してください。サブスクリプション形式ごとに含まれる項目は異なります。URLの拡張子を変えるだけで形式を変換することはできません。形式の変更が必要な場合は、利用者が契約しているサービスの互換形式に関する説明を確認し、非公開のURLを不明なツールに渡さないでください。

更新後に一部のサーバー情報だけ減った場合は、消えた項目のプロトコルやパラメーターを比較し、サービス側で削除されたのか、名前が変更されたのか、個別の解析に失敗したのかを確認します。表示名だけで同じサーバーと判断しないでください。名前は重複したり変更されたりすることがあります。サブスクリプション更新で手動編集した項目が上書きされる場合は、サブスクリプションの項目を繰り返し編集せず、診断用に管理できるローカルコピーを保存してください。ローカルコピーには以降の変更が自動で反映されない点にも注意します。保存方法は現在の画面にある機能に従ってください。

復旧後、元の問題が解決したか確認

サブスクリプションが再び表示されても、確認できたのは取得と解析が完了したことだけです。サーバー情報を一つ選んで実際に接続してください。まずグループ内の項目を確認し、次に重要なパラメーターを照合し、最後にテスト先へアクセスします。Configとすべてのサブスクリプションを同時に更新すると、どの操作で復旧したか判断できません。新しいURLでは更新できるのに古いURLではできない場合は、復旧を確認してから古いURLを無効にし、以前のサービス管理者に古い認証情報が失効しているか確認してください。失敗の詳細はサブスクリプション更新失敗・一覧が空のときの確認方法を、リンクの種類は共有リンクとサブスクリプションリンクの違いを参照してください。

速度が遅い・接続が途切れる：比較できるテスト条件を整える

低レイテンシでも転送速度が速いとは限らず、転送速度が十分でも操作への応答が遅いことがあります。Webページの表示には名前解決、接続の確立、最初のデータが届くまでの時間が関係します。大きなファイルのダウンロードでは、継続的な帯域、パケットロス、サーバー負荷の影響が大きくなります。まず、遅いのがどの部分かを説明してください。読み込み開始まで時間がかかる、転送中ずっと遅い、再生中に止まる、画面ロック後だけ切断される、といった違いがあります。症状を特定してからテストし、異なる問題をすべて「速度が遅い」とまとめて、プロトコル、DNS、ルールを同時に変更しないでください。

接続先、ネットワーク、時間帯を固定する

適法な中程度のサイズのテスト用ファイルを選び、同じネットワーク、同じ端末、近い時間帯で比較します。システムアップデート、クラウド同期、その他の大容量通信を一時停止し、端末が明らかに発熱していないことを確認してください。一度に変更するのは利用者が持つサーバー情報一つ、またはGlobal Routingの切り替え一回だけにし、他の条件は変えないでください。速度テストはデータ通信量を消費するため、モバイルデータでは回数を抑えます。大容量のテストを続けると、それ自体が混雑や発熱を引き起こし、後の結果を悪化させることがあります。

Directで通常のページも遅い場合は、Wi-Fiの電波状態、ルーターの負荷、上流ネットワークを確認します。ルーターに近づいて改善するなら、まずローカルのWi-Fi環境を調べてください。別のネットワークで改善する場合は、元のネットワーク経路を確認します。同じサーバーが異なるネットワークでも遅く、利用者が持つ他のサーバー情報では正常なら、そのサーバーまたは外部への経路に制限がある可能性があります。ローカルのルール変更で経路選択は変えられますが、遠隔側で実際に利用できる帯域は増やせません。

初回リクエストの遅さと継続的な転送の遅さを区別

初回のアクセスが遅く、再アクセスで明らかに速くなる場合、DNSキャッシュ、接続の再利用、接続先のコンテンツキャッシュが関係している可能性があります。この現象だけでサーバーが不安定とは判断できません。リクエスト記録でドメイン、適用されたポリシー、エラーの段階を確認します。リクエストが遠回りの経路に誤って振り分けられているなら、ルールを修正してから再テストしてください。想定どおりのポリシーが適用されている場合は、名前解決、接続、接続先の応答を比較します。記録から判断できる情報が限られる場合は、推測した時間を記入せず「判断材料不足」と記録してください。

ダウンロード中に周期的な停止が起こる場合は、パケットロス、ネットワーク切り替え、Wi-Fi干渉、サーバー側の速度制限、アプリ独自のバッファリングが関係していることがあります。端末を動かさずネットワークも切り替えない状態で再現し、利用者が持つ別のサーバー情報と比較します。特定の接続先だけ遅い場合は、接続先サイトやコンテンツ配信経路の問題かもしれません。一つの動画やダウンロードサイトだけで全体のアクセス状況を判断せず、一度のテスト結果を追うために長期設定を何度も変更しないでください。

接続が途切れたときは状態と発生時刻を記録

接続が途切れたら、まずシステムのVPN状態が変わったかを確認し、次にShadowrocketの接続表示を確認します。アプリに接続表示が残ったまま新しいリクエストが失敗する場合と、システムのトンネル自体が切断された場合では、確認する項目が異なります。前者ではサーバー、DNS、既存接続を確認します。後者ではネットワーク切り替え、On Demand、システム制限、アプリの異常を確認してください。画面ロック、Wi-Fiからモバイルネットワークへの切り替え、テザリングの開始、低電力モードの使用に続いて切断したかを記録します。発生時刻との関係は、一度の速度テストより有用なことがあります。

ネットワーク切り替え後に自動で復旧しない接続もあり、アプリによる再接続が必要になることがあります。まず小さなリクエストを新たに送信して接続できるか確認し、その後で切断・再接続を行うか決めてください。以前のダウンロードだけが停止し、新しいページは開けるなら、古いセッションが無効になった可能性があり、トンネル全体が使えないとは限りません。強制再接続は正常な他のセッションも中断するため、影響範囲を見極めてから操作してください。

Dataの統計は参考にとどめ、診断結果と決めつけない

Dataに表示される通信量は、バックグラウンドでの大容量通信を見つける手がかりになります。ただし、集計の単位、期間、リセットしたタイミングによって見方が変わります。サーバーの累積通信量が多くても、現在の速度が速いとは限りません。アプリの通信量が少なくても、接続に失敗していないとは言えません。まず集計方法を確認し、実際のテスト時刻と照らし合わせてください。サーバー別・アプリ別の確認方法はData画面の通信量統計についてを参照してください。統計をリセットする場合は、比較材料を消さないよう、先に現在の数値を保存します。

DNSとルールの適用状況：ドメイン、アドレス、ポリシーを切り分ける

DNSはドメインをアドレスに変換し、ルールはリクエストの経路を決めます。両者は関係しますが、互いに代用できません。ドメインにアクセスできない原因は、名前解決の失敗とは限らず、名前解決が正常でも接続先との通信に失敗することがあります。あるアドレスに接続できても、ドメイン経由のアクセスが正常とは限りません。HTTPSでは正しいドメイン名と証明書が必要になる場合があるためです。問題全体を判断するためにWebサイトのドメインをアドレスに置き換えないでください。また、名前解決エラーが表示されたからといって、見慣れないDNSアドレスをいくつも追加しないでください。

失敗がどの段階で起きたか確認

対象に再アクセスしてリクエスト記録を確認します。ドメインが記録されているか、アドレスを取得できたか、最終的にどのポリシーが使われたか、エラーが名前解決の前後どちらで起きたかを確認してください。無関係な複数のドメインで名前解決に失敗する場合は、現在のDNS設定と接続経路を調べます。一つのドメインだけ失敗する場合は、そのドメイン自体、キャッシュ、対応するルールを確認してください。テスト先には、普段正常にアクセスできる一般的なドメインも含め、アクセス条件に元々差がある接続先だけで判断しないようにします。

暗号化DNSを利用する場合も、対応するサーバーへ接続できる必要があります。状況によっては、そのサーバーのドメインを先に名前解決しなければならないこともあります。DNSリクエストの出口が利用できないプロキシに依存していると、すべてのドメインで同時に失敗することがあります。「名前解決サーバーはどこか」と「そのサーバーまでどの経路を使うか」を分けて記録してください。プロトコル名だけで利用可能と判断せず、一時的な切り分けのためにシステムや設定に必要な保護を恒久的に無効にしないでください。

ルールの順序とポリシーの参照先を確認

ルールは上から順に照合され、先に一致したルールが適用されるのが一般的です。DOMAINは完全一致のドメイン、DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲を対象とし、FINALはそれ以前のルールに一致しないリクエストを処理します。ドメインルールとアドレスルールでは判定基準が異なります。アドレスによる判定では、すでにアドレスを取得できているか、設定で名前解決をどう扱うかも確認してください。切り分けでは、まず明確なドメインを使って小規模にテストし、範囲の広いキーワードルールをいきなり追加しないでください。

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

この例では具体的なルールを広範囲のルールより前に置いています。intranet.example.comは先頭のルールに一致し、後方の同じサフィックスを使うルールには進みません。GEOIPはアドレスの地域情報を使うもので、Webサイトの言語、運営地域、コンテンツの種類を判定するものではありません。データと実際の通信出口が一致しない場合もあります。PROXY、DIRECT、REJECTはポリシーの種類を表します。実際の設定では、プロキシポリシーが利用可能なサーバー情報を正しく参照している必要があります。ルールが正しくても、ポリシーの参照先が使えないサーバーならアクセスに失敗します。

IPv4、IPv6、ローカルネットワークのドメインを個別に確認

ドメインによってはIPv4とIPv6の両方のアドレスが返されますが、現在のネットワークやサーバーで正常に使えるのはどちらか一方だけの場合があります。ネットワークを変えると症状が変わる場合は、アドレスファミリーの違いを確認し、すぐに「DNSの応答が間違っている」と結論づけないでください。ローカルネットワークの機器では、ルーターのローカル名前解決や特定の検索ドメインが必要なこともあります。外部DNSに変更すると、通常のWebサイトは開けてもプリンター、ファイルサービス、内部ドメインにアクセスできなくなる場合があります。これは名前解決の範囲が変わったためであり、すべてのリクエストをプロキシ経由にして解決する問題ではありません。

DNSやルールを変更した後は、接続とリクエストを新たに開始してください。既存の接続やキャッシュが結果に影響することがあります。関連する状態が更新されるまで待ってから同じ接続先をテストし、必要に応じてテストに使うアプリを再起動します。キャッシュの削除は以前の状態を切り分ける方法であり、恒久的な解決策ではありません。復旧したら変更前後の差分を保存し、テスト用に追加した一時的なルールを削除して、ローカルネットワークへのアクセスに影響がないか確認してください。原因を特定できない場合は、「ドメインが開けない」とだけ伝えるより、個人情報を伏せた適用ルール、アドレスファミリー、エラーが起きた段階を共有すると、続きの調査がしやすくなります。

バッテリー消費・アップデート後の不具合：まず安定した状態を基準にする

バッテリー消費が急に増えた場合は、ネットワークの利用状況と観察時間をあわせて判断します。システムがトンネル経由の通信を関連アプリの使用量として計上することがあり、アプリが使用量の上位に表示されるだけでは故障の証拠になりません。近い利用状況での電池残量の変化、画面点灯時間、モバイル信号、端末温度、通信量を比較し、再接続を繰り返していないか確認してください。アップデート後に異常が起きた場合も、まず設定が変わっていないか確認します。時間的に後から起きたことだけで原因と決めつけないでください。元の設定を残しておくと、ネットワーク環境の変化と端末内の状態変化を区別しやすくなります。

電池使用量の順位だけでなく、通信が続いているか確認

ダウンロード、クラウドバックアップ、メディアのアップロード、連続した速度テストを停止し、端末の温度が下がってから通常の使い方でしばらく様子を見ます。モバイル信号が弱い、テザリングを使っている、ネットワークを頻繁に切り替えている場合は、システムの負荷が増えるため、クライアントの動作と分けて考えてください。他の大容量通信を止めて明らかに改善する場合は、通信を発生させているアプリを確認します。何もしていない状態でも発熱が続く場合は、接続の再試行、サブスクリプションの繰り返し更新、同じリクエストの反復がないか調べてください。明確な根拠がないまま、すべてのサーバー情報を削除して「整理」しないでください。

On Demandの条件とネットワークが頻繁に変化すると、接続を繰り返し試すことがあります。元の条件を記録し、自動接続を短時間オフにして手動接続で様子を見ます。改善したら条件を一つずつ戻し、異常との関係を確認してください。接続を永久にオフにするのは解決策ではなく、システムのネットワーク機能をすべて停止しないでください。常時接続が必要な場合は、安定した条件で画面ロック、スリープ解除、ネットワーク切り替えを改めて確認します。画面を表示した短時間のテストだけで調査を終えないでください。

診断による追加負荷を抑える

詳細なログを長時間記録する、大量のサーバーを頻繁にテストする、サブスクリプションを何度も更新するといった操作は、追加の通信や処理を発生させることがあります。必要な診断情報だけを症状の再現中に記録し、原因がわかったら通常の設定に戻してください。ログにはアクセス先のドメインや接続情報が含まれることがあるため、書き出す前に内容を確認して個人情報を伏せます。「テスト開始、症状発生、テスト終了」を含む短い時間帯を記録してください。長すぎる記録は処理の負担になるうえ、本当に必要なエラー情報を見つけにくくします。

端末のストレージ容量が不足すると、システムやアプリのアップデート、キャッシュの書き込み、設定の保存にも影響することがあります。まずシステムのストレージ管理で、削除してよいと確認できたデータを整理してからアプリを再起動します。用途のわからない内部ファイルを手動で削除しないでください。バッテリーのテストでは、充電しながら温度を比較しないようにします。充電そのものが端末の熱状態を変えるためです。各回で画面の明るさ、ネットワーク、アプリの利用状況をそろえると、設定変更に継続的な効果があったか、一時的な変動だったかを判断しやすくなります。

アプリと設定を分けてアップデート前後を比較

アプリのアップデート、サブスクリプションの更新、Configの更新は別の操作です。異常が起きる前に実際に何を行ったか振り返ってください。アプリだけが変わったのか、サーバーのパラメーターやルールも同時に変わったのかを確認します。現在選択しているサーバーと有効なConfigを確認し、Global Routingが意図した設定か調べてください。Proxyは正常でConfigだけ異常なら、Configの差分を優先して確認します。すべてのモードで失敗する場合は、基本ネットワークとサーバーのパラメーターに戻って確認します。アップデートの問題を確かめるために何度もアンインストールしないでください。未バックアップの情報も一緒に失われることがあります。

iPhone / iPad版のアプリはApp Storeからアップデートします。Mac、Windows、Android、Linux版の新しいインストーラーはアプリのダウンロードページから入手してください。再インストール時にシステムでブロックされた場合は、まず当サイトから入手したことを確認し、ダウンロードページの手順に沿ってブロックを解除します。インストール前に、現在のConfig、手動で追加したサーバー情報、必要なメモを保存してください。バックアップには機密情報が含まれるため、自分で管理できる場所に保管し、公開領域にアップロードしないでください。

復旧の手順と再現状況の記録

テスト環境を作り直す必要がある場合は、まずシステムの許可を完了し、利用者が持つパラメーターの明確なサーバー情報を一つだけインポートして実際の接続を確認します。その後、元のConfig、サブスクリプション、On Demandの順に戻してください。各段階で同じ接続先をテストし、どの操作から失敗したかを記録します。こうすることで、アプリの基本接続、サーバー情報、複雑な設定のどこに問題があるかを区別できます。バックアップ全体をインポートした直後に再発し、単一のサーバー情報では正常なら、バックアップ内の設定を確認し、再インストールを繰り返さないでください。

アップデート後の不具合を報告する際は、端末のモデル、システム環境、ネットワークの種類、失敗した手順、個人情報を伏せたエラー文を記載します。アプリ情報は現在の画面で確認し、記憶だけで入力しないでください。「安定して再現できるか」「最小限の設定でも発生するか」は特に重要です。復旧後は検証済みの設定を保存し、次に変更する前にコピーを作成します。日常的に何度もリセットする必要はありません。変更を記録して元に戻せるようにし、元の利用環境で正常に使えることを確認してください。

iPadのチェック項目：設定を同期しても利用環境は同じにならない

同じ設定を使っているのにiPhoneでは正常でiPadでは失敗する場合、別のプロトコルが必要と決めつけず、2台のネットワークとシステム許可を比較してください。同じ名前のWi-Fiに接続していても、異なるゲストネットワーク、アドレスファミリー、管理ポリシーを使っていることがあります。まず2台をできるだけ同じネットワーク条件にし、接続をオフにして基本ネットワークを確認してから、利用者が持つ同じサーバー情報を短時間テストします。比較中はGlobal Routingをそろえ、設定の違いを端末の違いと取り違えないようにしてください。

iPadで初回のシステム許可を完了

別の端末でVPNを許可していても、このiPadでのシステム確認の代わりにはなりません。初回接続時にはiPadでVPN構成の追加を最後まで許可し、システム認証を完了してください。許可画面が表示されない場合は、システムに該当する構成がすでにあるか、端末管理による制限がないか確認します。学校や会社から支給された端末には、専用のネットワークポリシーが適用されていることがあります。サブスクリプションを繰り返しインポートして回避しようとしないでください。管理上の制限がわからない場合は、利用可能な条件を管理者に確認します。

画面が大きく、ウインドウを並べられても、接続がシステムレベルで動作することに変わりはありません。アプリをバックグラウンドに移動したり、表示中のウインドウから外したりしても、VPNが切断されたことにはなりません。逆に、Homeが前面に表示されていても、システムのトンネルが有効とは限りません。システムのVPN状態とアプリ内の接続状態を同時に確認し、リクエストを新しく送信してください。ウインドウを切り替えた後に以前のページだけが停止する場合は、新しいリクエストを試して、古いセッションの失効と接続全体の切断を区別します。

サーバー情報とConfigを一つずつ比較

同じサブスクリプションをインポートしていても、2台で異なるサーバー情報が選択されていたり、一方の端末でまだ更新されていなかったりすることがあります。サーバー名だけでなく、プロトコル、アドレス、ポート、主要なトランスポート設定を比較します。認証情報は端末内でのみ照合してください。次に、有効なConfig、Global Routing、ポリシーグループの選択を確認します。同じファイル名でも内容が同じとは限らず、手動編集や後からの更新で差が生じることがあります。リストの見た目が同じだけでは、実際のリクエスト経路が同じとは証明できません。

Scan QR Codeでインポートする場合は、読み取ったものがサーバー情報なのかサブスクリプションリンクなのか確認してください。両者では、その後の更新方法が異なります。共有機能で情報を渡す場合も、内容が完全か確認します。インポート後はAdd Serverで必須項目を確認し、実際に接続してください。「項目が一つ表示された」だけで設定全体が正しいと判断しないでください。QRコードを共有する際は周囲の人にも注意してください。コードにはテキストの認証情報と同じ機密情報が含まれていることがあります。

ローカルネットワークとネットワーク切り替えを確認

iPadはプリンター、ファイルサービスなどのローカルネットワーク機器と一緒に使われることがあります。通常のWebページは開けるのにローカルネットワークのリソースだけ使えない場合は、接続先のアドレス範囲がDIRECTで処理されているか、ローカルドメインを従来どおり名前解決できるかを確認してください。ローカルネットワークの範囲が常に192.168.0.0/16とは限らないため、実際のネットワークを確認し、例のルールをそのままコピーしないでください。アプリがローカルネットワークへのアクセス許可を求める場合は、用途に応じて許可するか判断します。VPNの状態が正常でも、アプリに必要なシステム権限の代わりにはなりません。

モバイル通信対応のiPadでは、Wi-Fiからモバイルデータ通信に切り替えた後、既存の接続を再確立する必要がある場合があります。Wi-Fiのみの端末でも、スリープ解除後にネットワークへ再接続することがあります。切り替えやスリープ解除の後に必ず不具合が起きるか確認し、ネットワークが安定してから新しいリクエストを送信してください。再接続で復旧する場合は、On Demandの条件とサーバーが経路の変化にどう対応するかを引き続き確認します。切り替え中にサブスクリプションも更新しないでください。二つの操作が重なると、どちらが原因か判断しにくくなります。

購入済みアプリの復元と、報告時に役立つ項目

端末の買い替えや再インストール時は、App Storeに元の購入アカウントでサインインしていることを確認し、購入済みの項目からアプリを探します。ストアでの購入済みアプリの復元と、アプリ内のサーバー情報の復元は別の操作です。前者はアプリの入手に関するもので、後者には利用者自身が保存した設定またはサブスクリプションが必要です。iPhone / iPad版はApp Storeで$2.99の買い切りで、両方のデバイスで利用できます。Mac、Windows、Android、Linux版は無料です。ストアの表示内容とシステム要件はApp Storeの製品ページを確認してください。復元方法は購入済み項目についてを参照してください。

iPad固有の問題を報告する際は、基本ネットワークが正常か、VPNの許可が完了しているか、同じサーバー情報が別の端末で使えるか、3つのモードでどのような結果になったか、画面ロックまたはネットワーク切り替えの後だけ発生するかを順に記載してください。個人情報を伏せた適用ルールとエラーの種類を添え、サブスクリプションの完全なURLやQRコードは添付しないでください。これらの情報があれば、わかっている条件から続きを調査でき、最初から推測する必要がありません。まだ初回インポートが済んでいない場合はクイックスタートの手順に戻ってください。接続できるのに一部のリクエストが失敗する場合は、このページの接続とルーティングの確認に戻って原因を調べます。