Clash 接続済みなのに繋がらない？DNS 漏洩と fake-ip を順に直す【2026】| Clash ブログ

まず三つに分ける：プロキシ・DNS・ルール

Web サイトを開くまでには、だいたい次の三段階があります。①端末がトラフィックを Clash に渡す（システムプロキシや TUN）、②ドメインを IP に解決する（DNS）、③ルールで直送かプロキシかを決める。どこかが「正常そうに見えるが実際は繋がっていない」と、接続中なのにページが開かない症状になります。

プロキシ層：OS のプロキシ／TUN、ポリシーグループで実ノードが選ばれているか（DIRECT や REJECT になっていないか）
DNS 層：解決が ISP やルーター DNS に流れていないか（DNS 漏洩）、セキュリティ製品による差し替えはないか
ルール層：どのルールに当たったか、MATCH／FINAL の出口は何か——順序がずれると「プロキシに送るべきドメイン」が先に直送されることがあります

ステップ 1：プロキシとモード——「画面が接続済み」で止めない

クライアントによっては「コアが動いている」だけで接続表示になることがあります。次を順に確認してください。

システムプロキシ：Windows / macOS でシステムプロキシが有効か、ポートは設定と一致しているか（mixed 例：7890）
TUN：TUN に依存している場合、仮想 NIC が有効か、別の VPN とルートが競合していないか
モード：一時的に Global で試す——Global では開けて Rule では開けないなら、原因は多くの場合ルール優先度側です
ポリシーグループ：メイン出口に実ノードが選ばれているか、ヘルスチェック失敗で意図せず直送に落ちていないか

ヒント

同じ PC でも CLI は HTTP_PROXY 未設定のまま直送のまま、ブラウザだけプロキシ、という並行状態になりがちです。CLI も通したいなら環境変数を揃えるか TUN を使います。

ステップ 2：DNS 漏洩——解決が Clash に入っていない

DNS 漏洩とは、プロキシを使っているつもりでも名前解決が ISP・ルーター・OS キャッシュ側で行われ、改ざんや誤った経路でタイムアウトや真っ白表示になる状態を指します。

OS のネットワーク設定で DNS が自動（ISP 配布）のままになっていないか。可能なら 127.0.0.1 やクライアント推奨のローカルリスナに変更
ルーター DHCP で DNS を強制していないか。衝突する場合は端末側を静的指定して切り分け
企業端末やセキュリティ製品が独自の DNS フィルタを入れていないか。一時停止や例外で比較

注意

Clash 側の YAML だけ直しても、OS／ルーター DNS が変わらないと「アプリによっては正常、アプリによっては失敗」が出やすいです。解決経路はアプリごとに異なるからです。

ステップ 3：fake-ip と redir-host——症状と境界

dns.enhanced-mode でよく使うのは fake-ip と redir-host です。違いを押さえると半分は切り分けできます。

fake-ip：ドメインにプライベート帯の「偽 IP」を割り当て、ハンドシェイクと分流を速くする一方、LAN サービスや一部ゲーム・古いアプリと相性が悪いことがあります
redir-host：実 IP を使うため互換性は高め。複雑なルールでは sniffing や SNI 周りの設定がより重要になります（内核・版によります）

fake-ip が疑わしいときは、設定をバックアップしたうえで 一時的に redir-host に切り替えて再現するか確認してください。古いキャッシュを参照しているモジュールがないかも合わせて見ます。

# dns snippet — adjust to your profile
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

ステップ 4：nameserver、fallback、policy

nameserver に書いた DoH / DoT / UDP が現在の回線から到達できないと、DNS 段階で全体が止まります。

国内ドメインと海外ドメインで使う DNS を分ける：nameserver-policy でサフィックスや geosite を指定
fallback と条件付きで fallback-filter を使い、汚染を避ける
DoH を使う場合は URL・証明書検証が正しいか、その DoH 自体が「先にプロキシがないと到達できない」になっていないか（卵とニワトリ）に注意

実務メモ

「国内サイトは開くが Google だけ開かない」ときは、海外 DNS か、そのドメインを誤った出口に送っているルールを疑うと早いです。まずノードを変え、続けて DNS とルール命中を見ます。

ステップ 5：ルール優先度と MATCH（FINAL）

Clash はルールを上から順に評価し、最初に当たったものが採用されます。先頭に広すぎる DOMAIN-SUFFIX や誤った GEOIP があると、後ろの細かいルールが一生使われません。

大量のドメインを誤って DIRECT に流していないか（その回線では直送できない相手にも当たっている、など）
MATCH（設定によっては FINAL）が期待どおりのデフォルト出口か
クライアントの接続ログやルールプレビューがあれば、実ドメインがどのルールに当たったかを確認

# rules example — order matters
rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

これは順序が重要であることを示す例です。実際の購読ルールはもっと長いので、プロバイダが配布する設定を上書きせず、差分だけを慎重に足してください。

ステップ 6：ブラウザの「安全な DNS」と DoH

Chrome、Edge、Firefox などの「安全な DNS を使用」は、アプリ内で別の解決経路を開き、Clash の DNS モジュールと二重化されます。一部のサイトだけ不調になることがあるので、まずブラウザ DoH をオフにして、OS と Clash に解決を寄せた状態で再現するか確認してください。

ログで見るポイント

接続ログで繰り返し出る種類を見ます：DNS タイムアウト、ハンドシェイク失敗、context deadline exceeded、特定ドメインの REJECT。「ドメイン名・命中ルール・出口ポリシー」の三つをセットで追うと、ノードを漫然と変えるより早く原因が絞れます。

よくある質問

Global では開くのに Rule では開けない

ルール優先度か、DNS とルールの組み合わせを疑ってください。ステップ 5 に戻り、Rule 時の実出口をログで確認します。

特定のサイトだけ開けない

単一ドメイン向けルール、広告ブロック系リストの誤爆、SNI／証明書検証とスニッフィング設定の衝突などが考えられます。該当ルール群を一時オフにするか、redir-host へ切り替えて比較してください。

まとめ

「接続は有効なのにページが開かない」は、単一トグルではなく、プロキシ接続・DNS がコアに入っているか・ルールの最終出口のどこかが欠けていることが多いです。モードとノードを確かめ、DNS 漏洩と fake-ip を整理し、nameserver／fallback を点検し、ルール順とブラウザ DoH を見る——この順で進めれば、原因の箱をかなり小さくできます。

YAML をあまり触りたくない場合は、ダウンロードページからよく使う分流と UI が整ったクライアントを入手し、ノード選びと日常利用に集中するのも現実的な選択です。

Clash は接続中なのにインターネットに繋がらない？DNS 漏洩と fake-ip を順に確認する