ADVANCED CONFIGURATION

Clash 高度な設定ガイド

プロキシグループ、ルールセット、DNSから始め、TUN、Fake-IP、ドメインスニッフィング、ローカル上書き、外部コントロールまで確認します。各章では設定レイヤーを示したうえで、変更方法と検証手順を説明します。

詳しく読む まずはじめにを見る
proxy-groups rule-providers dns tun sniffer

READING GUIDE

まず変更するレイヤーを特定する

このページは体系的な確認用であり、初回インストールの手順に代わるものではありません。購読のインポート、システムプロキシの有効化、基本的な接続確認がまだの場合は、まず使用ガイドに沿って基本操作を完了してください。基本接続が正常で、振り分け方法、DNSの動作、透過プロキシを調整したい場合に、このページの該当章へ戻ってきてください。

設定の切り分けでは、変更する変数を一つに保ちます。現在使える設定を保存し、一つのフィールドだけ変更して、再読み込み後に接続ログとルールのヒット状況を確認してください。購読、DNS、ルールセット、プロキシグループを同時に置き換えると、障害のレイヤーが混在し、最後には設定全体を戻すしかなくなります。

CHAPTER 01

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

プロキシグループはルールとプロキシノードの間に位置します。ルールの最後の引数は通常、個別のノードではなくプロキシグループ名です。プロキシグループが、どのノード、自動テストグループ、または直接接続の出口を使うかを決めます。「ルールにはヒットしているのに出口が違う」場合は、まずログのルール名を確認し、対応するプロキシグループを開いて現在の選択を確認してください。ルールを変更しても手動選択グループの状態は変わらず、ノードを切り替えてもルールは書き換わりません。この二つは分けて検証する必要があります。

select、url-test、fallback、load-balanceの違い

selectは手動選択グループで、「プロキシ選択」「ストリーミング」「ダウンロード」など、人が出口を固定したい場面に適しています。個別のノードだけでなく、別のプロキシグループも含められます。自動速度テストグループを手動グループに入れ、普段は自動グループを選び、地域を固定したいときだけ特定の地域グループへ切り替えると、構成が分かりやすく、戻しやすくなります。数十個のノードを各サービス用ポリシーへ直接並べないでください。購読元でノード名が変わると、複数箇所の参照が一度に壊れます。

url-testは定期的にテスト用URLへアクセスし、候補ノードから結果のよいものを選びます。測定対象URLでの接続性能であり、すべてのWebサイトや大容量ファイル転送の結果を示すものではありません。intervalはテスト間隔を制御し、短すぎるとバックグラウンド通信が増えます。toleranceは小さな変動による頻繁な切り替えを抑えます。現在のノードが利用可能で、最良結果との差が許容範囲内なら、現在のノードを使い続けるほうが安定することが多いでしょう。

fallbackは利用可能性と候補順を重視します。リスト上位のノードが復旧すると、グループは上位の項目へ戻る傾向があり、主回線と予備回線が明確な構成に適しています。load-balanceは複数ノードに接続を分散し、出口の変化を許容できる並列通信に向いています。ログイン状態、地域の一貫性、リスク管理が重要なサイトでは、同じサービスの接続ごとに出口が変わる可能性があるため、負荷分散を安易に使わないでください。

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
    lazy: true

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

フィルター条件で候補ノードを制御する

購読ノードが多い場合は、ノード名を手作業でコピーせず、自動グループや地域グループ内でフィルター条件を使います。対応するフィールドを備えたカーネルでは、include-allでノードを取り込み、filterで名前を照合し、exclude-filterで倍率、テスト用、または除外したい項目を外せます。フィルター式はノード名を対象とするため、購読元の改名後に候補が空になることがあります。購読を更新するたびにプロキシグループを開き、利用可能なメンバーが少なくとも一つあることを確認してください。

プロキシグループは別のグループを参照できますが、循環参照は避けてください。たとえば「プロキシ選択」が「自動選択」を含む構成は正常です。しかし「自動選択」が候補として「プロキシ選択」を参照すると、カーネルは出口を確定できません。グループ名はルール末尾と完全に一致させる必要があり、空白、大文字・小文字、全角文字の違いも別名として扱われます。設定の読み込みに失敗したら、まず同名グループの重複を検索し、次にルールが参照するグループが実際に存在するか確認してください。

種類 選択方式 適した用途 主なリスク
select ユーザーが手動で指定 地域の固定、ストリーミング、ダウンロード 選択中のノードが無効になっても自動で切り替わらない
url-test テスト結果に基づく自動選択 日常のWeb閲覧と一般的なプロキシ利用 テスト先の結果はすべてのサービスの結果と同じではない
fallback 利用可能な項目を順番に使用 メインノードと予備ノード 候補順の設定を誤ると意図しない出口が選ばれる
load-balance 複数ノードへ接続を分散 複数の出口を許容できる並列接続 ログインセッションと地域判定が一致しない可能性がある

CHAPTER 02

ルールセットの購読管理

ルールが増えたら、すべての項目をメイン設定に詰め込むと三つの問題が起きます。購読更新でローカルの変更が上書きされやすく、ルールの出所を個別に更新できず、どのルール群がヒットしたのかも判断しにくくなります。rule-providersでルール内容を独立した集合に分け、メイン設定には提供元、保存先、更新間隔、参照順だけを残します。広告、ローカルネットワーク、直接接続する地域、プロキシサービスのルールを個別に管理できますが、最終的な照合順はメイン設定のrulesで決まります。

behaviorが決めるルールファイルの形式

domainタイプはドメインだけの集合に使い、ルールファイルのpayloadには通常、ドメイン、サフィックス、ワイルドカード式を記述します。ipcidrはIPネットワーク向け、classicalはDOMAIN-SUFFIX、PROCESS-NAME、IP-CIDRなど、タイプ付きの完全なルールを格納できます。選択を誤ると、ファイルのダウンロードに成功しても解析できない場合があります。まずルールソースの内容を確認し、ファイル名だけでbehaviorを推測しないでください。

type: httpはリモート更新、urlはソースアドレス、pathはローカルキャッシュの保存先、intervalは更新間隔を示します。providerごとに異なるパスを使わないと、後からダウンロードしたファイルが先のファイルを上書きします。リモート更新に失敗しても、カーネルは通常、既存のキャッシュを使い続けます。ただし初回起動時にキャッシュがなく、リモートアドレスへ到達できない場合、そのルールセットは読み込めません。重要なローカルネットワークルールは、起動時の保険として少数のインライン項目を残しておくと安心です。

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

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

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-proxy,プロキシ選択
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ選択

サンプルのアドレスはフィールド構成を示すためのものです。実際に運用する際は、管理しているルールソースへ置き換えてください。YAML形式のルールファイルでは、domain providerを次のように記述できます。

payload:
  - localhost
  - "*.lan"
  - "+.example.internal"

ルール数より並び順が重要

Clashのルールは上から順に確認され、最初にヒットした時点で停止します。具体的なサービス用ルールは広範囲の地域ルールより前に、ローカルネットワークと予約アドレスはデフォルトのプロキシより前に置き、MATCHは必ず最後に置きます。先にGEOIP,CN,DIRECTを書き、その後にIP判定が必要なプロキシルールを書くと、前者がリクエストを先に奪う可能性があります。広いドメインサフィックスを先に書いてから、同じメインドメイン配下の特定サブドメインを書く場合も、後者は実行されません。

ルールが競合したときは例外を増やし続けるのではなく、まずリクエストが実際にヒットした項目を記録します。クライアントのログや外部コントロールパネルには通常、ルールタイプ、ルール内容、対象ポリシーが表示されます。誤ったルールにヒットしていることを確認したら、より具体的なルールを前方へ移動してください。ドメインを取得できない、接続がIPだけになっている、アプリがシステムの名前解決を回避している、といった場合に限ってIP系ルールを追加します。ドメインルールとIPルールを無計画に重ねると、結果を予測しにくくなります。

no-resolveは、IPルールに照合するための追加DNS解決を発生させたくない場合に使います。たとえばGEOIP,CN,DIRECT,no-resolveは、対象IPがすでに利用可能な場合だけ判定します。追加クエリを減らせますが、現在の接続がドメイン名だけの場合、解決してから照合することはありません。使用前に、ルール処理の段階でリクエストがドメインなのかIPなのかを確認してください。no-resolveを汎用的な高速化オプションと考えてはいけません。

更新失敗とルール未適用は分けて対処する

providerのダウンロード失敗はソース層の問題です。まず直接接続でアドレスへアクセスできるか確認し、URL、レスポンス形式、キャッシュディレクトリの権限を確認します。ダウンロードは成功したのにヒットしない場合は参照層の問題です。rulesに対応するRULE-SETがあるか、プロキシグループ名が正しいか、前方のルールが先にヒットしていないかを確認してください。ファイルの解析失敗は形式層の問題です。behavior、format、YAMLのインデント、payloadの階層を重点的に確認します。

ルールを更新したら、設定を一度再読み込みしてから固定したドメインでテストします。複数のサイトを同時に使わないでください。ブラウザのバックグラウンド通信、QUIC、キャッシュがログに混ざるためです。対象を一つ選び、接続履歴を消去して一度だけアクセスし、ドメイン、ヒットしたルール、最終ポリシーの三つが一致することを確認します。ルールの基本概念は用語ガイドで確認できます。ノードがすべてタイムアウトする場合はノードタイムアウトの切り分け手順へ進み、ルールセットを繰り返し変更しないでください。

CHAPTER 03

DNS設定の最適化

DNSの問題はノードの問題と誤認されがちです。ブラウザに接続失敗と表示されても、ドメインが解決されていない、誤った結果がキャッシュされている、クエリがClashに入っていない、またはルール処理で元のドメイン名を取得できていない可能性があります。診断ではまず「DNSクエリを誰が処理しているか」と「解決結果が接続にどう使われるか」を分けて考えます。システムDNS、クライアント内蔵DNS、ブラウザの暗号化DNS、アプリ独自の名前解決は同時に存在できます。クエリ経路を確認して初めて、設定項目に意味が生まれます。

まずnameserver、default-nameserver、fallbackを理解する

nameserverは主要な名前解決先です。通常のUDP/TCP DNSだけでなく、DoHやDoTも利用できます。default-nameserverは主に暗号化DNSの上流サーバー自身のドメイン名を解決するために使われ、通常は直接アクセスできるIPアドレスを指定します。「DoHへ接続するためにDoHのドメインを解決し、その解決にDoHが必要」という循環を避けるためです。すべてのサービスクエリのデフォルト出口ではなく、多数のアドレスを詰め込むものでもありません。

fallbackとフィルター設定は、異なる解決結果から選択するために使います。この仕組みは設定が複雑です。汚染対策や地域別の名前解決が明確に必要でなければ、まず安定したnameserverだけを使い、基本の名前解決が正常になってからfallbackを追加してください。上流を増やしても速くなるとは限りません。並列クエリでログが複雑になり、異なる結果がキャッシュされることもあります。役割が明確な上流を2〜3個に絞るのが基本です。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  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
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com
    - time.*.com
    - time.*.gov

proxy-server-nameserverはプロキシサーバー自身のドメイン名を解決するために使います。ノードアドレスがドメイン名で書かれている場合、まずノードのIPを取得し、その後でプロキシ接続を確立します。この種のクエリがまだ確立していないプロキシに依存すると、起動時のデッドロックが起きます。プロキシが先に接続を必要とし、その接続にもプロキシ経由の解決が必要になるためです。ノードのドメイン名を直接アクセス可能な上流で解決すれば、サービス用DNSとノード用DNSを分離できます。

Fake-IPとredir-hostの選択

fake-ipはドメイン名をすぐに実際の宛先IPへ解決せず、予約済みアドレスプールから対応アドレスを返します。アプリがそのアドレスへ接続すると、カーネルがマッピングテーブルからドメイン名を復元し、ドメインルールに従って処理します。ドメイン情報をより完全に保持し、実際のDNS結果がアプリへ早期に露出するのを抑えられるのが利点です。一方、LAN探索、デバイスへのキャスト、時刻同期、ゲーム、実IPの検証に依存するアプリなどでは互換性問題が起きることがあり、fake-ip-filterで除外する必要があります。

redir-hostは実際の解決結果を返すため、従来型プロキシに近い互換性がありますが、ルール処理でDNS結果やスニッフィングへの依存が増える場合があります。モードは「Webページを開けるか」だけで選ばないでください。LAN機器、システム時刻、普段使う通信アプリ、地域判定が必要なサービスも確認します。特定の種類のドメインだけに異常があるなら、全体をredir-hostへ戻す前に、そのドメインをフィルターへ追加することを優先してください。

IPv6の設定はローカルネットワークと合わせて判断する

ipv6: falseはAAAAレコードの結果を抑制します。ローカルのIPv6が不完全、ノードがIPv6に対応していない、IPv6が優先されるものの接続に失敗しやすい環境に適しています。ローカルと出口の両方で安定したIPv6を使える場合は有効化し、A、AAAAのクエリと実際の出口を個別に確認してください。システムでIPv6だけを無効にしてClashにAAAAを返させると、アプリは到達不能なアドレスを先に試すことがあります。逆にネットワークがIPv6対応でもDNSでAAAAを禁止すれば、IPv6は使われません。

DNSリークは一つの検査サイトだけで判断できません。まずシステムDNSがクライアントの待受アドレスを向いているか確認し、次にブラウザで独自のセキュアDNSが有効になっていないか確認し、最後にクエリがカーネルへ入っているかログを確認します。ブラウザのDoHがシステムDNSを回避していても、接続トラフィック自体はプロキシを通る場合があります。これはクエリ経路の違いであり、すべての通信が直接接続されていることを意味しません。統一して制御するには、ブラウザの独自解決を無効にするか、上流もルールで正しく処理します。

症状からDNS障害を切り分ける

「ドメインでは開けないがIPへ直接アクセスできる」場合は、まず上流DNSと待受ポートを確認します。「初回は遅いが再読み込みで正常」なら、上流への接続、キャッシュ、IPv6のタイムアウトを確認します。「一部のLAN機器が見つからない」場合はFake-IPフィルターを確認します。「ログにIPしか表示されずドメインルールにヒットしない」場合は、アプリがDNSを回避していないか、スニッフィングが有効か、透過プロキシが対象接続を捕捉しているかを確認します。変更後はシステムとブラウザのDNSキャッシュを消去し、対象アプリを再起動して、古い接続が結果に影響しないようにします。

症状 優先して確認する項目 次の手順
すべてのドメイン解決に失敗する DNSの待受、上流への到達性 ローカルの名前解決コマンドで待受ポートを指定してテストする
ノードのドメイン名だけ失敗する proxy-server-nameserver 直接接続でノードのドメイン名を解決できる上流へ変更する
LANサービスに異常がある fake-ip-filter 対象ドメインごとに除外項目を追加する
ドメインルールにヒットしない クエリがカーネルへ入っているか ブラウザのDoH、スニッフィング、TUNの捕捉を確認する

CHAPTER 04

TUNとFake-IP

システムプロキシは、プロキシ設定を自ら読み込むアプリにしか影響しません。コマンドラインツール、一部のゲーム、仮想マシン、独自のネットワークスタックを持つソフトは完全に無視することがあります。TUNモードはシステム内に仮想ネットワークインターフェースを作り、ルーティングによってより多くのTCP・UDP通信をカーネルへ渡すため、透過的に通信を取り込む用途に適しています。TUNは通信の入口を解決し、Fake-IPはドメインのマッピングを解決します。併用されることは多いものの、同じスイッチではありません。

設定前にルーティングの競合を除外する

TUNの起動には、仮想インターフェースの作成、ルートの追加、DNSの引き継ぎが必要で、通常はシステムの権限が求められます。クライアント画面でTUNが有効でも対象アプリが直接接続する場合は、まず仮想インターフェースの存在を確認し、次にデフォルトルートと除外ルートが機能しているか確認します。VPN、仮想マシン、コンテナ、ゲーム用アクセラレーター、他のプロキシソフトが同時にルートを変更することがあります。切り分け時は同種のツールを終了し、通信を引き継ぐプログラムを一つだけ残してください。

auto-routeはカーネルにルートを自動設定させるもので、一般的なデスクトップ利用に適しています。auto-detect-interfaceは実際の送信インターフェースを識別し、プロキシ通信が再びTUNへ入り込むループを防ぎます。有線から無線へ、家庭内ネットワークからテザリングへ切り替えると、古いインターフェース情報が無効になることがあります。ネットワーク切り替え後に突然すべてがタイムアウトしたら、すぐにノードを変えるのではなく、TUNまたはクライアントを再起動してインターフェースを再検出させてください。

tun:
  enable: true
  stack: mixed
  device: Mihomo
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: true
  mtu: 1500

stackはTUNデータをユーザー空間のネットワークスタックへ渡す方式を決めます。mixedはTCPとUDPの両方を扱う一般的なデスクトップ環境に向いています。特定のシステムで互換性問題がある場合は、クライアントが対応する範囲で別のスタックと比較しますが、一度に変更するのはこの項目だけにしてください。strict-routeは通信経路をより厳密に制御し、迂回を減らせる一方、LAN、仮想NIC、複数NICの環境に影響する可能性があります。有効化したら、ゲートウェイ、LAN機器、普段使うサービスをすぐにテストしてください。

DNSハイジャックは待受設定と対応させる

dns-hijackはTUNを通過する通常の53番ポートのクエリを内蔵DNSへ渡します。アプリが独自に開始したDoHを直接復号することはできず、TUNを通過しないクエリを確実に引き継げるわけでもありません。ハイジャックを設定していてもdns.enableが有効でない、または待受アドレスが競合していると、すべてのドメインが使えないように見えることがあります。この場合は先にルールを変更せず、DNSモジュールが起動しているか、ポートを別のサービスが使用していないかを確認してください。

Fake-IPのアドレスプールには通常、専用の予約範囲を使います。アプリがそのアドレスを受け取った後も、同じカーネルを経由しなければ、カーネルはマッピングテーブルからドメイン名を復元できません。ClashがDNSクエリにFake-IPを返しても、その後の接続がTUNやシステムプロキシを迂回すると、アプリはルーティングできない予約アドレスへ直接アクセスし、「解決できるのに接続できない」状態になります。この場合はDNS上流を変えるのではなく、通信の入口が一貫しているか確認します。

MTUとUDPはよくある境界要因

Webページは開くのに、大きなファイル、画像、一部のTLS接続が止まる場合はMTUを疑います。仮想インターフェースのカプセル化でオーバーヘッドが増え、基盤ネットワークの実効MTUが小さいこともあります。まず特定のネットワークだけで起きるか観察し、その後TUNのMTUを少しずつ下げてテストしてください。一度に極端に小さくしないでください。値が低すぎると分割と処理負荷が増え、高すぎると経路上のブラックホールに遭遇する可能性があります。

ゲーム、音声通信、QUICはUDPに依存します。TUNがUDPを捕捉していても、ノードのプロトコルや出口が対応しているとは限りません。確認順は、ログにUDP接続が出ているか、ルールが正しいポリシーにヒットしているか、選択したノードがUDPに対応しているか、システムファイアウォールが仮想インターフェースを許可しているかです。ブラウザの表示に異常がある場合は、一時的にQUICを無効にしてTCP経路を比較することもできます。これは切り分け用であり、恒久対策とは考えないでください。

プラットフォームごとの確認ポイント

Windowsではドライバーの権限、システムサービス、他のVPN仮想NICを確認します。macOSではネットワーク拡張の許可とシステムのネットワークサービス順を確認します。LinuxではTUNデバイスの権限、ポリシールーティング、転送、ファイアウォールルールを確認します。AndroidとiOSのClash系クライアントは通常、システムVPNインターフェースで通信を引き継ぎます。システム上で同時に許可される主要VPNセッションは通常一つだけなので、別のVPNを有効にすると現在の接続が置き換わることがあります。対応クライアントを選ぶときはダウンロードセンターで各プラットフォームの一覧を確認してください。Clash Plusは全プラットフォーム向けの第一候補です。

CHAPTER 05

ドメインスニッフィング

アプリがIPへ直接接続する、キャッシュされた結果を使う、またはDNSクエリがClashを経由しない場合、ルール処理では宛先IPしか見えないことがあります。ドメインスニッフィングは接続開始時のデータからホスト名を抽出します。たとえばTLSハンドシェイクのSNIやHTTPリクエストのHostを読み取り、ドメイン名をルールシステムへ渡します。経路判定の材料を補う機能であり、暗号化された内容をすべて解析するものではありません。また、すべてのプロトコルでドメイン名を復元できる保証もありません。

スニッフィングを有効にするタイミング

ログにIPしか表示されず、DOMAIN、DOMAIN-SUFFIX、ドメインルールセットにヒットしない状態が続く場合、スニッフィングが有効です。Fake-IP使用時は、カーネルがすでにドメイン名を把握していることが多く、必要性は下がりますが、内蔵DNSを回避する接続には役立つ場合があります。「機能を増やす」ためにすべてのポートを無条件で有効にしないでください。問題の接続が使うプロトコルとポートを特定してから、捕捉範囲を決めます。

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

parse-pure-ipは、宛先が純粋なIPである接続からドメイン名の抽出を試みます。force-dns-mappingは既存のDNSマッピングと組み合わせます。override-destinationは、スニッフィングで得たドメイン名を元の宛先の代わりに使うかどうかを決めます。宛先を上書きするとドメインルールを適用できますが、固定IP、証明書検証、独自プロトコルを使うアプリでは副作用が出る可能性があります。まずプロトコル単位で上書きを有効にし、最初から全体へ適用しないことを推奨します。

HTTPスニッフィングは暗号化されていないリクエストヘッダーに依存し、TLSスニッフィングはハンドシェイク中に見えるSNIを読み取ります。QUICはプロトコル実装と暗号化ハンドシェイクの影響を受けます。ECHなどの仕組みで従来のSNIが隠されると、スニッフィングで宛先ドメインを取得できません。これは設定ミスではなく、接続内に抽出可能な平文識別子がないためです。その場合はDNSクエリをカーネルへ入れるか、明示的なIP、プロセス、ルールセットの方針で補います。

skip-domainで互換性問題に対処する

LAN機器の検出、プッシュ通知、システムの接続確認、一部のゲームは宛先の書き換えに向かないことがあります。「スニッフィングを無効にすると正常だが、有効にすると特定のアプリだけ失敗する」場合は、まずログでスニッフィングされたドメイン名を確認し、具体的なドメインをskip-domainへ追加します。除外範囲はできるだけ小さくしてください。広すぎるトップレベルサフィックスを指定すると、多くの正常な接続でドメインルールが使えなくなります。

一部のクライアントでは、スニッフィングの項目がグラフィカルインターフェースの上書き設定にあり、購読を更新しても変わりません。別のクライアントでは設定ファイルを直接読み込みます。切り分ける前に購読元の原文ではなく、最終的に有効な設定を確認してください。クライアントに「実行中の設定」や「現在の設定」の表示機能がある場合は、その内容を基準にします。ローカル上書きですでにsnifferが変更されていると、購読ファイルを手作業で編集しても効果はありません。

スニッフィングが実際にルーティングへ参加しているか確認する

ログにIPしか表示されない対象を一つ選び、既存の接続を消去してリクエストを再実行します。元の宛先、スニッフィングされたドメイン、ヒットしたルール、最終ポリシーを順に記録してください。ドメインが表示されたからといって、ルールが必ずそれを使うとは限りません。ヒット項目がIPルールから想定したドメインルールへ変わったことも確認します。ドメインが正しいのにデフォルトルールへヒットする場合は、ルール順序とサフィックスの書き方を確認します。スニッフィングされたドメインが誤っている場合は、まず宛先の上書きを無効にし、そのドメインまたはアプリを除外へ追加します。

プロセスルールはデスクトップ環境の補助として使えますが、プロセス識別の対応状況や権限はOSによって異なります。ランチャー、子プロセス、サンドボックスによってプロセス名が変わることもあるため、すべてのサービスをプロセスに結び付けるべきではありません。安定した振り分けはドメインルールを中心にし、IPルールとプロセスルールはドメインを取得できない一部の接続を補う用途にします。

CHAPTER 06

ローカル上書きと複数購読の統合

リモート購読はノードや基本ポリシーの提供には適していますが、長期的な手動編集領域には向きません。クライアントが購読を更新すると、通常は設定を再生成するため、購読ファイルへ直接書き込んだDNS、ルール、プロキシグループが上書きされることがあります。ローカル上書きの目的は、「上流が更新を担当する内容」と「本機で長期的に保持する内容」を分離することです。変更前に、クライアントが対応するのがフィールド上書き、スクリプト処理、設定断片の統合、完全な設定管理のどれなのか確認してください。名称が似ていても、統合順序は異なります。

まず最終設定の生成順序を確認する

一般的な流れは、リモート購読を読み込み、ノードとプロキシグループを解析し、ローカルの前処理スクリプトや断片を適用してから、実行設定を書き出します。クライアントによってはローカルルールを購読ルールの前に追加し、別のクライアントでは後ろに追加します。同名キーを上書きするものもあれば、配列を連結するものもあります。順序を把握していないと、追加したルールがMATCHの後ろに入り、永遠にヒットしないことがあります。同名のプロキシグループも、一つのノードが追加されるのではなく、グループ全体が置き換わる場合があります。

最も確実な確認方法は、三つの内容を比較することです。リモート購読の原文、ローカル上書きの内容、クライアントの最終実行設定を比較します。エディターの断片を見るだけでは、適用されたとは証明できません。変更するたびに対象フィールドを検索し、最終設定内に一度だけ現れること、階層が正しいこと、参照先が存在することを確認します。YAMLでは配列とオブジェクトの違いにも注意してください。rulesとproxiesは順序を持つリストで、dnsとtunは通常キーと値のオブジェクトです。誤った統合方式は意味を直接変えてしまいます。

prepend-rules:
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - PROCESS-NAME,backup-client,DIRECT

append-proxies:
  - name: ローカル出口
    type: socks5
    server: 127.0.0.1
    port: 1081

override:
  ipv6: false
  log-level: info

上の例は一般的な上書き意図を示したものです。クライアントによって断片ファイルのフィールド名は統一されていないため、実際の仕様を確認してください。汎用Clash設定にはトップレベルのprepend-rulesフィールドはなく、上書きツールの構文をそのままconfig.yamlへコピーすることはできません。設定エラーの切り分けでは、最初に「カーネル標準のフィールド」と「クライアントの統合機能のフィールド」を区別します。

複数購読の統合では先に名前の競合を処理する

二つの購読に「自動選択」「プロキシ選択」など同じプロキシグループが含まれたり、同名ノードが存在したりすることがあります。単純に連結すると、重複名、参照のずれ、後の設定による上書きが起きます。統合前に、用途に応じて「仕事用」「予備」など、安定したプレフィックスをソースへ付け、そのうえで独自の上位プロキシグループを構築します。上位ルールは自作グループだけを参照し、上流がいつ変更するか分からないグループ名へ直接依存しないようにします。これにより、特定の購読を更新してもすべてのルールへ影響しにくくなります。

ノード名は参照キーであると同時にフィルター条件にもなります。異なる購読から同名ノードが来ると、サーバーが違ってもプロキシグループ内で区別しにくくなります。名前変更はノードをプロキシグループへ入れる前に行い、地域、用途、提供元の情報を短く明確に保ちます。購読期限や残り容量などの動的な文字列を長期的なフィルター条件に混ぜないでください。上流がその文字列を更新すると、正規表現が意図しない一致を起こします。

proxy-groups:
  - name: 総合出口
    type: select
    proxies:
      - メイン購読自動
      - 予備購読自動
      - DIRECT

  - name: メイン購読自動
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 予備購読自動
    type: fallback
    use:
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

上書き範囲を小さくするほど更新コストは下がる

長期的な上書きには、本機で本当に必要な内容だけを残します。LAN向けの直接接続ルール、DNSの選択、TUNパラメータ、自作プロキシグループ、少数のサービス例外などです。上流の設定全体をコピーして編集しないでください。購読更新によるノード変更を受け取れなくなるためです。完全な設定を管理する必要がある場合は、購読をノードproviderへ切り替え、プロキシノードだけを読み込む形にします。ポリシーとルールはすべてローカル設定で管理します。

統合に失敗したら、三つのレイヤーで確認します。構文層ではYAMLのインデント、リスト記号、重複キーを確認します。参照層ではプロキシグループ、provider、ルール名が存在するか確認します。実行層では、クライアントが生成後の設定を本当に選択しているか確認します。設定は読み込めるのにノードが空なら、通常はproviderまたはフィルターの問題です。設定を読み込めないなら、まず重複名と未知のフィールドを確認します。更新後にローカル設定が消えるなら、上書きの実行順または保存場所が誤っています。

より多くの自動処理を追加するより、戻せるポイントを作ることが重要です。検証済みの基本設定を一つ保存し、各ローカル断片の用途を記録して、変更後に再読み込みテストを行います。クライアントを更新したり別の端末へ移行したりする場合は、まず基本設定を読み込んでカーネルとネットワークが正常であることを確認し、その後で上書きを一つずつ戻します。プラットフォームごとのクライアントはダウンロードセンターで選べます。初回移行の手順は使用ガイドを参照してください。

CHAPTER 07

外部コントロールパネル

外部コントロールAPIでは、接続、ログ、ルール、プロキシグループの状態を読み取れるほか、ポリシーの切り替え、接続の終了、設定の再読み込みも行えます。これは切り分け用のツールであり、通信を転送する入口ではありません。コントロールパネルはカーネルが提供するAPIを呼び出すだけで、画面自体がカーネルの代わりになったり、設定を自動修復したりすることはありません。画面がオフラインと表示されたら、まずコントロールアドレスと認証を確認し、次にカーネルプロセスが動作しているか確認してください。

待受アドレスが公開範囲を決める

external-controllerはコントロールAPIの待受アドレスを指定します。本機だけで使う場合は、まず127.0.0.1へのバインドを優先してください。0.0.0.0へバインドすると、同じネットワーク上の他の端末がそのポートへアクセスできる可能性があるため、アクセス制御とファイアウォールを必ず併用します。ブラウザ画面を接続させるためだけに、公開範囲を広げないでください。まずパネルとカーネルが同じ端末上にあるか確認し、同一端末ならループバックアドレスを使うのが最も簡単です。

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-string"
external-ui: ./ui
external-ui-name: dashboard
external-ui-url: https://example.com/dashboard.zip

secretはコントロールAPIの認証情報で、パネル接続時には同じ内容を入力します。変更すると、古いパネルは直ちにアクセスできなくなりますが、正常な動作です。認証失敗では、APIへ到達できるのにポリシーや接続を読み取れないことが多いです。コントロール用の秘密情報を公開ページ、スクリーンショット、共有設定へ書かないでください。他者へ診断情報を渡す場合は、コントロールアドレス、認証フィールド、購読URL、ノードの認証情報を削除します。

external-uiはローカルの静的パネルディレクトリを指定し、external-ui-urlはパネルファイルの取得に使えます。カーネルAPIとパネルファイルは別の要素です。APIは正常なのに画面が空白ならUIファイルのパスが誤っている可能性があります。画面は開くのにデータがないなら、コントロールアドレス、クロスオリジン設定、認証の誤りが考えられます。別々にテストして、どのレイヤーに問題があるかを特定してください。

端末間アクセスには追加の制限が必要

LAN上の別端末からアクセスする必要がある場合は、待受アドレスをLANから到達可能なインターフェースへ変更し、システムファイアウォールで信頼できるネットワーク範囲だけにポートアクセスを許可します。ルーターのポート転送やインターネットへの待受はリスクを大きく広げるため、通常のリモート管理方法にすべきではありません。より安全なのは、管理されたプライベートネットワークやローカルトンネルを通じてループバックインターフェースへアクセスし、認証を有効に保つ方法です。

ブラウザのパネルはHTTPまたはWebSocketでコントロールAPIへ接続します。パネルがHTTPSで、APIが通常のHTTPの場合、ブラウザが混在コンテンツをブロックすることがあります。その場合はブラウザのセキュリティ制限を無効にするのではなく、パネルとAPIを同じ管理下の入口からアクセスさせてください。WebSocketが繰り返し切断される場合は、リバースプロキシがアップグレードヘッダーを正しく転送しているか、システムのスリープがカーネルを停止していないか、ファイアウォールがアイドル接続を破棄していないかも確認します。

パネルを使ってリクエストをレイヤーごとに確認する

接続一覧では少なくとも、宛先ドメインまたはIP、ヒットしたルール、ポリシーチェーン、最終ノードの四項目を確認します。ドメインが空ならDNSとスニッフィングへ戻り、ルールが違うならルール順序を確認します。ポリシーチェーンが正しいのに最終ノードが異常なら、プロキシグループの現在の選択を確認します。すべて正しいのに接続できない場合は、ノードのハンドシェイク、UDP対応、ローカルネットワークを確認します。この順序なら、タイムアウトを見てすぐに設定全体を変更する事態を避けられます。

ルール画面では通常、providerが読み込まれているか、ルール数が存在するかを確認できますが、数だけで品質を判断しないでください。接続ログのほうが重要です。固定した対象を一つ選び、古い接続を閉じてから一度リクエストを送り、ドメインから出口までの経路全体を確認します。ログレベルは日常の切り分けならinfoで十分です。ハンドシェイクやルールの詳細が必要なときだけ一時的にdebugへ切り替え、完了後は戻してください。大量のログで重要なイベントが埋もれるのを防げます。

パネルでポリシーを切り替えても、既存の長時間接続が新しいノードへすぐ移行するとは限りません。出口を検証するときは、対応する古い接続を閉じ、必要なら対象アプリを再起動して、新しいリクエストを送ります。ブラウザのタブ、ダウンロード、インスタントメッセージアプリは接続プールを維持します。プロキシグループの画面が切り替わっただけでは、現在のリクエストが新しい出口を使っている証明にはなりません。

再現可能な総合トラブル対処手順を作る

設定を何度も変更した後は、まず現在の実行設定と直近のログをエクスポートします。次にTUNを無効にしてシステムプロキシだけを残し、基本ノードへ接続できることを確認します。その後DNSを有効にして固定ドメインの解決を確認し、ルールセットを戻してヒット状況を確認します。最後にFake-IP、スニッフィング、TUNを順番に有効化します。各レイヤーを戻すたびに同じテスト対象を使ってください。ある段階で失敗し始めたら、障害は直前に戻したレイヤー、またはその前のレイヤーとの境界にあります。

特定のノードだけタイムアウトする場合は、ノードタイムアウトで接続できない場合の切り分け手順を確認してください。全体的に速度が低下した場合は、速度低下のレイヤー別診断を参照し、ノード、回線、ローカル設定を切り分けます。設定ファイルの読み込みに失敗した場合は構文と参照関係へ戻り、接続性の記事にあるノード変更手順を名前解決エラーへそのまま適用しないでください。