接続スイッチがオンでも、確認できるのはローカルで接続が開始されたことだけです。サーバー、名前解決、接続先のWebサイトが利用可能とは限りません。自分で用意したサーバー情報またはサブスクリプションをお持ちの方向けに、まず基本ネットワークを確認し、サーバー、Global Routing、DNS、ルールを順番にテストします。一度に変更する設定は一つに絞り、最後に普段の設定へ戻してください。
01 「接続中」と「リクエスト成功」を区別する
Shadowrocketの接続状態、サーバーの遅延テスト、Webページの実際の読み込みは、それぞれ別の確認項目です。ステータスバーにVPNの表示があっても、リモートサーバーの認証が完了したとは限りません。遅延テストに数値が表示されても、Webページに必要なDNS、TLS、その後のリソース取得まで成功したとは限りません。接続スイッチを何度も切り替えるより、まず状況を記録すると原因を絞り込みやすくなります。
始める前に、使用中のサーバー、Global Routingの選択肢、現在のConfig、開けないWebページのドメインを記録します。普段直接アクセスできるWebページを一つ、現在開けないページを一つ選びます。一つのサイトの不具合だけで、ネットワーク全体が使えないと判断しないでください。
-
基本ネットワークを確認する
まずSettings → On Demandで自動接続の設定を確認し、一時的にオフにします。次にHomeへ戻り、接続スイッチをオフにしてください。Safariで普段直接アクセスできるWebページを開きます。それでも開けない場合は、Wi-Fiのログイン認証、モバイルデータ通信の許可、またはネットワーク自体の問題を先に解決してください。
-
テスト条件をそろえる
同じネットワーク、同じWebページ、同じデバイスを使います。Homeに戻って自分のサーバーを選び、接続をオンにしてください。テスト中にWi-Fi、サーバー、Configを同時に切り替えると、どの変更が結果に影響したのか分からなくなります。
-
失敗する範囲を記録する
「すべてのWebページが開かない」「一部のドメインだけ開かない」「ページは開くが画像が表示されない」「特定のAppだけ失敗する」のどれに当てはまるかを記録します。発生時刻と、そのときのGlobal Routingの選択肢も記録し、後でリクエスト記録と照合してください。
-
一つずつ変更して再テストする
設定を一度に一つだけ変更し、同じリクエストをもう一度実行します。必要に応じて接続をオフにしてから、再度オンにしてください。改善しない場合はその設定を元に戻してから次へ進み、一時的な設定を重ねないようにします。
02 サーバーへの接続と既存のサブスクリプションを確認する
HomeでConnectivity Testを実行し、既存のサーバーを確認します。テスト対象として選択されている項目が、確認したいサーバーと同じかも確かめてください。結果はテスト方法や接続先に左右されます。ポートに接続できてもプロトコル認証の成功を意味せず、テスト先にアクセスできても他のWebサイトが使えるとは限りません。ブラウザーでの実際のリクエストと合わせて判断してください。
現在の項目の編集画面を開き、Type、サーバーアドレス、ポート、認証情報を一つずつ確認します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは必要なパラメーターが異なります。項目がタイムアウトしたからといって、別のプロトコルにむやみに変更しないでください。TLSを使う場合は、サービス提供元が指定するサーバー名と関連パラメーターも確認し、証明書検証をオフにして設定ミスを隠さないようにします。
- 失敗する項目が一つだけの場合：自分で用意した別の利用可能な項目があれば、ほかの条件を変えずに切り替えてテストします。結果の違いから、問題がそのサーバーまたは設定に集中しているかを判断できます。
- 同じネットワークで全項目が失敗する場合：まず基本ネットワークを確認し、自分が利用できる別のネットワークでも再テストします。ネットワークを切り替えて改善しても、経路に違いがあることを示すだけで、認証情報が正しいと断定はできません。
- 以前は使えたのに現在は使えない場合：自分が利用しているサービスの有効期限、通信量の状況、メンテナンスのお知らせを確認します。既存のサブスクリプションを更新したうえで、現在選択されている項目も確認してください。
- サブスクリプションの更新後も失敗する場合：更新できたことはサブスクリプションの内容を取得できたという意味であり、すべてのサーバーが利用可能という意味ではありません。更新後は選択中の項目も確認してください。更新処理が完了したかどうかだけでは判断できません。
03 Global Routingで比較テストする
サーバーがひとまず利用可能と確認できたら、Home → Global Routingで現在の選択肢を確認します。Proxy、Direct、Config、Sceneはそれぞれ異なるルーティング方式です。接続スイッチだけでは、通信がどの経路を通ったか分かりません。調査前に現在の設定を記録し、ProxyとConfigを一時的に比較したら、最後に普段の設定へ戻してください。
| 選択肢 | 確認するポイント | 結果の見方 |
|---|---|---|
Proxy | 通常のリクエストをプロキシ経由にし、現在のプロキシ選択を確認します。 | 同じWebページがここでは開き、Configでは失敗する場合は、まずルールとポリシーの選択を確認します。DNSの違いにも注意してください。 |
Direct | リクエストを直接接続経由にします。 | サーバーが選択されていても、リクエストがそのサーバーを使うとは限りません。基本的な比較には、直接アクセスできるWebページだけを使ってください。 |
Config | 現在のConfigに含まれるルールに従ってリクエストを処理します。 | 意図したConfigが有効になっていることを確認し、失敗したリクエストに適用されたルールと最終ポリシーを調べます。 |
Scene | 現在のSceneと、それに関連する設定を確認します。 | Sceneによって実際に使われるルーティング設定が変わる場合があります。サーバーを手動で選んだだけでは、最終的な通信経路を判断できません。 |
ProxyとConfigのどちらでも失敗する場合は、すぐにルールを追加せず、サーバーとDNSを引き続き確認します。Proxyでは使えてConfigでは使えない場合は、Configで対象ドメインがDIRECT、REJECT、または利用できないポリシーグループに割り当てられていないかを重点的に調べてください。この比較は原因を絞る手掛かりであり、サーバーが完全に正常だと証明するものではありません。
04 遅延は正常なのにWebページが開かない場合はDNSを確認する
Webページを開くには、まずドメイン名をIPアドレスに変換する必要があります。遅延テストがサーバーポートだけを確認している場合や、Webページとは異なる接続先を使っている場合、「遅延は正常なのにページが開かない」ことがあります。Settings → DNSで現在の設定を確認してください。また、有効なConfigに自分のDNS設定が含まれていないかも確認し、一方だけ変更してもう一方を見落とさないようにします。
まず元の設定を保存し、使えなくなったカスタムDNSアドレス、特定のネットワークでしかアクセスできないリゾルバー、不完全な暗号化DNSアドレスがないか確認します。よく分からないアドレスを次々に追加しないでください。リゾルバー自体に到達できない場合、数を増やしても解決するとは限らず、比較も難しくなります。
これらは各プロトコルで一般的に使われるポートであり、サーバー項目に一律で入力する値ではありません。サーバーのポートはサービス提供元の指定どおりにしてください。DoHでホスト名を含むエンドポイントを使う場合、そのホスト名を最初に名前解決する必要があります。リゾルバーへのアクセスにプロキシが必要な場合は、プロキシが使えないと名前解決にも失敗することがあります。
- まず元に戻して比較する：最近追加したカスタムDNS設定を一時的に取り消し、以前使えていた設定に戻します。その後、接続を確立し直して同じドメインを開いてください。
- 次に失敗した段階を確認する：名前解決結果を取得できなかったのか、アドレス取得後に接続またはTLSの段階で失敗したのかを区別します。後者はDNSを変更するだけでは解決できません。
- IPアドレスでの表示を結論の代わりにしない：HTTPSサイトでは、ドメインに対応する証明書、SNI、バーチャルホストが必要な場合があります。IPアドレスへの直接アクセスに失敗しても、ネットワークがつながっていないとは限りません。
05 ルールの順序、ポリシー、FINALを確認する
Configでのみ問題が発生する場合は、Configを開いて現在使用中の設定を確認し、そのルールを調べます。ルールは通常、上から順に評価され、最初に一致したルールのポリシーが適用されます。FINALはそれ以前のルールに一致しなかった場合の受け皿です。そのため、正しいルールを追加しても、早い位置にあるFINALより後ろに置くと期待どおりに動作しません。
以下は構文の説明であり、設定全体を置き換えるためのものではありません。example.comと192.0.2.0/24は例です。実際のルールは、対象とポリシーの設定に合わせてください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY：指定したドメインとそのサブドメインに一致し、PROXYに割り当てます。Webページの読み込みに使われる別ドメインまで自動的に対象にするものではありません。IP-CIDR,192.0.2.0/24,DIRECT,no-resolve：宛先IPアドレスの範囲で一致させます。no-resolveは、このルールのために能動的なドメイン名解決を行わないという意味であり、リクエスト全体でDNSが不要になるわけではありません。GEOIP,CN,DIRECT：宛先IPの地理データベース上の分類に基づいて一致させます。Webサイトの記載内容やドメインの末尾から地域を判定するものではありません。FINAL,PROXY：それ以前のルールに一致しなかったリクエストを処理します。実際の設定がDIRECTまたはREJECTの場合は、それが意図した動作か確認してください。
再テスト時はアプリ内のリクエスト記録を開き、直前の時刻とドメインでリクエストを特定し、一致したルールと実際のポリシーを確認します。PROXYに一致しても失敗する場合は、使用されたサーバーまたはポリシーグループを引き続き調べます。REJECTに一致した場合は、範囲が広すぎるルールにブロックされていないかを先に確認してください。一つのページを開くためにすべてのルールを削除せず、まずバックアップを取り、変更範囲を絞ってください。
06 エラーメッセージから次の手順を判断する
エラーメッセージは、表示された場所と合わせて判断してください。以下は接続や名前解決の記録によく出る英語のエラー例です。大文字・小文字や追加情報は異なる場合があります。ブラウザーに表示される「ページを開けません」だけでは失敗した段階を特定できないため、同じ時刻のアプリ内記録も確認してください。
エラー：Connection refused
原因と対処：接続先のアドレスまたは経路上の機器が接続を拒否しています。ポートで待ち受けていない場合や、アクセスが拒否された場合によく見られます。自分のサーバーアドレスとポートを確認し、サービス提供元に待ち受け状態を問い合わせてください。すぐにパスワードの誤りと決めつけないでください。
エラー：Connection timed out
原因と対処：制限時間内に接続が完了しませんでした。通信経路、サーバーの状態、ファイアウォールなどが原因として考えられます。設定を変えずに、自分が利用できる別のネットワークで再テストし、一つのサーバーだけで発生するか記録してください。
エラー：NXDOMAIN
原因と対処：DNSがドメインを存在しないものとして返しています。ドメイン名の入力ミスや、名前解決結果の異常が考えられます。まず完全なドメイン名を確認し、以前正常に使えたDNS設定で再テストしてください。サーバー一覧を何度更新しても、ドメイン名の入力ミスは直りません。
TLS証明書に関するエラーがある場合は、デバイスの日付と時刻、サーバー名、サービス提供元の証明書設定も確認してください。Webページから明確なHTTPステータスコードが返っている場合は、少なくとも一度はHTTP応答を受け取れています。ステータスコードをもとにWebサイトやアクセス方針を確認し、すべての失敗をDNSの問題と決めつけないでください。
07 よくある質問と設定の復元
Connectivity Testに数値が表示されるのに、なぜWebページが開かないのですか？
まずHome → Global Routingで現在の選択肢を記録し、同じWebページを使ってProxyとConfigを比較します。遅延テストではWebページのすべてのリクエストを確認できません。失敗した時刻を手掛かりに、DNSの結果、適用されたポリシー、接続エラーを確認してください。
Proxyに切り替えると使えます。そのまま使い続ければよいですか？
これはルーティング方式によって結果が異なることを示していますが、ルールの問題が解決したとは限りません。Configに戻り、対象ドメインに一致するルールの位置、ポリシーグループ、FINALを確認してください。修正後は元のルーティング方式に戻し、同じWebページで結果を確かめます。
接続をオフにしても自動的にオンになります。基本テストを行うにはどうすればよいですか？
Settings → On Demandを開き、現在の設定を記録してから自動接続を一時的にオフにします。その後Homeに戻って接続をオフにしてください。調査が終わったら元のOn Demand設定に戻し、テスト用の状態を普段の設定として残さないようにします。
サブスクリプションを更新した後、サーバーを選び直す必要はありますか？
Homeに戻り、現在の項目を確認してください。更新によって項目の内容や名前が変わる場合があります。選択内容を確かめてからConnectivity Testを実行し、実際のWebページもテストしてください。サブスクリプションの更新成功だけでは、接続先が使える証明にはなりません。
先にアプリを削除して再インストールしたほうがよいですか？
まずは上記の手順に沿って原因を切り分けてください。再インストールしてもリモートサーバーや通信経路の問題は解決せず、ローカル設定を失う可能性があります。再インストールが必要な場合は、先に設定をバックアップし、自分のサブスクリプションと認証情報を安全に保管してください。
調査が終わったら、元のネットワークとWebページで再テストし、一時的に変更したGlobal Routing、DNS、On Demandの設定を元に戻してください。失敗した時刻、ネットワークの種類、使用したサーバー、一致したポリシー、エラーメッセージ、有効だった変更を簡潔に記録しておきます。問い合わせる場合は、機密情報を伏せた記録だけを共有してください。サブスクリプション内のtoken、パスワード、秘密鍵をスクリーンショットや公開メッセージに含めないでください。