Clash 設定の上級編：プロキシ、DNS、トラフィック制御

01 / プロキシ構成

プロキシグループの種類と実践的な組み合わせ

プロキシグループは、ルールと個々のプロキシの間に位置します。ルールは接続がどの種類のトラフィックに属するかを判定するだけで、どのプロキシを使うか、自動テストを行うか、失敗時にどう切り替えるかを決めるのはプロキシグループです。長期的に保守しやすい設定の要点は、すべてのノードを1つのグループに詰め込むことではなく、用途ごとに安定した抽象レイヤーを先に作ることです。たとえばルールからは「海外サイト」「ストリーミング」「メッセージング」「漏れたトラフィック」だけを参照し、サブスクリプションによってノード名が変わっても、ルール側を修正せずに済むようにします。

select、url-test、fallback、load-balance

select は手動選択グループで、出口を明確に管理したい場合に適しています。ノードの品質を自動判定せず、現在のメンバーが利用できなくなっても通常は別のメンバーへ自動切り替えしません。そのため、select には生のノードだけでなく、複数の自動選択グループを入れる構成が一般的です。url-test は指定した URL を定期的にテストし、結果のよいメンバーを選択します。ただし、テスト結果はテスト先までの通信状態を示すもので、すべてのサイトの実速度を表すわけではありません。間隔が短すぎると余計な接続が発生するため、モバイル回線では頻繁に実行する必要は特にありません。

fallback はメンバーの並び順に従い、最初に利用できる項目を選びます。最短のテスト時間を選ぶのではなく、安定した主回線と予備回線の関係を重視する方式です。固定回線を優先し、予備回線へ切り替える構成では、url-test より動作を予測しやすくなります。load-balance は複数のメンバーへ異なる接続を振り分けるため、同時接続が多く、サービス側が出口の変化を許容する場合に適しています。ログイン、決済、厳格なリスク管理を行うサイトでは、短時間で出口が変わると異常と判断される可能性があるため、すべてのトラフィックの既定戦略にはしないでください。

安定した2層の戦略構造を作る

よくある構成は、1層目で地域や回線特性に基づいて自動選択し、2層目で用途ごとに手動選択する方法です。以下の「自動選択」はサブスクリプションプロバイダーからノードを絞り込み、「海外サイト」では自動選択、フェイルオーバー、直接接続を切り替えられます。この構成なら、ルールは「海外サイト」だけを参照すればよく、日常の調整をプロキシグループに集約できます。特定のサブスクリプションにルールが強く依存することもありません。

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: フェイルオーバー
    type: fallback
    use:
      - provider-main
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 海外サイト
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT

use はプロキシプロバイダーを参照し、proxies は明示的に列挙したプロキシや他のプロキシグループを参照します。サブスクリプションのノードを絞り込む場合は filter を使えますが、正規表現は安定したキーワードを軸に作成し、サブスクリプション名で変わりやすい装飾文字に依存しないでください。ノード名で用途を安定して区別できない場合は、誤ってノードを取り込む広すぎる表現を使わず、手動選択を残す方が安全です。

プロキシグループを調整したら、まず参照関係を確認してください。ルールの送信先が存在し、グループのメンバーも存在し、グループ同士が循環参照していないことが必要です。クライアントへの読み込み後に設定解析エラーが表示された場合は、追加したグループを一度外し、部分ごとに戻してください。プロキシグループはトラフィックがマッチしなければ接続経路を変えないため、診断時はログで最終的なルールが本当にそのグループを指しているかも確認します。

02 / ルール管理

ルールプロバイダー化とマッチング順序

Clash のルールは上から下へ評価され、マッチした時点で処理を停止します。ルールの数より順序が重要です。完全一致のドメインを広いサフィックスルールの前に置かなければ意味がなく、LAN や直接接続が必要なサービスを広範囲のプロキシルールの後ろに置くと、先に取り込まれることがあります。最後には通常 MATCH を置き、前のルールに該当しなかった接続を受けます。これにより、すべてのトラフィックの行き先を明確にできます。

インラインルールとルールプロバイダー

個人環境に密接に関係する少数のルールは、ホームサーバー、開発環境のドメイン、必ず直接接続したいサイトなど、メイン設定の rules に書くのが適しています。規模が大きく継続更新が必要な公開ルールは rule-providers に任せるとよいでしょう。ルールプロバイダーを使うと、ルール本体とメイン設定を分離し、ダウンロード URL、ローカルキャッシュのパス、形式、更新間隔を設定できます。更新に失敗しても、通常はカーネルがキャッシュ済みのルールファイルを使い続けるため、キャッシュ先には書き込み権限が必要です。また、複数のプロバイダーが同じファイルを指さないようにしてください。

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

  service-proxy:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-proxy.yaml
    url: https://example.invalid/rules/service-proxy.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT
  - RULE-SET,private-direct,DIRECT
  - RULE-SET,service-proxy,海外サイト
  - GEOIP,CN,DIRECT
  - MATCH,海外サイト

例のドメインには予約済みのテスト用ドメインを使っており、そのまま取得できる実在のルール URL ではありません。実際には、信頼でき、継続的に管理できるルール配布元へ置き換えてください。behavior: domain はドメイン型ルールだけを扱うため、ファイルを簡潔に保てます。classical には DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME などの従来型ルール構文を含められ、互換範囲が広い一方、解析とマッチングの構造は複雑になります。behavior はリモートファイルの内容と一致させる必要があり、メイン設定のフィールドだけを変更してルールファイルの形式を無視してはいけません。

狭いルールから広いルールへ並べる

説明しやすい順序は通常、ローカルの例外、LAN への直接接続、明確にプロキシが必要なサービス、明確に直接接続するサービス、地域データベースのルール、最後に MATCH です。公開ルールを特定のドメインで上書きしたい場合は、該当する公開ルールより前にカスタムルールを置きます。IP ルールには no-resolve を追加でき、マッチング時に対象 IP を得るための DNS 解決が発生するのを防げます。ただし、接続自体にすでに IP が含まれているか、前段で IP を取得できる場合にのみ意味があります。

rules:
  - DOMAIN,api.example.invalid,DIRECT
  - DOMAIN-SUFFIX,example.invalid,海外サイト
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,海外サイト

上の例では、まず単一ホストを直接接続し、同じサフィックスに属する他のドメインはプロキシへ送ります。これは「より具体的なルールを前に置く」という原則を示しています。実際の設定では DOMAIN-KEYWORD にも注意が必要です。同じ文字列を含む無関係なドメインまで誤ってマッチしやすいためです。サフィックスで表現できる場合は DOMAIN-SUFFIX を優先し、単一ホストを正確に制御する場合は DOMAIN を使います。

ルールの更新とロールバック

ルールセットの更新をクライアントのアップデートと同時に扱わないでください。クライアント、カーネル、サブスクリプションのノード、ルールセットにはそれぞれ異なる変更周期があります。一度に変更する層を1つに絞り、ログでルールプロバイダーが正常に読み込まれたか確認してから、代表的なドメインをいくつか検証します。更新後に多くのサイトで経路異常が起きた場合は、DNS、TUN、プロキシグループまで同時に変更せず、まず古いルールキャッシュへ戻すか、新しいプロバイダーを一時的に無効化してください。個人ルールを別ファイルに保存すれば、サブスクリプション更新でローカル変更が上書きされるのを防げます。

ログにルールプロバイダーのダウンロード失敗が出たら、まず URL にアクセスできるか、ファイル形式が一致しているか、キャッシュディレクトリに書き込み権限があるかを確認します。起動時だけ失敗し、その後の手動更新は成功する場合、端末がネットワークへ接続した直後で準備が整っていなかった可能性があります。その場合は自動更新間隔を延ばし、有効なキャッシュを残してください。ルール関連の基本用語は用語クイックリファレンスで確認できます。ルール名だけで効果を判断せず、最終的には接続ログに表示されるマッチしたルールとプロキシグループを根拠にしてください。

03 / 名前解決

DNS 設定の最適化と名前解決経路

DNS 設定はドメインをアドレスへ変換する方法を決め、ルールが十分な情報を取得できるかどうかにも影響します。問題がノードの不調と誤認されることは少なくありません。ノード接続が正常でも、名前解決の失敗、不適切な応答、誤ったネットワーク経路での問い合わせは、同じようにサイトが開けない原因になります。診断時は「DNS クエリを誰が処理するか」「どこへ送るか」「結果がどのようにルール判定へ渡るか」を3段階に分け、ノードを何度も切り替えないようにします。

基本リスナーと上流 DNS の役割分担

enable は mihomo の DNS モジュールを有効にするかどうかを制御し、listen は待ち受けアドレスを決めます。本機だけで使う場合は、ループバックアドレスでの待ち受けを優先してください。Android クライアントでは通常、アプリが待ち受けと VPN によるトラフィック制御を管理するため、LAN 端末向けにポートを開放する必要はありません。default-nameserver は主に暗号化 DNS の上流サーバー自身のドメインを解決するために使うので、通常は直接到達できる IP アドレスのリゾルバーを指定します。nameserver は通常の問い合わせを担い、proxy-server-nameserver はプロキシサーバーのドメインを専用に解決します。これにより、まだ確立していないプロキシ経路にノードの名前解決が依存する事態を避けられます。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

上流アドレスは現在のネットワークから到達できるかを基準に選び、数を増やせばよいとは限りません。複数のリゾルバーへ並列問い合わせを行うと異なる結果が返ることがあり、原因の切り分けも難しくなります。まず安定した上流を1組設定して基準を作り、必要に応じて分流を追加してください。プロキシサーバーがドメイン名で指定されている場合は、プロキシ起動前にそのドメインを解決できなければなりません。そうでないと「プロキシの確立に DNS が必要なのに、DNS にもプロキシが必要」という循環が発生します。

redir-host と fake-ip の違い

redir-host は実際の解決先アドレスを返すため、システム本来の動作に近く、互換性も分かりやすい方式です。ただし、後続段階でカーネルが IP しか認識できない場合があり、ドメインルールが有効になるかはトラフィックの入口とマッピング情報に左右されます。fake-ip は予約済みアドレス帯からドメインごとに一時アドレスを割り当てます。アプリがそのアドレスへ接続すると、カーネルがマッピングから元のドメインを復元してルール判定を行います。TUN 環境でもドメインルールの一貫性を保ちやすく、実際の DNS 応答がアプリへ先に露出する機会を減らせるのが利点です。

Fake-IP はリモートサーバーのアドレスではないため、DNS エラーとみなさないでください。198.18.0.0/16 の範囲の結果が表示される場合、通常は拡張モードが機能しています。確認すべきなのは、接続がカーネルに取り込まれているか、対応するマッピングが残っているかです。LAN 検出、デバイスへのキャスト、ネットワーク接続性の確認、特殊な DNS 応答に依存するアプリの一部は Fake-IP に適さないため、フィルターリストで実際の応答を返すようにできます。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.stun.*.*"
    - "connectivitycheck.gstatic.com"

フィルター項目は実際のログを見ながら少しずつ追加してください。多くのサフィックスをフィルターリストへ入れると、Fake-IP によるドメイン識別の効果が弱くなります。少なすぎると LAN サービスの検出に失敗することがあります。変更後は古い DNS キャッシュを削除するかカーネルを再起動し、古いマッピングが判断に影響しないようにします。

ドメインごとにリゾルバーを選択する

nameserver-policy を使うと、特定のドメインやルールセットに指定したリゾルバーを割り当てられます。たとえば内部ドメインは家庭内ルーターへ、パブリックドメインは暗号化 DNS へ送れます。ポリシーは一方向で説明しやすい構成にし、内部リゾルバーをすべての問い合わせのランダムな候補にしないでください。モバイル端末が Wi-Fi とモバイル回線を切り替えると、LAN リゾルバーへ突然到達できなくなることがあります。LAN アドレスに依存するポリシーでは、ネットワーク変更後の失敗も想定してください。

dns:
  nameserver-policy:
    "router.local": 192.168.1.1
    "+.home.arpa": 192.168.1.1
    "+.example.invalid":
      - https://1.1.1.1/dns-query

DNS 障害の確認順序は固定してください。まずドメインの問い合わせログが出ているか、次に上流が応答を返しているか、その後にルールがマッチしているか、最後に想定したプロキシグループ経由で接続が確立しているかを確認します。IP アドレスではアクセスできるのにドメインではできない場合、問題は名前解決層にある可能性が高いです。ドメインが解決済みでログに接続失敗が出ているなら、ノード、ルーティング、TUN の確認へ進み、DNS をさらに変更し続けないでください。

04 / トラフィック制御

TUN、Fake-IP、Android VPN インターフェース

TUN モードは仮想ネットワークインターフェースでシステムのトラフィックを受け取り、システムのプロキシ設定を参照しないアプリも mihomo へ渡せるようにします。Android クライアントはシステムの VPN 権限を使ってこのインターフェースを作るため、ステータスバーに VPN アイコンが表示されるのは正常です。TUN が解決するのはトラフィックの入口であり、Fake-IP が解決するのはドメインのマッピングと識別です。両者は組み合わせて使われますが、同じ機能ではありません。

自動ルートと厳格ルート

auto-route はカーネルがルートを自動設定し、対象トラフィックを TUN インターフェースへ向ける機能です。strict-route は、想定どおりインターフェースへ入らない経路をさらに制限し、別のルートからの迂回を減らします。一方で、テザリング、LAN アクセス、企業 VPN、特殊なシステムルートとの競合を大きくする可能性があります。初回は自動ルートで基本アクセスを確認し、その後に漏洩対策とアプリ互換性を考慮して厳格ルートを評価してください。

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

stack は TUN のネットワークスタック実装を決めます。mixed は通常、互換性と性能のバランスを取りやすい方式です。ただし、利用できる値はシステムやクライアントの実装によって異なるため、現在のクライアントが受け付ける設定を基準にしてください。ネットワークスタックの切り替えは診断手段であり、障害の根拠がない状態で頻繁に変更するものではありません。auto-detect-interface は実際の外向きインターフェースを識別する機能で、Wi-Fi とモバイル回線を切り替える端末で便利です。

DNS ハイジャックの範囲

dns-hijack は一般的な DNS ポート宛ての問い合わせを mihomo DNS モジュールへ渡し、アプリが統一された名前解決ポリシーを迂回しにくくします。ただし、アプリ内蔵の暗号化 DNS まで必ず取り込めるわけではありません。暗号化 DNS は通常の HTTPS や TLS 接続として見えるためです。ブラウザーがセキュア DNS を独自に有効化している場合、該当ドメインの解決が mihomo の通常 DNS ログに現れないことがあります。動作を統一したい場合は、アプリ設定で独立した名前解決を無効にするか、2つの解決経路を受け入れて別々に診断してください。

ハイジャックの範囲を無制限に広げるべきでもありません。LAN デバイスの検出、通信事業者の認証ページ、企業ネットワーク内のドメインはローカル DNS に依存する場合があります。Wi-Fi 接続後に認証ページが表示されない、プリンター名を解決できないといった場合は、まず TUN を一時停止して確認してください。そのうえで直接接続ルール、実 IP のフィルター、LAN DNS ポリシーを検討し、いきなり DNS 設定全体を削除しないでください。

Android のアプリ別ルーティング

Android の VPN インターフェースは、通常、同時に1つのアプリしか使用できません。システム内の他の VPN、仕事用プロファイル管理ツール、VPN ベースのファイアウォールやフィルターアプリが Clash Plus、Clash Meta for Android、FlClash、Surfboard と競合することがあります。画面上は起動済みでもシステムに VPN インターフェースが作られない場合は、他のアプリが権限を保持していないか、バックグラウンド実行権限が取り消されていないか確認してください。

クライアントがアプリの包含・除外に対応している場合、指定アプリだけを制御したり、一部の LAN ツールを迂回させたりできます。包含モードはテストしやすく、まずブラウザーを1つ選んで経路を確認し、徐々にアプリを追加します。除外モードは大半のアプリを制御し、銀行アプリや LAN 制御アプリだけを例外にしたい場合に適しています。両方を重ねると判断が難しくなるため、分かりやすい方式を1つだけ選び、どのアプリがシステム経由で直接通信するかを記録してください。

TUN の基本的な仕組みを先に理解したい場合は、Android 版 Clash の TUN モードの仕組みと有効化手順を参照してください。本章ではパラメーター同士の関係に重点を置いています。最終的な判断はスイッチがオンと表示されるかではなく、システム VPN インターフェース、DNS ログ、接続ログ、ルールのマッチ結果が一連の経路を形成しているかで行います。

05 / ドメイン復元

ドメインスニッフィングの用途、対象範囲、制約

接続がカーネルへ入る時点で宛先 IP しか含まれていないと、ルールシステムは元のドメインを直接知ることができません。ドメインスニッフィングは、TLS ハンドシェイクのサーバー名や HTTP リクエストの Host など、接続初期に見えるプロトコルメタデータを読み取り、ドメインを復元して再びルール判定へ渡します。ウェブページの本文を読む機能ではなく、すべての暗号化接続からドメインを取得できるわけでもありません。プロトコルが可視メタデータを提供するか、ハンドシェイク段階で接続を取り込めるかによって結果は変わります。

TLS、HTTP、QUIC スニッフィング

TLS スニッフィングは ClientHello 内の SNI の読み取りに、HTTP スニッフィングは Host の読み取りに使われます。QUIC スニッフィングは UDP ベースの関連ハンドシェイクを処理します。有効にするプロトコルを増やすほど対象範囲は広がりますが、誤判定や互換性問題も増えます。初期設定では必要なポート範囲だけを有効にし、除外リストを用意するとよいでしょう。アプリが接続直後に再試行する、動画の再生開始に失敗する、ログのドメインが実際のサービスと一致しないといった場合は、すべてのルールシステムを無効にするのではなく、対象ドメインやネットワーク帯でスニッフィングを無効にしてください。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "+.lan"
    - "+.local"

parse-pure-ip は、IP アドレスだけで指定された宛先からドメインの復元を試みます。force-dns-mapping は DNS マッピング情報を利用して識別を補助し、Fake-IP やカーネル DNS がすでにドメインの対応関係を把握している場合に特に有効です。override-destination は、スニッフィングしたドメインで後続接続の元の宛先を上書きするかどうかを決めます。上書きにより一部のドメインルールの一貫性は向上しますが、固定 IP、特殊な証明書動作、独自プロトコルに依存するサービスへ影響する可能性があるため、必要性を確認してから有効にしてください。

スニッフィングと Fake-IP の組み合わせ

Fake-IP 環境では、カーネルが仮想アドレスのマッピングから元のドメインを取得できる場合が多く、スニッフィングはカーネル DNS を迂回して実 IP へ直接接続するトラフィックを補う役割が中心になります。redir-host や一部の透過プロキシ環境では、ドメイン復元におけるスニッフィングの重要性が高まります。両方を有効にする場合は、ドメインの出所を理解しておきましょう。ログのドメインは DNS マッピング由来の場合もあれば、プロトコルのハンドシェイク由来の場合もあります。両者が一致しないとき、最終的にルール判定と接続に使う名前は上書き設定によって決まります。

ドメインルールを設定したのに IP ルールへマッチしても、必ずしもスニッフィングの失敗を意味しません。接続に取得可能なフィールドがない、暗号化されたクライアントハロー拡張を使っている、スニッフィング完了前に IP ルールで処理された、アプリが独自プロトコルを直接使っている、といった可能性があります。診断時は一般的な HTTPS サイトを基準にし、ログに SNI が表示されることを確認してから問題のアプリを調べてください。スニッフィングに対応しないプロトコルだけで機能全体を否定しないようにします。

除外リストとリスク管理

skip-domain は LAN ドメイン、デバイス検出サービス、スニッフィング後に異常が確認されたサービスドメインに適しています。一部の設定では宛先アドレスや送信元アドレス単位で除外でき、内部ネットワークにも利用できます。除外ルールはできるだけ具体的にし、広すぎるサフィックスを避けてください。一般的なトップレベルドメイン全体を除外すると、多数のパブリック接続でドメイン復元機能が失われます。

ドメインスニッフィングは、正しい DNS 設定の代わりにはなりません。DNS がすでに失敗していると、アプリはスニッフィング可能な接続を開始できないことがあります。IP 接続でも、必ず名前を復元できるとは限りません。まず DNS と TUN の経路を安定させ、その後にスニッフィングで IP だけのトラフィックを補うのが基本です。変更後は、ログの宛先、スニッフィング結果、マッチしたルール、最終プロキシグループを確認し、4項目が一致して初めて期待どおりと判断してください。

モバイル回線では、UDP と QUIC の経路が TCP と異なることがあります。ウェブページは開くのに動画やリアルタイム通信だけが不安定な場合は、QUIC スニッフィングを一時的に無効にするか、ルールで UDP 443 を遮断して比較し、アプリを TCP へフォールバックさせます。この操作は原因特定のためのもので、すべての UDP を常時遮断する設定ではありません。対象サービスとネットワーク条件を確認したうえで、対応するプロトコル範囲を決めてください。

06 / 設定オーケストレーション

ローカルオーバーライドと複数サブスクリプションの統合

サブスクリプションは通常、サービス提供者が管理しており、更新時にノード、プロキシグループ、ルールが置き換わります。サブスクリプションから生成されたメイン設定を直接編集すると、次回更新でローカル変更が簡単に消えてしまいます。オーバーライドの目的は、「リモートで頻繁に変わる部分」と「ローカルで長期的に保持したい部分」を分離することです。ノード一覧はサブスクリプションから取得し、DNS、TUN、個人ルール、プロキシ構造はローカルオーバーライドで安定して管理できます。

オーバーライドの優先順位と最小限の変更範囲

クライアントによってオーバーライドの呼び方は異なり、オーバーライド、ミックスイン、設定パッチ、スクリプト処理などと表記されます。名称にかかわらず、まず統合方向を確認してください。ローカルの項目がリモートを上書きするのか、配列をリモートの配列へ追加するのかを把握する必要があります。マッピング型の項目はキー単位で統合できても、配列型の項目は全体置換になる場合があります。ルールとプロキシグループはどちらも配列で、「追加」だと思っていた処理が実際には「置換」だと、サブスクリプション本来のルールがすべて消えることがあります。

最も安全なのは、オーバーライドの範囲を小さく保つことです。DNS の拡張モード、TUN の有効化、外部コントローラーの待ち受け、ルール先頭の個人的な例外など、明確に制御したい項目だけを変更してください。プロキシグループをローカルで完全に管理する場合は、リモートルールが存在しないグループ名を参照していないかも確認します。名前は参照関係の一部です。空白、大文字・小文字、全角記号の違いだけでも送信先が見つからなくなることがあります。

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

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

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

store-selected はプロキシグループの選択状態を保存し、サブスクリプションの更新やカーネル再起動のたびに選び直す手間を減らします。store-fake-ip は Fake-IP のマッピングを保存し、再起動後に既存接続の対応関係が失われる影響を抑えます。有効化するかどうかは、クライアントの保存権限と実際の症状を考慮して決めてください。マッピング異常が起きた場合は、古いキャッシュを消去して再構築し、状態を積み重ね続けないようにします。

proxy-providers で複数サブスクリプションを取り込む

複数のサブスクリプションを単純にコピーして、巨大なノード配列へまとめるべきではありません。proxy-providers を使えば、ソースごとに独立して更新・キャッシュでき、プロキシグループから必要なものだけを参照できます。メインと予備のサブスクリプションには別々のファイルパスを指定し、更新失敗時に互いを上書きしないようにします。ヘルスチェックをプロバイダー層に置けば、そのプロバイダーを参照する複数のプロキシグループで結果を共有できます。

proxy-providers:
  provider-main:
    type: http
    url: https://example.invalid/subscription/main
    path: ./providers/main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  provider-backup:
    type: http
    url: https://example.invalid/subscription/backup
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

例の URL は予約済みのテスト用ドメインです。実際のサブスクリプション URL は機密設定にあたるため、公開ファイル、スクリーンショット、共有ログへ記載しないでください。複数のソースに同名ノードがあると、カーネルやクライアントの統合時に上書き、改名、読み込み拒否が発生する可能性があります。プロバイダーで接頭辞、接尾辞、フィルターを使い、ソースを区別するとよいでしょう。たとえば予備ソースのノードに「予備」という接頭辞を一律で付けます。プロキシグループで絞り込む際も、接頭辞と地域キーワードを組み合わせ、同名ノードの出所を判断できるようにします。

更新失敗とロールバック方針

サブスクリプションの自動更新間隔を短くしすぎないでください。ノードの変更に分単位の更新は通常必要なく、頻繁なリクエストは失敗の可能性を高めます。一時的なネットワーク障害時に不完全な内容で現在の設定が置き換わることもあります。クライアントに「設定の自動更新・間隔 1440 分」のような項目がある場合、日次更新で通常の変化には十分対応できます。更新後はまず構文を検証し、その後に稼働中の設定を切り替えてください。旧設定を保持できるクライアントでは、少なくとも直前の起動可能なバージョンを保存します。

複数サブスクリプションの統合後に起動できなくなったら、層ごとに分けて確認します。まずローカルの基本設定だけを残し、次にメインプロバイダー、予備プロバイダー、最後にプロキシグループとルールを順番に追加します。解析エラーは項目や行番号を特定できることが多く、論理エラーは「ノードが読み込まれているか、グループにメンバーがあるか、ルールの送信先が存在するか」の3段階で確認します。失敗中に変換スクリプトを追加し続けると、元のエラーがさらに多くの処理層に包まれてしまいます。

デスクトップと Android の間で移行する場合は、デバイス固有のパスを含まない汎用項目を優先して移してください。Windows と Android では、ファイルパス、待ち受け権限、TUN の実装、アプリ別ルーティングの扱いが異なるため、同じ完全な設定をすべてのプラットフォームでそのまま使えるとは考えないでください。サポート終了クライアントからの移行については、mihomo カーネル搭載クライアントへの設定移行ガイドを参照してください。

07 / コントロールインターフェース

外部コントロールパネルとインターフェースの安全範囲

mihomo の外部コントロールインターフェースでは、対応パネルからプロキシグループの読み取り、メンバーの切り替え、接続とログの確認ができます。これは管理機能であり、プロキシポートではありません。コントロールインターフェースは mixed-port、HTTP プロキシポート、SOCKS ポートとは別に設計してください。本機だけで使う場合はループバックアドレスで待ち受け、LAN 内の他の端末から管理画面へアクセスされる可能性を減らします。

待ち受けアドレスとアクセスパスワード

external-controller: 127.0.0.1:9090
secret: "replace-with-a-local-password"
external-ui: ./ui
external-ui-name: dashboard

external-controller は待ち受けアドレスとポートを指定します。127.0.0.1 は本機からの接続だけを受け付け、クライアント内蔵パネルや同じ端末のブラウザーに適しています。LAN から管理する必要がある場合は、LAN から到達できるアドレスで待ち受けられますが、必ずアクセスパスワードを設定し、システムファイアウォールで接続元を制限してください。コントロールインターフェースでは稼働状態の変更や接続情報の閲覧ができるため、インターネットへ直接公開してはいけません。

external-ui は静的パネルファイルのディレクトリを指定します。パネルはコントロールインターフェースのフロントエンドにすぎず、正常に読み込まれたからといってカーネルへ接続できているとは限りません。画面が空白になる、プロキシグループが表示されない場合は、静的ファイルの存在、ブラウザーからコントロールアドレスへアクセスできるか、パスワードが一致しているか、パネルのプロトコルとポートが正しいかを個別に確認します。クライアントにパネル入口が用意されている場合は、手動でディレクトリを設定するより、クライアントが管理するパスを優先してください。

別の端末から LAN のコントロールパネルへアクセスする

端末をまたいだアクセスには、4つの条件を同時に満たす必要があります。カーネルがループバック以外のアドレスで待ち受けていること、OS のファイアウォールがポートを許可していること、アクセス元の端末からホストの LAN アドレスへ到達できること、コントロールパスワードが正しいことです。どれか1つでも満たさないと、パネル接続失敗として表示されます。まずカーネルが動作している端末から本機アドレスへアクセスし、次に同じ LAN 上の別端末から試してください。最初からプロキシポート、TUN ルート、コントロールインターフェースを同時に変更しないでください。これらは別々の問題を解決する設定です。

allow-lan は主に、プロキシポートが LAN 接続を受け付けるかどうかに影響します。外部コントロールインターフェースの唯一の有効化スイッチではありません。コントロールインターフェースは独自の待ち受けアドレスで決まります。他の端末にはプロキシだけを使わせ、カーネルの管理を許可したくない場合は、プロキシポートを開放したままコントロールインターフェースをループバックアドレスに制限できます。逆に、コントロールインターフェースだけを開放しても、LAN 端末が自動的にプロキシを使えるようにはなりません。

インターフェースから状態を取得する

デバッグ時は、本機からコントロールインターフェースへリクエストを送り、カーネルが応答するか確認できます。以下の例ではバージョン情報とプロキシグループ一覧だけを取得し、実際のパスワードは含めていません。パスワードを設定している場合は、リクエストヘッダーに対応する認証情報を指定します。コマンドはカーネルが動作している同じ端末で実行してください。

curl http://127.0.0.1:9090/version
curl http://127.0.0.1:9090/proxies

1つ目のリクエストでコントロールサービスが起動しているか確認し、2つ目でプロキシグループが正常に読み込まれているか確認します。ポート接続が拒否された場合は、まず待ち受けアドレス、ポートの使用状況、カーネル起動ログを確認します。未認証が返る場合は、インターフェースは存在するもののアクセスパスワードが一致していません。データは返るのにパネルへ表示されない場合、問題はプロキシグループではなく、パネル設定、ブラウザーの制限、静的リソースにあります。

ログレベルと接続の確認

log-level: info は日常の診断に適しており、ルールのマッチや接続確立の情報を確認できます。より詳細なデバッグレベルでは大量の記録が出るため、問題を再現するときだけ短時間有効にしてください。ログにはアクセス先ドメイン、LAN アドレス、プロキシ名が含まれる場合があります。共有前に個人のサブスクリプション URL、認証情報、関係のない接続を削除してください。診断後は通常のログレベルへ戻し、長時間の記録によるストレージ圧迫を避けます。

外部パネルは状態の確認に適していますが、設定ファイル自体のバージョン管理に取って代わるものではありません。プロキシグループの切り替えは実行時の状態であり、ルール、DNS、TUN のパラメーターは設定のソースへ戻って変更してください。そうしないと、再起動、サブスクリプション更新、クライアント変更後にパネル上の一時的な操作から完全な意図を復元できません。

08 / 障害診断

設定診断の順序と長期メンテナンス

複雑な設定で問題が起きたときに最も有効なのは、すべてのスイッチを次々に切り替えることではなく、変数を減らすことです。経路を「設定解析、プロキシプロバイダー、DNS、ルール判定、プロキシ選択、トラフィック制御、宛先接続」の7層に分け、各層が正常かを一つずつ確認します。ログの最初のエラーは、後続の連鎖エラーより価値があることが多いものです。設定を読み込めない、プロバイダーを取得できないといった上流の問題を先に処理し、その後で個別サイトの接続を確認してください。

最小限の実行可能な設定から始める

診断の基準として、利用可能なプロキシ1つ、手動プロキシグループ1つ、基本 DNS、最後のルールだけを残した最小設定を作成します。起動できることを確認したら、プロキシグループ、ルールプロバイダー、TUN、Fake-IP、スニッフィング、オーバーライドの順に1層ずつ戻します。各層を戻すたびに、直接接続するサイト、プロキシを使うサイト、LAN アドレス、問題のアプリを同じ条件でテストします。対象を固定すれば、サイト側の一時的な変動を設定変更の影響と誤認しにくくなります。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: local-test
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: テスト用プロキシ
    type: select
    proxies:
      - local-test
      - DIRECT

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,テスト用プロキシ

例のローカル SOCKS サービスは、端末上で対応するポートが実際に動作している場合にだけ利用できます。これは最小構成を示すためのもので、公開ノードではありません。実際の診断では、動作確認済みのサブスクリプションノードへ置き換えてください。最小設定の目的は、クライアント、カーネル、基本的なネットワーク経路が動作することを確認することです。それでも起動できない場合は、YAML のインデント、対応フィールドの範囲、ポート競合を先に確認します。

現象に応じて確認する層を選ぶ

「接続済みなのにインターネットへアクセスできない」場合は、まず既定のプロキシ戦略が利用可能なメンバーを選んでいるか確認し、次に DNS が応答を返しているか、最後に TUN が取り込んでいるかを確認します。詳しいチェック項目はAndroid 版の段階的トラブルシューティングを参照してください。「一部のサイトだけ失敗する」場合は、ルール、IPv6、DNS の結果、UDP、接続先サービスの出口制限が原因である可能性が高くなります。「すべてのノードが遅い」場合は、まず自宅 Wi-Fi、モバイル回線、システムの省電力制限を除外します。「1つのノードだけ遅い」場合は、ノードと回線を優先して確認します。速度問題についてはノード、回線、ローカル設定の3層診断も参照してください。

ログに DIRECT と表示され、プロキシを使うはずだった場合は、ルールの順序とドメインの復元状態を確認します。正しいプロキシグループが表示されているのに接続できない場合は、そのグループの現在のメンバーを確認してください。接続ログがまったくない場合は、アプリがシステムプロキシや TUN に入っているか確認します。DNS ログはあるのに後続の接続がない場合、アプリのキャッシュ、想定外の解決結果、システム層による接続阻止などが考えられます。現象ごとに確認すべき層は異なるため、すべてを「ノードを変更する」だけで解決しようとしないでください。

YAML 構造とよくある解析エラー

YAML はスペースで階層を表し、タブと混在させることはできません。リスト項目のハイフンは同じ階層の項目と揃え、コロン、シャープ記号、特殊文字を含む名前には引用符を使えます。重複キーはパーサーによって上書きされる場合もあれば、直接エラーになる場合もあります。複数の設定を統合する際は、dns が2つ、rules が2つ、同名のプロバイダーが複数存在しないか特に確認してください。解析できることと参照関係が正しいことは別です。プロキシグループ、ルールセット、プロバイダー名も確認する必要があります。

エラー行番号が表示されたら、その前の数行も同時に確認してください。実際にインデントや引用符が欠けている場所は、エラー行より前にあることがよくあります。直近に追加したブロック全体をいったん削除して復旧するか確認し、その後ブロックを半分ずつ戻して二分探索で特定できます。エラー行だけを削除しないでください。その行は、パーサーが初めて処理を続けられなくなった場所にすぎない可能性があります。

変更履歴、バックアップ、更新ペース

3つの状態を保持することをおすすめします。最後に動作を確認した設定、現在テスト中の設定、サブスクリプションまたはルール更新前のスナップショットです。ファイル名には日付と用途を使えますが、公開場所にサブスクリプション URL を保存しないでください。変更のたびに「なぜ変更したか、どのフィールドを変更したか、どう検証したか」を記録すると、大量のコピーを保存するだけよりロールバックしやすくなります。クライアント更新、カーネル変更、サブスクリプション更新、ルールセット更新は分けて実行し、一度の変更で4つの層を同時に変えないようにします。

クライアントを更新するときは、現在のプラットフォームに適し、継続的に保守されているパッケージを優先してください。Android ではインストールパッケージ一覧の Android セクションから Clash Plus、Clash Meta for Android、FlClash、Surfboard を確認できます。デスクトップでは対応するプラットフォーム向けのものを選びます。Clash for Windows と ClashX Meta は開発が終了しているため、移行時はまず汎用設定をエクスポートし、その後でプラットフォーム固有の項目を調整してください。旧クライアント向けのパッチを追加し続ける方法は避けます。

長期的に安定する設定は、通常それほど複雑ではありません。明確なプロキシ層、限定され信頼できるルールソース、説明しやすい DNS 経路、制御された TUN 範囲、ロールバック可能なオーバーライドを備えています。自動化は、こうした関係を明確にした後に導入すべきです。設定の目的はすべてのオプションを有効にすることではなく、各接続の入口、名前解決、ルール判定、出口の選択をログから説明できるようにすることです。