Clash でノードが全て赤に見えるとき：遅延テスト・UDP・DNS・STUN を順に切り分ける

「全ノード赤」が意味すること

ClashやMihomo（旧 Clash Meta）を核にしたクライアントでは、プロキシ一覧に遅延（レイテンシ）や色分け表示が付きます。画面によってはタイムアウトや高遅延が赤で示され、「全部赤＝プロバイダーのノードが全滅」と感じやすいのですが、実際には健康チェック（遅延テスト）用の経路だけが詰まっているケースが非常に多いです。

本稿では、Clash 遅延テストが参照する URL や DNS の解決経路、UDP と STUN（WebRTC などで使われる NAT 越えのためのプロトコル群）がブロックされている状況を区別し、ノード全赤と表現される症状から原因を段階的に狭める手順を整理します。プラットフォーム横断で共通する論点（Fake-IP、enhanced-mode、DNS まわりの取り違え）と、クライアント固有の表示の差にも触れます。

遅延テストは「実際の通信速度」ではない

多くの GUI は、各プロキシに対して HTTP ベースの健康チェックを送り、その結果を遅延テストとして表示します。使用する URL はプロファイルの proxy-groups 内の url-test／fallback 系の設定や、クライアント既定の測定先に依存します。ここが社内フィルタ・地域ブロック・DNS の誤解決に引っかかると、実際に YouTube や Git が速くても、一覧上は全ノードがタイムアウトに見えます。

逆に、遅延が緑でもUDP だけ通らない、音声通話やゲームの NAT が厳しい——といった症状は、測定が TCP／HTTP 中心であることとセットで理解する必要があります。STUN 系のサーバーへの到達や、対称型 NAT 環境では、表示上の数値と体感が一致しないことがあります。

用語：本稿ではプロバイダーが配布するノード一覧を「購読」、画面上の一時的な品質表示を「健康チェック」、ユーザーがボタンで実行する一括計測を「遅延テスト」と呼び分けます。実装名はクライアントごとに異なります。

ステップ 0：購読・プロファイル・コアの前提確認

まず購読 URL が最新で取り込めているか、選択中のプロファイルが意図したものかを確認してください。期限切れトークンや空のリストでは、そもそもテスト対象が存在しません。取り込み手順の共通点はサブスクリプション URL 追加の総合ガイドにまとめています。

次に、Mihomo／Clash Meta 系カーネルか、レガシー Core かで挙動差があります。古いコアのまま新しいプロトコルだけを有効にしていると、接続自体は別経路で成立しても測定が失敗する、という整理が必要です。アップグレードの全体像は既存の Meta 移行記事も参照してください。

ステップ 1：DNS（Fake-IP・enhanced-mode・DoH）を疑う

DNS が壊れていると、ブラウザは動いても健康チェック先のホスト名だけ解決できず、結果としてノード全赤やタイムアウト一色に見えます。Clash 系では dns.enhanced-mode が fake-ip のとき、ルールと解決結果の組み合わせを誤ると「意図しない IP」に向いてしまい、測定だけ失敗することがあります。

確認のポイント

  • システム DNS とクライアント DNS の二重設定：OS が DoH／Private DNS、クライアントが別の名前解決を使うと、ルール評価と実際の接続先がずれます。
  • fallback や nameserver の到達性：DoH の URL 自体がプロキシ必須ドメインだと、鶏卵問題になります。
  • IPv6：AAAA が返るが経路が無い環境では、タイムアウトが増えやすいです。

TUN モードと DNS の関係を深く押さえたい場合は、TUN モードの解説を併読すると、システムプロキシのみのときとの差分が整理しやすくなります。

ステップ 2：UDP と STUN（WebRTC・NAT）

遅延表示は多くの場合 TCP／HTTP ですが、実利用でUDP が必要なアプリ（一部のゲーム、RTC、QUIC を含む通信）では別問題になります。STUN は NAT の向こう側を知るための仕組みで、ブラウザの WebRTC テストやオンライン会議の事前チェックで使われます。プロキシや TUN が UDP を正しく転送していない、またはルーターが対称型 NAT で厳しいと、「接続はできるが品質が悪い」「テストだけ失敗」が起きます。

切り分けとしては、（1）クライアントが TUN／システムプロキシのどちらで動いているか（2）OS やセキュリティソフトがUDP をドロップしていないか（3）同一 LAN 内で別端末は正常か、を順に見ます。モバイルではキャリアや「データセーバー」が関与することもあり、Android 向けの接続切り分けと組み合わせると再現条件が掴みやすいです。

ステップ 3：url-test・interval・健康チェック URL

プロキシグループが url-test や fallback のとき、健康チェックに使う URL と間隔（interval）、許容遅延（tolerance など）が結果に直結します。測定先がクラウドフロントの固定ホストだと、地域によってブロックされやすく、一見全サーバーが死んだように見えます。

対策の方向性は、（1）到達確認用の URL を複数持ち、ローカルで curl 等から到達できるかを見る（2）プロバイダー推奨の測定先があればそれに合わせる（3）間隔を短くしすぎてレート制限に触れていないか、です。ルールの評価順が誤っていると、DNS 問い合わせ自体が意図しないポリシーに流れる点は、ルール分岐の詳解で扱った「順序の落とし穴」と共通です。

ステップ 4：TUN、ファイアウォール、ローカル競合

Windows の Defender、企業エンドポイント、macOS のファイアウォールが、カーネルドライバや仮想 NIC 越しのトラフィックを止めていると、GUI 上の遅延テストだけが失敗することがあります。TUN を有効にした直後から全滅する場合は、まずルールでローカル宛を除外できているか、競合する VPN やフィルタが無いかを確認してください。

HTTP プロキシだけを有効にしているときと、TUN で全トラフィックを捕捉するときでは、DNS と UDP の経路が変わります。片方の設定だけ直しても症状が残るのは、この層の差が理由であることが多いです。

モバイル GUI と「全赤」の読み替え

Android の FlClash などでは、遅延表示や一括テストのボタン位置がデスクトップと異なります。一覧の色がノードの死活ではなく、直近の測定結果のキャッシュであることもあります。操作手順と表示の意味はFlClash Android 向けガイドで詳しく触れています。携帯回線と Wi-Fi で挙動が変わるときは、DNS とキャリアのフィルタを優先的に疑ってください。

短いチェックリスト（再掲）

  1. 購読が更新できており、プロファイルとモード（RULE／GLOBAL 等）が意図どおりか。
  2. DNS：Fake-IP／DoH／システム設定の競合、IPv6 の片道不通。
  3. 健康チェック URL 自体がブロックされていないか（別端末・直列で確認）。
  4. UDP／STUN 依存のアプリだけ悪いなら、TUN と UDP 転送、NAT 環境を疑う。
  5. ファイアウォール・他 VPN・セキュリティ製品の干渉。

運用のコツ：原因が特定できたら、測定用 URL や DNS を安易に「全部直結」に寄せすぎないこと。ルールとプライバシーのバランスを保ちつつ、健康チェックだけを安定した宛先に変える、という段階的な直し方が安全です。

ドキュメントと入手経路

YAML の詳細や高度なトピックは、当サイトのチュートリアル・ドキュメントも参照してください。クライアントの実行ファイルは、説明が一貫した配布導線としてダウンロードページから入手するのがおすすめです。

まとめ

ノード全赤や遅延テストの全滅は、必ずしもプロバイダー側の障害だけを意味しません。DNS の誤解決、測定 URL のブロック、UDP／STUN を要するアプリとのレイヤーの違い、健康チェック間隔の不適切さ、TUN とファイアウォールの組み合わせ——といった要因を順に潰すと、原因範囲はかなり早く狭まります。

同種のツールのなかでも、Clash／Mihomo 系はルールと DNS をローカルで制御しやすく、表示と実通信のズレを自分で追いやすいのが強みです。切り分けに慣れれば、画面の赤色一つで慌てずに済むようになります。

各 OS 向けクライアントの入手先はダウンロードページにまとめています。計測 URL と DNS を一度見直したうえで、環境に合ったビルドを入れると、トラブル時の再現と修正がはるかに楽になります。→ Clash クライアントを無料でダウンロードし、安定した接続を試す