config.yaml 設定リファレンス：mihomo の項目・ルール・オーバーライド

1. YAML の構造と設定ファイルの範囲

マッピング、リスト、スカラー

config.yaml は、コアの動作を記述するテキストファイルです。トップレベルは通常、キーと値の集合であるマッピングです。dns の下にはさらにマッピングが続き、rules の下には順序を持つリストが並びます。文字列、数値、真偽値はスカラーです。まずこの3種類の構造を見分けてから内容を編集すると、リストを文字列として記述したり、トップレベルに置くべき項目を別のオブジェクトの内側にインデントしたりするミスを防げます。

YAML ではインデントで親子関係を表します。半角スペース2つに統一し、タブは使わないことをおすすめします。同じ階層の項目は左端をそろえ、リスト項目のハイフンの後にはスペースを入れます。キーの後のコロンにも、通常はスペースが必要です。以下の例では mode と dns が同じ階層にあり、enable は DNS オブジェクトの項目です。nameserver の2つの値は1つのリストに属します。空行は読みやすさのためのもので、階層には影響しません。

mixed-port: 7890
mode: rule

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

rules:
  - MATCH,DIRECT

真偽値には true または false、ポートには整数を使います。識別子として扱う値は文字列にしてください。パスワード、シャープ記号を含むアドレス、コロンを含む複雑な文字列は、コメントやマッピングの区切りと誤認されないよう、引用符で囲むのがおすすめです。シングルクォート内のバックスラッシュは通常そのまま扱われますが、ダブルクォートではエスケープ文字として機能します。Web ページから Windows のパスをコピーする際は、バックスラッシュの扱いに注意してください。コメントは引用符の外にある、構文上有効な位置のシャープ記号から始まります。

トップレベルの配置順は実行順ではない

rules をファイル末尾に置くのは読みやすさのためであり、コアが先にすべての項目を実行し、その後にルールを処理するという意味ではありません。順序が意味を持つのはルールのリストや、一部のプロキシグループにおける候補の並び順です。トップレベルキーの順序は通常、結果に影響しません。同じマッピング内で同じキーを重複して定義しないでください。パーサーによって、重複キーを拒否する場合と後の値を採用する場合があります。この違いを利用しても、確実なオーバーライドにはなりません。DNS を変更する場合は、ファイル末尾に2つ目のオブジェクトを追加せず、既存の DNS オブジェクトを編集してください。

元のサブスクリプション、クライアントが保存した設定、コアに渡される実行時ファイルも区別する必要があります。サブスクリプションにはノードだけが含まれる場合もあれば、プロキシグループやルール一式が含まれる場合もあります。クライアントは読み込み後に内容を再構成し、ポート、コントローラー、TUN の設定を追加することがあります。そのため、サブスクリプションのキャッシュを編集しても実行結果が変わるとは限らず、クライアントの再起動で変更が上書きされることもあります。問題を調べる際は、まずクライアント内で現在の設定、実行時設定、またはコア設定のプレビューを探し、元ファイルとの差分を記録してください。

構文が正しくても参照関係を確認する

YAML を解析できるのは、インデントやデータ形式が基本的に正しいことを示すだけで、現在のコアがすべての項目に対応しているとは限りません。存在しないプロキシグループをルールが参照している、プロキシグループが名前を間違えたノードを参照している、といった問題は設定の意味に関するエラーです。名前は通常、大文字と小文字を区別します。日本語の空白、末尾の空白、全角の句読点で名前が変わることもあります。先にプロキシグループとノードの名前を一覧にし、ルールの最後の項目と照合すると、インデントを何度も誤った場所で修正する手間を減らせます。

以降の各セクションにあるコードは部分的な例です。既存の設定に追加する場合は、同じ階層にある既存項目を残し、リストを項目ごとに統合してください。クライアントが必ずしも config.yaml という名前のファイルを使うとは限らず、起動オプションで別の名前を指定することもできます。判断基準は、実行中のコアが実際に読み込んでいるパスです。オリジナルの Clash と mihomo の項目の違いは、コアの変遷と互換性の比較をご覧ください。同じ設定でも、異なるコアで同じ結果になるとは限りません。

2. 共通項目：ポート、モード、アクセス範囲

受信ポートとシステムプロキシは別の設定

受信ポートは、コアがアプリからの接続を受け付ける入口です。port は HTTP プロキシ、socks-port は SOCKS、mixed-port は1つのポートで HTTP と SOCKS の両方を受け付けます。一般的なデスクトップ利用では、管理する入口を増やさずに済むよう、まずは混合ポート1つにしておくとよいでしょう。ポート番号はローカルで決めるもので、すべてのクライアントが使う固定の番号はありません。アプリに設定するプロキシアドレスは、実際の待ち受けアドレスと一致させてください。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

コアが正常に待ち受けていても、システムプロキシが有効とは限りません。システムプロキシは、対応アプリに対して、指定されたプロキシアドレスへ接続するようOSが通知する仕組みです。設定内の受信ポートは接続を受け付けるだけです。システムプロキシを無効にしても、プロキシアドレスを手動設定したアプリはコアを使い続けることがあります。逆に、コアを終了してもシステムプロキシが解除されていないと、ブラウザーは待ち受けていないポートへ接続しようとします。トラブル時はクライアントの全体スイッチだけで判断せず、プロセス、待ち受けポート、システムプロキシの状態をそれぞれ確認してください。

項目	意味	確認ポイント
`mixed-port`	HTTP と SOCKS の混合ポート	ローカルのポートが使用中でないか
`allow-lan`	LAN 内の端末からの接続を許可	待ち受け範囲とファイアウォールの設定が一致しているか
`mode`	通信の振り分け方法	rules による振り分けが有効か
`log-level`	ログの詳細度	一時的なトラブルシューティング後に適切なレベルへ戻す

rule、global、direct

rule はルールの順に接続の振り分け先を選びます。global はコアに入った接続をグローバル設定に渡します。direct は接続先へ直接接続します。モードが決めるのは、コアに入った後の処理方法であり、すべてのアプリの通信をコアに取り込む機能ではありません。そのため、グローバルモードは TUN の代わりにはならず、システムプロキシを無視するアプリにプロキシを強制することもできません。まず通信を取り込む範囲を解決し、その後で、取り込んだ接続の出口を選んでください。

日常利用の出発点としては、直接接続とプロキシの条件を個別に設定できるルールモードが一般的です。グローバルモードはルールの影響を一時的に切り分け、特定の出口が使えるかを確認するのに適しています。直連モードは比較テストに使えますが、受信や DNS などの影響が残る場合があります。テスト後は元のモードに戻し、実際の接続記録を確認してください。各モードの詳しい比較は3つのプロキシモードの選び方をご覧ください。特定のWebページが開けたことだけで、すべての振り分けが正しいと判断しないでください。

待ち受け範囲と管理インターフェース

allow-lan と bind-address は、他の端末から受信ポートへ接続できるかどうかに関わります。現在のPCだけで使う場合は、アクセス範囲をループバックアドレスに限定すると問題を切り分けやすくなります。スマートフォンと共有する場合は、LAN 接続を許可するだけでなく、待ち受けアドレスがLAN側のネットワークインターフェースを含むこと、2台が通信できること、ファイアウォールが該当する受信通信を許可していることも確認してください。待ち受けを公開することは、インターネットへ安全に公開することと同じではありません。ルーターのポート転送を設定すると、アクセス範囲は大きく変わります。

external-controller は管理インターフェースであり、ブラウザー用のプロキシポートではありません。コントロールパネルやクライアントからコアを管理するためのもので、アプリの HTTP プロキシ設定には使えません。クライアントが管理アドレスや認証情報を自動生成する場合があり、手動で上書きすると画面から接続できなくなることがあります。個別に管理する必要がなければ、クライアントの設定をそのまま使ってください。変更が必要な場合は、まずローカルアドレスにバインドし、認証を設定してください。管理用の認証情報を含む実行時ファイルを公開の掲示板などに貼り付けないでください。

ポートが競合する場合は、まず他のプロキシアプリを終了し、古いコアのプロセスが残っていないか確認してください。ポートを変更したら、設定を再読み込みし、手動でプロキシアドレスを設定しているアプリも更新する必要があります。log-level は一時的に debug にできますが、詳細ログには接続先ドメインや通信情報が含まれる場合があります。共有する前に機密情報を削除してください。クライアントを選び直す場合は、ダウンロードページでプラットフォーム別に確認できます。一般的なGUIでの利用なら、まず Clash Plus をご検討ください。

3. DNS：問い合わせ先、上流サーバー、ドメインとの関連付け

誰が誰に問い合わせるかを整理する

DNS 設定には少なくとも3つの役割があります。アプリやシステムが問い合わせを開始し、コアの DNS モジュールが受信して転送し、上流 DNS サーバーが結果を返します。dns.enable はコアの DNS モジュールを有効にし、listen は待ち受けアドレス、nameserver は上流サーバーを指定します。モジュールを有効にしただけでは、システムがその DNS を使うとは限りません。システムの DNS 設定、クライアントの通信取り込み機能、または TUN の横取りルールを使って、該当する問い合わせをこの入口へ送る必要があります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

この例では、既存のシステムサービスと共存しやすいよう、DNS サービスをローカルの標準外ポートに限定しています。DNS モジュールの構造を示す例であり、システムのリゾルバーを自動で変更するものではありません。default-nameserver は主に、上流 DNS サーバー自身のドメインを解決し、暗号化 DNS への接続を確立するための初期問い合わせに使われます。すべてのドメイン問い合わせに使うデフォルトの出口ではありません。上流サーバーにドメイン名を指定していて、初期問い合わせに失敗すると、DNS モジュール全体で安定して問い合わせられなくなることがあります。

fake-ip と redir-host の違い

fake-ip は問い合わせに対して対応付け用の仮想アドレスを割り当てます。コアは後続の接続でそのアドレスから元のドメインを特定し、ドメインルールと出口選択を適用します。このアドレスは接続先サーバーの実際のグローバル IP ではないため、アプリがこの値を取得しても DNS 障害とは限りません。redir-host は通常、実際の名前解決結果を返し、ドメインの関連付け方法も異なります。どちらを選ぶかは、アプリとの互換性や通信の取り込み経路に基づいて判断してください。速度や安全性の段階として捉えるものではありません。

一部のLAN内サービス、デバイス検出、実アドレスを前提とするアプリでは、仮想アドレスが適さない場合があります。fake-ip-filter を使うと指定したドメインへの仮想アドレス割り当てを回避できますが、フィルターが変えるのは DNS の応答方法だけで、DIRECT ルールを追加するわけではありません。LAN内の実アドレスへ接続するドメインでは、上流 DNS が内部名を解決できることと、後続のルーティングで該当ネットワークに到達できることも確認してください。トラブルシューティングでは、まず対象を1つ決めてフィルターを追加します。範囲の広すぎるワイルドカードを最初から入れないでください。

トップレベルの ipv6 と DNS オブジェクト内の同名項目は、作用する範囲が異なります。前者はコア全体の IPv6 利用可否、後者は DNS モジュールの IPv6 名前解決に影響します。DNS から IPv6 アドレスを返さない設定にしても、アプリの既存キャッシュ、内蔵リゾルバー、事前に保存されたアドレスの影響がなくなるとは限りません。ネットワークが IPv6 に対応している場合は、ルートと出口の対応状況を確認したうえで個別に有効にしてください。誤設定された IPv6 経路を隠すためだけに AAAA レコードを非表示にするのは避けてください。

振り分け用 DNS とプロキシサーバー用 DNS

nameserver-policy は特定のドメインに使用する DNS サーバーを指定します。社内ドメインや明確な名前解決要件がある場合に適しています。どの上流 DNS に問い合わせるかを決める項目であり、通信そのもののプロキシポリシーを決めるものではありません。proxy-server-nameserver はプロキシサーバーのドメイン名を個別に解決し、出口を確立する前にその出口を使ってサーバーアドレスを解決しようとする循環を防ぎます。循環や名前解決の差が確認できた場合に限って設定を追加し、複数の項目を同時に変更しないようにしてください。

dns:
  nameserver-policy:
    "+.internal.example.com":
      - 192.168.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

上記の内部ドメインとルーターアドレスは構造を示す例です。実際に管理している内部ドメインと、DNS サービスを提供するアドレスに置き換えてください。調査は、まずコアが問い合わせを受信しているか、次に上流へ到達できるか、最後に応答結果と後続の接続がドメインに正しく関連付けられているかの順に進めます。アプリ独自の暗号化 DNS はシステム設定を迂回することがあります。ブラウザーですでに確立済みの接続も、DNS を変更しただけではすぐに再接続されません。必要に応じて既存の接続を閉じ、関連キャッシュを消去してから同じ対象を再テストし、新しい設定の動作を確認してください。

4. プロキシノード：プロトコル項目とプロバイダー

共通項目とプロトコル固有の項目

proxies は静的なプロキシノードのリストで、各項目が1つの出口を表します。共通項目には、名前の name、プロトコルの type、サーバーの server、ポートの port があります。それ以外の項目はプロトコルによって異なるため、別のプロトコルの認証項目をそのまま流用できません。ノード名はプロキシグループやルールから参照するためのもので、認証には使いません。サーバーにはドメイン名またはアドレスを指定します。Webサイトのトップページ URL やパス付きのサブスクリプションリンクで代用することはできません。

proxies:
  - name: SS-Example
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

この例は Shadowsocks ノードの構造を示しています。サーバーのドメイン名とパスワードは説明用で、そのままでは接続できません。暗号化方式、ポート、認証情報をサーバーの設定と一致させてください。udp: true は、そのノードで UDP を使えるようにする設定です。UDP に対応していないサーバーに自動で転送機能を追加するものではありません。アプリで実際に UDP を使えるかどうかは、受信方式、プロキシグループ、サーバー、中間ネットワークのすべてが対応しているかによります。

TLS を使う接続では、接続先と証明書の検証に使うサーバー名を区別してください。接続先はクライアントが接続する場所を指定し、サーバー名は TLS ハンドシェイクと証明書検証に使います。環境によって両者が異なることはありますが、その場合はサーバー提供元が指定する正確な値を使う必要があります。証明書エラーが発生したら、システム時刻、サーバー名、証明書チェーン、接続先アドレスを確認してください。検証を無効にするのは避けてください。安全性が損なわれるだけでなく、誤ったサーバーに接続している問題を一時的に隠すことがあります。

ノードリストとサブスクリプション一式を混同しない

proxy-providers はノードリストを独立したソースに置き、メイン設定からプロバイダー名で参照します。ノードの更新とローカルのルールを別々に管理できます。プロバイダーが受け取るのは通常、proxies 構造を持つデータです。あらゆるサブスクリプション形式をそのまま読み込めるわけではありません。Base64 テキスト、単一の URI、完全な Clash YAML はそれぞれ構造が異なります。形式が合わない場合は、変換するかクライアントからインポートしてください。詳しくはサブスクリプションリンクの形式と変換方法をご覧ください。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

このプロバイダーはローカルファイルを使い、サブスクリプションURLは使いません。相対パスは通常、コアの作業ディレクトリまたはクライアントが指定した設定ディレクトリを基準にします。編集中のファイルがあるディレクトリとは限りません。ファイルが見つからない場合は、まず起動オプションとログに出ている最終パスを確認し、ファイルを読み取れることを確かめてください。ファイルの内容にはノードリストが必要です。メイン設定全体をコピーしても、コアが任意の階層からノードを自動抽出するわけではありません。クライアントが管理するディレクトリでは、アプリのサンドボックス権限が影響する場合もあります。

リモートプロバイダーでは通常、type: http を指定し、取得元URL、キャッシュパス、更新間隔を設定します。取得元URLにはアクセス認証情報が含まれる場合があるため、機密情報として扱い、スクリーンショットや公開リポジトリに載せないでください。更新に失敗した場合は、ネットワーク要求の失敗、認証エラー、YAML 以外の内容、非対応プロトコル項目の4つに分けて確認します。キャッシュがあれば、コアが古いノードを使い続けることがあります。画面にノードが表示されていても、直近の更新が成功した証拠にはなりません。

ヘルスチェックは実際のサービス利用を保証しない

ヘルスチェックは指定したURLを使ってノードの接続状態をテストします。結果はテスト先、名前解決経路、サーバーの応答に左右されます。テストに成功しても、そのチェック経路が使えるというだけで、すべてのWebサイト、UDP アプリ、地域限定サービスにアクセスできるとは限りません。プロバイダーのチェックとプロキシグループのチェックも、まったく同じ階層の機能ではありません。頻繁なチェックを重複して有効にすると、要求が増えます。テスト先を明確にし、適切な間隔を設定してください。まず単一ノードを確認してから、自動選択へ広げるのがおすすめです。

ノードの定義が正しく見えるのに使えない場合は、ハンドシェイク中に出た具体的なエラーを確認してください。ドメインの名前解決失敗は接続前のネットワーク問題、タイムアウトはアドレス、ポート、ファイアウォールなどが原因の可能性があります。認証エラーでは認証情報を確認し、プロトコル解析エラーでは種類とコアの互換性を確認します。すべての項目を一度に置き換えないでください。元の値を残し、サービス提供元のプロトコル情報と照合して1項目ずつ変更します。手動選択のプロキシグループで出口を固定してテストすると、自動切り替えによる問題の見落としを防げます。

5. プロキシグループ：参照関係と選択方法

プロキシグループは出口を選ぶレイヤー

proxy-groups はノード、他のプロキシグループ、組み込みポリシーをまとめ、ルールから参照できる選択先を作ります。ルールは通常、変わりにくいグループ名を参照し、グループ内で実際の出口を選びます。ノードリストを更新しても、すべての通信ルールを書き直す必要がありません。グループ名は設定間のインターフェースの一部です。名前を変更した場合は、すべての参照先も合わせて変更してください。名前の重複や循環参照は、設定を分かりにくくするだけでなく、読み込み失敗の原因にもなります。設計時には、ルールからグループ、グループからノードへ向かう一方向の参照図を作ると整理しやすくなります。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT
    use:
      - local-nodes

  - name: Auto
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 50

この例は前のセクションで定義した local-nodes プロバイダーを使います。proxies は候補名を明示的に列挙し、use はプロバイダー内のノードを取り込みます。名前の種類を相互に置き換えることはできません。Proxy は手動選択グループで、自動グループ、DIRECT、プロバイダーのノードを選択できます。Auto から Proxy を参照すると循環するため、避けてください。例を結合するときはプロバイダー定義を残す必要があります。プロキシグループだけをコピーすると、未定義の参照が発生します。

手動選択、自動テスト、フォールバック

select は候補を手動で選ぶ方式で、単一出口の確認や固定ポリシーに適しています。url-test はテスト結果に基づいて候補を選び、使用可能な出口を自動で管理したい場合に適しています。fallback は候補の順に使用可能なものを選ぶ方式で、メインと予備の関係が明確な設定に向いています。これらは順番に高度になるモードではありません。切り替えが許容されるか、出口を固定したいか、テストによる追加接続を許容できるかを基準に選んでください。

種類	選択基準	用途の目安
`select`	ユーザーが手動で選択	出口の固定、個別のトラブルシューティング
`url-test`	テスト結果と切り替えの許容差	候補となる出口を自動管理
`fallback`	順序と利用可能な状態	通常はメインを使用し、障害時は予備に切り替え
`load-balance`	指定した分散方式	複数の出口に接続を振り分ける

自動選択グループの interval はチェック間隔、tolerance はわずかなテスト結果の差による頻繁な切り替えを抑えるための設定です。ネットワーク遅延の目標値でも、高速化のスイッチでもありません。テスト先への応答が速いノードでも、ファイルのダウンロードや動画サービスが速いとは限りません。load-balance は接続を振り分けますが、通常の1つのダウンロード接続を複数ノードに分割して帯域を合算するものではありません。接続ごとに出口が変わると、サービス側でセッション状態に影響することもあります。

候補の絞り込みと選択状態

候補数の多いプロバイダーでは、フィルター条件で候補を絞り込めます。ただし、絞り込んだ後に候補が残っていることを確認してください。正規表現の特殊文字と YAML の引用符のルールが重なるため、ノード名を正規表現としてコピーすると、括弧、プラス記号、角括弧などに追加の処理が必要な場合があります。通信を開始する前に、クライアントで候補リストをプレビューしてください。トラフィックが空のグループに入ってから調べるより簡単です。サブスクリプションの命名規則がずっと同じとは限らず、名前が変わると既存のフィルター条件が機能しなくなることもあります。

手動選択グループの選択状態は、クライアントや profile.store-selected などの機能によって保存される場合があります。ファイルを再読み込みしても以前の選択が残るからといって、設定が反映されていないとは限りません。以前の実行状態を復元している可能性があります。候補を追加しても画面上で切り替わらない場合は、現在のグループで何が選択されているかを確認してください。逆に、選択中のノードを削除すると、コアやクライアントが別の利用可能な候補を選ぶことがあります。リストの先頭だけで最終的な出口を判断しないでください。

プロキシグループを調べるときは、まずルールがどのグループに一致したかを確認します。次に、そのグループで選択されている次の階層を展開し、最終ノードまたは組み込みポリシーにたどり着くまで確認してください。後続の参照関係を把握しないままログに表示されたグループ名だけを見ると、ノードの問題をルールの問題と誤認しやすくなります。分かりやすい手動テスト経路を1つ用意し、自動グループを何段も入れ子にしないことをおすすめします。OS ごとにクライアントを比較する場合は、選び方ガイドをご覧ください。画面上の表示が異なっても、内部の参照関係は変わりません。

6. ルール構文：マッチタイプ、順序、ルールセット

上から順に評価し、最初に一致したルールを適用

rules は順序を持つリストです。コアは接続を上から順に調べ、適用可能なルールに一致すると、指定されたポリシーに接続を渡します。後にある、より細かく見えるルールまで評価することはありません。そのため、個別の例外ルールは広い範囲を対象とするルールより前に置き、フォールバック用のルールは最後にします。ルールの順序は文書の見た目ではなく、実際の動作に関わります。広範囲に一致するルールを先頭へ移すと、その後にある多くの項目が機能しなくなる場合があります。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-KEYWORD,example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

通常、ルールはタイプ、マッチ対象、ポリシーを英語のカンマで区切って記述します。MATCH はマッチ対象が不要で、最終的なポリシーを直接指定します。ポリシーには組み込みの DIRECT、REJECT のほか、定義済みのプロキシグループ名やノード名を指定できます。英語のカンマを全角カンマに置き換えたり、ポリシー名に説明文を付けたりしないでください。例の Proxy はプロキシグループ名と完全に一致させる必要があります。一致しない場合、ルールの形式が正しく見えても参照は成立しません。

ドメインルールとアドレスルールの違い

DOMAIN は完全一致のドメインを、DOMAIN-SUFFIX はドメイン自体とそのサブドメインを、DOMAIN-KEYWORD はドメイン内に含まれるキーワードを対象にします。範囲を制御しやすいのは、無計画にキーワードを使うよりサフィックスでの指定です。ルールにはホスト名を指定し、プロトコル、パス、クエリを含む完全なURLは指定しません。同じWebサイト内の特定ページだけを区別したくても、通常のドメインルールでは対応できません。プロキシのルーティングでは、暗号化接続内のリクエストパスを参照できるとは限らないためです。

IP-CIDR は宛先の IPv4 ネットワーク範囲に一致します。IPv6 の範囲には対応する IP-CIDR6 ルールを使います。省略可能な no-resolve は、そのアドレスルールを確認するためだけにドメインの名前解決を開始しない設定です。接続全体でドメインを解決しないよう強制するものではありません。接続に利用可能な宛先アドレスがすでにある場合は、引き続きアドレスによる判定が行われます。不要な名前解決を避けるのに有効ですが、ドメイン名しか分からない接続がネットワーク範囲のルールを通らなくなる場合もあります。実際の通信に照らして判断してください。

GEOIP は IP アドレスのデータベース、GEOSITE はドメイン分類データに依存します。これらの分類はデータベースが管理するもので、サービスの属性が恒久的に固定されているわけではありません。複数地域の CDN を使うドメインでは、アドレスの所在地とサービスの地域が一致しない場合があります。想定外の振り分けが起きたら、まず一致したのがドメインルールかアドレスルールかを確認し、データファイルの有無と更新状況を調べてください。最初からすべてのノードを切り替えたり、DNS を無効にしたりするのは避けましょう。

ルールプロバイダーと behavior

rule-providers はルールの内容を外部ファイルに分離し、RULE-SET でメインのルールチェーンに取り込みます。プロバイダーの behavior は内容の形式を指定します。domain はドメインのマッチ項目、ipcidr はアドレスのネットワーク範囲、classical はルールタイプ付きの項目を格納します。形式が異なるデータは、項目を1つ変更するだけでは相互に切り替えられません。ファイルの内容も合わせる必要があります。取得元がプレーンテキストか YAML かも、形式の設定と一致させてください。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,Proxy

# ./rules/local-direct.yaml
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

ルールセット内では通常、最終ポリシーを指定しません。ポリシーはメイン設定の RULE-SET で指定します。上の例ではルールセット全体を DIRECT に渡し、メインのルールチェーンで出口を管理しやすくしています。リモートルールの更新に失敗してもキャッシュが使われる場合があるため、「引き続き一致する」ことは「更新済み」の証拠にはなりません。ルールを検証するには、対象を1つ決め、既存の接続を閉じて再アクセスし、一致したルール、プロキシグループ、最終出口を確認してください。すでに確立した長時間接続は、ルールを変更しても新しい順序で自動的に再接続されません。

7. TUN：仮想インターフェース、ルーティング、DNS の取り込み

TUN は通信の入口を担い、ルールの代わりにはならない

TUN は仮想ネットワークインターフェースとルーティングを使い、システムプロキシを利用しない通信をコアへ送ります。mode とは役割の階層が異なります。TUN は通信をどのように取り込むかを担い、ルールは取り込んだ後の処理を決めます。TUN を有効にしてもルールモードは引き続き使えます。また、ルートからの除外、インターフェースの選択、権限の問題で、一部の通信を取り込めない場合もあります。スイッチの状態だけで判断せず、対象アプリの通信がコアの接続記録に表示されるか確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable は仮想インターフェースを有効にし、stack はネットワークスタックの処理方式、auto-route は関連ルートの自動設定、auto-detect-interface は出口インターフェースの自動検出を指定します。mixed は mihomo が対応するスタックの選択肢の1つであり、すべてのOSにとって最適という意味ではありません。他のスタックの対応状況や動作は、使用中のコアとプラットフォームに基づいて判断してください。トラブルシューティングでは一度に1つのスタック設定だけを変更し、ログを比較できるよう残します。ルートの変更とスタックの変更を混同しないようにしてください。

DNS の横取りと暗号化 DNS の範囲

dns-hijack の any:53 は、該当する経路に入り、通常の DNS ポートを宛先とする問い合わせを取り込んで、コアの DNS モジュールに渡します。暗号化 DNS を一般的にブロックする機能ではありません。HTTPS 経由の DNS 問い合わせは通常の暗号化接続のように見えるため、宛先ポートが異なればこのルールで自動的に変換されることはありません。ブラウザーで独自の DNS 機能が有効な場合は、コアの上流設定を何度も変える前に、実際の問い合わせ経路を確認してください。

TUN と DNS モジュールは通常、連携して動作しますが、それぞれ別の設定です。DNS モジュールが無効、待ち受けポートが競合、上流サーバーに到達できないといった場合、通信は取り込めても名前解決に失敗することがあります。逆に、DNS の応答に成功しても、通信経路が正常とは限りません。既知のアドレスへの接続とドメインへのアクセスを別々にテストし、「アドレスへの接続失敗」と「名前解決失敗」を切り分けたうえで、ポリシー、出口、ルートを確認してください。

プラットフォームごとの権限とルート競合

デスクトップOSでは、インターフェースの作成やルート変更に管理者権限、特権サービス、またはOSの許可が必要なことが一般的です。クライアントがこれらの機能を管理する場合、YAML を直接変更してもOSの許可手続きの代わりにはなりません。Android クライアントは通常、VpnService を通じて通信の取り込み許可を得ます。システムに表示される VPN の許可画面は、デスクトップの仮想ネットワークインターフェースとは仕組みが異なります。iOS クライアントは対応するネットワーク拡張機能を利用するため、デスクトップ用の項目をモバイル画面へそのまま当てはめないでください。

症状	まず確認する項目	次の手順
仮想インターフェースを作成できない	システムの許可、サービスの状態	コア起動時のエラーを確認
ドメインでは失敗するが、IPアドレスには到達できる	DNS モジュールと問い合わせ経路	名前解決ログを確認
社内ネットワークにアクセスできない	社内ルートと他の VPN	対象ネットワークの除外設定を確認
スリープ復帰後に接続が不安定	インターフェースの変更と既存接続	出口を再検出して再テスト

企業 VPN、仮想マシンのネットワーク、コンテナブリッジ、他のプロキシツールが同時にルートを変更することがあります。自動検出で不適切なインターフェースが選ばれると、通信の迂回やループが起きる場合があります。まず他の通信取り込みツールを終了し、現在のルート情報を保存したうえで、クライアントを1つだけ有効にしてテストしてください。複数のツールを同時に使う場合は、どのネットワーク範囲を企業 VPN に、どの通信をプロキシコアに渡すのか明確にします。再起動を繰り返して解決を待つのは避けてください。次にネットワークインターフェースの順序が変わると、同じ問題が再発する可能性があります。

ルーティング制約を厳しくすると、LAN へのアクセス、テザリング、他の VPN の動作が変わることがあります。関連するスイッチを万能の修復手段として扱わないでください。まず最小限の TUN 設定を作り、問題を確認してから除外項目やプラットフォーム固有の設定を追加します。スリープからの復帰やネットワーク切り替えの後は、システムプロキシと仮想インターフェースが想定どおりの状態に戻っているかも確認してください。具体的な手順はTUN の仕組みと通信の取り込み手順をご覧ください。Android でバックグラウンド動作がシステムに停止される場合は、VpnService とバッテリー最適化の除外設定もご確認ください。原因が YAML とは限りません。

8. オーバーライド、マージ、実行時の検証

設定の読み込み元を確認し、マージ方法を決める

オーバーライドとは、サブスクリプションやローカル設定を読み込む際に、クライアントが一部の項目を置き換えたり、追加したり、再構成したりする処理です。YAML 言語に共通の機能として備わっているものではなく、すべての Clash クライアントに共通するマージ順もありません。同じ画面上の名称でも、クライアントによって浅い階層での置換、再帰的なマージ、スクリプト処理を意味する場合があります。変更前にクライアントのオーバーライド仕様を確認し、対象が現在の設定か全設定か、サブスクリプション更新後も処理されるかを確かめてください。

マッピングとリストは特に分けて考える必要があります。DNS オブジェクトを再帰的にマージすると、変更していない上流項目が残る場合があります。オブジェクト全体を置き換えると、元のオブジェクトにあった他の設定が削除されます。ルールリストを置き換えると、サブスクリプションの既存ルールが失われます。追加する方式でも、元の設定にある MATCH が先にあると、新しいルールに一致しない場合があります。ノードとプロキシグループのリストには名前の参照関係もあるため、2つのファイルを単純に連結しただけで有効になるとは限りません。

# 元の設定にある DNS オブジェクト
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

# クライアントのオーバーライドで追加したい項目
# これは別の入力であり、dns キーを2つ目としてそのまま追加してはいけません。
# dns:
#   ipv6: false

上の例で目指しているのは、元の DNS オブジェクトに ipv6: false を追加することであり、既存の有効状態、解析モード、上流サーバーを削除することではありません。このようにマージできるかどうかは、クライアントの実装によります。保存後は実行時プレビューを開き、4つの項目がすべて残っているか確認してください。クライアントが設定全体の置き換えにしか対応していない場合は、オーバーライド側に残す項目も明記し、暗黙の動作に依存して通信を維持しないようにしてください。

サブスクリプション更新とローカル変更の保存先

サブスクリプションからダウンロードしたキャッシュファイルを直接編集すると、次回の更新でリモートの内容に上書きされることがあります。より確実な方法は、個人用ルール、DNS の設定、ポートの指定をクライアントが対応する永続オーバーライドに保存するか、独立したローカル設定を管理し、プロバイダー経由でリモートノードを参照することです。どちらにも手間があります。前者はクライアントのマージ機能に依存し、後者はプロキシグループやルールを自分で管理する必要があります。選ぶ前に、サブスクリプションが管理する項目とローカルで管理する項目を明確にしてください。

ノードやプロキシグループの名前を変更する場合は、名前を設定をまたぐ参照インターフェースとして扱ってください。最終的なノードとグループを作ってから、ルールの参照先を確認します。項目を削除する前に、他のグループから参照されていないか検索してください。サブスクリプション変換サービスが名前、ルール、グループを再構成することもあるため、変換前後のテキストは同じ構造とは限りません。機密性の高いサブスクリプションURLを扱う場合は、信頼できるローカルの処理方法を優先し、設定を共有する前にURLの認証情報を削除してください。

構文テスト、読み込み確認、接続の再テスト

コマンドライン版のコアを利用できる場合は、テスト用オプションで設定が現在のバイナリから読み込めるか確認できます。テストにはクライアントと同じコアと関連データディレクトリを使ってください。別の実行ファイルでテストに成功しても、GUI クライアントのコアが同じ項目に対応しているとは限りません。プロバイダーファイルや地理データが含まれる場合は、テスト環境からそれらにアクセスできることも確認します。テスト結果は設定上の問題を見つけるためのもので、実際のネットワーク接続の検証に代わるものではありません。

mihomo -t -f ./config.yaml

検証は4段階で進められます。まずバックアップを保存して構文テストを行い、次にクライアントから設定を再読み込みします。その後、ログで新しい設定が受け入れられたことを確認し、最後に既存の接続を閉じて対象を1つテストします。実行時ファイルを見れば項目が保持されているか確認でき、接続記録を見ればルールと出口が想定どおりか確認できます。保存ボタンを押しただけで読み込みが実行されていない場合や、編集中のファイルが現在の設定ではない場合、ネットワークの動作は変わりません。

変更内容を記録しておくと役立ちます。今回変更した項目、期待する結果、実際の結果、元に戻す方法を書き留めてください。1回に1つの階層だけを変更し、検証できてから次へ進みます。詳細ログはトラブルシューティング中だけ有効にし、共有する前にサブスクリプションの認証情報、サーバーの認証情報、不要なアクセス記録を削除してください。クライアントの状態自体に問題がある場合は、使い方ガイドに戻ってインポート、モード、接続手順を確認してください。クライアントを入れ替える場合は、ダウンロードページでプラットフォームに合ったものを選び、すべての問題を設定ファイルの破損と決めつけないようにしましょう。