Clash が接続済みなのにサイトが開かない:ノードから DNS までの逐次チェックリスト

プロキシは緑色でオンなのにブラウザが回り続ける。原因はノード・ルール・DNS・システムプロキシのどこかにある。9つのチェックポイントを易しい順に並べ、判断基準と対処法を示す。

まず問題の範囲を絞ってから調べる

「接続表示は正常なのにサイトが開かない」という一言の裏には、まったく異なる原因が潜んでいる場合がある。作業を始める前に1分だけ範囲を絞ると、後の手間を大きく減らせる。

• 一部のサイトだけ開かず、他は正常:ルール振り分けか単一ノードの問題である可能性が高く、全体的な通信障害ではない。
• すべてのサイト(日本国内サイトを含む)が開かない:まずシステムプロキシ、TUNネットワークアダプタ、あるいは端末のネットワーク自体を疑うべきで、Clashのノードとはあまり関係がない。
• サイトは開くが極端に遅い、画像が読み込めない:多くはノードの遅延や帯域の問題であり、「接続できない」とは異なる。
• サブスクリプションや設定を変更した直後に発生:設定ファイル内のルールやDNS部分をまず疑い、設定を一度ロールバックすれば素早く検証できる。

現象を上記のいずれかに分類したら、以下のチェックポイントの順序に沿って進めればよく、すべてを一つずつ試す必要はない。

チェックポイント1~3:ノード自体の問題

1. 選択中のノードは本当に接続できているか

プロキシページに表示される「接続済み」は通常、クライアントとコア間の制御接続が正常であることを示すだけで、選択中のノード自体が外部ネットワークにアクセスできることを意味しない。プロキシページを開き、現在のポリシーグループ内のノードで遅延テストを一度実行する。タイムアウトや3桁以上の遅延数値が表示され、かつサイトが開かない場合は、まず遅延の低いノードに切り替えて検証する。それで開けばノード側の問題なので、続けて2、3点目を確認する。ノードを変えても開かない場合はルールとDNSの部分に進む。

2. ポリシーグループが無効なノードを選択していないか

select や url-test ポリシーグループを使用している場合、サブスクリプション提供元が一時的に特定のノードをオフラインにしても、クライアントは自動的には通知せず、ポリシーグループはその無効なノードに留まったままになる。ログページで dial tcp: connection refused や i/o timeout が多数出ていないか確認し、同一ノード名に集中している場合は、グループ内の別ノードに手動で切り替えるか、ポリシーグループのタイプを url-test に変更してコアに遅延異常なノードを自動的に回避させる。

3. サブスクリプションが期限切れ間近、または既に切れていないか

一部のサブスクリプションは、通信量や期間が切れても取得失敗として直接エラーを出さず、すべてのノードを接続不可能なダミーノードに置き換える。表面上は「接続は正常だがどのサイトも開かない」という状態になる。サブスクリプション提供元の管理画面で期限と残り通信量を確認するのが、クライアントを何度も再起動するより効果的な確認方法だ。

チェックポイント4~6:ルールが通信を誤った方向に流していないか

4. プロキシ経由にすべきドメインがルールで直接接続と判定されている

Clashはルールを上から順に照合し、あるルールに一度でも合致すると以降は照合しない。カスタムルールに範囲が広すぎる DOMAIN-SUFFIX や DOMAIN-KEYWORD が存在すると、本来プロキシ経由にするべきドメインが先に DIRECT にマッチしてしまう可能性がある。ログページでログレベルを debug に上げ、開けないサイトにアクセスして、対応するドメインがどのルールにマッチし、どのポリシーグループに落ちたかを確認し、問題のルールを直接特定する。

5. ルールセット(rule-provider)が正常に取得できていない

リモートルールセットを使用している場合、取得に失敗するとコアは通常、空のルールセットや前回のキャッシュを無言で使い続け、プロキシ接続自体は中断されない。設定ページでルールセットの更新時刻を確認するか、設定ファイルに次のような保険を追加する:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject.txt"
    path: ./ruleset/reject.txt
    interval: 86400
rules:
  - RULE-SET,reject,REJECT
  - MATCH,PROXY

末尾の MATCH,PROXY により、ルールセットでカバーされなかった通信すべてに明確な行き先が用意され、未定義動作に落ち込むことを防げる。

6. FINAL / MATCH ルールが誤ったポリシーグループを指している

設定ファイル末尾の兜底ルール(旧文法では FINAL、新文法では MATCH)が誤って DIRECT に設定されていると、前段のどのルールにもマッチしなかったドメインがすべて直接接続され、着地ノードのないネットワーク環境では大規模に開けなくなる。設定ファイルの最終行を確認し、直接接続ではなくプロキシのポリシーグループを指しているかチェックする。

チェックポイント7~9:DNSとシステム層に潜む見落とし

7. DNS解決が汚染されている、または誤ったIPを返している

通信自体はプロキシを経由していても、ドメイン名解決の段階で端末の通信事業者のDNSが使われ、Clashが引き継いだDNSでない場合、解決結果が汚染される可能性があり、誤ったIPを取得した後はプロキシがどれだけ速くても開けない。設定ファイルの dns セクションが有効になっているか、enhanced-mode が fake-ip または redir-host に設定されているか確認する:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN

fake-ip モードでは、クライアントがドメインに仮の IP を割り当て、コア層で本当のリクエストに復元するため、ローカルDNS汚染の大部分を回避できる。現時点でデフォルトとして推奨されるモードだ。

8. システムプロキシが実際には機能していない

一部のアプリケーション(特にコマンドラインツール、一部のゲームクライアント、旧バージョンのブラウザ)はシステムプロキシの設定を読み取らず、Clashの画面上で接続済みと表示されていても、これらのプログラムは直接接続を続けるため、プロキシが必要なサイトは当然開かない。ブラウザをシステムプロキシに明確に対応したアプリ(Chrome、Edgeなど)に切り替えて再テストし、開けばそのアプリがシステムプロキシに対応していないだけでClashの故障ではないと分かる。この種のアプリには個別にプロキシアドレスを設定するか、TUNモードで引き継ぐ必要がある。

9. TUNモードとシステムプロキシが同時に有効で衝突している

TUNモードはネットワーク層ですべての通信を引き継ぐが、同時に手動でシステムプロキシも設定していると、2つの引き継ぎ経路が重なり、ルーティングのループや通信の重複処理が起きやすく、断続的に開かない・不安定になるといった症状になる。どちらか一方の引き継ぎ方式だけを残すよう確認する:TUNを有効にするならシステムプロキシは切り、逆も同様で、両方を同時に有効にしないこと。

9つのチェックポイントを通した完全な調査フロー

問題がどの層にあるか分からない場合、以下の順序で一通り試すと通常5分以内に特定できる:

1. ノードを切り替えてテストし、ノード自体の失効を排除する(チェックポイント1~3)。
2. ログレベルを debug に上げて問題を再現し、ドメインがどのルールにマッチしたかを見る(チェックポイント4~6)。
3. enhanced-mode が fake-ip になっているか確認し、DNS汚染を調べる(チェックポイント7)。
4. システムプロキシに明確に対応したアプリに切り替えて比較テストする(チェックポイント8)。
5. TUNとシステムプロキシが同時に有効になっていないか確認する(チェックポイント9)。

この5ステップを終えれば、9割以上の「接続は正常だが開かない」という問題は具体的な原因まで特定できる。すべてのチェックポイントを排除してもなお問題が残る場合は、設定ファイル自体の記述に誤りがある可能性が高い。出所が明確でシンプルな構成のサンプル設定に一度置き換えてテストし、クライアント自体に異常がないことを確認した上で、カスタムルールを一つずつ戻していくことを推奨する。