Clash設定の応用ガイド

プロキシグループ、ルールセット、ネットワークスタックを、問題がある階層ごとに確認できます。

まず接続を確立してから、設定を調整しましょう。クイックスタートガイドでは、インストール、サブスクリプションの読み込み、システムプロキシ、初回の動作確認を解説します。このページでは、設定項目の関係や継続的な管理方法、変更後の確認手順を説明します。クライアントがまだ決まっていない場合は、クライアントのダウンロードページでプラットフォームに合ったものを選んでください。各プラットフォームの第一候補としてClash Plusを紹介しています。すでに使える設定がある場合は、該当する章から読み進めてください。

ここでは主にmihomoの設定仕様に沿って解説します。クライアントによって設定項目が変換、上書き、制限される場合があるため、デスクトップ向けのYAMLをすべてのモバイルアプリにそのまま適用できるとは限りません。コードブロックは各テーマの設定例です。実際に使う場合は、完全な設定ファイルの同名項目に統合してください。例に記載したドメインはマッチングの仕組みを示すもので、プロキシサービスを意味しません。プロキシノード情報は掲載しておらず、単一のテスト結果だけで経路全体を判断することもありません。

設定の階層とClashのポート設定

変更を加える前に、実際に有効な設定を確認しましょう。サブスクリプションからダウンロードしたファイル、クライアントに保存された設定、マージ後の実行設定は、別々のファイルであることが少なくありません。サブスクリプションはプロキシと基本的なポリシーを提供し、クライアントの設定がポート、モード、DNS、TUNを管理する場合があります。さらにローカル上書きでルールを追加できます。エディターで項目を確認できても、カーネルで適用されているとは限りません。実行設定、設定画面、起動ログを確認し、最終的な値を確かめてください。実行設定を確認できない場合は、関連する管理オプションがクライアントで有効か、少なくとも記録しておきましょう。

YAMLのインデントと項目の階層

YAMLではスペースで階層を表します。同じ階層の項目は位置をそろえ、リスト項目はハイフンで始めます。タブを混在させたり、同じ階層にdnsやrulesを重複して記述したりしないでください。重複キーは読み込み時に拒否される場合も、後の値だけが残る場合もあります。コロンや空白を含む名前など、特殊文字を含む値は引用符で囲むと安全です。変更時は元の構造を保ち、対象の項目だけを編集してください。サブスクリプション全体を1行に圧縮すると、インデントの誤りや意図しない上書きを見つけにくくなります。

まず設定ファイルをローカルにバックアップし、設定チェックを実行してください。コマンドライン版のカーネルを使う場合は、次のコマンドを実行します。./config.yamlはカレントディレクトリにある設定ファイルを表します。実際のファイルが別の場所にある場合は、パスを変更してください。チェックに通っても、確認できるのは構文と基本的な参照関係です。サーバーへの接続、システム権限、DNS経路が正しいことまでは保証されません。クライアントに設定検証機能がある場合は、適用前に検証し、動作中のセッションまで停止させないようにしましょう。

mihomo -t -f ./config.yaml

混合ポートと待ち受けアドレス

mixed-portを使うと、HTTPプロキシとSOCKSプロキシで同じ待ち受けポートを共有できます。これはローカルアプリがカーネルに接続するための入口であり、リモートノードのサーバーポートでもコントローラーパネルのポートでもありません。以下の設定はループバックアドレスだけで待ち受けるため、単一端末での利用に適しています。通常、ブラウザーはシステムプロキシ経由で接続しますが、コマンドラインツールではプロキシ環境変数を個別に設定する必要がある場合があります。システムプロキシを自動設定するかどうかはクライアント側の機能です。mixed-portを記述しただけで自動設定されるわけではありません。

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

項目	役割	変更後の確認項目
`mixed-port`	HTTP・SOCKSの接続先	システムプロキシとアプリのプロキシポート
`allow-lan`	LANからのアクセス許可	待ち受けアドレス、ファイアウォール、アクセス範囲
`mode`	ルール、グローバル、直接接続の各モード	接続ログに表示される実際のポリシー
`log-level`	ログの詳細度	診断後に通常のログレベルへ戻す

ポートエラーが発生したら、別のプロキシアプリか、終了しきれていないカーネルがポートを使用していないか確認します。名前の分からないシステムプロセスを、いきなり終了させないでください。重複して起動しているクライアントを終了し、プロセスが消えたことを確認してから再起動します。ポートを変更する場合は、システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数もあわせて変更してください。YAMLだけを変更してシステムプロキシを古いままにすると、カーネルは正常に動作しているのにブラウザーでは接続が拒否されることがあります。詳しくはポート使用中エラーの対処法をご覧ください。

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

一度に変更するのは、ポート、DNS、TUNなど、動作の種類を一つに絞りましょう。適用後は新しい接続を作って確認してください。すでに確立しているブラウザーの長時間接続だけで判断してはいけません。変更前後の項目、問題が発生したアプリ、ログの時刻を記録しておけば、どの階層を元に戻すべきか分かります。他の人に相談する場合は、必要最小限の設定だけを共有し、サブスクリプションURL、認証情報、個人のネットワーク情報は削除してください。項目の構造とエラー発生時の状況は残しましょう。

設定が有効かどうかを最終的に判断するには、新しい接続がカーネルに届いたか、どのルールに一致したか、どの出口が選ばれたかを確認します。スイッチがオンになったこと、ファイルの保存に成功したこと、設定チェックに通ったことは、それぞれ異なる段階の完了を示すだけです。段階ごとに分けて確認すれば、ポートの問題をサブスクリプションの問題と取り違えたり、画面表示の誤りだけを理由に設定全体を書き直したりせずに済みます。

プロキシグループの種類と実際の振り分け

ルールはトラフィックの振り分け先を決め、プロキシグループは選択可能な出口を管理します。まず用途ごとに安定したグループ名を決め、グループ内のノードを更新する構成にすれば、サブスクリプションの更新ごとにルールを書き換えずに済みます。グループ名は大文字・小文字、空白、句読点も含めて、ルールの指定と完全に一致させてください。グループから別のグループを参照することはできますが、相互参照はできません。たとえば手動選択グループに自動選択グループを含める構成は一般的ですが、自動選択グループが逆に手動選択グループを含めると、正常に解決できない依存関係になります。

手動選択と自動選択

selectは出口を固定したい場合に適しており、クライアント上でメンバーを選択します。url-testは候補の応答遅延を定期的に比較するため、自動で出口を切り替えたい場合に向いています。fallbackはリストの順に利用可能なメンバーを選ぶため、主系・予備系が決まっている場合に適しています。load-balanceは複数の接続をメンバーに振り分ける機能であり、単一のダウンロードに帯域を直接合算するものではありません。測定頻度を考える前に、用途に合った動作を選びましょう。便利そうだからといって、すべてのアプリを自動選択グループに入れるのは避けてください。

以下は、グループの参照関係を理解するための最小構成例です。メンバーは組み込みのDIRECTだけなので、プロキシ出口はありません。実際のサブスクリプションを読み込んだ後、サブスクリプションに含まれるプロキシやほかのグループをメンバーに追加できます。この例は構造を分かりやすく示すためのもので、接続可能に見せるための架空サーバー情報ではありません。実際に使う場合はグループ名を安定させ、メンバーはサブスクリプションまたはローカル設定で管理してください。

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,出口選択
  - MATCH,DIRECT

速度テストの設定値は実際の使い心地を示すものではありません

自動テストには通常、urlやintervalなどのパラメーターが必要です。toleranceを設定すると、小さな遅延差による頻繁な切り替えを抑えられます。テスト先には、候補となる出口から安定してアクセスできる軽量なリソースを選んでください。例のドメインは設定項目の位置を示すだけで、信頼できる速度測定サービスではありません。実際の環境からアクセスできるURLを選びましょう。テスト間隔が短すぎるとリクエストが増え、モバイル端末のバッテリーも消耗します。長すぎると障害の検知が遅れるため、利用環境に合わせて調整してください。

テストに成功しても、特定のリクエストを出口から送信できたことを示すだけで、すべてのサイトにアクセスできるとは限りません。接続確立は速くても、混雑する時間帯は帯域が限られる出口もあれば、ウェブ閲覧には適していても、遅延の変動に敏感な音声通話には不向きな出口もあります。自動選択グループを比較するときは、同じテスト先、近い時間帯、新しい接続で確認してください。遅延の意味と測定範囲についてはノードの遅延テストと実際の通信速度の違いもご覧ください。ミリ秒の数値だけで長期的な出口を決めないようにしましょう。

種類	選択方法	主な注意点
`select`	メンバーを手動で選択	無効になった場合は通常、手動での対応が必要
`url-test`	テスト結果に応じて選択	低遅延でも広い帯域が保証されるわけではない
`fallback`	利用可能なメンバーを順に選択	リストの順序で優先するメンバーが決まる
`load-balance`	ポリシーに従って接続を振り分け	接続ごとに異なる出口が選ばれる場合がある

用途別グループとノードの供給元を分ける

長期運用する設定は2階層に分けられます。下位グループでノードの集約、自動テスト、主系・予備系の切り替えを行い、上位グループでウェブや業務サービスなどの用途を選択します。ルールからは上位グループを参照するため、ノード名が変わっても影響は下位グループに限られます。proxy-providersを使う場合、グループからuseで定義済みのプロバイダーを参照できます。プロバイダー名はノード名ではないため、完全な設定内で先に定義しておく必要があります。クライアントがグループを自動生成する場合は、カスタムグループが維持されるか確認し、更新時に同名の設定が上書きされないようにしてください。

ログイン状態を安定させたいサービスでは、手動選択グループか、主系・予備系が明確なグループを優先してください。出口が頻繁に変わると、追加認証を求められたり、接続元アドレスに基づくアクセス判定が変わったりすることがあります。グループのメンバーを切り替えても、すでに確立された接続は通常、元の経路を使い続けます。新しい接続から切り替え後の設定が適用されます。必要に応じて接続一覧から該当セッションを終了してください。設定が保存されていないと誤解しないようにしましょう。負荷分散を有効にする前に、リクエストごとに出口が異なってもサービスに問題がないか確認してください。

設定後は、ドメインを指定したルールで用途別グループへの振り分けを確認し、次にフォールバックルールを確認します。グローバルモードでは従来のルール振り分けが適用されないことがあり、直接接続モードでは用途別グループが使われません。そのため、グループの動作を調べる際は、まずルールモードになっているか確認してください。クライアントの一覧にグループが表示されているだけでは、実際の通信が参照しているとは限りません。接続詳細に表示されるルールと経路が、最終的な判断材料です。

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

ルールセットはルールの供給元と更新を管理するものであり、プロキシノードを提供するものではありません。rule-providersでルールデータを定義し、rulesで参照する条件と参照後のポリシーを指定します。この役割を混同しないでください。ルールファイルをダウンロードしただけでは、RULE-SETを記述しない限りマッチングに使われません。参照だけを書いても、データが読み込まれていなければ設定全体の読み込みに失敗する場合があります。まず小規模なローカルルールで動作を確認してから、リモート管理のセットを追加すると、書式の問題とネットワークの問題を切り分けやすくなります。

動作タイプとファイル形式

behaviorは、セットにどの種類のルールを格納するかを指定します。domainはドメインのリスト、ipcidrはIPアドレス範囲のリストに適しています。classicalには、DOMAIN-SUFFIX,example.comのようにルールタイプを含む項目を保存します。ルールの適用先は通常、外側のRULE-SETで指定します。classicalセットの項目にプロキシグループ名を追加しないでください。formatはファイルの形式を表します。YAML、プレーンテキスト、バイナリー形式は拡張子を変更するだけでは変換できません。動作タイプも、その形式でサポートされている範囲に合わせる必要があります。

以下は、構造の確認に適したローカルYAMLファイルの例です。相対パスは通常、カーネルの作業ディレクトリを基準に解決されます。GUIクライアントには独自の設定ディレクトリやファイルアクセス制限がある場合があり、エディターの現在のディレクトリが基準になるとは限りません。まず該当ディレクトリにrulesフォルダーを作成し、ルールファイルを保存してから、providerの定義を完全な設定に統合してください。用途別のルールはフォールバックルールより前に配置します。この例では直接接続を適用先にしており、外部のプロキシグループには依存しません。

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

上記のルールファイルの内容は次のとおりです。含まれるのはマッチング条件だけで、プロキシサーバー、グループ定義、グローバルDNS設定はありません。domainタイプを使う場合は、そのタイプのドメインセット用の書式で記述してください。classical形式のファイルは、項目を一つ変更するだけで別のタイプにはなりません。読み込みエラーが発生したら、まずproviderの動作タイプと形式が一致しているか確認し、次にファイルの内容を確認します。その後で、ルール自体が意図どおりかを調べてください。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.net

ローカルファイルからリモートの供給元へ移行する

リモート管理に切り替える場合は、供給元タイプをhttpに変更し、実際のルールファイルのURLを指定したうえで、専用のキャッシュパスと適切な更新間隔を設定します。intervalの単位は分ではなく秒です。セットごとに異なるパスを使い、一方の更新で別のセットが上書きされないようにしてください。リモートの供給元には、ルールファイルそのものを返すURLを指定します。ウェブページのプレビューURLではありません。ダウンロードが成功しても、HTMLのログイン画面やアクセス案内ページはルールデータとして読み込めません。

供給元を選ぶ際は、セットの容量ではなく、メンテナンス対象、項目の種類、更新方法を確認してください。対象範囲が広すぎるセットは、意図しない振り分けを引き起こす場合があります。特に業務ネットワーク、イントラネットのドメイン、特定アプリのログイン動作に影響することがあります。初めて導入する際は、個別の例外ルールをセットより前に置き、少数の接続先で確認してから対象範囲を広げてください。直近で正常に使えたローカル設定を保存しておき、キャッシュの動作は実際に使うカーネルとクライアントで確認しましょう。オフライン時に空のキャッシュから起動できると決めつけないでください。

ルールの順序と名前解決への影響

ルールは上から順に評価され、最初に一致した時点で判定が終わります。完全一致の例外を先に、より広いドメインサフィックスやルールセットを後に置き、最後にMATCHでフォールバックします。IP系のルールでは、ドメイン名を判定するために先に名前解決が行われ、待ち時間が増えることがあります。該当するルールにno-resolveを指定すると、そのルールの判定のために名前解決を開始するのを防げますが、すべてのルールに使える汎用スイッチではありません。ドメインに応じてポリシーを決めたい場合は、通常、ドメインルールを先に置き、アドレス判定が必要なルールを後に配置します。

特定の接続先が意図どおりに振り分けられない場合は、まず接続詳細で実際にマッチしたルールを確認してください。先に広範囲のセットがマッチしている場合、その後にある個別の例外は適用されません。フォールバックだけに一致している場合は、ドメイン情報が取得できているか、ルールファイルが読み込まれているか、接続先が別の関連ドメインを使っていないかを確認します。ログにルールのダウンロード失敗が記録されていれば、供給元へのアクセスとキャッシュディレクトリの権限を調べてください。一つの接続先がマッチしないからといって、すべてのルールセットを同時に入れ替えると、調査範囲が広がってしまいます。

長期的に管理するには、各供給元の用途と想定する適用先を記録しておきましょう。providerを削除する前に、すべてのRULE-SET参照を検索してください。グループ名を変更する場合も、参照先をあわせて更新します。個人用の例外は小規模なローカルセットに、共通の分類はリモートセットに分けると、更新リスクを明確な範囲に限定できます。複雑な振り分けの用語を確認したい場合は、用語クイックリファレンスを参照し、その後、接続ログで結果を確認してください。

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

まず、どこで名前解決が行われているかを確認してから、DNSサーバーを選びましょう。アプリはシステムDNS、ブラウザー内蔵の暗号化DNS、独自のDNSサーバーを使う場合があります。カーネルも、プロキシサーバーのアドレス解決やルール判定のために、別途DNSクエリを送ることがあります。これらのリクエストが同じ経路を通るとは限りません。nameserverを変更しても、アプリがカーネルを経由せずに名前解決していれば、設定画面の値が正しくても実際の結果は変わりません。まず対象のクエリがカーネルに届いているか確認し、その後、どの上流DNSが選ばれたかを調べてください。

デフォルトDNS、上流DNS、ノードのドメイン名

default-nameserverは主に、ドメイン名を含むDNS上流サーバーのホスト名を解決するために使います。通常は、直接アクセスできるIPアドレスを指定します。nameserverは通常の上流DNSリストです。proxy-server-nameserverは、プロキシサーバーのドメイン名を解決するために使えます。プロキシ経路が確立する前に、その経路へ依存した名前解決を行う状態を避けられます。利用できるDNSサーバーはネットワークによって異なります。パブリックDNSのアドレスはあくまで例です。使う前にアクセスできるか、正しい結果が返るか確認してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

ここで指定するローカル待ち受けポートはDNS専用で、HTTPプロキシの入口ではありません。1053を指定しても、システムDNSが自動的にこのポートを使うわけではありません。OSの通常のDNS設定は標準ポートを使用するため、ほかのポートを使うにはクライアントによる統合、転送、TUNによるリダイレクトなどが必要です。まずクライアントがシステムのDNSクエリをどのように処理するか確認してから、待ち受けアドレスを検討してください。ほかの端末からのアクセスを可能にするためだけに、すべてのアドレスで待ち受ける設定へ安易に変更しないでください。DNSサービスもアクセス範囲を制限する必要があります。

ドメインごとにDNSの経路を指定する

nameserver-policyは、イントラネットのドメイン、特殊なサービス、特定のDNSサーバーからの応答が必要なドメインの処理に適しています。社内ドメインは社内DNSでしか解決できないことがあり、パブリックDNSに問い合わせると存在しないという結果が返る場合があります。パブリックサービスでは、安定した暗号化DNS経路が必要なこともあります。ポリシーのマッチングには、この項目でサポートされているドメイン構文を使ってください。通常のrules項目をそのまま記述することはできません。まず対象を明確にしたドメインサフィックスで設定し、応答を確認してから範囲を広げましょう。

respect-rulesを有効にすると、DNS上流へのリクエストもルールに従って経路が選ばれます。この場合、プロキシサーバーのドメイン名を確実に解決できる方法も必要です。設定によっては、プロキシ接続のためにサーバー名を解決しようとし、そのDNSサーバーへのアクセスにもプロキシが必要になるという循環が発生します。循環を確認する際は、プロキシサーバーの名前解決を直接到達できる上流DNSに分け、DNSサービスが復旧するか確認してください。DNSサーバーを増やしても信頼性が上がるとは限りません。応答の違いやトラブルシューティングの複雑さが増す場合もあります。

項目	主な役割	混同しやすい点
`default-nameserver`	上流DNSのホスト名を解決	すべてのアプリで使われるシステムDNSとは限らない
`nameserver`	通常の上流DNS	設定が存在してもアプリのクエリがそこを通るとは限らない
`proxy-server-nameserver`	プロキシサーバーのドメイン名を解決	プロキシに依存する名前解決の循環を避ける
`nameserver-policy`	ドメインごとに上流DNSを割り当て	通常の通信ルールとは構文が異なる

キャッシュ、IPv6、トラブルシューティング

DNSを変更した後も、ブラウザー、OS、カーネルに古いキャッシュが残る場合があります。確認する際は、該当する古い接続を終了し、クライアントが対応している方法でキャッシュを消去してから、新しいクエリを実行してください。古いページを一度再読み込みしただけで、新しい設定が無効だと判断しないようにしましょう。システムのクエリツールで確認できるのは、そのツールが使った名前解決経路の結果だけです。ブラウザーで独自のセキュアDNSが有効な場合は、異なる結果になることがあります。必要に応じて一時的にDNS経路を統一してテストし、終わったら普段の設定に戻してください。

IPv6では、DNSがIPv6アドレスを返すか、システムで利用可能なルートがあるか、プロキシノードが接続先のアドレスに対応しているか、TUNが該当トラフィックを処理するかをあわせて確認してください。DNS項目を一つ無効にしただけでは、ほかのアプリがIPv6リクエストを送らなくなるとは限りません。一部のサイトで、表示まで待たされた後に開く場合は、到達できないアドレスへの接続を先に試し、その後、別のアドレスファミリーへ切り替わっていないか確認しましょう。状況を把握してから調整し、すべての待ち時間をノードの遅延のせいにしないでください。

ログにDNSタイムアウトが記録されている場合は、上流DNSへの接続性と名前解決の循環を確認してください。アドレスは返るのに接続できない場合は、ルールで選ばれた出口と接続先のサービスを確認します。イントラネットの名前だけが解決できない場合は、プロキシグループ全体を切り替えるのではなく、ドメインポリシーと社内DNSを優先して調べましょう。クエリの入口、上流DNSの選択、応答アドレス、サービスへの接続という4段階で確認すると、パブリックDNSを次々に入れ替えるより効率的です。詳しいログの確認方法は実行ログの読み方をご覧ください。

TUNによる全体的な通信の取り込みとFake-IP

TUNは通信の入口、Fake-IPはDNSのマッピング方式で、同じスイッチではありません。TUNは仮想ネットワークインターフェースを作成してルートを調整し、システムプロキシに従わない一部のプログラムからの通信もカーネルに渡せるようにします。Fake-IPはドメイン名に対応するマッピング用アドレスをDNSの応答として返し、カーネルが接続を受け取った後に元のドメイン名へ復元します。組み合わせるとドメイン情報を保ちやすくなりますが、すべての端末やアプリに適しているわけではありません。ブラウザーがすでにシステムプロキシで正常に接続できている場合は、必要性を確認してからTUNを使いましょう。

有効化の条件と最小限の設定

デスクトップでは通常、管理者権限、サービスモード、またはネットワーク設定の権限が必要です。モバイル端末では、OSのVPNインターフェースを使います。権限不足、サービスの停止、別のVPNによるネットワークインターフェースの占有は、通信の取り込みに影響します。まずクライアントでサービスの状態を確認してからTUNを有効にしてください。enableをtrueにするだけでルーティングも設定されると思わないでください。以下はmihomoでよく使われる項目です。YAMLで管理できるかどうかは、クライアントが同名の設定を管理していないか確認してから判断してください。

tun:
  enable: true
  stack: system
  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は出口に使うインターフェースを検出します。複数のネットワークアダプター、仮想マシン、企業VPNがある環境では、適切でないインターフェースが選択される場合もあります。dns-hijackの対象は捕捉できる通常のDNSリクエストであり、アプリ独自のDoHを自動的に復号するものではありません。stackはネットワークスタックの実装に関わる項目です。system、gvisor、ほかの対応方式が使えるかどうかは、プラットフォームとカーネルのビルドに依存します。名称だけで速度を判断しないでください。

Fake-IPのマッピングと互換性の例外

Fake-IPアドレスは接続先サーバーの実際のアドレスではないため、通常のインターネット接続確認には使えません。カーネルがドメイン名とマッピングアドレスの対応を保持する仕組みなので、DNSクエリとその後の接続は同じ処理系を通す必要があります。アプリに古いマッピングがキャッシュされている一方で、カーネル側の状態が変わっていると、一時的にアクセスできない場合があります。アドレス範囲を変更したり、名前解決方式を切り替えたりした後は、必要に応じてキャッシュを消去し、接続を作り直してください。マッピングの不一致をルールの障害と取り違えないようにしましょう。

一部のLANサービス、デバイス検出、ゲーム、実際のアドレスを必要とするアプリは、fake-ip-filterに追加する必要があります。上記の例は一般的なローカルドメインサフィックスにすぎず、すべてのイントラネットに対応するものではありません。実際に問題が起きたドメインを個別に追加し、すべてのドメインをまとめて除外しないでください。フィルターに一致したドメインは通常、実際のDNS応答が返されます。その後もドメインに基づいて振り分けられるかどうかは、クエリ経路、キャッシュとの対応、スニッフィング機能によって変わります。これは互換性のための調整であり、直接接続を強制するルールではありません。

プラットフォーム環境	有効化前の確認事項	重点的に確認する項目
Windowsデスクトップ	クライアントサービスまたは管理者権限	残存する仮想インターフェース、重複したプロキシプロセス
macOSデスクトップ	ネットワーク設定の許可とクライアントサービス	ほかのVPN、ルーティング、インターフェースの選択
Linuxデスクトップ	ネットワーク管理権限とTUNデバイス	ポリシールーティング、ファイアウォール、サービスの権限
モバイル端末	VPNの許可とバックグラウンド実行の条件	アプリの除外リスト、OSの省電力制限

通信、DNS、ルートを分けて確認

有効にした後は、まず新しい接続がカーネルに入っているか確認します。接続ログがまったくない場合は、権限、ルート、アプリの除外リストを優先して確認してください。接続は記録されるもののアドレスしか表示されない場合は、DNSが想定どおりの経路を通っているか調べます。ドメインを識別できても出口が違う場合は、ルールの順序とプロキシグループを確認しましょう。一部のUDPアプリだけで問題が起きる場合は、ノードのプロトコルとサーバー側が該当する通信に対応しているかも確認してください。ウェブサイトが開けるだけでは、すべてのプロトコルが使えるとは言えません。

TUNを無効にしてもインターネットに接続できない場合は、カーネルが正常に終了したか、システムのルートが復元されたか、DNSが停止中のサービスを参照したままになっていないかを確認してください。まずクライアントからサービスを停止し、ネットワーク設定をリセットしましょう。すべての仮想ネットワークアダプターの削除を最初に試すのは避けてください。通信を取り込む仕組みやネットワークスタックの選び方については、TUN仮想ネットワークアダプターによる通信の取り込みを解説を参照し、プラットフォームに合わせて設定範囲を決めてください。

安定した動作確認には、通常のウェブ閲覧、システムプロキシを使わない接続先のアプリ、LAN内サービス、スリープ復帰後の通信を含めてください。それぞれ新しい接続でテストし、実際に適用されたルールと出口を確認します。TUNでより広い範囲の通信を取り込むと、問題が発生しうる範囲も広がります。必要なアプリだけを取り込み、適切な例外を残すほうが、すべての通信を無条件に取り込むより管理しやすくなります。

ドメインスニッフィングでルール判定を補正する

ドメインスニッフィングは接続先の情報を補う機能であり、暗号化された通信内容をすべて読み取るものではありません。アプリがIPアドレスへ直接接続している場合、DNSクエリがカーネルを通らない場合、または接続先とドメイン名の対応が失われた場合、ルールからIPアドレスしか認識できないことがあります。スニッフィングはプロトコルのハンドシェイクやリクエストヘッダーからホスト名を抽出します。たとえばHTTPのHost、TLSの一部のSNI、判別可能なQUICハンドシェイク情報などが対象です。抽出できるかどうかはプロトコルの実装やプライバシー機能に左右されるため、すべての接続からドメイン名を取得できるとは限りません。

不足しているのがドメイン情報かどうかを先に確認する

接続ログに長期間アドレスだけが表示され、関連するドメインルールにも一致しない場合に、スニッフィングを優先して検討してください。ログに正しいドメインが表示されているなら、ルールの順序、グループの選択、接続先への到達性に原因がある可能性があります。スニッフィングを有効にする前に、DNSと通信の入口が適切に設定されているか確認してください。スニッフィングは情報を補う機能であり、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

上記のポートは、該当するプロトコルの解析を試みる対象範囲を示します。待ち受けポートではなく、その範囲内のすべての通信を対象プロトコルに変換するものでもありません。parse-pure-ipは、純粋なIPアドレスを接続先とする通信でもスニッフィングを試みる設定です。force-dns-mappingは、DNSマッピングがある場合のスニッフィング動作に関係します。override-destinationは、スニッフィングで得たドメイン名を接続先の情報に適用するかどうかを制御します。まずfalseに設定すると、接続先の情報と接続方法が同時に変わるのを避けやすくなります。必要性を確認してから調整してください。

接続先を上書きする場合と、識別情報だけを補う場合の違い

接続先を上書きすると、その後の接続を新しいドメイン名に基づいて処理できるため、一部の振り分けでは役立ちます。一方、アプリが選択した元のアドレスが変わることもあります。同じドメインでもDNSサーバーによって異なる接続先が返る場合があり、アプリが選んだアドレスとカーネルが再解決したアドレスが一致するとは限りません。アクセス状況が変わった場合は、スニッフィングで得たドメイン名、元のアドレス、最終的な出口をあわせて確認してください。ルールがIPルールからドメインルールに変わっただけで、変更が正しいと判断しないようにしましょう。

暗号化されたClientHelloなど、ハンドシェイクのホスト名を隠す仕組みをアプリが使っている場合や、通信データがスニッファーの対応形式と異なる場合、カーネルが有効なドメイン名を取得できないことがあります。この場合、すべてのポート範囲を広げても改善しないことがあり、むしろ待ち時間や誤認識が増える可能性があります。接続先がもともとIPアドレスの場合、復元できるホスト名が存在しないこともあります。必要なIPルールを残すか、アプリに合わせて通信の入口を調整してください。スニッフィングに失敗するたびに設定エラーと考える必要はありません。

除外設定と動作確認

イントラネット機器、特殊なTLSサービス、初回ハンドシェイクのタイミングに敏感なプログラムは、実際のドメインに合わせてスニッフィングの除外リストに追加できます。まず問題を再現してから、対象を限定して追加してください。一つの例外のために、一般的なサービス全体を除外しないようにしましょう。除外リストはスニッフィングだけに影響し、直接接続を強制するものではありません。直接接続する通信は、rulesで明示的に指定してください。クライアントによってはスニッフィング関連の項目をすべて設定できない場合があります。画面上の設定を使う場合も、最終的な実行設定を確認してください。

動作確認では、まずスニッフィングを無効にして対象アプリで新しい接続を行い、その記録を保存します。次に同じ範囲で有効にし、接続を作り直して、ドメイン名、ルール、アクセス結果を比較してください。ブラウザーでテストする場合は、すでに確立された接続が再利用されないようにします。新しい接続で想定したドメイン名が取得され、安定してアクセスできることを確認してから、対象範囲を広げましょう。必要に応じてログを一時的に詳細にしますが、テスト後は通常のログレベルに戻してください。出力や個人のアクセス記録が増えるのを防げます。

QUICを識別できるかどうかは、UDP通信が実際にカーネルに届いているかにも左右されます。システムプロキシだけでは、すべてのアプリのUDP通信をプロキシ経由にできるとは限りません。適切な入口としてTUN、またはアプリ自体の対応が必要になる場合があります。同じサイトでもTCP接続は識別できるのに、UDP接続の記録がない場合は、スニッフィングのポートを何度も変更するのではなく、まず通信の入口を確認してください。特定のプロトコルだけで問題が起きるアプリでは、ドメイン名だけでなく接続プロトコルも記録すると役立ちます。

最終的には、スニッフィング情報がなくても妥当なフォールバックができるルール構成を維持してください。ドメインルールで主な分類を行い、必要に応じて明確なアドレス範囲をIPルールで処理し、判別できない接続は末尾のフォールバックで受けます。スニッフィングで分類精度を高めることはできますが、設定全体の唯一の識別手段にしてはいけません。アプリの更新、ネットワークの変化、プロトコルのプライバシー機能が強化された後も、設定の動作を把握しやすくなります。

ローカル上書きと複数サブスクリプションのマージ

個人用ルールはローカル上書きに置き、サブスクリプションの元データは更新用に残しておきましょう。ダウンロードしたサブスクリプションを直接編集すると、次回の更新で変更が失われることがあります。一方、サブスクリプションの内容をローカルファイルにコピーして固定すると、通常の更新ができなくなります。管理しやすい構成にするには、供給元、クライアントの設定、上書きの各レイヤーを分けます。プロキシ情報はサブスクリプションに連動させ、ポート、用途別グループ、個人用例外は安定して維持します。機能名は上書き、拡張、マージ、スクリプトなどさまざまです。画面上の名称だけでマージの仕様を判断しないでください。

オブジェクト、リスト、マージの順序

オブジェクトの項目は再帰的にマージされる場合も、全体が置き換えられる場合もあります。リストは追加、先頭への挿入、全体の置き換えなど、クライアントによって動作が異なります。特にrulesでは、個人用の例外をMATCHの後ろに追加すると適用されません。まず判別しやすいドメインの例外を一つ使って、先頭への挿入が機能するか確認してからルールを追加しましょう。dnsを変更する場合も、既存の上流DNSやポリシーが維持されているか確認してください。新しい項目があるだけで、従来の設定も有効だと思い込まないようにしましょう。

以下は、実行後に期待するルールの順序を示す例であり、あらゆるクライアントで使える上書きファイルの構文ではありません。個人用の例外を先頭に置き、その後に既存の用途別ルールを残し、末尾にはフォールバックを一つだけ置きます。クライアントで専用のprepend形式やappend形式が必要な場合は、そのクライアントの説明に従ってください。実行設定の一部を、すべてのクライアントで使える拡張形式だと見なしてはいけません。マージ結果を確認するには、実行設定を参照してください。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

複数のサブスクリプションをマージする前に名前の衝突を解決する

異なる供給元で同じグループ名やノード名が使われることは珍しくありません。そのまま連結すると、参照先が不明確になります。マージ前に供給元ごとの安定した識別子を決め、重複した名前がどう処理されるか確認してください。自動でプレフィックスが付く場合は、手書きのメンバーリストやフィルター式も更新が必要です。表示名だけを変更して参照先を更新しないと、グループのメンバーが見つからなくなります。一時的なテスト用の名前を長期運用の用途別グループにしないでください。用途別ルールからは、ローカルで定義した安定した上位グループを参照する構成がおすすめです。

proxy-providersを使うと供給元ごとに管理でき、グループのuseからそれぞれを参照できます。providerのURLには機密性の高いサブスクリプション情報が含まれるため、個人用の設定内に保管し、公開するスクリーンショットや相談用の資料には載せないでください。以下はローカルのプロキシデータを供給元にする例です。ファイルは利用者が事前に有効な内容を用意する必要があります。完全なサブスクリプションでも、利用可能なノード情報でもありません。供給元にプロキシ項目がない場合は、まず供給元を確認してください。グループが自動で出口を生成することはありません。

proxy-providers:
  personal-source:
    type: file
    path: ./providers/personal.yaml

proxy-groups:
  - name: サブスクリプションの出口
    type: select
    use:
      - personal-source

リモートのプロキシ供給元には、カーネルがサポートするプロキシセット形式のデータが必要です。完全なGUI設定ファイルを、そのままproviderの内容として読み込めるとは限りません。サブスクリプションの変換やクライアントへの読み込み時にプロキシ情報が抽出される場合もありますが、対応状況は実装によって異なります。供給元の読み込みは成功しているのにメンバーがいない場合は、DNSを変更する前にデータ構造、フィルター条件、名前の変更ルールを確認してください。フィルターが広すぎると不要なメンバーが含まれ、狭すぎると供給元が空になります。

上書きスクリプトの適用範囲

スクリプトは重複の削除、名前の統一、ルールの一括追加に適していますが、入力と出力の範囲を明確に保ちましょう。配列を変更する前に対象の項目が存在するか確認し、ルールを追加する前に同じものがすでに含まれていないか確認します。そうしないと、更新のたびにルールが重複します。供給元に変更があった場合、診断に必要なエラー情報を残し、空の設定を返さないようにしてください。スクリプトのAPIはクライアントごとに異なります。ポートを固定するだけの設定に、複雑なスクリプトを導入する必要はありません。

マージ後は3つの点を確認します。個人用の例外が共通ルールより前にあるか、用途別グループに想定した供給元が含まれているか、サブスクリプション更新後も上書きが維持されているかを確認してください。供給元が空の場合やダウンロードに失敗した場合もテストし、クライアントが利用できない設定を正常と誤認しないか確かめましょう。サブスクリプションを複数使うと、独立した障害点が増えます。単一の供給元で正常に動作する設定を残しておけば、問題が起きた際に原因をすばやく絞り込めます。

旧クライアントから移行する際は、まずサブスクリプションURLと必要な用途別ルールを移し、その後DNS、TUN、スクリプトを一つずつ戻してください。旧設定の画面向け項目や拡張構文が、新しいクライアントで認識されるとは限りません。拡張子が同じだからといって、ファイル全体をそのまま置き換えないでください。旧Clash for WindowsとClashX Metaは、すでにメンテナンスが終了したアーカイブ版の選択肢です。移行方法はサポート終了後の設定移行ガイドを参考にし、プラットフォームに合ったクライアントはクライアント比較で確認してください。

外部コントローラーパネルと実行時の診断

外部コントローラーはカーネルを管理するためのインターフェースです。パネルから状態を取得したり、プロキシグループを切り替えたり、接続を確認したりできます。プロキシの入口でもDNSの待ち受けでもありません。ブラウザーのプロキシ設定にコントローラーのポートを指定しても、通常のプロキシ通信はできません。パネルの接続先に混合ポートを指定しても、カーネルを管理できません。パネルを設定する前に、それぞれのポートの役割を確認してください。多くのデスクトップユーザーは、クライアント内蔵のパネルを使えば十分です。別途管理方法を用意する必要があるのは、サーバーや独立したカーネルを使う場合に限られます。

ローカルでの待ち受けとアクセス認証

単一端末で使う通常の設定では、ループバックアドレスでの待ち受けを優先してください。以下の例にあるsecretは、説明用の明示的なダミー値です。使用前に強度の高いランダム値を自分で設定し、個人用の設定内だけに保存してください。secretはコントローラーのAPIを保護するものであり、LAN向けプロキシの認証には使えません。ローカルだけで待ち受ける場合も、ほかのローカルプログラムからアクセスされるリスクを考慮してください。リモートで管理する必要がある場合は、管理ポートを直接公開するのではなく、アクセスを制限したトンネルを利用しましょう。

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"
log-level: info

クライアントがコントローラーのアドレスと認証情報を自動設定する場合、手動で記述した項目が最終設定に反映されないことがあります。パネルに接続する前に、実行設定か、クライアントが提供する管理画面で接続情報を確認してください。パネル側に設定するホスト、ポート、プロトコル、認証情報は、同じカーネルインスタンスのものにそろえる必要があります。複数のクライアントが起動していると、パネルが古いインスタンスに接続し、グループを切り替えても変化しないと思い込むことがあります。まず接続先のインスタンスを確認してから、APIの動作を調べましょう。

パネルのファイルとブラウザーのアクセス制限

external-uiはローカルのパネルリソースがあるディレクトリを指定します。そのディレクトリには、ページ本体と関連する静的ファイル一式が必要です。存在しないフォルダーを指定したり、クライアントのインストール先をパネル用ディレクトリとして指定したりしないでください。サーバーに導入する場合は、パネルのリソース、カーネル設定、キャッシュの各パスで権限を個別に管理します。パネルをアップグレードした後も、リソースのパスが正しいか確認してください。内蔵パネルだけを使う場合は、通常、この項目を自分で設定する必要はありません。

ブラウザーで接続に失敗する原因には、認証エラー、クロスオリジン制限、混在コンテンツのブロックなどがあります。HTTPSのページからHTTPのコントローラーにアクセスすると、ポートに接続できてもブラウザーにリクエストを拒否される場合があります。別オリジンの独立したパネルでは、カーネル側のクロスオリジン設定も適切に行う必要があります。コントローラーを公開したまま、手軽さを理由にすべての接続元を許可しないでください。最も簡単に確認できるのは、クライアントが提供するローカルの管理画面か、同一オリジンのパネルです。まずその方法で動作を確認してから、リモートアクセスを検討しましょう。

症状	優先して確認する項目	次に行うこと
接続が拒否される	カーネルの動作状況、待ち受けアドレス、ポート	ポートの役割と接続中のインスタンスを確認
認証に失敗する	パネルの認証情報と実行設定が一致しているか	ローカルパネルの接続設定を更新
ページは表示されるがデータが空	APIリクエスト、クロスオリジン、ブラウザーの制限	同一オリジンの入口でリクエストを確認
切り替え後もアプリが古い出口を使う	長時間接続と用途別グループの参照	該当する接続を作り直し、経路を確認

実行ログを使って調査の流れを整理する

まず接続一覧を確認します。接続先のドメイン名またはアドレス、マッチしたルール、プロキシグループの経路、出口は、設定の効果を判断するための重要な情報です。次に同じ時刻のログを確認し、DNSタイムアウト、接続開始の失敗、接続拒否、ルール不一致を切り分けます。ログレベルをinfoからdebugに一時的に変更した後、対象の問題を一度だけ再現し、必要な情報を収集したら元に戻してください。詳細ログを長期間有効にすると、ストレージ使用量が増え、アクセスに関するメタ情報も多く保存されます。

問題を再現するときは、時刻、アプリ、接続先、現在のモード、通信の入口、想定するポリシーを記録してください。ウェブページが開けず接続一覧にも記録がない場合は、アプリの通信経路とシステムプロキシを確認します。記録はあるのにドメイン名が表示されない場合は、DNSとスニッフィングを確認してください。ルールは正しいのに接続開始に失敗する場合は、ノードとリモートの接続先を調べます。切り替え後も古い出口が使われる場合は、長時間接続を確認しましょう。この順に切り分ければ、DNSの問題でノードを何度も変更したり、ノードの問題でルートを繰り返し変更したりするのを防げます。

診断資料を共有する際は、関連する接続と短時間のログだけを抜き出し、サブスクリプションURL、認証情報、個人のアクセス記録を隠してください。経路の構造を説明するために、ルール名やグループ名は通常そのまま残せます。プロキシサーバーの情報は、実際のプライバシー要件に応じて扱ってください。キャッシュ、サブスクリプション、クライアント設定が含まれる可能性があるため、実行ディレクトリ全体をそのままアップロードしないでください。必要最小限の再現情報に絞ると、情報の漏えいを抑えられ、問題も正確に把握しやすくなります。

メンテナンスが終わったら、使える状態を基準として復元してください。ルールモード、通常のログレベル、想定する待ち受け範囲、予備の設定が保たれているか確認します。クライアントを一度再起動し、現在のセッションだけで有効な設定になっていないか確かめてください。さらにサブスクリプション更新後も個人用ルールが残ることを確認します。最初の設定に不安がある場合はシステムプロキシの設定手順に戻ってください。項目の意味を調べるには用語クイックリファレンスをご利用ください。応用設定の目的は、動作を説明でき、変更を検証でき、障害時に元へ戻せることです。スイッチをできるだけ多く増やすことではありません。