まず症状のスコープを決める
「Clash が接続されているのにインターネットに出られない」という一言の背後には、少なくとも三つの大枠があります。第一に名前解決が終わっていないケース。第二にルール上はプロキシだが実際は直結や別出口に流れているケース。第三に出口まで辿り着いたが TLS やプロトコルで失敗しているケースです。最初にブラウザだけか、他アプリや ping でも同じかを分けると、調査の手戻りが激減します。
システムプロキシ運用ではブラウザだけ通り、ターミナルや一部アプリが直結するパターンも珍しくありません。逆に TUN を使っていれば OS 全体を同じ条件に載せやすい一方、権限や競合の影響も受けます。モードごとの前提はTUN モード解説と合わせて押さえておくと、以降のログ解釈が安定します。
ログは「種類」と「時刻」をセットで読む
多くの GUI クライアントは、ダッシュボード用の接続一覧と、コア（Mihomo など）が吐く詳細ログを分けています。前者は最終的にどのポリシー名へ振られたかが分かりやすく、後者はDNS クエリ、ルール評価、TLS ハンドシェイク、タイムアウト理由の断片が残りやすいです。症状再現の直前から数分だけログレベルを上げ、同じ URL を開き直す——この単純作業だけでも、推測と現実のズレを小さくできます。
メッセージに lookup や resolve、no such host などの語が混じるなら DNS 側を優先して疑います。DIRECT や意図しないプロキシ名が並ぶならルール順と例外の不足を疑います。handshake、i/o timeout、EOF が続くなら、ノードの到達性や中間機器の遮断、あるいはサーバ証明書と SNI の不一致といった出口以降の話に寄せて調べます。
DNS：Fake-IP と redir-host、フォールバックの落とし穴
Clash 系の DNS は、モードひとつで挙動がまったく別物になります。Fake-IP はアプリから見える解決結果を早く返す一方、ログ上では仮アドレスと実名の対応が読み取りにくく、誤設定だと解決は成功したように見えるのに実接続で詰まることがあります。redir-host 系では OS やブラウザの DoH と二重解決になり、意図しない経路で NXDOMAIN が返る例もあります。
切り分けの実務的な順番は、(1) 問題のホスト名をログから抜き出す、(2) クライアントの DNS セクションで nameserver と fallback の役割が重なっていないか確認する、(3) ブラウザのセキュア DNS を一時オフにして再現する、の三手です。ルールの書き方と DNS の境界は分流ルール入門でも触れているとおり、ルールは正しくても名前の段階で止まる典型パターンです。
社内ポリシーやルーター側の DNS フィルタとぶつかる場合、Clash のローカル DNS だけをいじっても全体像が見えません。一時的に上流を公衆 DNS に切り替えて再現が消えるかを見ると、責務の所在がはっきりします。
ルール漏れ：最初の一致がすべて
ルールは YAML 上で上から最初の一致で打ち切られます。そのため、意図せず広い GEOIP や巨大な RULE-SET が先にマッチすると、細かい例外が永遠に評価されません。結果として「プロキシグループは選べているのに、実トラフィックだけ直結」に見えることがあります。GUI の接続履歴に DIRECT が並ぶなら、まずそのドメインがどのルール行に当たったかを特定します。
対策の型はシンプルで、狭い例外を上に、広い塊を下に、最後に MATCH です。購読テンプレを丸ごと信じず、ローカルに小さな RULE-SET か直書きの例外を足す運用はRule Providers 解説でも推奨されているパターンです。変更は一度に一つだけ入れ、ログで「マッチ行が本当に変わったか」を確認する癖をつけると安全です。
UDP や HTTP/3（QUIC）だけ別ルートに落ちると、ページ本体は表示されるのに埋め込みや動画だけ失敗する、という部分症状にも見えます。ブラウザ側で一時的に HTTP/3 を切って比較すると、UDP 経路の問題かどうかが切り分けやすくなります。
TLS／SNI とノード握手：出口まで来たあとの話
DNS とルールが整っているのに、特定サイトだけ開けない場合は TLS 周りを疑います。企業フィルタ、中間者証明書、期限切れのルート、あるいはサーバ側の SNI 必須化とクライアントの挙動の組み合わせで、ブラウザは証明書エラーを出し、Clash ログには短い切断理由だけが残ることがあります。逆にすべてのサイトで同様なら、ノードの帯域枯渇やプロトコル実装の相性を疑う価値が高いです。
ノード側のタイムアウトが続くときは、別プロトコルや別地域のサーバに切り替えて再現が消えるかを見ます。ここで重要なのは、GUI の「レイテンシ表示」が低くても実 TLS セッションが安定しないケースがあるという点です。計測 URL と実利用サイトが乖離していると、見かけだけ良いままブラウジングは失敗し続けます。
実測チェックリスト（短時間版）
現場で繰り返し使えるよう、短い順序を箇条書きにまとめます。(1) ブラウザのみか全体かを切り分ける。(2) ログでホスト名とポリシー名をメモする。(3) DNS モードとブラウザの DoH を確認する。(4) そのホストがヒットしたルール行を特定し、順序を見直す。(5) それでも失敗するなら別ノードと別プロトコルで比較する。(6) 変更は一つずつ戻しながら再検証する——この六手を守ると、設定迷子になりにくいです。
まとめ：ログでレイヤを分け、設定は一歩ずつ
接続インジケータが緑でも通信が出ないとき、いきなりサブスクリプションを差し替える前に、ログが示すレイヤを一枚ずつ剥がすほうが成功率が高いです。用語と画面の対応を俯瞰したい場合はドキュメントとチュートリアル一覧も参照してください。オープンソースの信頼性を確認したい読者はMihomo の GitHubでソースや Issue を追うのがよいでしょう。一方、インストールパッケージの入手経路は読者を迷わせないよう、当サイトのダウンロードページを主導線にすると親切です。
同種ツールのなかでも、Clash エコシステムはルール表現と可視化の蓄積が厚く、ログを手がかりに戻り道を作りやすいのが強みです。いきなり完璧な一枚岩の設定を目指さず、DNS・ルール・出口の順に仮説を潰していくのが、長く安定して使うための近道です。