Clash 設定上級ガイド

CH-01プロキシグループ:設定内のギアチェンジ機構

まず2つを区別しましょう。ルールが担うのは「このトラフィックを誰が処理するか」の判定です。プロキシグループが担うのは「担当が決まった後、具体的にどのノードを使うか」という答えです。長く使える設定では、ルールの出口はほぼすべて単一ノードを直接指すのではなく、プロキシグループを指します——ノードは今日あっても明日には消えるかもしれませんが、グループ名は変わりません。グループをきちんと組んでおけば、後で業者やノードを変えても弾倉を交換するだけで、銃自体をいじる必要はありません。

5種類のタイプ、1枚の仕様表

選び方の原則はシンプルです。機械に判断を任せるなら url-test、人が決めるなら select。残り3種は特定場面向けの専用パーツです。初心者はこの2種類を使いこなせれば、9割のニーズはカバーできます。

url-test の3つのつまみ

url は速度測定の対象で、通例204ステータスコードを返す軽量なアドレスを指定します。例えば https://www.gstatic.com/generate_204 は空のレスポンスしか返さず、ページ読み込み時間を含まない純粋な通信遅延だけを測定できます。interval は測定周期(秒単位)で、300なら5分ごとに1回測定します。小さくしすぎると測定リクエストが頻発し、大きくしすぎるとノード障害の発見が遅れます。tolerance は許容差(ミリ秒単位)で、新旧の最速ノードの遅延差がこの値を超えない限り切り替えません。これを設定しないと、2つのノードの遅延が80と85の間で揺れるたびにグループも切り替わり続け、長時間接続が何度も切断されてしまいます。もう1つよく使うつまみが lazy: true です。グループが使われていない間は測定を発行せず、無駄なバックグラウンドリクエストを省けます。

長く使える階層構造

実践では3階層構成を推奨します。最上位に select のメインスイッチ、中間に自動測速グループと地域別グループ、最下層が具体的なノードです。ルールは常にグループ名を指定し、個別ノードを直接指定することはありません。特定地域を手動で固定したい場合はメインスイッチで切り替え、全自動にしたい場合は自動測速グループに戻します。構成は以下の通りです:

proxy-groups:
  - name: 手動メインスイッチ
    type: select
    proxies: [自動測速, 香港ノード, 日本ノード, DIRECT]

  - name: 自動測速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies: [HK-01, HK-02, JP-01, JP-02]

  - name: 香港ノード
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, HK-02]

  - name: 日本ノード
    type: select
    proxies: [JP-01, JP-02]

CH-02ルールセット:ルールを交換可能な弾倉にする

数百件のルールを1つずつメイン設定に書き込むのは、すべての部品を基板に溶接してしまうようなものです——1つ交換するだけでも全体を分解しなければなりません。rule-providers の考え方は、ルールを着脱可能な弾倉に分割することです。メイン設定には RULE-SET の参照を1行残すだけで、弾倉本体は外部アドレスに置かれ、時間になれば自動更新されます。メンテナ側が弾倉を更新すれば、こちら側は何もする必要がありません。

スロット仕様

各 provider には5つの重要フィールドがあります。type は http(URLから取得)と file(ローカルファイルを読み込む)の2種類。behavior は弾倉に入っている弾の種類を宣言します(詳細は次節)。format はファイル形式で、yaml または text。path はダウンロード後のローカルキャッシュパス。interval は自動更新周期(秒単位)で、86400なら1日ごとに更新します。キャッシュの意味は、ネット切断後の再起動時にコアがローカルコピーを直接読み込み、ルールが取得できないせいで起動できなくなることを防ぐ点にあります。

behavior:3択の選び方

domain 弾倉にはドメインのみを入れ、コアは専用インデックスを構築するため、マッチングが最速でメモリ消費も最小です。ipcidr は IP セグメントのみを入れ、同様に専用マッチングを使います。classical はどんな種類でも入れられ(DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME が混在)、柔軟ですが1件ずつマッチングするため、ルールが増えるとパフォーマンスを消費します。選び方:純粋なドメインリストなら domain、純粋な IP セグメントなら ipcidr、混在させる場合のみ classical を使います。classical で純粋なドメインリストを扱うことは動作はしますが、トラックで宅配便を運ぶようなものです。

組み立て例と更新ペース

rule-providers:
  streaming:
    type: http
    behavior: classical
    format: yaml
    url: "https://example.com/rulesets/streaming.yaml"
    path: ./rulesets/streaming.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: text
    url: "https://example.com/rulesets/cn-ip.txt"
    path: ./rulesets/cn-ip.txt
    interval: 86400

rules:
  - RULE-SET,streaming,手動メインスイッチ
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - MATCH,手動メインスイッチ

更新周期は弾倉の性質に応じて決めます。コミュニティ管理の振り分けリストなら1日1回で十分です。自分で管理し頻繁に調整するリストなら数時間まで短縮できます。ルールセットの取得失敗のトラブルシューティングはサブスクリプション更新失敗と同じ考え方で対応できます。ヘルプセンターのトラブル対処カテゴリーを参考にしてください。

CH-03DNS設定の最適化:トラブルの半分は解析にある

「プロキシは有効なのにページが開かない」「ルールを書いたのにマッチしない」——このような問題の半分は DNS に原因があります。コアには DNS リゾルバーが内蔵されており、適切に設定すれば解析は速く安定しますが、設定が乱れると汚染や漏洩が交互に起きます。この章では解析経路上の各スロットを一つずつ説明します。

まず解析経路を理解する

リゾルバーは3層構成です。default-nameserver はブートストラップ層です。メインのリゾルバー自体がドメイン名(例えば DoH アドレス https://doh.pub/dns-query)の場合、そのドメイン名を先に IP に解析する必要があり、それを担うのがブートストラップ層です。そのため純粋な IP のみを指定できます。ドメイン名を指定すると、鶏が先か卵が先かのループに陥ります。nameserver はメイン層で、日常のクエリはここを通ります。fallback はバックアップ層で、メイン層が汚染されている可能性がある場面に対応します。3層はそれぞれ役割が異なるので、DoH アドレスをブートストラップ層に入れたり、メイン層を空にしたりしないでください。

nameserver と fallback の役割分担

動作方式は並行実行です。1回のクエリをメイン層とバックアップ層に同時に送り、fallback-filter がどちらの回答を採用するか判定します。最もよく使われる判定器は geoip: true と geoip-code: CN の組み合わせです。メイン層が返した IP が中国本土のセグメントに該当すれば、メイン層の回答を採用します(正常な現地解析であることを示します)。海外セグメントに該当する場合は、バックアップ層の回答に切り替えます(現地のリゾルバーが海外の IP を返すのは汚染の疑いがあるため)。この仕組みの代償は、クエリごとにリクエストが1件増えることですが、それによって耐汚染性が得られます。メイン層自体が暗号化通信(DoH/DoT)を使っている場合は汚染リスクはすでに低いため、fallback は簡略化しても構いません。

nameserver-policy:ドメインに専用リゾルバーを指定する

特定のドメインについては、どこで解析すべきか明確にわかっている場合があります。現地サービスは現地のリゾルバーを使うことで、最寄りの CDN ノードが得られます。速度測定用ドメインやローカルネットワークのドメインにもそれぞれ専用の行き先があります。nameserver-policy はこの振り分け表で、ワイルドカードと geosite 分類に対応しています。完全な例:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    "geosite:cn": https://doh.pub/dns-query
    "+.lan": 223.5.5.5

CH-04TUNとFake-IP:システム層での取りこぼし防止と仮アドレスの番号札

TUN:言うことを聞かないトラフィックを引き受ける

システムプロキシは紳士協定のようなものです。「システムプロキシ設定を読む意志のある」アプリだけがそれを経由します。コマンドラインツール、一部のゲームクライアント、いくつかのデスクトップソフトはこの設定を無視し、トラフィックを直接外に送り出します。TUN モードのやり方は、仮想ネットワークカードを1枚挿し、デバイス全体の送出トラフィックをネットワーク層で捕捉してコアに渡すことです——アプリが協力するかどうかは関係なく、すり抜けようとしても検査を通らなければなりません。

ついでに Android の状況も説明しておきます。クライアントで「起動」をタップした際にシステムへ申請する VPN チャネルは、本質的に TUN ネットワークカードそのものです。そのため Android ユーザーは元から TUN モードで動いており、この部分を手動設定する必要はありません。明示的に TUN を有効化する必要があるのはデスクトッププラットフォームです。各プラットフォームのクライアント取得はダウンロードページを、横断的な違いは機能比較を参照してください。デスクトップ側の重要フィールド:stack はプロトコルスタックの実装で、system は性能が良いがシステム機能に依存し、gvisor はユーザー空間実装で互換性が安定、mixed は両者の長所を取ったもの——迷ったら mixed を選んでください。auto-route はルーティングテーブルを自動的に引き受けます。dns-hijack は任意の53番ポートへ送られる平文 DNS リクエストをコアに強制的に引き込み、アプリ独自の解析が振り分けを回避することを防ぎます。

Fake-IP:先に番号札を発行し、後で処理する

銀行の番号札発行と同じ仕組みです。アプリが「このドメインのIPは何か」と問い合わせると、コアは実際には解析せず、198.18.0.1/16 という予約セグメントから即座に仮アドレスを番号札として発行します。遅延はゼロです。アプリはその番号札で接続を開始し、接続がコアに到達すると、コアは番号札からドメイン名を逆引きして、ドメインルールに従って振り分けます。プロキシを経由する必要がある場合、実際の解析は出口側に任せます。メリットは2つあります。ローカルでの実解析の待ち時間が省けるため接続開始が速いこと、そしてコアが常に各接続の背後にあるドメイン名を把握しているため、ドメインルールの命中率も高いことです。

代償は、番号札が窓口の外では使えないことです。ローカルネットワーク機器の検出、プリンター、一部のオンラインゲーム、IPをサーバーに送り返す必要がある場面では、仮アドレスを受け取ってしまうと機能しません。解決策は fake-ip-filter です。リストに載っているドメインには番号札を発行せず、素直に実解析を行います。

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

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
    - "+.stun.*.*"

fake-ip と redir-host の比較

CH-05ドメインスニッフィング:入口に取り付けたバーコードリーダー

Fake-IP でパッチは当たりましたが、経路にはまだ隙間が残っています。一部のトラフィックはコアに到達した時点で IP しか持たず、ドメイン名がありません。典型的な原因は、アプリ内蔵の暗号化解析(アプリ内蔵の DoH で、コアの DNS を経由しない)や、IP を直接ハードコードして接続するクライアントです。ドメインルールはこの種のトラフィックに対して一律機能せず、IPルールや MATCH で処理するしかなく、振り分けの精度が大きく落ちます。

sniffer は入口に取り付けたバーコードリーダーのようなものです。トラフィックが入ってきた際、TLS ハンドシェイクの SNI フィールドや HTTP リクエストヘッダーの Host フィールドからドメイン名を読み取り、その接続に貼り直してからルールマッチングに送ります。ドメイン名が取り戻せれば、ルールは正常に機能します。

設定項目の仕様

sniff の下ではプロトコル別にスキャン対象ポートを宣言します。TLS は通常 443 と 8443 を、HTTP は 80 とよく使われるプロキシポート範囲をスキャンします。override-destination はスニッフィングで得たドメイン名で元の宛先アドレスを上書きするかどうかを決め、HTTP の場面では有効にすることを推奨します。force-domain は強制スニッフィングリストで、すでに解析結果があってもリストに載っているドメインは再度スニッフィングされます。skip-domain は検査免除リストです——証明書検証が厳格、または SNI の変更に敏感なサービス(Apple のプッシュ通知が常連です)では、スニッフィングがむしろ接続を切断してしまうため、リストに加えてそのまま通過させます。

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080-8880]
      override-destination: true
  force-domain:
    - "+.v2ex.com"
  skip-domain:
    - "+.push.apple.com"

CH-06ローカル上書きと複数サブスクリプション統合:更新で変更が消える心配なし

サブスクリプションファイルを直接編集しない理由

サブスクリプションから配信される設定ファイルを直接編集してルールを変えたりノードを追加したりするのは手軽に感じますが、結末は悲惨です。サブスクリプションが更新されるたびに、ファイル全体がサーバー側の新バージョンで上書きされてしまい、あなたの変更はすべて消えてしまいます。正しいやり方は上書きです——サブスクリプションの原文は常に読み取り専用のまま保ち、あなたの変更は別のローカル層に記録しておき、サブスクリプション更新が完了するたびに自動的に新しいファイルへ再適用されます。変更とサブスクリプションはこれ以降互いに干渉しません。

クライアント内の上書き機能の入口

主流のクライアントにはこの仕組みが内蔵されており、名称は異なりますが考え方は共通しています。Clash Verge Rev を例にすると、2段階の機能を提供しています。Merge は宣言的なスニペットで合成を行い、ルールの追加やプロキシグループの追加といった構造化された変更に適しています。Script はスクリプトで設定全体をプログラム的に書き換えるもので、ノードの一括リネームや条件によるフィルタリングといった複雑な操作に適しています。Merge で解決できるものに Script を使わないでください——宣言的なスニペットは一目で理解できますが、スクリプトはエラー発生時の調査コストがはるかに高くなります。各クライアントの上書き機能の違いは機能比較に専用の節があります。

proxy-providers で複数サブスクリプションを統合する

2社以上のプロバイダーを利用している場合、設定ファイルを切り替えて使い回すのはやめましょう。proxy-providers はルールセットの provider と同じ考え方です。各サブスクリプションが1つのノード弾倉となり、プロキシグループは use フィールドで複数の弾倉を同時にマウントできます。2社のノードは同じ自動測速グループに混在させられ、速いほうが使われます。

proxy-providers:
  airport-a:
    type: http
    url: "https://example.com/sub/a.yaml"
    path: ./providers/a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
  airport-b:
    type: http
    url: "https://example.com/sub/b.yaml"
    path: ./providers/b.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 全ノード
    type: url-test
    use: [airport-a, airport-b]
    url: https://www.gstatic.com/generate_204
    interval: 300

health-check は弾倉内のノードを定期的にチェックし、落ちたノードは自動測速グループから除外されます。interval: 43200 はサブスクリプション本体を半日ごとに1回取得し直すことを示します。サブスクリプションリンクの形式認識と取り込み方法は、まずこちらの記事を参照してください:Clash サブスクリプションリンク導入ガイド。

CH-07外部コントロールパネル:コアに遠隔操作用のインターフェースを取り付ける

3つのフィールドで遠隔操作を有効化

external-controller は RESTful API のリスンアドレスを宣言し、通例は 127.0.0.1:9090 です。secret はアクセス用のパスワードで、すべてのリクエストに付ける必要があります。external-ui はローカルディレクトリを指し、Webパネルの静的ファイルをそこに置くことで、ブラウザからリスンアドレスに直接アクセスすればグラフィカルなインターフェースが開けます。市場にある Web パネル(metacubexd、yacd 系)は本質的にすべてこの API のフロントエンドの見た目にすぎず、皮を変えても中身は同じです。

external-controller: 127.0.0.1:9090
secret: "your-strong-password"
external-ui: ./ui

パネルを開かなくても使える:よく使う3つのコマンド

API そのものが使えるツールなので、スクリプトや自動化を組む際に直接呼び出せます:

# 全プロキシグループとノードの状態を確認
curl -H "Authorization: Bearer your-strong-password" \
  http://127.0.0.1:9090/proxies

# 「手動メインスイッチ」グループを HK-01 に切り替え
curl -X PUT -H "Authorization: Bearer your-strong-password" \
  -d '{"name":"HK-01"}' \
  http://127.0.0.1:9090/proxies/手動メインスイッチ

# 単一ノードの遅延を1回測定
curl -H "Authorization: Bearer your-strong-password" \
  "http://127.0.0.1:9090/proxies/HK-01/delay?timeout=5000&url=https://www.gstatic.com/generate_204"

パネルでよく使う3つの機能

接続リスト:各接続がどのルールにマッチし、どの出口を通っているかをリアルタイムで確認できます——「このトラフィックがなぜ直接接続になっているのか」といった疑問は、ここで一目で解決します。ログ:レベルを一時的に debug に上げると、ルールマッチングの全過程が1件ずつ出力されます。確認が終わったら戻すのを忘れないでください、debug ログの量は非常に多くなります。Provider 管理:特定のサブスクリプションやルールセットの更新を手動でトリガーでき、interval の到来を待つ必要がありません。

CH-08設定トラブル速見表

症状に合わせて対応表を確認し、まず最も一般的な原因を調べ、その後リンクをたどって該当する章や記事に進んでください。ほとんどの問題は最初の2ステップで解決します。

表に載っていない問題は、ヘルプセンターの「基礎知識 / インストール設定 / 使い方のコツ / トラブル対処」の4カテゴリーから探してください。クライアント自体の問題が疑われる場合は、まず機能比較でその機能範囲を確認し、必要であればダウンロードページで推奨の Clash Plus に切り替えて試してください。基本操作を忘れた場合は、いつでもクイックスタートに戻って確認できます。