Windows Clash ノード測速が全タイムアウト：DNS・IPv6・購読

想定する症状：遅延テストが「全部だめ」に見える

Clash／Mihomo 系クライアントでは、プロファイル読み込み後にノード一覧の横でレイテンシ（遅延）を測る操作がよくあります。ここがすべてタイムアウトだったり、スピナーのまま終わらなかったり、数字がまったく付かないとき、ユーザーはまず「サーバーが全部落ちているのでは」と不安になります。実際には、測定パケット自体が出口まで届いていない、名前解決でつまずいている、IPv6 側だけ経路が閉じているなど、より手前の層で詰まっているパターンが非常に多いです。

本章のゴールは、Windows を使っている前提で、DNS の変更・IPv6 の切り分け・購読 URL の到達確認という三本柱から「測速全滅」を解体することです。ブラウザでは普通にサイトが開けるのにクライアントだけおかしい、というときほど、この順序が効きます。初回セットアップの流れはClash Verge Rev の Windows 向けガイドに沿っておくと、プロファイルやコア再起動のイメージが揃いやすくなります。

💡

キャッシュや「更新したのに一覧が変わらない」問題とは別物です。 購読の再取得やローカル保存まわりはWindows での購読キャッシュと手動再取得の稿で扱っています。本稿は測速／接続確立の手前にフォーカスし、両方を読むと運用の死角が減ります。

前提：遅延テストが実際にしていること

GUI の「測速」「遅延チェック」は、実装や設定によってTCP の接続試行に近いものだったり、設定ファイルに書かれた url-test 用の HTTP(S) への HEAD／GET に近いものだったりします。いずれにせよ、名前解決 → 実際のピアへソケットを開くまでが成立しないと、結果はタイムアウトか未取得のままです。ここで誤解しやすいのは、「ブラウザで Google が開ける＝ノード測定も同じ条件で成功する」ではない、という点です。ブラウザは OS の別スタック・別 DNS キャッシュ・拡張や Secure DNS の影響を受け、Clash のテスト流量はコアが選んだ DNS とルールに直結します。

したがって測速が全滅でも、実際のプロキシセッションが一部成功しているケースはあり得ます。逆に、測速だけ偶然成功しても本番の動画やゲームが不安定、ということもあります。トラブルシュートでは「一覧の数字」を単独の真実とせず、接続ログとルール命中で、対象ホストがどのポリシーに落ちているかを照合する癖をつけると安定します。

DNS：リーク、上書き、Clash 側の DNS 設定

Windows では、Wi‑Fi またはイーサネットのアダプターごとにDNS サーバーが DHCP から配られるのが一般的です。ここがキャリアのフィルタリング系や社内ポリシー付き DNS だと、特定ドメインだけ応答が遅い／存在しないという形で Clash のテスト先ホスト名が解けず、結果として全ノードがタイムアウトに見えることがあります。対処の第一段は、OS のネットワーク設定で信頼できるパブリック DNS（例：1.1.1.1、8.8.8.8）を一時的に指定し、症状が変わるかを見ることです。変わるなら、元の DNS がボトルネックだった可能性が高いです。

第二段はClash 側の DNS セクションです。enhanced-mode が fake-ip のとき、ブラウザやアプリが見ている名前解決と、実際のバックエンド接続の見え方が分かりにくくなります。設定ミスやルール順のせいで、テスト先が意図せず DIRECT 側の古いキャッシュや別リゾルバへ流れている場合もあるため、ログに出るクエリ名と IP を突き合わせます。詳細なモード比較はfake-ip と redir-host の比較記事も参照ください。

第三段は「DNS だけ Clash の外に逃げている」状態、いわゆるリークに近い現象です。システムプロキシだけオンで、アプリが独自にスタブリゾルバを叩く場合、見かけ上プロキシ経由でも名前解決がズレます。TUN モードや DNS のキャプチャ設定を使う構成では、そのズレ方が変わるため、変更の前後で測速結果を比較すると原因が絞れます。

IPv6：優先されてハンドシェイクだけ落ちるパターン

Windows は環境によってIPv6 が有効なまま、かつルーター側や ISP 側の IPv6 は中途半端に繋がっていることがあります。このとき、アプリケーションやテスト実装が IPv6 を先に試し、サーバー側は応答しない／経路が非対称で戻ってこないといった事象が起きると、ユーザーから見ると「ずっとタイムアウト」に見えます。IPv4 だけなら問題ない出口でも、AAAA レコードが返ることで IPv6 が選ばれ、結果が悪化する典型です。

切り分けとしては、(1) 一度ネットワークアダプターのプロパティから IPv6 をオフにして再起動し、測速が一気に通るかを見る、(2) 通るなら、IPv6 を再度オンにしたうえでルーターや ISP、あるいはノード側の IPv6 対応を別途検討する、の二段が現実的です。開発者向けの検証としては ping -6 やブラウザとは別経路の確認もありますが、一般ユーザーにはIPv6 オフでの A／B テストが手軽です。企業端末ではポリシーで無効化できない場合もあるため、そのときはネットワーク管理者への確認が必要です。

なお、IPv6 を止めることはあくまで診断と回避であり、IPv6 単体が「悪」というわけではありません。恒久対応としては、安定した IPv6 経路の確保や、クライアント・サーバー双方で期待どおりのスタックが使われているかを確認します。

購読 URL：ブラウザでは開けるか、取得ログはどうか

ノード一覧自体が古い・空に近い状態で測速しても意味がありません。まず購読 URL をブラウザで開き（トークン付き URL は漏洩に注意し、画面共有しない）、期待どおりのプレーンテキストや YAML 断片が返るかを確認します。HTTPS の証明書エラーが出る環境では、Clash 側の取得も同様に失敗しやすいです。企業プロキシの TLS インスペクションはその代表例です。

次に、GUI のログまたはコアのログでfetch／provider／HTTP ステータスを探します。403・429・5xx が続いているのに UI だけ古いノードを抱えている場合、測速対象のホスト名も実体とズレていたり、そもそも古いノード定義のままだったりします。購読が更新できていない状態で「全部タイムアウト」と感じることもあるため、更新ボタン実行直後のログ行と、一覧の最終更新時刻のような表示があればセットで見ます。

複数購読や変換サービスを挟んでいる場合は、どのプロファイルがアクティブかの取り違えにも注意してください。手元の整理としては購読 URL と複数ソースの記事の運用ルールに寄せると、設定が読みやすくなります。

Windows 側のその他：ファイアウォール、競合プロキシ、7890 支配

ローカルで動いている別の VPN／フィルタ／「ネットワーク加速」系ソフトがループバックやフォワードを握っていると、Clash のコアが自分自身へ再接続しようとして詰まることがあります。Windows Defender の誤検知で実行ファイルが隔離されているケースもあり、隔離と除外の記事が参考になります。また mixed-port の競合でコアがListenに失敗していると、測速以前に機能不全になります。7890・netstat の稿で PID を特定し、ポートとシステムプロキシの記述を揃えてください。

ブラウザは通るがターミナルだけ直結する、というレイヤー分離はGit／curl と HTTP_PROXY の記事で扱っています。測速が GUI 内だけ失敗するときも、「システム全体のプロキシ」と「コアが Listen しているポート」が食い違っていないかを改めて確認します。

まとめ：測速全滅は「出口不良」だけではない

Clash でノード測速がすべてタイムアウトに見えるとき、最初にサーバー契約を疑う前に、Windows のDNS・IPv6・購読 URL の到達という近い所を見た方が早いことが多いです。特に IPv6 とフィルタ DNS は、画面には強く出ないままテストだけが落ちるので、A／B テストの価値が高いです。キャッシュや一覧の鮮度は別問題なので、購読まわりは前述の対になる記事（購読キャッシュ編）とセットで読んでください。

長期的には、ログが読めるクライアント世代に寄せ、ルールと DNS を一貫した説明で管理できる状態がいちばんメンテナンスしやすいです。導入から設定の全体像を押さえたい場合は当サイトの使い方ドキュメントも併せてどうぞ。安定したビルドの入手経路をまとめたダウンロードページから環境に合うパッケージを選び、→ 無料で Clash をダウンロードし、DNS と IPv6 の切り分けから再確認する流れがおすすめです。