この記事では、Shadowrocketに自分のサーバーまたはサブスクリプションを追加したものの、接続をオンにしてもWebページにアクセスできない場合の確認手順を説明します。まず基本のネットワークを確認し、選択中のサーバー、Global Routing、DNS、ルールとオンデマンド接続の設定を順にチェックします。変更は一度に1項目だけにし、同じ宛先で再テストしてください。「トンネルが起動した状態」と「宛先へのリクエストが成功した状態」を分けて考えることが大切です。
1. 接続スイッチだけで通信できていると判断しない
Homeの接続スイッチやシステムのVPN表示は、トンネルが起動していることを示します。接続先サーバーに到達できること、認証情報が有効であること、すべてのWebサイトが正常に応答することを保証するものではありません。ブラウザーが待ち続ける、すぐにサーバーが見つからないと表示される、特定のサイトだけ開けない、といった症状はそれぞれ原因が異なります。すべてをサーバーの障害と決めつけないでください。
まず自動接続の影響を止め、接続をオフにしたときとオンにしたときの状態を比べます。オフにしても通常のWebページが開かない場合は、Wi-Fi、モバイルデータ通信、または現在のネットワークのログイン認証を先に確認してください。この段階でルールを何度も更新しても、通常は解決につながりません。公衆Wi-Fiでログインが必要な場合は、認証を済ませてからテストします。
-
オンデマンド接続を一時停止する
Settings → On Demandを開き、現在の設定を記録してからオンデマンド接続を一時的にオフにします。Homeに戻って接続スイッチもオフにしてください。手動で切断した直後に自動接続され、比較結果が変わってしまうのを防げます。
-
基本のネットワークを確認する
普段アクセスできるWebページをブラウザーで開き、現在のWi-Fiまたはモバイルデータ通信が使えることを確認します。もともと直接アクセスできない宛先だけを判断材料にしないでください。
-
選択中の項目を確認する
Homeで選択中のサーバーを示す丸印を確認し、サーバー名とプロトコルを記録します。サーバーが一覧にあることと、実際にそのサーバーが選択されていることは別です。
-
接続テストを実行する
接続をオンにし、Home → Connectivity Testを実行して、テスト方法と結果を記録します。テストに成功したら、先ほど開けなかったWebページにもアクセスしてみてください。テストのリクエストとWebページへのアクセスは別のリクエストです。
-
再テストの条件をそろえる
ネットワークの種類、現在のGlobal Routingのモード、テスト先、エラーメッセージを記録します。その後は一度に1項目だけ変更し、同じアドレスで再テストしてから変更を維持するか判断してください。
2. サーバー設定とサブスクリプションの状態を確認する
サーバーアドレス、ポート、プロトコル、認証情報は、すべて同じ有効な設定の組み合わせである必要があります。まずHomeで現在選択しているサーバーの編集画面を開き、サービス提供元から受け取った情報と各項目を照合してください。接続を試すためにすべてのポートを443へ変更したり、異なるプロトコルの項目を流用したりしないでください。
- アドレスとポート：アドレス欄に、その欄に不要なパス、空白、サブスクリプションURL全体を入力しないでください。ポートはサーバーの待ち受け設定と一致させます。WebサイトがHTTPSを使っているからといって、プロキシも443で待ち受けているとは限りません。
- Shadowsocks：暗号化方式とパスワードを確認してください。アドレスとポートが正しくても、有効なプロキシ接続を確立できない場合があります。
- VMess / VLESS：UUID、転送方式、および関連するHost、Path、TLSの設定を確認してください。転送層の設定が一致していないと、タイムアウトやハンドシェイクの失敗につながることがあります。
- Trojan：パスワード、TLS、サーバー名を確認してください。サーバー名が証明書の検証やハンドシェイクに使われる場合、証明書と関係のない値に変更しないでください。
- Hysteria2 / WireGuard：現在のネットワークでUDPが到達可能かどうかも確認してください。TCPのテストに成功しても、UDP経路やプロトコル認証が正常とは限りません。
サーバーがサブスクリプションから追加されている場合は、該当するサブスクリプションを更新してから、サーバーが削除、改名、置き換えされていないか確認します。サブスクリプションはサービス提供元から取得してください。更新に失敗した場合、今回サブスクリプションの内容を取得できなかったことは分かりますが、すでに追加済みのサーバーがすべて使えなくなったとは限りません。更新に成功しても、すべてのサーバーの接続が確認されたわけではありません。
アプリの買い切り購入と回線サービスの契約は別です。Shadowrocketはクローズドソースの商用アプリです。アプリを購入しても、サービス提供元のアカウントが作成されたり、サービスの利用枠が追加されたり、サブスクリプションの有効期限が延長されたりすることはありません。アカウントの状態やサーバーのメンテナンス状況は、ご利用のサービス提供元に確認してください。
3. Global Routingでモードとルールの問題を切り分ける
Home → Global Routingで現在のモードを確認します。Configは現在有効な設定を使ってルールで通信を振り分けます。Proxyはすべての通信をプロキシ経由にする比較用、Directはすべての通信を直接接続にする比較用です。Sceneを使用している場合は、選択中のシーンの設定も確認してください。シーン名だけで通信経路を判断することはできません。以下の3つは今回のトラブルシューティング用の比較条件であり、モードの一覧ではありません。
| 比較する設定 | 確認できる症状 | 次に確認する項目 |
|---|---|---|
| Direct | 直接接続できるはずのWebページも開かない | 基本のネットワーク、DNS、トンネル内で引き続き有効な関連設定 |
| Proxy | 複数のテスト先すべてで失敗する | 選択中のサーバー、認証、転送設定、ネットワークからの到達性 |
| ProxyとConfig | 同じ宛先がProxyでは開くが、Configでは開かない | 適用されたルール、ポリシーの指定先、現在有効な設定、DNSの違い |
| Config | 一部のドメインだけ開かない | 該当ドメインと関連ドメインへのルール適用状況。設定全体をいきなり入れ替えないでください |
比較するときは、同じサーバー、ネットワーク、宛先アドレスを使ってください。モードを切り替えると同時にサーバーも変更すると、Webページが表示されたとしても、どちらの変更が効果をもたらしたか分かりません。切り替え後にリクエストを再送します。既存の長時間接続が古い経路を使い続けることがあるため、必要に応じてテストページを閉じて開き直してください。
4. DNSを確認する：名前解決の失敗と接続の失敗を切り分ける
DNSはドメイン名をIPアドレスに変換します。名前解決に失敗した場合、接続はまだ宛先サーバーに到達していない可能性があります。名前解決に成功しても、接続、TLS、アプリケーションの応答段階で失敗することがあります。サーバーアドレスにドメイン名を使っている場合、その名前解決も接続経路の一部です。そのため、DNSの問題がプロキシサーバーに接続できない症状として現れることもあります。
この流れは確認箇所を切り分けるためのもので、すべてのリクエストでの内部処理順を示すものではありません。ドメインルールが先に適用される場合もあれば、アドレスに関するルールで名前解決の結果が必要になる場合もあります。また、リモートDNSを使うと名前解決が行われる場所も変わります。トラブルシューティングでは、図だけからクライアントの動作を推測せず、実際のリクエスト記録を確認してください。
- 設定元を確認：Configで現在有効な設定を確認し、DNS関連の項目をチェックします。Settingsで関連項目を変更したことがある場合は、その変更内容も記録してください。設定ファイル、リゾルバー、サーバーを同時に変更しないでください。
- リゾルバーへの到達性を確認：カスタムDNSのアドレスには、想定される経路でアクセスできる必要があります。DoHは443を使っていても、ドメイン名の名前解決、TLS、接続経路の問題で失敗することがあります。
- 記録した元の値に戻す：DNSの変更直後に問題が起きた場合は、検証していないリゾルバーを次々に追加せず、記録しておいた元の値に戻して再テストしてください。
- IPv4とIPv6を切り分ける：ドメインにAAAAレコードがあり、現在のネットワークのIPv6経路に問題がある場合、一部の宛先で待ち時間が長くなったり、接続に失敗したりすることがあります。実際の接続先アドレスを確認してください。すべてのタイムアウトをIPv6の問題と決めつけないでください。
「ブラウザーにWebサイトのIPアドレスを直接入力する」方法だけで、HTTPSが正常かどうかを判断しないでください。HTTPSでは通常、ドメインに対応する証明書とサーバー名が使われます。IPアドレスに直接アクセスすると、証明書エラーが表示されたり、別のサイトが開いたりする場合があります。元のドメイン名を使い、名前解決の結果、接続先アドレス、ハンドシェイクの結果をそれぞれ確認してください。
5. Configのルール順序と実際のポリシーを確認する
ProxyではアクセスできるのにConfigではできない場合、保存されているファイルだけを見るのではなく、Configで実際に有効になっているルールを優先して確認します。通常のルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。範囲の広いルールが前にあると、後続の細かいルールが適用されないことがあります。FINALは最後のフォールバックルールです。最終的にどのポリシーを指定しているか確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY上記は構文を説明するための例であり、現在の設定を置き換えられる完全なファイルではありません。example.comと192.0.2.0/24はドキュメント用の例です。PROXYの実際の接続先は、使用中の設定で確認してください。例にあるポリシー名を、接続できることが確認済みのサーバーだとみなさないでください。
- DOMAIN-SUFFIX：ドメインの末尾に基づいて一致します。例ではexample.comとそのサブドメインが対象ですが、Webページが画像、スクリプト、ログイン用APIなど別のドメインにもリクエストを送ることがあります。
- IP-CIDR：IPアドレスの範囲に基づいて一致します。例にあるno-resolveは、このアドレスルールのためにドメイン名の名前解決を明示的に行わない設定です。クライアント全体のDNSを無効にするものではありません。
- GEOIP：IPアドレスの地理情報に基づいて一致します。Webページの言語、ドメインの末尾、サイト運営者の所在地で判定するものではありません。
- FINAL：それまでのルールに一致しなかった通信を処理します。利用できないポリシーを指定していると、前のルールで対象にならなかったリクエストがまとめて失敗することがあります。
失敗するリクエストを一度再現し、利用できるリクエスト記録やログを確認して、ドメイン、一致したルール、最終的なポリシー、エラーを照合してください。ホームページは開くのにログインできない場合は、ログイン用APIのドメインを個別に確認します。ページの文字は表示されるのに画像が読み込まれない場合は、画像リソースへのリクエストを確認してください。1つのWebページには複数の接続が含まれるため、1つのリクエストが成功してもページ全体の動作確認にはなりません。
6. エラーの原文から次の確認項目を判断する
以下はネットワークログでよく見られるエラーの例です。すべてのトラブルで表示されるとは限らず、画面に必ず同じ文言が出るわけでもありません。実際に表示された全文と前後の状況を保存し、失敗している対象がプロキシサーバー、DNSリゾルバー、Webサイトのいずれかを確認してから、該当する方法で調べてください。
エラー：connection refused
原因：その接続が明示的に拒否されています。ポートで待ち受けていない場合や、接続を明示的に拒否された場合によく起こります。対処：エラーに記載されたアドレスとポートを確認し、サービス提供元に待ち受け状態を確認してください。すぐにパスワードの誤りと判断しないでください。
エラー：i/o timeout
原因：処理の一部が制限時間内に完了していません。ネットワークでのパケット損失、サーバーから応答がない、後続の接続が停止しているなどの可能性があります。対処：まずタイムアウトが発生した段階を特定し、同じサーバーと宛先を使ってWi-Fiとモバイルデータ通信を比較してください。
エラー：no such host
原因：対象のドメイン名を有効なアドレスに変換できていません。アドレスの入力ミスや名前解決の問題が考えられます。対処：エラーに記載された完全なドメイン名を確認し、それがサーバー、リゾルバー、宛先Webサイトのどれに該当するかを特定して、該当するDNS経路を確認してください。
エラー：certificate has expired or is not yet valid
原因：証明書の有効期間が現在の日時と一致していません。サーバー側の証明書切れ、またはデバイスの日時設定の誤りが考えられます。対処：デバイスの日時とサーバー名を確認してください。サーバー側の証明書に問題がある場合は、管理元に対応を依頼します。証明書検証を無効にする方法を通常の解決策にしないでください。
エラーの詳細が表示されない場合は、最小限の再現情報をまとめてください。使用したネットワーク、選択中のプロトコル、Global Routingのモード、Connectivity Testの方法、失敗した宛先、接続をオフにすると復旧するかを記録します。共有前にパスワード、UUID、秘密鍵、サブスクリプションURL内のtokenを削除し、認証情報を含む設定全体は公開しないでください。
7. 再テスト後にOn Demandを元に戻し、確認結果を記録する
アクセスが復旧したら、まず現在のネットワークで再確認し、次に別のネットワークでもテストします。モバイルデータ通信では成功してWi-Fiでは失敗する場合は、そのWi-Fiの接続条件を詳しく確認してください。特定のサーバーだけ失敗する場合は、そのサーバーの設定や状態を重点的に調べます。どちらも「再起動したら直った」だけの場合より、後から原因を特定しやすくなります。
- 日常的に使うGlobal Routingのモードに戻し、現在有効なConfigと選択中のサーバーが想定どおりであることを確認します。
- 通常のWebページ、先ほど開けなかった宛先、その宛先のログインやリソース読み込みをそれぞれ確認してください。ホームページだけの確認で終わらせないでください。
- Settings → On Demandを開き、記録しておいた設定に戻します。ネットワークを切り替えたとき、意図しない再接続やモード変更が起きないか確認してください。
- 効果があった変更と、解決していない症状を記録してください。サービス提供元に問い合わせる際は、個人情報や認証情報を除いたエラーと再現手順を共有し、複数の設定を手当たり次第に変更しないでください。
アプリの入手先を確認する場合、ShadowrocketはAppleプラットフォーム向けにのみ提供されており、主にiPhone / iPadで利用できます。入手先はApp Storeのみです。開発者はShadow Launch Technology Limitedで、アプリは買い切りです。システム要件はApp Storeの掲載内容をご確認ください。アプリを入手し直しても、サーバー、DNS、ルールの問題は解決しません。操作の前に、ご自身の設定を適切に保存してください。