Clash設定ファイルリファレンス

CHAPTER 01

YAML構造の概要

設定ファイルが読み込まれる仕組み

Clashの設定ファイルは本質的にYAMLドキュメントです。コアは起動時にまず構文を解析し、次に待受ポート、DNS、プロキシノード、プロキシグループ、ルールなどのトップレベル項目を読み込み、最後にローカルのプロキシ入口と通信のマッチングチェーンを構築します。構文解析に失敗すると、通常クライアントは利用可能な状態になりません。構文が正しくても項目間の関係に誤りがあると、起動はできるのに選択可能なノードがない、またはルールがマッチしないといった問題が起こります。そのため、設定のトラブルシューティングではファイルを開けるかだけでなく、YAML構文、項目名、オブジェクト参照、実行環境を順番に確認する必要があります。

よく使われるトップレベル項目には port、socks-port、mixed-port、mode、log-level、dns、proxies、proxy-groups、rules、proxy-providers、rule-providers があります。すべての設定に全項目を同時に記述する必要はありません。たとえば mixed-port だけを使う場合、HTTPポートとSOCKSポートを個別に設定する必要はありません。ノードをリモートプロバイダーから読み込む場合、proxies は空でも構いませんが、プロキシグループから use で対象プロバイダーを参照する必要があります。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - https://dns.alidns.com/dns-query

proxies:
  - name: Example-Trojan
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - MATCH,ノード選択

上の例は、最小構成で成立する一連の流れを示しています。ローカルアプリは 7890 ポートに接続し、DNSモジュールがドメイン名を解決し、proxies が出口を定義し、proxy-groups が出口を選択可能なポリシーとしてまとめ、rules が通信をどのポリシーへ渡すかを決めます。実際のサブスクにはより多くのノードとルールが含まれますが、関係は「入口—名前解決—出口—ポリシー—マッチング」のままです。この流れを理解しておけば、接続に失敗したときに問題の層を判断できます。

インデント、リスト、データ型

YAMLではインデントで階層を表します。半角スペース2個に統一し、Tabは使わないことをおすすめします。コロンの後にはスペースを1つ入れ、リスト項目はハイフンとスペースで始め、同じ階層の項目は同じインデントにそろえます。dns はマッピングオブジェクトで、内部の項目は1段深くします。nameserver はリストなので、各アドレスはさらに1段深くします。enable と nameserver のインデントを別の階層にずらすと、パーサーが直接エラーを出す場合もあれば、意図と異なる構造として解釈する場合もあります。

真偽値には true と false、ポートには整数、名前やアドレスには文字列を使います。コロン、シャープ、カンマを含む値や、真偽値と認識されやすい文字列には引用符を付けると安全です。たとえばパスワードにシャープが含まれる場合、引用符がないとシャープ以降がコメントとして扱われます。ノード名を on や off にすると、YAMLパーサーによって解釈が異なることがあります。サブスクURL、正規表現、複雑なパスワードにはシングルクォートを使い、エスケープ文字が必要な場合はダブルクォートを使うとよいでしょう。

名前の参照は完全一致が必要

プロキシグループとルールは、名前を使って他のオブジェクトを参照します。名前では全角・半角、スペース、大文字・小文字が区別されます。ノード名が「香港 01」なのに、プロキシグループで「香港01」と書けば別のオブジェクトです。ルールの末尾が「ノード選択」なのに、設定側には「プロキシ選択」しかなければ、参照先が存在しない状態になります。サブスクを変更するときは定義部分だけでなく、すべての参照箇所も同時に検索してください。同名ノードも避けるべきです。画面上では1つの名前しか表示されず、実際にどれが選択されたか判断しにくくなるためです。

YAMLではコメントを使えますが、コメントは項目の用途を説明するために使い、無効になった設定を大量に保存する用途には向きません。コメントアウトしたノードをプロキシグループが参照している場合があり、ノードを削除したのに参照を残すのもよくあるミスです。安全な管理方法は、ベース設定を1つ保存し、実験用の項目を別コピーに置き、読み込みに成功してから普段使いの設定へ移すことです。Clash Plus、Clash Verge Rev、FlClashなどのGUIクライアントでは、先にクライアント内で設定チェックを実行してから現在の設定に切り替えることもできます。クライアントの入口と対応プラットフォームはクライアントを入手で確認できます。

CHAPTER 02

共通項目、ポート、動作モード

ローカルの待受ポート

port はHTTPプロキシの入口、socks-port はSOCKS5の入口、mixed-port は同じポートでHTTPとSOCKSのリクエストを受け付けます。多くのデスクトップ環境では mixed-port だけを設定し、クライアントのシステムプロキシ機能でOSのプロキシアドレスをそのポートへ向ければ十分です。開発ツールがSOCKS5しか受け付けない場合は、socks-port を個別に有効にできます。複数の項目を同時に有効にする場合、ポート番号は重複させず、他のローカルプログラムが使用している番号も避けてください。

port: 7890
socks-port: 7891
mixed-port: 7892
redir-port: 7893
tproxy-port: 7894

redir-port と tproxy-port は主にLinuxのルーティング転送や透過プロキシで使います。通常のデスクトップアプリでシステムプロキシを設定するために必須の項目ではなく、設定に記述しただけでファイアウォールやルーティング規則が自動構成されることもありません。透過プロキシを使う場合は、システム側で通信転送、ポリシールーティング、権限を設定する必要があります。システムプロキシに従わないアプリもClashへ通したいなら、まずTUNモードを理解するとよいでしょう。原理と設定手順はClash TUNモードの有効化方法を参照してください。

LANからのアクセスと待受アドレス

allow-lan は、他のデバイスが現在の端末上のプロキシポートへ接続できるかどうかを決めます。false なら端末上のアプリはプロキシを使えますが、LAN内のスマートフォン、テレビ、別のPCはここをプロキシサーバーとして利用できません。true にする場合は、bind-address、OSのファイアウォール、ネットワークの種類も確認してください。信頼できるLANでのみ使う場合は、特定のプライベートアドレスに待受範囲を制限し、すべてのネットワークインターフェースで公開しないようにします。

allow-lan: true
bind-address: 192.168.1.20
authentication:
  - local-user:your-password

LANアクセスを有効にすると、同じネットワーク上のデバイスが待受ポートへ接続を試みられるため、ネットワーク名だけで安全性を判断してはいけません。公共ネットワーク、一時的なテザリング、共有寮ネットワークでは、allow-lan を無効にすることをおすすめします。共有が必要な場合は、認証項目を設定し、OSのファイアウォールで指定したサブネットだけを許可してください。リモート操作用インターフェースとプロキシ入口は別のサービスです。プロキシポートを公開したからといって、操作用インターフェースまでLANに公開する必要はありません。

Rule、Global、Directモード

mode: rule は rules を上から順に照合するモードで、日常利用で最も一般的です。global は通信をグローバルプロキシグループへ渡し、分岐ルールを1件ずつ実行しません。direct は直接接続します。GUIクライアントのモード切り替えは、実行中に設定ファイルの既定値を上書きすることがあります。そのため、ファイルが rule でも画面上はGlobalになっている場合があります。分岐の異常を調べるときは、設定項目とクライアントの現在状態を両方確認してください。

Globalモードは、問題の原因がルールにあるか短時間で確認する用途には向いていますが、整備されたルール設定の代わりにはなりません。Ruleモードではサイトにアクセスできず、Globalモードではアクセスできるなら、通常はドメインが誤ったポリシーへ渡されている、ルール順が不適切、または対象プロキシグループで利用できないノードが選択されています。Directモードは、ローカルネットワーク自体に到達できるかを確認するのに適しています。Directでも失敗するなら、プロキシノードを何度も変更する前に、ネットワーク、DNS、対象サービスを確認してください。

ログ、IPv6、操作用インターフェース

log-level でよく使う値は silent、error、warning、info、debug です。通常利用では info で十分です。設定の読み込み、DNS検索、接続ハンドシェイクを調べるときだけ、一時的に debug へ変更できます。ログにはアクセス先ドメイン、ノード名、ローカル接続情報が含まれることがあるため、トラブルシューティング用のスクリーンショットを共有する前に内容を確認してください。問題が解決したら通常のレベルに戻し、不要な出力を減らします。

ipv6 は単純に「ネットワークを高速化する」スイッチではありません。利用地域のネットワークが安定したIPv6に対応していないのに、DNSがAAAAレコードを返すと、到達できないアドレスを先に試すことがあります。一方でIPv6を完全に無効にすると、IPv6専用環境に影響する可能性があります。実際のネットワーク能力に応じて決め、トップレベルの ipv6、DNSモジュール、TUN設定の整合性を保ってください。同じドメインが接続できたりできなかったりする場合は、IPv4のみを返す場合とIPv6も返す場合を分けてテストし、アドレスファミリーの違いを確認します。

external-controller はGUIや外部パネルに操作用インターフェースを提供します。デスクトップクライアントではこの項目を自動管理することが多く、手動で公開する必要はありません。自分で設定する場合は、127.0.0.1:9090 のようなループバックアドレスで待ち受け、操作用キーを設定してください。0.0.0.0:9090 にすると他のネットワークインターフェースからアクセスできるため、リモート管理が明確に必要でアクセス制限を設定済みの場合だけ使用します。external-ui は静的パネルファイルのディレクトリにすぎず、画面を自動でダウンロードまたは更新するものではありません。

external-controller: 127.0.0.1:9090
secret: your-control-secret
external-ui: dashboard

共通項目は「最小限の動作構成」から追加してください。まず混合ポート1つ、Ruleモード、基本ログが動くことを確認し、その後にLANアクセス、TUN、操作用インターフェース、高度なネットワーク項目を少しずつ有効にします。一度に大量の項目を追加すると、ファイルは完全に見えてもエラーの原因を特定しにくくなります。Clashの各派生版では高度な項目の対応範囲が異なる場合があります。GUIクライアントでは、搭載コアと設定チェックの結果を基準にしてください。

CHAPTER 03

DNS設定と名前解決の流れ

DNSモジュールが解決する問題

アプリがドメインへアクセスするときは、まず接続先アドレスを取得してから接続を確立します。ドメイン解決がClashを迂回し、接続だけがプロキシに入ると、名前解決の結果とプロキシ出口が一致しない、汚染された結果を直接使う、ルールが元のドメインを取得できないといった問題が起こります。ClashのDNSモジュールは端末からの問い合わせを受け、指定した上流DNSで解決できます。Fake-IPモードでは仮想アドレスとドメインの対応を作り、後続の通信をドメインルールで判定できるようにします。

dns.enable はモジュールの有効・無効、listen は待受アドレス、nameserver は主要な上流DNS、fallback は別の名前解決元を指定します。デスクトップクライアントはTUNやシステム設定を通じて、問い合わせを内蔵DNSへ自動的に向けることがあります。設定に listen: 127.0.0.1:1053 と書いただけでは、OSのDNS設定は自動変更されません。通常のシステム問い合わせがルーターへ送られている場合は、クライアントのDNS引き継ぎ設定を確認してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  nameserver:
    - 223.5.5.5
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com
    - time.*.com

Fake-IPとRedir-Host

enhanced-mode: fake-ip は、予約済みアドレス範囲の仮想IPをアプリへ返し、そのIPに対応する元のドメインを記録します。アプリがこの仮想IPへ接続すると、Clashがドメインを復元してルールを照合します。この方式はドメイン情報を保持しやすく、アプリが先に独自解決して接続することによる分岐のずれも減らせます。fake-ip-range には専用の予約アドレス範囲を使い、家庭LAN、社内ネットワーク、実在するパブリックIP範囲へ勝手に変更しないでください。既存のルーティングと衝突する可能性があります。

一部のLANサービス、ゲーム機のデバイス検出、プリンター、時刻同期、実アドレスを必要とするアプリはFake-IPに適さないため、fake-ip-filter で除外できます。フィルター項目は多ければよいわけではありません。範囲が広すぎると多くのドメインが実際の名前解決へ戻り、Fake-IPによるドメイン識別の利点が弱まります。あるアプリでWebページは開けるのにローカルデバイスを検出できない場合は、すべてのドメインを除外するのではなく、そのアプリが使うLANドメインから確認してください。

redir-host は実際の名前解決結果を返すため、従来のDNSに近い互換性がありますが、複雑な透過プロキシ環境では元のドメインを保持しにくい場合があります。どちらを選ぶかは、クライアント、OS、ネットワークの引き継ぎ方式によって決まります。一般的なデスクトップ・モバイルのGUIクライアントでは、まず既定モードを使ってください。明確な互換性問題がある場合だけ変更します。拡張モードを切り替えた後も、古いDNSキャッシュや接続が残ることがあります。テスト前にクライアントのDNSモジュールを再起動し、必要に応じてシステムキャッシュを消去して対象アプリを再起動してください。

Nameserver、Fallback、ブートストラップ解決

nameserver には通常のUDP DNSアドレスだけでなく、DoHアドレスも指定できます。通常のアドレスは設定が簡単ですが、問い合わせ経路はローカルネットワークに左右されます。DoHはHTTPSで通信するため、まずDoHサーバー自身のドメインを解決する必要があり、ブートストラップ解決が発生します。対応コアでは default-nameserver にIPアドレスのDNSを指定し、暗号化DNSのホスト名を解決できます。このリストにはIPアドレスを記述し、さらにドメイン解決が必要なDoH URLを入れないでください。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

proxy-server-nameserver はプロキシサーバーのアドレスを解決するために使います。ノードの server がドメイン名の場合、そのドメインのIPを先に取得しなければプロキシ接続を確立できません。まだ確立していないプロキシ経路に解決を依存すると循環が発生します。プロキシサーバー用に直接アクセスできるDNSを用意すれば、「ノードアドレスの解決」と「通常ドメインのプロキシ」を分離できます。サブスク内のノードがすべてIPアドレスなら、この項目の影響は小さくなります。

fallback は、すべての問い合わせを単純に第2グループへ同時送信するものではありません。具体的な選択ロジックは、コアの実装やフィルター項目の影響を受けます。fallback-filter では、地理データベース、IP範囲、ドメインなどに基づいて結果を選べますが、複雑にしすぎるとトラブルシューティングの負担が増えます。基本設定では、まず安定した nameserver が動作することを確認し、その後でfallbackを検討してください。すべてのDNSへ到達できないなら、数を増やしてもネットワーク経路の問題は解決しません。

DNSトラブルシューティングの順序

トラブルシューティングでは、まず問い合わせがClashに入っているか、次にClashが上流DNSへアクセスできるか、最後に応答結果がルールと接続でどう使われているかを確認します。ログに対象ドメインのDNS問い合わせがまったくないなら、OSやアプリが別の解決経路を使っている可能性があります。問い合わせはあるのにタイムアウトが続く場合は、上流アドレス、ネットワーク、ファイアウォール、プロキシ依存を確認します。問い合わせに成功してもアクセスできない場合は、ルールのマッチ、ポリシー選択、対象アドレスファミリーを調べます。すべての接続問題をDNSのせいにしたり、経路を確認せず頻繁にDNSを変更したりしないでください。

ブラウザーが独自のセキュアDNSを有効にしている場合や、モバイルOSがプライベートDNSを使っている場合、問い合わせ経路が変わります。TUNによる引き継ぎはより多くの通信をカバーできますが、OSの権限やルーティングの衝突には対処が必要です。ノードのタイムアウト、ドメインの断続的な失敗、システムプロキシ状態の混在が見られる場合は、サブスクからDNSまでのトラブルシューティング手順に沿って層ごとに確認してください。DNS設定の目的は上流アドレスを増やすことではなく、解決経路を明確で再現可能にすることです。

CHAPTER 04

プロキシノードの項目

すべてのノードに共通する基本関係

proxies はノードオブジェクトのリストです。各オブジェクトには少なくとも、名前、プロトコル種別、サーバーアドレス、ポート、そのプロトコルが要求する認証項目が必要です。name はプロキシグループや画面から参照する名前、type は後続項目の解釈方法、server はIPまたはドメイン、port はサーバー側の待受と一致する番号です。ノード情報は通常サブスクから提供されるため、経験だけで別プロトコルの項目をコピーしないでください。

ノードがYAMLチェックを通過しても、項目構造を読み取れるというだけで、実際にサーバーへ到達できるとは限りません。サーバーアドレスの誤り、閉じたポート、認証不一致、システム時刻のずれ、TLSホスト名の不一致、ローカルネットワークによる遮断などで接続に失敗します。まず元のサブスクが有効かを確認し、次にクライアントログで失敗した段階を確認してください。異なるプロトコルのノードが複数同時にタイムアウトするなら、サブスク、DNS、ローカルネットワーク、システムプロキシの問題である可能性が高く、各ノードが偶然同時に無効になったとは考えにくいでしょう。

ShadowsocksとTrojanの例

proxies:
  - name: Example-SS
    type: ss
    server: ss.example.net
    port: 8388
    cipher: aes-128-gcm
    password: your-password
    udp: true

  - name: Example-Trojan
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net
    skip-cert-verify: false
    udp: true

Shadowsocksの cipher はサーバー側と一致させる必要があり、クライアントの対応一覧だけを見て変更してはいけません。password は文字列として扱い、特殊文字を含む場合は引用符を付けます。udp はそのノードでUDPを扱えることを示しますが、実際に使えるかはサーバー、ネットワーク経路、クライアントの動作モードにも左右されます。システムプロキシだけでは、多くのUDP通信は自然にプロキシへ入りません。UDPの引き継ぎが問題になるのは、TUNや透過プロキシ環境が中心です。

Trojanは通常TLSで接続し、sni はハンドシェイクで指定するサーバー名です。ノードの server がIPで、証明書がドメイン名に発行されている場合、正しいSNIが特に重要です。skip-cert-verify: true は証明書検証を無効にするため、一般的な修正方法として使わないでください。有効にすると接続できる場合でも、サーバー名、システム時刻、証明書チェーン、サブスク項目を確認し続ける必要があります。検証を有効に保つことで、ハンドシェイク先と証明書の身元が一致しない問題を発見できます。

VMessとVLESSのトランスポート項目

proxies:
  - name: Example-VMess
    type: vmess
    server: vmess.example.net
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    alterId: 0
    cipher: auto
    tls: true
    servername: vmess.example.net
    network: ws
    ws-opts:
      path: /proxy
      headers:
        Host: vmess.example.net

  - name: Example-VLESS
    type: vless
    server: vless.example.net
    port: 443
    uuid: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
    network: tcp
    tls: true
    servername: vless.example.net
    udp: true

VMessとVLESSはどちらもUUIDを使いますが、同じプロトコルではありません。WebSocket転送では network、パス、Hostも確認してください。サーバーが特定のパスを要求している場合、スラッシュ1つの違いや大文字・小文字の違いだけでハンドシェイクに失敗します。TLS項目の名前は設定形式やコアの派生版によって異なる場合があります。サブスクが生成した構造を優先して保持し、「形式を統一する」ために一括改名しないでください。設定チェックで未知の項目は検出できても、リモートのリバースプロキシが同じパスへ転送することまでは検証できません。

ノードがgRPC、HTTP/2、Realityなどの拡張トランスポートを使う場合、サービス名、公開鍵、短いID、フロー制御項目などが追加されます。これらはサーバー設定から一式で取得する必要があります。1項目でも欠けると、構文チェックには通ってもハンドシェイクを完了できないことがあります。ノードを手動移行する際は、server、port、UUIDの3項目だけでなく、完全なオブジェクトとして移行してください。拡張プロトコルへの対応はコアによって変わるため、GUIクライアントではサブスクの要件に合うコアを選びます。

DIRECT、REJECT、組み込みの出口

DIRECT と REJECT はよく使う組み込みポリシーで、proxies に宣言する必要はありません。DIRECTは通信を直接接続し、REJECTは接続を拒否します。プロキシグループの proxies リストに入れることも、ルール末尾に直接書くこともできます。利用時は、サブスク内のカスタムノードが同じ名前を使っていないか確認してください。DIRECTという名前の通常プロキシノードを作ると、読み取りやトラブルシューティングで混乱します。

設定によっては、COMPATIBLE、DROP、DNS関連の組み込みタイプを使うこともあります。対応状況は現在のコアを基準にしてください。Clash Plus、Clash Verge Rev、FlClashなどのクライアント間で設定を移行するなら、ベースファイルでは一般的な項目を優先し、特定コア向けの拡張は独立した上書きに分けると安全です。モバイルとデスクトップではシステム引き継ぎの方式が異なりますが、ノードオブジェクト自体はできるだけ共通化し、差異は主にポート、TUN、DNSの待受、画面設定に置きます。

ノード障害を層別に判断する

遅延テストの失敗は、すべての業務通信が失敗したことを意味しません。遅延テストのURLも実際のアクセス先とは異なります。まず、DNS解決の失敗、TCP接続のタイムアウト、TLSハンドシェイクエラー、認証拒否のどれかを確認してください。解決失敗なら server とプロキシサーバーDNS、接続タイムアウトならネットワークとポート、TLSエラーならSNI、システム時刻、証明書、認証失敗ならサブスク情報を確認します。問題を示すログや現在の項目を失わないよう、いきなりクライアント設定全体を削除しないでください。

手動ノードはテストや項目の理解に向いていますが、長期的なノード一覧はプロキシプロバイダーで管理する方が適しています。サブスク更新でノードの追加・削除を統一できますが、ローカルのプロキシグループとルールは安定して参照できるようにする必要があります。次の章ではノードをプロキシグループへ入れる方法、第7章では proxy-providers でリモートノードを読み込む方法を説明します。初回読み込み後のノード選択や確認方法が分からない場合は、先に初回接続ガイドをお読みください。

CHAPTER 05

プロキシグループの項目と選択ロジック

プロキシグループはルールとノードの中間層

proxy-groups は、複数のプロキシノード、他のプロキシグループ、組み込みの出口を、参照可能な1つの名前にまとめます。ルールは通常、特定のノードではなく「ノード選択」「自動選択」「ストリーミング」などのプロキシグループを参照します。ノードが変わってもルールを1件ずつ変更する必要がなく、グループのメンバーや現在の選択だけを調整できます。プロキシグループは入れ子にできますが、AがBを含み、BがAを含むような循環参照は避けてください。

よく使うタイプは select、url-test、fallback、load-balance です。Selectはユーザーがメンバーを明示的に選択します。URL-Testは定期的にテストし、条件に合うメンバーを選びます。Fallbackは順番に利用可能なメンバーを探します。Load-Balanceは複数メンバーへ接続を分散します。タイプごとに解決する問題が異なり、「自動」だから必ず速いとは限りません。遅延テストが示すのはテスト先とその時点のネットワークであり、実際のサービスは別経路を通ることがあります。

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - Example-Trojan
      - Example-SS
      - DIRECT

  - name: 自動選択
    type: url-test
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: フェイルオーバー
    type: fallback
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

Selectと自動テストグループ

select の利点は結果が明確なことです。画面でノードを選ぶと、その選択が維持されるため、固定出口、ログイン状態、特定地域が必要なサービスに適しています。欠点はノードが無効になっても自動で切り替わらず、手動選択が必要なことです。自動テストグループをSelectの最初のメンバーにすれば、自動と手動の入口を両立できます。普段は「自動選択」を使い、固定回線が必要なときだけ特定ノードへ切り替えます。

url-test は url を使って到達性をテストし、interval が周期を、tolerance が遅延の近いノード間で頻繁に切り替えないための許容差を制御します。間隔が短すぎると継続的なリクエストが発生し、画面上の選択も変わり続けることがあります。長すぎると障害をすぐに検出できません。テストURLには、ログイン不要で安定した簡単な応答を返すものを使い、ログイン必須、複雑なリダイレクト、ローカルネットワークで遮断されやすいページは避けてください。テスト成功は、そのノードがテスト先へ到達できることだけを示します。

fallback はメンバーの順番を重視します。通常は最初の利用可能なメンバーを使い、失敗したら後続へ切り替えるため、主回線と予備回線が明確な構成に適しています。URL-Testとの違いはテストの有無ではなく選択原則です。URL-Testはテスト結果を重視し、Fallbackは順番と利用可能性を重視します。安定したセッションが必要な場合、ノード間の頻繁な切り替えでログイン状態や送信元アドレスが変わる可能性があるため、最低遅延を追求するより主系・待機系の方が適しています。

負荷分散とセッションの一貫性

load-balance は複数ノードへ異なる接続を分散できますが、1つのダウンロードの帯域を単純に合算するものではありません。1つのWebページが複数の接続を作る場合、それぞれが異なる出口から送信されることがあります。対象サービスが同じ送信元アドレスでのセッション維持を要求すると、出口の分散によって認証画面、ログイン失効、リクエスト拒否が起こる可能性があります。対応コアでは一貫性ハッシュなどを使って同じ宛先を同じメンバーへ割り当てられる場合がありますが、実際のサービスで検証してください。

  - name: 均衡出口
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

負荷分散は、複数の独立した宛先や接続を扱う場合に適しており、すべてのルールの既定出口にするのはおすすめしません。設定前に、各メンバーが単独で動作し、地域、アクセス権、プロトコル能力が近いことを確認してください。特性の大きく異なるノードを同じグループに入れると、同じサービスの挙動を再現しにくくなります。ノード障害時の自動切り替えが目的なら、通常はFallbackの方が適しています。

ノード名でメンバーを絞り込む

proxy-providers を使う場合、プロキシグループは use でプロバイダー全体を取り込み、filter または exclude-filter で名前を絞り込めます。フィルターには通常、正規表現を使うため、まずサブスク内の実際の命名を確認してください。特定の記号や固定プレフィックスに依存しすぎると、サブスク側の名称変更でグループが突然空になることがあります。まず簡単なキーワードから始め、重要なグループには手動選択できる入口を残すと安全です。

proxy-groups:
  - name: 香港ノード
    type: select
    use:
      - remote-nodes
    filter: '(?i)香港|HK|Hong Kong'

  - name: ノード選択
    type: select
    proxies:
      - 香港ノード
      - DIRECT
    use:
      - remote-nodes

正規表現の括弧、縦線、特殊文字は引用符内に置いてください。絞り込み結果が空の場合は、まずプロバイダーが正常に読み込まれたか、次に名前が一致しているかを確認し、すぐに「サブスクにノードがない」と判断しないでください。クライアント画面にプロバイダーの元ノード一覧が表示されるなら、1〜2個の名前をコピーして最小構成でテストできます。名前による絞り込みは管理手段であり、ノード品質の判断材料ではありません。「高速」「専用回線」といった名前だけで回線状態は証明できません。

プロキシグループ階層の管理原則

ルールの最上位では、「ノード選択」「直接接続サービス」「ブロックルール」のような少数の安定したポリシーを参照するのが適しています。地域グループ、自動グループ、個別ノードはその下に置きます。階層が深すぎると画面での選択経路が複雑になり、ルールがマッチした後の最終出口も追跡しにくくなります。通常は「サービス方針—地域方針—ノード」の2〜3層で十分です。階層を増やすたびに、それがどの選択問題を解決するのか説明できるようにしてください。

プロキシグループを変更したら、3方向を確認してください。すべてのメンバーが存在するか、ルールが参照するポリシーが存在するか、ポリシー間で循環していないかです。サブスク更新で、手動グループが参照していた特定ノードが削除されることもあります。そのため長期設定では、リモートノード名を個別にコピーするより、プロバイダーとフィルターで参照する方が適しています。クライアントにグループは表示されるのに展開できない場合は、まず空グループ、参照ミス、プロバイダーの読み込み状態を確認してください。

CHAPTER 06

ルール構文とマッチ順

ルールは上から順に実行される

rules は順序付きリストです。各接続は1番目から確認され、最初にマッチした時点で停止し、後続ルールは見ません。したがって、ルールの種類が正しくても順番が間違っていれば結果は意図から外れます。範囲が具体的なルールを前に、広いルールを後ろに置き、MATCH は最後のフォールバックとして末尾に置きます。MATCHを途中に置くと、後続ルールは実行されません。

rules:
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.com,ノード選択
  - DOMAIN-KEYWORD,example,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

通常のルールは、ルールタイプ、マッチ対象、送信先ポリシーで構成され、半角カンマで区切ります。ポリシー名は proxy-groups で定義した名前または組み込みポリシーと一致させる必要があります。全角カンマ、末尾の余分なスペース、名前の綴り違いで、ルールが意図どおり読み込まれないことがあります。ルール値自体にカンマが含まれる場合は、そのルールタイプが適切なエスケープに対応しているか確認し、複雑な文字列を通常の3要素形式へそのまま入れないでください。

ドメインルールの違い

DOMAIN は完全なドメイン名を正確に照合します。たとえば DOMAIN,api.example.com はそのホストだけにマッチし、www.example.com には自動的にマッチしません。DOMAIN-SUFFIX はドメインのサフィックスにマッチし、親ドメインとサブドメインをまとめて対象にできます。DOMAIN-KEYWORD はキーワードで照合するため範囲が最も広く、誤って別のドメインに適用されやすい方式です。ドメインの境界を特定できる場合はDOMAINまたはDOMAIN-SUFFIXを優先し、対象ドメインが分散していて安定したキーワードがある場合だけキーワードルールを検討してください。

ドメインルールが利用できるかは、接続時にコアがドメイン名を取得できるかに左右されます。アプリが直接IPへ接続する場合や、DNS問い合わせが完全にClashを迂回する場合、DOMAIN系ルールにはマッチ対象がないことがあります。Fake-IP、TUNのスニッフィング、システムプロキシはドメイン保持に役立つ場合がありますが、経路はそれぞれ異なります。ドメインルールがマッチしないときは、まず接続ログにドメインとIPのどちらが表示されているかを確認し、その後DNS、スニッフィング、ルール自体を調べてください。

ルールの対象範囲は、サービスの境界から設計してください。範囲が広すぎるトップレベルのサフィックスをプロキシへ送ると、無関係なサービスの出口まで変わる可能性があります。ログイン用ドメインを1つだけ指定すると、静的リソース、API、コンテンツ用ドメインを取りこぼすことがあります。接続ログで1回の操作に関係するドメインを確認し、同じポリシーが必要なドメインをルールへ追加してください。ブラウザーのアドレスバーだけで全リクエストを推測しないでください。

IP、サブネット、no-resolve

IP-CIDR はIPv4サブネット、IP-CIDR6 はIPv6サブネットにマッチします。CIDR後の数字はネットワークプレフィックス長を示します。たとえば 192.168.0.0/16 は一般的なプライベートアドレス範囲の1つをカバーします。IPルールはLAN、固定サーバー、データベースが提供するアドレス範囲に適していますが、動的アドレスやCDNを使うサービスでは、個別のIPがすぐ変わる可能性があります。

no-resolve は、このIPルールを実行するときにIP取得のための追加解決を自動的に行わないことを示します。LANサブネットや、すでにIP形式で確立された接続では、不要なDNS問い合わせを避けられます。すべてのIPルールに必須の飾りではありません。前段のマッチ処理でドメイン解決が必要な場合は、追加したときの影響を理解してください。トラブルシューティングでは、ログで元のIP、解決結果、Fake-IPのどれがルールに渡っているか確認できます。

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,ノード選択

LANへの直接接続ルールは、通常のプロキシルールより前に置き、プリンター、ルーター、社内サービスがリモートノードへ送られないようにします。ただし社内ネットワークでは、一般的なプライベートネットワークと重なる複雑なルーティングが使われることがあります。TUN環境では実際のルーティングテーブルも関係します。内部アドレスへ接続できない場合は、ルールだけでなく、OSが対象サブネットをローカルインターフェースへ正しくルーティングしているかも確認してください。Clashは受け取った接続を処理できますが、基盤ネットワークにない経路を代替することはできません。

GEOIP、ルールセット、データベース

GEOIP はローカルのアドレスデータベースに基づいて、IPの所属地域を判定します。精度はデータベースの内容と更新状態に左右され、すべてのアドレスが永久に同じ地域だとは限りません。サービスの移転、CDNノードの変更、データベースの遅れによって分類が変わることがあります。重要なサービスがGEOIPで誤ったポリシーへ分類された場合は、広範な地理ルールが偶然直るのを待つのではなく、より具体的なドメインまたはIPルールを追加してください。

大規模なルールデータベースは rule-providers で管理し、RULE-SET から参照するのが適しています。メイン設定にはルールセットの順序と送信先ポリシーだけを残し、具体的な項目はプロバイダーで更新できます。複数のルールセットには重複があり得るため、最終結果はメイン設定での参照順に従います。広告ブロック、直接接続、プロキシ用ドメインに同じ対象が含まれる場合、先に置いたセットが結果を決めます。

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,direct-domain,DIRECT
  - RULE-SET,proxy-domain,ノード選択
  - RULE-SET,private-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ルールがマッチしないときの確認

まず接続ログで対象リクエストを見つけ、表示されたドメインまたはIP、マッチしたルール、最終ポリシーを記録します。範囲が広すぎる前段ルールにマッチしているなら、順番を変えるか範囲を狭めます。すぐMATCHへ落ちるなら、ルール内容がログの対象と一致しているか確認します。正しいポリシーにマッチしているのに誤ったノードを使うなら、問題はルールではなくプロキシグループの現在の選択です。この3層を分けると、ルールを何度も変更しても出口が変わらないという状況を避けられます。

ルールをテストするときは、一度に1つの条件だけ変更し、変更後に現在の設定が再読み込みされたことを確認してください。ブラウザーの接続再利用、DNSキャッシュ、アプリのバックグラウンドプロセスが古い接続を使い続けることがあるため、必要ならアプリを終了して再試行します。ルールは読みやすく設計し、具体的な例外を前、ルールセットを中央、地域ルールと最終フォールバックを後ろに置き、特殊項目の理由を短いコメントで説明します。説明のない一時ルールを大量に追加すると、後の保守が難しくなります。

CHAPTER 07

サブスク、プロキシプロバイダー、ルールプロバイダー

ローカルノードとリモートプロバイダーの違い

ノードを proxies に直接記述する方法は、少数の固定ノードや一時的なテストに適しています。一方、proxy-providers を使うと、リモートURLからノード一覧を定期的に更新し、プロキシグループから use で参照できます。プロバイダーは「ノードデータの更新方法」と「ノードをポリシーへ参加させる方法」を分離します。リモート内容が変わっても、メイン設定のポリシー名やルールを変更せずに済みます。

プロバイダーは、完全な設定サブスクと同義ではありません。サブスクURLによってはポート、DNS、プロキシグループ、ルールを含むClash設定全体を返しますが、proxy-providers は通常ノード集合形式を要求します。完全設定のURLをそのままproviderへ入れると、構造が合わず読み込みに失敗することがあります。クライアントの通常サブスク取り込みと、設定内部のプロキシプロバイダーは別の層です。まずサーバーが提供するファイル形式を確認してください。

proxy-providers:
  remote-nodes:
    type: http
    url: https://config.example.net/nodes.yaml
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: ノード選択
    type: select
    use:
      - remote-nodes
    proxies:
      - DIRECT

type: http はリモートURLから取得すること、url はサブスクアドレス、path はローカルキャッシュの場所、interval は更新間隔を示します。キャッシュがあれば、リモートURLへ一時的にアクセスできない場合も、前回成功した内容を読み込めます。パスはクライアントが書き込める設定ディレクトリ内に置き、追加のシステム権限が必要な場所を指定しないでください。複数のプロバイダーで同じキャッシュファイルを共有すると、更新時に互いの内容を上書きします。

サブスクURLには通常アクセス権があるため、公開ログ、スクリーンショット、サンプルファイルへ記載しないでください。この記事の例では実サービスに使えないサンプルドメインを使用しています。サブスクの読み込みに失敗したら、HTTPステータス、TLSエラー、応答形式、ローカルファイルの書き込み権限を確認します。プロキシグループが空かどうかだけを見てはいけません。リモートリクエストが成功しても、内容が想定したYAMLでなければ解析に失敗します。

ヘルスチェックとポリシーのテスト

health-check は、プロバイダー内のノードが指定URLへアクセスできるかを定期的に確認します。プロキシグループのURL-Testと関係はありますが、同じ層の機能ではありません。プロバイダーのヘルスチェックはノードの利用可能状態を管理し、プロキシグループのテストはグループ内の選択方法を決めます。両方の間隔を短くしすぎるとテストが重複します。ノード数と利用方法に応じて適切な周期を設定し、高頻度で探査し続ける必要はありません。

ヘルスチェックの失敗はノードが利用できない場合もあれば、テストURLが現在のネットワークや対象地域から到達できない場合もあります。すべてのノードが同じ時刻に同じテスト先で失敗するなら、実際の対象や別の安定したURLでも確認してください。リダイレクト、CAPTCHA、大きなページを返すURLは誤判定を増やします。単純な空レスポンスのエンドポイントは到達性確認に向いていますが、実際の業務アクセスの検証には代わりません。

ルールプロバイダーの構造

rule-providers は更新可能なルールセットを読み込みます。よく使う項目には、動作タイプ behavior、形式 format、リモートURL、キャッシュパス、更新周期があります。behavior: domain はドメイン集合、ipcidr はIPサブネット、classical はルールタイプを含む従来形式の項目に適しています。メイン設定のRULE-SET参照は集合の動作タイプと一致させる必要があり、IP集合では通常 no-resolve も併用します。

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://rules.example.net/private-ip.yaml
    path: ./rules/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,direct-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,ノード選択

Domain形式のYAML内容は通常ドメイン項目のリストで、IPCIDR形式はサブネットのリストです。Classical形式には DOMAIN-SUFFIX、IP-CIDR などの完全なルールタイプが含まれます。ClassicalファイルをDomainとして宣言すると、パーサーが読み込みを拒否したり、項目が意図どおり解釈されなかったりします。独自のルールセットを作るときは、先に動作タイプを決め、その形式に合わせて記述してください。異なる形式を1つの簡略集合に混在させないでください。

更新、キャッシュ、失敗からの復旧

リモート更新は、1回の設定変更として扱ってください。ノードプロバイダーの更新後は、現在選択中のノードが削除または改名されることがあります。ルールプロバイダーの更新後は、同じドメインが別の集合にマッチする可能性があります。更新後は、プロバイダーの状態、プロキシグループの現在の選択、重要サービスのルールマッチを確認してください。自動更新でも監視が不要になるわけではありません。特にローカル設定が名前フィルターに依存している場合、リモート側の命名変更がグループのメンバーへ直接影響します。

プロバイダーの取得に失敗してもキャッシュが残っていれば、クライアントは古いデータを使い続けることがあります。接続維持には役立ちますが、更新に成功したと誤解しやすい動作です。状態を確認するときは、「キャッシュを読み込んだ」のか「リモート更新が完了した」のかを区別してください。キャッシュファイルが壊れた場合は、リモートURLが利用できることを確認してから該当するキャッシュだけを削除し、再取得します。クライアントのディレクトリ全体を消去しないでください。すべてのデータを消すと、ポリシー選択、設定、トラブルシューティングの手がかりも失われます。

サブスクが空の内容を返した場合、すぐに長期利用中のローカルファイルへ空の結果を上書きしないでください。GUIクライアントは通常、解析に失敗すると古い設定を保持しますが、実装によって動作は異なります。手動スクリプトで更新する場合は、まず一時ファイルへダウンロードし、YAMLと設定チェックを通してから対象ファイルを置き換えてください。「検証してから置換する」流れなら、通信中断やサーバー異常で利用可能な設定が空ファイルになるのを防げます。

機密情報と移行しやすい設定

設定内のサブスクURL、ノードパスワード、UUID、操作用キーは、すべてアクセスに関わる情報です。トラブルシューティング用に設定を共有するときは、これらの値を削除しつつ、項目構造、プロトコルタイプ、エラー付近のインデントは残してください。ノード名を変更するだけでは認証情報を削除できません。ログに完全なサブスクURLが出ることもあるため、送信前に処理してください。

デスクトップとモバイル間の移行性を高めるには、リモートノード、共通プロキシグループ、ルールをベース層に置き、ポート、操作用インターフェース、TUN、DNS待受アドレスなどデバイス固有の差異を上書き層へ分けます。Clash PlusはダウンロードページからOS別に入手できます。他のクライアントでは上書き入口やローカルディレクトリの見え方が異なる場合がありますが、ベースYAMLの参照関係は明確に保ってください。

CHAPTER 08

設定の上書き・マージとシステムのトラブルシューティング

上書き層が必要な理由

リモートサブスクは通常サーバー側で管理され、更新時に設定が再生成されます。サブスクファイルへDNS、プロキシグループ、ルールを直接追加しても、次回更新でリモート版に戻ることがあります。上書きやマージは、元のサブスクを変更せずに、更新後の設定へローカルの長期設定を適用する仕組みです。クライアントによっては、この機能を上書き、マージ、拡張設定、前処理と呼びます。画面の場所や対応構文は完全には共通していません。

上書きを設計するときは、「値を1つ置き換える」「リストへ要素を追加する」「既存要素を削除する」「名前でオブジェクトを変更する」の4操作を区別してください。通常のYAMLマージはオブジェクトキーの上書きは表現できますが、2つのプロキシグループが同じ名前だからメンバーを自動的に統合すべきだとは判断できません。クライアントの上書き機能に専用ルールがあっても、すべてのクライアントが同じ意味で処理すると考えないでください。設定を移行する前に、上書き元ではなく実際に生成された最終結果を確認します。

マッピングの上書きとリストの置換

マッピング項目は通常、キー単位で上書きされます。たとえばベース設定が mode: rule で、ローカル上書きが mode: global なら、最終値は通常後者になります。ネストしたマッピングを深くマージするかどうかはツールによって異なります。dns 内の指定した子項目だけを上書きする場合もあれば、新しい dns オブジェクト全体で置き換える場合もあります。上書き後にnameserverが突然消えたなら、ネストしたオブジェクト全体が置換された可能性があります。

# base.yaml
mixed-port: 7890
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5

# override.yaml
mode: rule
dns:
  ipv6: false
  fake-ip-filter:
    - '*.lan'

理想的な深いマージでは、enable、enhanced-mode、nameserver を保持し、ipv6 とフィルター項目を追加します。一方、全体置換では上書き側の2項目だけが残ります。ファイル名だけでは動作を判断できないため、クライアントで最終設定をエクスポートまたは確認してください。上書きを初めて設定するときは、DNSやプロキシグループ全体を一度に追加するより、観察しやすく機密性のない項目を1つ選んでテストすると意味を確認しやすくなります。

リストの処理にはさらに注意が必要です。rules、proxies、proxy-groups はすべてリストです。通常のマージツールはリスト全体を置き換えることが多く、別のツールでは前置き、後置き、名前による挿入を許可します。ローカルルールをサブスクルールより優先したい場合は、「前置ルール」機能を明示的に使ってください。MATCHの後ろへ単純に追加しても実行されません。クライアントが全体置換しか対応しない場合は、リモートルールを完全に保持するか、ルールプロバイダーへ切り替える必要があります。追加した数件だけを書いてはいけません。

YAMLアンカーの適用範囲

YAMLアンカーは、同じファイル内で重複する項目を減らすために使えます。たとえば複数の自動プロキシグループで同じテストURLと間隔を使う場合、共通マッピングを定義してマージできます。ただしアンカーは同じYAML解析内でのみ有効で、リモートサブスクとローカル上書きファイルをまたいで自動共有することはできません。設定処理ツールによっては生成時にアンカーを展開または削除するため、使用前にクライアントが最終結果を読み込めるか確認してください。

group-test: &group-test
  type: url-test
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 80

proxy-groups:
  - name: 自動選択
    <<: *group-test
    proxies:
      - Example-Trojan
      - Example-SS

  - name: 予備自動グループ
    <<: *group-test
    proxies:
      - Example-SS
      - Example-Trojan

アンカーは静的な重複を減らすのに適していますが、複雑な階層を隠すために使うものではありません。使いすぎると、読み手がマージ元を何度も追跡する必要があり、クライアント間の移行も難しくなります。長期保守する公開設定では、少量の重複を残してでも、各プロキシグループの主要な動作が見えるようにしてください。アンカー展開後の最終設定を確認しにくい場合は、クライアントが明確に対応している上書き機能を優先します。

段階ごとに最終設定を検証

設定変更は4段階で検証します。第1段階はYAML構文で、インデント、引用符、データ型を確認します。第2段階はオブジェクト関係で、ノード、プロキシグループ、プロバイダー、ルールの参照先がすべて存在するか確認します。第3段階はクライアントの読み込みで、ポート、DNS、操作用インターフェースがシステム資源と衝突していないか確認します。第4段階は実際の接続で、ルールのマッチと最終出口を検証します。第1段階だけ完了しても、設定が利用可能だとは限りません。

1. ベースファイルと現在使える状態を保存

   元のサブスク、ローカル上書き、最終生成設定のコピーを保管し、変更前に正常動作していたポリシーを記録してください。復元時に、記憶を頼りに1項目ずつ戻すのではなく、明確な状態へ戻せるようにします。

2. 一度に1つの設定層だけ変更

   まず共通項目を変更し、次にDNS、その後でプロキシグループとルールを追加します。ノード変更、TUN有効化、DNS書き換えを同時に行うと、エラーがどの層で発生したか判断しにくくなります。

3. 最終的に展開された結果を確認

   上書き後も元のリストが残っているか、同名ポリシーが置き換わっているか、ルールがMATCHより前にあるか、プロバイダーのキャッシュパスが独立しているかを確認します。

4. 接続経路に沿ってテスト

   直接接続、ローカルプロキシポート、DNS問い合わせ、単一ノード、プロキシグループ、ルール分岐の順にテストします。各段階が通ってから次へ進み、すべての症状をノードの問題と決めつけないでください。

よくあるエラーと対処の順序

ポートの競合はOSのネットワークツールで確認できます。Windowsではターミナルで netstat -ano を使って待受ポートを確認し、macOSとLinuxでは lsof または ss を使えます。占有しているプロセスを見つけたら、別のプロキシクライアントが起動していないかを先に確認してください。複数クライアントのシステムプロキシとTUNを同時に有効にしないでください。ポートが異なっていても、ルーティング、DNS、システムプロキシが何度も上書きされて循環することがあります。

# Windows：7890ポートを確認
netstat -ano | findstr :7890

# macOS：7890ポートを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：待受ポートを確認
ss -lntp | grep 7890

最小構成から復元

複雑な設定で原因を特定できない場合は、ローカルポート1つ、動作確認済みのノード1つ、Selectプロキシグループ1つ、MATCHルール1つだけを残した最小テストファイルを作成します。まずTUN、カスタムDNS、ルールプロバイダー、スクリプト上書きを無効にし、基本のプロキシ経路を検証します。基本経路が成功したら、DNS、プロバイダー、プロキシグループ、ルール、TUNの順に層ごとに戻します。数千行の設定を無作為に削除・変更するより信頼性の高い方法です。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: Test-Node
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - Test-Node
      - DIRECT

rules:
  - MATCH,ノード選択

最小構成でも失敗する場合は、ログからローカルポート、ノード解決、サーバー接続、TLS認証のどこに問題があるかを判断します。最小構成が使えて完全構成が失敗するなら、原因は後から追加した層のいずれかです。層を1つ戻すたびに動作状態を保存すれば、問題の境界を明確にできます。症状別の対処法はよくある質問を、インストールや初回サブスク読み込みがまだの場合はクイックスタートを参照してください。

長期的な保守のポイント

安定した設定は項目数ではなく、関係が明確で、更新を制御でき、障害から復旧できるかで評価します。ベース層には共通ポート、DNS、少数の安定したポリシーを保存し、リモート層にはノードと大規模なルール集合を任せます。デバイス層にはTUN、待受アドレス、システム固有の差異を置き、上書き層には長期保持が必要なローカル変更だけを保存します。各層について、入手元と役割を個別に説明できる状態にしてください。

サブスクやルールデータベースを更新した後は、プロバイダーの状態、空のプロキシグループ、現在のノード、重要ルールのマッチを重点的に確認します。クライアントをアップグレードした後は、設定チェックで高度な項目が引き続き対応しているか確認してから普段の設定を有効にしてください。問題が起きたら、ログ、最終展開設定、最小再現断片を保存します。結果を記録せずに複数の設定ファイルを行き来しないでください。「構文—参照—ポート—DNS—ノード—ポリシー—ルール—システム引き継ぎ」の順で確認すれば、問題を明確な層まで絞り込めます。