MIHOMO / CONFIGURATION REFERENCE

Clash設定の応用ガイド

Clash をダウンロード 導入ガイドを見る

設定の依存関係から通信の取り込み経路まで、章ごとに変更し、接続ログで結果を確認します。

このページは、基本接続の設定を終えた方向けのリファレンスです。初回インストールやサブスクリプションの追加、システムプロキシの設定については、先に使い方ガイドをご覧ください。以下では主にmihomoの設定構造を扱います。クライアント画面に同じ名前の項目があっても、設定の上書きによって最終値が変わる場合があるため、実際の動作設定を確認してください。

モードと基本設定

応用設定を始める前に、接続経路が正常に動作することを確認してください。現在使えているサブスクリプション、手動選択したノード、システムプロキシ設定を維持し、クライアント名、カーネルの種類、混合ポート、使用中のProfileを記録します。サブスクリプションの変更、TUNの有効化、DNSの変更を同時に行うのは避けてください。変更を重ねると、ページが開くかどうかだけでは、どの層が動作を変えたのか判断できません。

設定元と実際の動作を切り分ける

クライアントは通常、サブスクリプションファイル、ローカル設定、上書き設定を組み合わせてカーネルに渡します。サブスクリプションの編集画面に表示されたポートが、カーネルの実際の待ち受けポートと一致するとは限りません。クライアントの実行設定、カーネル設定のプレビュー、起動ログで実際の値を確認してください。ファイルを保存しても動作が変わらない場合は、現在有効なProfileを編集したか、再読み込みが必要かを確認しましょう。同じ項目を繰り返し追加するのは避けてください。

設定内の名前参照も動作上の依存関係です。ルール末尾に指定したポリシー名は、ノードまたはプロキシグループに存在する必要があります。プロキシグループが参照するproviderも、あらかじめ定義してください。YAMLを解析できても、参照先のオブジェクトが存在するとは限りません。インデントにはスペースを使い、タブは避けます。名前にカンマ、コロン、特殊記号が含まれる場合は引用符で囲み、名前を変更した後はすべての参照箇所を確認してください。

ルール・グローバル・DIRECTの使い分け

mode: ruleは、ルールリストを上から順に評価して通信先を決定します。グローバルモードでは、通常、プロキシが必要な接続をグローバルポリシーに渡します。DIRECTモードは、プロキシを経由せずに通信する場合に使います。モードを変えても、ノード、名前解決、ルーティングの問題が自動で解決するわけではなく、すべてのアプリの通信が取り込まれるわけでもありません。システムプロキシを使わないアプリの通信がカーネルに届くかどうかは、アプリの設定、TUN、ゲートウェイ転送によって決まります。

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

この基本設定では、混合プロキシポートを7890に固定し、LANからのアクセスを無効にして、ログレベルはinfoのままにします。混合ポートはHTTPとSOCKSのプロキシ要求を受け付けますが、アプリ側でも正しいプロキシプロトコルを指定する必要があります。ポートが使用中の場合は、別の待ち受けプロセスを停止するか、クライアントとアプリの設定を合わせて変更してください。アプリ側の番号だけを変更すると、接続先に待ち受けポートが存在しなくなります。

モード確認できること判断できないこと
ルールドメイン・IPアドレス・ルールの順序すべてのアプリの通信が取り込まれているか
グローバル現在のプロキシ経路が使えるかルールの内容が正しいか
DIRECTローカルネットワークと直接接続の経路DNSが必ずカーネルを迂回するか

再現可能な検証手順を作る

一度に変更する設定は一つだけにし、同じアプリから新しい接続を発生させて確認します。既存の長時間接続は古いポリシーを使い続けることがあるため、該当する接続を閉じるか、テスト用アプリを再起動してください。まず接続パネルで要求がカーネルに届いているかを確認し、次に適用されたルールと実際の送信先を調べます。接続記録がなければ通信の取り込み設定を、記録はあるもののポリシーが違う場合はルールとプロキシグループを確認してください。

グローバルモードでは使えるのにルールモードで失敗する場合、モードごとに選ばれる送信先が異なるか、ルールモードで対象に適さないDIRECT経路が選ばれている可能性があります。実際の送信先名を比べてから判断してください。特定のサイトにDIRECTで接続できても、サブスクリプション全体が無効とは限りません。対象アドレス、名前解決の結果、サーバーの動作が異なる場合があります。同じ対象で比較した結果を残し、一部の現象を全体の障害と混同しないようにしましょう。

クライアント画面とカーネルの動作を切り分けるには、まず用語解説で設定構造とネットワークの取り込み方を確認してください。クライアントを変更する場合は、ダウンロードセンターからClash Plusを選び、プラットフォームと必要なカーネル機能に応じて他のクライアントと比較しましょう。画面上のスイッチの場所が違っても、確認の順序は同じです。設定の読み込み、要求の取り込み、ルールの適用、送信先への接続を確認してください。

プロキシグループの種類と使い方

プロキシグループを使うと、ルールと個々のノードを分離できます。ルールから「業務用出口」のようなグループを参照しておけば、サブスクリプション更新後にグループ内のノードを入れ替えられます。設計時は、手動で選びたいのか、特定の回線を優先したいのか、応答の速い候補を自動選択したいのか、独立した接続を複数の出口に分散したいのかを明確にしてください。すべてのグループ種類を一つの設定に詰め込むのは避けましょう。階層が増えるほど、問題の切り分けでたどる参照関係が複雑になります。

手動選択と自動選択

selectは出口を手動で固定したい場合に適しており、選択結果を把握しやすいタイプです。url-testは測定結果をもとに候補を自動選択します。fallbackはリスト順に利用可能な候補を選ぶため、主系・待機系の構成に向いています。load-balanceは複数の接続をポリシーに沿って振り分けるもので、単一のダウンロード接続の帯域を合算する機能ではありません。ログイン、決済、セッションなど、出口の安定性が必要な用途では、頻繁な自動切り替えを避けるのが一般的です。

以下の例では、現在の設定に「回線A」と「回線B」という2つのノードが定義されているものとします。実際に使用する際は、サブスクリプションにある正確な名前に置き換えてください。最上位の手動選択グループから自動選択グループもノードも選べます。ルールからは最上位グループだけを参照すれば、候補リストを後で変更してもルールを一つずつ直す必要がありません。

proxy-groups:
  - name: 自動出口
    type: url-test
    proxies:
      - 回線A
      - 回線B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 業務用出口
    type: select
    proxies:
      - 自動出口
      - 回線A
      - 回線B

rules:
  - DOMAIN-SUFFIX,example.com,業務用出口
  - MATCH,業務用出口

測定パラメーターの意味を理解する

intervalは測定間隔で、単位は秒です。toleranceは切り替えの許容差を示し、候補間の小さな変動で頻繁に切り替わるのを防ぎます。測定用URLは候補の回線から安定して接続できるものを指定してください。測定値が示すのは、その回線から指定したテストサービスへ要求したときの結果です。すべてのサイトでの速度、動画の実効速度、パケット損失、対象サービスの利用可否を示すものではありません。

複数のグループで同じ候補を共有し、測定間隔を短くすると、ヘルスチェックによるバックグラウンド通信が増えます。まずは余裕のある間隔を設定し、回線の変化頻度に応じて調整してください。遅延測定の遅延実行機能を有効にすると、未使用のグループでは新しい測定結果がすぐに得られない場合があります。パネルに表示された古い値は、最終測定時刻と合わせて判断してください。常時更新されるリアルタイム監視の値ではありません。

グループのネスト・サブスクリプション参照・用途別の設計

ノードをproxy-providersで提供している場合、グループはノード名をすべてコピーせず、useでproviderを参照できます。サブスクリプションのノードが追加・削除されても、読み込み結果に応じて候補を更新できます。名前による絞り込みは候補を減らすのに便利ですが、地域ラベルは多くの場合プロバイダー独自の命名で、実際の出口の所在地を示すとは限りません。絞り込み条件の誤りでグループが空になることもあるため、展開後の候補一覧を確認してください。

安定した構成としては、手動選択の出口グループを一つ置き、その下に用途別のグループを少数作る方法が一般的です。業務ルールから用途別グループを参照し、そのグループから自動選択グループまたは固定ノードを参照します。グループAからB、BからAのように相互参照しないでください。循環依存があると設定の読み込みに失敗します。自動選択グループの候補にも、自分自身へ戻る選択経路を含めないでください。画面に名前が表示されても、最終的な送信先を解決できない場合があります。

自動選択グループが頻繁に切り替わる場合は、候補の安定性とテストサービスの制限を確認してから、許容差を大きくするか主系・待機系の構成に変更してください。特定のサービスだけで問題が起きる場合は、同じノードに固定して再テストし、テスト中に出口が変わらないようにします。グループの選択が変わっても、既存の接続は以前の送信先を使い続けることがあります。グループのボタン表示だけで判断せず、新しい接続を確認してください。

ノードの品質は、通信量の倍率、地域、プロトコルにも左右されるため、測定値一つだけで順位を決めないでください。ノード選びと遅延の見方を参考に、候補を絞り込むこともできます。応用設定の目的は、すべての通信を一つの自動経路にまとめることではありません。各ルールでその選択をする理由が明確で、障害時には手動で切り替えられる出口を用意することが大切です。

ルールセットを使ったルール管理

ルールリストは評価順を決め、ルールセットは複数の条件をまとめて管理します。頻繁に更新されるドメインやアドレスをrule-providersに分けると、メイン設定を簡潔に保てます。ただし、ルールセットは独立した優先順位で評価されるわけではありません。カーネルは引き続きrulesを上から順に確認し、最初に一致したルールで送信先を決定します。範囲の広すぎるセットを先頭に置くと、後続の詳細なルールに一致しなくなることがあります。

先にルールの種類を決め、次にファイル形式を選ぶ

behavior: domainはドメインの集合、ipcidrはIPアドレスのネットワーク範囲、classicalは複数種類の完全なルール条件に使います。ルールの種類とファイル形式は別の設定です。formatはファイルの形式を示し、ルールの種類は内容の解釈方法を指定します。拡張子がどちらもYAMLだからといって、ドメインだけを受け付けるセットにDOMAIN-SUFFIX形式の完全なルールを入れることはできません。

まず構造を確認できるよう、ローカルのclassicalルールセットを使います。2つ目のブロックをカーネルの作業ディレクトリにあるrules/work.yamlとして保存し、1つ目のブロックを現在の設定に追加してください。この例では「業務用出口」プロキシグループが定義済みです。ファイル型providerを変更した場合は、通常、再読み込みが必要です。クライアントがファイルを別の作業ディレクトリにコピーしている場合は、実際に読み込まれる場所を確認してください。

rule-providers:
  work:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work.yaml

rules:
  - RULE-SET,work,業務用出口
  - GEOIP,CN,DIRECT
  - MATCH,業務用出口
payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

例外・通常のルール・フォールバックの順序

他の条件より優先すべき例外を少数だけ先頭に置き、その後に用途別のドメインセット、必要なIPアドレスルールを並べ、最後にMATCHを置く方法がおすすめです。ここでのGEOIP,CN,DIRECTはよくある構成例であり、すべての通信を地域に応じてDIRECTにすべきという意味ではありません。IPアドレスの位置情報、地域をまたぐサービス、共有インフラなどを考慮し、実際の用途に合わせて調整してください。

ドメインルールは、通常、一致判定のためだけにすぐIPアドレスへ解決する必要はありません。一方、IPアドレスルールでは名前解決が発生する場合があります。このパラメーターに対応するIPアドレスルールにno-resolveを付けると、一致判定のための能動的な名前解決を避けられます。ただし、ドメインだけで対象アドレスがない要求は、そのルールに一致しなくなる可能性があります。これは万能な高速化設定ではなく、ルールの一致精度と名前解決の動作を選択するための設定です。

ルールの種類対象となる内容主な確認項目
domainドメインとその一致形式ドメインセットの構文に合っているか
ipcidrIPv4・IPv6のネットワーク範囲ネットマスクとアドレスファミリーが正しいか
classical完全なルール条件送信先ポリシー名が誤って含まれていないか

リモート更新を設定の依存関係として考える

HTTP形式に切り替える場合は、実際にアクセスできるルールのURL、キャッシュパス、更新間隔を設定してください。更新間隔の単位は秒です。クライアントのサブスクリプション画面で使われる分や時間の値を流用しないでください。キャッシュパスは一意にし、複数のproviderで同じファイルを共有しないようにします。初回起動時にキャッシュがない場合、ルールをダウンロードする通信経路がすでに使える必要があります。そうでないと、設定の依存関係が整う前に、その設定自身の完了を待つ循環が発生します。

リモート更新の失敗とルールの不一致は、分けて調べてください。まずproviderが読み込まれているか、項目が存在するかを確認し、その後に要求がセットに一致するかを調べます。キャッシュがあれば動作を継続できる場合もありますが、更新に成功した証拠にはなりません。逆にダウンロードに成功しても、内容が指定したルールの種類に合っているとは限りません。ログに出る解析エラー、空のセット、ダウンロードエラーをそれぞれ確認し、すべてノードの不具合として扱わないでください。

ルールセットを管理する際は、取得元、用途、ロールバック用ファイルを記録し、最後に読み込みに成功した内容を残してください。セットを追加したら、一致するはずのドメインと一致しないはずのドメインを使って、両方向からテストします。その後、他の通信への影響も確認してください。結果が想定と異なる場合は、関連ルールを一時的に前方へ移動して優先順位の影響を確かめます。原因を確認したら意図した順序に戻し、例外を際限なく追加し続けないようにしてください。

DNSの名前解決経路を最適化する

DNS設定では、まず通信経路を設計し、その後にサーバーを選びます。アプリがどこに問い合わせるか、カーネルがどこに問い合わせるか、プロキシサーバー自身のドメインをカーネルがどう解決するかを分けて考えてください。ブラウザーが独自の暗号化DNSを使っていることも、OSが古い結果をキャッシュしていることも、ルーターが問い合わせを中継していることもあります。nameserverを変更しただけでは、すべてのアプリの問い合わせがカーネルを経由するとは限りません。また、プロキシノードのドメインが同じ経路で解決される保証もありません。

起動時の名前解決と通常のDNS問い合わせを区別する

default-nameserverは主にDNS上流サーバー自身のドメインを解決するための起点として使います。現在のネットワークから直接アクセスできるアドレスを指定してください。nameserverは通常の通信に伴う問い合わせを処理し、proxy-server-nameserverはプロキシノードのドメイン解決に使います。これらの用途を混同すると、「プロキシのアドレスを解決するために、先にプロキシへ接続しなければならない」という依存関係の循環が起き、起動後も送信先への接続を確立できないことがあります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  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
  fake-ip-filter:
    - "*.lan"
    - "*.local"

この例は、現在のネットワークから記載したDNSサービスにアクセスできることを前提としています。システムのDNS設定を自動的にポート1053へ変更するものではなく、TUNによる横取りも有効にしません。一般的なOSのDNS設定ではカスタムポートを指定できないため、待ち受けの確認と通信の取り込みは別々に行います。ポートを指定できる問い合わせツールでカーネルをテストし、システムからの要求が実際に転送されているかも確認してください。

ドメインごとにDNSの上流サーバーを選ぶ

nameserver-policyを使うと、特定のドメインで指定した上流サーバーを利用できます。社内ドメイン、専用のDNS環境、実際に差のある業務に適しています。これは名前解決に使うリゾルバーを選ぶ設定であり、最終的な接続先を直接決めるものではありません。「このドメインのDNSを指定すること」と「このドメインが必ずプロキシ経由になること」は別です。接続には引き続きルールが適用され、必要に応じてDNS要求自体のルーティング設定も影響します。

respect-rulesを使ってDNS要求にもルールを適用する場合は、プロキシサーバーのドメイン解決と起動時の経路を特に確認してください。DNS要求までルールに流すと、誤ったフォールバック先の設定により、まだ確立していないプロキシへの接続に名前解決が依存する可能性があります。まず直接処理できる必要のある問い合わせを明確にしてから、ポリシーを追加してください。暗号化DNSのアドレスが設定されているだけでは、通信経路が想定どおりとは判断できません。

キャッシュ・IPv6・結果の比較

DNSを変更した後は、アプリ、OS、カーネルそれぞれのキャッシュを考慮してください。Webページを再読み込みしただけでは既存の接続が再利用される場合があり、新しい名前解決の証拠にはなりません。対象の接続を閉じ、必要な層のキャッシュを消去してから、問い合わせと接続のログを確認します。最初からすべての状態を消去するのではなく、変更前の結果を残しておきましょう。返されたアドレス、応答の種類、実際の送信先を比較すると、問題がどの層で起きているか判断しやすくなります。

トップレベルのipv6とDNS設定内のipv6は、作用する範囲が異なります。前者はカーネルでのIPv6利用に、後者はDNS応答に含めるIPv6アドレスに関係します。ネットワークに利用可能なIPv6経路がないのに、アプリへ優先利用されるIPv6アドレスを返すと、接続待ちの後にIPv4へ切り替わることがあります。反対に、IPv6を無効にすることがすべてのネットワークで正解とも限りません。まず端末のルーティングとサービス要件を確認してください。

名前解決は正常なのに接続できない場合、DNSを手当たり次第に変更し続けないでください。選択した送信先から対象アドレスへ接続できるか、ルールが誤判定していないか、証明書とシステム時刻が正常かを確認します。名前解決に失敗してもノードには接続できる場合は、問い合わせ経路と上流サーバーへの到達性を重点的に調べます。「アドレスを解決できること」と「アプリの要求が完了すること」を別々の確認項目にすると、DNS設定を何度も試す範囲を大幅に絞れます。

TUNとFake-IPを組み合わせて使う

TUNは通信をカーネルへ取り込む方式で、Fake-IPはDNSでドメインとの対応関係を保持する方式です。併用されることは多いものの、同じ機能ではありません。TUNは仮想ネットワークインターフェースを作成し、ルーティングと連携してパケットを取り込みます。Fake-IPはアプリに予約済みアドレスを返し、カーネルがそのアドレスを元のドメインに対応付けます。Fake-IPを有効にするだけではアプリの通信は自動で取り込まれません。TUNだけを有効にしても、各接続のドメインをカーネルが把握できるとは限りません。

まず最小限の通信範囲で取り込む

デスクトップクライアントでTUNを有効にするには、サービスモード、管理者権限、OSのネットワーク拡張機能への許可が必要な場合があります。具体的な仕組みはプラットフォームによって異なります。まず既存のDNSとルール設定を維持したまま、クライアントがインターフェースを正常に作成したことを確認し、その後に自動ルートを有効にしてください。他のVPN、仮想マシンのネットワーク、セキュリティソフトもルートやフィルターを追加する場合があります。同時に使う場合はデフォルトルートの変化を記録し、競合を設定構文の問題と混同しないようにしましょう。

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

この例では通常のUDPとTCPのDNSポートを横取りしますが、すべての暗号化DNSを透過的に取り込むわけではありません。ブラウザー独自のHTTPS DNS要求は通常のHTTPS接続に見えるため、ポートの横取りだけで問い合わせ内容を復元することはできません。検証時は、まずテスト用アプリでシステムの名前解決経路を使い、ドメインが正しく対応付けられることを確認してください。その後、アプリ独自の暗号化DNS設定を残すか検討します。

ネットワークスタックとインターフェースの方針を選ぶ

system、gvisor、mixedは異なるネットワークスタックの処理方式を示します。対応状況はプラットフォームやカーネルのビルドによって異なるため、特定の方式が常に最適とは限りません。特定のプロトコルで互換性の問題が起きた場合は、他の設定を変えずに一つずつ比較し、その項目が未対応だとログに明記されているか確認してください。設定を保存できても、カーネルがその値を実際に使っているとは限りません。

出口インターフェースの自動検出は、単一の出口を使う一般的な端末に適しています。一方、複数のネットワークアダプター、テザリング、コンテナ、ルーター環境では、インターフェースとルートを明示的に設計する必要がある場合があります。OSの更新、再接続、機器の変更でインターフェース名が変わることもあります。通信が仮想インターフェースへ戻り続ける、接続数が異常に増える、ネットワーク全体が切断される場合は、接続先への再試行を続けず、まずTUNを無効にしてネットワークを復旧し、ルーティングのループを確認してください。

Fake-IPの対応付けと例外を管理する

アプリがFake-IPを受け取った後の接続は、その対応情報を保存した同じカーネルを通る必要があります。端末AがDNS応答を返し、端末Bが接続を処理すると、Bはその予約アドレスに対応するドメインを知らない可能性があります。LAN内でプロキシを共有する場合は、DNSと接続をどの端末が処理するのか明確にしてください。Fake-IPの結果を、そのプロキシを経由しない端末や別のネットワーク経路にそのまま渡さないでください。

fake-ip-filterは指定ドメインへのFake-IP割り当てを避ける設定ですが、フィルター後も実際のアドレスを解決できるDNS上流が必要です。実アドレスを必要とするアプリでは、問題のある具体的なドメインから例外に追加し、広範なパブリックドメイン全体をまとめて除外しないでください。フィルター範囲が広すぎると、カーネルが対応情報からドメインを取得する機会が減り、一部の判定をIPルールやスニッフィングに任せることになります。

アプリに古いFake-IPがキャッシュされた状態でカーネルを再起動し、対応情報が失われると、新しい接続でドメインを復元できないことがあります。保存の仕組みを理解したうえでprofile.store-fake-ipを使い、クライアントが対応するデータディレクトリを保持しているか確認してください。問題の調査では、フィルターを広げるよりアプリのキャッシュを消して再解決するほうが有効な場合があります。このカーネルを使わないネットワークに切り替えた後も、予約アドレスを使い続けないようにしてください。

一般的なWebページ、システムプロキシに従わないアプリ、LAN内サービスへのアクセスを使って動作を確認してください。それぞれについて、カーネルに通信が届くか、ドメインが表示されるか、想定したルールに一致するかを調べます。システムプロキシでは正常でTUNだけが異常なら、ルーティング、権限、DNSの横取り、ネットワークスタックに原因を絞れます。両方式の詳しい違いはTUNモードとシステムプロキシの仕組みの違いをご覧ください。通信範囲を広げるために、すべての取り込み機能を同時に有効にする必要はありません。

ドメインスニッフィングと適用範囲

接続先のIPアドレスしか分からず、信頼できるドメイン情報がない場合、ドメインルールを想定どおりに適用できないことがあります。ドメインスニッフィングは、一部のプロトコルのハンドシェイクや要求からホスト名を取得し、ルール判定に手がかりを加える機能です。HTTPSの内容を復号するものではなく、すべての接続を識別できるわけでもありません。まず通常のDNS通信の取り込みとFake-IPの対応付けを整えてから、境界的なケースを補うためにスニッフィングを検討すると、全面的に依存するより管理しやすくなります。

プロトコルとポートで対象範囲を絞る

HTTPでは要求のホスト情報からドメインを取得できます。TLSでは通常、見えるハンドシェイク情報からサーバー名を取得できます。QUICの識別はカーネルの対応状況と実際の通信内容に依存します。独自プロトコルを使うアプリ、IPアドレスへの直接接続、既存接続の再利用、関連するハンドシェイク情報が隠されている場合は、ドメインを取得できないことがあります。結果が空でもカーネルの障害とは限りません。まず通信に識別可能な情報が含まれているか確認してください。

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

この設定例では、対象を一般的な通信ポートに絞り、元の接続先アドレスを維持します。parse-pure-ipを有効にすると、IPアドレスだけの接続も識別を試みます。force-dns-mappingはDNSの対応情報がある場合のスニッフィング動作に関係します。名前が似ていても、通常のDNS処理の代わりにはなりません。カーネルが項目に対応していないと報告した場合は、クライアント名だけで判断せず、実際のカーネルを確認してください。

ドメイン情報の補完と接続先の上書きを区別する

override-destinationは、スニッフィングした結果で接続先を変更するかを決めます。ドメインに基づいて接続し直す必要があるケースでは役立つことがありますが、アプリが選んだアドレスを変えて問題を起こす可能性もあります。専用IP、社内サービス、CDNによる振り分け、証明書との対応が重要な通信では、まず無効のままにしてください。ドメイン情報の補完とルールの結果だけを確認し、接続先の上書きが必要か判断します。

同じIPアドレスが複数のドメインをホストする場合も、同じドメインが複数のアドレスを返す場合もあります。スニッフィングでドメインを取得してから再度名前解決すると、アプリが最初に使ったアドレスと異なる結果になることがあります。そのため、「正しいドメインを識別できたこと」と「正しいサービスに接続できたこと」は別々に確認してください。上書きを有効にした後、特定のアプリだけ失敗する場合は、上書きを無効にして比較し、該当ドメインにスキップ設定を追加することを検討します。

例外とプライバシーの範囲を考慮する

スニッフィングに適さないドメインには、カーネルの対応状況に応じてskip-domainなどの除外設定を使えます。互換性の問題が明確なものだけを追加し、理由も記録してください。出所が分からない大規模な除外リストをそのまま使うのはおすすめしません。対象範囲が広すぎるとスニッフィングがほとんど機能しなくなりますが、調査時には機能が全面的に有効だと思い込み、最後にはルールへパッチを追加し続けることになりかねません。

スニッフィングでは、暗号化されたクライアントHelloなどの仕組みを常に検出できるとは限らず、アプリのログを置き換えることもできません。取得したドメインは接続先のホスト名であり、ユーザーが閲覧しているページのタイトルやサービス全体を示すとは限りません。共有インフラ上のサービスでは特に注意が必要です。一度取得したドメインだけを根拠にインフラ全体を同じ送信先へ割り当てず、安定して確認できるホスト名に基づいてルールを設計してください。

デバッグでは対象を一つに固定し、既存の接続を閉じてから再度要求を送ります。スニッフィングを無効にした場合と有効にした場合で、対象ドメイン、ルール名、送信先を比較してください。スニッフィング前に明示的なIPルールへ一致している場合は、ルールの順序とカーネルの処理も確認します。一度のテストでポート範囲、接続先の上書き、振り分けルールセットを同時に変更すると、差が生じた原因を特定できません。

ログにはアクセスしたドメイン、接続先アドレス、アプリの情報が含まれる場合があります。調査のためにログレベルを一時的に上げる場合は、原因の特定に必要な時間だけ記録してください。共有前にサブスクリプションURL、認証情報、個人のアクセス履歴を取り除きます。問題が解消したら通常のログレベルに戻し、必要最小限の設定を維持してください。スニッフィングは動作を説明できる補助機能として使い、DNS、通信の取り込み、ルール参照の構造上の問題を覆い隠すために使わないでください。

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

サブスクリプションを更新すると、通常、リモートProfileの内容は置き換えられます。ダウンロードしたファイルを直接編集すると、次回の更新で変更が失われる可能性があります。ローカルの上書き設定は、待ち受けポート、DNSポリシー、少数の業務ルール、制御インターフェースなど、端末やユーザー固有の設定を長期的に保持するために使います。設定画面では「上書き」「マージ」「拡張」「スクリプト」などの名称が使われることがありますが、同じ結合方法とは限りません。項目の置き換え、オブジェクトの深いマージ、配列の連結のどれに当たるか、先に確認してください。

設定を3つの管理主体に分ける

リモートサブスクリプションではノードと関連設定、ローカルの端末設定では権限・待ち受け・通信の取り込み方、ユーザーポリシーでは通信の振り分けと長期的な例外を管理します。同じ項目を複数の層で設定しないようにしてください。たとえば画面でポートを固定し、上書き設定で別のポートを指定し、サブスクリプションにもさらに別の値があると、最終結果は暗黙の読み込み順に依存します。クライアントを移行した際に動作が変わりやすくなります。

まずlog-levelのように確認しやすく影響の小さい項目で、設定のマージ動作を試します。読み込み後に最終設定を確認し、それからルール配列の処理をテストしてください。新しいルールでrules全体が置き換わる場合、その機能は想定していた追加方式ではありません。すべてのYAMLマージで既存配列が保持されると決めつけず、クライアントが用意する前置・後置機能やルール編集機能を使ってください。

# マージ用の設定例：使用前にオブジェクトと配列の処理方法を確認
log-level: info

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

ファイル全体を直接つなげず、ノードをマージする

完全なサブスクリプションには、どちらもポート、DNS、プロキシグループ、フォールバックルールが含まれている場合があります。テキストをそのまま連結すると、キーの重複や相互の上書きが発生します。より安定した方法は、ルールとグループ構造をメイン設定で管理し、複数のproxy-providersからノードを読み込むことです。ただし、各ソースがカーネルで利用できるノードprovider形式を提供している必要があります。完全なクライアント設定は、ファイル名を変えるだけではノード一覧として使えません。

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 複数ソースの出口
    type: select
    use:
      - source-a
      - source-b

2つのローカルファイルには、それぞれproxiesのノード一覧と、有効なプロトコル項目を記述します。この例は参照関係を示すもので、ノードの認証情報は含みません。異なるソースに同じ名前のノードがあると区別しにくくなるため、ノード名は見分けやすいものにしてください。名前の変更やソース名の追加を行う場合は、クライアントまたは変換処理が正式に対応していることを確認します。更新後に生成されたファイルを手作業で置き換える方法は避けてください。

更新間隔・変換・失敗時の復旧

クライアントのProfile更新とカーネルproviderの更新は別の処理で、間隔の単位も異なる場合があります。前者はメイン設定を再取得し、後者は特定のノードやルールの取得元を更新します。それぞれの処理を誰が開始するのか、キャッシュの保存先、更新失敗時に古いファイルを使い続けるかを記録してください。端末のスリープ、モバイル回線の制限、バックグラウンド処理の仕様によって更新が遅れることもあるため、設定した間隔だけで実行時刻を判断できません。

サブスクリプションURLにはアクセス用の認証情報が含まれることがあります。完全なURLを公開画像、ログ、サンプル用リポジトリに記載しないでください。形式を変換する場合は、元のURLが第三者サービスに送信されないか確認します。信頼できるクライアントの機能またはローカルでの処理を優先し、変換後にノードのオプションが失われていないか確認してください。設定を読み込めることは最初の確認にすぎません。プロトコル項目が簡略化されると、実際の接続が変わる場合があります。

設定をマージする前に、現在動作しているメイン設定、新しい上書き設定、復旧手順の3つを用意します。適用後は、まずノード数が想定どおりかを確認し、次にプロキシグループが空でないこと、ルールの参照先が存在すること、DNSとポートが計画どおりであることを確認します。更新後に異常が起きたら、追加した上書きを無効にして基本設定へ戻してください。復旧できた場合は、クライアントを再インストールして調査の手がかりを失うのではなく、設定を一つずつ有効にします。

複数Profileの切り替えやマージに対応する範囲は、クライアントごとに異なります。設定を切り替えても、複数のProfileのノードを同時に使えるとは限りません。まず管理の仕組みを確認し、詳しくはProfileの構成と複数サブスクリプションの管理をご覧ください。長期的な管理では、複雑で説明のないマージスクリプトに頼るより、ルールの意図と取得元の関係を短く記録するほうが、移行しやすく更新後の確認も簡単です。

外部制御とメンテナンス手順

外部制御インターフェースでは、カーネルの状態確認、ポリシーの切り替え、接続の表示、一部の管理操作を行えます。アプリがインターネットに接続するためのプロキシポートではありません。よく使われる設定では、制御ポートが9090、混合プロキシポートが7890です。ブラウザーやシステムプロキシの接続先に制御ポートを指定しても、通常のプロキシとしては動作しません。設定する前に、2つのポートの用途、待ち受けアドレス、接続を許可する端末をそれぞれ整理してください。

まずはローカルホストだけで待ち受ける

単一端末のクライアントでは、通常、LANから制御インターフェースへ直接アクセスできるようにする必要はありません。ループバックアドレスで待ち受ければ、アクセス範囲を絞れます。クライアントが制御インターフェースと認証情報を管理している場合、上書き設定で無理に変更しないでください。内蔵パネルから接続できなくなる可能性があります。以下では説明用の認証値を使い、項目の位置だけを示します。実際の環境では推測されにくい値を個別に生成し、安全に保管してください。

external-controller: 127.0.0.1:9090
secret: "your-password"

制御インターフェースの認証機能だけでは、ネットワーク上のアクセス制限を代替できません。リモート管理が本当に必要な場合は、待ち受けアドレスを変更する前に、信頼できるネットワーク、暗号化通信、ファイアウォールの制限を設計してください。利便性のためにすべてのアドレスで待ち受けたり、インターネットからアクセスできるようポート転送したりしないでください。このインターフェースを操作できる相手は送信先ポリシーを変更したり、接続情報を読み取ったりできる可能性があります。権限はシステム管理用のインターフェースと同等に扱ってください。

APIで接続の問題とパネルの問題を切り分ける

まずカーネルを実行している端末でインターフェースを確認し、その後にブラウザーパネルを調べます。以下のコマンドで使う認証値は、前の説明用設定に対応しています。実際の環境では同じ値に置き換えてください。認証失敗、接続拒否、期待と異なる応答内容は、それぞれ異なる問題です。認証設定、待ち受けまたはプロセスの状態、ポートまたはサービスの選択に分けて確認してください。パネルを再ダウンロードすればすべて解決すると考えないでください。

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/version

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/proxies

Windows PowerShellでは、curlがコマンドのエイリアスやバージョンによって異なる動作をすることがあります。curl.exeを明示的に使い、利用するターミナルに応じて改行方法を調整してください。インターフェースからデータを取得できたら、パネルに入力したアドレス、プロトコル、認証情報を確認します。HTTPSで開いたパネルから通常のHTTPインターフェースへ接続する場合は、ブラウザーの混在コンテンツ制限が影響することもあります。

静的パネルと接続履歴の注意点

external-uiはローカルの静的パネルファイルを置くディレクトリを指定します。パスはカーネルの作業ディレクトリを基準に解決されます。静的ファイルが存在していても、正しいカーネルに接続されているとは限りません。パネルを開いた後、制御先アドレスと認証情報を確認してください。内蔵パネルでは通常、この接続設定が済んでいます。一般的なデスクトップユーザーはクライアントのメニューから開き、出所の異なる管理ページを複数維持するのは避けましょう。

パネルの接続一覧は通常、現在の接続状況を確認するためのもので、永続的な監査記録ではありません。カーネルの再起動、接続の終了、設定の切り替えによって、表示内容は変わることがあります。調査に必要なログは残しつつ、接続の詳細を長期間公開しないでください。問題を共有するときは、対象の種類、適用されたルール、エラーの種類を説明すれば十分です。サブスクリプションURL、認証情報、アクセス履歴全体は事前に削除してください。

更新後の動作確認リストを作る

クライアントの更新、サブスクリプションの切り替え、上書き設定の変更後は、毎回同じ順序で確認します。カーネルの起動、実際の待ち受けポート、providerの読み込み、ルールの一致、DNSとTUNの順に確認し、最後に外部パネルを調べてください。パネルが一時的に使えなくても、ログと基本接続からプロキシ経路が正常か確認できます。管理画面の問題をネットワーク全体の障害と誤解せずに済みます。

ロールバックでは、最後に編集したファイルだけでなく、直前に動作確認した設定の組み合わせを復元してください。サブスクリプションのキャッシュ、上書き設定、ポリシーの選択、クライアントのスイッチがそろって最終的な動作を決めます。復旧手順には、無効にする上書き設定、選ぶProfile、TUNを無効にするかどうか、キャッシュを削除するタイミングを記録してください。復旧後は新しい接続を開始し、古いセッションに結果が隠されていないことを確認します。

各章は個別に参照できますが、変更は依存関係に沿って進めてください。まず入口とノードを安定させ、次にプロキシグループとルールを整え、その後にDNS、TUN、スニッフィング、最後にリモート管理を設定します。基本接続で問題がある場合は、システムプロキシの設定を確認してください。クライアントを移行する場合は、ダウンロードセンターに戻ってください。設定項目を増やし続けるより、確認できる結果と実行可能なロールバック手順を毎回残すことが、長期的な運用に役立ちます。