なぜ「ログから入る」のが早いのか
ブラウザに「接続できません」「タイムアウト」と出た瞬間、多くの人はいきなりノードを切り替えたり、ルールファイルを丸ごと入れ替えたりします。しかし Clash（Mihomo コアを含む）は、通信のたびにどのドメイン／IP を、どのルール行で、どのポリシー（プロキシグループ）へ送ったかをログに残します。ここを読めば、「そもそもプロキシに乗っていない」「乗っているが出口が遅い」「DNS だけが別ルート」といった原因の系統を、感覚ではなく証拠で分けられます。
本稿では、特定の GUI 名に依存しないようログに現れる情報の意味に焦点を当てます。実際の表示文言はクライアント（Clash Verge 系、ClashX Pro、Android 版など）で多少異なりますが、たいてい INFO 相当の接続行に、ドメイン、マッチしたルール、選択されたポリシー、実際の出口が並びます。分流の全体設計は分流ルールの最適戦略で押さえ、本記事は「動かないときの顕微鏡」として使ってください。
ログを見る前に確認したい 3 点
ログだけ見ても誤診しやすいのが、システムプロキシ／TUN／モードとDNS モードです。例えばブラウザ拡張だけプロキシを通し、本体の通信は直結している場合、ログにそのホストが現れません。逆に TUN を有効にしているのにルートが競合していると、ログ上は Clash に来ているのに OS 側で別経路に逃げる、という見かけ上の矛盾が起きます。TUN と非ブラウザ通信の整理はTUN モード詳解も参照してください。
次に fake-ip を使っているかどうかです。fake-ip 有効時、ログに出る IP は「実サーバの IP」ではなく、アプリが最初に受け取った仮アドレスであることがあります。DNS 関連のログ行（ドメインと IP の対応づけ）を読むときは、この前提を外さないことが重要です。
最後に、ルールの評価順です。Clash 系は上から順にマッチした行で打ち切ります。リストの下の方に「きれいな最終ルール」があっても、上段の広いルールに先に吸われていると、意図した分流になりません。ログに出る「どのルール名／タイプに当たったか」は、YAML の並びとセットで読むのが鉄則です。
接続ログで見るべきフィールド（概念）
クライアントによってラベル名は違いますが、典型的には次のような塊で情報が並びます。宛先（ドメインまたは IP、ポート）、プロトコル（TCP など）、マッチしたルール（DOMAIN-SUFFIX や GEOIP など、ルール行の要約）、ルーティング結果（DIRECT またはある proxy-group 名）、チェーン先（実際に使われたノード名）。ここまで揃えば、「その通信はプロキシに乗ったのか／直結したのか」「乗ったならどのグループ経由か」が一度に見えます。
ルール命中が期待と違うときは、まず rules の上から順に該当ドメインがどこで捕まるかを追います。ログに MATCH や最終行に落ちている場合は、意図した細かいルールより手前の広いルールが優先されているサインです。GEOIP や IPCIDR は、見えている IP が「本物のサーバ」か「fake-ip」かで解釈が変わる点に注意してください。
エラー行が別に出る場合もあります。dial tcp、i/o timeout、TLS handshake などは、ルールは通ったが出口側（ノードまたは直結先）で失敗している可能性が高いです。ここでいきなり DOMAIN ルールを足しても治らないことが多く、まずはポリシーグループで選ばれているノードの健全性を疑うのが得策です。
DNS 由来の症状をログで疑うパターン
次のような組み合わせは DNS を疑います。(1) ドメインはログに出るが、解決に時間がかかる／繰り返し失敗する (2) 期待する IP と実際の挙動が一致しない (3) IPv6 だけタイムアウトする。Clash では dns セクションの nameserver と fallback、fake-ip の有無、domain ベースの DNS 分割が絡みます。
対策の方向性は、まず「そのドメインがどの DNS パイプに入ったか」をログと設定で突き合わせることです。社内ドメインや国内 CDN を誤ってリモート DNS で解いている、逆に海外ドメインをローカル DNS のフィルタにかけている、といった経路の食い違いは、ノードを何度変えても表面化し続けます。分流と DNS を一体で設計する考え方は、前述の分流記事や TUN 記事の DNS 節と相互に参照すると理解が早いです。
ノード・遅延・切断を疑うパターン
ルールとポリシーが一貫していても、遅延が高い・不安定・プロトコルによってだけ失敗する場合は出口の問題です。ログでは、同じサイトでも時間帯によって別ノードに振られている、url-test や fallback が短時間で何度も切り替わっている、といった行が手がかりになります。
体感としては「ブラウザの他タブは速いのに特定ドメインだけ遅い」場合、ルールでそのドメインが別グループに割り当てられていることが多いです。ログのポリシー名と proxy-groups の対応を確認し、意図したグループかどうかを見ます。Windows で GUI の導線を押さえたい場合はClash Verge Rev ガイドで画面位置の前提を揃えるとよいでしょう。
YAML とログを突き合わせる実務手順
おすすめの手順は次の 4 ステップです。(1) 問題の URL からドメインを特定する（リダイレクトやサブドメインに注意）。(2) ログでそのドメインの一行を探し、ヒットしたルール種別とポリシー名をメモする。(3) 設定ファイルの rules を上から読み、同じドメインがより上の行で先にマッチしていないかを確認する。(4) 必要なら RULE-SET の読み込み失敗や古い Provider を疑い、更新ログも見る。
ルールを足すときは、安易に末尾に追記するのではなく、競合する広いルールより上に挿入するか、広いルール自体を分割するかを検討します。最終行の MATCH に頼る運用は楽ですが、意図しない直結／意図しないプロキシに一括で流れやすく、トラブル時のログも読みにくくなります。
ログ共有とセキュリティ上の注意
接続ログには、閲覧サイトのドメイン、ローカルアプリの通信、時刻が含まれることがあります。コミュニティに貼る際は、個人を特定しうる情報や社内ホスト名をマスクしてください。またログレベルを上げすぎると、一時的に詳細が出すぎてファイルが肥大化します。調査が終わったらレベルを戻す習慣をつけると安全です。
オープンソース情報と入手先
コアやクライアントのソースコード、Issue、ライセンスは各プロジェクトの GitHub で確認できます。一方で、初めて Clash 系クライアントを導入する場合は、検証済みのパッケージ導線として当サイトのダウンロードページもあわせてご利用ください。ログの読み方は一度身につくと、設定変更のたびに「当てずっぽう」を減らせます。
まとめ
サイトが開かない問題は、ルール未命中・DNS・ノード品質の三つに大別できます。Clash の接続ログは、その境界を素早く切るための第一資料です。ルール命中と YAML の順序、DNS モードと fake-ip、ポリシーグループの実選択をセットで見れば、同じ症状でも次に手を入れる場所がはっきりします。長文の設定より、まず一行のログから事実を拾う癖を付けると、トラブルシューティングの再現性が格段に上がります。
環境が整ったら、安定版クライアントでログ表示をオンにし、意図した分流になっているかを確認してみてください。準備ができたら → Clash を無料ダウンロードして、ログを手がかりに接続を最適化するところから始められます。