なぜ「ルール不効」の前にログを確定させるのか
検索やコミュニティで「書いたDOMAINが効かない」という相談は多いですが、実際には別の行が先に当たっているケースが最も多く、YAML parserのエラーほど劇的な原因ではありません。Clash系は rules を上から1行ずつ試し、最初の一致だけ採用します。ここがブレると、ユーザー体感では「いつも同じノードに行く」「国内サイトなのにプロキシに載る」などに変換されます。
さらにルール右辺が DIRECT や単一のプロキシ名ではなく、別のポリシーグループ名である構成はごく普通です。その場合、ログ上の matched rule は「グループAへ」と出ても、実際のTCP終端はグループAの中で今選ばれているメンバーBになります。ルール→ポリシー→実ノードの3段を混同しないことが、高走査のコツです。
コアの入れ替えや前提プロトコルは Clash Meta（mihomo）コアの更新ガイド も参照してください。古いコアと新しいプロファイルを組み合わせると、ログフォーマットや未対応指令だけがズレて見えることもあります。
手順1：ログレベルを切り分け用に上げる
まず「どの接続が、どのルール行にマッチしたか」をコアが吐き出す状態にします。設定ファイルの log-level を debug または製品ドキュメントで推奨される詳細レベルへ一時変更し、GUIがあるクライアントならログビューを開いたままにします。ログはファイルと標準出力のどちらに出るかはクライアント依存なので、設定画面の「ログ保存先」を合わせておくと後戻りが減ります。
log-level: debug
注意： debug は常時運用向けではありません。I/OとCPUのオーバーヘッドが増え、接続数の多い環境では体感できるほど重くなることがあります。再現が取れたら info 等へ戻す前提で使ってください。セキュリティ的にも、ログにホスト名やターゲットIPが並ぶため、共有マシンではマスクやローテーションを意識します。
手順2：対象トラフィックだけを再現して1行を特定する
ブラウザのキャッシュや常駐アプリを止めきれないときは、再現手順を固定します。例：シークレットウィンドウでURLを開く、curl で同一ホストへTLSを張る、問題のアプリだけ起動する。並行してログを流し、時刻とプロセス名（出る場合）で絞り込みます。
ログ行に rule／policy／proxy といったラベルが並ぶフォーマットが多く、ここで「どのキーワード（DOMAIN-SUFFIX など）にヒットしたか」と「次に解決したポリシー名」が分岐します。複数クライアントを試している場合は、同じプロファイルでもログ文言が微妙に違うので、mihomoの標準表記に公式ドキュメントを当てはめる癖をつけると早いです。
接続が短く切れるとログが流れやすいので、Developper Toolsのネットワークタブや curl -v で同一ホストへの再試行を挟み、確実に1本のフローを掴みます。
手順3：MATCH／FINAL の行をYAML上の「最後の1行」と同期する
多くのテンプレートは末尾に MATCH,PROXY または MATCH,DIRECT、あるいは FINAL エイリアスを置きます。これはそれまでのどの条件にも当てはまらなかった残り全部を受け止める行です。ログに FINAL と出ていたからといって「ルール全体が無効」なのではなく、手前の条件がすべて外れた結果としてそこに落ちたことが多い、と理解してください。
rules: - DOMAIN-SUFFIX,example.com,EXAMPLE_GROUP - GEOIP,CN,DIRECT - MATCH,PROXY
ここで example.com を直結にしたいのに PROXY に行くときは、(1) 実際のTLS SNIやHTTP Hostが example.com と一致しているか、(2) もっと上の行（RULE-SET含む）に吸われていないか、の両方を疑います。ログの matched 表示が MATCH なら、上の細かい行に一度も触れていないことを意味します。
手順4：ルールの「上から先勝ち」を紙（またはエディタ）に書き出す
エディタの折りたたみや購読マージ後のビルド結果で順序が変わっていると、人間の記憶と実際の評価順がズレます。実際にコアが読んでいる最終的な rules リストをダンプできるクライアントなら活用し、そうでなければマージ後ファイルを1本にして行番号を振り直します。
特に罠になりやすいのが RULE-SET です。サードパーティの巨大セットを上に置くと、意図したDOMAIN行より先に「広いパターン」がマッチし、ユーザーは「自分の1行が無視される」と感じます。逆に、例外を上に、汎用セットを下に、MATCHを最下、という階層にすると迷いが減ります。学内Captive Portalのように直結を先頭に固定すべき状況は、キャンパスWi‑Fi向けの順序稿 でも同型の話をしています。
「ルールが効かない」のではなく「もっと強い（早い）ルールに負けた」と言い換えると、次の修正箇所が見えやすくなります。
手順5：ポリシーグループのネストと「今選ばれているメンバー」を開く
matched rule の右辺が 代理マスタ のようなグループ名で、その中にさらに 香港・自動 が並んでいる構成は典型です。このときログの policy は親グループまでしか言わない場合があり、実ノードは子グループの url-test 結果になります。
- select：ユーザーがGUIで選んだ1つがそのまま実体になるまで解決します。誤ったノードに見える場合、まず選択が古いままか確認します。
- url-test／fallback：到達チェックの結果でメンバーが切り替わります。「ルールは合っているのに国が変わった」は、自動選択のスコープ内の話であることが多いです。
- relay：多段のため、末端までログを辿らないと延迟だけが増えて原因が隠れます。
ダッシュボード（Yacd Meta など）で 今アクティブなチェーンを見られる場合は、ログ1本より速いこともあります。ただしAPIとログの粒度が違うため、最終的にはコアログを正とする姿勢が安全です。
手順6：DNS／Fake-IPでログに出る「名前」が期待と違わないか確認する
ルールはしばしばドメイン文字列でマッチしますが、コア内部では Fake-IP や異なる解決経路によって、ログ1行目に出るホスト表示がブラウザのアドレスバーと一致しないことがあります。ユーザーは「example.comへ行っている」と思っても、実際の評価はCDNの別名やIP直撃に寄っている、というギャップです。
DNSセクションで enhanced-mode や fake-ip をどう載せているかを確認し、必要なら一時的に redir-host 側へ寄せて解決結果とルール条件のズレを切り分けます。深掘りは DNS Fake-IPとRedir-Hostの排障稿 に譲りますが、分流デバッグでは「ログの文字列を鵜呑みにしない」だけでも誤診が減ります。
ブラウザのDoHやOSキャッシュが別経路にあると、アプリが見ている名前とClashが評価した名前が分岐します。TUNモードとシステムプロキシモードで挙動が変わるのも同じ構造です。
よくある質問（整理）
FINAL ばかり見えるのは設定が壊れていますか？
壊れているとは限りません。細かい条件が上に無い、または条件が実トラフィックと合致していないとき、自然とキャッチオールへ落ちます。まず matched 行が本当に MATCH か、それとも別行なのに表示省略されているかを確認してください。
「proxy-policy」と実ノードの欄が食い違うのは正常ですか？
ポリシー列とプロキシ列が分かれているログでは、ポリシー＝中途のグループ名、プロキシ＝最終出口という読み方が通用します。どちらか一方しかないフォーマットの場合は、公式のログ解説にフィールド定義を当てはめます。
購読を更新した直後だけ挙動が変わりました。ログはどう見ればよいですか？
購読マージで rules の順序や RULE-SET の中身が変わると、リロード前と同じ見た目でも実体は別リストです。更新直後に一度だけ debug を上げ、同じホストで before／after を比較すると原因が特定しやすいです。サブスクURLの取得エラーや混線は 購読更新のチェックリスト も併用してください。
6手順を終えても矛盾する場合は？
クライアント側の「プロセスごとの分離プロキシ」やOSの別VPN、スプリット除外リストが同時に動いていないかを疑います。複数のトンネルが競合すると、Clashのログは正しくてもパケットが別経路へ抜けることがあります。
まとめ：ルールデバッグは「1本のログ列」と「YAMLの行番号」の突合仕事
matched rule と FINAL／MATCH の行き先を突き合わせ、続けてルール順・ポリシーグループの入れ子・DNS表示を見れば、「書き損じ」か「順序負け」か「グループ内の自動選択」か、という3分岐にほぼ収束します。毎回感覚でルールを足す前に、ログを1本固定してからYAMLを直すと、予期せぬ副作用も減らせます。
長期運用では、メタ情報の揃ったクライアントと、更新しやすいプロファイル管理の組み合わせが重要です。端末ごとに最適なビルドを試す場合は、ダウンロードページ で対応OSのエディションを比較し、同じ config.yaml を複数端末へ載せ替えて挙動差だけを見るのも有効です。
同類ツールのなかでも、Clash／Meta系はログとYAMLの対応が比較的直線的な部類です。一度6手順を体に染み込ませれば、「とりあえず全面書き換え」ではなく1行単位の外科的修正で済む場面が増えます。
ほかのチュートリアルや最新記事は 技術コラム からどうぞ。