利用中のサービスとサブスクリプションがあり、Shadowrocketでノードがタイムアウトする、または接続後にアクセスできない方を対象にしています。同じノードでテストを繰り返し、ネットワークを切り替えて比較したうえで、アドレス、ポート、認証情報、通信設定を順に確認し、最後にシステム時刻とサブスクリプションの状態を調べます。問題の発生箇所を特定することが目的であり、すべてをノードの停止と決めつけないことが大切です。
1. 遅延テストのタイムアウトと実際の接続失敗を区別する
Shadowrocketの遅延テスト結果と、Webサイトへのアクセス結果は別の指標です。テストがタイムアウトした場合、そのテストが制限時間内に完了しなかったことを示しますが、それだけでアカウントの無効化や、すべてのWebサイトへのアクセス不可が確定するわけではありません。反対に、ミリ秒の数値が表示されても、そのテストが完了したというだけで、後続の認証、TLSハンドシェイク、目的のサイトへのアクセスまで成功するとは限りません。
まずHomeで選択中のノードを確認し、Connectivity Testを実行します。テスト方法を記録し、比較時は同じ方法を使ってください。途中で方法を変えると、結果を直接比較できません。TCP接続テストと、プロキシ経由で目的のサイトにアクセスするテストでは確認できる段階が異なります。特に、TCPテストだけでUDPを使う通信も利用可能だと判断することはできません。
| 確認できた現象 | 現時点で判断できること | 次の手順 |
|---|---|---|
| 同じノードで続けてテストしてもタイムアウトする | テスト経路が完了していないが、原因はまだ特定できない | 設定を変えずにWi-Fiとモバイル通信を切り替えて比較する |
| テストでは数値が表示されるが、Webサイトにアクセスできない | テストが完了しても、実際のリクエストが成功したとは限らない | 認証、TLS、Global Routing、DNSを確認する |
| 特定のノードだけ失敗する | そのノードまたは設定に原因がある可能性が高い | 手元にある別のノードと比較する |
| 同じネットワークですべて失敗する | ネットワークや設定に共通の原因がある可能性がある | まずローカルネットワークを確認し、別のネットワークでもう一度テストする |
特定のミリ秒数を一律の合格基準にしないでください。遅延は利用中のネットワーク、サーバーの場所、テスト先によって変わります。異なる環境の数値を比べるより、「同じノード・同じテスト方法・異なるネットワーク」での結果を記録すると、原因を絞り込みやすくなります。
2. 再現可能なテスト記録を5ステップで作る
一度に変更する条件は1つだけにしてください。サブスクリプションの更新、プロトコルの切り替え、DNSの変更、端末の再起動をまとめて行うと、アクセスが復旧してもどの操作が有効だったのか分からなくなります。まず現在の設定を残し、調査中に使用可能な設定を上書きしないようにします。記録は端末内のメモで十分です。設定全体を公開する必要はありません。
-
ネットワークを確認する
Homeの接続スイッチを一時的にオフにし、現在のWi-Fiまたはモバイル通信で、普段直接アクセスできるWebサイトを開けるか確認します。公共Wi-Fiでログインが必要な場合は、先にネットワーク認証を済ませてからテストしてください。
-
ノードを固定する
Homeで手元にあるノードを1つ選び、Connectivity Testを同じ方法で3回実行します。3回ともタイムアウトするのか、ときどき成功するのか、毎回数値が返るのかを記録してください。この3回の結果を長期的な稼働率として扱わないでください。
-
ネットワークを切り替える
ノードと設定は変えず、iPhoneのシステム設定でWi-Fiとモバイル通信を切り替えて、同じテストを繰り返します。特定のネットワークだけで失敗する場合は、そのネットワークのアクセス制限やUDPの到達性を優先して確認してください。
-
実際にアクセスする
Homeの接続スイッチをオンにし、選択中のノードを確認してから同じアクセス先を開きます。ルールの影響を一時的に切り分ける場合は、Global RoutingをProxyにして比較テストを行います。テスト後は、普段使用しているConfigに戻してください。
-
自動接続を切り分ける
手動で切断しても接続が自動的に再開する場合は、Settings → On Demandを確認します。現在の設定を記録したうえでOn Demandを一時的にオフにし、手動接続のテストを繰り返してください。原因を特定した後、普段の使い方に合わせて設定を戻します。
まとめ：ネットワークを切り替えて障害が変わるか確認する
同じノードがWi-Fiではタイムアウトし、モバイル通信に切り替えるとテストを完了できる場合は、ノードの設定をそのままにしてWi-Fi側の通信経路を調べます。すぐに設定をすべて作り直したり、認証情報を変更したりしないでください。
3. アドレス、ポート、プロトコル固有の設定を確認する
Homeで該当ノードの編集画面を開き、利用中のサービス提供元から案内された最新の設定と照らし合わせます。まずType、次にサーバーアドレスとポート、最後に認証情報と通信オプションを確認してください。サーバーアドレス欄にWebページのパスを含めないでください。ポートはサーバー側の待ち受け設定と一致している必要があります。ポート番号が443でも、プロトコルが必ずTLSを使うとは限らず、設定が正しいことの証明にもなりません。
たとえば、サーバー側でexample.com:443が指定されている場合、アドレスはexample.com、ポートは443になっているか確認します。速度を試すために、8443へ勝手に変更しないでください。ここに記載したドメインとポートは形式の説明用であり、実際の接続には使えません。認証情報に余分な空白がある、文字が欠けている、大文字と小文字が異なるといった点も、接続失敗の原因になります。
| Type | 重点的に確認する項目 | 間違えやすい点 |
|---|---|---|
| Shadowsocks | サーバーアドレス、ポート、暗号化方式、パスワード | パスワードが正しくても、暗号化方式が異なれば正常に通信できない |
| VMess | UUID、暗号化設定、通信方式、TLS関連の設定 | 通信パスやHostがサーバーアドレスと同じとは限らない |
| VLESS | UUID、通信方式、サーバー指定のTLSまたはその他のセキュリティ設定 | アドレスとUUIDだけでは、ほかの設定を判断できない |
| Trojan | パスワード、サーバーポート、TLS server name | 接続先アドレスと証明書に対応するドメイン名が異なる場合がある |
| Hysteria2 | 認証、TLS server name、UDPの到達性、サーバー指定のオプション | TCPテストの成功だけでは、QUIC通信が使えるとは判断できない |
| WireGuard | ローカルの秘密鍵、ピアの公開鍵、Endpoint、アドレス、Allowed IPs | 接続中の表示があっても、正常なハンドシェイクやデータ通信が完了したとは限らない |
TLSを使う設定では、接続先アドレス、server name、証明書の要件をあわせて確認します。ドメイン名をIPアドレスに置き換えると、証明書名の照合やアクセス経路が変わる可能性があります。証明書の検証を無効にして設定ミスを補わないでください。証明書の期限が切れている場合は、サーバーの管理者に対応を依頼します。
4. エラーメッセージから失敗した段階を特定する
タイムアウトは現象の説明にすぎません。エラーメッセージの原文があれば、接続のどの段階で失敗したかを切り分けやすくなります。アプリ内の該当リクエストの接続記録やログを確認し、エラー文と発生時刻を記録してください。以下は低レベルの接続記録に表示されることがあるエラー例です。すべての不具合で決まったポップアップが表示されるわけではありません。同じ文言が見つからない場合は、実際の記録を確認してください。
エラー：i/o timeout
原因：ネットワークの読み書き処理が待機時間を超えています。この文言だけでは、ローカルネットワーク、サーバー、アクセス先のどこに問題があるか特定できません。
対処：まず同じノードでネットワークを切り替えて比較し、エラー前後のアドレスと接続段階を確認して原因を絞ります。待機時間を延ばすだけで不具合を覆い隠さないでください。
エラー：connection refused
原因：接続先のポートから明示的に拒否されています。ポートが待ち受けていない、サービスが停止している、ネットワーク機器が接続を拒否している場合などに発生します。
対処：記録にある接続先がプロキシサーバーかWebサイトかを確認します。プロキシサーバーの場合は、利用中のサービス提供元にアドレス、ポート、サービスの稼働状況を確認してください。
エラー：no such host
原因：名前解決でホスト名に対応するアドレスを取得できていません。ドメインの入力ミスやDNS名前解決に問題がある可能性があります。
対処：アドレスに空白、プロトコルの接頭辞、パスが混ざっていないか確認してから、別のネットワークでもう一度テストします。ドメインを確認する前にパスワードを何度も変更しないでください。
エラー：certificate has expired or is not yet valid
原因：証明書の有効期間と端末の時刻が一致していません。システム時刻の誤り、またはサーバー証明書の更新が必要な可能性があります。
対処：まずiPhoneの日付と時刻を正しく合わせてから再接続します。時刻が正しいのにエラーが続く場合は、サーバーの管理者に連絡してください。証明書の検証は無効にしないでください。
記録を共有するときは、パスワード、UUID、秘密鍵、サブスクリプションのtokenを隠してください。プロトコルの種類、マスキングしたサーバーアドレス、ポート、テスト時刻、エラーの原文は残せます。サブスクリプションの完全なURLはアクセス権限を含む場合があるため、公開の問い合わせ用スクリーンショットに載せないでください。
5. 最後にシステム時刻とサブスクリプションの更新を確認する
iPhoneの「設定 → 一般 → 日付と時刻」で「自動設定」を確認します。端末の時刻が大きくずれている場合は、正しい時刻に戻してから接続し直してください。時刻はTLS証明書の有効期間の判定に使われ、時刻検証を行う認証にも影響する場合があります。日付を意図的に前後させても解決にはなりません。
サブスクリプションの更新とノード接続は、別々の通信経路を使います。前者は設定情報を取得し、後者は保存済みの設定でサーバーに接続します。そのため、更新に失敗しても、ローカルに保存済みのノードがすべてすぐに使えなくなるわけではありません。更新に成功しても、すべてのノードに接続できるとは限りません。更新後は目的のノードを選び直し、設定にどのような変更があったか確認してください。
- サブスクリプションの接続先を確認：Homeで登録済みのSubscribe項目を開き、自分の有効なリンクが設定されているか確認します。形式の例は
https://example.com/sub?token=xxxxです。このアドレスは構造を説明するための例です。 - 更新を1回実行：Homeで登録済みのサブスクリプションを下に引いて更新し、結果が表示されたらノード一覧を確認します。まずエラー情報を記録し、状況を複雑にしないよう連続で更新しないでください。
- 更新経路を確認：サブスクリプションのURLへのアクセスにプロキシが必要で、利用可能な接続がすでにある場合は、Settings → Subscribe → Update via Proxyを確認します。この設定には動作するプロキシ経路が必要です。利用できないノードを自動的に復旧させるものではありません。
- サービスの状態を確認：利用中のサービス提供元に、サブスクリプションの有効性、アカウントの利用状況、アドレスや認証情報に変更がないか問い合わせてください。クライアントの購入状況とサービス提供元のアカウント状態は、それぞれ別に確認します。
まとめ：更新後は接続先を1つだけ再テストする
失敗したノードを1つ選び、更新前後でアドレス、ポート、認証情報に変更があったか比較してから、同じネットワークで同じテストを繰り返します。設定に変更がなく、タイムアウトも続く場合は、ネットワーク経路とサーバーの状態を重点的に調べてください。
6. テストに成功してもWebサイトを開けない場合はルーティングを確認する
ノードのテストが完了しても実際のアクセスに失敗する場合は、リクエストが本当にそのノードを経由しているか確認します。HomeでGlobal Routingを確認してください。Configは設定に従ってリクエストを処理し、Proxyはプロキシ経路との比較、Directは直接接続との比較に使います。Sceneは該当するシーン設定とあわせて判断します。接続スイッチがオンというだけで、すべての通信がプロキシ経由だと決めつけないでください。
Configを使う場合は、無効なファイルではなく、現在有効な設定をConfigで確認します。DOMAIN-SUFFIXはドメインの末尾、IP-CIDRはIPアドレスの範囲、GEOIPはIPの地理データベースに基づいて判定し、FINALはそれ以前のルールに一致しない場合に適用されます。DIRECTに一致したリクエストは、ノードを選択していても自動的にプロキシ経由にはなりません。REJECTに一致したリクエストは拒否されます。
- Proxyではアクセスできるが、Configでは失敗する：設定内のルールの順序、ポリシーの参照先、DNSの結果を優先して確認し、すぐにノードを作り直さないでください。
- 特定のWebサイトだけ失敗する：そのリクエストに適用されたルールとアクセス先からの応答を確認します。1つのサイトにアクセスできないだけで、プロキシ経路全体が使えないとは判断できません。
- すべてのアクセス先で失敗する：プロトコル設定と接続記録に戻り、認証、TLS、送信接続のどの段階で止まっているか確認します。
比較が終わったら、普段使っているルーティングモードに戻してください。Proxyは今回の切り分けに使う方法であり、すべてのルールの問題を解決する代わりにはなりません。操作手順全体を確認する場合は、Global Routingの使い方を参照してください。
7. ノードのタイムアウトに関するよくある質問
ノードが1つだけタイムアウトします。アプリを再インストールすべきですか？
まずは再インストールしないでください。Homeで手元にある別のノードを選び、同じテストを行います。ほかのノードが正常なら、失敗したノードのアドレス、ポート、認証情報、サーバーの状態を優先して確認します。再インストールしても、サーバー側でポートが待ち受けていない問題は解決せず、端末内の調査記録を失うおそれもあります。
遅延が表示されるのに、接続後もWebサイトを開けないのはなぜですか？
まずテスト方法でどの接続段階まで確認できるかを調べ、Global Routing → Proxyにして実際のアクセスを比較します。それでも失敗する場合は、認証やTLSのエラーを確認してください。Configだけで失敗する場合は、遅延の数値だけに注目せず、現在有効な設定のルールとポリシーを確認します。
サブスクリプションの更新がタイムアウトしました。以前のノードも使えなくなったのでしょうか？
必ずしもそうとは限りません。まず端末に保存済みのノードをテストし、その後サブスクリプションのURLへのアクセス経路を個別に確認してください。プロキシ経路が必要な更新リクエストには、利用可能なプロキシ接続がある場合に限り、Settings → Subscribe → Update via Proxyが役立つことがあります。リンクが有効かどうかも、利用中のサービス提供元に確認してください。
サービス提供元に問い合わせる際、どの情報を用意すればよいですか？
発生時刻、使用したWi-Fiまたはモバイル通信、プロトコルの種類、マスキングしたアドレス、ポート、3回のテスト結果を伝え、エラーの原文を添えてください。ネットワークを切り替えると復旧するか、ほかの手元のノードは正常かも説明します。秘密鍵、パスワード全体、tokenを含むサブスクリプションURLは送らないでください。