Clash Meta 上級設定ガイド

01

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

プロキシグループは設定における判断レイヤーです。プロキシノードが「接続をどう確立するか」を担うのに対し、プロキシグループは「この種類のトラフィックをどこへ渡すか」を決めます。保守しやすい設定では、ルールから具体的なノードへ直接指定せず、「通常選択」「自動速度測定」「フェイルオーバー」「ダウンロード振り分け」などの安定した名前を先に作り、ルールからそれらを参照します。こうしておけば、サブスクリプションやノード名を変更しても、ルール層を書き直す必要がありません。プロキシグループ名には日本語も使えますが、proxy-groups、rules、他グループの proxies 内で完全に一致させる必要があります。スペース、大文字・小文字、記号も省略できません。

select、url-test、fallback、load-balance

select は手動選択グループで、出口を明示的に指定したい場面に適しています。ノードの品質を自動判定するものではなく、現在の選択を保持します。自動グループ、フェイルオーバーグループ、よく使う少数のノードを 1 つの select グループにまとめると、安定性と手動制御を切り替えられます。url-test は指定間隔でテスト URL にアクセスし、利用可能なノードから測定遅延の低いものを選びます。Web 閲覧や API リクエストなど、応答速度を重視する短時間の接続に適しています。ただし測定結果は、現在の端末からテスト先までの性能を示すだけで、すべての Web サイトやストリーミングサービスで同じ速度になるとは限りません。

fallback はリスト順に利用可能か確認し、前方のノードを優先します。現在のノードが使えない場合にのみ次の項目へ切り替わります。主回線と予備回線を固定したい構成や、ログイン状態・出口地域を頻繁に変えたくないサービスに適しています。load-balance は複数ノードへ接続を分散でき、並列ダウンロードや複数宛先へのアクセスに利用できます。ただし同じ Web サイトへの複数接続が異なる出口から送信されると、ログイン認証を求められることがあります。そのため、負荷分散を日常のデフォルトグループの代わりに使わず、専用ルールから明示的に参照するのが安全です。

保守しやすい階層構成

次の構成では、ノードの供給元をプロキシプロバイダーに任せ、自動選択とフェイルオーバーを下位グループとして構成し、最後に「デフォルトプロキシ」からルールへ一元的に公開します。include-all: true は、利用可能なプロキシプロバイダーのノードをグループへ取り込みます。クライアントや既存設定でプロキシプロバイダーを使わない場合は、proxies に明示的に列挙する方法へ変更できます。interval はヘルスチェックまたは速度測定の間隔で、単位は秒です。tolerance は、現在のノードよりどれほど良い結果になったら切り替えるかを示します。適切な許容差を設定すると、遅延が近い 2 つのノード間で頻繁に切り替わるのを防げます。

proxy-groups:
  - name: デフォルトプロキシ
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT

  - name: 自動選択
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: フェイルオーバー
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300

テスト URL には、サイズが小さく安定したレスポンスを返すものを選びます。現在のネットワークでリダイレクトされたり、キャッシュされたり、アクセスできなかったりすると、グループ内のノードがすべて失敗と表示される場合があります。その際はまずログで、DNS 解決失敗、接続タイムアウト、TLS エラーのどれかを確認してから、テスト URL の変更を検討してください。小さな数値を得るために測定間隔を極端に短くしないでください。頻繁な測定は接続数とバッテリー消費を増やし、モバイルネットワークを繰り返し起動させることもあります。

ノードを並べるのではなく、用途ごとにグループ化する

長期運用する設定では、「ストリーミング」「開発サービス」「大容量ファイルのダウンロード」のように用途で命名するほうが適しています。すべての地域とノードを数十個の入口として並べる構成は避けましょう。用途グループから地域グループ、地域グループから自動速度測定グループを参照すれば、2～3 層の明快な構造になります。階層が深すぎるとトラブルシューティングが難しくなり、循環参照も起こり得ます。A グループが B を含み、B も A を含む場合、設定チェックは失敗します。変更後は、まずクライアントの設定チェック機能または mihomo のテスト起動で構文を確認し、次にログで最終的に一致したプロキシグループを確認してください。3 種類の自動グループの違いと組み合わせ例は、プロキシグループの種類と選び方ガイドで詳しく説明しています。

02

ルールセットのサブスクリプション管理

ルールは、リクエストを直接接続、プロキシ、拒否、または特定用途のプロキシグループへ振り分けます。数千件のドメインや IP をメイン設定へ直接記述しても動作しますが、更新、レビュー、原因特定が難しくなります。rule-providers を使うと、ルール本体を独立ファイルに分離し、メイン設定では取得元、動作種別、保存先、更新間隔を宣言できます。実際のルールは RULE-SET で参照するだけです。メディアルール、イントラネットルール、開発サービスルールを個別に更新でき、ルール元が一時的に利用できなくてもローカルキャッシュを使い続けられます。

behavior と format は内容に合わせる

behavior は、ルールセットが保存する内容の形式を示します。domain はドメイン項目向けで、完全修飾ドメイン、ドメインサフィックス、キーワード形式の集合に適しています。ipcidr は IPv4・IPv6 のネットワーク向けです。classical は、DOMAIN-SUFFIX,example.org や IP-CIDR,192.0.2.0/24 のように種別プレフィックスを含む完全なルールを保存します。3 種類はフィールド名を変更するだけでは相互変換できず、リモートファイルの実際の構造が宣言と一致していなければなりません。format でよく使う値は yaml、text、mrs です。形式はルール元が提供するファイルに合わせる必要があり、通常のテキスト URL をバイナリルール形式として宣言してはいけません。

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://rules.example.com/private-domains.yaml
    path: ./ruleset/private-domains.yaml
    interval: 86400

  private-networks:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://rules.example.com/private-networks.yaml
    path: ./ruleset/private-networks.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - RULE-SET,private-networks,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,デフォルトプロキシ

サンプルのドメインは構造説明用です。実際には、信頼できるルール元が提供する完全なファイル URL に置き換えてください。path はカーネルの作業ディレクトリ内にあるキャッシュ保存先です。作業ディレクトリの選択はクライアントごとに異なるため、mihomo を手動実行する場合はプロセスに書き込み権限があることを確認します。ルールファイルの初回ダウンロードに失敗し、ローカルキャッシュもない場合、そのプロバイダーはマッチングに参加できません。以前に取得成功していれば、通常はキャッシュを読み続けられますが、リモート側の追加内容は反映されません。

ルールは上から順にマッチする

rules の順序は決定的です。リクエストが最初の適用可能なルールに一致すると、それ以降の判定は停止します。そのため、範囲が狭く意図が明確なルールを前に置き、広いルールを後ろへ配置します。MATCH は最後のフォールバック専用です。たとえば社内ドメインを直接接続する場合は、一般的なプロキシ用ドメイン集合より前に置きます。LAN のネットワーク範囲も、広範な IP ルールより先に処理します。広いプロキシ集合を先頭に置くと、後続の直接接続例外は構文が正しくても一度も発動しません。

no-resolve は IP 系ルールに使用し、マッチング時に宛先 IP を得るための追加 DNS 解決を行わないことを示します。不要な問い合わせを減らし、ドメインがまだ解決されていないときに判定経路が変わるのを防げます。ただし、すべてのルールへ機械的に追加すべきではありません。ドメインルールはドメイン情報を必要とし、プロセスが IP だけを提供してスニッフィング結果もない場合は、後続の IP ルールで判定する必要があります。ルールの問題を分析するときは、グループ名だけでなく、ログの対象ホスト、ルール種別、最終的なプロキシを同時に確認してください。

更新失敗とロールバック

ルールセットの更新失敗は、主に 4 つの原因で起こります。リモート URL の無効化、DNS 解決失敗、ダウンロードにプロキシが必要なのに現在のポリシーが未準備、キャッシュディレクトリへの書き込み不可です。まずログの HTTP ステータスやネットワークエラーを確認し、同じ端末からブラウザまたはコマンドラインでルール URL にアクセスします。カーネルだけがアクセスできない場合は、ルールプロバイダーの取得にプロキシが必要か、起動初期の DNS でルール元のドメインを解決できるかを確認します。ディレクトリ権限の問題では、ファイル作成、テンポラリファイルのリネーム、書き込みに失敗したというメッセージが表示されます。

リモートルールだからといって、起動のたびにオンライン取得が必須になるわけではありません。本番環境では、直近の正常動作するキャッシュを残し、更新前にファイル形式を確認し、変更範囲を管理するのが適切です。すべてのルール元、DNS 設定、プロキシグループを一度に置き換えると、どの層が原因か判断しにくくなります。まずプロバイダーを追加しても参照せず、ダウンロード成功を確認します。次に RULE-SET を 1 つ追加してマッチングを観察し、最後に古いルールを削除します。戻す必要がある場合は、メイン設定の参照を復元するだけで済みます。キャッシュファイルは確認用に残しておけます。

ルール数は設定品質そのものではない

ルールを増やせば自動的に振り分けが正確になるわけではありません。重複した集合は読み込み時間を増やし、同じドメインに対して異なる集合が矛盾した判定を返すこともあります。まず用途グループを少数に絞り、その用途をカバーするルールセットを選びます。「特定サイトが誤ったグループへ送られる」場合は、まずログで実際に一致した最初のルールを確認し、順序を調整するか、より正確な例外を追加してください。ルール一式を丸ごと交換すると、新たな不明点を招きがちです。GeoIP やルールプロバイダーの更新異常をさらに確認する場合は、よくある質問の該当トラブルシューティングを参照してください。

03

DNS 設定の最適化

DNS 層はドメインをアドレスへ変換し、ルールが正しい宛先を認識できるかにも直接影響します。「ノードは使えるのに Web ページが開かない」「同じドメインが直接接続になったりプロキシになったりする」「ログに IP しか表示されずドメインを判断できない」といった問題は、ノードの速度ではなく、DNS リクエストの経路、キャッシュ結果、トラフィックの取り込み方が揃っていないことが原因になりがちです。DNS を設定する前に、次の 3 点を確認します。問い合わせを誰が処理するか、どのリゾルバーへ送るか、リゾルバー自身のドメインをどう解決するかです。この 3 層を整理してから Fake-IP の有効化を判断します。

nameserver、default-nameserver、プロキシ専用 DNS

nameserver は通常のドメイン問い合わせに使う主要なリゾルバーです。従来の UDP/TCP DNS のほか、DoH などの暗号化形式も指定できます。default-nameserver は主に DoH サーバーのドメインやプロキシサーバーのドメインなど、起動時に必要な項目の解決に使います。直接アクセスできる IP 形式のリゾルバーを指定すると、「DNS サービスのドメインを解決してから、その DNS サービスを使う」という循環を避けられます。proxy-server-nameserver はプロキシノードのサーバードメイン専用にでき、ノードアドレスと通常のサービスドメインを分離して、業務ルールがプロキシ接続へ逆に影響する可能性を減らします。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

この例はフィールド間の関係を示すもので、すべてのネットワークに同じリゾルバーが適しているわけではありません。DNS サービスを選ぶ際は、現在のネットワークからの到達性、応答結果、プライバシー要件を考慮してください。DoH サービスへのアクセスにプロキシが必要で、起動時にそれを唯一の DNS 入口にすると、プロキシがまだ確立していないのに DNS がプロキシを待つ依存ループが起こる可能性があります。直接アクセスできる基礎的な解決経路を残し、プロキシサーバーのドメインを個別に解決すると、通常はより安定します。

nameserver-policy のマッチング用途

nameserver-policy では、ドメイン、ルール集合、geosite 分類ごとに使用するリゾルバーを指定できます。たとえばローカルドメインを近いリゾルバーへ、それ以外のドメインを別のリゾルバー群へ送れます。これは「問い合わせを誰に送るか」を決めるものであり、「最終的なトラフィックをどのプロキシグループへ送るか」を決めるものではありません。接続ポリシーは引き続き rules が決定します。DNS ポリシーとルーティングルールは似た分類を使えますが、完全に一致させる必要はありません。重複するドメイン集合を大量に同時指定すると、どのリゾルバーが使われたか分かりにくくなるため、精密な条件から広い条件へ並べる原則を守ります。

respect-rules: true は、DNS 接続自体がルーティングルールに従うことを示します。有効化する場合は、DNS サーバーのドメインとアドレスに起動を完了できる経路があることを確認してください。そうでないと、リゾルバーへのリクエストがまだ利用できないプロキシグループへ送られる可能性があります。変更後にすべてのドメイン解決が失敗したら、まず直接アクセスできるリゾルバーで一時的に検証し、その後 DNS サービスのドメインがどのルールに一致したかを確認します。

IPv6、キャッシュ、結果の違い

ipv6: false は通常、DNS モジュールが AAAA レコードを返さないことを意味し、端末や出口に安定した IPv6 接続がない場合に適しています。ローカルネットワークとプロキシノードの双方で IPv6 が利用できるなら有効化できますが、TUN、システムルート、IPv6 ネットワーク範囲に対するルール処理も同時に確認してください。DNS だけで IPv6 を有効にし、TUN や出口が対応していない場合、アプリが IPv6 を優先して長時間待機した後、IPv4 へフォールバックすることがあります。

DNS を変更しても、古い結果が OS、ブラウザ、クライアント、カーネルのキャッシュに残っている場合があります。トラブルシューティングでは、まず関連クライアントを再起動するか、システム DNS キャッシュを消去してから、同じドメインを繰り返しテストします。ブラウザが独自のセキュア DNS を使っていると、システムの解決経路を迂回します。システムツールでは正常なのにブラウザだけ異常なら、ブラウザ側の設定を確認してください。逆にブラウザは正常でターミナルだけ異常なら、システム DNS、環境変数、またはターミナルアプリが想定した入口を通っていない可能性が高いです。

04

TUN と Fake-IP

システムプロキシは、アプリが明示的にプロキシ設定を読み取ることを前提とします。ブラウザは通常よく対応していますが、一部のターミナルアプリ、ゲーム、システムサービス、独自ネットワークスタックを使うアプリは完全に無視することがあります。TUN モードは仮想 NIC とシステムルートを通じて、より広い範囲の TCP・UDP トラフィックを取り込み、mihomo に渡します。Fake-IP は DNS 段階でドメインに予約アドレスを割り当て、アプリがそのアドレスへ接続すると、カーネルがマッピングから元のドメインを復元します。これにより、より多くの場面でドメインルールを適用できます。両者は併用されることが多いものの役割は異なり、TUN は取り込み、Fake-IP はドメインマッピングを担います。

TUN の基本設定とプラットフォーム権限

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

stack は TUN パケットを処理するネットワークスタックを決めます。mixed は一般的な互換設定ですが、利用できる値と挙動はカーネルの能力やプラットフォーム実装によって異なります。auto-route は必要なルートを自動追加し、auto-detect-interface はデフォルト出口から物理 NIC を識別します。有線、無線、テザリング、VPN の切り替えがある環境で特に便利です。dns-hijack は条件に一致する DNS リクエストをカーネルの DNS モジュールへ渡し、システムが元のリゾルバーへ問い合わせ続けるのを防ぎます。strict-route は迂回経路をより厳格に制限し、漏洩やルーティングのずれを減らせますが、仮想マシン、LAN 共有、他の VPN とのルート競合も起こりやすくなります。

仮想 NIC の作成やルート変更には通常、管理者権限が必要です。Windows クライアントではサービスモードで権限操作を行う場合があります。macOS ではネットワーク拡張機能やシステム権限が要求されます。Linux でカーネルを直接実行する場合は、必要なネットワーク権限と systemd サービスの権限設定を確認してください。有効化後に端末全体がオフラインになったら、最初にノードを変更するのではなく、TUN を無効化して基礎ネットワークが復旧するか確認します。その後、仮想 NIC が正常に作成されたか、デフォルトルートが誤って上書きされていないかを確認します。

Fake-IP の動作経路

enhanced-mode: fake-ip では、DNS モジュールが fake-ip-range 内のアドレスをドメインへ返します。アプリがそのアドレスへ接続すると、カーネルはマッピング表から元のドメインを取得し、ドメインルールに基づいてポリシーを選び、実際の宛先を解決します。198.18.0.0/15 はベンチマーク用途の予約アドレス範囲で、このようなマッピングによく使われます。Fake-IP をリモートサーバーの実アドレスと誤解しないでください。パケットキャプチャやログにこの範囲が表示されても、DNS が見知らぬホストへハイジャックされたのではなく、マッピング経路が動作していることを示します。

Fake-IP の利点はドメイン情報を比較的完全に保持でき、ルール判定が分かりやすく、アプリが実 IP を先に取得してドメインルールを回避するケースを減らせることです。一方、DNS 応答を検証するアプリ、LAN ディスカバリに依存するアプリ、特殊な UDP プロトコルを使うアプリ、解決結果を同じカーネルを通らないプロセスへ渡すアプリでは、マッピングが適さない場合があります。その場合は Fake-IP を完全に無効にするのではなく、fake-ip-filter で特定ドメインだけ実アドレスを返すようにします。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - geosite:private

blacklist モードでは、リスト内のドメインに Fake-IP を使わず、それ以外のドメインは引き続きマッピングします。除外範囲はできるだけ正確にしてください。広すぎるワイルドカードを追加すると、多数のリクエストが実 IP モードへ戻り、ドメインルールの効果が弱まります。LAN デバイスの検出に問題がある場合は、まずデバイスが使う .local、プライベートドメイン、メーカーのサービスだけを例外に追加してログを確認します。一般的なトップレベルドメイン全体を一度に除外するのは避けてください。

他の VPN、仮想マシン、LAN との競合

TUN と企業 VPN、ゲーム用ネットワーク最適化ツール、仮想マシンの NIC、コンテナネットワークを同時に動かすと、競合は通常、ルート優先度、DNS の取り込み、同じ予約アドレス範囲で発生します。まず TUN を無効にした状態のデフォルトルートと DNS を記録し、その後ネットワークコンポーネントを 1 つずつ有効化すると、どの段階で出口が変わったか特定できます。企業 VPN が特定のネットワーク範囲だけを許可する場合は、その範囲に正しいルートを残し、内部ドメインを企業 DNS へ渡します。そうしないと、プロキシノードが利用可能でも、名前解決とルーティングが分離して社内サービスへ接続できないことがあります。

LAN へアクセスできない場合は、プライベートネットワーク範囲が DIRECT に設定されているか、TUN が LAN ルートを保持しているか、システムファイアウォールが仮想 NIC からのアクセスを許可しているかを確認します。ルーターやサイドゲートウェイで運用する場合は、クライアントのトラフィックが自身へ戻ってループしないようにします。Linux では ip route と ip rule、Windows では route print、macOS では netstat -rn でルートとポリシーを確認できます。観察だけが目的なら、これらのコマンドでシステム設定を変更する必要はありません。

# Linux：ルートとポリシールールを確認
ip route
ip rule

# Windows：IPv4 と IPv6 のルートを確認
route print

# macOS：現在のルーティングテーブルを確認
netstat -rn

ブラウザと一般的なデスクトップアプリだけをプロキシ経由にするなら、システムプロキシのほうが構成が簡単で原因も特定しやすいです。システムプロキシを読み取らないアプリが実際にある場合に限り、TUN を有効にしてください。両方式の適用範囲、権限、性能の違いは、TUN モードとシステムプロキシの比較を参照してください。

05

ドメインスニッフィング

すべての接続が、カーネルへ入る時点でドメインを含んでいるとは限りません。アプリが DNS を自分で解決してから対象 IP へ直接接続することもあり、透過プロキシやゲートウェイ構成ではアドレスしか見えない場合もあります。ドメインスニッフィングは接続初期のプロトコル特性を読み取り、HTTP Host、TLS SNI、QUIC ハンドシェイクからドメインを抽出してルール判定に利用します。業務データを復号する機能ではなく、任意のプロトコルに有効なわけでもありません。ハンドシェイク段階で元々見えている宛先識別情報だけを利用し、ルーティング判断に必要な情報を補います。

プロトコルとポートで範囲を制限する

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.org"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ip は、元の宛先が IP である接続に対してスニッフィングを試みます。透過的な取り込みに適しています。force-dns-mapping は DNS マッピングと組み合わせてドメイン情報を探し、Fake-IP と併用されることが多い設定です。プロトコルごとにポートを限定すれば、HTTP、TLS、QUIC ではないことが明らかな接続で余計な判定を避けられます。ポート範囲は実際のアプリに合わせて調整してください。すべてのポートをすべてのスニッファーへ渡しても精度は上がらず、誤判定とトラブルシューティングの負担が増えるだけです。

override-destination は、スニッフィングで得た宛先で元の宛先情報を上書きする設定です。有効にするとドメインルールに一致しやすくなりますが、誤ったスニッフィング結果が接続先へ直接影響するため、明確なプロトコルに限定して有効にするのが一般的です。force-domain は特定ドメインでスニッフィング結果の使用を強制し、skip-domain は既知の非互換サービスを除外します。ドメインの記述方法はカーネルが対応するワイルドカード規則に従い、変更後はログで抽出されたドメインが実際のリクエストと一致することを確認してください。

スニッフィング、DNS、ルールの適用順序

1 回の接続には、アプリが送信したドメイン、DNS マッピングに保存されたドメイン、スニッフィングで得たドメインという 3 種類の宛先情報が含まれることがあります。アプリが通常のプロキシプロトコルでドメインを送信する場合、通常は追加のスニッフィングは不要です。アプリが IP にしか接続しない場合、カーネルはマッピングやハンドシェイクからドメインを復元する必要があります。ルールエンジンが最終的にどの情報を使うかは、取り込み方式と設定によって決まります。トラブルシューティングでは、ログの宛先が IP からドメインへ変化したか、どのルールに一致したか、実際に接続したアドレスを確認します。

スニッフィングは DNS の代わりにはなりません。接続開始後に行われるため、ノードサーバーのドメイン、ルールプロバイダーの URL、一部の識別可能なハンドシェイクを持たないプロトコルは、通常の名前解決に依存します。また、ルール設計の代替にもなりません。ドメインを抽出できても、適切な DOMAIN、DOMAIN-SUFFIX、ルールセットによって正しいプロキシグループへ送る必要があります。ログに正しいドメインが表示されているのに誤ったグループへ送られるなら、スニッフィングのポートを広げるのではなく、ルールの順序へ戻って確認してください。

よくある誤判定と例外処理

一部のアプリは非標準ポートで独自プロトコルを使い、データの先頭が HTTP や TLS に偶然似ていることがあります。また、共有アドレスやフロントドメインを使うサービスでは、ハンドシェイクのドメインが画面上のサービスドメインと一致しない場合があります。スニッフィングを有効にすると接続に失敗し、無効にすると復旧する場合は、対象 IP、ポート、抽出されたドメイン、一致したルールを記録してください。単一サービスの問題だと確認できたら、すべてのスニッフィングを無効にするより、そのサービスをスキップリストへ追加するほうが適切です。

QUIC は UDP ベースのため、ネットワーク、ファイアウォール、プロキシノードの UDP 対応状況の影響を受けやすいプロトコルです。ブラウザは同じ Web サイトへのアクセスで QUIC と TCP/TLS を切り替えることがあり、問題が断続的に見える場合があります。ログで両方の接続の宛先とポリシーを比較してください。ノードが UDP に対応していないなら、すべての UDP を DNS の問題と決めつけず、ポリシーを調整するかアプリをフォールバックさせます。モバイル端末がスリープから復帰したときや Wi-Fi からモバイルデータへ切り替えたときは、古い接続が残ることもあるため、新しい設定を確認するには接続を再確立します。

ログで再現可能なサンプルを作る

スニッフィング設定を調整するときは、1 回に 1 つのフィールドだけを変更し、同じアプリ、同じドメイン、同じネットワークでテストします。無効時と有効時の宛先表示、ルール一致、エラー種別を記録してください。timeout なら、対象へ到達できないのか、ポリシーのノードへ到達できないのか、UDP が使えないのかをさらに切り分けます。証明書のドメイン不一致なら、上書き後の宛先が正しいかを重点的に確認します。ログ項目と一般的な接続エラーの読み方は、Clash 実行ログのトラブルシューティングガイドを参照してください。

06

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

サブスクリプションは通常、ノード、基本的なプロキシグループ、一部のルールを提供します。一方、ユーザー固有の LAN 例外、DNS の好み、TUN 設定をリモートサブスクリプションへ直接書き戻すのは適切ではありません。サブスクリプションを更新するとクライアントが設定を再生成するため、生成ファイルを直接編集しても上書きされる可能性があります。より安全なのは、リモート内容を「入力」とみなし、長期保存するローカル設定を上書き設定、マージスクリプト、独立したメイン設定へ置く構成です。クライアントによって「上書き」「拡張」「マージ」の名称や構文は異なり、実際に置換、浅いマージ、深いマージのどれが行われるかを確認してから使ってください。

置換・追加・深いマージを区別する

YAML ではマッピングとリストでマージの挙動が異なります。マッピング内の dns.enable はキー単位で上書きできますが、rules、proxies、proxy-groups はリストです。多くのツールはリストに遭遇すると自動追加ではなく全体置換を行います。ローカルルールを 1 行だけ書いたつもりでも、サブスクリプションの既存ルールがすべて置き換わり、ローカル項目だけが残ることがあります。クライアントによっては prepend、append など、リストの先頭や末尾へ挿入する明示的な操作を提供します。使い始める前に、判別しやすいテストルールを 1 つ使って最終設定を出力し、挿入位置と元の内容が保持されるか確認してください。

ローカル上書きには、ポート、ログレベル、DNS、TUN、スニッフィング、少数のルール例外を保存するのが適しています。ノードや頻繁に変わるリモートルールは、引き続きサブスクリプションまたは provider で管理するほうが適切です。複数の層で同じフィールドを変更しないでください。たとえばサブスクリプション変換テンプレート、クライアントの上書き設定、起動パラメータのすべてで mixed-port を指定すると、最終値は適用順に左右され、原因を復元しにくくなります。

# ローカルメイン設定の例：ノードは provider が更新し、
# ルールとポリシー名は安定させる。
proxy-providers:
  work-subscription:
    type: http
    url: https://subscription.example.com/work.yaml
    path: ./providers/work.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: デフォルトプロキシ
    type: select
    use:
      - work-subscription
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,デフォルトプロキシ

サンプル URL は provider の構造を示すためだけのものです。実際のサブスクリプション URL には通常、アクセス資格情報が含まれるため、公開ログ、スクリーンショット、共有設定へコピーしないでください。use が参照するのは proxy-providers の名前であり、ノード名ではありません。provider が更新されると、それを参照するプロキシグループに新しいノードが追加されます。ルールは引き続き安定した「デフォルトプロキシ」を指すため、サブスクリプション側でノードを追加・削除してもルーティング層は壊れません。

複数サブスクリプションの命名と重複排除

仕事用、個人用、異なる提供元のサブスクリプションを同時に使うと、ノード名の重複が最もよく起こります。2 つの provider に「香港 01」が含まれている場合、同じリストへ平坦に並べると出所を区別できません。各 provider を独立して保存し、filter、exclude-filter、またはクライアントが対応する名前プレフィックスで区別するのが適切です。フィルター式は単純なキーワードから始め、グループ内のノード数が妥当だと確認してから条件を追加します。複雑すぎる正規表現は、すべてのノードを除外するおそれがあります。

複数サブスクリプションを使うからといって、すべてのノードを 1 つの自動速度測定グループへ入れる必要はありません。「仕事用経路」「日常用経路」という 2 つの下位グループを作り、上位の手動グループから選択する方法もあります。仕事用サービスのルールは仕事用グループだけを、日常のトラフィックはデフォルトグループを参照させ、速度測定で業務用の出口が要件に合わない提供元へ切り替わるのを防ぎます。異なるサブスクリプションに同名のプロキシグループがある場合は、リモート側の名前が長期的に変わらないことを期待せず、ローカルメイン設定で統一して改名してください。

更新前の確認と失敗時の復旧

サブスクリプションを更新する前に、元のサブスクリプションだけでなく、直近に正常動作した最終設定を保存します。更新後は、設定の解析が成功するか、主要なプロキシグループが残っているか、グループ内にノードがあるか、ルール末尾にフォールバックが残っているかの 4 点を確認します。その後、接続テストを行います。更新後にクライアントが起動できない場合は、まず前回の最終設定を復元し、ノード、グループ名、リストのインデントを比較してください。壊れた設定を連続して修正する必要はありません。

YAML はインデントに敏感で、リスト項目は正しい階層に置く必要があります。タブ、全角句読点、見た目が似た特殊な空白が解析失敗の原因になることがあります。サブスクリプション変換ツールが生成した設定も通常の設定として確認し、自動生成だからと検証を省略しないでください。provider のパスを使う場合はディレクトリが存在し、書き込み可能であることを確認します。複数ファイルを扱う場合は、メイン設定を移動した後に相対パスも確認してください。

クライアント間で設定を移行する

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu などのクライアントは mihomo 設定を中心に動作できますが、画面上の上書き方法、設定ディレクトリ、サービスモードは異なります。移行時は、まず端末固有のパスを含まないコア YAML をインポートし、新しいクライアントの画面でシステムプロキシ、TUN 権限、自動起動を設定します。キャッシュ、ロックファイル、プラットフォーム固有のパスまで新環境へ持ち込まないよう、旧クライアントのデータディレクトリ全体を直接コピーしないでください。クライアントの選び方とプラットフォームごとの差異は、比較レビューで確認できます。

07

外部コントロールパネル

mihomo は外部コントロールインターフェースを提供し、接続の確認、ポリシーの切り替え、プロバイダーの更新、ログの取得に利用できます。デスクトップクライアントには通常このインターフェースへ接続する画面が組み込まれています。サーバー、ルーター、純粋なコマンドライン環境では、独立した Web コントロールパネルと組み合わせられます。コントロールインターフェースには実行状態を変更する権限があるため、通常の Web サービスではなく管理入口として扱ってください。安全な設定の要点は、待受範囲を制限し、アクセス資格情報を設定し、信頼できるネットワークまたはリバースプロキシ経由でリモートアクセスを提供することです。

待受アドレスとアクセス範囲

external-controller: 127.0.0.1:9090
secret: "your-control-secret"
external-ui: ./ui
external-ui-name: dashboard

127.0.0.1:9090 はローカルからの接続だけを受け付け、デスクトップクライアントやコントロールパネルとカーネルを同じ端末で動かす場合に適しています。0.0.0.0:9090 に変更すると、LAN 内の他の端末からもアクセスできる可能性があるため、ファイアウォールと強力なアクセス資格情報を必ず同時に設定してください。例の資格情報は説明用のダミー値です。実運用では独立した推測困難な値を使い、サブスクリプション URL や他のアカウントと共用しないでください。

external-ui は静的コントロールパネルのファイルディレクトリを指定し、その中にはパネルのエントリーファイルが必要です。external-ui-name は UI ディレクトリの識別または指定に使います。具体的なダウンロード・更新方法は、使用するコントロールパネルとカーネル設定によって異なります。インターフェースへ接続できるのに画面が空白なら、静的ファイルのパスとプロセスの作業ディレクトリを確認します。画面は開くのにカーネルへ接続できない場合は、コントロールインターフェースのアドレス、プロトコル、ブラウザの同一オリジン制限、資格情報を確認してください。

LAN とリモートアクセスの境界

LAN で管理する場合は、コントロールインターフェースを内部アドレスで待ち受けさせ、管理端末のあるネットワーク範囲だけにアクセスを許可します。管理ポートをインターネットへ直接公開しないでください。リモート管理が必要なら、信頼できる VPN に接続してからアクセスするか、認証と TLS に対応したリバースプロキシを利用するのが適切です。リバースプロキシでは、許可するメソッド、リクエストボディのサイズ、アクセス元も制限し、Web ページへアクセスできるだけのユーザーがカーネルを操作できないようにします。

コントロールパネルでのプロキシグループ切り替えは現在の実行状態を変更しますが、元の設定へ書き戻されるとは限りません。再起動後も選択を保持するかどうかは、profile.store-selected などの永続化設定とクライアント実装に依存します。再起動後も選択を復元したい場合は、対応する永続化機能を有効にしてください。サーバーを毎回固定の出口で起動したい場合は保存を無効にし、設定でデフォルト順序を明示します。

profile:
  store-selected: true
  store-fake-ip: true

log-level: info
unified-delay: true
tcp-concurrent: true

store-selected はプロキシグループの現在の選択を保存し、store-fake-ip は Fake-IP のマッピングを保存して、再起動後の接続挙動の一部を維持しやすくします。保存ファイルには作業ディレクトリへの書き込み権限も必要です。log-level: info は日常的な確認に適しています。トラブルシューティング時は一時的に詳細度を上げられますが、詳細ログを長期間保存するとディスク書き込みと情報露出の範囲が増えます。unified-delay は遅延テストの計算方式を統一し、tcp-concurrent は対象アドレスへの試行を並列化して、一部のデュアルスタック接続の確立を改善します。適性は端末リソースとネットワークの挙動に基づいてテストしてください。

コントロールパネルでの正しいトラブルシューティング

接続一覧では、アプリがどの宛先へ接続したか、どのルールに一致したか、最後にどのポリシーを使ったかの 3 点を確認できます。Web サイトが開けない場合は、まず対象ドメインで接続を絞り込み、リクエストが表示されるか確認します。接続記録がなければ、トラフィックがカーネルへ入っていない可能性があるため、システムプロキシまたは TUN を確認します。記録はあるものの宛先が IP だけなら、DNS とスニッフィングを引き続き確認します。ルールとポリシーが正しいのにタイムアウトする場合は、ノードと対象への到達性を確認します。

プロキシグループ画面の遅延テストはヘルスチェックの 1 つであり、経路の総合評価ではありません。テスト URL への応答が速いノードでも、特定サービスでは使えない可能性があります。実際の接続ログと組み合わせて判断してください。プロバイダー画面で更新に失敗した場合は、プロキシプロバイダーとルールプロバイダーのどちらが失敗したかを確認し、それぞれサブスクリプション URL、ルール URL、DNS、書き込み権限を確認します。1 回のクリックで更新を連続実行するとリクエストが重複するため、現在の処理が終わってから再試行するとログを確認しやすくなります。

設定変更の安全な手順

コントロールインターフェースから設定を再読み込みする前に、独立した場所で構文チェックを完了させます。リモートサーバーで待受アドレス、TUN、デフォルトルートを変更する場合は、現在の管理セッションを維持し、旧設定へ戻せるサービスコマンドを用意してください。systemd 環境では、まずサービスログを確認してから制御された再起動を行います。新しい設定を読み取れると確認する前に、旧ファイルを削除しないでください。サービスが再起動失敗を繰り返す場合は自動再起動を停止し、最初に失敗した行を直接確認します。後続のエラーは、最初の問題が連鎖した結果にすぎないことがよくあります。

# サービス状態と直近のログを確認
systemctl status mihomo
journalctl -u mihomo -n 100 --no-pager

# 設定を確認してから再起動
sudo systemctl restart mihomo

システムサービス名は実際のインストール方法によって異なる場合があるため、実行前に本体のユニット名を確認してください。純粋なコマンドライン運用には、より高度なシステム管理知識が必要です。サブスクリプション、プロキシポリシー、システムプロキシを直接管理したいデスクトップユーザーは、まずLinux クライアントまたは対応プラットフォームの GUI クライアントから始めることをおすすめします。Linux デスクトップ版と systemd の 2 つの導入方法は、Clash Linux インストールガイドで詳しく説明しています。