1 なぜ「ノードを差し替えるだけ」では足りないのか
多くの GUI では接続一覧や速度テストが目に入りやすく、遅さや開かなさを出口サーバの品質のせいにしがちです。しかし Clash Meta／Mihomo では、同じ「開かない」でも原因が 名前解決の失敗・遅延なのか、ルールが期待した行にヒットしていないのか、セレクタや TUN の経路が別レイヤで上書きされているのかで打ち手がまったく変わります。ログはその一次情報です。
すでに Sniffer や GeoIP、購読の 403、Android のプライベート DNS、Tailscale との併用など、題材を絞った記事は本ブログにあります。本稿はそれらを置き換えるものではなく、「症状が複数混ざっているときに、内核が何と言っているかを手元で確認する」ための横断的なログリテラシーを補います。
2 log-level の選び方（いつ上げるか）
設定トップレベルの log-level は、コンソールやクライアントのログビューに出る分量を決めます。ざっくり、通常運用は info で十分なことが多いです。warning や error に下げすぎると、ルール名や DNS の細部が欠けて「何が起きたか分からない」状態になりがちです。一方 debug は DNS の問い合わせや内部状態まで出るため、再現手順が決まった短時間にだけ上げ、終わったら戻すのが無難です（ディスクやメモリ、画面のノイズにも配慮）。
クライアントによっては「ログレベル」の UI と「実行中の設定ファイル」が別々の場合があります。変更後はプロファイルのリロードを忘れず、ログの先頭で実際のレベルが意図どおりかを一度確認してください。
# Log verbosity: silent | error | warning | info | debug
log-level: infodebug にはホスト名やクエリの断片が含まれやすいです。Issue やチャットに貼る前はマスキングし、不必要に長時間録画しないでください。
3 connection ログで最初に見る項目
「接続」「Connections」「コネクション」などの名称で GUI に出る一覧や、テキストログ中の接続行は、だいたい次のような束として読むと整理しやすいです。宛先（ドメイン／IP／ポート）、実際に選ばれたアウトバウンド（プロキシ名または DIRECT）、マッチしたルールの行またはポリシー名、TLS 利用時は SNI や嗅探結果。ここで「ルール表に書いたドメインと違う出口」になっているなら、その行のルール名がどれかをメモし、設定ファイルの上から順にたどります。
HTTPS でドメインが最初から見えないケースは Sniffer と SNI の記事とセットで理解すると速いです。ログ上「IP のままマッチしている」「広い GEOIP や MATCH に吸われている」といった痕跡があれば、嗅探や override-destination、ルール順の見直しが候補になります。
Web ダッシュボード（Yacd など）で接続表を眺める運用は、external-controller と Yacd の記事で扱っている API イメージと重なります。テキストログより列が整っている分、ルール列とアウトバウンド列の対応を追いやすい環境もあります。
4 DNS 失敗・不安定のサインをログで拾う
名前解決が遅い・失敗する場合、ブラウザでは「白画面のまま」「ERR_NAME_NOT_RESOLVED に近い挙動」「たまにだけ成功」など幅広く現れます。コア側では タイムアウト、応答なし、意図しないフォールバック先に流れたこと、FakeIP と実 IP の対応が途切れたこと、が文言や繰り返し現れ方に現れることがあります。複数の nameserver や proxy-server を DNS に割り当てている構成では、「DNS クエリ自体がどの経路で外に出ているか」もログと合わせて確認したくなります。
OS やブラウザの「セキュア DNS」が別経路を塞いでいる典型は、Android プライベート DNS や Chrome／Edge の Secure DNS の各記事で扱っています。ログで DNS がコアに届いていないように見えるときは、まずそのレイヤを疑うと早いです。
DoH や fake-ip の基礎整理は DNS・FakeIP のベストプラクティスを参照してください。ログに出るエラー名と、YAML の dns ブロックのどのサーバが対応するかを突き合わせると、設定ミス箇所が特定しやすくなります。
5 ルールが「外れている」「薄すぎる」サイン
ルールの問題は大きく二類型あります。第一に、細かい例外より先に広いルールがマッチしている場合。ログには意図しないポリシー名や「最終行のプロキシ」に近い名前が付きます。設定では DOMAIN-SUFFIX を足したはずなのに、というときほど順番を疑ってください。第二に、マッチ材料そのものが足りない場合。IP しか無い、bundle ID やプロセス条件がズレている、Rule Provider が古い、といった理由で想定の行に到達する前に別行で消化されているパターンです。
GeoIP／GEOSITE のデータ鮮度は別問題として、手元で更新する手順は GEOIP／GEOSITE 手動更新を参照できます。ログで国コードやカテゴリマッチが妙なときは、データとルール記法の両方を疑います。
6 FakeIP が効いていないように見える症状
FakeIP は「アプリに返す IP」と「コア内部のドメイン対応」をセットで理解する必要があります。クライアント側キャッシュ、別 DNS スタック、嗅探の有無によっては、ログ上は IP ベースのマッチが続き、「ドメインルールを書いたのに効かない」ように見えます。ここでいきなりノードを変えるのではなく、そのセッションのログ一行で「ルール評価に使われている名前／IP は何か」を確認します。fake-ip-filter に入れるべき名前が抜けている典型もあるため、DNS 記事のフィルタ設計とあわせて見直すとよいです。
7 実務フロー（短時間で回す順序）
- 再現手順を固定する（同じ URL／同じアプリ操作だけを試す）。
log-levelをinfoで再現し、connection 行とエラーメッセージの有無を把握。- まだ理由が分からなければ、短時間だけ
debugに上げ、DNS とルールの行を比較（終了後に戻す）。 - ログのルール名／アウトバウンドと YAML の対応を取り、順序と嗅探を点検。
- OS・ブラウザの DNS が横から入っていないか、別記事のチェックリストで確認。
- 改善後も同じログの取り方でリグレッションがないか確認。
VPN や仮想 NIC を複数載せている場合は、経路競合自体がログの前にあります。Tailscale と Clash の優先順位のように、ルートと DNS を OS レベルから押さえる必要があるケースも忘れないでください。
8 まとめ
Clash Meta／Mihomo で誤ったノードや間欠的な不通を追うとき、connection ログと適切な log-level があれば、DNS 失敗とルールのミスマッチを雑に混ぜずに扱えます。Sniffer や購読、Private DNS など個別ガイドがあるなかで、本稿が担うのは「ログの読み方」という一通のレールです。このレールができると、設定の打ち直しが当て推量ではなく検証の繰り返しになります。
Clash 互換クライアントはコア設定と GUI を一体で扱える製品が多く、ログビューや外部ダッシュボードを組み合わせれば同じ手順をGUI上でも再現できます。インストール用パッケージは、信頼できるビルドを本站のダウンロードページから選ぶのが安全です。ソースやコミュニティ情報は GitHub も参照できますが、パッケージの第一入手先は本站を推奨します。
