Shadowrocketの接続スイッチをオンにすると、システムのネットワークトンネルが有効になります。ただし、サーバーやDNS、接続先のWebサイトまで通信できるとは限りません。利用中のサービスとサブスクリプションがあり、設定を読み込み済みでもアクセスできない場合に向けた手順です。「基本ネットワーク → サーバー → Global Routing → DNS → Rule」の順に、設定を一度に一つだけ変更して原因を切り分けます。確認後は元の設定に戻し、テスト用の設定をそのまま使い続けないでください。
始める前に：テスト条件をそろえて基本ネットワークを確認
まず、「すべてのWebページを開けない」のか「特定のドメインだけ開けない」のかを切り分けます。前者は基本ネットワークとサーバー、後者は接続先のWebサイトや名前解決、ルールが関係している可能性があります。システムのVPN表示だけで通信が正常だと判断したり、遅延テストが一度成功しただけで、すべての通信が成功すると考えたりしないでください。
-
現在の状態を記録する
Homeで選択中のサーバーとGlobal Routingの値を記録し、Configで現在有効な設定ファイルを確認します。元の設定を複製して保管し、アクセスできないドメイン、発生時刻、Wi-Fiとモバイル通信のどちらを使ったかも記録してください。記録を共有する際は、パスワード、サブスクリプションURL、認証情報を隠します。
-
自動接続を一時停止する
Settings → On Demandを開き、元の設定を記録してから、オンデマンド接続を一時的にオフにします。その後、Homeの接続スイッチもオフにしてください。これにより、基本ネットワークのテスト中にネットワーク状況が変わってトンネルが再接続されるのを防げます。
-
基本ネットワークをテストする
接続をオフにした状態で、普段直接アクセスできるWebページを開きます。それでも開けない場合は、まずWi-Fiのログイン認証を済ませる、モバイルデータ通信の使用許可を確認する、または別のネットワークに切り替えてください。この段階ではRuleやDNSを先に変更しないでください。
-
テストするリクエストを固定する
基本ネットワークに問題がなければ再接続し、各テストで同じ完全なURLを使います。単に「開けない」と記録するのではなく、名前解決エラー、接続タイムアウト、証明書エラーのどれが発生したかを記録してください。Wi-Fiとモバイル通信を切り替えた場合は、別のテストとして記録します。
トンネルをオフにしてアクセスできても、その時点で直接アクセスする経路が使えたことしか分かりません。元のサーバーが正常だとは限りません。反対に、特定の接続先に直接アクセスできなくても、それだけで基本ネットワークが切断されているとは判断できません。直接アクセスできることが分かっている別の接続先を比較対象にしてください。
手順1：Homeでサーバーと接続パラメータを確認
Homeで選択中のサーバーが想定どおりか確認し、該当項目の編集画面を開いて、サービス提供元から受け取った情報と一つずつ照合します。アドレス、ポート、Type、認証情報の組み合わせが正しい必要があります。ポートが443だからといって設定が正しいとは限らず、ポート番号だけでプロトコルを判断することもできません。
- アドレスとポート：余分な空白や入力ミスがないか、ポート番号が正しいか確認します。サーバーアドレスにドメイン名を使っている場合は、接続を確立する前にその名前を解決する必要があります。
- プロトコルと認証：Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardではパラメータの構成が異なります。対応するTypeを選び、手元の情報に従って入力してください。あるプロトコルの項目を別のプロトコルにそのまま当てはめないでください。
- TLS関連の項目：TLSを使用する接続では、サービス提供元から指定されたSNI、証明書名、トランスポートパラメータを確認します。接続先アドレスと証明書名が異なる場合もあるため、独断で同じ値に変更しないでください。
- サブスクリプションの状態：サブスクリプションから追加した項目の場合は、まずHomeで自分のサブスクリプションを更新し、選択中の項目が引き続き有効か確認します。サブスクリプションの更新とConfigでの設定ファイルの有効化は別の操作であり、互いに代用できません。
Homeで接続テストや遅延テストを行う際は、使用されたテスト方法と結果の両方を確認してください。TCP接続に成功しても、その時点で該当アドレスとポートに接続できたことしか分かりません。認証、TLS、転送、接続先Webサイトからの応答までを完全に検証するものではありません。サーバーが複数ある場合は、ほかの設定を変えずに、登録済みの別の項目と比較できます。
エラー：connection refused
原因と対処：接続先のホストまたは中継機器が接続を明示的に拒否しています。ポートで待ち受けていない、または接続が拒否されている可能性があります。まずアドレスとポートを確認し、利用中のサービス提供元に接続先の状態を問い合わせてください。ポート拒否への対処として、先にDNSやルールを変更しないでください。
エラー：i/o timeout
原因と対処：ネットワーク処理が所定の時間内に完了しませんでした。名前解決、接続確立、その後の読み書きのいずれかで発生した可能性があります。エラー前後のアドレスや処理内容から箇所を判断し、別のネットワークでも同じ項目をテストしてください。タイムアウトだけでパスワードの誤りとは判断できません。
エラー：no such host
原因と対処：ドメイン名を解決できず、有効な結果を取得できていません。エラーがサーバーのドメインと接続先Webサイトのドメインのどちらを指しているか確認し、スペルとDNS設定を確認してください。対象のドメインを特定する前に、サーバーと設定ファイルを同時に変更しないでください。
ここに挙げたのは、ネットワークログに表示される可能性のあるエラーの原文です。画面によって同じ表記が表示されるとは限りません。確認時は、実際のエラーと前後の情報を残してください。「timeout」だけを切り出すと、サーバーへの接続失敗とWebサイトの応答遅延を混同しやすくなります。
手順2：Global RoutingでProxy、Direct、Config、Sceneを切り分ける
Home → Global Routingで現在のモードを確認します。サーバーを正しく選んでいても、リクエストが想定した経路を通らなければ、接続がオンでもアクセスできないことがあります。テストではサーバーを固定し、モードを一つずつ比較してください。サーバー、DNS、設定ファイルを同時に切り替えないでください。
| モード | トラブルシューティングでの見方 | 確認する項目 |
|---|---|---|
Proxy | Proxy経由のルーティングを比較対象にし、Ruleによる振り分けの影響を抑えます。 | 選択中のサーバー、接続パラメータ、接続先からの応答を確認します。ほかの設定がすべて解除されるわけではありません。 |
Direct | プロキシサーバーを経由せず、直接アクセスする経路を比較対象にします。 | ローカルネットワークからテスト対象にアクセスできるかを確認します。システムのトンネルをオフにすることと完全に同じではありません。 |
Config | 現在の設定ファイルにあるルールに基づいて、リクエストの処理方法を決定します。 | Configで有効になっているファイル、Ruleの順序、ルールに一致した後の処理方針。 |
Scene | 設定済みのシーン条件に応じて、ルーティング動作を切り替えます。 | 現在のネットワークに適用されるシーン設定。切り分け中は、動作が明確な固定モードを一時的に使用してください。 |
ポイント：同じリクエストでは変更する条件を一つに絞る
同じサーバーでProxyなら開けるのにConfigでは失敗する場合は、現在の設定にあるルールと処理方針を優先して確認します。どちらも失敗する場合は、サーバーとDNSの確認を続けてください。これは原因を絞り込む方法であり、障害原因を最終的に断定するものではありません。
DirectではアクセスできてProxyでは失敗する場合も、この結果だけでサーバーの停止とは判断できません。プロキシ経由の名前解決、認証、TLS、接続先Webサイトの制限などが影響する可能性があります。テスト後は元のGlobal Routingに戻してください。Sceneを使っている場合は、ネットワークを切り替えたときに結果が変わらないよう、シーン条件も元に戻します。
手順3：DNSでサーバーの名前解決とWebサイトの名前解決を切り分ける
DNSの問題は2か所で発生する可能性があります。最初にサーバーのドメイン名を解決する段階と、アクセス時に接続先Webサイトのドメイン名を解決する段階です。前者で失敗するとプロキシ接続自体を確立できず、後者で失敗するとサーバーテストには応答があるのにWebページを開けないことがあります。エラーに記載されたドメインを確認してから、変更する設定を決めてください。
- Configで現在有効なファイルの編集画面を開き、
[General]内のdns-serverを確認して、元の値を記録します。同じ名前でも有効になっていない別ファイルは編集しないでください。 - 元の設定でカスタムDNSを使用している場合は、アドレス、書式、現在のネットワークから到達できるかを確認します。DNS over HTTPSを使用している場合は、HTTPSエンドポイントにアクセスできるか、エンドポイントのドメイン名解決と証明書が正常かも確認してください。
- 設定ファイルを複製し、その中で一時的にシステムDNSへ変更して比較できます。複製を保存して有効にし、接続を確立し直してください。変更するのはDNSだけにし、サーバーとGlobal Routingはそのままにします。
- 同じドメインに再度アクセスします。結果が改善した場合は、元のDNS経路を引き続き確認してください。変化がない場合は元の値に戻してからルールを確認し、未検証の変更を重ねないでください。
[General]
dns-server = system[General]は設定ファイルの共通設定セクションです。dns-server = systemは、この項目でシステムDNSを使うことを示します。これは比較テスト用の設定例であり、設定ファイル全体ではありません。既存設定のほかのセクションを上書きするために使わないでください。システムDNSを使用した場合も、結果は現在のネットワークが提供する名前解決サービスに左右されます。
DNS over HTTPSはHTTPSで名前解決リクエストを送信しますが、あらゆるネットワークからアクセスできるとは限りません。名前解決のエンドポイント、サーバーアドレス、接続先Webサイトはそれぞれ別の対象です。DNSの通信方式を変えるだけでは、サーバーのポート拒否や認証パラメータの誤りは解決できません。
手順4：ConfigでRuleの順序と適用される処理方針を確認
Configに戻り、テスト時に有効になっていたファイルを確認します。Global RoutingがConfigの場合、通常はルールが上から順に評価され、先に一致したリクエストは、後続の同種ルールによる上書きを待ちません。まず対象ドメインに対応するルールを確認し、次にIPルールと最終ポリシーを調べます。設定に「PROXY」と書かれていても、そのリクエストが実際に該当ルールに一致したとは限りません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY[Rule]：ルールセクションの開始を示します。この断片は構文の説明用です。example.comは例示用のドメインで、接続テスト用のアドレスでも、すべてのユーザーに適した振り分け設定でもありません。DOMAIN-SUFFIX,example.com,PROXY：example.comとそのサブドメインに一致し、PROXYポリシーを適用します。一致するのはリクエストのドメイン末尾であり、Webページのパスに含まれる単語ではありません。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：このIPv4ネットワーク範囲に一致し、DIRECTを適用します。no-resolveは、このルールに一致させるためのドメイン名解決を明示的に開始しないことを示します。DNSを全体的に無効にする指定ではありません。GEOIP,CN,DIRECT：IPの地理情報データベースに登録された国コードに基づいて一致させ、直接アクセスします。判定にはIPデータを使い、Webページの言語、ドメインの末尾、サービス提供元の名称は使いません。データベース上の結果が実際のサーバー設置場所と異なる場合もあります。FINAL,PROXY：それ以前のルールに一致しなかった場合にPROXYを適用します。最終ポリシーで、すでに一致したDIRECTやREJECTのルールを上書きすることはできません。
Proxyでは正常にアクセスでき、Configでは失敗する場合は、より上位のDIRECTまたはREJECTに一致していないか、カスタムポリシーグループで有効なメンバーが選ばれているか確認します。一時的に検証する場合は、設定ファイルの複製に対象を一つに絞ったDOMAINまたはDOMAIN-SUFFIXルールを追加し、競合する可能性があるルールより前に配置してください。一つのドメインのためにRuleセクション全体を削除しないでください。
ポイント：ルールがあるかではなく、一致したかを確認
変更した設定を保存して有効にし、同じリクエストを再度実行します。アプリ内の接続履歴やログで、対象と適用されたポリシーを確認してください。「現在のファイルが有効」「リクエストが想定したルールに一致」「該当ポリシーが利用可能」の3点がそろって、今回のルール検証は完了です。
最後に：テスト結果から原因を絞り、設定を元に戻す
4段階の確認は、すべての設定を変更するためのものではありません。再現可能な比較結果を得ることが目的です。どのテストで成功または失敗したかを記録し、次回も同じ条件で再テストしてください。特定のWebサイトだけが開けない場合は、そのサイト自体が利用可能かも確認します。一つのサイトの障害を、すべてのプロキシ接続の問題と同一視しないでください。
| 比較結果 | 次に確認すること |
|---|---|
| 接続をオフにしても、直接アクセスできることが分かっているWebページを開けない | まずWi-Fiの認証、モバイルネットワークの使用許可、基本ネットワークを確認します。 |
| 同じ項目がWi-Fiでは失敗し、モバイル通信では成功する | Wi-FiネットワークのDNS、ポート、通信経路への到達性を確認し、両方のテスト結果を記録します。 |
| Proxyでは成功し、Configでは失敗する | 有効なファイル、ルールの順序、一致したポリシー、ポリシーグループのメンバーを確認します。 |
| dns-serverだけを変更したところ結果が変わった | 元のDNSへの到達性と名前解決結果を再テストし、一時的なネットワーク変動ではないことを確認します。 |
| どのモードでも、同じ接続先だけが失敗する | 接続先サービスの状態、名前解決結果、証明書エラーを確認し、全体設定をやみくもに変更しないでください。 |
- Global Routing、DNS、Settings → On Demandを元の設定に戻します。検証用に追加したルールは削除するか、検証用と分かるよう明記した設定ファイルの複製として残します。
- 利用中のサービス提供元に問い合わせる際は、プロトコルの種類、サーバーアドレスとポート、ネットワークの種類、発生時刻、個人情報を伏せたエラー情報を伝えてください。パスワードやサブスクリプションの認証情報全体は送らないでください。
- サブスクリプションを更新した後は、現在選択中の項目を再確認します。設定ファイルを変更した後は、Configで有効になっているファイルを確認し、実際に使っている対象と記録が食い違わないようにしてください。
ShadowrocketはAppleプラットフォーム向けの有料クライアントです。主にiPhoneとiPadで利用でき、入手先はApp Storeのみです。システム要件、デバイスの互換性、ユニバーサル購入への対応はApp Storeの表示をご確認ください。クライアントの購入と接続サービスは別のものです。当サイトでは接続先やサブスクリプションを提供、販売、推奨していません。