Clash 上級設定マニュアル

設定レイヤーと編集箇所

各パラメータを調整し始める前に、実際に有効な設定がどのレイヤーで構成されているかを把握しましょう。レイヤー構造を理解すると、自分の変更がサブスクリプション更新で上書きされるかどうか、カスタム内容をどこに書くべきかが分かります。

4つのレイヤーの優先順位

Clash Verge の実行時設定は4つのレイヤーが重なって構成されます。優先順位は低い方から順に次のとおりです。

• サブスクリプション設定:サブスクリプション URL から取得した元の YAML、または手動でインポートしたローカルファイル。このレイヤーはサービス提供者または自分自身が管理し、クライアントはサブスクリプションを更新するたびに新しい内容で全体を置き換えます。
• ローカル設定:クライアントに内蔵された基本セクション。通常はポートやモードなどのフィールドのみを提供し、編集は可能ですが用途は限られます。
• 上書き設定:サブスクリプション設定に差分変更を加える YAML。prepend / append のマージ命令に対応します。サブスクリプション更新後も上書きは有効で、長期間の使用で最も重要なカスタムレイヤーです。
• スクリプト設定:マージ完了後に最終設定へプログラム的な変更を加える JavaScript。条件分岐や一括生成が必要な場面に向いています。

実行時の最終設定 = サブスクリプション → ローカル → 上書き → スクリプト。後のレイヤーが前のレイヤーと同じキーを上書きします。「変更したのに反映されない」ときは、まずこの流れに沿って、より上位のレイヤーが値を戻していないか確認してください。

設定ファイルの保存場所とバックアップ

各プラットフォームのデフォルトパス:

• Windows:%APPDATA%\clash-verge\profiles\
• macOS:~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/
• Linux:~/.config/clash-verge/profiles/

各サブスクリプションには UUID 名のディレクトリが対応し、その中の config.yaml が取得後の元の内容、merge.yaml と script.js がそれぞれ上書きとスクリプトです。バックアップは profiles ディレクトリごとコピーすれば OK です。手動で調整したい場合は、「設定」ページで対象のサブスクリプションを選び、「編集」から上書きまたはスクリプトに入るのがおすすめです。取得した config.yaml を直接編集すると、次回のサブスクリプション更新で変更が消えてしまいます。

共通フィールド早見表

以下のフィールドは mihomo コアが直接読み取るもので、設定のトップレベルに書きます。どのサブスクリプションでも使われます。

設定例 · トップレベルの共通フィールド

port: 7890              # HTTP プロキシポート
socks-port: 7891        # SOCKS5 プロキシポート
allow-lan: false        # LAN 内のデバイスからの接続を許可するか
mode: rule              # rule / global / direct
log-level: info         # silent / error / warning / info / debug
ipv6: false             # IPv6 トラフィックを処理するか
external-controller: 127.0.0.1:9090
secret: ""              # コントロール API のアクセストークン

• mode: rule はルールに基づく振り分け、global はすべてプロキシ経由、direct はすべて直接接続です。通常は rule のままにします。
• log-level を debug にすると、各接続がどのルールに一致したかがログに表示され、トラブルシューティングに役立ちます。確認が終わったら info に戻すのを忘れずに。
• allow-lan を有効にすると、同じ LAN 内のスマホやタブレットから手動でプロキシをこの PC に向けられます。その際は OS のファイアウォールで該当ポートを許可してください。

編集と検証

YAML を編集したら、まず「設定」ページのデバッグボタンを押すか、ログウィンドウにパースエラーがないか確認します。よくあるエラーは3種類:インデントにタブを使っている(スペースを使う必要があります)、コロンの後にスペースがない、引用符が閉じていない。mihomo のエラーは行番号まで表示されるので、行番号に従って戻って確認できます。設定全体のセクション構造は《Clash 設定ファイル YAML 構造のセクション別解説》と併せて読むと理解が深まります。

プロキシグループの種類と実践

プロキシグループ(proxy-groups)は、ノード群がどのようなロジックで選ばれるかを決めます。ルールが最終的に指すのは個々のノードではなく、多くの場合プロキシグループです。グループをきちんと設定すれば、ルールレイヤーはシンプルになります。

5つの内蔵タイプ

select:手動選択。パネルでクリックしたノードを使います。「メインノード」など、いつでも切り替えたいグループに向いています。

設定例 · select グループ

- name: メイン
  type: select
  proxies:
    - 香港 01
    - 日本 01
    - ダイレクト

url-test:自動スピードテスト。定期的に全メンバーへテストリクエストを送り、遅延が最も低いノードを選びます。interval はテスト間隔(秒)、tolerance は許容差(ミリ秒)。2つのノードの遅延差が許容差未満の場合は現在のノードを維持し、頻繁な切り替えを防ぎます。

fallback:リスト順に使用し、現在のノードが利用できなくなったら自動的に次のノードへ切り替えます。「特定の回線を優先し、落ちたら別の回線に切り替えたい」という場面に向いています。

load-balance:負荷分散。接続を複数のノードに分散します。strategy は consistent-hashing(同一ドメインを同一ノードに固定。互換性が最も高い)、round-robin(順番に割り当て)、sticky(セッション維持)に対応。ダウンロードや大容量通信の場面では、このグループで複数回線を最大限活用できます。

relay:チェーンプロキシ。トラフィックがグループ内の順番に各ノードを経由します。「出口ノード」の組み合わせによく使われます。relay は対応プロトコルが限られており、一部のプロバイダのノードはチェーン転送に対応していません。有効にする前にパネルでノードごとに動作確認してください。

特殊グループとネスト

DIRECT と REJECT はプロキシグループではありませんが、proxies リストに記述でき、それぞれ直接接続と拒否を表します。プロキシグループはネスト可能です。外側のグループが内側のグループを参照し、ルールは最も外側のグループだけを指せば OK です。mihomo は include-all: true で設定内の全ノードを自動的に含めることも、include-other-group で他のグループのメンバーを参照することもできます。サブスクリプションのノードが頻繁に変わる場合、この2つのパラメータでメンテナンスを大幅に減らせます。

実践テンプレート

設定例 · ストリーミング / ゲーム / ダウンロードの3グループテンプレート

proxy-groups:
  - name: ストリーミング
    type: url-test
    proxies: [香港 01, 香港 02, 日本 01]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: ゲーム
    type: fallback
    proxies: [香港 01, 日本 01, ダイレクト]
  - name: ダウンロード
    type: load-balance
    proxies: [香港 01, 香港 02]
    strategy: consistent-hashing
  - name: メイン
    type: select
    proxies: [ストリーミング, ゲーム, ダウンロード, ダイレクト]

• ストリーミンググループは url-test で最速の回線を自動選択します。tolerance は 50ms に設定し、数ミリ秒の差で切り替わって再生が途切れるのを防ぎます。
• ゲームグループは fallback を使います。優先回線の遅延が上がっただけで切れていない場合、url-test は切り替えてしまいますが、fallback は本当に利用できなくなったときだけ切り替えるため、長い接続に向いています。
• テスト URL には http://www.gstatic.com/generate_204 を使います。204 を返すだけでトラフィックを消費しません。アクセスできない場合は http://cp.cloudflare.com/generate_204 に変更してください。

よくある誤解

• tolerance を 0 に設定:遅延差 1ms で切り替わるため、短い接続の場面で頻繁に切断されます。
• select グループに数十個のノードを詰め込む:パネルの選択リストが非常に長くなります。自動グループにノードを任せ、select はグループだけを参照するのがおすすめです。
• デフォルトで有効な lazy を無視する:最初はスピードテストが実行されず、パネルに表示される遅延はプレースホルダーです。すぐに数値を見たい場合は手動でスピードテストを実行してください。
• グループ名の大文字小文字が一致していない:ルール内のグループ名参照は大文字小文字を区別します。間違えてもエラーにはならず、トラフィックがフォールバックポリシーに落ちます。

ルールセットの管理

ルール(rules)は設定の中で最も肥大化しやすい部分です。数百件のルールをメイン設定に直接書くと、読みにくいうえ、サブスクリプション更新で上書きされます。ルールセット(rule-providers)はルールを独立したファイルに分け、個別に更新し、メイン設定には参照だけを残します。

ルールセットの3つの動作

behavior がルールセットの解析方法を決めます:

• domain:内容はドメインリスト。1行に1ドメインで、+ 始まりはサフィックスマッチを意味します。自分で管理するサイトリストに向いています。
• ipcidr:内容は IP または CIDR レンジ。IP ルールに使います。
• classical:完全なルール構文。1行に1ルールで、DOMAIN,xxx,ポリシー や IP-CIDR,1.2.3.0/24,ポリシー の形式。最も柔軟です。

リモートとローカルのルールセット

設定例 · rule-providers の2つのソース

rule-providers:
  geosite:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/geosite.yaml"
    path: ./rules/geosite.yaml
    interval: 86400
  my-custom:
    type: file
    behavior: classical
    format: text
    path: ./rules/custom.txt

• type: http はリモート取得を表し、interval は自動更新間隔(秒)です。86400 は1日1回を意味します。path はローカルキャッシュパスで、取得に失敗した場合もコアはキャッシュを使って動作し続けます。
• type: file はローカルファイルを表します。自分で管理するルールに向いており、リモート更新の対象になりません。
• format: yaml の場合は内容を YAML リストで書きます。format: text の場合は1行に1エントリで、プレーンテキストの習慣に近くなります。

rules での参照

設定例 · RULE-SET 参照

rules:
  - RULE-SET,geosite,ストリーミング
  - RULE-SET,my-custom,ダイレクト
  - MATCH,メイン

RULE-SET の1つ目の引数はルールセット名、2つ目の引数は一致したときのプロキシグループです。ルールセット内部が classical 動作で各ルールがポリシーを内包している場合、2つ目の引数は省略できます。

更新とメンテナンス

• リモートルールセットは「サブスクリプション」ページから個別に更新できます。interval の期限が来れば自動更新もされます。
• サブスクリプション更新はルールセットに触れません。ルールセットは独立したファイルであり、これがルールをメイン設定から分離する最大の利点です。
• ルールセットファイルにはリスト以外の余計な内容を書かないでください。format: yaml モードではトップレベルがリストである必要があります。形式を間違えるとルールセット全体の読み込みに失敗し、対応するルールがすべて無効になって、トラフィックがフォールバックポリシーに落ちます。
• ルールセットが有効かどうかの確認:ログウィンドウで rule-provider を検索すると、読み込みと更新の記録が見られます。debug ログでは各接続が一致したルールも確認できます。

振り分けの考え方

一般的な構成は「ドメインルールセット + IP ルールセット + フォールバック」の3層です。まず広告・トラッキングドメインを REJECT し、次にストリーミングドメインをストリーミンググループへ、続いて中国国内ドメインを直接接続にし、最後に MATCH でメイングループへ流します。mihomo は上から順にマッチし、最初に一致したルールが有効になるため、REJECT と直接接続のルールは前に置く必要があります。

DNS 設定の最適化

DNS は振り分け品質の分かれ目です。ドメインの解決結果が、接続がプロキシ経由になるか直接接続になるかを直接決めます。設定が不適切だと、「プロキシ経由にすべきものが直接接続になる」「DNS リーク」「解決タイムアウト」の3種類の問題が発生します。

dns セクションの基本構造

設定例 · 中国国内 DoH をメイン + 海外 DoH をフォールバック

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geosite: geolocation-!cn

• default-nameserver は DNS サーバー自身のドメインを解決するためだけに使われ、IP アドレスで書く必要があります。そうしないと起動時にまず DNS 解決で止まってしまいます。
• nameserver はメインの解決チャネルです。中国国内の DoH(アリババ、テンセント)は速く、国内ドメインの解決精度も高いです。
• fallback は予備チャネルで、メインチャネルの結果が fallback-filter で異常と判定されたときに使われます。geoip: true と geosite: geolocation-!cn の組み合わせは、nameserver が返した IP が海外で、かつドメインが中国国内ドメインでない場合に fallback で再解決するという意味です。これは中国国内 DNS による海外ドメイン解決の汚染を防ぐ標準的な方法です。
• ipv6: false の場合、システムに IPv6 があっても mihomo は A レコードのみを要求します。IPv6 の出口が必要になったら有効にしてください。

enhanced-mode の選び方

fake-ip:ドメインを実際に解決せず、fake-ip-range(デフォルト 198.18.0.1/16)内の仮想 IP に直接マッピングします。アプリは仮想 IP に接続し、コアは転送時にドメインを復元してルールマッチングを行います。高速で DNS リークも防げるため、TUN モードでの推奨選択肢です。

redir-host:実際に解決して結果を返し、ルールマッチングには実際の IP を使います。互換性は安定していますが、接続のたびに解決完了を待つ必要があり、結果が汚染される可能性もあります。

ハイジャックとキャッシュ

dns-hijack は tun セクションで設定し、53 番ポート宛ての DNS リクエストをコア自身の DNS サービスにハイジャックします:

設定例 · DNS ハイジャックとキャッシュ

tun:
  dns-hijack:
    - any:53

cache:
  enabled: true
  size: 4096
  ttl: 300

cache セクションは解決結果をキャッシュし、重複クエリを減らします。ttl はキャッシュ秒数です。短すぎるとキャッシュの意味がなく、長すぎるとドメインの IP 変更後に遅延が大きくなります。300 秒がよく使われる値です。

トラブルシューティング

• ウェブページを開くたびに数秒待たされる:nameserver が DoH を使っているか、ネットワークから DoH サーバーへ直接接続できるかを確認してください。一部のネットワーク環境では海外 DoH への接続が不安定なため、予備の DoH を nameserver リストに入れておきます。
• 中国国内サイトが海外 IP に解決される:fallback-filter の geosite ルールが機能していません。コアが geosite データソースを取得できるか確認するか、geox-url を手動で指定してください。
• サブスクリプション内蔵の dns セクションと上書きが衝突する:上書きでは dns キーをセクション全体で上書きしてください。フィールド単位でのマージは避けます。

TUN モードと Fake-IP

システムプロキシは「プロキシ設定を自ら読み取る」アプリだけを対象にします。コマンドラインツール、ゲーム、UDP トラフィックはしばしばこれを迂回します。TUN モードはシステム内に仮想ネットワークインターフェースを作成し、すべての IP トラフィックをコアに取り込みます。「全体を確実にキャプチャする」ための正解です。Fake-IP は TUN モードにおける DNS とルールマッチングのパートナーです。

システムプロキシと TUN の違い

システムプロキシはシステム設定を変更してアプリに「トラフィックを 127.0.0.1:7890 に送る」と伝えます。アプリがこの設定を読まなければ無効です。TUN モードは IP レイヤーで動作し、仮想ネットワークインターフェースがすべての送信 IP パケットを受け取るため、アプリの協力に依存しません。違いは次のとおりです。

• コマンドラインツール、curl、git はデフォルトでシステムプロキシを読みません。TUN モードなら個別に export する必要がありません。
• ゲームや UDP アプリはシステムプロキシではほぼ対処できませんが、TUN ならキャプチャできます。
• TUN がキャプチャするのは IP パケットです。アプリは DNS クエリを送ってから TCP 接続を確立するため、TUN は DNS ハイジャックと組み合わせる必要があります。そうしないとドメイン解決は依然としてシステム DNS を通り、ルールマッチングがドメインを取得できません。

tun セクションの完全な設定

設定例 · tun セクション

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

• stack:パケット処理スタック。system は互換性が最も高いものの性能は普通。gvisor は性能が良くリソース消費も少ないですが、一部の古いシステムでは非互換。mixed はコアがプラットフォームに応じて自動選択するため、新しめのバージョンではまずこれを使うのがおすすめです。
• auto-route:デフォルトルートを仮想ネットワークインターフェースに任せるルートを自動追加します。必ず有効にしてください。
• auto-detect-interface:出口インターフェースを自動検出します。複数インターフェース(有線 + 無線 + 仮想マシン)の環境では有効にするのがおすすめです。誤ったインターフェースを選ぶとネットワーク断が発生することがあります。
• strict-route:Windows では有効にするとルーティングテーブルを厳密に管理し、「一部トラフィックの漏れ」を防げます。ただし VPN や仮想ネットワークアダプターと衝突しやすくなるため、トラブルシューティング時はまずオフにして試してください。

Fake-IP の仕組み

enhanced-mode: fake-ip を有効にすると、コアはドメイン解決リクエストを受け取っても実際の DNS に問い合わせず、fake-ip-range(デフォルト 198.18.0.1/16)から仮想 IP を返し、「ドメイン ↔ 仮想 IP」のマッピングをメモリに記録します。アプリが仮想 IP に接続すると、コアはマッピングからドメインを復元してルールマッチングを行います。利点は2つ:解決時に実際の DNS の往復を待たずに済むため接続が速くなること、ルールマッチングが常にドメイン基準になり IP 汚染に影響されないことです。

fake-ip-filter は仮想 IP を必要としないドメインを除外するためのものです。よくあるのはローカルサービスや、実際の IP での直接接続が必要なサイトです:

設定例 · fake-ip の範囲とフィルタ

dns:
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*"

各プラットフォームの注意点

• Windows:サービスモードで実行する必要があります。インストール時に「サービスをインストール」にチェックを入れるか、後で設定からサービスモードを有効にしてください。OS のファイアウォールでコアプロセスを許可する必要もあります。
• macOS:TUN の有効化には管理者権限が必要で、初回有効化時にパスワードダイアログが表示されます。OS アップデート後に権限が無効になることがあるため、TUN を一度オフにして再度オンにすれば復旧します。
• Linux:cap_net_admin 権限が必要です。通常ユーザーで実行する場合は、バイナリに対応するケイパビリティが付与されているか確認するか、systemd サービスで起動してください。
• Android:Clash Meta for Android などのクライアントも TUN に対応しています。システム VPN 権限が必要で、システムプロキシとは排他的な2つの動作方式です。

トラブルシューティング

• TUN を有効にしたら完全にネットワーク断になる:まず strict-route をオフにし、次に stack: system に変更して、auto-detect-interface が正しいインターフェースを選択しているか確認してください。
• 国内にはつながるが海外はタイムアウト:TUN と DNS ハイジャックの連携に問題があります。tun セクションに dns-hijack: [any:53] があり、dns.enable が true になっているか確認してください。
• 一部のアプリの接続がリセットされる:アプリが宛先 IP を検証している可能性があります。そのドメインを fake-ip-filter に追加して実際の解決を使わせてください。

ドメインスニッフィング

TUN モードがキャプチャするのは IP パケットです。アプリが IP に直接接続する場合や、すでに解決済みのアドレスに接続する場合、コアはドメインを取得できず、ルールマッチングは IP だけに頼ることになります。ドメインスニッフィング(sniffing)は接続内容からドメインを「見抜いて」、この欠けた部分を補います。

どのような場面でスニッフィングが必要か

• アプリが自前で DNS 解決を行う(一部のゲームクライアント、特定のアプリが IP に直接接続):TUN に到達したトラフィックには IP しかなく、ドメインがありません。
• QUIC / HTTP3 接続:UDP トラフィックにはハイジャックできる従来の DNS クエリがありません。
• 接続の再利用:同じ TCP 接続上の後続リクエストでは DNS が再送されないため、ルールは IP でしかマッチできません。

設定例

設定例 · sniffing セクション

sniffing:
  enable: true
  override-destination: false
  force-doman: true
  parse-pure-ip: true
  skip-dest-address:
    - 192.168.0.0/16
    - 198.18.0.1/16

• enable:全体のスイッチです。
• override-destination:スニッフィングでドメインを検出した後、接続先をドメインに書き換えるかどうか。有効にするとルールマッチングがより正確になりますが、QUIC など一部のプロトコルは書き換えに対応していません。安全に書き換えられる場合だけ変更するよう、false のままにするのがおすすめです。
• force-doman:設定に IP ルールが書かれていても、ルールマッチングにスニッフィングで検出したドメインを強制的に使います。
• parse-pure-ip:純粋な IP 接続でもドメインの解析を試みます(TLS SNI などのフィールド経由)。
• skip-dest-address:スニッフィング不要の宛先ネットワークをスキップします。通常はプライベートネットワークと fake-ip-range を除外し、仮想 IP に対する無意味なスニッフィングを避けます。

スニッフィングとルールマッチングの順序

接続が入ってからのマッチング順序は次のとおりです。まず接続が Fake-IP マッピングに一致するか(ドメインがあればそのドメインを使う)、次に skip でスキップされるか、その後スニッフィングを試み、ドメインが検出されたら「ドメインルール → IP ルール → フォールバック」の順でマッチします。そのため、DOMAIN で始まるルールはスニッフィング有効時にカバー範囲が広がります。IP ルールも依然として有効ですが、ドメインルールより後になります。

注意事項

• スニッフィングは接続の最初の数パケットだけを読むため、性能への影響はごくわずかです。ただし override-destination を有効にすると、宛先アドレスの書き換えによって一部のアプリがエラーを起こします。「特定のアプリで TUN を有効にすると接続できない」という場合は、まずこの項目をオフにしてください。
• TLS でない平文 HTTP トラフィックは Host ヘッダーをスニッフィングできます。TLS トラフィックは SNI を読み取り、QUIC トラフィックは CHLO 内の SNI を読み取ります。ただし UDP セッションには安定した「接続」の概念がないため、一部の実装ではスニッフィング範囲が制限されます。
• Fake-IP との関係:Fake-IP は DNS レイヤーで既にドメインを取得しています。スニッフィングは主に「DNS ハイジャックを通らなかった」トラフィックを補います。両方を同時に有効にしても重複作業ではなく、異なる入口をカバーしています。

ローカル上書きと複数サブスクリプションの統合

サブスクリプションから取得した設定を直接変更すると、更新1回で全て失われます。上書き(merge)は Clash Verge が提供する差分変更レイヤーです。サブスクリプション更新後も、上書き内の変更は自動的に再適用されます。複数のサブスクリプションが并存する場合、上書きで異なるサブスクリプションのノードを同じプロキシグループに統合することもできます。

上書きの構文

上書きファイル自体は YAML で、2種類の命令に対応します:

• キーの上書き:対象のキーと値を直接書き、サブスクリプション内の同名キーを置き換えます。DNS や TUN などセクション全体を書き直す場面で使います。
• 追加命令:prepend- と append- プレフィックスのキーで、内容をサブスクリプションの対応リストの前または後に挿入します。prepend-proxies、append-proxies、prepend-proxy-groups、append-proxy-groups、prepend-rules、append-rules などに対応します。

設定例 · 追加命令

prepend-rules:
  - DOMAIN-SUFFIX,company.com,ダイレクト
append-rules:
  - GEOIP,CN,ダイレクト
  - MATCH,メイン
prepend-proxy-groups:
  - name: 仕事
    type: select
    proxies:
      - 会社専用回線
      - メイン

完全な上書きの例

設定例 · ノード統合 + カスタムルール + DNS 固定

# 上書き:2つのサブスクリプションのノードを統合し、カスタムルールを追加し、DNS を固定
prepend-proxy-groups:
  - name: 全ノード
    type: select
    proxies:
      - サブスクAノード
      - サブスクBノード
      - ダイレクト
prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,ダイレクト
  - RULE-SET,my-custom,メイン
append-rules:
  - MATCH,全ノード
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

注意:上書きに dns キーを書くと、サブスクリプションの dns セクション全体を置き換えます。サブスクリプションの DNS を維持しつつ1箇所だけ変更したい場合は、サブスクリプションの完全な dns セクションをコピーして変更するか、prepend-dns/append-dns でリストに追加してください。ただし dns セクションのフィールドはネストされたオブジェクトで、追加命令はリストにのみ有効なため、最も確実なのはセクション全体の上書きです。

複数サブスクリプションの統合

• 「設定」ページで複数のサブスクリプションを追加できます。各サブスクリプションは独立して更新され、互いに干渉しません。
• 「全ノード」のようなプロキシグループで複数サブスクリプションのノードをまとめます。include-all または上書き内の proxies でグループ名を参照します。
• サブスクリプションを切り替えると、現在有効な profile が丸ごと切り替わります。上書きとスクリプトは常に「現在のサブスクリプション」に重ねて適用されるため、上書きでノード名を参照する場合は、各サブスクリプションに同名ノードが存在することを確認してください。存在しないとプロキシグループが空のメンバーを参照することになります。
• スクリプトモード(script.js)はより複雑な統合ロジックに向いています。たとえばサブスクリプション名のプレフィックスで自動グループ化したり、「期限切れ」を含むノードをフィルタリングしたりできます。スクリプトは上書きの後に実行され、config オブジェクトを受け取り、変更後のオブジェクトを返します。

メンテナンスの提案

• 上書きの内容は用途ごとに区切り、コメントで「ルール」「プロキシグループ」「DNS」を明示しておくと、半年後に見ても一目で分かります。
• サブスクリプションを更新したら、まずログに merge 失敗系のメッセージがないか確認し、上書きの構文がサブスクリプションの内容と衝突していないか確かめてください。
• ルールはできるだけルールセットで管理し、上書きには少数のカスタムルールだけを置きます。上書き自体が第二のメイン設定に肥大化するのを防ぎます。

外部コントロールパネル

日常的にノードを切り替えたり接続を確認したりする分にはクライアントの UI で十分です。しかし一括操作、ルールの一致確認、リモート管理を行うには、mihomo の外部コントロール API を使います。パネルは HTTP でコアと通信し、external-controller を設定すれば利用できます。

基本設定

設定例 · 外部コントロールの待受とトークン

external-controller: 127.0.0.1:9090
secret: "your-long-random-token"

• external-controller の形式は「アドレス:ポート」です。ローカルだけでアクセスするなら 127.0.0.1:9090 と書きます。LAN からアクセスしたい場合は 0.0.0.0:9090 に変更してファイアウォールを設定しますが、パブリックネットワークには直接公開しないでください。パネルはプロキシの切り替えや接続情報の読み取りができるため、保護されていない公開ポートはプロキシの制御権を誰にでも渡すことになります。
• secret はアクセストークンで、パネルと API リクエストの両方に必要です。十分に長いランダム文字列を使ってください。Verge の設定ページでも secret を生成・保存できます。
• external-controller や secret を変更した後は、コアの再起動が必要です。

よく使われるパネル

mihomo の公式リポジトリは Yacd、MetaXD などのパネルを提供しています。ビルド後はコアと同じディレクトリの ui フォルダに配置し、ブラウザで http://127.0.0.1:9090/ui にアクセスすると開けます。パネルを初めて開くと、バックエンドアドレスと secret の入力が求められます。Verge の「設定 → 外部コントロール」にもパネルへの入口があり、開くだけで使えます。

REST API のよく使うエンドポイント

呼び出し例 · curl での取得と切り替え

curl -H "Authorization: Bearer your-long-random-token" \
  http://127.0.0.1:9090/proxies

curl -X PUT -H "Authorization: Bearer your-long-random-token" \
  -d '{"name":"香港 01"}' \
  http://127.0.0.1:9090/proxies/メイン

• GET /connections で「この接続がなぜ直接接続になったのか」を調べられます。レスポンスには rule と rulePayload フィールドが含まれ、一致したルールが直接表示されます。
• PUT /configs はモードの素早い切り替えに便利です。{"mode":"global"} で一時的にグローバルプロキシにし、使い終わったら rule に戻します。
• すべての API は Authorization ヘッダーが必要です。形式は Bearer <secret> です。

セキュリティの推奨事項

• パネルと API はループバックアドレスのみで待受するか、SSH トンネル経由で LAN 外のマシンにアクセスしてください。
• secret は同期されるノートに書かないでください。またコマンドライン履歴に平文で繰り返し残さないようにし、環境変数やクライアント内蔵の secret 管理を使ってください。
• 定期的に GET /configs で mode が変更されていないか確認してください。自分が変更していないのに mode が global になっていたら、まずポートの露出を疑い、その後 secret を交換してください。