Shadowrocketに手元の設定を追加済みで、遅延テストがタイムアウトする、または接続をオンにしても通信できない場合の確認手順です。テストの意味、ローカルネットワーク、プロトコルの各項目、システム時刻、TLSの順に確認し、一度に変更する条件は一つだけにします。最後に同じリクエストを再テストし、サーバーに到達できないのか、設定が一致していないのか、ルールに一致していないのかを切り分けます。
1. 遅延テストと実際の接続を区別する
「タイムアウト」は、処理のいずれかが制限時間内に完了しなかったことを示すだけで、パスワードの誤りやサーバー停止を直接意味するものではありません。遅延テストの方式によって、確認する経路も異なります。TCPハンドシェイクに成功しても、その時点で宛先のアドレスとポートへTCP接続できたことしか分かりません。プロキシ経由のHTTPリクエストでは、プロトコルのネゴシエーション、接続先サイトへのアクセス、応答の受信も関係します。両者は同じものとして扱えません。
まずHomeで、選択中の設定名、テスト方式、結果を記録します。その後、普段アクセスできるHTTPSページをブラウザで開いて確認します。これは接続状況を調べるための操作で、アカウント情報を入力する必要はありません。一度のテスト結果を恒常的な状態とみなさず、VPNの表示だけを根拠にプロキシ経路が使えると判断しないでください。システムトンネルの確立と、リモート側での認証成功は別の段階です。
| 結果 | 分かること | 次に確認すること |
|---|---|---|
| TCPテストは成功するが、Webページは開かない | ポートへの接続は可能。プロトコル認証やTLSの成功を意味するわけではない | Type、認証情報、TLSの各項目を確認する |
| 遅延テストはタイムアウトするが、Webページは開く | テスト方式、テスト対象、プローブ経路が異なる可能性がある | テスト方式を記録し、同じリクエストを再実行する |
| Wi-Fiでは失敗し、モバイル通信では成功する | 接続ネットワークに関係する問題だが、原因の機器までは特定できない | Wi-Fiのログイン、DNS、ネットワーク制限を確認する |
| 特定のWebサイトだけ開かない | 接続全体が使えないとすぐに判断しない | 該当リクエストのルール判定と接続先からの応答を確認する |
まとめ：実際のアクセス確認も行う
遅延の数値とWebページの表示結果が食い違う場合は、現在の設定を保ったまま、テスト方式と実際のリクエスト結果を記録します。そのうえで失敗した段階を確認してください。すぐにプロトコルを一括で入れ替えたり、すべての設定をリセットしたりしないでください。
2. 6つの手順でテスト条件を固定する
確認中は、既存の設定一つと同じテストページを使います。ネットワークの切り替え、サブスクリプションの更新、ルーティングモードの変更は、いずれも結果に影響する可能性があります。一度に複数の条件を変えると、原因を切り分けにくくなります。以下の手順は、再現可能な基準を作るためのもので、特定のルーティング状態を常時使うことを勧めるものではありません。
-
元の設定を記録する
Homeで選択中の設定と、現在のGlobal Routingの状態を記録します。Settings → On Demandでオンデマンド接続の状態も確認してください。テスト中に自動再接続する場合は、元の条件を記録してから一時的に無効にし、確認後に元へ戻します。
-
ローカルネットワークを確認する
接続を一時的にオフにし、現在のWi-Fiまたはモバイル通信で普段使うページにアクセスできるか確認します。公共Wi-FiでWebログインが必要な場合は、先に認証を済ませてからShadowrocketの接続をオンにします。
-
設定を固定する
Homeに戻り、確認したい設定を選択して、同じ名前の別の項目ではないことを確かめます。テスト中にアドレス、ポート、認証情報が変わるのを避けるため、サブスクリプションを何度も更新するのは控えてください。
-
ルールの影響を切り分ける
Home → Global Routingで一時的にProxyを選び、同じテストページでプロキシ経路を確認します。Proxyはルールの影響を切り分けるための設定で、すべてのページにアクセスできることを保証するものではありません。Directは直接接続するため、選択中のプロキシが使えることの確認にはなりません。
-
ネットワークを切り替える
設定とページは変えず、Wi-Fiとモバイル通信でそれぞれテストします。各ネットワークで3回ずつ試し、成功・タイムアウトと発生時刻を記録してもよいでしょう。これは記録方法の提案であり、あらかじめ決まったテスト結果を示すものではありません。
-
元の状態に戻す
テスト後、Global Routingを元のConfig、Sceneなどの状態に戻し、On Demandの条件も復元します。Proxyでは使えるのにConfigでは使えない場合は、Configの有効な設定とルールを確認してください。
モバイル通信に切り替えて復旧する場合は、すぐにパスワードを変更せず、まず元のWi-Fiを確認します。逆に、どちらのネットワークでも同じ段階で失敗する場合は、アドレス、ポート、認証情報、サーバーの状態など、共通する条件を引き続き確認します。この結果だけで、特定の項目が誤りだとは断定できません。
3. アドレス、ポート、プロトコル設定を確認する
Homeで対象設定の編集画面を開き、サービス提供元から受け取った元の情報と項目ごとに照合します。Typeはクライアントが使うプロトコルを決める項目なので、アドレスが同じという理由だけで変更しないでください。アドレス欄には通常、ホスト名またはIPアドレスを入力します。サブスクリプションURL全体をサーバーアドレスとして入力したり、Webページのパスをホスト名欄に入れたりしないでください。
| 設定項目・プロトコル | 確認する内容 | よくある誤解 |
|---|---|---|
| アドレスとポート | ホスト名のつづり、ポート番号、前後の空白を確認する。元の設定情報に従う | 443はよく使われるポートの例にすぎず、すべてのサービスを443に変更すべきという意味ではない |
| Shadowsocks | 暗号化方式とパスワードがサーバー側の設定と一致しているか確認する。プラグインがある場合はその設定も確認する | ポートに接続できることだけを確認し、暗号化方式の不一致を見落とす |
| VMess / VLESS | UUID、トランスポート方式、設定で使われているTLS、Host、Pathなどの項目を確認する | UUIDを一般的なパスワードとして扱ったり、トランスポート層の設定を見落としたりする |
| Trojan | パスワード、TLS、SNIを確認し、サーバー証明書と設定に一致しているか確かめる | ポートに接続できればTLSとパスワードも正しいと思い込む |
| Hysteria2 | 認証情報、TLS、既存設定の難読化パラメータを確認し、必要なUDP通信がネットワークで許可されているか確かめる | TCPプローブの結果から、QUICベースの接続状態を判断する |
| WireGuard | 鍵、Endpoint、トンネルアドレス、ルーティング範囲を確認し、UDPで到達できるか確かめる | TLS証明書を使わないプロトコルの問題まで、SNIの問題として扱う |
たとえば、元の情報にポートが8443と明記されている場合は、編集画面も8443になっているか確認します。TLSを使うからといって443に変更する必要はありません。同様に、TLSのSNIはハンドシェイクで使うサーバー名、トランスポート層のHostは該当トランスポートのホスト情報です。ある設定で両者が同じでも、すべての設定で一致させる必要があるとは限りません。
- 認証情報をコピーするときは、前後の空白、改行、全角文字に注意し、長い文字列を手入力し直さないようにします。
- 暗号化方式を一つずつ総当たりで試すのは避けてください。まず元の設定項目を入手し、一つずつ照合します。
- サブスクリプションを更新した後は、Homeで現在選択されている項目を確認します。新しく追加された項目や名前が変わった項目が、以前選択していたものとは限りません。
- 問い合わせ時は、パスワード、UUID、秘密鍵、サブスクリプショントークンを隠してください。プロトコルの種類とエラーが発生した段階が分かれば、通常は初期調査を始められます。
4. iPhoneのシステム時刻とTLS証明書を確認する
TLSでは、証明書に記載された名前だけでなく有効期間も検証します。iPhoneの時刻が実際の時刻から大きくずれていると、証明書がまだ有効でない、または期限切れだという判定に影響する場合があります。iPhoneの「設定 → 一般 → 日付と時刻」を開き、「自動設定」と現在の時刻を確認してください。管理ポリシーによって変更できない場合は、先にデバイス管理上の要件を確認します。
時刻を修正したら、接続を確立し直してテストします。それでも証明書エラーが出る場合は、デバイスの時刻、サーバー証明書の期限切れ、SNIと証明書名の不一致を切り分けてください。デバイスの時刻が正しくても、期限切れのサーバー証明書は修復できません。接続先をIPアドレスに変更しても、証明書名の不一致が自動的に解消されるわけではありません。
Allow Insecureで証明書の問題を隠さない
Allow Insecure（安全でない接続を許可）は証明書検証を弱めるため、通常の解決策として使うべきではありません。検証を有効に保ち、SNIと元の設定情報を照合したうえで、サービス提供元にサーバー証明書を確認してもらいます。エラー表示を消すためだけに安易に有効にしないでください。
- 時刻を確認：日付、時刻、タイムゾーンが適切か確認します。特に時刻を手動で変更した場合は注意してください。
- 名前を確認：SNIには既存設定で指定されている名前を使います。
https://を含むURL全体やパスは入力しません。 - 有効期間を確認：デバイスの時刻が正しいのに証明書の期限切れが表示される場合は、エラーの原文を記録してサービス提供元に確認します。
- プロトコルを区別：この項目を確認するのは、実際にTLSを使用する接続だけです。WireGuardの鍵やハンドシェイクの問題は、SNIを変更しても解決しません。
5. ログのエラーから失敗した段階を特定する
「Webページが開かない」という結果でも、名前解決、接続確立、TLSハンドシェイク、認証のいずれで失敗したかは異なります。一度再現したあと、アプリで利用できる診断ログから該当時刻の記録を探し、エラー全文を保存してください。以下はよく見られるエラーの一部です。大文字・小文字、接頭辞、表示場所はプロトコルの実装によって異なることがあり、毎回同じ文言が出るとは限りません。
エラー：i/o timeout
原因と対処：読み書きの処理が制限時間を超えています。この文言だけでは失敗した階層を特定できません。前後のログで宛先アドレスと処理段階を確認し、設定を変えずにWi-Fiとモバイル通信を切り替えて再テストします。
エラー：connection refused
原因と対処：宛先または途中の機器が接続を明示的に拒否しています。ポートで待ち受けていない、またはアクセス制限がある可能性があります。まずポートとプロトコルを確認し、設定が一致していればサービス提供元にそのポートの稼働状態を確認します。
エラー：no such host
原因と対処：名前解決で有効なホストアドレスを取得できていません。ホスト名の入力ミスやDNS応答に問題がある可能性があります。サーバーのホスト名を確認し、別の接続ネットワークでもテストしてください。認証情報はすぐに変更しないでください。
エラー：x509: certificate has expired or is not yet valid
原因と対処：証明書の有効期間と現在時刻が一致していません。まずiPhoneの自動時刻設定を確認し、時刻が正しければサービス提供元にサーバー証明書を確認します。検証を無効にしたまま使い続けないでください。
記録には「どのリクエストが、どのネットワークで、いつ失敗したか」を明記します。赤いタイムアウト画面のスクリーンショットだけでは不十分です。ログに接続が切断されたとしか表示されていなくても、パスワードの誤りとは限りません。サーバー側のポリシー、トランスポート設定の不一致、ネットワークの切断などで接続が早期終了する可能性があるため、前述の設定確認と合わせて判断します。
まとめ：最初に失敗した段階を確認する
同じリクエストで最初に失敗したのがホスト名の名前解決なら、まずアドレスとDNSを確認します。接続がTLSまたは認証の段階まで進んでいる場合に限り、該当する設定項目を確認してください。まだ到達していない段階の設定を何度も変更するのは避けます。
6. 接続復旧後にルールとサブスクリプションを確認する
ProxyではアクセスできるのにConfigに戻すと失敗する場合は、有効な設定のルールとポリシーの宛先を確認します。DOMAIN-SUFFIXはドメインの末尾で照合し、IP-CIDRはIPネットワーク範囲で照合します。GEOIPは地理的なIP条件を使い、FINALは最後のフォールバックを処理します。これらをすべて同じドメイン判定として扱うことはできません。ルールの順序、実際のリクエスト先ドメイン、最終的に適用されたポリシーを合わせて確認してください。
たとえば、手元の設定にあるFINAL,DIRECTは、前のルールに一致しない接続を直接送信することを意味します。ページが開いたからといって、プロキシ経由だとは限りません。反対に、サイトのトップページとリソースのドメインが異なる場合もあり、メインドメインだけにルールを適用しても、すべてのリソースが同じ経路を使うとは限りません。リクエスト記録で実際のドメインと適用ルールを確認してから、Configを変更するか判断します。
遅延テストに数値が出るのに、Webページが開かないのはなぜ？
まずテスト方式を確認してください。TCPで到達できても、プロトコル認証が成功したとは限りません。Homeで選択中の項目とGlobal Routingを確認し、一時的にProxyで再テストしてから、プロトコル設定とTLSログを確認します。テスト後は元の状態に戻してください。
サブスクリプションの更新がタイムアウトしたら、すべての設定が使えなくなったということ？
いいえ。サブスクリプションの更新はサブスクリプションURLへのアクセスで、保存済み設定による接続とは別のリクエストです。Homeでサブスクリプションの項目を確認し、契約中のサブスクリプションが有効か確かめてください。Settings → Subscribe → Update via Proxyの設定が、現在使える経路に合っているかも確認します。プロキシ自体が使えないときに、更新を何度も試さないでください。
Directに切り替えてWebページが開けば、直ったということ？
そのページに直接アクセスできることが分かるだけで、プロキシ設定が復旧したとは確認できません。Home → Global Routingに戻り、Proxyで選択中の設定を確認してから、Configに戻してルールを確認します。元の設定でSceneを使っていた場合は、該当シーンのルーティング設定も確認してください。
手動で切断したのに、なぜ自動で再接続するの？
Settings → On Demandでオンデマンド接続の条件を確認してください。テスト条件を固定するには、設定を記録してから一時的に無効にし、確認が終わったら元に戻します。システム接続が自動的に再確立しても、リモート側の認証成功を意味するわけではありません。
7. 再現できる記録をまとめて問い合わせる
ここまで確認しても解決しない場合は、必要最小限の記録をまとめ、サービス提供元にサーバーの稼働状況を確認してください。公開の問い合わせにはサブスクリプションURL全体を貼らないでください。URL内のトークンにはアクセス権限が含まれることが多く、スクリーンショットでもQRコードや認証情報を隠す必要があります。アプリの購入情報と接続サービスの設定は別のものです。アプリを購入しても、サーバーの不足している設定情報は補われません。
- 利用環境：iPhoneまたはiPad、実際のOS情報、Wi-Fiまたはモバイル通信。システム要件はApp Storeページの記載を確認してください。
- 設定：プロトコルのType、ポート、TLSとトランスポート方式の使用有無。パスワード、秘密鍵、サブスクリプションURL全体は記載しないでください。
- ルーティング状態：Global RoutingでProxy、Direct、Config、Sceneのどれを使用していたか、テスト中にOn Demandが有効だったか。
- 結果：同じページを2種類のネットワークでそれぞれ3回テストした成功・失敗の記録と、使用した遅延テスト方式。
- ログ：再現した時刻と最初に発生したエラーの原文。機密情報を削除したうえで、必要な前後関係を残します。
アドレスとポート、プロトコル設定、デバイスの時刻を確認し、異なるネットワークでも同じ段階で安定して失敗する場合は、サービス提供元にポートの待ち受け状態、認証情報、証明書を確認してもらいます。ローカル設定を手当たり次第に変更するより、原因を絞り込みやすくなります。最後にルールとOn Demandの条件を元に戻し、普段のアクセスも想定どおりか確認してください。