Clash 上級設定マニュアル

はじめる前に:本マニュアルの位置づけと設定の基礎

まず本ページとチュートリアルページの役割分担を説明します。サブスクリプション設定入門はメインのチュートリアルで、サブスクのインポート、モード選択、接続開始、動作確認まで、順に進めればクライアントを使い始められます。本ページではその流れを繰り返さず、上級トピックを9章に分けて、調整したい部分だけを引けるリファレンスとしてまとめています。ブックマークに入れて手引きとして使うのに適しています。初回接続がまだの方は、先にチュートリアルページを一通り進めるか、ブログ記事「Clash 初回接続チュートリアル:ノード選択、遅延テスト、プロキシの動作確認」を参照してから、テーマ別に本ページをご覧ください。

本ページの設定対象は mihomo コア(旧 Clash Meta)です。クライアントダウンロードページに掲載しているメンテナンス中のクライアント——Clash Plus、Clash Verge Rev、FlClash、Clash Meta for Android など——はすべてこのコアをベースとしており、設定構文は共通です。本ページの YAML スニペットはすべて mihomo 設定です。デスクトップ・モバイルの GUI クライアントでは通常、設定編集または上書きの入口が用意されており、コアを直接動かすユーザーは設定ディレクトリ内の config.yaml を直接編集します。

作業を始める前に、まず「現在有効な設定ファイル」を特定してください。Clash Verge Rev では「サブスクリプション」ページで対象の設定を右クリックすると、ファイル編集やグローバル拡張の記述ができます。Clash Plus では設定管理から現在のサブスクを開きます。FlClash では設定詳細で上書きセクションを編集します。コア単体の場合はデフォルトで設定ディレクトリ内の config.yaml を読み込みます。複数のサブスクを併用している場合、違うファイルを編集してしまうことが「変更が反映されない」最大の原因です。

YAML 構文には4つのルールがあり、以降のすべての例もこれに従います。インデントは Tab ではなくスペースのみ、2スペースで統一。キー名の後のコロンはスペース1つを挟んでから値を書く。値にコロン、#、ワイルドカードを含む場合は全体を英字の引用符で囲む。同階層のキーは厳密に揃える。第9章に代表的な構文エラーの対照表を掲載しています。

# config.yaml 最小構成(mihomo)
mixed-port: 7890        # HTTP と SOCKS 共用ポート
allow-lan: false        # LAN 内デバイスからの接続を許可するか
mode: rule              # rule ルール / global グローバル / direct 直接接続
log-level: info
dns: {}                 # 第4章で展開
proxies: []             # ノード。通常はサブスクまたは proxy-providers から提供
proxy-groups: []        # 第2章で展開
rules: []               # 第3章で展開

プロキシグループの種類と実践

プロキシグループは振り分けの中枢です。rules の各ルールの末尾に書くのは具体的なノードではなく、プロキシグループ名です。ルールにマッチしたトラフィックはグループに渡され、グループが自身のタイプ別ロジックで実際の出口を選びます。「ノード選び」をルールから切り離すのが mihomo 設定の核心思想です。ルールは分類だけ、グループは選択だけを担当します。実際のノードを参照するほか、グループには2つの組み込みポリシーも入れられます。DIRECT は直接接続、REJECT は即時拒否(広告やトラッキングドメインで多用)です。

5種類を順に見る

select:手動選択。proxies リストの先頭がデフォルト出口で、その後はダッシュボードで手動切り替えします。最もよく使われ、一般的に最上位の出口グループとして配置します。

url-test:自動速度テストで最適化。グループ内のノードに url へ HTTP リクエストを送って遅延を計測し、interval 秒ごとに1ラウンド実行して遅延最小のノードを選びます。tolerance はミリ秒単位の許容差で、新旧ノードの差が許容差以内なら切り替えず、ノードのフラッピングを防ぎます。lazy を true にすると、グループ内にトラフィックがない間はテストを行わず、リクエストもバッテリーも節約できます。

fallback:フェイルオーバー。proxies の順に、最初にヘルスチェックを通過したノードを使います。主系・待機系の構成に適しています——メインノードが故障すると自動でバックアップに切り替わり、復旧後に戻ります。

load-balance:負荷分散。strategy に consistent-hashing を指定すると、同じ宛先ドメインは常に同じノードにハッシュされ、出口 IP の変動でサイトのログイン状態が切れるのを防げます。round-robin ならリクエストごとにローテーションし、マルチスレッドダウンロード系の用途に向きます。

relay:チェーンプロキシ。proxies を順に直列接続し、トラフィックはまず中継ノードを経由してから出口ノードへ向かいます。「入口を通ってから出口へ」という特殊な経路に使えますが、1ホップ増えるごとに遅延と故障箇所が倍増するため、日常の振り分けでは使いません。

グループのネストと use 参照

proxies にはノード名だけでなく別のグループ名も書けます——「ノード選択」の中に「自動選択」と各地域グループを入れれば、ユーザーは1か所で切り替えるだけで済みます。また use フィールドで proxy-providers が取得したサブスクのノード集合全体を参照できます(第7章参照)。サブスクが更新されるとグループ内のノードも自動で追従し、グループリストを手で直す必要がありません。

実践的な組み合わせ例

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies: ["自動選択", "香港", "日本", "米国", "DIRECT"]

  - name: "自動選択"
    type: url-test
    use: ["airport-a"]        # 第7章のサブスク集合を参照
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

  - name: "ストリーミング"
    type: select
    proxies: ["香港", "日本", "ノード選択"]

  - name: "ダウンロード"
    type: load-balance
    use: ["airport-a"]
    strategy: consistent-hashing
    url: "http://www.gstatic.com/generate_204"
    interval: 600

ルールセットのサブスクリプション管理

ルールは「どのトラフィックをどの出口へ流すか」を決めます。数十〜数百条のルールを config.yaml に直接書き込むと2つの問題があります。ルールは陳腐化し、ドメインリストは日々変わること。サブスク更新で手直しした内容が丸ごと上書きされること。ルールセット(rule-providers)はルールを独立したリモートファイルに切り出し、コアが interval ごとに定期的に取得し直すため、メイン設定には参照1行だけを残せます。

フィールドの個別説明

type:http は URL から取得、local はローカルファイルを読み込みます。behavior:ルールセットの内容形態——domain は純粋なドメインサフィックスリスト、ipcidr は純粋な IP レンジリスト、classical はクラシックルール(ファイル内の各行が DOMAIN-SUFFIX,example.com のようなタイプ接頭辞付きの完全なルール)。format:ファイル形式で、yaml、text、mrs をサポート(mrs はバイナリ形式で最も小さく、超大規模リストで優先)。url / path:リモートアドレスとローカルキャッシュパスで、取得失敗時は path のキャッシュでフォールバック。interval:更新間隔(秒)。

参照方法と順序の原則

rules では RULE-SET,ルールセット名,プロキシグループ の形式で参照します。ルールマッチングは上から順に行われ、最初にマッチした時点で終了するため、順序がそのまま優先度です。広告拒否セットを最前に、LAN と中国本土向けの直接接続を中間に、FINAL のフォールバックを最後に置きます。RULE-SET の位置を間違えると、その後ろに並んだルールには永遠に番が回ってきません。なお、GEOSITE ルール(GEOSITE,cn など)はコア内蔵の geosite データベースから供給され、RULE-SET の外部ファイルとは別系統のソースですが、混在して使えます。

rule-providers:
  reject:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/reject.yaml"
    path: ./ruleset/reject.yaml
    interval: 86400
  lan:
    type: http
    behavior: classical
    format: text
    url: "https://example.com/rules/lan.txt"
    path: ./ruleset/lan.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,lan,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

DNS 設定の最適化

DNS は振り分け品質の分かれ目です。典型的な問題は3つ。ISP の DNS が汚染された結果を返す。システムやブラウザがプロキシを迂回して ISP に直接問い合わせ、DNS リークが起きる。海外ドメインを中国本土の DNS で解決し、最適でない CDN ノードを掴まされる。mihomo の dns セクションはこの3つを引き受けるためのものです。

推奨構成

コア DNS を有効にし(enable と listen)、enhanced-mode は fake-ip を選びます(仕組みは第5章)。nameserver には中国本土のパブリック DNS を保険として設定。nameserver-policy で geosite に基づき中国本土ドメインを中国本土 DNS に固定。fallback には海外ドメイン向けの DoH を設定。fallback-filter は geoip でフィルタリング——解決結果が CN レンジ以外の場合のみ fallback を採用するため、汚染された結果は入りません。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.msftconnecttest.com"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - "https://1.1.1.1/dns-query"
    - "https://dns.google/dns-query"
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29

DNS リークとは

リークとは、アプリがコアを経由せず ISP の DNS に直接クエリを送り、アクセス記録が ISP に完全に見えてしまう状態です。対策はコアに全 DNS クエリを引き受けさせること。TUN モードでは dns-hijack でマシン全体の53番ポートを捕捉し(第5章)、非 TUN 環境ではシステム DNS を 127.0.0.1 に向け、listen が53番ポートを監視していることを確認します。リークの症状と検証方法はよくある質問ページの DNS 項目をご覧ください。

TUN モードと Fake-IP

システムプロキシが制御できるのは「従順な」アプリだけです——ブラウザやシステムプロキシ設定に従うソフトウェア。ゲーム、一部のコマンドラインツール、UWP アプリはシステムプロキシを通らず、UDP や ICMP トラフィックも制御できません。TUN モードは仮想 NIC を作ってマシン全体のトラフィックを引き受ける、最もカバー範囲の広い方式です。日常のブラウジングならシステムプロキシで十分で、プロキシ設定に従わないアプリに遭遇したら TUN を有効にしましょう。

主要フィールド

stack:プロトコルスタックの実装。違いは下表を参照。dns-hijack:DNS ハイジャック。any:53 でマシン全体の53番ポートへのクエリをすべてコア DNS に捕捉させ、第4章の設定と連動します。auto-route:ルーティングテーブルを自動構成し、トラフィックを仮想 NIC に導きます。auto-detect-interface:出口 NIC を自動識別し、トラフィックのループを防ぎます。mtu:デフォルトで問題ありませんが、一部の学内ネットワークや専用線環境では小さくする必要があります。

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

Fake-IP と redir-host の違い

redir-host モードでは、アプリがまず実際にドメインを解決して IP を取得してから接続を開始し、コアは IP からドメインを逆引きしてルールをマッチします——実解決の待ち時間が1回分増え、汚染された IP を掴む可能性もあります。fake-ip モードでは DNS 段階で 198.18.0.1/16 レンジの偽アドレスを直接返し、アプリは偽アドレスに接続し、コアは偽アドレスからドメインを逆引きしてルールをマッチします——実解決を省略でき、ルールマッチでドメインを直接取得するため、振り分けがより正確で初回接続も速くなります。

代償として、偽アドレスを渡せないサービスがあります。LAN ドメイン、NTP 時刻同期、一部の中国本土直接接続サービスです。これらは fake-ip-filter に書き、コアはこれらのドメインに実際の解決結果を返します。第4章の例に基本リストが含まれているので、必要に応じて追加してください。

ドメインスニッフィング

理想的には、コアは接続から宛先ドメインを直接取得します。しかし多くのアプリは独自に DNS を行っています——内蔵 DoH、ハードコードされた IP——コアの層に届く時点で IP アドレスしか残らず、ドメインルールはすべて空振りになり、IP ルールのフォールバックに頼るしかなく、振り分け精度が著しく低下します。ドメインスニッフィング(sniffer)は、この失われたドメインを取り戻す機能です。

動作原理

コアは接続の最初のハンドシェイクパケットを検査します。TLS の ClientHello には SNI フィールド、HTTP リクエストには Host ヘッダーがあり、どちらにも宛先ドメインが書かれています。スニッフィングはドメインを抽出して接続先を置き換え、ルールマッチをやり直します——これまで IP ルールにしかマッチしなかったトラフィックがドメインルールにマッチするようになり、ダッシュボードで裸の IP で表示される接続も目に見えて減ります。

設定例

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

override-destination はスニッフィングで得たドメインで接続先を上書きすることを意味し、fake-ip と TUN 環境では有効化を推奨します。純粋な redir-host でルールが IP レンジ中心の設定では不要です。skip-domain にはスニッフィングで問題が起きるサービスを入れます。Apple プッシュ通知や米家(Mijia)のような証明書ピンニングが厳格なサービスは、スニッフィングによる書き換えでハンドシェイクが失敗するため、素直にスキップするのが一番手軽です。

ローカル上書きと複数サブスク統合

サブスクリプションは丸ごと配信されます。プロバイダが設定を更新し、クライアントが取得し直すと、手で直したプロキシグループやルールはすべて上書きされます。正しいやり方は、サブスクはサブスク、ローカルの変更はローカルと分け、読み込み時にマージして、同じファイルに混ぜないことです。

Clash Verge Rev:Merge 上書き

「サブスクリプション」ページからグローバル拡張設定に入り、Merge(マージ)方式を選び、固定キー名で変更を記述します。prepend-rules と append-rules はルールの先頭または末尾に挿入。prepend-proxies と append-proxies はノードを追加。prepend-proxy-groups と append-proxy-groups はプロキシグループを追加。処理タイミングはサブスク読み込み後なので、サブスクがどう更新されても上書きは再適用されます。JavaScript に慣れたユーザーは Script 方式で処理関数を書くこともでき、自由度は高いですが、多くの要件は Merge キー名で十分です。

# Clash Verge Rev グローバル拡張設定(Merge)
prepend-rules:
  - "DOMAIN-SUFFIX,internal.example.com,DIRECT"
append-proxy-groups:
  - name: "ダウンロード"
    type: select
    proxies: ["ノード選択", "DIRECT"]

他のクライアントの入口

Clash Plus では設定管理で現在のサブスクに上書きを行います。FlClash では設定詳細で上書きセクションを編集します。コア単体のユーザーには上書きレイヤーがないため、メイン設定は自分で管理し、サブスクは proxy-providers 経由でノード提供だけに回すのがおすすめです。

複数サブスク統合:proxy-providers

複数のプロバイダを利用している場合、ノードをメイン設定にコピーする必要はありません。proxy-providers は各サブスクを独立したノード集合として取得し、それぞれ定期更新・ヘルスチェックを行います。プロキシグループは use で複数の集合を同時に参照でき、ノードの和集合がグループに入り、1か所で切り替えられます。

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

proxy-groups:
  - name: "自動選択"
    type: url-test
    use: ["airport-a", "airport-b"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

外部ダッシュボード

mihomo には RESTful API が内蔵されており、デスクトップクライアントの UI は本質的にそのフロントエンドです。API を公開すれば、ブラウザにダッシュボードを載せられます——サーバーやルーターでコアを直接動かす場合は GUI がないため、これが標準的な管理方法です。

API を有効化

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ui

external-controller はリッスンアドレス、secret はアクセスキー、external-ui はダッシュボードの静的ファイルディレクトリを指します。設定後は http://127.0.0.1:9090/ui にアクセスするとダッシュボードが直接開きます。ダッシュボードファイルを自前でホストしたくない場合は、オンラインダッシュボードを使いましょう——metacubexd、zashboard、yacd-meta はいずれも活発にメンテナンスされており、ページを開いて API アドレスとキーを入力するだけで使えます。

よく使うエンドポイント

# すべてのプロキシグループとノードを表示
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/proxies

# 「ノード選択」を指定ノードに切り替え
curl -X PUT -H "Authorization: Bearer your-password" \
  -d '{"name":"香港 01"}' \
  http://127.0.0.1:9090/proxies/ノード選択

ほかによく使うエンドポイントとして /connections(アクティブ接続リスト、個別切断可能)、/traffic(リアルタイム速度)、/logs(ログストリーム)があります。スクリプトでノードを一括切り替えたり、ヘルスチェックを回したりするのは、これらのエンドポイントが頼みの綱です。

設定検証とトラブルシューティング

設定を変更したら、再起動の前に検証しましょう。GUI クライアントのログページは YAML エラーの行番号を直接報告します。コア単体の場合はコマンドラインで完全な読み込みテストを行います。

mihomo -t -d /etc/mihomo

-t はテストのみで実行しないことを意味し、-d は設定ディレクトリを指定します。構文エラー、存在しないプロキシグループの参照、ルールセットパスの不存在は、すべてこの段階で報告され、問題を抱えたまま本番投入されることはありません。

YAML 頻出エラー対照表

調査手順

「変更が反映されない」は4ステップで進めます。1つ目、編集しているのが現在有効な設定ファイルかを確認。複数サブスク併用時に最もよくハマる落とし穴です。2つ目、サブスク更新後に上書きがまだ有効かを確認。3つ目、ランタイム設定を見て、マージ結果が想定通りかを確認。4つ目、ルールセットとノードのキャッシュをクリアしてコアを再起動。ルールにヒットしない場合は、ダッシュボードやログでその接続が実際にヒットしたルールチェーンを確認しましょう。多くは順序の問題です——より具体的なエラー Q&A はよくある質問ページに集約しており、Windows プラットフォームのインストールの落とし穴はブログ記事「Clash Windows 版インストール設定の全手順と頻出問題の回避」をご覧ください。

問題がクライアントやコア自体にある場合は、まず最新バージョンを使っているか確認してください。クライアントダウンロードページには5つのプラットフォームのクライアントとコアパッケージをまとめており、全プラットフォームで Clash Plus を第一推奨としています。サブスクレベルの更新失敗の調査はブログ記事「Clash サブスクリプション更新失敗のよくある原因と自動更新の設定方法」をご覧ください。