Clash 設定上級ガイド - プロキシグループ・DNS・TUN・ルールセット解説

設定モデル、読み込み順序、検証の基準

クライアント、カーネル、設定の取得元をまず分ける

Clashエコシステムでは、デスクトップやモバイルのクライアントが購読管理、設定編集、システム権限の申請、画面表示を担当し、実際の接続処理はカーネルが行います。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどのクライアントは互換カーネルを呼び出す場合がありますが、購読の上書き、設定の統合、外部画面の実装方法はそれぞれ異なります。トラブル対処では、まず問題がどの層に属するかを確認してください。ダウンロードやインストールはクライアント層、YAMLフィールドが認識されない場合はカーネル・設定層、ノード自体が使えない場合はプロキシ経路の問題です。3つの層を混同すると、誤ったルールを直さないままクライアントだけを何度も変更することになります。

設定の取得元は通常、クライアントが生成する基本フィールド、購読から返されるノードとプロキシグループ、ユーザーが記述するローカル上書き、実行時状態の4種類です。実行時状態には、現在選択中のプロキシグループ、キャッシュ済みルールセット、DNSマッピングなどが含まれ、すべてがYAMLへ完全に書き戻されるとは限りません。購読更新時に設定を再生成するクライアントもあるため、生成後の一時ファイルを直接編集すると、次回更新で変更が上書きされる可能性があります。長期的に使う設定は、クライアントが用意した上書き、統合、スクリプトの入口に置き、現在の設定を直接編集する方法はテスト用途に限定してください。

インバウンドからアウトバウンドまでのデータ経路を理解する

接続がカーネルに入ると、通常はインバウンドの識別、ドメインの復元またはスニッフィング、ルール照合、プロキシグループの判断、プロキシ経由のアウトバウンドという順に進みます。TUNを有効にすると、システムルートが先にトラフィックを仮想インターフェースへ渡します。Fake-IPを有効にすると、DNS検索で予約アドレスが返され、カーネルがマッピングテーブルに基づいて元のドメインを復元する場合があります。ルールのDOMAIN-SUFFIX、GEOSITE、ドメインルールセットはドメイン情報に依存し、IP-CIDRとGEOIPは宛先アドレスを処理します。この流れを理解すれば、同じアプリがシステムプロキシでは正常なのにTUNでは別のルールに一致する理由を説明できます。

ルールは上から順に照合され、最初に一致すると後続の確認を停止します。そのため、具体的なドメイン、サービス専用ルール、ブロックルールは一般的な地域ルールより前に置き、MATCHは末尾に配置してください。プロキシグループはルールの宛先名にすぎず、トラフィックを自動的に照合するものではありません。たとえばDOMAIN-SUFFIX,example.com,業務トラフィックと記述した場合、設定内に完全に同じ名前のプロキシグループまたはプロキシノードが必要です。全角スペース、大文字・小文字の違い、名称変更の反映漏れは、読み込み失敗や選択不能の原因になります。

最小限の実用設定を作る

複雑な設定を数百行のテンプレートから始める必要はありません。まずリスニングポート1つ、ノードの取得元1つ、手動選択グループ1つ、フォールバックルール1つだけを残し、読み込みと接続を確認してから、ルールセット、DNS、TUNを段階的に追加します。以下の骨格はフィールド間の参照関係を示すものです。例のノードアドレスには予約ドメインを使用しているため、構造の説明専用であり、実際のプロキシ接続には使えません。

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

proxies:
  - name: Example-Node
    type: socks5
    server: proxy.example.com
    port: 1080

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選択
  - MATCH,手動選択

読み込み時はまずインデントを確認します。YAMLでは空白で階層を表すため、Tab文字、同じ階層の不統一なインデント、コロンの後の空白不足が解析失敗を招くことがあります。名前にコロン、シャープ、角括弧、前後の空白が含まれる場合は、引用符で囲むのがおすすめです。配列は複数行のリストにも角括弧形式にもできますが、同じブロックでは書式を統一すると確認しやすくなります。真偽値にはtrueまたはfalseを使い、画面でよく見かける「有効」「無効」の文字列を混在させないでください。

設定変更後の回帰チェック

変更後は少なくとも4種類のトラフィックを検証してください。明示的に直結させるサイト、明示的にプロキシを通すサイト、純粋なIPで接続する通信、ローカルLANサービスです。ブラウザーで成功しても、すべてのアプリが正常とは限りません。ブラウザーが独自のセキュアDNSやQUIC接続を使っている可能性があるためです。システムコマンドも併用し、たとえばnslookup example.comでシステムDNSを確認し、curl -I https://example.comでコマンドラインが想定した入口を通るか検証します。システムプロキシとTUNを同時に有効にしている場合は、一方ずつ無効にして再テストし、二重にトラフィックを取得していないか切り分けてください。

設定ファイルの安定性は、ロールバックできるかどうかで決まります。「直近の正常版」「現在のテスト版」「導入予定版」の3状態を残すほうが、同じファイルを繰り返し上書きするより安全です。プロキシグループ名を変更するときは、ルール、ルールセット、子プロキシグループ、ショートカットスクリプトに古い名前が残っていないか全体検索します。ノードプロバイダーを削除する前に、プロキシグループがuseで参照していないことを確認してください。クライアント再起動、購読更新、端末再起動後も設定が一貫して動作して、初めて検証完了です。

プロキシグループの種類と実際の組み合わせ方

select：最終的な選択を利用者に委ねる

selectは最も基本的なプロキシグループ種別です。グループにはノード、DIRECT、REJECT、他のプロキシグループを含められます。自動速度測定は行わず、現在の選択だけを保持します。「総合出口」「業務用」「ストリーミング」など、結果を明確に制御したい最上位グループに適しています。クライアントは通常、選択状態を保存しますが、保存先が元の設定ではなく実行時キャッシュの場合もあります。再起動後も選択を維持したい場合は、カーネルが対応するprofile.store-selectedを有効にし、クライアントが起動ごとに設定をリセットしていないことも確認してください。

最上位の選択グループに数百のノードを直接詰め込むのはおすすめしません。自動速度測定、フェイルオーバー、地域別ノードを子グループとして整理し、最上位グループからそれらを選ぶほうが明快です。ルールが依存する名前を安定した最上位グループに限定できるため、購読ノードの増減に合わせてルールを書き換える必要がなくなります。一時的な直結が必要な業務では最上位グループにDIRECTを追加できますが、プロキシ経路を迂回するため、出口を固定したい接続には適しません。

url-test：測定結果に基づいて利用可能なノードを選ぶ

url-testは指定したURLへ定期的にノードを測定し、応答性能が条件に合うノードを選択します。測定結果が示すのは測定先への接続状態であり、すべてのサイトやプロトコルの品質を保証するものではありません。テストURLは安定していて応答本文が小さく、実際に必要なプロトコルを使うものにしてください。intervalが短すぎるとバックグラウンド通信とモバイル端末の電池消費が増え、長すぎるとノード障害後の切り替えが遅れます。toleranceは、性能が近いノード間で頻繁に切り替わるのを抑える値です。値が大きいほど、差が小さい場合に現在のノードが維持されやすくなります。

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

  - name: 総合出口
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT

lazy: trueは、プロキシグループが実際に使われるまで必要な測定を行わない設定で、未使用グループのバックグラウンド測定を減らせます。画面にすべてのノードがタイムアウトと表示されても、すぐに全ノードが無効だと判断しないでください。テストURLに現在のネットワークからアクセスできるか、DNSが正しいか、システム時刻が正確か、プロキシプロトコルのハンドシェイクがネットワーク入口で妨げられていないかを確認します。段階的な確認にはノードのタイムアウト対処手順を参照してください。

fallback：優先順位と障害時の切り替え

fallbackは可用性とリスト順を重視します。通常はリスト前方にあり、測定を通過したノードを優先し、現在のノードが使えなくなると後続の利用可能な項目へ切り替えます。url-testと比べ、固定した主系・待機系の出口や、送信元アドレスを比較的安定させたいサービスに適しています。低遅延ノードを先頭に置けばよいとは限りません。固定地域や特定の提供元が必要な業務では、まず業務上の制約で並べ、その後に応答時間を考慮してください。

フェイルオーバーはセッションの移行ではありません。出口を切り替えると、既存のTCP接続は通常再確立が必要になり、ダウンロード、リモートターミナル、長時間接続が中断されることがあります。継続性が重要な処理ではアプリケーション層でリトライを設定し、頻繁なヘルスチェックによる誤切り替えを避けてください。ノードが一時的に不安定な場合は、測定間隔を適度に延ばすか、グループ内の順序で優先出口を維持します。測定時間の短さだけを追求しないでください。

load-balance：接続の分散であり、帯域の合算ではない

load-balanceは異なる接続を複数のノードへ分散します。1本のTCP接続を分割して複数回線の帯域を合算する機能ではありません。代表的な方式には、宛先ごとの対応を維持するハッシュ方式と、接続をより均等に順番で割り当てる方式があります。ログイン状態、送信元アドレスの検証、安定したリスク管理が必要な業務では、同じ宛先への対応を維持できる方式、またはselectとfallbackを使ってください。ラウンドロビン方式は独立した短時間接続に適しますが、同じサービスから短時間に複数の出口アドレスが見える可能性があります。

種類	判断基準	適した用途	主な制約
`select`	手動選択または永続化された状態	最上位の出口、業務専用グループ	無効なノードを自動で除外しない
`url-test`	測定結果と許容差	日常的な自動選択	測定先はすべての業務を代表しない
`fallback`	リスト順と可用性	固定した主系・待機系の出口	切り替え時に既存接続が中断する
`load-balance`	接続ハッシュまたはラウンドロビン	独立した接続への分散	1接続の帯域は合算しない

フィルターで購読ノードを管理する

ノードプロバイダーではfilter、exclude-filter、またはクライアントが提供する正規表現によって地域別グループを生成できます。正規表現は購読内に実際に存在する命名方式に合わせ、すべての提供元が同じ略称を使うと決めつけないでください。まずクライアントで元のノード名を確認してから式を作成します。マッチ結果が空になると、プロキシグループに選択肢がなくなる場合があります。地域名に複数の表記がある場合は、(香港|HK|Hong Kong)のようなグループ式を使えます。「期限切れ」「残り通信量」などの情報ノードを除外する場合は、別途除外条件を記述し、速度測定グループに混入しないようにしてください。

プロキシグループ設計の要点は、安定した参照関係です。ルールから参照するグループ名を少数の固定名にし、グループ内で変動するノードを整理します。一般的には「総合出口」から「自動選択」「フェイルオーバー」「地域選択」「DIRECT」を参照し、業務ルールは「総合出口」または少数の専用グループだけを参照します。同じ機能のグループをルールセットごとに作ると、設定が急速に肥大化し、購読更新後の実際の出口も確認しにくくなります。グループ名の意味を明確にし、階層は3段以内に抑え、2つのグループが互いを参照する循環を避けてください。

ルールセットの購読管理と照合順序

ルールの内容とプロキシ判断を分離する

ルールセットプロバイダーrule-providersは、ローカルファイルやリモートURLからルール群を読み込みます。解決するのはルール内容の更新であり、どのノードを使うかの判断ではありません。メイン設定ではRULE-SET,ルールセット名,プロキシグループ名によって、ルール内容をプロキシ判断へ接続します。同じルールセットを別の設定で異なるプロキシグループへ向けたり、ルールファイルを変更せずプロキシグループを差し替えて一時的に振り分けたりできます。

購読による管理は、規模が大きく独立更新したいドメイン分類、IPネットワーク、サービス一覧に適しています。数件だけで長期的に変わらないローカルルールは、rulesへ直接書くほうが確認しやすいでしょう。形式を揃えるためだけに、すべての単一ルールをリモートファイルへ分けないでください。リモート取得には、ダウンロード失敗、キャッシュ失効、形式変更という3つの変数が増えます。重要なローカルネットワーク、管理用アドレス、最終フォールバックルールはメイン設定に残し、外部ルールセットが一時的に利用できなくても基本ルートを予測できるようにしてください。

behaviorがルールファイルの意味を決める

behavior: domainはドメイン集合に使い、通常は完全なドメイン、ドメインサフィックス、特定のドメイン表現を記述します。behavior: ipcidrはIPv4およびIPv6のネットワークに使います。behavior: classicalでは、各項目にDOMAIN-SUFFIX、PROCESS-NAME、IP-CIDRなどの完全なルール種別を含められます。メイン設定で宣言したbehaviorは、ファイルの内容と一致していなければなりません。IPネットワークをdomainとして読み込んだり、完全なクラシックルールを単なるドメイン集合として読み込んだりすると、解析エラーやルール不一致の原因になります。

ルール形式には、YAMLテキスト、通常のテキスト、カーネルが対応するバイナリ形式などもあります。バイナリ形式は読み込み効率が高い一方、手作業での確認には向きません。テキスト形式はトラブル対処やバージョン比較が容易です。クライアントとカーネルの対応範囲は完全には一致しないため、設定を移行する際は、対象カーネルが指定したformatを認識できるか確認してください。容量より互換性を優先する場合は、対象クライアントで動作確認済みのYAMLまたはテキスト形式を選びましょう。

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

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

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,総合出口
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,総合出口

pathはルールセットのローカルキャッシュ保存先です。異なるプロバイダーで同じパスを共有すると、更新時に互いのファイルを上書きする可能性があります。パスのあるディレクトリには書き込み権限が必要です。モバイル端末や制限されたデスクトップ環境では、通常クライアントが管理します。intervalは秒単位で更新間隔を指定します。ルールは頻繁に更新するほどよいとは限らず、短すぎる間隔は起動時の通信と配信元への負荷を増やします。業務の変化が少ない場合は、数分ごとに更新するより1日ごとの更新のほうが安定します。

ルールの数より順序が重要

カーネルは上から下へ照合します。プライベートネットワーク、LANドメイン、必ず直結する管理アドレスは前方に置きます。具体的な業務ルールは広範な地域ルールより前に配置し、ブロックルールはそれらを許可する可能性のある一般ルールより前に置いてください。MATCHは、それまでに一致しなかった接続だけを処理します。広範なドメイン集合を先頭に置くと、後続の具体的なルールが正しくても実行されません。

ドメインルールでは通常、先にIPを解決する必要がなく、照合のコストと結果も分かりやすくなります。IP系ルールはドメイン解決を発生させる場合があります。すでに宛先アドレスが明確な接続だけを確認するルールなら、カーネルの構文に従ってno-resolveを追加し、照合のためだけにDNS検索を行わないようにできます。ただし、すべてのIPルールへ機械的に追加してはいけません。接続がドメインだけを持ち、宛先IPに基づく判断が必要な場合、解決を禁止すると照合条件が失われます。インバウンドからアドレスを取得できるか、DNSモード、スニッフィングの状態に応じて判断してください。

ローカルルールセットの構造とテスト

YAMLルールセットでは通常、payloadがリストの入口になります。domain形式のファイルにはドメインパターンだけを保存し、classical形式のファイルには完全なルールを保存します。更新前に個別ファイルの構文を確認してから、メイン設定で参照してください。リモートルールセットのダウンロードは成功したのに一致しない場合は、4点を確認します。プロバイダー名がRULE-SETと一致しているか、behaviorが内容に対応しているか、より前の項目に先に捕捉されていないか、対象接続にドメイン情報が残っているかです。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,assets.example.com
  - PROCESS-NAME,example-client
  - IP-CIDR,192.0.2.0/24,no-resolve

ルールの取得元が無効になった場合、カーネルは既存のキャッシュを使い続けることもあれば、初回読み込みでキャッシュがなく、そのルールグループが欠落することもあります。重要なルールにはローカルの基準版を用意し、すべてのアクセス制御を1つのリモートURLに依存させないでください。購読URLの解析異常とルールセット形式のエラーは似た症状になり、どちらも更新失敗と表示される場合があります。HTTP応答、ファイル内容、キャッシュ、YAML構造を切り分けるには、購読失効と設定解析の復旧手順を参照してください。

保守しやすい命名と変更履歴を作る

プロバイダー名は取得元ではなく内容を表すようにし、work-domainやprivate-cidrのように命名してください。「ルール1」「最新ルール」のような、長期的に意味を理解できない名前は避けます。プロキシグループ名は画面の利用者向けなので日本語でも構いませんが、プロバイダー名やパス名は安定したASCII文字のほうが、プラットフォーム間のパス処理やスクリプトの差異を減らせます。リモートURL、behavior、形式を変更する場合は構造変更として扱い、古いキャッシュが新しいファイルの誤りを隠さないよう、対応するキャッシュを削除してからテストしてください。

ルールセットが大きくなったら、各集合の用途、データ種別、更新元、対象プロキシ、最後に手動検証した結果を記録することをおすすめします。重要なのはルール数ではなく、各層の役割が明確であることです。一致に異常があるときは、ログから最初に一致したルールを探し、該当集合の内容へ戻って確認するほうが、全体のモードを闇雲に変更するより効果的です。日本国内と海外の直結、プロキシ、ブロック、フォールバックを含む並び順は、ルール振り分け設定の実践で詳しく説明しています。

DNS設定の最適化と名前解決の振り分け

DNSはルールエンジンに見える情報を決める

DNS設定は単に名前解決サーバーを変更するだけではありません。ドメイン解決の経路、ルールでドメインを保持できるか、Fake-IPのマッピング、プロキシノードのサーバーアドレスをどう解決するかにも影響します。システムが最初にどのリスナーへドメインを渡すか、検索を直結またはプロキシ経由で行うか、実アドレスと予約アドレスのどちらを返すかによって、その後のルール動作は変わります。「ノードは利用可能なのにウェブページが開かない」「ブラウザーは正常なのにコマンドラインは失敗する」「同じドメインが何度も別のプロキシグループに一致する」といった場合は、DNSを独立した経路として確認してください。

nameserverは通常のドメイン検索を担当します。default-nameserverは主に暗号化DNSサーバー自身のドメインを解決したり、初回接続を確立したりするため、通常は直接到達できるIP形式のリゾルバーを指定します。proxy-server-nameserverはプロキシノードのサーバードメイン専用に使い、誤ったルールでノード名を解決するのを防げます。nameserver-policyはドメインごとにリゾルバーを指定します。対応フィールドはカーネルによって異なり、クライアント画面では一部しか設定できない場合があります。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query

  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver-policy:
    "geosite:private":
      - system

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "stun.*.*"

例はフィールド間の関係を示すもので、すべてのネットワークで同じパブリックリゾルバーを使うべきだという意味ではありません。リゾルバーを選ぶ前に、現在のネットワークから到達できるか、プライバシー要件を満たすかを確認してください。暗号化DNSのアドレス自体がドメインの場合、カーネルには初期解決経路が必要であり、それがdefault-nameserverの役割です。初期リゾルバーに到達できなければ、暗号化検索も開始できません。respect-rulesを有効にするとDNS接続もルールに従いますが、プロキシグループを選ぶためのDNS検索が、まだ完了していないDNS結果に依存する循環を避ける必要があります。

redir-hostとfake-ipの違い

redir-hostは実IPを返し、従来型DNSに近い動作をします。Fake-IPに対応しないプログラムとの互換性は高い一方、解決後にドメイン情報が宛先アドレスだけになり、TUNが取得した純粋なIP接続ではドメインルールに一致できない場合があります。fake-ipは予約アドレス範囲からマッピング用のアドレスを返し、アプリがそのアドレスへ接続するとカーネルが元のドメインを復元してルールを照合します。これにより、実際の解決結果がシステム経路へ先に漏れるのを抑え、TUN環境でもドメインルールを安定させられます。

Fake-IPはプロキシアドレスではなく、インターネット上へ直接現れるものでもありません。本機のカーネル内にあるマッピングテーブルで、特定のドメインを表すだけです。予約アドレスを取得したアプリは、接続をClashへ渡し続ける必要があります。システムルート、ルーター側のルール、セキュリティソフトがそのアドレス範囲を横取りすると、接続に失敗します。そのためFake-IPとTUNのルート取得はセットで検証し、DNS検索がアドレスを返したかだけを確認しないでください。

fake-ip-filterの適用範囲

LAN探索、プリンター、画面投影、時刻同期、一部の音声通話、STUNに依存するプログラムは、実アドレスや特殊なDNS応答を必要とする場合があります。そのようなドメインはfake-ip-filterへ追加し、Fake-IPマッピングを回避させます。フィルター範囲はできるだけ具体的にしてください。広すぎるワイルドカードを追加すると、多数のドメインが実際の名前解決へ戻り、ドメイン復元とルール照合の安定性が低下します。アプリに異常がある場合は、まずログやパケットキャプチャで実際の検索ドメインを特定し、最小限のルールを追加してください。説明できない長大なフィルター一覧をそのままコピーしないでください。

一部のカーネルは、ブラックリストまたはホワイトリスト形式のフィルターモードに対応しています。ブラックリストは、リスト内のドメインを実際の名前解決にする一般的な動作です。ホワイトリストでは、リスト内のドメインだけでFake-IPを有効にする場合があります。設定を移行する際はモードのフィールドも必ず移行してください。同じドメイン一覧でも、モードが違えば逆の結果になります。クライアント画面がスイッチしか提供しない場合は、エクスポートした最終設定で実際の値を確認しましょう。

IPv6、キャッシュ、ブラウザー独自DNS

ipv6: falseは通常、内蔵DNSがAAAAレコードを返さないことを示しますが、OS全体でIPv6を無効にする意味ではありません。システムが別のリゾルバーからIPv6アドレスを取得したり、アプリがキャッシュ済みアドレスへ直接接続したりする可能性があります。IPv6の出口が安定しない場合は、まずClash DNSでの返答を無効にし、システムのネットワークアダプターとブラウザー設定を個別に確認してください。IPv6が正常に使えるネットワークなら、IPv6用のルールも用意し、設計していないフォールバック経路へすべてのIPv6接続が流れないようにします。

ブラウザーは独自のセキュアDNSを有効にし、システムが指定したClash DNSを迂回することがあります。トラブル対処では、一時的にブラウザー独自の名前解決を無効にし、システムコマンドで指定したリスニングポートを検索して、OSとブラウザーのキャッシュを削除してください。設定変更後も古いアドレスが表示される場合、新設定が反映されていないとは限らず、単にキャッシュの有効期限が残っている可能性があります。カーネルを再起動して消えるのはカーネル側の一部状態だけで、OS、ブラウザー、アプリ内部のキャッシュは個別に処理する必要があります。

症状	優先して確認する項目	確認方法
ドメインルールに一致しない	DNSがカーネルを迂回していないか、宛先IPだけになっていないか	接続ログのHostとルール種別を確認する
Fake-IPは返るが接続できない	予約アドレス範囲がTUNに取得されているか	システムルートとTUNログを確認する
ノードのドメインを解決できない	初期リゾルバーとノード専用リゾルバー	ノードのサーバードメインを直接検索する
ブラウザーとコマンドラインの結果が異なる	ブラウザー独自DNSとアプリキャッシュ	独自名前解決を無効にして検索結果を比較する

TUNによる取得、Fake-IPマッピング、プラットフォームごとの境界

TUNとシステムプロキシは異なる範囲の問題を解決する

システムプロキシは、アプリがOSのプロキシ設定を自発的に読み取ることに依存し、通常はブラウザーやシステム設定に従うデスクトップアプリを対象にします。TUNは仮想ネットワークインターフェースを作り、システムルートを通して、TCP、UDP、プロキシ設定を読み取らないアプリのトラフィックもカーネルへ渡します。そのため、ゲーム、コマンドラインツール、ストアアプリ、常に直結するアプリがシステムプロキシでClashに入らなくても、必ずしもルールの問題ではありません。そもそもプロキシ入口を通っていない可能性があります。TUNは取得範囲を広げますが、同時にルーティング、権限、DNSの横取り、LANアクセスなどの変数も増やします。

TUNを有効にする前に、通常のシステムプロキシモードが使えることを確認してください。ノード、プロキシグループ、DNSの基準が未検証のままTUNを直接有効にすると、入口の問題とアウトバウンドの問題が重なります。推奨順序は、TUNを無効にしてノードを検証し、TUNを有効にしても複雑なルーティングはまだ変更せず、通常のウェブとコマンドライン接続がカーネルに入ることを確認してから、LAN、IPv6、アプリの除外、厳格なルーティングを段階的に処理することです。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

stack、auto-route、strict-route

stackはTUNパケットをどのネットワークスタックで処理するかを決めます。一般的な値にはシステムスタック、ユーザー空間スタック、混合モードがあります。システムスタックは互換性を確保しやすく、ユーザー空間スタックはカーネルで接続を一貫して処理しやすく、混合モードはTCPとUDPの両方でバランスを取ろうとします。OS、クライアントのパッケージ方法、アプリのプロトコルによって結果は異なり、すべての端末に共通する最適値はありません。UDP、LAN探索、特定アプリに異常がある場合、stackの切り替えは有効な比較テストになりますが、一度に変更するのはこの項目だけにしてください。

auto-routeはシステムルートを書き込み、対象トラフィックを仮想インターフェースへ送ります。auto-detect-interfaceは実際の出口となるネットワークアダプターを識別し、データが再びTUNへ戻るループを防ぎます。strict-routeは迂回経路をより厳密に制限し、システム検索や一部のトラフィックが取得を回避するのを抑えますが、複数NIC、仮想マシン、企業ネットワーク、LANサービスに影響する可能性もあります。有線、無線、VPN、コンテナブリッジを同時に使う場合は自動検出が出口を誤ることがあるため、ルートテーブルでデフォルトルートを確認してください。

DNS横取りとFake-IPアドレス範囲

dns-hijackは一般的な53番ポートの検索を内蔵DNSへ渡し、アプリの通常DNSリクエストを既定の解決経路へ入れます。アプリ内蔵の暗号化DNSを自動的に取得したり、他のセキュリティソフトに遮断されたリクエストを修復したりするものではありません。システム上で別のVPN、フィルタリングソフト、仮想NICツールも動作していると、複数のコンポーネントがDNSとデフォルトルートを奪い合う可能性があります。その場合は、まず取得コンポーネントを1つだけ残し、Clash単独で動作することを確認してから他のソフトを戻してください。

Fake-IPは通常、専用の予約ネットワーク範囲を使ってドメインマッピングを作ります。この範囲はTUNにルーティングされる必要があり、企業ネットワーク、検証環境、他の仮想ネットワークで実際に使うアドレス設計とも衝突させないでください。別のコンポーネントが同じ範囲を実在する内部ネットワークとして扱うと、アプリの接続が誤ったインターフェースへ送られます。Fake-IPの範囲を変更した後はDNSキャッシュとカーネルのマッピングを削除してください。古いアドレスが新しい対応関係を自動的に表すことはありません。

MTUと、接続は確立するのに転送が止まる問題

MTUが大きすぎると、経路上のフラグメントやパスMTU探索が妨げられ、ハンドシェイクは成功し少量のデータは送れるのに、大きなページ、アップロード、特定プロトコルが長時間停止することがあります。小さすぎるMTUはパケット数と処理負荷を増やします。既定値は多くのイーサネット環境をカバーしますが、モバイル回線、オーバーレイトンネル、一部のブロードバンド接続で異常が出る場合は、MTUを少しずつ下げて比較してください。最初から極端な値に設定しないでください。テストでは小さなリクエスト、大きな応答、アップロード、UDPを確認し、トップページが開くかだけで判断しないようにします。

一部のサイトだけ途中まで読み込んで止まる場合は、まずDNSとルールの問題を除外し、その後MTUを確認します。ログで接続が確立済みか、失敗が大きな応答に集中しているかを確認してください。システムコマンドの具体的な引数はプラットフォームによって異なりますが、原則は同じです。フラグメントを禁止してパケットサイズを段階的に変え、安定する上限を見つけてから、トンネルのヘッダー分を確保します。調整後は実際の業務を再テストし、1回の測定だけに依存しないでください。

Windows、macOS、Android、iOS、Linuxの違い

WindowsとmacOSでTUNを有効にするには、通常、管理者権限またはシステムネットワーク拡張の許可が必要です。権限が取り消されると、画面のスイッチは有効に見えてもルートが正常に書き込まれないことがあります。AndroidとiOSは通常、システムVPNインターフェースでトラフィックを取得し、同時に維持できる接続は1つだけの場合が多いです。バッテリー最適化、バックグラウンド制限、アプリ別プロキシ設定も対象範囲に影響します。LinuxではTUNデバイス、ルート書き込み権限、ファイアウォールルールを確認してください。サーバー環境では、リモート管理接続を誤ってプロキシへ送って切断しないよう注意が必要です。

クライアントの実装によって、アプリの除外、ルートの迂回、自動復旧を画面から設定できるかが決まります。クライアントはプラットフォームの能力を基準に選び、ダウンロード入口はダウンロードページで確認してください。全プラットフォームではClash Plusを優先候補とし、デスクトップでは用途に応じてClash Verge Rev、FlClash、Clash Nyanpasuも比較できます。開発が停止しているClash for WindowsとClashX Metaは旧環境との互換性を確認する際の参考にとどめ、新しいカーネル機能を得る目的で依存しないでください。

LAN、仮想マシン、コンテナへのアクセス

TUNを有効にした後は、通常、プライベートネットワークをルールの前方で直結し、実際のネットワークに応じたルートを保持します。GEOIP,LAN,DIRECTだけでは不十分な場合があります。トラフィックがルールエンジンへ入る前に、システムルートによって誤ったインターフェースへ送られる可能性があるためです。システムルート、TUNの除外ネットワーク、Clashルールを併せて確認してください。LANに複数のプライベートネットワークがある場合は、実際のネットワークを明示し、すべての端末が同じサブネットにあると仮定しないでください。

仮想マシン、コンテナ、WSL系環境には独立した仮想スイッチやDNSが存在する場合があります。ホストでTUNを有効にすると、サブシステムの通信がホストを経由することもあれば、独立したNATを通ることもあります。まずサブシステム内でデフォルトゲートウェイとDNSを確認し、ClashのリスニングアドレスをLANへ開放する必要があるか判断してください。allow-lanを有効にする場合は、ファイアウォールで信頼できるネットワーク範囲を制限し、プロキシポートを管理外のネットワークへ公開しないようにします。TUNを調査するときは、設定を誤っても復旧できるよう、そのルートを通らない管理経路を常に1つ残してください。

ドメインスニッフィングの役割、設定、誤判定の抑制

スニッフィングでドメイン情報を補う

一部の接続は、ドメインルールの照合に使えるホスト名を持たず、宛先IPだけをカーネルへ渡します。ドメインスニッフィングは、HTTPのHost、TLS ClientHelloのサーバー名、識別可能なQUICハンドシェイク情報からドメインを抽出し、ルール判断に利用します。これはDNS検索ではなく、HTTPSの内容を復号するものでもありません。接続確立時に本来見えているメタデータだけを読み取ります。TUN、透過プロキシ、アプリが先に名前解決した接続では、ドメインルールの一致率を高められます。

スニッフィングは強ければよいとは限りません。接続にドメインがない、プロトコルが特殊にカプセル化されている、アプリが暗号化されたクライアント挨拶を使う、宛先が純粋なIPサービスである場合、カーネルは名前を正確に復元できません。誤って宛先を上書きすると、正常な接続が一致しないドメインへ送られることもあります。プロトコルとポートを制限し、互換性が確認できないサービスには除外ルールを設定してください。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.com"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.example.com"

parse-pure-ipは、宛先が純粋なIPの接続に対してプロトコル解析を試みます。force-dns-mappingはDNSマッピングと連携し、以前にカーネルが処理したドメインの復元を助けます。override-destinationは、ドメインを取得できた後、スニッフィング結果を後続の宛先判断に利用または置き換える設定です。フィールドの詳細はカーネルの実装によって変わるため、インポート前にクライアントが最終的に生成した設定を確認してください。画面のスイッチと手書きの設定が同時に存在し、互いに上書きしないよう注意が必要です。

HTTP、TLS、QUICで見える範囲

平文HTTPでは通常、Hostリクエストヘッダーからドメインを取得できますが、必ずしも80番ポートだけで動作するわけではありません。一般的なプロキシポートや開発用ポートへ対象範囲を広げると内部サービスを識別しやすくなりますが、範囲が広いほど非HTTP通信を解析しようとする機会も増えます。TLSスニッフィングは主にハンドシェイクのサーバー名を読み取ります。アプリがIPを直接使う、サーバー名が隠されている、標準TLSではない場合は有効なドメインを取得できません。QUICはUDPを使うため、TUNとノード経路が該当するUDP通信に対応しているかも確認してください。

ポート一覧は実際の業務から決めてください。すべてのポートを各プロトコルに追加すれば対象が広がるように見えますが、実際には誤判定と処理コストが増えます。通常のウェブ通信では80、443と、明確に使う少数の代替ポートを優先します。データベース、リモートデスクトップ、ゲーム、音声プロトコルにドメインルールの要件がないなら、HTTPやTLSとして無理に解析しないでください。ログにスニッフィング失敗が継続して表示されても、接続へ影響するとは限りませんが、現在のポート範囲が広すぎる可能性を示します。

force-domainとskip-domain

force-domainは、優先的にスニッフィングを試すドメインパターンを指定します。DNSマッピングが不完全でもドメインで振り分ける必要があるサービスに適しています。skip-domainは、互換性がない、ドメイン結果が不安定、宛先を上書きすべきでない接続を除外します。ドメインパターンの構文は対象カーネルの要件に従って記述してください。一般的な+.example.comはルートドメインとサブドメインを含むことを示します。除外項目には実際の障害の根拠が必要です。見慣れないテンプレートから、本機のアプリに関係しない大量の名前をコピーしないでください。

あるアプリがスニッフィング有効時に失敗する場合は、まず無効にすると復旧するか比較し、その後、接続ログから抽出されたドメインを確認します。ログのドメインがアプリの実際の宛先と異なるなら、そのドメインや関連プロセスを除外範囲へ追加します。名前をまったく抽出できていないなら、DNS、ルール、IP振り分けへ戻って確認してください。強制ドメインを増やしても実際の情報は生まれません。スニッフィングは補助手段であり、正しいDNSの取得に代わるものではありません。

スニッフィングとルール順序の連携

スニッフィングが成功しても、ルールエンジンがドメインを取得できたことを示すだけで、期待したプロキシグループに一致するとは限りません。より前にあるIPルール、プロセスルール、広範なルールセットが先に一致する可能性があります。トラブル対処では「sniff success」だけを確認せず、ログに出る対象ドメイン、対象アドレス、一致したルール、プロキシグループを確認してください。ドメインルールを優先したい場合は、接続を先に捕捉する可能性のある一般的なIPルールより前に、具体的なドメインルールを置きます。

プロセスルールの利用可能性はプラットフォームによって大きく異なります。デスクトップではプロセス名やパスを識別できても、モバイルではシステム制限により同等の情報を取得できないことが多いです。すべてのドメインルールをプロセスルールで置き換えないでください。より安定する方法は、ドメインルールを中心にし、専用クライアントやドメインを安定して識別できない通信だけをプロセスルールで処理することです。プロセス名は更新で変わる場合があるため、ログで実際の名前を確認してください。

すべてのプロトコルを一度に有効にせず、段階的に有効化する

まずTLSの443番ポートだけを有効にし、普段使うウェブサイトとアプリで一致の変化を確認してください。異常がないことを確認してから、HTTPとQUICを追加します。プロトコルを1種類追加するごとに、直結、プロキシ、LAN、長時間接続をそれぞれテストします。QUICを有効にした後、一部のアプリだけが異常になる場合は、UDP転送を残したままQUICスニッフィングを一時的に無効にし、問題がプロトコル識別と転送経路のどちらにあるか切り分けてください。

ドメインスニッフィングが最も役立つのは、透過的な取得によってドメイン情報が失われた場合であり、すべての宛先を「推測」するためではありません。設定を明確にするほどトラブル対処は容易になります。長期運用では、各強制項目と除外項目の理由を記録し、再現できなくなった互換性設定を定期的に削除してください。あるサービスが大量のスニッフィング例外なしでは動作しないなら、DNSモード、Fake-IPフィルター、アプリ自身の名前解決を見直してください。根本原因は通常、スニッフィング一覧そのものではありません。

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

まずクライアントの統合レイヤーを確認する

複数購読の統合は通常Clash設定形式の共通フィールドではなく、クライアントが行います。クライアントには、基本設定、グローバル上書き、購読別上書き、JavaScriptスクリプト、ビジュアル統合ツールなどが用意されている場合があります。入口の実行順序は最終結果に影響します。後から実行された同名のスカラー値は通常前の値を上書きし、マッピングは再帰的に統合され、配列は全体置換、追加、名前による重複排除のいずれかになります。あるクライアントの統合動作を、すべてのクライアントにそのまま当てはめないでください。

開始前に、クライアントが最終的にカーネルへ渡す設定をエクスポートし、小さな実験を行います。購読には2つのプロキシグループを残し、上書き側で1つ追加して、最終配列が追加されるのか置き換わるのかを確認してください。動作を確認してから完全なルールを移行します。Clash Plusは全プラットフォーム向けの優先候補で、デスクトップではClash Verge Rev、FlClash、Clash Nyanpasuも異なる購読管理機能を提供します。具体的な入口は現在のクライアント画面を基準にしてください。クライアント間で移行する場合は、まず標準YAMLを移し、その後クライアント固有の統合ロジックを再構築します。

スカラー、マッピング、配列の処理の違い

mixed-port、mode、log-levelはスカラー値で、後の設定が通常そのまま置き換えます。dnsとtunはマッピングで、子フィールド単位で統合される場合があります。proxies、proxy-groups、rulesは配列で、意図しない結果が最も起きやすい項目です。統合ツールが配列全体を置き換える場合、ローカルルール3件だけの上書きによって、購読にあったルールがすべて消える可能性があります。追加方式の場合は、ローカルのフォールバックルールが購読側のMATCHの後ろに置かれ、実際には永遠に一致しない可能性があります。

そのため、ルール配列には「前置」「後置」「置換」の意味を明確に持たせる必要があります。LAN直結や業務の具体的なルールは前方に置き、最終的なMATCHは1つだけ末尾に維持します。プロキシグループ配列はnameで重複排除してください。同名で種別が異なるグループを単純に連結してはいけません。ノード配列も重複名を処理しないと、画面に一方しか表示されず、ルールが実際にどの対象を参照しているか分からなくなります。

# ローカル基本上書き：長期的に安定したスカラーとマッピングだけを置く
mode: rule
log-level: info
ipv6: true

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

dns:
  enable: true
  enhanced-mode: fake-ip

tun:
  auto-route: true
  auto-detect-interface: true

上の断片にはノード、プロキシグループ、ルール配列を含めていないため、再帰的なマッピング統合に対応するクライアントで購読へ重ねるのに適しています。クライアントがブロック全体を置き換える方式なら、統合プレビューでdnsの他の子フィールドが保持されるか確認してください。最も安全なのは推測ではなく、最終YAMLを確認することです。結果を表示できない統合ツールは、本番設定へ直接使うべきではありません。

複数購読ノードの命名と取得元の分離

2つの購読に同じノード名が含まれることがあります。直接統合すると、プロキシ選択、ヘルスチェック、永続化状態が誤ったノードを指す可能性があります。統合時に取得元を示す安定した接頭辞を付け、「メイン / ノード名」「予備 / ノード名」のように命名し、プロキシグループの参照も更新してください。接頭辞に購読タイトルによって変わる期限日や通信量の情報を含めないでください。更新のたびに新しいノードと見なされ、保存済みの選択が無効になるためです。

より明快な方法は、複数のproxy-providersを保持し、プロキシグループからuseで取得元を参照することです。すべてのノードを巨大な配列へ展開せずに済むため、更新間隔、ヘルスチェック、フィルターを個別に設定でき、特定の取得元を一時停止するのも簡単です。プロバイダーのパスは一意にし、リモートURLが無効になった場合は直近の正常なキャッシュを保持しつつ、画面には更新失敗を明確に表示してください。古いキャッシュを更新成功と誤認しないようにします。

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

  backup:
    type: http
    url: https://sub.example.com/backup.yaml
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: メイン購読
    type: select
    use:
      - primary
  - name: 予備購読
    type: fallback
    use:
      - backup
    url: https://www.gstatic.com/generate_204
    interval: 600

機密フィールドと設定の配布

購読URL、外部コントロールキー、ノード認証情報は、公開リポジトリ、スクリーンショット、オンライン整形ツールへコピーしないでください。複数人で管理する場合は、機密情報を含まないルールと上書きを分離して保存し、購読と認証情報はクライアント内に残します。端末間で同期する必要がある場合は、管理されたプライベートストレージを使い、同期範囲を制限してください。サンプル設定はフィールド構造だけを示すもので、実際の購読URLをコピーしてはいけません。

外部ルールとローカル上書きは分けて管理するのがおすすめです。ルールセットは「どの対象がどの分類に属するか」を担当し、ローカル設定は「その分類をどのプロキシへ送るか」を担当します。こうすれば購読やクライアントを変更しても、ルール資産を再利用できます。ノード、ルール、DNS、端末固有のパスを1つの巨大なファイルへ詰め込むと、どの更新でも競合の可能性が高まります。

更新後の自動チェックリスト

購読を更新するたびに、まずプロバイダーの状態とノード数が妥当かを確認します。次に最上位プロキシグループにメンバーが残っているか、選択状態が存在するノードを指しているか、ルールが参照するプロキシ名が完全かを確認してください。その後、DNS設定が購読によって上書きされていないか、TUNと外部コントロールAPIがローカルで期待する値を維持しているかを検証します。クライアントが設定前処理スクリプトに対応している場合、スクリプトが異常になったら部分的に統合されたファイルを出力せず、新設定の適用を停止すべきです。

複数購読の問題は、「更新後にノードがない」「プロキシグループが空になる」といった形で現れることがよくあります。購読内容が空とは限らず、フィルターの正規表現が全ノードを除外した、同名排除に失敗した、プロバイダーファイルの解析に失敗した、統合ツールが配列全体を置き換えた可能性もあります。元のレスポンス、単一購読の解析、統合前の構造、最終設定、カーネルへの読み込みという5段階で確認してください。具体的な復旧手順は購読失効と設定解析失敗を参照してください。

外部コントロールAPI、パネル接続、安全な公開範囲

コントロールAPIとプロキシポートは別のサービス

external-controllerは、実行状態、プロキシ切り替え、接続管理、ログ、設定の再読み込みなどを制御します。HTTPやSOCKSのプロキシポートではないため、アプリが通常のネットワーク通信をここ経由で転送することはできません。一般的なコントロールパネルはこのAPIからプロキシグループを読み取り、選択操作を送信します。クライアント自身が画面表示のために同じAPIを呼び出す場合もあります。コントロールAPIには実行状態を変更する権限があるため、信頼できるネットワークにだけ公開してください。

127.0.0.1でリッスンすると、本機のプログラムだけがアクセスでき、デスクトップクライアントやローカルパネルに適しています。0.0.0.0でリッスンすると利用可能なすべてのインターフェースにバインドされ、LAN内の端末からアクセスできる可能性があるため、強力なキーとファイアウォールによる送信元制限を同時に設定する必要があります。全インターフェースでリッスンするだけではリモート管理は完成しません。システムファイアウォール、ルート、リバースプロキシ、ブラウザーのオリジン制限も確認してください。リモートアクセスが不要なら、ローカルリッスンを維持します。

external-controller: 127.0.0.1:9090
secret: "change-this-secret"

# パネルファイルはクライアントまたはローカル環境で用意した場合のみ有効にする
external-ui: ./dashboard

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

サンプルのキーはフィールドの説明用です。導入時はローカルで予測困難な独立した値を生成してください。コントロールキーを購読URL、システムログインパスワード、他サービスの認証情報と共用しないでください。キーを変更したら、パネル側の接続設定も更新します。パネルが継続して未認証を返す場合は、まずリクエストに正しい認証情報が含まれているかを確認し、その後、起動時に別の設定がsecretを上書きしていないか確認してください。

外部パネルの接続手順

コントロールパネルには通常、APIのアドレスと認証キーが必要です。パネルはAPIからプロキシグループ、プロキシノード、現在の接続、ログを読み取り、利用者の操作に応じて切り替えや切断のリクエストを送信します。パネルページは開くのにデータが表示されない場合は、「静的ページの読み込み」と「API接続」を分けて確認してください。前者はパネルファイルやWebサービスに依存し、後者はAPIアドレス、認証、ブラウザーの同一オリジン制限、ネットワーク到達性に依存します。

パネルを本機に置き、APIも本機だけでリッスンしている場合は設定が簡単です。パネルが別の端末にあるとき、ブラウザーから見た127.0.0.1はClashが動作するホストではなく、ブラウザーのある端末を指します。これはよくあるアドレスの誤認です。その場合は、Clashホストの信頼できるLANアドレスを使い、ファイアウォールで送信元を制限してください。インターネットへAPIを公開するリスクは高いため、管理された安全なアクセス層を使い、ポートを直接開放しないでください。

よく使う状態確認と読み取り専用の観察

トラブル対処では、まず読み取り専用の情報を使い、コントロール画面が正しいカーネルへ接続しているか確認します。現在の設定モード、プロキシグループ一覧、カーネルログ、アクティブ接続を確認してください。複数のクライアントやカーネルが動いていると、ポートが占有され、パネルが古いインスタンスへ接続することがあります。プロセス、リッスンポート、ログの起動時刻で対象を確認しましょう。プロキシを切り替えた後は新しい接続がどの出口を使うかを観察します。既存接続がすべて自動移行するわけではないため、必要に応じて対象接続を閉じて再確立してください。

接続一覧から、アプリがカーネルへ入っているか、対象ドメインが復元されたか、どのルールに一致したか、実際のプロキシ経路が何かを判断できます。アプリが接続一覧にまったく現れない場合は、システムプロキシ、TUN、アプリの迂回設定、ファイアウォールを優先して確認します。表示されるがプロキシが誤っている場合は、ルール順序とプロキシグループを確認します。プロキシが正しいのに接続できない場合は、ノードと対象ネットワークを確認してください。この層別の順序は、ノードを何度も切り替えるより原因を特定しやすくします。

設定の再読み込みと実行時状態

API経由で設定を再読み込みする場合は、先に構文検証を完了してください。誤った設定は拒否されることもあれば、一部機能の再起動を引き起こすこともあります。プロキシ選択、Fake-IPマッピング、ルールセットキャッシュを保持するかどうかは、設定とカーネル状態によって決まります。profile.store-selectedはプロキシ選択の保存に、profile.store-fake-ipはマッピング状態の保存に使います。Fake-IP範囲の変更、キャッシュの削除、設定ディレクトリの移動を行う場合は、これらの状態が再構築されることを想定してください。

再読み込み後は、リッスンポート、コントロールアドレス、DNS、TUNが正常か確認します。コントロールAPI自身のアドレスを変更すると、現在のパネル接続が切れるため、新しいアドレスで再接続する必要があります。プロキシポートを変更した後も、システムプロキシが古いポートを指している可能性があります。TUNデバイス名やルート設定を変更した場合は、古いルートをクライアントが削除する必要が生じることもあります。完全再起動は時間がかかりますが、リスナー、仮想インターフェース、ルートが関係する場合は、連続したホットリロードより確実な状態を得やすくなります。

ログレベルとトラブル対処

silent、error、warning、info、debugは、それぞれ詳細度が異なります。日常利用ではinfoにしておくと、ルールセットの更新、リッスン失敗、接続エラーを見つけやすくなります。DNS、スニッフィング、ルール一致を調査するときだけ一時的にdebugへ変更し、問題を1回再現したら必要な部分を保存して通常レベルへ戻してください。ログには対象ドメイン、LANアドレス、ノード名が含まれる場合があるため、共有前に機密情報を削除します。

ログを読むときは、1つの接続を時系列で追います。まずインバウンド種別と送信元、次に対象ドメインまたはアドレス、一致ルール、プロキシ経路、実際のノード、最終エラーを確認してください。最後の「timeout」という1行だけでは原因を判断できないことが多いです。タイムアウトはDNS、ノードのハンドシェイク、プロキシから対象への接続、UDP転送、アプリの応答待ちなど、どの段階でも発生します。トラブル対処の分類と組み合わせれば、エラーが入口、名前解決、ルール、アウトバウンドのどこに属するかを先に絞り込めます。

安全に公開するための最小原則

コントロールAPIは必要なアドレスだけにバインドし、プロキシポートは必要な端末にだけ開放してください。allow-lanとコントロールAPIの公開は別々に判断します。LAN端末にプロキシの利用を許可しても、プロキシグループの切り替えや接続の閲覧まで許可する必要はありません。システムファイアウォールで送信元アドレスに基づいてコントロールポートを制限し、パネルとAPIには独立したキーを使います。信頼できるネットワークを離れたり公共ネットワークへ接続したりしたときは、リッスン設定がサービスを公開し続けていないか確認してください。

外部パネルのファイルは、確認済みのクライアントコンポーネントまたは管理された環境から提供し、パネル更新とカーネル更新は分けて行ってください。パネルの表示異常はプロキシコアの停止を意味せず、コアの接続が正常でもAPIが安全とは限りません。保守時は、カーネル設定、パネルのバージョンと取得元、リッスンアドレス、アクセス範囲を個別に記録し、すべての問題を「パネルに接続できない」とまとめないようにします。

再現可能な変更手順を作る

安定した上級設定では、現在正常な設定をエクスポートし、1つの機能領域だけを変更し、YAMLと参照を確認してテスト設定で起動します。その後、直結、プロキシ、DNS、TUN、コントロールAPIを検証してから正式設定へ置き換えてください。購読更新後も重要な確認を繰り返し、ロールバック用コピーを残します。初回の接続手順は利用ガイドに戻り、クライアントのインストーラーとプラットフォームの選択はダウンロードページで確認してください。

最終設定に、利用可能なフィールドをすべて含める必要はありません。プロキシグループは明確な判断意味を持つ階層だけにし、ルールセットは取得元と用途を説明できる集合だけにします。DNSとTUNは現在のネットワークで本当に必要な機能だけを有効にし、スニッフィングの例外には説明できる理由を持たせ、コントロールAPIは最小限の範囲で公開してください。入口から出口までのデータ経路を設定から明確に読み取れるほど、問題が起きたときログで原因を追いやすくなり、設定全体のリセットやテンプレート交換に頼らずに済みます。