Clash上級者向け設定ガイド：ルール構文・Provider・DNS・TUN完全リファレンス

config.yaml構造の全体像

完全な設定ファイルはいくつかのトップレベルのフィールドで構成されています。この表を理解すれば、以降の各セクションはそれぞれのフィールドの詳しい書き方の説明になります：

プロキシプロトコルパラメータ詳細

サブスクリプションに完全に依存せず、ノードを手動で追加したい場合は、proxiesフィールド配下の主要プロトコルのコアパラメータを以下に示します：

Shadowsocks

コアとなるフィールドはcipher（暗号方式、例：aes-256-gcm、chacha20-ietf-poly1305）とpasswordです。一部のノードではplugin（obfsやv2ray-pluginなど）を使ってトラフィックを難読化することもあります。

VMess

uuidとalterId（新しいバージョンでは通常0）が必要で、cipherは一般的にautoを使います。TLSが有効なノードの場合はtlsやservername（SNI）も設定が必要です。

Trojan

コアとなるフィールドはpasswordとsniです。Trojanはデフォルトで標準TLSを強制し、通常のHTTPS通信になりすますため、sniが証明書のドメインと一致しているかどうかが接続の成否に直結します。

Hysteria2

QUICプロトコルをベースとし、コアとなるフィールドはpasswordとup / down（アップロード/ダウンロード帯域のヒント値）です。弱い回線や高遅延の環境では、従来のTCPプロトコルより安定する傾向があります。

WireGuard

他のプロトコルとはフィールドの構成が異なります：private-key、相手側のpublic-key、そしてip（WireGuardの内部ネットワーク上での自分のアドレス）が必要です。設定はやや低レベルで、通常はノード提供元から完全な設定スニペットがそのまま渡されます。

proxies:
  - name: "ss-node"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

  - name: "trojan-node"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

  - name: "hy2-node"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    up: "50 Mbps"
    down: "200 Mbps"

ルール構文完全リファレンス

ルールの形式は統一されており、ルールタイプ,マッチ対象,ターゲットポリシーという形で上から順に照合し、一致した時点で処理を停止します。以下によく使われるルールタイプの一覧を示します：

Providerの仕組み：Proxy ProviderとRule Provider

Providerは、Clashが「リモートかつ自動更新可能」なリソースを管理するための統一された仕組みです。サブスクリプションリンクの裏側は実はProxy Providerであり、ルールセットの裏側はRule Providerです。どちらも定期的な自動更新に対応しており、ファイルを手動で置き換える必要はありません。

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/api/v1/subscribe?token=xxx"
    interval: 3600
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

ここでintervalは自動更新の周期（秒単位）を制御し、health-checkはクライアントに定期的にProvider配下のノードを一括で速度測定させます。behaviorは、ルールセットの内容がドメインリスト（domain）、IP範囲（ipcidr）、あるいは完全なルール（classical）のいずれかであるかをクライアントに伝えます。

プロキシグループの高度なパラメータ

基本的なtypeとproxiesのほかに、プロキシグループには知っておくと役立ついくつかの高度なパラメータがあります：

• lazy —— url-test / fallbackグループで有効にすると、実際に使用されたときだけバックグラウンドで速度測定を行い、アイドル時のリソース消費を減らします；
• tolerance —— 遅延の許容値（ミリ秒）。新しいノードの遅延が現在のノードよりこの値以上低くならない限り切り替えは発生せず、測定値のブレによる頻繁な切り替えを防ぎます；
• strategy（load-balanceグループのみ）—— ロードバランシングの戦略で、一般的なのはconsistent-hashing（同じ宛先は常に同じノードを使用し、セッション維持が必要な場面に適する）またはround-robin（順番に巡回）です；
• disable-udp —— そのプロキシグループ内のノードのUDP転送を無効化します。一部のノードや回線がUDPに対応していない場合に使用します。

DNSの高度な設定

DNS設定は漏洩防止のオン・オフだけでなく、解決動作を細かく制御することもできます：

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.google/dns-query
    - https://1.1.1.1/dns-query
  fallback:
    - https://1.0.0.1/dns-query
    - https://dns.quad9.net/dns-query
  nameserver-policy:
    "geosite:private": [192.168.1.1]
  fallback-filter:
    geoip: true
    geoip-code: JP

enhanced-mode: fake-ipは最も一般的なモードで、クライアントが各ドメインに仮のIPを割り当て、プロキシ層で実際のドメインに戻すため、互換性が最も高いです。nameserver-policyはドメインの所属に応じてどのDNSグループで解決するかを個別に指定できます（例：自宅ルーターなどLAN内のホスト名だけローカルDNSで解決する）。fallback-filterはある解決結果が「汚染されている疑いがある」かどうかを判定し、fallbackリストで再度問い合わせるかどうかを決定するために使われます。geoip-code（ここではJP）とサンプルのIP/ドメインは、実際にお使いの地域やDNSサーバーに置き換えてください。

TUNモードのパラメータ詳細

TUNモードのコアパラメータは以下の通りです：

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stackは仮想ネットワークアダプターの実装方式を決めます。systemは互換性が最も高く、gvisor/mixedは場面によってはパフォーマンスが優れています。auto-routeを有効にすると、クライアントが自動的にシステムのルーティングテーブルを引き継ぎます。auto-detect-interfaceは、現在使用している物理ネットワークインターフェースをクライアントが自動的に検出し、手動指定を不要にします。dns-hijackは、UDP53ポート経由のDNSリクエストを強制的に横取りし、アプリがシステムのDNS設定を回避して直接問い合わせるのを防ぎます。

外部コントローラーとRESTful API

external-controllerを設定すると、Clashは指定したアドレスでRESTful APIを公開します。ダッシュボード系クライアントと組み合わせることで、クライアントを再起動せずに接続状況の確認、ノードの切り替え、遅延の確認などをリアルタイムで行えます。

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

パフォーマンス・セキュリティのおすすめ設定

• 何百ものDOMAIN-SUFFIXをrulesに直接並べるのではなく、できるだけRULE-SETでルールセットを参照する方が、照合が速く、メンテナンスも簡単です；
• アクセス頻度が高く、明確なルールほどrulesリストの上位に置き、平均的な照合回数を減らしましょう；
• 必要がない限りlog-levelをdebugのまま長時間運用しないでください。詳細なログはディスクとメモリを消費し続けます；
• external-controllerには必ずsecretを設定し、複数デバイス・複数プラットフォーム間で同じシークレットを使い回さないでください；
• プロキシグループの速度測定の間隔は短すぎないようにしましょう。数十秒から数分に1回で十分にノードの異常を検知できます。頻度が高すぎるとノード側の負荷やローカルリソースの消費が増えるだけです；
• カスタムで上書きしたルールやプロキシグループは別途バックアップしておくと、サブスクリプション更新やクライアント再インストール後にすぐ復元できます。

よくある質問