Clash 設定ファイル完全ガイド

01YAML 構造の全体像

config.yaml はカーネルへの唯一の入力です。Clash Verge Rev、Clash Plus、FlClash といった GUI クライアントは、本質的には同じことをしています。すなわちこのファイルを管理し、mihomo カーネルに実行させることです。画面上でのノード切り替え、モード変更、ポート変更といった操作は、最終的にすべてこの YAML テキストに反映されます。このファイルを読み解けばクライアントの挙動がすべて分かり、正しく編集できればすべてのクライアントに正しく反映されます。

ファイルの場所をわざわざ覚える必要はありません。Clash Verge Rev の設定ページで任意のサブスクリプションカードを右クリックすれば、「ファイルを開く」から現在の設定の原文へ直接アクセスできます。同じメニューから更新や編集も行えます。カーネルを単体で動かす場面(サーバーやルーター)には GUI がなく、ファイルの位置は起動パラメータの -f(ファイル指定)や -d(ディレクトリ指定)で決まり、クライアントとは無関係です。

トップレベルの構造は役割ごとに 5 つの区分に分かれます。記述順序に決まりはありませんが、コミュニティの慣例は以下の通りです。

# ① 共通フィールド:ポート、モード、ログ、外部コントロール
mixed-port: 7897
mode: rule
log-level: info

# ② DNS:カーネルによる名前解決
dns:
  enable: true

# ③ プロキシノード:アウトバウンド一覧
proxies: []

# ④ ポリシーグループ:ノードの組織化
proxy-groups: []

# ⑤ ルール:振り分け判定(上から順に評価)
rules:
  - MATCH,DIRECT

5 区分の外は拡張領域です。proxy-providers はサブスクリプションのノードを集約、rule-providers は外部ルールセットを取り込み、tun はシステムトラフィックを引き受け、hosts は静的な名前解決テーブル、listeners は追加のリスニング設定を担います。使うものだけ、該当する章で確認してください。

YAML 記法には 6 つの絶対規則があり、いずれかに違反すると起動に失敗します。

• インデントは半角スペースのみを使用し、Tab は禁止。同階層のインデント幅は揃える必要があり、慣例として半角スペース 2 個を使う。
• key: value のコロンの後には必ず半角スペースを入れる。key:value は不正な記法。
• リスト項目は - で始め、ハイフンの後にも半角スペースを入れる。- は親キーと同じ列でもさらに字下げしてもよいが、ファイル全体で統一すること。
• 文字列に #、: を含む場合、または @、&、* で始まる場合、数値や真偽値に見える場合は必ず引用符で囲む。パスワード欄はほぼ常に必要。
• # でコメントを開始し、行末コメントは内容との間に半角スペースを空ける。空けないと # が直前の文字列に取り込まれてしまう。
• アンカー &name と参照 *name で繰り返し部分を再利用できる。カーネルは標準 YAML パーサーで解釈するため、この機能に対応している。

最小構成の設定例。わずか 20 行で「ローカル混合ポート + 単一ノード + 中国本土は直接接続、それ以外はプロキシ経由」という振り分けが完成します。

mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies:
  - name: ノードA
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
proxy-groups:
  - name: デフォルトプロキシ
    type: select
    proxies:
      - ノードA
      - DIRECT
rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,デフォルトプロキシ

変更を反映させるには 2 段階の手順が必要です。ファイルを編集し、カーネルに再読み込みさせます。Clash Verge Rev では設定を再アクティブ化するとホットリロードが実行されます。GUI 上のシステムプロキシ、TUN、自動起動といった設定はクライアント側の設定であり、サブスクリプションファイルには書き込まれません。この 2 種類の設定を混同しないよう注意してください。

カーネルの差異には注意が必要です。原版 Clash は開発が停止し、Clash Meta は mihomo に名称を変えて開発が継続されています。3 世代のカーネルでフィールドが共通というわけではなく、mihomo が新たに追加した vless、hysteria2、tuic、wireguard といったノードタイプや論理ルールは、旧カーネルでは認識できません。各クライアントが内蔵するカーネルの対応関係はブログの「Clash カーネルのバージョン差異まとめ」を参照してください。本ページのフィールドはすべて mihomo 準拠です。

02共通フィールド:ポート・モード・基本動作

共通フィールドはトップレベルに置かれ、カーネルのリスニング、モード、基本動作を管理します。特定のノードとは無関係で、いずれかを変更すれば全体に影響します。サブスクリプションの設定には通常適切なデフォルト値がすでに設定されており、実際に調整が必要になるのはポート・モード・ログの 3 箇所が中心です。

ポート系。port は HTTP プロキシポート、socks-port は SOCKS5 ポート、mixed-port は両方のプロトコルを 1 つのポートに統合します。システムプロキシや多くのアプリはいずれか片方しか認識しないため、混合ポートを使えばどちらを選ぶか迷う必要がありません。Clash Verge Rev はデフォルトで 7897 の混合ポートを使用します。redir-port と tproxy-port は Linux の透過プロキシ専用で、デスクトップ利用では空欄にします。

LAN。allow-lan: true で LAN からの接続を許可し、bind-address でリスニングするネットワークインターフェースを指定します。* は全インターフェースを意味します。スマホやテレビでパソコンのプロキシを共有する具体的な設定はブログの「混合ポートと LAN 共有プロキシの設定」を参照してください。開放は露出でもあるため、信頼できるネットワークでのみ有効にし、公共 Wi-Fi では false のままにしてください。

モード。mode は 3 択です。rule はルールに基づく振り分けで通常使用するモード、global はすべての通信を選択したプロキシグループ経由に、direct はすべて直接接続にします。GUI のモード切り替えは、このフィールドを書き換えているだけです。ルールのトラブルシューティングの基本手順は、まず global に切り替えてプロキシ経路自体が使えるか確認し、次に rule に戻してルールを段階的に検証することです。

ログと外部コントロール。log-level は silent から debug まで 5 段階あり、通常は info、トラブルシューティング時のみ一時的に debug にして、終わったら戻します。debug はログ量が多く、アクセスしたドメイン名も含まれます。external-controller はカーネルの RESTful API のリスニングアドレスで、GUI やサードパーティ製パネルはこれを通じてカーネルを操作します。リスニングアドレスをループバック以外に変更する場合は必ず secret も設定してください。設定しないと同一ネットワーク内の誰でもプロキシを操作できてしまいます。

動作の微調整。unified-delay: true は測定基準を統一し、プロトコルのハンドシェイクによる差異を排除することで、ノード間の遅延を正しく比較できるようにします。tcp-concurrent: true は候補アドレスへ並行して接続を試み、最速のものを採用します。find-process-mode はプロセス照合の挙動を制御し、PROCESS-NAME ルールがこれに依存します。profile.store-selected: true にすると、手動で選択したノードを再起動後も記憶します。ipv6: false は IPv6 環境が不安定な場合の「つながるのに開けない」問題によくある解決策です。

port: 7890
socks-port: 7891
mixed-port: 7897
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict
external-controller: 127.0.0.1:9090
secret: "your-secret"
profile:
  store-selected: true
  store-fake-ip: false

03DNS フィールド:解決経路と fake-ip

DNS を単独の章として扱うのは、振り分けの正しさの半分がここにかかっているからです。ルール内の GEOIP や IP-CIDR は、まず解決結果を得る必要があります。解決結果が汚染されていれば、振り分けも合わせて誤ります。dns.enable: true が前提条件で、false の場合はこの区分全体が無効になり、カーネルはシステムの名前解決に戻ります。fake-ip やポリシー解決はすべて機能しません。

リスニングとモード。listen はカーネル DNS サービスのリスニングアドレスを決定します。TUN モードでは問い合わせはカーネル内部で処理され、システム側で変更する必要はありません。enhanced-mode: fake-ip が主流の選択です。ドメイン名の問い合わせに対して即座に 198.18.0.1/16 プールから偽アドレスを返し、実際に接続する時点でカーネルがドメイン名でルールを照合するため、実際の名前解決の待ち時間を省け、ページの表示が明らかに速くなります。旧来の redir-host モードは mihomo から削除されており、古い設定に見つかれば削除してください。

fake-ip の境界。fake-ip-range はデフォルトで 198.18.0.1/16 で、社内ネットワークのセグメントと衝突する場合のみ変更が必要です。fake-ip-filter は偽アドレスを返さないホワイトリストです。LAN 内のドメイン、NTP 時刻同期、システムの接続確認は必ず含めてください。含めないと、プリンター、ルーター管理画面、時刻同期が原因不明に失敗することがあります。以下の例に頻出項目を示すので、そのままコピーし自分の社内ドメインを追加してください。

リゾルバのグループ。nameserver はデフォルトグループで、複数の記法に対応(下表参照)し、複数のサーバーへ並行して問い合わせ、最速の応答を採用します。proxy-server-nameserver はノードのドメイン名専用の解決先です。ノードのアドレス自体もドメイン名であることがあり、これを使って信頼できるリゾルバを指定することで「プロキシに接続しないと接続先のドメインが解決できない」という循環を避けられます。direct-nameserver は直接接続するドメイン向けで、通常は契約プロバイダや中国国内のパブリック DNS を指定します。

ポリシー解決。nameserver-policy はドメイン名に応じてリゾルバを振り分けます。キーには具体的なドメイン名、geosite: カテゴリ、rule-set: ルールセットを指定できます。中国国内のドメインは契約プロバイダの DoH、それ以外は信頼できる海外の DoH というような振り分けもここで表現します。旧フィールドの fallback は非推奨で、mihomo では nameserver-policy に置き換わっています。移行時は「どの種類のドメインにどのサーバー群を使うか」という発想で書き直してください。

その他のオプション。respect-rules: true にすると、海外リゾルバ自体もルールに従ってアウトバウンドされます。proxy-server-nameserver と併用が必要です。use-hosts と use-system-hosts は hosts テーブルの取得元を制御します。prefer-h3 にすると DoH の問い合わせが HTTP/3 を優先的に使用します。

dns:
  enable: true
  listen: 0.0.0.0:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"
  use-hosts: true
  use-system-hosts: true
  prefer-h3: true
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://doh.pub/dns-query
  direct-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://dns.cloudflare.com/dns-query
      - https://dns.google/dns-query

トラブルシューティングの手がかり。ページに「つながるのに開かない」「開くのが極端に遅い」「解決先の地域がおかしい」といった症状が出たら、まず DNS を確認してください。ログでドメイン名ごとの解決経路を確認し、どのリゾルバ群に渡ってどんな結果が返ったかを確かめてから、対応するフィールドを修正します。

04プロキシノードのフィールド:proxies 配列

proxies は配列で、1 要素が 1 ノードに対応します。すべてのノードは 4 つの基本フィールドを共有します。name、type、server、port。それ以外のフィールドは type によって決まります。type 固有のフィールド名を間違えても、カーネルはエラーを出さずそのまま無視するため、ノードが接続できないという結果だけが表れます。

name はノードの識別子です。ポリシーグループはこの名前で参照し、重複した場合は後に書いたものが上書きします。名前を変更するとそれを参照しているすべての箇所が無効になります。名前に半角スペース、コロン、# を含む場合は引用符で囲みます。server はドメイン名または IP アドレスを指定でき、ドメイン名の場合は proxy-server-nameserver が解決を担当します(前章参照)。

共通の任意フィールド。udp: true は UDP 転送を許可し、QUIC、ゲーム、音声通話に必要です。skip-cert-verify: true は証明書検証をスキップしますが、これは一時的な調査手段に限ります。tfo は TCP Fast Open を有効化します。interface-name は使用する送信インターフェースを指定でき、複数ネットワークインターフェースを持つマシンで役立ちます。

Shadowsocks

  - name: ss-node
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

cipher の代表的な値:aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305、2022-blake3-aes-128-gcm。plugin には obfs や v2ray-plugin を指定してトラフィックを偽装でき、パラメータは plugin-opts に記述します。

VMess

  - name: vmess-ws
    type: vmess
    server: vmess.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    servername: vmess.example.com
    network: ws
    ws-opts:
      path: /ray
      headers:
        Host: vmess.example.com
    udp: true

alterId は最近のサーバーではすべて 0 です。network は tcp、ws、grpc、h2、http に対応します。ws 伝送を使う場合、ws-opts 内の path と headers.Host はサーバー側と厳密に一致させる必要があり、1 文字でも違えば 400 エラーになります。

VLESS + Reality

  - name: vless-reality
    type: vless
    server: 192.0.2.10
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    client-fingerprint: chrome
    reality-opts:
      public-key: "your-public-key"
      short-id: "0123456789abcdef"

flow は xtls-rprx-vision のみ対応します。Reality の public-key と short-id はサーバー側の設定から取得し、client-fingerprint は chrome を推奨、servername はサーバーが偽装しているドメイン名を指定します。

Trojan

  - name: trojan-node
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: trojan.example.com
    alpn:
      - h2
      - http/1.1
    skip-cert-verify: false
    udp: true

sni はサーバー証明書のドメイン名と必ず一致させ、alpn は h2 と http/1.1 が一般的です。パスワードは認証情報そのものであり、流出すればノードが乗っ取られたことと同じです。

Hysteria2

  - name: hy2-node
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: "your-password"
    obfs: salamander
    obfs-password: "obfs-password"
    sni: hy2.example.com
    skip-cert-verify: false
    up: 50
    down: 200

QUIC を基盤とし UDP を強制するため、udp フィールドを書く必要はありません。obfs は現時点で salamander のみ対応し、パスフレーズは obfs-password に指定します。up、down の単位は Mbps で、実際の帯域より高く盛ると輻輳制御が逆効果になるため、実測値に基づいて設定してください。プロバイダの QoS 制限が厳しい場合は ports によるポートホッピングが使えます。

TUIC

  - name: tuic-node
    type: tuic
    server: tuic.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    alpn:
      - h3
    congestion-controller: bbr
    udp-relay-mode: native
    reduce-rtt: true
    sni: tuic.example.com

第 5 世代プロトコル。congestion-controller は bbr、cubic、new_reno から選択でき、パケットロスが多い回線では bbr がより安定します。udp-relay-mode のデフォルトは native、reduce-rtt: true にするとハンドシェイクの遅延が減ります。

WireGuard

  - name: wg-node
    type: wireguard
    server: 198.51.100.20
    port: 51820
    ip: 172.16.0.2
    private-key: "your-private-key"
    public-key: "peer-public-key"
    mtu: 1420
    udp: true

ip は割り当てられたトンネルアドレスです。private-key は自分側の秘密鍵、public-key は対向側の公開鍵で、取り違えないようにしてください。mtu は 1420 が一般的です。プロバイダによっては reserved の 3 バイト値が必要で、公式クライアントからエクスポートした値をそのまま使います。

サブスクリプション集約:proxy-providers

サブスクリプションから配布されるノードは proxy-providers が管理し、カーネルが定期的に取得して health-check でヘルスチェックを行います。ポリシーグループは use でグループ全体のノードを参照します。手書きのノードと provider 由来のノードは同じ設定内に混在させられます。

proxy-providers:
  provider-01:
    type: http
    url: "https://example.com/subscribe?token=xxxx"
    path: ./providers/provider-01.yaml
    interval: 86400
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300

フィールド確認の方法:ノードが接続できない場合、まず type に応じた小節の例を見つけ、フィールドを 1 つずつ照合してください。多く書いたフィールドは無視され、書かなかったフィールドはデフォルト値が使われ、書き間違えたフィールドは警告なしに無視されます。サブスクリプションのノードのフィールドはプロバイダの配布内容に従いますが、カーネル側のフィールド名は共通です。

05ポリシーグループのフィールド:proxy-groups

ポリシーグループは「通信を誰に任せるか」を決めます。ルールにはポリシー名だけを書き、ポリシー名の先にグループがあり、グループの中にノードがある——この 3 層の分離によって、ノードを変えてもルールは変えず、ルールを変えてもノードは変えずに済みます。

5 種類のタイプがあり、それぞれ挙動が異なります。

• select:手動選択。最上位の入口グループとして使うのに適しており、他のグループはその下に配置します。
• url-test:グループ内のノードの遅延を定期的に測定し最小のものを選択します。tolerance を 50(ミリ秒)に設定すると、遅延のわずかな揺れによるノード切り替えの往復を防げます。
• fallback:proxies の順序に従って最初にヘルスチェックを通過したノードを採用し、メインノードが復旧すれば自動で切り戻ります。
• load-balance:strategy は 3 択です。consistent-hashing は同じドメインを常に同じノードに固定しセッションが最も安定、round-robin はラウンドロビン、sticky-sessions は同一セッションを同一ノードに固定します。
• relay:通信は最初のノードに入り最後のノードから出ていきます。経路上のすべてのホップが利用可能である必要があり、どこか 1 か所でも切れると経路全体が切断されます。

共通フィールド。proxies にはノード名、use には proxy-providers の名前を列挙し、両者は混在できます。filter は正規表現でノード名を絞り込み(例:香港|HK)、exclude-filter は逆に除外、exclude-type はプロトコル種別で除外します。icon は GUI にアイコンを表示するため、hidden: true にするとそのグループを GUI で非表示にし、disable-udp: true にするとそのグループでの UDP 転送を禁止します。

速度測定関連。url のデフォルトは http://www.gstatic.com/generate_204 で、204 が返れば利用可能と判定します。interval の単位は秒で、短すぎると電力を消耗し長すぎると反応が鈍くなるため、300 が一般的な妥協点です。timeout は単発の測定タイムアウト、lazy: true(デフォルト)はグループが使われていなければ測定しないことを意味します。max-failed-times は連続何回失敗したらノードを利用不可と判定するかを制御し、expected-status は期待する HTTP ステータスコードを指定します。

ネスト。グループの proxies には別のグループ名を書くこともでき、「デフォルトプロキシ → 自動選択 → 各ノード」という 3 層構造はこうして組み立てます。rules では最上位のグループ名だけを参照すれば十分です。サブスクリプションから配布される設定には通常すでに複数階層のグループが含まれており、ノードを手動追加する際は最上位グループに追加すると経路全体に反映されます。

proxy-groups:
  - name: デフォルトプロキシ
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT
    use:
      - provider-01

  - name: 自動選択
    type: url-test
    use:
      - provider-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: フェイルオーバー
    type: fallback
    proxies:
      - 香港ノード
      - 日本ノード
    url: http://www.gstatic.com/generate_204
    interval: 120

  - name: ロードバランス
    type: load-balance
    use:
      - provider-01
    strategy: consistent-hashing
    url: http://www.gstatic.com/generate_204
    interval: 300

  - name: リレーチェーン
    type: relay
    proxies:
      - 入口ノード
      - 出口ノード

3 種類の自動グループの選び方の詳細——速度優先選択、フェイルオーバー、ロードバランスがそれぞれどんな場面に適しているか——はブログの「Clash のポリシーグループ、どれを選ぶべきか」を参照してください。グループ設計の原則はただ 1 つ、少なく精選することです。グループを増やすたびに保守コストが増え、グループ名はルールから参照されるため、名前を変えるとルールも合わせて変更する必要があります。

06ルール記法:上から順に、最初に一致したものが確定

ルールは振り分けの中枢であり、マッチングモデルはひと言に尽きます。上から順に評価し、最初に一致した時点で確定する。順序がそのまま優先度であり、MATCH は無条件で一致するため必ず最後の 1 行に置く必要があります。それ以降のルールは決して実行されません。

1 行のルールは 3 要素構成です。タイプ,パラメータ,ポリシー。一部のタイプでは 4 番目の要素 no-resolve を追加できます。ポリシーにはポリシーグループ名のほか、組み込みポリシーも指定できます。DIRECT は直接接続、REJECT は拒否してエラーを返す、REJECT-DROP は無応答で破棄、PASS は現在の分岐をスキップして評価を続行します(主に SUB-RULES と組み合わせて使用)。

ドメイン系と IP 系はここで大きく分かれます。ドメインルール(DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOSITE)は接続に含まれるドメイン名を直接照合するため名前解決は不要です。IP 系ルール(IP-CIDR、GEOIP、IP-ASN)は宛先 IP が必要で、ドメイン名による接続が IP ルールに到達した場合、カーネルは判定のために先に DNS 解決を強制的に行うことになります。4 番目の要素 no-resolve はこの解決を禁止するもので、ドメイン名による接続はそのルールをスキップし、純粋な IP 接続だけが評価対象になります。解決結果に基づいて明確に振り分けたい場合を除き、IP 系ルールにはすべて no-resolve を付けるべきです。

GEO データ。GEOSITE と GEOIP は geosite.dat と geoip.dat(または mmdb)というデータファイルに依存します。geodata-mode: true にすると dat 形式に切り替わります。これらのファイルはカーネルとともに更新され、欠落していると対応するルールが静かに一致しなくなり、振り分けが効かないという結果だけが表れます。

論理ルール

mihomo は AND、OR、NOT によるサブルールの組み合わせに対応し、サブルールは二重括弧で囲みます。

rules:
  - AND,((DOMAIN-SUFFIX,example.com),(PROCESS-NAME,chrome.exe)),デフォルトプロキシ
  - OR,((DOMAIN-KEYWORD,blog),(DOMAIN-SUFFIX,notes.io)),デフォルトプロキシ
  - NOT,((GEOSITE,cn)),デフォルトプロキシ

ルールセット:rule-providers

件数が多く更新頻度も高いルールは rule-providers という外部ルールセットに任せ、rules 内では RULE-SET,名前,ポリシー で参照します。behavior は 3 択で、domain(ドメインサフィックス)、ipcidr(IP セグメント)、classical(従来の 3 要素形式)です。

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

rules:
  - RULE-SET,ad-list,REJECT
  - MATCH,デフォルトプロキシ

プロセスマッチング。PROCESS-NAME と PROCESS-PATH は find-process-mode に依存します。Windows ではプロセス名に .exe 拡張子が付き、macOS と Linux では実行ファイル名を使用します。

並び順の原則:

• 厳密なものを先に、緩やかなものを後に:DOMAIN は DOMAIN-SUFFIX より先に、サフィックス系は GEOSITE より先に。
• LAN や社内ネットワークのセグメントは先頭に置き、直接接続としてプロキシを経由させない。
• 中国国内向け直接接続の締めには GEOSITE,cn と GEOIP,CN を使い、ドメインを 1 つずつ列挙しない。
• MATCH は常に最後に置き、メインのプロキシグループか DIRECT を指す。

rules:
  # LAN・社内ネットワークは直接接続
  - DOMAIN-SUFFIX,local,DIRECT
  - 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
  # プロセスとアプリ
  - PROCESS-NAME,steam.exe,ゲームアクセラレーション
  # ドメインルール、厳密なものを先に
  - DOMAIN,api.example.com,デフォルトプロキシ
  - DOMAIN-KEYWORD,telegram,デフォルトプロキシ
  # 分類ライブラリで締める
  - GEOSITE,category-games@cn,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  # 兜底ルール
  - MATCH,デフォルトプロキシ

07オーバーライドとマージ:サブスクリプション更新で変更を失わない

サブスクリプションファイルを直接編集すると必ずこの問題にぶつかります。サブスクリプションが更新されると変更内容がすべて失われるのです。Clash Verge Rev はこのために 3 段階の変更機構を用意しており、「何を変更するか、残すかどうか」で役割分担しています。

第 1 層、ファイル編集。設定ページのサブスクリプションカードを右クリックして「ファイルを編集」を選ぶと YAML の原文を直接編集でき、保存すればすぐ反映されますが、次回サブスクリプション更新時には上書きされます。一時的な検証やアイデア確認にのみ使い、検証が済んだ変更は以下の 2 層に移してください。

第 2 層、サブスクリプション単位の編集。右クリックの「ルールを編集」「プロキシを編集」「プロキシグループを編集」から、そのサブスクリプションのルール・ノード・ポリシーグループに前挿入または後挿入ができます。現在のサブスクリプションに紐づき、更新で上書きされないため最も日常的に使う層です。社内直接接続ルールの追加、自前ノードの追加などはここで行います。

第 3 層、グローバル拡張設定。設定ページ右上のメニューから開き、2 つの形態があります。Merge は YAML でマージの意図を宣言し、Script は JavaScript で設定オブジェクト全体を自由に書き換えます。すべての設定に適用され、サブスクリプションを切り替えても失われないため、サブスクリプションとは無関係な個人用の基本設定を置くのに適しています。

Merge:宣言的マージ

6 つの専用キーで配列のマージ方向を制御し、prepend は前方、append は後方に挿入します。ルールを前挿入すると、サブスクリプション本来のルールより早く一致することを意味します。それ以外のトップレベルキーは元の値をそのまま上書きします。mixed-port や mode のようなスカラー値は書いた値がそのまま採用され、dns のようなネストしたセクションは丸ごと置き換わるため、オーバーライド時はそのセクション全体を書き切ってください。半分だけ書くのは避けましょう。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
append-rules:
  - DOMAIN-KEYWORD,download,ダウンロード用グループ
prepend-proxies:
  - name: 自前バックアップ
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"
append-proxy-groups:
  - name: ダウンロード用グループ
    type: select
    proxies:
      - 自前バックアップ
      - DIRECT
mixed-port: 7897

Script:プログラムによる書き換え

条件分岐が必要な場合はスクリプトを使います。エントリポイントは main(config) に固定され、引数にはマージ後の完全な設定が渡され、戻り値がカーネルに渡される最終設定になります。

function main(config) {
  config["mixed-port"] = 7897;
  const extra = {
    name: "自前バックアップ",
    type: "ss",
    server: "203.0.113.10",
    port: 8388,
    cipher: "aes-256-gcm",
    password: "your-password"
  };
  config.proxies = config.proxies || [];
  config.proxies.push(extra);
  (config["proxy-groups"] || []).forEach(function (group) {
    if (Array.isArray(group.proxies)) {
      group.proxies.push("自前バックアップ");
    }
  });
  return config;
}

反映される順序は固定されています。サブスクリプション原文 → サブスクリプション単位の編集(ルール/プロキシ/プロキシグループ)→ グローバル Merge → グローバル Script → カーネル。トラブルシューティングはこの連鎖を逆にたどって確認します。まず実行時に最終的に反映されている設定がどうなっているかを確認し、そこから問題がどの層にあるかを特定していきます。

頻出のオーバーライド活用例:

• 社内ドメインの直接接続:prepend-rules に DOMAIN-SUFFIX ルールを追加し、前挿入で最優先に一致させる。
• 自前ノードを全グループに注入:Script で proxy-groups を走査して一括追加する。
• ポートの統一:Merge に mixed-port を 1 行書く。
• fake-ip-filter に社内ドメインを補完:dns セクション全体をオーバーライドし、サブスクリプションの filter リストをすべて写してから追加する。

他のクライアントと単体実行。Clash Plus、FlClash も同様に「サブスクリプション + ローカル変更」の機構を提供しており、考え方は同じで入口が異なるだけです。カーネル単体実行にはオーバーライド層がなく、原本ファイルを直接管理するため、Git で履歴を管理するのがおすすめです。複数デバイスで同一設定を運用する方法の比較はブログの「Clash 設定をマルチデバイスで同期する 3 つの方法」を参照してください。

08検証とトラブルシューティング:エラーからログまで

アクティブ化に失敗したら、まずエラー内容を読みます。Clash Verge Rev は設定をアクティブ化する際にカーネルが完全な解析を行い、エラーメッセージには行番号と原因が示されます。その行番号を手掛かりにファイルへ戻れば、9 割の問題はこの段階で特定できます。エラーが省略表示されている場合は、ログページで完全な出力を確認してください。

YAML の頻出エラーを、発生頻度の高い順に紹介します。

• Tab インデント:エディタの設定で Tab をスペースに変換し、ファイル全体でスペース 2 個に統一してください。
• コロンの後にスペースがない:port:7890 は不正な記法です。
• パスワードに # を含み引用符を付けていない:# 以降の内容がコメントとして扱われ、パスワードが途中で切れてしまいます。
• リストのインデントのずれ:- と親キーの従属関係が崩れ、ノードが別のキーの下に入り込んでしまいます。
• ノード名の重複:後に書いたものが前のものを上書きし、ポリシーグループから参照できるのは 1 つだけになります。
• 存在しないポリシー名をルールが参照:アクティブ化時に proxy not found エラーとなるので、グループ名のスペルを確認してください。

ログは第二の現場です。log-level を一時的に debug に上げれば、カーネルのログページで各接続がどのルールに一致し、どの出口を通ったかを確認できます。画面各部の機能はブログの「Clash Verge Rev 画面機能ひと目ガイド」を参照してください。調査が終わったら info に戻しましょう。

「変更しても反映されない」を順番に確認する手順:

1. ファイルを変更したものの、設定ページで再アクティブ化していないため、カーネルはまだ古い設定で動いている。
2. 変更したのはサブスクリプション原文だが、オーバーライド層がそれを元に戻してしまっている——実行時に最終的に反映されている設定を確認する。
3. 設定は正しいが、GUI が古いカーネルプロセスに接続したままになっている。カーネルを再起動するか再接続する。
4. システムプロキシや TUN が有効になっておらず、通信がそもそもカーネルに入っていないため、何を変更しても効果がない。

ポートと LAN。bind: address already in use と表示されるのはポートが使用中というエラーです。mixed-port を変更するか、使用中のプロセスを終了してください。allow-lan は有効なのにスマホから接続できない場合は、まずパソコン側のファイアウォールがそのポートを許可しているか確認し、次に両者が同一ネットワークにあり、パソコンの内部 IP を入力しているかを確認してください。

fake-ip の異常。銀行、官公庁・企業システム、一部のアンチチート付きゲームなど、一部のアプリは偽アドレスに敏感です。該当ドメインを fake-ip-filter に追加し、direct-nameserver を設定し、必要であればそのルール全体を直接接続にしてください。追加後は設定を再アクティブ化すれば反映されます。

TLS と時刻。証明書関連のエラーが出たら、まずシステム時刻を確認してください。数分のずれでもハンドシェイクが必ず失敗します。skip-cert-verify は一時的な調査手段に過ぎないので、経路を確認したら false に戻してください。

DNS の漏洩と汚染。漏洩が疑われる場合は次の順で確認します。nameserver がすべて信頼できる経路を通っているか、proxy-server-nameserver が設定済みか、respect-rules が意図どおりに動作しているか、nameserver-policy の geosite キーのカテゴリ名が正しく書かれているか——カテゴリ名を書き間違えるとエラーは出ずに黙って機能しなくなります。

最後に。それでも解決しない場合はよくある質問ページのカテゴリ別一覧をひと通り確認してください。クライアントのダウンロードとカーネルの説明はダウンロードページ、選び方の比較はクライアント比較ページにあります。