Clash高度な設定ガイド

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

ルールの振り分け先とノード選択を分ける

プロキシグループは、ルールと実際のアウトバウンドの間にある中間層です。ルールが接続をどのグループに渡すかを決め、グループが使用するアウトバウンドを選びます。業務ルールを特定のノード名に直接結び付けると、ノード名の変更、サブスクリプションの差し替え、プロバイダーの変更がルールにも影響します。安定したグループ名を用意すれば、メンバーだけを管理すればよく、ルールは同じ宛先を参照し続けるため、長期的な保守が容易になります。

proxiesには個別のアウトバウンド、proxy-groupsには選択や自動振り分けに使うグループ、rulesには順番に評価されるルールを定義します。3か所で使う名前は完全に一致させてください。空白、大文字・小文字、日本語の句読点も勝手に変えないでください。グループから別のグループを参照できますが、循環依存は作れません。たとえば、業務グループが自動選択グループを参照し、その自動選択グループが業務グループを参照すると、有効な選択経路を構成できません。

選択動作に合わせてグループの種類を決める

selectは手動選択用で、出口を明示的に選べる状態にしたい場合に適しています。url-testは疎通テストの結果に応じてアウトバウンドを選び、用途の近い回線をまとめる場合に使います。fallbackはメンバーを順番に確認し、先頭側の利用可能な出口を優先します。load-balanceはポリシーに従って接続を振り分けます。複数ノードの帯域を一つのダウンロードに合算する機能ではなく、同じアカウントの接続が常に同じIPアドレスから出ることも保証しません。

業務グループと自動選択グループの2層構成

以下の例では、カーネル組み込みのDIRECTアウトバウンドを使っています。そのためグループ間の参照関係を確認できますが、プロキシとしては動作しません。実際に使う場合は、自動選択グループのDIRECTメンバーを既存ノード名に置き換えるか、useで定義済みのプロキシプロバイダーを参照してください。自動選択が業務要件に合わない場合に固定の出口へすぐ戻せるよう、手動選択の入口も残しておきます。

proxy-groups:
  - name: 自動出口
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 通常利用
    type: select
    proxies:
      - 自動出口
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,通常利用
  - MATCH,通常利用

intervalの単位は秒で、チェック間隔を指定します。toleranceの単位はミリ秒で、小さな差による頻繁な切り替えを抑えます。lazyはグループ未使用時のチェック動作を制御します。テスト先は安定してアクセスでき、できるだけ回線の用途に合うものを選んでください。軽量なWebページ一つへのテスト結果だけでは、大容量ファイルの転送、動画再生、特定地域のサービスの品質は判断できません。

ログイン状態を維持するサービスには専用の手動グループを用意し、出口をできるだけ固定するのがおすすめです。ショッピング、決済、アカウント管理の通信を頻繁に切り替わる出口に含めると、サービス側で不審なアクセスと判定されることがあります。切り替える場合は、関連タスクを停止してから対象ノードを選び、接続し直してください。すでに確立した接続は、グループの選択を変えても通常は自動で移行しません。

実際に適用されたルールからグループの経路を確認する

トラブル対処では、まず接続の詳細でルールの振り分け先を確認し、次にプロキシグループで現在選択されている項目を開き、最後に実際のノードを確認します。画面上で特定のノードが選択されていても、対象サイトの通信がそのグループを通るとは限りません。ルールが先にDIRECTへ振り分けている場合や、アプリの通信がカーネルに届いていない場合があります。回線を比較する前に経路を確認すれば、ルールの問題をノードの問題と取り違えずに済みます。

グループが空の場合は、メンバー名が存在するか、プロキシプロバイダーの読み込みに成功したか、フィルター式ですべてのノードが除外されていないかを確認してください。参照エラーを隠すために全体モードを何度も切り替えるのは避けましょう。モードの意味はアウトバウンドモードのガイドで確認できます。YAMLの各セクションの関係は、設定ファイルをセクションごとに解説で詳しく説明しています。

ルールセットをサブスクリプションで管理する

ルールの順序を決めてから、参照元を分ける

ルールは上から順に評価され、通常は最初に条件が一致した項目でアウトバウンドが決まります。具体的なドメインルールは広範囲な地域ルールより前に置き、最後にフォールバックを配置してください。ルールを外部ファイルに分けても、評価順の仕組みは変わりません。適切に管理されたルールセットでも、配置場所を誤ると一度も評価されないことがあります。

rule-providersはルールリソースを宣言し、RULE-SETはそのリソースをマッチング処理に組み込みます。プロバイダー名は参照用の識別子であり、プロキシ経由かDIRECTかを自動で決めるものではありません。実際の振り分け先はRULE-SETの後に指定します。同じルールセットを異なる設定で別々のプロキシグループに割り当てれば、分類データと個人のアウトバウンド設定を分けて管理できます。

behaviorとformatの違いを理解する

behaviorは内容の解釈方法を指定します。domainはドメインの集合、ipcidrはIPアドレスの範囲、classicalはDOMAIN-SUFFIXやIP-CIDRなどのルール種別を含む形式です。formatはファイルの形式を指定し、YAML、プレーンテキスト、MRSなどがあります。拡張子は命名上の慣習にすぎないため、実際の内容形式を確認してください。

まずインラインプロバイダーを使って、ルールを取り込む一連の関係を示します。リモートからダウンロードする必要がないため、名前、behavior、ルール順を検証するのに適しています。classicalの各ルールに振り分け先を記述する必要はありません。参照元のRULE-SETで指定するためです。ルール項目に振り分け先まで重ねて記述すると、形式に互換性がなくなることがあります。

rule-providers:
  ローカル例外:
    type: inline
    behavior: classical
    payload:
      - DOMAIN-SUFFIX,example.com
      - IP-CIDR,192.168.50.0/24,no-resolve

rules:
  - RULE-SET,ローカル例外,DIRECT
  - MATCH,DIRECT

ローカル構成を読み込めることを確認してから、集中管理が必要な部分をリモートプロバイダーに切り替えます。以下のURLは説明用です。実際に使う前に、アクセス可能で内容形式も一致するルールファイルのURLに置き換えてください。既存のルールサービスとして使えるものではありません。相対パスのpathはカーネルの作業ディレクトリを基準に解決され、クライアントから見えるサブスクリプション保存先と一致するとは限りません。

rule-providers:
  サービス用ドメイン:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/business.yaml
    path: ./rules/business.yaml
    interval: 86400

rules:
  - RULE-SET,サービス用ドメイン,DIRECT
  - MATCH,DIRECT

更新とオフライン復旧の手順を設計する

リモート更新では、初回起動とその後の更新の両方を考慮してください。ローカルキャッシュがなく、リソースの取得にまだ確立していないプロキシ経路が必要な場合、起動時に依存関係の循環が起きることがあります。現在のネットワークからアクセスできるルールソースを優先してください。リソースのダウンロードに使うアウトバウンドを指定する場合は、現在のカーネルが対応するプロバイダーフィールドを確認し、そのアウトバウンドが対象のルールセットに依存しないようにします。

更新間隔を短くしすぎないでください。ルール分類は通常、秒単位で変化するデータではありません。頻繁に取得するとネットワークリクエストが増え、誤った更新も速く広がります。復元可能な前の設定を残し、ログでプロバイダーの読み込み完了を確認してください。キャッシュを継続利用できるかはキャッシュの状態、クライアントの保存先、失敗の種類によって異なり、恒久的な保証ではありません。

ルールセットごとに別のパスを指定し、複数のプロバイダーで同じファイルを使わないでください。PCの移行やクライアントの再インストール時は、メインのYAMLだけでなくローカルルールファイルもバックアップします。モバイルアプリのサンドボックスとデスクトップのファイルシステムは異なるため、絶対パスをそのままコピーしても移植できないことがあります。長期的な設定では分かりやすい相対パスを使い、クライアントが管理するファイルも記録してください。

誤マッチとDNSへの影響に対処する

サイトの振り分けが誤っている場合は、まず実際にマッチしたルール名を確認し、分類データとルール順のどちらに問題があるか判断します。個別の例外は通常、共通ルールセットより前に置き、必要なドメインやネットワーク範囲だけを記述します。特定のドメインを直すために大きなカテゴリ全体をDIRECTにすると、同じルールセット内のほかの通信経路も変わってしまいます。

no-resolveは、一部のIPアドレス系ルールで判定のために追加のドメイン解決が発生するのを避ける設定です。接続全体のDNSを無効にするものではありません。アプリから接続先IPアドレスが渡されている場合、IPアドレス系ルールは引き続き評価できます。ドメインルールとIPアドレスルールを混在させる場合は、どの段階で名前解決が発生するかを明確にしてください。そうしないと、ルールによるクエリをDNSの重複リクエストと誤認することがあります。

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

クエリの経路から名前解決の発生箇所を特定する

DNSを最適化するには、まずクエリの経路を把握します。アプリがドメインをどこに渡し、システムが処理を引き継ぐか、カーネルにクエリが届くか、最後にどの上流DNSが応答するかを確認してください。メインYAMLのDNSアドレスを変更しても、ブラウザー、システムサービス、単独アプリがすべて同じ経路を使うとは限りません。ブラウザー内蔵の暗号化DNS、アプリ内の名前解決、キャッシュによってテスト結果が想定と異なることもあります。

システムプロキシは、プロキシ設定に従うアプリの通信を主に処理します。システム全体のDNSを自動で処理するわけではありません。TUNを使うと処理範囲を広げられますが、ルーティング、DNSハイジャックの設定、アプリの動作にも左右されます。検証時はテストするアプリを一つに決め、必要なキャッシュを消して、カーネルログのドメイン情報と照合してください。上流DNS、拡張モード、ルーティング設定を同時に切り替えると、どの変更が効果をもたらしたか判断しにくくなります。

ブートストラップ用・通常用・ノード用の名前解決を区別する

default-nameserverは主に、DNSの上流サーバー自身のホスト名を解決するために使います。nameserverは通常のクエリで使う上流DNSの一覧です。proxy-server-nameserverはプロキシノードのドメインを解決し、ノードの名前解決がプロキシに依存し、プロキシの接続確立もノードの名前解決に依存する循環を避けるのに役立ちます。これらのフィールドは単純なプライマリ／セカンダリの関係ではありません。名前だけを見て、順番に失敗したら切り替わる設定だと解釈しないでください。

nameserver-policyを使うと、指定したドメインに特定の上流DNSを割り当てられます。LAN内サービスや社内ドメインなどに便利です。マッチ構文は現在のカーネルのドキュメントで確認してください。通常のサブドメインには+.example.comのような書き方が使えます。内部ドメインは名前を解決できる内部DNSに渡してください。公共DNSに送ってからプライベートアドレスが返ることを期待するのは避けましょう。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.example.com":
      - 192.168.50.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"

例にあるプライベートネットワーク用DNSアドレスは、実際のルーターや組織が提供するDNSに置き換えてください。内部ドメインが不要なら、到達できないアドレスを残さず、該当するポリシーを削除します。暗号化DNSはクエリの転送方式を変えるもので、プロキシ経由になることを自動で保証しません。接続の出口は、カーネルのDNS設定、ルーティング、ルールを合わせて判断してください。

ルール準拠とフォールバックDNSは慎重に設定する

respect-rulesを有効にすると、DNS上流への接続にルーティングルールを適用できますが、依存関係も増えます。有効にする前にノードのドメインを解決できる専用経路を用意し、ルールによってDNS接続が未確立の出口に再び依存しないことを確認してください。ネットワークが安定しているなら、設定が整って見えるという理由だけで有効にする必要はありません。

fallbackとfallback-filterを使う場合は、カーネルがどの応答を有効と判定するかを先に理解してください。フォールバックDNSは、通常の上流がタイムアウトした後だけ使われる予備とは限りません。フィルター条件によって返される応答が決まる場合があります。実際のネットワーク環境を把握せずに地域条件やアドレスフィルターを大量にコピーすると、余分なクエリやアドレス選択の不一致が起こりやすくなります。

IPv6は、DNSの応答、システムのルーティング、ノードの対応状況、接続先サイトへの到達性を合わせて評価してください。dns.ipv6: falseは主にカーネルのDNS応答に影響します。システム全体でIPv6を無効にするわけではなく、アプリがキャッシュ済みのアドレスを使うことも防げません。一部のサイトだけ読み込みに時間がかかる場合は、接続の詳細で到達不能なIPv6経路を先に試していないか確認してください。

症状からトラブル対処の範囲を絞る

ドメインをまったく解決できない場合は、上流DNSに到達できるか、上流DNS自身のホスト名を解決できるかを確認してください。ノードへの接続だけ失敗する場合は、ノードのドメイン解決を優先して確認します。社内サービスだけに問題があるなら、公共DNSへ誤って送信されていないか確認してください。関係のない複数のサイトが同時に遅くなる場合は、システム標準の名前解決とカーネルの名前解決を比較し、問題が本当にDNSに起因するかを判断します。

名前解決が成功しても、接続先に到達できるとは限りません。ログにアドレスが記録されているのに接続がタイムアウトする場合は、ルールの出口、ファイアウォール、回線を続けて確認してください。DNSを何度も変更するのは避けましょう。ブラウザー、システム、カーネルのキャッシュはそれぞれ独立しているため、変更後はテスト対象に応じてキャッシュを消し、既存の接続も閉じてください。キャッシュの残留と通信速度のボトルネックの見分け方は、通信速度低下の段階的な確認方法を参照してください。

TUN仮想ネットワークインターフェースとFake-IP

通信の入口とDNS拡張モードを区別する

TUNはシステムに仮想ネットワークインターフェースを作り、ルーティング条件に合う通信をカーネルに送ります。Fake-IPはDNS拡張モードです。カーネルがドメインに仮想アドレスを返し、対応関係からドメインを復元して後続の処理を行います。両方を併用することはよくありますが、同じ設定ではありません。TUNを有効にしてもDNSを処理しているとは限らず、Fake-IPを有効にしてもすべてのアプリが仮想インターフェースを経由するとは限りません。

システムプロキシはブラウザーなど、プロキシ設定に従うアプリに適しています。TUNはシステムプロキシの対象外の通信も取り込みたい場合に向いています。切り替える前に既存のシステムプロキシ経路が正常であることを確認し、TUNは個別に検証してください。ほかのVPN、仮想ネットワークインターフェースソフト、エンドポイントセキュリティ製品がインストールされている場合は、デフォルトルートとインターフェースの優先順位を確認します。複数の通信制御ツールが自動で連携すると決めつけないでください。

最小限のルーティング設定から始める

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

auto-routeは関連ルートを自動設定し、auto-detect-interfaceは出口インターフェースを自動検出します。stackは通信処理のスタックを指定するもので、性能を切り替える設定ではありません。対応状況はOS、プロトコル、アプリによって異なります。まずはクライアントの現在のデフォルト値を使い、問題を再現して比較結果を記録したうえで、ほかの対応スタックを試してください。

dns-hijackの一般的なポート指定によるハイジャックは、通常のDNS通信を主な対象とします。暗号化DNSもカーネルのクエリに変換されるとは限りません。実際の効果はOSやルーティングの動作にも左右されます。アプリが暗号化DNSサービスへ直接接続すると、想定したドメインマッピングを経由しないことがあります。ポートルールを次々と追加するのではなく、アプリ独自のDNS設定を確認してください。

権限とプラットフォームの違いに対処する

デスクトップでは、クライアントが提供するサービスのインストールと権限付与の手順で有効にしてください。デスクトップ環境全体を過剰な権限で長期間実行するのはおすすめしません。AndroidのVPN権限はシステムが管理しており、通常は同じVPN経路を占有するアプリを2つ同時に実行できません。iOSでは対応するクライアントの設定画面を使ってください。デスクトップ向けTUNフィールドがすべてのプラットフォームで同じ操作を表すとは限りません。

デバイスを社内ネットワークに接続している場合、内部ネットワークの範囲、専用DNS、セキュリティソフトに追加の要件があることがあります。まず組織が許可している接続方法を確認し、必要なルート除外を設定してください。すべてのプライベートアドレスを対象にする除外リストをそのままコピーしないでください。カーネルを経由すべき業務通信も含まれることがあります。除外範囲は実際のネットワークに合わせ、リモートサービスへの通信がLAN側に流れないようにしてください。

Fake-IPのマッピングと互換性の例外を管理する

Fake-IPが返す仮想アドレスは、ノードのアドレスでも接続先サーバーの実アドレスでもありません。アプリがそのアドレスに接続すると、カーネルがマッピングを使ってドメインを復元します。設定の切り替えやカーネルの再起動後に、システムが古い仮想アドレスをキャッシュしていて、カーネル側のマッピングが変わっていると、一時的に接続に失敗することがあります。まず該当するキャッシュを消して接続し直し、マッピングの永続化が必要かどうかを検討してください。

fake-ip-filterは、一致したドメインを実アドレスで解決します。LAN内のデバイス検出や特定アプリなど、実アドレスが必要な場合に使います。トラブル対処のためにインターネット全体を対象とする大規模なフィルターを一度に追加しないでください。Fake-IPによるドメインとの関連付けが失われます。フィルターを追加した後も、実アドレスが正しいか、アクセスルールが適切かを確認してください。フィルター自体で到達できないサーバーを修復することはできません。

通信の取り込みに成功したかどうかは、接続画面にテストアプリの新しい接続が表示され、マッチしたルールと出口を確認できるかで判断してください。TUNスイッチがオンになっているだけでは十分ではありません。TUNをオフにした後は、ネットワークが復旧したか、システムに手動プロキシの設定が残っていないかも確認します。インストールや権限の問題はガイドを確認してください。クライアントを変更する場合は、ダウンロードセンターでプラットフォームを選び、複数のプロキシ入口を同時に実行して比較するのは避けましょう。

ドメインスニッフィングとルールマッチ

スニッフィングで補える情報を理解する

カーネルに入る接続に接続先IPアドレスしかなく、ドメインルールに使える情報が不足していることがあります。ドメインスニッフィングは、HTTPのHost、TLSハンドシェイクで確認できるサーバー名、対応するQUICハンドシェイク情報などからホスト名を抽出します。追加されるのはルーティングの手掛かりであり、暗号化されたWebページの内容を復号するものではありません。また、すべての接続からドメインを特定できるとは限りません。

Fake-IPのマッピングが完全な場合、カーネルは通常すでに対応するドメインを把握しているため、スニッフィングの効果は小さいことがあります。アプリが独自に名前解決する場合、実IPアドレスを直接使う場合、またはDNSクエリがカーネルを経由しない場合は、ドメインルールへのマッチ改善が期待できます。まずどの段階で情報が不足しているかを確認し、有効化するか判断してください。安定している通信経路を、設定をそろえるためだけに複雑にする必要はありません。

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

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

この例では、対象を一般的なWebポートに絞っています。parse-pure-ipは、ドメイン名のないIPアドレス宛ての接続でもスニッフィングを試します。force-dns-mappingは、一部のDNSマッピングに関連するスニッフィング処理を拡張します。どちらも、アプリが送信していないホスト名を生成するものではありません。ポート範囲を広げるほど処理対象が増え、Web以外のプロトコルを誤って候補とみなす可能性も高くなります。

override-destinationはマッチ情報を補うだけでなく、スニッフィング結果で接続先を書き換えるかどうかを指定します。書き換えによって新たなドメイン解決が発生し、アプリが選んだものとは異なるアドレスに接続することがあります。特定の入口、アドレスへの固定、LAN内DNSに依存するサービスでは、変更の影響を慎重に検討してください。初回のテストでは無効のままにして、ルーティング情報だけで十分かを確認できます。

互換性問題には対象を絞った例外を設定する

skip-domainは、スニッフィングに適さないと分かっているドメインを対象外にします。例のサフィックスは形式を示すものです。実際には問題が起きるサービスを指定してください。例外を追加する前に、スニッフィングの有効時と無効時で接続ログ、接続先アドレス、マッチしたルールを比較します。再現性のある違いだけを長期的な例外にしてください。一時的な回線問題を不要な設定として固定してしまうおそれがあります。

アプリが固定IPアドレスを使い、ハンドシェイクにもドメインが含まれない場合、ドメインルールを適用する確かな根拠はありません。その場合は、明示的なIPルールか、クライアントとプラットフォームが対応する範囲でプロセスルールを検討してください。ドメインルールをマッチさせるためにマッピングを作り上げるのは避けましょう。一つのアドレスで複数のサービスが提供されることがあり、逆引きで得た名前もアプリが実際にアクセスしたホスト名とは限りません。

暗号化クライアントHelloなどの技術によって、ハンドシェイクから確認できる情報が減ることがあります。標準外のプロトコルは解析できない場合もあります。QUICを正しく解析できるかは、カーネルの機能と実際のハンドシェイク構造にも左右されます。スニッフィングでドメインが見つからなくても、設定ミスとは限りません。スニッフィングのポートを際限なく広げるのではなく、通信の入口とDNS経路を見直し、アプリのクエリをカーネル経由にするべきか判断してください。

同じ接続でルールの変更を検証する

比較テストでは、まずテストアプリの既存接続を閉じてから、対象のページを一つだけ開きます。接続の詳細で、元の接続先、識別されたドメイン、マッチしたルール、最終的なアウトバウンドを記録してください。その後、スニッフィングのスイッチかパラメーターを一つだけ変更し、同じ手順を繰り返します。既存の長時間接続はハンドシェイクをやり直しません。ページを再読み込みしても古い接続が再利用され、変化がないように見えることがあります。

ドメインスニッフィングとルールの優先順位は別の問題です。正しいドメインを識別できても、先に評価されるIPアドレスルールやプロセスルールでアウトバウンドが決まることがあります。結果が想定と異なる場合は、先にマッチしたルールを確認してから順番を調整してください。グローバルモードでプロキシ接続が見えても、ドメインルールが機能している証明にはなりません。

有効化後、一部のアプリだけ初回通信が遅くなる場合は、スニッフィング範囲が広すぎないか、対象プロトコルが対応しているか、不要な接続先の書き換えを有効にしていないか確認してください。すぐにノードの品質が原因と決めつけないでください。対象プロトコルとポートを一つに絞って再現条件を保ち、ログページのよくあるエラーを参考に、ハンドシェイク失敗、名前解決失敗、接続タイムアウトを区別できます。

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

サブスクリプションの原文を保ち、最終的に有効な設定を把握する

サブスクリプションは外部からの入力、クライアントに保存されたProfileは設定を入れるコンテナ、カーネルが読み込むのは最終的に有効な設定です。この3つは完全に一致しないことがあります。クライアントがポート設定、TUNオプション、ローカルオーバーライドを追加したり、再読み込み時にファイルを再生成したりするためです。キャッシュされたサブスクリプションの原文を直接変更しても、次の更新で失われやすく、長期的な管理方法には適しません。

まず設定画面で現在有効なProfileを確認し、クライアントにオーバーライド、拡張、設定編集の機能があるかを調べてください。機能名やマージ方法はクライアントによって異なります。FlClashでは、現在の画面と実際に生成された結果を基準にしてください。対応する機能が見つからない場合は、独立したローカルの完全設定を管理し、任意のYAML断片が自動でマージされると考えないでください。

ローカルオーバーライドには個人ルール、DNSの優先設定、コントローラーの制限を保存し、ノード情報はサブスクリプションプロバイダーに任せる方法が適しています。分離しておけば回線の更新時に個人ルールを書き直す必要がなく、端末を変える際も環境固有の設定を見分けやすくなります。基本的な考え方はProfileと複数設定の管理を参照してください。サブスクリプションの初回追加は、引き続きガイドの手順に従ってください。

マッピング、リスト、参照を分けて扱う

YAMLのマッピングとリストは、同じ考え方で処理できません。マッピングはキーごとにマージされる場合も、オブジェクト全体が置き換わる場合もあります。リストは追加、先頭への挿入、全置換のいずれもあり得て、実際の動作はクライアントのオーバーライド機能によって異なります。特にrulesでは、既存のMATCHより後ろに追加したルールは通常マッチしません。編集内容が保存されたことだけでなく、最終的な順序も必ず確認してください。

以下のカーネルフィールドは、選択状態やマッピングの状態を管理するのに使えます。ただし、クライアントがその設定を管理するか、設定を切り替えた後も引き継がれるかは、実際の動作を確認してください。複数のサブスクリプションをマージする指示ではなく、同名ノードを解決するものでもありません。職場と自宅など環境差が大きい場合は、条件を積み重ねるよりProfileを分けるほうが管理しやすいことがあります。

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

異なるソースのノードを同じプロキシグループで使う場合は、proxy-providersを利用できます。ただし、ソースがカーネル対応のプロキシプロバイダー形式を出力する必要があります。完全なClash設定、通常のノードリンク一覧、その他のサブスクリプション形式は、そのままプロバイダーファイルとして使えるとは限りません。内容の構造を確認し、proxiesを主体とする有効なノード一覧であることを確かめてください。

プロキシプロバイダーで複数のソースをまとめる

proxy-providers:
  回線A:
    type: http
    url: https://example.com/provider-a.yaml
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  回線B:
    type: http
    url: https://example.com/provider-b.yaml
    path: ./providers/b.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: まとめて選択
    type: select
    use:
      - 回線A
      - 回線B

rules:
  - MATCH,まとめて選択

例のURLは実際のプロバイダーURLに置き換え、キャッシュパスはそれぞれ別にしてください。サブスクリプションの認証情報を公開スクリーンショット、ブログ、共有リポジトリに載せないでください。実際の設定ファイルも機密情報として扱いましょう。ノードのパスワード、サブスクリプションURL、コントローラーのパスワードが同時に含まれる場合があります。トラブル対処用の情報を共有する際は、構造だけを残し、値は必ずマスキングしてください。

複数のソースを使うと、同じ名前のノードが発生しやすくなります。ノード名は画面表示だけでなく、選択状態の保存やルールからの参照に使われる場合もあり、重複すると判別しにくくなります。現在のカーネルがプロバイダーの名前の上書きに対応している場合は、ドキュメントに従ってソースごとに接頭辞を付けてください。対応していない場合は、管理可能なデータ処理の段階で名前を変えるか、ソースを分けて使います。単純な文字列置換でYAML全体を書き換えると、ルールの振り分け先やグループ名まで壊すおそれがあります。

元に戻せる更新手順を整える

更新前に、直前の有効な設定とローカルオーバーライドを保存してください。更新後は、プロバイダーの読み込み、グループのメンバー、ルールの順序、DNS設定を順に確認します。必要であれば、対応するバイナリのディレクトリでmihomo -t -f ./config.yamlを実行し、カーネルの設定テスト機能で構文を確認します。構文を解析できたことは分かりますが、ノードへの接続やルールの適合性まで保証するものではありません。

再読み込み後は、まず新しい接続を一つ確立し、想定したアウトバウンドを使うことを確認してから、ほかのアプリのタスクを再開してください。失敗した場合は、最近追加したオーバーライドを一段階戻します。すぐにすべてのProfileを削除しないでください。トラブル対処の記録には、元の設定、変更した断片、最終生成結果、エラーログを残します。段階的に戻すほうが、サブスクリプションを何度も再インポートするより原因を特定しやすく、検証済みの個人設定も維持できます。

外部コントローラーパネルと保守手順

プロキシの入口と管理用の入口を区別する

mixed-portなどのプロキシポートは業務通信を受け付け、external-controllerは管理用APIを提供します。コントローラーパネルは管理APIを通じて接続を確認したり、プロキシグループを切り替えたり、動作状態を調整したりします。新しいプロキシノードではありません。LANからの接続を許可するプロキシ設定を開放しても、管理APIまで外部に公開する必要はありません。両者は別々に評価してください。

デスクトップクライアントは通常、カーネルの管理に内部コントローラーを使います。リッスンアドレス、ポート、パスワードを手動で変更すると、クライアントの画面からカーネルに接続できなくなることがあります。クライアントがこれらの設定の変更に対応しているか、起動時に値を再生成するかを確認してください。画面上では切断されているのに通信できる場合は、プロキシカーネルが停止したと判断する前に管理APIを調べましょう。

デフォルトではlocalhostのみで待ち受ける

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

ここに記載するパスワードは説明用の仮の値です。実際に使う場合は、専用の強力なパスワードに置き換えてください。external-uiには、準備済みのパネル静的ファイルがあるディレクトリを指定します。パスを記述してもページが自動生成されるわけではありません。相対パスはカーネルの作業ディレクトリが基準です。クライアントのサンドボックス、サービスの実行ユーザー、ファイル権限によって読み込みに失敗することがあります。設定後はまずlocalhostでAPIに接続できることを確認し、それからパネルのファイルを調べてください。

Webパネルが不要であれば、external-uiを省略し、クライアント本来の管理方法を使ってください。パネルが必要な場合は、現在のカーネルAPIと互換性のある静的リソースを、信頼できる方法で用意します。パネルに項目が表示されないからといって、リッスンアドレスを安易に追加しないでください。パネルの互換性、APIの認証、カーネルの応答内容のどこに問題があるかを確認しましょう。

ブラウザーの接続と認証を確認する

パネルが開けても、静的ページにアクセスできるだけで、管理APIへの接続に成功したとは限りません。APIアドレス、パスワード、イベント接続を個別に確認してください。ブラウザーのコンソールで接続拒否が表示される場合は、ポートや待ち受け設定が原因の可能性があります。認証エラーではパスワードを確認します。パネルが別のオリジンから配信されている場合、オリジン間の制限を受けることもあります。エラーごとに対処する場所は異なります。

HTTPSのページからHTTPの管理APIへリクエストすると、ネットワーク上で両方に到達できても、ブラウザーに混在コンテンツとしてブロックされることがあります。オリジン間アクセスを許可する場合も、任意のWebサイトから認証情報付きでアクセスできる設定にしないでください。まずパネルの配信元を確認し、カーネルが対応する範囲で許可を最小限にします。パスワードを公開リンクのクエリパラメーターに含めないでください。ブラウザーの履歴、スクリーンショット、アクセスログに残るおそれがあります。

リモート管理では、管理対象のローカル転送や信頼できるネットワークを通じてlocalhostのAPIへアクセスしてください。LANで待ち受ける必要がある場合は、ファイアウォールで接続元を制限し、ネットワークが信頼できるか確認します。管理ポートをそのまま公共ネットワークに公開しないでください。管理APIはプロキシグループを切り替えたり、既存接続に影響を与えたりできます。読み取り専用のステータスページより権限が広いため、一般的な表示用ポートと同じ扱いにしてはいけません。

読み取り専用の情報からトラブル対処を始める

初めてパネルに接続したら、まず動作モード、プロキシグループ、接続履歴を確認し、すぐに全体設定を変更しないでください。クライアントの画面とパネルが同じカーネルインスタンスを管理しているか照合します。端末で独立したmihomoとデスクトップクライアントが同時に起動している場合、それぞれ別のポートと設定を使っていることがあります。パネルから切り替えても実際の通信に影響しない場合は、別のインスタンスに接続している可能性があります。

トラブル対処の順序を決めておくと便利です。カーネルが動作していること、APIが待ち受けていること、認証に成功すること、パネルから設定を読み込めること、新しい接続を確認できることの順にチェックします。一度に解決するのは一つの層だけです。業務通信は正常なのにパネルが真っ白な場合は、静的リソースとブラウザーを確認します。パネルは正常でも通信に失敗する場合は、プロキシの入口、ルール、DNS、ノードに戻ってください。管理画面の表示を実際の接続テストの代わりにしないでください。

長期的な保守と復旧のチェックリスト

大きな変更を行うたびに、変更内容を記録してください。どのフィールドを変更したか、どの症状への対応か、どう検証したか、どのように元へ戻すかを残します。メイン設定のバックアップ時には、ローカルルールのディレクトリ、プロバイダーのキャッシュパス、クライアントが管理するオーバーライドも記録してください。移行後は、まず最小限の通信経路を復旧し、その後TUN、DNSポリシー、コントローラーパネルを一つずつ戻します。旧環境のパスや権限の問題まで一緒に引き継がないようにしましょう。

クライアントとカーネルは同時に更新されるとは限りません。見慣れないフィールド、設定テストの失敗、パネル機能の不一致が起きた場合は、実際に実行中のカーネルが対応しているか確認してください。画面の見た目だけで対応状況を判断しないでください。クライアントを選び直す場合は、ダウンロードセンターでプラットフォームを選択できます。最初から接続を復旧する場合は、サブスクリプションの追加と接続ガイドに戻って基本手順を完了し、その後このページの高度な設定を章ごとに戻してください。