プロキシノードがタイムアウトするのにネットワークは正常：サブスクリプション、DNS、接続経路の確認手順
ローカル接続、サブスクリプションの有効性、ノード設定、DNS、プロキシの適用範囲を順に確認し、テスト先の到達不能と実際の接続失敗を切り分けます。再インストールの繰り返しも防げます。
1. まず遅延テストのタイムアウトと実際の接続失敗を切り分ける
ブラウザーで日本国内の普段使うサイトを開けても、Clash クライアントがノードを「タイムアウト」と表示することはあります。ローカル接続が確認できるのは、直結経路の一つが使えるということだけです。ノードの遅延テストでは通常、プロキシサーバー、プロトコルのハンドシェイク、指定されたテスト先を順に経由します。どこか一つでも失敗すれば、画面上は同じタイムアウトとして表示される場合があります。
クライアントは画面、サブスクリプション、設定を管理し、コアはプロキシ接続、ルール、DNS などを処理します。Clash と Clash Meta（現在は mihomo と呼ばれることが多い）では、対応フィールドや動作が異なります。クライアントによってテスト入口、既定 URL、タイムアウトのしきい値も完全には一致しません。切り分けではアプリ名だけでなく、クライアントのバージョンと実際に動作しているコアのバージョンを記録してください。
| 症状 | 優先して確認する項目 | この時点では判断できないこと |
|---|---|---|
| 遅延テストはタイムアウトするが、実際のウェブ閲覧は可能 | テスト URL、想定ステータスコード、テストのしきい値 | ノードがすでに無効になっている |
| 一つのノードだけ失敗する | そのノードの設定、サービス状態、経路 | クライアント全体の異常 |
| 同じサブスクリプションの全ノードが失敗する | アカウント状態、共通パラメータ、DNS、ローカルでのプロキシ適用 | 再インストールが必要 |
| ブラウザーは使えるが、特定のアプリだけ使えない | アプリがシステムプロキシに従うか、UDP を使用するか | すべてのプロキシ通信が正常 |
2. ローカル接続を確認する：ポータル認証と残存プロキシを除外
現在の設定を保存してから、クライアントのシステムプロキシと TUN による適用を無効にします。ほかの VPN やプロキシアプリがある場合も、利用許可を得たうえで終了してください。画面を閉じただけではバックグラウンドサービスが停止するとは限らず、システムプロキシも必ずしも解除されません。トレイアイコンだけでなく、システム設定を確認しましょう。
Windows で直結の基準状態を確認する
- Windows 11 の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、自動セットアップスクリプトと手動プロキシの元の状態を記録します。組織から配布された設定は勝手に変更しないでください。
- 普段から直結できるウェブサイトを2つ開き、Wi-Fi がホテル、学校、公共ホットスポットの認証ページで止まっていないことを確認します。ルーターの管理画面を開けても、確認できるのは LAN の接続だけです。
- 「設定」→「時刻と言語」→「日付と時刻」を確認し、日付、タイムゾーン、時刻の同期が正常であることを確認します。時計が大きくずれていると、TLS 証明書の検証に失敗することがあります。
システムに curl がインストールされている場合は、PowerShell で次の直結リクエストを実行できます。Windows では curl.exe を使い、一部の PowerShell 環境で curl が別のコマンドとして解釈されるのを避けます。macOS、Linux ではコマンド名を curl に変更できます。
curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://example.com/--noproxy "*" は curl に設定済みの明示的なプロキシを使わせないための指定ですが、動作中の TUN、透過ゲートウェイ、組織ネットワークのポリシーを回避するものではありません。ここでの example.com は説明用の接続先なので、直結できることを確認したアドレスに変更してください。一つのサンプルサイトに到達できなくても、ローカルネットワークが切断されているとは限りません。5秒は接続フェーズの上限、15秒は今回の操作全体の上限であり、実測遅延ではありません。
3. サブスクリプションの状態を確認する：更新成功とノード利用可能は別
クライアントで現在使用している設定の詳細を開き、直近の更新が成功したか、ノード数が想定どおりか、更新後に本当にこの設定へ切り替わっているかを確認します。クライアントによっては古い設定を保持したまま動作するため、「ノード一覧が残っている」ことだけでは、先ほどの更新成功を証明できません。
- アカウント状態：サブスクリプション提供元のアカウントページで、有効期限、残り通信量、端末数や同時接続の制限を確認します。クライアントに使用量が表示されなくても、通信量が十分だとは判断しないでください。
- レスポンスステータス：
401または403は認証やアクセス制御の問題を示します。429では通常、頻繁な更新を止めて待つ必要があります。5xxの場合は、まずサーバー側の状態を確認します。 - レスポンス内容：HTTP
200でも、ログインページやエラー説明が返されることがあります。完全な YAML、ノードだけを含むデータ、単一ノードの共有リンクは、同じインポート入口で処理できるとは限りません。 - 更新経路：サブスクリプション更新時に直結またはプロキシを選べるクライアントがあります。更新に必要なノードがすでに無効だと、「更新にはプロキシが必要だが、プロキシには新しいサブスクリプションが必要」という循環に陥ります。
クライアントに該当設定が明確に用意されている場合だけ、サブスクリプション更新経路を変更して手動更新を一度行い、ログを確認します。更新ボタンを連打したり、個人用サブスクリプション URL を公開オンライン変換サービスや診断サービスに貼り付けたりしないでください。URL に含まれるトークンは、多くの場合アクセス認証情報です。
4. ノード設定を確認する：ポート接続とプロトコルのハンドシェイクを分けて考える
失敗したノードを一つ選び、プロトコル、server、port、認証パラメータを確認します。TLS、WebSocket、gRPC を使うノードでは、提供元が指定したサーバー名、トランスポート種別、パス、サービス名も確認が必要です。Reality などの拡張パラメータはコアの対応が前提であり、別プロトコルのフィールドをそのまま移植してはいけません。
まずノードサーバーの TCP ポートを確認する
次は Windows PowerShell で対話的に確認する方法です。実行時に、対象ノードの実際のサーバーアドレスとポートを入力します。サーバーアドレスにはホスト名または IP だけを入力し、https:// のプレフィックスやサブスクリプション URL は入力しません。
$nodeHost = Read-Host "ノードの server アドレスを入力"
$nodePort = [int](Read-Host "ノードの port 番号を入力")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailedこの確認は、TUN などの適用を無効にした直結の基準状態で行ってください。そうしないと、結果が既存のプロキシを経由する可能性があります。TcpTestSucceeded: True は、その TCP 接続が確立したことだけを示し、パスワード、UUID、TLS、プロキシプロトコルが正しいことまでは示しません。False の場合は、アドレス解決、リモート側の待ち受け、中間ネットワークの制限を引き続き確認します。
これは UDP ノード向けの汎用検査ツールではありません。QUIC ベースのプロキシプロトコルなどは主に UDP を使うため、TCP ポートテストに失敗しても利用不能とは限りません。同様に、ping が測定するのは ICMP です。サーバーが ICMP に応答しなくても、プロキシサービスは正常に提供している場合があります。
- ポートには接続できるが、ログに認証失敗が出る：アカウントとノード設定を確認し、まず DNS は変更しない。
- 証明書名の不一致が出る：サーバー名、システム時刻、サーバー側の証明書を確認し、証明書検証の無効化を通常の修復方法にしない。
- 特定のネットワークだけで失敗する：許可されている場合は同じ端末をスマートフォンのテザリングへ切り替えて再テストし、差異を記録する。ただし、1回のネットワーク切り替えだけで通信事業者の制限と断定することはできない。
5. DNS を確認する：ノードのドメインと接続先のドメインを分けて検証する
プロキシ接続には、少なくとも2種類のドメインが関わることがあります。一つはノードサーバー自体のドメイン、もう一つはブラウザーがアクセスする接続先のドメインです。前者の名前解決に失敗すると、通常はまだノードへ到達していません。後者の解決方法は、プロトコル、DNS 設定、トラフィックがコアに入る方式に左右されます。
前の手順で開いた PowerShell ウィンドウで次のコマンドを実行すると、システムがノードのドメインを解決した結果を確認できます。server がすでに IP アドレスの場合は、この項目を省略できます。
Resolve-DnsName -Name $nodeHost -Type A
Resolve-DnsName -Name $nodeHost -Type AAAAAAAA レコードがないことは、必ずしも異常ではありません。AAAA レコードがあっても、現在のネットワークで IPv6 経路が使えるとは限りません。ログに IPv6 アドレスへの接続がタイムアウトし、IPv4 経路は利用できると表示される場合は、IPv6 経路とコアのアドレス選択設定を確認してください。いきなりシステム全体を恒久的に無効化するのは避けます。
システムでは名前解決できるのに、なぜコアはエラーを出すのか？
- コアが独自の DNS 処理を有効にしており、システムとは異なる上流 DNS を使っている可能性があります。システムコマンドの成功だけでは、コアのログの代わりになりません。
- 暗号化 DNS の上流自体がドメイン解決やプロキシ経路を必要とする場合、設定ミスによって起動依存の循環が生じることがあります。
- ルールやオーバーライドによって DNS の経路が変更され、実行中の設定がサブスクリプションファイルの内容と完全には一致していない可能性があります。
一部の mihomo バージョンは proxy-server-nameserver に対応しており、ノードサーバーのドメイン解決に使う上流 DNS を指定できます。採用するかどうかは、実際のバージョンと DNS 設定全体を確認したうえで判断してください。確認せずにすべての Clash 設定へ追加する項目ではありません。フィールドの関係は設定リファレンスの DNS 説明を参照してください。
DNS を変更したら、クライアントが対応する方法で設定を再読み込みし、テスト接続を新しく確立します。Windows の ipconfig /flushdns で消去できるのはシステムの DNS キャッシュだけで、ブラウザーのキャッシュ、コアのキャッシュ、既存の接続までは同時に消去されません。
6. プロキシの適用を確認する：ローカルポートでシステム設定を切り分ける
ノードと DNS に明らかな異常がなければ、アプリのリクエストがコアに入っているかを確認します。システムプロキシが有効なのは、その設定に従うアプリだけです。TUN は仮想ネットワークインターフェースとルーティングによって通信を引き受けるため、適切なシステム権限が必要で、ほかの VPN の経路と競合することもあります。TUN を有効にしても無効なノードが自動修復されるわけではなく、すべての通信が必ずプロキシを通るわけでもありません。
次のコマンドは、現在の実行設定で HTTP または mixed の待ち受けアドレスが 127.0.0.1:7890 であることを前提にしています。7890 は説明用の例で、すべてのクライアントに共通する固定値ではありません。まず現在の設定または待ち受け情報で確認してください。このポートに認証が必要な場合は、クライアントの説明に従ってローカルで認証情報を指定します。記録を共有する際は機密情報を削除してください。
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/このコマンドはローカルプロキシへ明示的に接続するため、ブラウザーがシステムプロキシを採用しているかどうかに依存しません。空の --noproxy リストは、既存のプロキシバイパス設定を上書きするためのものです。テスト時は接続記録のルール命中と最終出口も確認してください。リクエストがローカルポートに入っても、ルールによって DIRECT に振り分けられることがあり、それだけでノードが利用可能だとは判断できません。
| 確認できた結果 | 次の手順 |
|---|---|
| 127.0.0.1:7890 に接続できない | 待ち受けポート、コアの動作状態、ポートの使用状況を確認し、まずリモートノードは調べない。 |
| コアに記録はあるが、出口が DIRECT | ルールとポリシーグループを確認し、テストノードを固定して接続を作り直す。 |
| 明示的なプロキシは成功するが、ブラウザーは失敗する | ブラウザーのプロキシ拡張機能、システムプロキシ、PAC、アプリ独自の DNS 設定を確認する。 |
| システムプロキシは正常だが、TUN だけ失敗する | 仮想インターフェース、サービス権限、ルーティング、ほかの VPN との競合を確認する。 |
診断時は一時的にグローバルモードへ切り替え、テストノードを明示的に選択できます。ただし元のモードを記録し、テスト後はルールモードへ戻してください。既存の接続が古い出口を使い続ける場合があるため、切り替え後は古いテスト接続を閉じてから新しいリクエストを開始します。グローバルモードでルール設定の誤りを長期的に隠さないでください。
7. テスト先とログを確認する：タイムアウトが発生した段階を特定する
明示的なプロキシで実際のサービス接続先にはアクセスできるのに、クライアントの遅延テストだけがタイムアウトする場合は、まずテスト URL を確認します。テストサービスの障害、頻繁なリクエストの制限、特定の出口からの到達不能が考えられます。実装によっては想定 HTTP ステータスコードも確認します。赤い遅延表示一つだけを根拠に、設定全体を削除しないでください。
一度に変更するテスト条件は一つだけにする
- 現在のテスト URL としきい値を記録します。画面で変更できる場合は、3000ミリ秒を一時的に10000ミリ秒へ変更し、同じノードを3回テストします。これは診断用の設定であり、推奨される遅延基準ではありません。
- アクセス権があり、応答が安定している小規模な HTTPS 接続先に変更して比較します。接続先を変える目的はテスト側の障害を切り分けることであり、常に成功する数値を返すサイトを選ぶことではありません。
- HEAD に対応しない接続先では、curl コマンドの
-Iを-o NULに変更し、通常の GET を送信してレスポンス本文を破棄します。macOS、Linux では-o /dev/nullを使います。 - コアのログと接続記録を同時に確認し、アクセス先ドメイン、適用ルール、ポリシーグループ、実際のノードが一致しているか確認します。
curl の終了コード 7 は通常、接続を確立できなかったことを示します。28 は操作のタイムアウト、60 は証明書検証失敗に関係します。いずれも一律に「ノードオフライン」を示すコードではありません。HTTP プロキシ経由で HTTPS にアクセスする場合、出力の 200 Connection established は CONNECT トンネル段階の成功だけを示します。その後の TLS と接続先の HTTP レスポンスも確認してください。
ログにある lookup、dial tcp、handshake などの文脈は、失敗した段階の特定に役立ちます。ただし、最後の「timeout」1行だけを切り出さないでください。同じ時刻前後の記録を残し、テスト対象も記載します。一時的にログレベルを上げた場合は、アクセス記録が長期間蓄積しないよう、確認後すぐに戻してください。
8. 設定を戻し、報告内容を整理する
切り分けが終わったら、元のルールモード、DNS 設定、適用方式に戻し、自動ポリシーグループを再有効化する必要があるか確認します。タイムアウトを延長する、一時的にノードを固定する、TUN を停止するなどの診断操作を、そのまま最終設定にしないでください。最終確認には、少なくとも新しいウェブ接続を1回作成し、元々失敗していたアプリの操作も含めます。
- 環境：OS、アーキテクチャ、クライアントのバージョン、実際のコアのバージョン、問題発生時のネットワーク種別。
- 範囲：すべてのノードか特定のノードか、すべての接続先か一つだけか、システムプロキシと TUN で挙動が異なるか。
- 証拠：正確なテスト時刻、使用したポート、ルール命中、実際の出口、機密情報を隠したエラーの前後関係。
- 実施済みの操作：サブスクリプションの更新時刻、アカウント状態の確認、DNS の結果、ネットワーク切り替え時の比較結果、元の設定へ戻したかどうか。
スクリーンショットや報告を共有する前に、サブスクリプション URL、トークン、パスワード、UUID、公開したくないサーバー情報を隠してください。同じノードが複数のネットワークでハンドシェイクを完了できない場合は、機密情報を除いた記録をサブスクリプション提供元へ提出できます。明示的なプロキシは正常なのにクライアントの適用だけが異常なら、該当クライアントプロジェクトへの報告が適しています。失敗した層に応じて問い合わせ先を選ぶほうが、再インストールを繰り返すより実行可能な修正案を得やすくなります。