config.yamlの各項目を解説：ポート・DNS・proxies・proxy-groups・rulesの役割

1. 設定ファイルの構造と実際の適用順

config.yamlには、接続の入口、名前解決、利用できる出口、出口の選択ルールを記述します。「アプリの通信 → ローカルポートまたはTUN → ルール判定 → プロキシグループ → ノードまたはDIRECT」の流れで見ると理解しやすくなります。DNSはドメイン名の解決を担いますが、すべての接続が必ず同じDNS経路を通るわけではありません。

この記事では、一般的なファイルの記述順に沿って解説します。YAMLのトップレベル項目は通常、順序を入れ替えられます。dnsをrulesより前に書いても、ルールより優先されるわけではありません。実際に順序が影響するのは、rules内のルール一覧です。対応するプロトコルや一部の項目は使用するコアによって異なり、従来のClashとClash Meta（現mihomo）ですべての設定機能が共通しているわけではありません。

トップレベルのマッピング：dns:やproxies:などの項目は行頭から記述します。
ネストのインデント：各階層は半角スペース2つでインデントし、Tabは使わないのが基本です。リスト項目の前には- を付けます。
名前の参照：プロキシグループ名とノード名は文字列で完全一致させます。大文字・小文字や空白も一致させてください。
クライアントによる設定生成：サブスクリプション、オーバーライド、マージスクリプト、画面上の設定が組み合わさり、実行用の設定が生成されることがあります。ディスク上のYAMLを編集しても、コアの動作がすぐに変わるとは限りません。

2. ポート、動作モード、管理API

ポート項目は、クライアントがローカルで接続を受け付ける場所を指定します。リモートノードのサーバーポートではありません。ここでは混合プロキシの入口として7890を例にします。数値は説明用のため、実際の設定やポートの使用状況に合わせてください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

項目	役割	設定時のポイント
`port`	HTTPプロキシの入口	HTTPプロキシとCONNECTトンネルに対応します。Webサーバー用のポートではありません。
`socks-port`	SOCKSプロキシの入口	アプリ側でSOCKSプロキシを明示的に選択する必要があります。
`mixed-port`	HTTP・SOCKS共用の入口	同じ待ち受けポートで2種類のプロキシ接続を受け付けます。アプリ側では適切なプロトコルを選んでください。
`allow-lan`	LANからの接続を許可するか	LANで共有するには、待ち受けアドレス、システムのファイアウォール、アクセス認証も確認が必要です。
`mode`	動作モード	`rule`はルールに従って出口を選択し、`global`はグローバルポリシーを使用、`direct`は直接接続します。
`external-controller`	管理APIの待ち受けアドレス	状態の確認やポリシーの切り替えに使います。アプリのプロキシ接続先ではありません。

7890と9090を混同してはいけない理由

実行中の設定でmixed-portが7890なら、ブラウザーの手動プロキシにはホスト127.0.0.1、ポート7890を指定します。別途external-controller: 127.0.0.1:9090が設定されている場合、9090は管理API用です。ブラウザーのプロキシ設定に入力すると接続に失敗します。

管理APIはループバックアドレスにバインドし、専用のsecretを設定するのが基本です。LANプロキシを有効にする場合も、管理APIまで全ネットワークインターフェースに公開しないでください。システムプロキシの切り替えは通常、クライアントの画面で管理します。mixed-portだけ変更しても、すべてのアプリが自動で新しいポートを使うとは限りません。

3. dns：DNSサーバー、待ち受けアドレス、Fake-IP

dnsセクションでは、コアのDNS機能を設定します。enableは有効・無効、listenはDNSの待ち受けアドレス、nameserverは上流のDNSサーバーを指定します。DNSの待ち受けポートはHTTPやSOCKSのポートとは別のサービスです。プロキシ用ポートをDNSサーバーのポートとして使うことはできません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

この例では、ループバックアドレスの1053番ポートでDNSサービスを提供します。記載したIPアドレスの上流サーバーは通常のDNSを使用し、暗号化された名前解決を意味するものではありません。この待ち受けを起動しただけでは、OSのDNS設定は自動で変更されません。アプリやOSの名前解決経路、またはTUNのDNSハイジャックを別途設定する必要があります。

Fake-IPのアドレスは実サーバーのアドレスではない

fake-ipモードでは、設定されたアドレス範囲から合成アドレスを割り当て、コアがそのアドレスとドメイン名の対応を保持します。これにより、後続の接続をドメイン名に基づいて処理できます。名前解決結果が198.18.で始まっていても、まず接続が引き続きコアによって処理されているか確認してください。リモートサイトの実IPだとすぐに判断しないでください。

アプリとの互換性：デバイス検出やゲームなど、実際の名前解決結果に依存するアプリでは、fake-ip-filterの設定を個別に確認してください。最初から広範囲のワイルドカードを追加するのは避けましょう。
上流DNSへの到達性：現在のネットワークから選択したDNSサーバーにアクセスできるか、まず確認してください。暗号化DNSを追加する場合は、サーバーのドメイン名を最初に解決する方法も考慮します。
上級項目：mihomoのrespect-rulesやproxy-server-nameserverなどは、それぞれ経路制御や名前解決に関する用途があります。使用中のコアのドキュメントに従って設定し、DNSリクエストの送信ポリシーと通常の通信ルールを混同しないでください。

調査時は、ポートを指定できる環境でdig @127.0.0.1 -p 1053 example.comを実行し、応答があるか確認できます。このコマンドで確認できるのは、指定したDNS待ち受けが応答するかどうかです。OSの通信がコアに取り込まれていることや、ノードに接続できることまでは証明できません。

4. proxies：ノード定義とプロトコルのパラメーター

proxiesはノードオブジェクトのリストです。各オブジェクトには通常、name、type、server、portが含まれ、その他の項目はプロトコルによって異なります。たとえばShadowsocksではcipherとpasswordを使います。ほかのプロトコルではUUID、TLS、トランスポート層のパラメーターが必要な場合があります。typeだけ変更しても、プロトコルを切り替えることはできません。

proxies:
  - name: "ローカルテストノード"
    type: ss
    server: 127.0.0.1
    port: 8388
    cipher: aes-128-gcm
    password: "local-demo-only"

ノード名とサーバーアドレスは別の項目

nameはプロキシグループからの参照や画面表示に使う識別名で、serverが接続先です。「ローカルテストノード」の名前を変更したら、それを参照しているプロキシグループの設定も変更してください。ノードのport: 8388はサーバー側のポートで、ローカルのmixed-port: 7890とは数値上の関連はありません。

コロンやシャープ記号を含む文字列、または真偽値として解釈されやすい文字列は、引用符で囲むことをおすすめします。認証情報も文字列として扱ってください。設定やログを共有する際は、パスワード、トークン、サブスクリプションURL全体を隠してください。ノードの表示名だけを変更しても、機密情報は削除されません。

5. proxy-groups：ルールとノードをつなぐポリシー層

proxy-groupsでは、ノードやほかのプロキシグループをまとめ、ルールから参照できる出口を定義します。ルールからは通常、変更されにくいグループ名を指定し、サブスクリプション更新時にグループ内のノードを入れ替えます。「どの通信をここに流すか」と「現在どのノードを使うか」を分けて管理できます。

proxy-groups:
  - name: "手動出口"
    type: select
    proxies:
      - "ローカルテストノード"
      - DIRECT

select：ユーザーまたは管理APIがメンバーを選択します。出口を明示的に指定したい場合に適しています。
url-test：接続テストの結果に基づいてメンバーを自動選択します。テストURL、間隔、許容差が選択に影響しますが、実際のダウンロード速度と同じとは限りません。
fallback：リストの順に利用可能なメンバーを選びます。主系・予備系の切り替えに適しており、遅延の低い順に並べ替える方式ではありません。
load-balance：対応する分散方式に基づいて接続ごとにメンバーを選択します。通常の1接続を複数ノードの帯域に自動で束ねる機能ではありません。

上のリストは、前のセクションで定義した「ローカルテストノード」と、組み込みの出口DIRECTを参照しています。ノードを削除して参照だけ残すと、設定エラーになります。グループから別のグループを参照することもできますが、AがBを参照し、BがAを参照するような循環依存は避けてください。

サブスクリプションのノードがproxiesに直接記述されているとは限らない

proxy-providersを使う設定では、プロバイダーからノードを読み込めます。プロキシグループはuseでプロバイダー名を参照します。そのため、トップレベルのproxies: []だけを見てノードがないと判断しないでください。プロバイダーの読み込み状況、グループ内のuse設定、画面上のフィルター条件も確認しましょう。

6. rules：上から順に判定し、合致したルールの出口を選択

mode: ruleでは、コアがリストの上から順にルールを判定し、最初に合致したルールで指定されたポリシーを使います。一般的な構成は「ルールの種類、照合する内容、接続先の出口」です。MATCHには照合内容が不要で、通常は最後に置いて、ほかのルールに合致しなかった接続を処理します。

rules:
  - DOMAIN,example.com,手動出口
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動出口

ルール	対象範囲	確認ポイント
`DOMAIN`	ドメイン名の完全一致	`example.com`はサブドメインを自動では含みません。
`DOMAIN-SUFFIX`	ドメイン名とそのサブドメイン	`example.org`は`www.example.org`にも適用されます。
`IP-CIDR`	宛先のIPv4ネットワーク範囲	`no-resolve`は、このルールのためだけにドメイン名を積極的に解決するのを防ぎます。すべてのDNSを無効にする設定ではありません。
`RULE-SET`	ルールプロバイダーを参照	対応する`rule-providers`の定義と、利用可能なルールデータが必要です。
`MATCH`	残りの接続	前に置くと、後続ルールが判定されなくなります。

「LANはDIRECT」というルールは、例にある192.168.0.0/16だけですべての環境をカバーできるわけではありません。実際のネットワークでは10.0.0.0/8、172.16.0.0/12、IPv6アドレスが使われることもあります。例を完全なルール一覧と見なさず、ローカルのネットワーク範囲やサービス検出の方式に合わせてルールを追加してください。

MATCH,手動出口を1行目に移動すると、後続のドメインルールは実行されません。「ルールを書いたのに反映されない」場合は、まずルールモードになっているか確認し、次に前方のルールとクライアントが追加したオーバーライドを確認します。最後に接続ログで、合致したルールと実際の出口を確認してください。

7. 最小構成のサンプルとTUNの役割

次は、構造を確認するための最小構成です。混合ポート、コアのDNS、ルールモードを有効にし、DIRECTだけをメンバーに持つプロキシグループを定義しています。リモートプロキシ機能はありません。まずYAMLを読み込めるか、ポートが待ち受けているか、グループ名の参照が一致しているか確認するのに使えます。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

proxies: []

proxy-groups:
  - name: "手動出口"
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,手動出口

TUNは通信を取り込む入口であり、ルールの代わりにはならない

TUNは仮想ネットワークインターフェースを通じて通信を取り込みます。システムプロキシに従わないアプリでよく使われます。proxiesの一部ではなく、ノードの認証情報の誤りを自動で修正する機能もありません。関連項目に対応したmihomoを例に、既存の設定へ次の記述を追加できます。従来のClashを含むすべてのコアで共通して使える設定ではありません。

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

実際に有効化するには、OSの権限、利用可能な仮想ネットワークインターフェース、適切なルーティングが必要です。dns-hijackは、その通信経路に入った対象のDNS通信を処理します。アプリ独自のHTTPS暗号化DNSまで必ず捕捉するわけではありません。クライアントの画面でTUNを管理している場合は、生成後の設定を先に確認し、複数箇所で相反する設定を管理しないようにしてください。

8. 変更・検証・ロールバックの手順

バックアップを取る：現在のProfileを書き出し、選択中のプロキシグループのメンバーを記録します。サブスクリプションの元ファイルとローカルのオーバーライドもそれぞれバックアップしてください。
一度に変更するのは1種類だけ：まずポートを変更して検証し、次にDNS、最後にノード、グループ、ルールを調整します。コアの変更、TUNの有効化、DNS設定一式の置き換えを同時に行うのは避けてください。
設定を検証する：mihomoのコマンドラインを使い、設定ファイルが現在のディレクトリにある場合は、mihomo -t -f ./config.yamlを実行します。ほかのコアでは、まず-hでオプションを確認してください。コマンドラインの検証に通っても、ネットワークに接続できるとは限りません。
実際の実行設定を確認する：再読み込み後にログを確認し、YAMLの解析エラー、参照先のないノード、待ち受けアドレスの競合などがないかチェックします。
段階的に検証する：ローカルの入口、DNS応答、ノード接続、ルールの適用を順に確認します。接続ログでは、宛先ドメイン、適用されたルール、プロキシグループ、最終的に選ばれたメンバーを記録してください。
問題が起きたらロールバックする：直前に使えていたProfileへ戻し、システムプロキシまたはTUNの設定も元に戻してから、変更箇所を特定します。原因を覆い隠すように、出所不明の設定を次々と読み込まないでください。

エラーの症状から該当項目を特定

読み込み時に行番号が表示される：まずインデント、引用符、コロン、リストの書式を確認し、次にエラー行の直前で構造が途切れていないか調べます。
プロキシまたはポリシーが見つからないと表示される：rules、proxy-groups、proxies間の名前の参照を確認してください。
アドレスが使用中と表示される：7890や1053など、現在の設定で使っているポートを、別のプロセスや別のコアが使用していないか確認してください。
名前解決はできるが接続できない：ノードのサーバー、プロトコルのパラメーター、現在選択中のメンバー、外向きのネットワークを確認してください。DNSだけを繰り返し変更しないでください。
更新後に手動変更が消える：編集したファイルがサブスクリプションのキャッシュではないか確認します。保持したい設定は、クライアントが対応するオーバーライドやマージ機能へ移してください。

設定を読むときは、まず入口となるポートを確認し、次にルールが参照するグループとそのメンバーを追い、最後にDNSとTUNの適用条件を個別に確認します。この関係を理解すれば、「ファイルを読み込める」「ルールに合致した」「接続できる」という異なる状態を見分けられます。詳しい手順は上級設定を、各項目の意味は用語集を参照してください。