Shadowrocketでタイムアウトと表示されても、接続先のサーバーが停止しているとは限りません。この記事では、自分でサービスと設定を用意している方を対象に、同じ方法でテストして、特定のノード・現在のネットワーク・接続先サイトのどこに問題があるかを切り分けます。次にアドレス、ポート、認証、通信方式、TLSを確認し、最後にシステム時刻と実際の通信経路をチェックします。確認のたびに変更する項目は一つに絞り、元の設定とテスト結果を保存して、切り分け中に新たな問題を持ち込まないようにしましょう。
1. 遅延テストのタイムアウトと実際の接続失敗を切り分ける
遅延テストで確認できるのは、実際に実行された疎通確認の範囲に限られます。すべてのサイトやプロトコルが正常だとは判断できません。TCPハンドシェイクに成功しても、通常わかるのは接続先のTCPポートに到達できることだけです。パスワードやUUID、その後のTLSハンドシェイクが正しいことまでは確認できません。プロキシ経由でテスト用アドレスにアクセスした結果は、テスト先、DNS、接続先からの出口にも左右されます。まずテスト方法を記録し、数値を比較してください。異なる方法で測定した遅延を同列に並べないようにしましょう。
以下は結果を判断するための目安であり、当サイトで測定した実績ではありません。お使いの端末で結果を記録し、テスト方法、ノード、ネットワークを変えずに、少なくとも3回連続でテストしてください。
| 確認できた現象 | 考えられること | 次の確認項目 |
|---|---|---|
| 1つのノードだけが3回連続でタイムアウトする | そのノード、またはノードまでの経路に問題がある可能性が高い | そのノードのアドレス、ポート、プロトコル設定を確認する |
| 登録済みのノードがすべてタイムアウトする | ネットワーク、名前解決、設定など共通の問題が考えられる | まず通常のインターネット接続を確認し、ネットワークを切り替えて再テストする |
| ポートテストには応答するが、実際のWebページは開けない | ポートに到達できても、プロキシ認証に成功したとは限らない | 認証、TLS、通信方式、ルーティングを確認する |
| Webページは開けるが、テストだけがタイムアウトする | テスト先またはテスト方法が現在の接続に適していない可能性がある | テスト設定を確認し、ノードの作り直しは急がない |
| 特定のWebサイトだけ開けない | それだけでノード全体が使えないとは判断できない | 対象ドメインのルール、DNS、サイトの状態を確認する |
ポイント：テスト条件をそろえる
同じ方法で同じノードを3回連続してテストし、次にネットワークだけを切り替えて再テストします。プロトコルとルールを同時に変更すると、結果が変わった原因を特定できません。
2. 条件をそろえて最小限の再テストを行う
以下では、iPhone / iPadのHome、Config、Settingsを例に、確認する場所を説明します。他のプラットフォームでは、それぞれ対応する設定を確認してください。開始前に現在の設定を複製して保存します。サブスクリプションから追加したノードと手動編集したノードも、それぞれ記録を残してください。特に、バックアップなしでリスト全体を削除しないようにしましょう。
-
インターネット接続の基本確認
Homeで接続をオフにし、普段プロキシなしで開けるページをブラウザーで表示します。通常のインターネット接続も失敗する場合は、Wi-Fiのログイン、モバイルデータ通信の許可、ルーターとの接続を先に確認してください。ノードのパスワードを先に変更する必要はありません。
-
テスト対象を固定する
Homeに戻り、登録済みのノードを1つ選び、テスト方法と3回連続の結果を記録します。Connectivity Testを使う場合は、まずテスト設定を確認してください。再テスト中はテスト先を変更しないでください。
-
接続するネットワークを切り替える
同じノード、同じテスト方法のまま、Wi-Fiからモバイルネットワークに切り替えて再テストします。一方のネットワークだけで失敗する場合は、そのネットワークによるポート、UDP、ドメイン名解決への影響を優先して確認します。
-
自動接続の設定を確認する
Settings → On Demandを開き、現在の設定を記録します。手動で切断しても自動接続される場合は、切り分け中だけOn Demandを一時的にオフにできます。比較テストが終わったら元の設定に戻してください。
-
再テストの結果を記録する
ネットワークの種類、ノード名、テスト方法、発生時刻、エラーの原文を記録します。変更する項目は毎回1つだけにし、保存して再接続した後、同じ条件でテストしてください。
3. アドレス・ポート・認証・通信方式の順に確認する
Homeで対象ノードの編集画面を開き、自分のサービス提供元から受け取った元の設定と項目ごとに照合します。まずサーバーアドレスとポート、次にプロトコルの種類と認証情報、最後に通信方式とTLSを確認してください。設定名をサーバーアドレスと取り違えないようにしましょう。また、「よく使われるポート」という理由だけで数値を変更しないでください。443を使っていても、そのノードがTLSを使用するとは限りません。8443も自由に置き換えられる予備ポートではありません。
| プロトコルまたは項目 | 確認する内容 | 間違えやすい点 |
|---|---|---|
| アドレスとポート | 完全なホスト名またはIPアドレス、元のポート番号（1～65535） | 文字の抜け、コピー時の空白、接続先アドレスに含まれる別の数字をポート番号と誤認する |
| Shadowsocks | 暗号化方式とパスワード。元の設定にプラグインが含まれる場合は、そのパラメーターも確認する | ポートには到達できるが、暗号化方式またはパスワードが一致していない |
| VMess / VLESS | UUID、サーバーが求めるオプション、通信パラメーター | UUIDだけをコピーし、WebSocketのパスなど他の通信設定を見落とす |
| Trojan | パスワード、TLS、Server Name、証明書の対応関係 | 接続先IPアドレスは正しいが、TLSに使う名前が間違っている |
| Hysteria2 | 認証、TLS、ポート、および現在のネットワークで必要なUDP通信が許可されているか | TCPテストの結果でUDPの疎通状況を判断する |
| WireGuard | 鍵、Peer、Endpoint、インターフェースアドレス、ルーティング範囲 | Endpointだけを入力して他の設定が抜けている、または秘密鍵と公開鍵を逆に入力している |
| WebSocket / gRPC | 通信方式と、元の設定で指定されたHost、Path、Service Name | WebSocketのパスをgRPCのService Nameとして入力する |
サーバーへの接続アドレス、TLSのServer Name、WebSocketのHostは異なる場合があります。それぞれ接続の確立、証明書の検証、アプリケーション層のリクエストに使われます。必ず自分の元の設定を基準にしてください。「同じ値にそろえる」ために、すべてを同じドメイン名にする必要はありません。パスも元の設定どおりに保持します。たとえば元の設定が/gatewayなら、先頭のスラッシュを削除したり、大文字と小文字を変えたりしないでください。
- サブスクリプションから追加したノードは、ローカルの設定が古くなっていないか確認する前に、サブスクリプションの更新が成功していることを確認してください。
- サブスクリプションのノードを手動で編集する前に複製を保存してください。次回の更新でノードの項目が上書きされることがあります。
- 同じサービス提供元のノードでも、ポート、パスワード、通信方式が共通とは限りません。別のノードの設定を流用しないでください。
- TLSエラーを隠すために証明書の検証をオフにしないでください。まず名前、証明書、システム時刻を確認しましょう。
4. エラーの原文からタイムアウト・接続拒否・TLSエラーを切り分ける
接続ログにエラー文が表示される場合は、原文と発生時刻を保存してください。システムやプロトコルによって表示内容は異なるため、以下はよくあるネットワークエラーの読み取り方です。すべてのプラットフォームで同じ文言が表示されるとは限りません。エラーの単語だけでは原因箇所を特定できないことが多いため、前述のネットワーク比較テストとあわせて判断してください。
エラー：i/o timeout
原因と対処：接続、ハンドシェイク、読み込みなどのネットワーク処理が制限時間内に完了しなかった可能性があります。まずエラーが発生した段階を確認し、アドレスとポートを見直したうえで、別のネットワークでもテストしてください。
エラー：connection refused
原因と対処：接続要求が明示的に拒否されています。接続先のポートで該当サービスが稼働していない場合や、接続が拒否された場合によく発生します。まずポート番号に誤りがないことを確認し、そのポートのサービス状態を自分のサービス提供元に問い合わせてください。
エラー：no such host
原因と対処：サーバーのドメイン名を必要な形で名前解決できていません。ドメイン名の入力と現在のネットワークでの名前解決状況を確認してください。パスワードを先に変更したり、ネット上で見つけたIPアドレスを元のドメイン名の代わりに使ったりしないでください。
エラー：certificate has expired or is not yet valid
原因と対処：証明書の有効期間と端末の現在時刻が一致していません。まずシステム時刻の自動設定を有効にしてください。時刻が正しいのに解決しない場合は、証明書の有効期間を自分のサービス提供元に確認してください。
具体的なエラーがなく、「タイムアウト」とだけ表示される場合は、まずテスト条件を補足してください。すぐに認証エラーと断定することはできません。認証失敗、TLSハンドシェイク失敗、接続先から応答がない状態は、簡略化されたステータス表示では似て見えることがありますが、対処方法はそれぞれ異なります。
5. システム時刻と証明書の検証条件を確認する
システム時刻があらゆるタイムアウトの共通原因というわけではありませんが、TLSや認証に関係する接続がまとめて失敗する場合は確認する価値があります。証明書には有効期間の開始日時と終了日時があり、端末の時計が実際の時刻から大きくずれていると検証に失敗します。プロトコルによっては、認証の仕組みでも時刻が使われます。タイムゾーンの変更は表示方法を変えるだけで、端末の時計を正しく調整する代わりにはなりません。
- iPhone / iPad：システムの「設定 → 一般 → 日付と時刻」を開き、「自動設定」をオンにします。項目を変更できない場合は、デバイス管理やシステム制限を確認してください。Shadowrocketの設定を何度も変更する必要はありません。
- Mac：「システム設定 → 一般 → 日付と時刻」で日付と時刻の自動設定を確認し、端末が同期できることを確かめてください。
- Windows：「設定 → 時刻と言語 → 日付と時刻」で時刻の自動設定を確認し、システムの同期機能を実行してください。
- Android / Linux：システムの日付と時刻の設定で、ネットワーク時刻または時刻同期サービスを確認してください。メニュー名は端末やデスクトップ環境によって異なります。
時刻を調整したらShadowrocketに戻り、いったん切断してから再接続し、同じテストをもう一度行います。時刻が正しいのに証明書エラーが続く場合は、Server Nameが証明書と一致しているか、証明書チェーンが有効かを確認してください。証明書の有効期間に合わせて端末の日付を意図的に変更しないでください。他のアプリに影響するうえ、接続先の証明書の問題も解決できません。
ポイント：時刻を確認してから証明書を調べる
自動時刻が正常で、再接続しても証明書エラーが繰り返される場合は、エラーの原文と発生時刻を自分のサービス提供元に伝えて確認してください。証明書の検証設定は維持し、検証要件を下げた状態で使い続けないでください。
6. ノードが使えるのにページが開けない場合はGlobal Routingとルールを確認する
ノードのテストが正常に戻ってもWebページを開けない場合は、実際の通信経路を確認します。Home → Global Routingで現在のモードを確認してください。Proxyは通信をプロキシ経由で処理し、Directは直接接続します。Configは有効な設定内のルールに従い、Sceneは設定済みのシーンに従って処理します。ノードを選択していても、すべての接続が必ずそのノードを経由するとは限りません。
元の設定を記録したうえで、一時的にProxyにして比較できます。Proxyでは対象ページを開けるのにConfigでは失敗する場合は、ノードの認証情報を変更し続けるのではなく、有効なConfig、該当したルール、適用されるポリシーを確認してください。テスト後は元のモードに戻し、普段の使い方と異なる設定を長期間残さないようにしましょう。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY上記はルールの照合方法を説明するための例であり、現在の設定をそのまま置き換えることを推奨するものではありません。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致し、IP-CIDRはIPアドレスの範囲に一致します。ルールは通常、上から順に照合され、FINALはそれ以前のルールに一致しなかった接続を処理します。GEOIPはIPアドレスの地理情報データベースを基に判定するもので、ドメインの末尾による照合とは異なります。
- Configで、設定ファイルを開いただけではなく、意図したConfigが現在有効になっていることを確認してください。
- 対象のドメインが、先にDIRECT、拒否ポリシー、または意図と異なるポリシーグループに一致していないか確認してください。
- ドメイン名でのアクセスだけが失敗し、アドレスへの接続は可能な場合は、DNSを確認してください。IPアドレスへのアクセスとドメイン名でのアクセスは、TLSのテスト条件もまったく同じではありません。
- 端末で別のVPN接続も動作している場合は、切り分け中にいったん停止し、システムのネットワーク状態による影響を減らしてください。
7. よくある質問と切り分け記録のまとめ方
遅延テストの数値は出るのに、Webページが開けないのはなぜですか？
まず、遅延テストがポートの確認だけを行っていないか確認します。Homeに戻ってGlobal Routingを確認し、現在のモードを記録してからProxyでアクセスを比較してください。それでも失敗する場合は、認証、TLS、通信方式の項目を確認します。ポートに到達できても、プロキシ接続全体のテストにはなりません。
モバイルネットワークに切り替えると使える場合、設定を再インポートすべきですか？
まず元の設定を削除しないでください。同じノードを2種類のネットワークでそれぞれ3回テストし、ネットワークの種類を記録します。結果に安定した差がある場合は、Wi-Fiのログイン状態、名前解決、UDPの疎通状況を確認してください。同じ設定を再インポートしても、接続ネットワークによる違いの原因はわからないことがほとんどです。
サブスクリプションの更新もタイムアウトします。すべてのノードが使えなくなったのでしょうか？
必ずしもそうとは限りません。サブスクリプションの取得とノードへの接続は、別々の通信経路を使います。まず自分のサービス提供元に、登録済みのサブスクリプションURLが有効か確認し、更新が成功したかをチェックしてください。ノードをすべて削除するのは避けましょう。エラー記録を共有する際は、URL内のtokenなどの認証情報を隠してください。
一通り確認しました。どの情報を伝えればよいですか？
プロトコルの種類、OSのプラットフォーム、エラー発生時刻、接続ネットワーク、テスト方法、3回分の結果、個人情報を伏せたエラーの原文を伝え、ネットワーク切り替え後の結果も説明してください。パスワード、秘密鍵、サブスクリプションURL全体、認証tokenを公開スクリーンショットや掲示板に載せないでください。
再インストールやプラットフォームごとの入手方法を確認する場合は、当サイトのダウンロードページをご覧ください。iPhone / iPad版はApp Storeから入手できます。開発者はShadow Launch Technology Limitedです。システム要件はApp Storeの掲載内容をご確認ください。Mac版はAppleシリコン用とIntel用があり、Windows、Android、Linux版もあります。パラメーターやネットワークの確認を再インストールで代用せず、操作前にバックアップしてください。