Shadowrocketでタイムアウトが表示されても、パスワードの誤りや接続先サービスの停止とは限りません。ご自身でサービス事業者と契約し、サブスクリプションを利用している方を対象に、iPhone、iPad、Mac（Appleシリコン・Intel）、Windows、Android、Linuxでの確認方法を説明します。画面操作はiPhone／iPadを例にしています。まず元の設定とテスト結果を保存し、テスト方法、プロトコル設定、システム時刻、ネットワークの出口を順番に確認してください。一度に変更する項目は一つに絞ります。
1. 遅延テストの失敗と実際の接続失敗を見分ける
遅延の数値は、その時点のネットワークで特定のテストが完了したことを示すだけで、すべてのアプリが正常に通信できる証拠にはなりません。TCPテストでは主にポートへの接続を確認します。プロキシ経由のHTTPテストでは、プロトコルのハンドシェイクやテスト先の応答も関係します。ICMP Pingは接続先や途中のネットワークで破棄されることがあります。それぞれ測定対象が異なるため、一つの結果を別のテストの結果と同じように扱わないでください。
Homeで選択中の項目を確認し、テスト方法を記録したうえで、同じ項目を3回続けてテストします。成功が1回だけ、または数値の変動が大きい場合は、結果を記録して、すぐにプロトコルを変更しないでください。次に接続を有効にし、普段から安定して利用できる、自分にアクセス権のあるHTTPSページをブラウザーで開いて、特定の接続先だけ失敗するか確認します。項目の切り替え、DNSの変更、ネットワークの変更を同時に行うと、何が改善につながったのか判断できません。
| 確認できた現象 | そこから判断できること | 次に行うこと |
|---|---|---|
| TCPテストは成功するが、実際のアクセスは失敗する | ポートに接続できても、認証、TLS、接続先へのリクエストが失敗する可能性があります | プロトコルの設定項目を確認し、リクエストが選択中の項目を経由しているか調べます |
| ICMPは応答しないが、実際のアクセスは正常 | ICMPの結果だけでは、プロキシプロトコルが利用できないとは判断できません | 設定は変更せず、実際のアクセスとプロトコルテストの結果を基準にします |
| 同じサブスクリプションの全項目でタイムアウトする | 共通の原因が考えられます。すべてのサーバーの障害とは限りません | ネットワーク、サブスクリプションの状態、ドメイン名の解決、端末の時刻を確認します |
| 一つの項目だけ繰り返し失敗する | その項目、または接続先サービスに原因がある可能性が高くなります | 該当項目のアドレス、ポート、サービスの稼働状況を確認します |
ポイント：テスト対象を固定する
一つの項目、一つのテスト方法、一つの接続先ページを選び、基準となる結果を記録します。基準を固定してからネットワークを切り替えたり設定を修正したりすれば、変更前後を比較できます。
2. アドレス、ポート、サブスクリプションの内容を順に確認する
まず基本的な接続情報から確認します。アドレスの入力漏れや、別サービス用の待受ポートの指定は、タイムアウトの原因になります。ポート番号はプロトコル名だけで決まるものではありません。TLSを使うからといってポートが必ず443になるわけではなく、443が一般的だからと元のポートを変更するのも避けてください。
-
元の設定を保存する
Homeで現在の項目名、Type、エラーが発生した時刻を記録します。Configを変更する前に、元の設定を複製して保存してください。パスワード、UUID、秘密鍵を含む情報は自分の端末だけに保存し、公開の掲示板などには投稿しないでください。
-
アドレスを確認する
Homeから現在の項目の編集画面を開き、Addressの値をサービス事業者から提供された元の情報と一文字ずつ照合します。Addressには通常、ドメイン名またはIPアドレスを入力します。ウェブページのURL全体やパス、前後の空白を含めて貼り付けないでください。
-
ポートを確認する
Portが接続先の待受ポートと一致しているか確認します。有効なポート番号は1～65535です。たとえば接続先で8443が指定されている場合、ブラウザーのHTTPSでよく使われるという理由で443に変更してはいけません。ポートに接続できても、そこで正しいプロキシサービスが動作しているとは限りません。
-
認証情報を確認する
元の情報と照らし合わせ、Password、UUID、または該当するキーの値を確認します。コピー時に改行や前後の空白が入っていないかも確認してください。サブスクリプションURLのアクセストークンをノードのパスワード欄に入力しないでください。用途が異なります。
-
更新して再テストする
サブスクリプションから追加した項目の場合は、Homeで該当するサブスクリプションを更新するか、画面を下に引いて更新します。処理の完了後、項目を選び直してください。更新によってサブスクリプション由来の設定が上書きされることがあります。一時的な変更は事前に記録し、更新に失敗しても、まだ使える古い設定を削除しないでください。
サブスクリプションの更新が成功したことは、内容を取得して解析できたことを示すだけで、すべてのアドレスが稼働中という意味ではありません。反対に、更新に失敗しても、保存済みの項目が必ず使えなくなるわけではありません。サービス事業者がポート、認証情報、通信設定を変更すると、古い項目が一覧に残っていても、現在の設定に合わないことがあります。その場合は、古い内容を何度も読み込み直すのではなく、契約先のサービス事業者に変更内容を確認してください。
3. プロトコルのハンドシェイクと通信設定を確認する
AddressとPortが正しいことを確認したら、Typeと関連項目を確認します。プロトコルは名称を変えるだけで互換性が得られるものではありません。同じサーバーアドレスでも、異なるサービス設定が使われている場合があります。次の表は確認箇所の目安です。表示される項目はプロトコルや設定によって異なり、各行の設定をすべての項目にそのまま適用できるわけではありません。
| プロトコル | 主な確認項目 | 判断時の注意点 |
|---|---|---|
| Shadowsocks | 暗号化方式、Password、Address、Port | Passwordと暗号化方式の両方が一致している必要があります。ポートに接続できても、復号に成功したとは限りません |
| VMess | UUID、暗号化設定、通信方式、サービス事業者が指定する追加パラメーター | システム時刻が大きくずれていると認証に影響することがあります。UUIDだけでなく時刻も確認してください |
| VLESS | UUID、通信方式、TLS、サービス事業者が指定するセキュリティ設定 | UUIDをコピーしただけでは、利用可能な設定をすべて複製したことにはなりません |
| Trojan | Password、TLS、Server Name、証明書の信頼状態 | 接続先のIPアドレスとTLS検証に使うドメイン名が異なる場合があります。元の設定どおりに入力してください |
| Hysteria2 | 認証情報、TLS、サービス事業者が指定する設定、UDPの到達性 | QUICベースのプロトコルです。TCPテストに成功しても、UDP通信が利用できるとは限りません |
| WireGuard | ローカル秘密鍵、対向側の公開鍵、Endpoint、トンネルアドレス、Allowed IPs | UDPを使用します。ハンドシェイク成功後も、ルーティングとDNSを確認してください |
WebSocketで通信する場合は、PathとHostを確認します。Pathのスラッシュ、大文字・小文字、末尾の文字が異なると、リクエストが正しくないサービスパスに送られることがあります。HostはHTTPリクエストに使われ、Server NameはTLSハンドシェイクでサーバー名として使われます。任意に入れ替えられる同じ項目ではありません。元の設定で同じ値が指定されている場合に限り、同じ値を入力してください。
- TLSのサーバー名：AddressにIPアドレスを指定し、証明書がドメイン名に対して発行されている場合は、サービス事業者指定のServer Nameをそのまま使います。すべての名前の項目をIPアドレスに置き換えないでください。
- 通信方式：接続先がWebSocketを要求している場合、通常のTCPに変更しても自動的に互換性が得られるわけではありません。gRPCなどの通信方式も、対応するサーバー設定が必要です。
- 証明書の検証：証明書エラーが発生した場合は、まず時刻、ドメイン名、証明書の有効期限を確認してください。証明書の検証を常に無効にする方法で解決しようとしないでください。
4. エラーの種類から原因を探り、すべてをタイムアウトと見なさない
該当するリクエストのログや診断結果に、エラーの全文を記録してください。以下はよく見られる低レベルのエラー例です。プラットフォームによって表示される文言は異なることがあります。「接続に失敗しました」とだけ表示される場合は、発生した段階も踏まえて判断してください。一つの語句だけを見て、原因が端末側か接続先側か決めつけないでください。
エラー：i/o timeout
原因と対処：処理が制限時間内に完了しなかったことを示します。名前解決、接続、ハンドシェイクのいずれかで発生する可能性があります。前後のログから接続先アドレスと発生段階を確認し、同じ項目でネットワークを切り替えて比較してください。このエラーだけでパスワードの誤りとは判断できません。
エラー：connection refused
原因と対処：接続要求が明示的に拒否されています。ポートでサービスが待ち受けていない、または接続が拒否されている場合によく発生します。Portを確認し、そのポートの待受状態を契約先のサービス事業者に確認してください。待ち時間を長くしても解決しません。
エラー：no such host
原因と対処：ドメイン名の解決に失敗しています。入力ミス、DNSの設定、ドメインのレコードなどが関係している可能性があります。まずAddressを一文字ずつ確認し、次に現在のネットワークのDNSを確認してください。認証エラーと決めつけないでください。
エラー：x509: certificate has expired or is not yet valid
原因と対処：証明書の有効期間と端末の現在時刻が一致していません。まず端末の日付、時刻、タイムゾーンを修正してください。時刻が正しいのにエラーが続く場合は、サーバーの管理者に証明書の有効期間と証明書チェーンを確認してもらいます。
ログで接続確立後に接続先サイトのHTTPエラーが発生している場合は、プロキシ経路の問題と接続先からの応答を区別してください。特定のページで403や429が返されても、接続先サイトのアクセス制限やリクエスト頻度の制限が原因の可能性があり、ノードのポートに接続できないことを意味するとは限りません。応答が発生した時刻と接続先のドメインを記録し、ページ側のアクセス拒否をクライアント全体の障害と誤認しないようにしてください。
5. システム時刻を合わせてからネットワークの出口を確認する
TLSは証明書の有効期間を確認し、一部の認証方式も時刻の範囲に依存します。日付が過去または未来にずれている場合や、端末が長期間オフラインで時刻が同期されていない場合、設定が正しくてもハンドシェイクに失敗することがあります。iPhone／iPadでは、システムのSettings → General → Date & TimeでSet Automaticallyを確認してください。他のプラットフォームでは、システムの日付と時刻の設定で自動同期を有効にし、表示されている時刻が正しいことを確認してから再テストします。
- まず直接接続で基準を確認：Shadowrocketの接続を一時停止し、ブラウザーで現在のWi-Fiまたはモバイルネットワークから通常のページにアクセスできるか確認します。ホテルや学校など、ウェブページでの認証が必要なネットワークでは、先に認証を済ませてください。
- ネットワークを切り替えて比較：同じ端末、同じ項目、同じ接続先で、Wi-Fiとモバイルネットワークをそれぞれテストします。一方のネットワークだけで失敗する場合は、すべてのプロトコル設定を変更するのではなく、そのネットワークの出口側の制限を優先して確認してください。
- UDPの制限を確認：Hysteria2とWireGuardはUDPを使用します。特定のネットワークでこれらが失敗し、すでに設定済みのTCP系接続が使える場合は、UDP経路を確認する手がかりになります。ただし、プロトコルの実装に問題があるとはまだ断定できません。
- トンネルの競合を確認：ほかのVPNやネットワークフィルターが接続を処理していないか確認し、競合する設定を一時的に無効にして再テストします。管理対象の端末では管理者のポリシーに従い、組織の制限を回避しないでください。
接続を切っても自動的に再接続する場合は、ShadowrocketのSettings → On Demandを確認し、元の設定を記録してから自動接続の条件を一時的に無効にします。On Demandは接続を開始するタイミングを制御する機能であり、アドレスやパスワード、接続先サービスの状態を修正するものではありません。トラブル対応後は元の用途に応じて設定を戻してください。自動接続を常に無効にすることを一般的な解決策にしないでください。
DNS変更時の注意：名前解決に失敗した場合や明らかに誤った結果が返る場合に限り、DNSを重点的に確認します。すべてのDNS設定を一度に置き換えたり、ドメイン名を安易にIPアドレスへ変更したりしないでください。TLSのサーバー名検証に影響し、元の問題を再現しにくくなることがあります。
6. 遅延は正常でもページが開かない場合はGlobal RoutingとRuleを確認する
ノードテストとアプリからのリクエストでは、処理経路が異なることがあります。Home → Global Routingを開き、まず現在の選択内容を記録してください。Proxyはプロキシ経由のルーティング、Directは直接接続、Configは現在の設定に基づく処理、Sceneは設定済みのシーンに基づく処理です。これらは接続プロトコルの種類ではありません。名称だけでは、現在のページがどの出口を通ったか判断できないため、マッチしたルールと実際に使用された項目も確認してください。
- 短時間で比較：ネットワークへの影響を理解したうえで、ProxyとConfigを切り替えてアクセス結果を比較し、テスト後は元の設定に戻します。Proxyでは使えてConfigでは使えない場合は、認証情報を変更する前にルールとポリシーを確認してください。
- 確認する順番：Configで現在有効な設定を開き、Ruleのマッチ順を上から確認します。先にあるルールが適用されると、通常、そのリクエストの振り分けでは後続のルールは確認されません。
- 確認する対象：DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIP地理データベースに基づく照合に使われます。FINALはそれまでのルールに一致しなかったリクエストを処理します。照合対象が異なるため、すべての接続を一つのルールだけで判断することはできません。
- ポリシーを確認：一致したPROXY、DIRECT、REJECT、またはカスタムポリシーグループが、意図した動作を指しているか確認します。グループ名が存在していても、グループ内で現在選択されている項目が利用可能とは限りません。
以下はルールの順序と構文の例であり、既存のConfig全体を置き換えるための推奨設定ではありません。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,PROXYポイント：障害が発生した段階に応じて設定を変更する
ポートに接続できない場合は、まずアドレスとネットワークを確認します。ハンドシェイクに失敗する場合は、認証、TLS、時刻を確認してください。ハンドシェイクと実際のプロキシ経由のアクセスが成功した場合に限り、特定のリクエストが誤ったポリシーに振り分けられていないかを重点的に調べます。
7. 再現できる記録を残し、契約先のサービス事業者に問い合わせる
ここまで確認しても解決しない場合は、「すべてタイムアウトする」とだけ伝えるより、原因を特定できる記録を添えて問い合わせると効果的です。テスト結果と推測を区別してください。たとえば「同じ項目がWi-Fiでは失敗し、モバイルネットワークでは成功する」は再確認できる現象ですが、「サーバーが制限された」は検証が必要な推測です。未テストの内容を結論として書かず、記録をそろえるために認証情報を公開することも避けてください。
- 端末と環境：端末のプラットフォーム、現在のネットワークの種類、ネットワーク認証や組織管理のポリシーの有無。
- 再現時刻：問題が発生した日時とタイムゾーン、システム時刻が同期されているか。接続先のログとの照合に役立ちます。
- 設定の範囲：プロトコルのType、通信方式、TLSの使用有無、一つの項目だけが失敗するのか同じグループ全体が失敗するのか。
- 比較結果：テスト方法、3回連続の結果、ネットワークを切り替えた結果、Global Routingの選択内容。
- エラーの抜粋：発生段階の特定に必要な情報を残し、Password、UUID、秘密鍵、サブスクリプションのトークン、個人情報は伏せてください。
当サイトではノードやサブスクリプションの提供、販売、推奨は行っていません。接続先の稼働状況、認証情報の有効性、接続先の設定については、ご自身が利用しているサービス事業者にご確認ください。クライアントの入手と接続サービスは別のものです。設定を確認せずに何度もインストールし直しても、問題の解決にはつながりません。インストールや端末の変更が必要な場合は、当サイトの全プラットフォーム対応ダウンロードガイドで、端末に合った方法を確認してください。