CONFIG REFERENCE

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

1つのYAMLファイルがClashの動作をすべて決めます。どのポートで待ち受けるか、どのノードを使うか、どの通信を直接接続にするか、ドメインをどう解決するか。このページでは実際の設定ファイルの構造に沿ってフィールドと文法を1つずつ分解し、各項目にそのまま使える例を用意しました。導入後も長く使えるリファレンスとして活用してください。

まだインストールやサブスクリプションの導入が済んでいない場合は、先に使い方ガイドで基本的な流れを一通り終えてから本ページで細部を確認することをおすすめします。インストーラーが必要な場合はダウンロードページから各プラットフォーム向けクライアントを入手してください。本ページは、すでに通常のネット接続ができていて、設定ファイルの内容を理解し自分で編集したいユーザーを対象にしています。

mihomo コア · YAML · rule-based

第1章 リファレンスの使い方とYAML構造の全体像

Clash系クライアント(および実行コアであるmihomo)は、YAML形式の設定ファイルを読み込んですべての動作を決定します。サブスクリプションリンクの正体は、サーバー側にホストされ随時取得・更新できる設定ファイルそのものです。クライアント画面上のあらゆるスイッチも、最終的にはこのファイルのどこかのフィールドに反映されます。この構造を理解すれば、サブスクリプションの内容・クライアントの設定項目・コアのログという3つの対応関係が同時に把握でき、問題を切り分ける際にあちこちの画面を無駄にいじる必要がなくなります。

本ページと使い方ガイドの役割分担は「導入は軽く、リファレンスは重く」です。ガイドはサブスクリプションの導入から接続確認までの一連の流れを担当し、本ページはその流れの外側で「このフィールドは何を意味し、どう書けるか」を体系的に説明します。両者は補完関係にあるので、ガイドで簡単に触れられたフィールドについては上の目次から該当章に飛んでください。

トップレベル構造:5つのブロック

設定ファイル全体は、おおまかに上から5つのブロックで構成されています。ファイル内での記述順は解析結果に影響しませんが、ほとんどのサブスクリプションは下表の順で構成されているため、他人の設定ファイルを読む際もこの順番で見当をつけると早く目的の箇所が見つかります。

ブロック役割代表的なフィールド
基本項目ポート、動作モード、ログ、LAN共有などのグローバルな動作mixed-port、mode、log-level
dnsコアがドメイン解決を行う方式(Fake-IPを含む)enhanced-mode、nameserver
proxies利用可能なプロキシノードとそのプロトコルパラメータを列挙type、server、port
proxy-groupsノードを選択・速度測定可能なプロキシグループとしてまとめるtype: select、url-test
rules通信を順に照合し、どのプロキシグループを使うか決定DOMAIN-SUFFIX、GEOIP、MATCH

YAML文法の鉄則3つ

YAMLは書式に非常に敏感で、設定エラーの9割は文法の問題であり、フィールドの問題ではありません。書く前に次の3点を必ず覚えておきましょう。1つ目、インデントはスペースのみを使うこと。Tab文字が1つ混入するだけでファイル全体の解析が失敗し、しかもエラー行番号がずれて実際より後ろの位置を指すことが多く、気づきにくいです。2つ目、コロンの後には必ず半角スペースを1つ入れること。port:7890は不正な書き方で、port: 7890が正しい形です。3つ目、ノード名に絵文字・シャープ記号・引用符が含まれる場合や特殊文字で始まる場合は、文字列全体をダブルクォートで囲むこと。そうしないとコメントや構文として誤解釈される可能性があります。行頭の#はコメントを意味し、あるルールを一時的に無効化したいときは削除するより行頭に#を付けるほうが安全です。用語に不安がある場合は用語集の「サブスクリプションと設定」カテゴリを参照してください。

第2章 基本項目:ポート・モード・起動パラメータ

基本項目はファイルのトップレベルにあり、いずれのインデントブロックにも属さず、コアの動作全体を決定します。以下はそのまま使える最小構成の例です。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

ポート系フィールド:mixed-portとその仲間たち

mixed-portは現在最も一般的なポート設定で、同じポート上でHTTPとSOCKS5の両方の受信接続を受け付けます。システムプロキシはこのポートを指定するだけでよく、別々に設定する必要はありません。従来の設定でよく見るport(HTTP専用)やsocks-port(SOCKS5専用)も現在も有効で、2つのプロトコルを別々のソフトに割り当てたい場合に向いています。ほかにredir-portとtproxy-portがあり、これらはLinux上の透過プロキシやルーター用途向けで、一般的なデスクトップ利用では設定不要です。ポート番号は1024未満のシステム予約領域を避けてください。起動時のログにbind: address already in useと出た場合は、そのポートを別のプロセス(終了していない別のプロキシプロセスであることが多い)が使用中という意味なので、ポート番号を変えるか、使用中のプロセスを終了させてください。

mode:3つの動作モード

値動作適用場面
rule各接続をrulesブロックで1つずつ照合して振り分ける日常使いの標準設定。速度と精度のバランスが良い
globalルールを無視し、全通信を選択中のグローバル方針に流すあるノードが使えるかを一時的にテストする
direct全通信を直接接続にし、いずれのノードも経由しない「本当にプロキシの問題なのか」を切り分ける

クライアント画面の「ルール/グローバル/直接接続」切り替えボタンが操作しているのはこのフィールドです。トラブル時はまずdirectに切り替えてローカルネットワークが正常か確認し、次にglobalに切り替えてノードが使えるか確認し、最後にruleに戻ってルールを検証する、という3段階の切り分けが最も早い方法です。

その他の頻出フィールド

allow-lanをtrueにすると、同じLAN内の他デバイスが本機のポートをゲートウェイプロキシとして指定でき、テレビボックスやゲーム機でプロキシを共有できます。有効にする場合はbind-addressで監視するネットワークインターフェースを絞ることをおすすめします。公共のネットワーク上でポートを見知らぬデバイスにさらしてしまうのを防げます。log-levelは詳細から静かな順にdebug、info、warning、error、silentがあり、ルールのマッチ状況を調べる際は一時的にdebugにすると、各接続がどのルールに命中したかがログで確認できます。external-controllerはRESTfulインターフェースを開放し、パネル系ツールが状態取得やノード切り替えを行えるようにします。secretフィールドを設定している場合はアクセス時に同じ鍵が必要で、例ではsecret: "xxxx"のような仮の値を使います。ipv6はデフォルトで無効で、IPv6環境が不完全なネットワークでうかつに有効化すると解決タイムアウトの原因になります。

第3章 DNSブロック:解決モードとFake-IP

「ルールは正しく書いているのに効かない」「特定サイトが繋がったり切れたりする」といった問題の多くは、実はDNSに原因があります。コアが独自のDNS設定を持つのは、振り分けルールの多くがドメイン名や地理的位置に基づく判断だからです。この解決の段階が汚染されたりコアを経由しなかったりすると、以降のルールマッチングは誤った答えに基づいて判断することになります。以下はよく見るDNSブロックです。

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"
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

enhanced-mode:fake-ipとredir-host

fake-ipモードでは、コアはドメイン名の問い合わせを受けても実際の解決を行わず、fake-ip-rangeで指定された予約セグメント(デフォルトは198.18.0.1/16)から「仮のアドレス」を1つ返し、ドメイン名と仮アドレスの対応を記憶します。アプリが実際にこの仮アドレスへ接続を試みると、コアはその対応関係からドメイン名を復元してルールマッチングを行います。利点は解決待ちの時間が省け、ドメインルールの命中率が非常に高くなることです。代償として、実際のIPに依存する一部の場面(LAN内デバイスの検出、一部のゲームのオンライン対戦、IPを返す必要がある認証サービスなど)では仮アドレスが渡ってエラーになります。これこそがfake-ip-filterの存在意義で、ここに列挙したドメインは仮アドレスのロジックをスキップし、実際の解決結果を返します。redir-hostモードは常に実際のIPを返すため互換性は高い一方、解決経路が長くなります。両モードの詳しい原理比較はブログ記事「Fake-IPモードとは何か」を参照してください。

nameserverとfallbackの役割分担

nameserverはデフォルトの上流サーバーで、通常は地理的に近く応答が速いサーバーを指定します。fallbackは代替の上流サーバーで、fallback-filterがデフォルトの上流サーバーからの結果を疑わしいと判定した場合(例:geoip: trueのとき、海外ドメインなのに現地のIPが返ってきた場合など)に代替結果を使用します。上流アドレスは4種類の書き方に対応しています。プレーンIP(UDP 53)、tls://(DoT)、https://(DoH)、quic://(DoQ)で、暗号化された書き方を使うと解決リクエストが経路上で改ざんされるのを防げます。nameserverには直接接続で解決できるアドレスを少なくとも1つ含める必要があります。そうしないと「鶏が先か卵が先か」問題(プロキシサーバーのドメイン自体の解決にもDNSが必要)に陥ります。

注意enhanced-modeを切り替えたりfake-ip-rangeを変更したりした後、システムやブラウザに古い解決結果のキャッシュが残っていることがあり、設定を変えたのにネットに繋がらなくなるという症状が出ます。クライアントを再起動し、システムのDNSキャッシュをクリア(Windowsではipconfig /flushdnsを実行)してから再度確認してください。

第4章 プロキシノードのフィールド:proxiesの各項目解説

proxiesはリスト形式で、各要素が1つのノードを表します。通常のサブスクリプション利用ではこの部分はサブスクリプションサーバー側で生成され、自分で書く必要はほぼありません。ただし理解しておくことには2つの実用的な価値があります。1つはノードが繋がらないときにフィールドレベルで原因を切り分けられること(ポートの誤り、トランスポート層パラメータの不足、暗号方式の不一致など)、もう1つは自前のノードを一時的に追加したいときに変換ツールに頼らずに済むことです。すべてのプロトコルに共通する4つの基本フィールドがあります:name(グループ内で参照する一意の識別子。重複すると解析に失敗します)、type(プロトコル種別)、server、portです。udp: trueはそのノードがUDP通信を転送することを示し、音声通話やゲーム系アプリはこれに依存します。

3つの代表的なプロトコルのフィールド構成

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

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

  - name: "例-Trojan"
    type: trojan
    server: node3.example.com
    port: 443
    password: "your-password"
    sni: node3.example.com

Shadowsocks(ss)の要点はcipherとpasswordがサーバー側と完全に一致していることで、暗号方式が1文字違うだけで接続は静かに失敗します。VMessはuuidを認証情報として使い、alterIdは現行のプロトコルでは0固定です。networkはトランスポート層の形式を決め、wsを指定する場合はws-optsでパスとHostヘッダーを合わせて指定する必要があり、grpcを指定する場合は対応するgrpc-optsが必要です。Trojanは元々TLS上で動作するため、sniが証明書のドメインと一致しないとハンドシェイクが拒否されます。自己署名証明書のテスト環境ではskip-cert-verify: trueを追加できますが、本番環境での利用は推奨しません。

mihomo拡張プロトコル

現在主流の実行コアであるmihomoは、上記の従来プロトコルに加えてVLESS、Hysteria2、TUICなどの新しいプロトコルにも対応しており、それぞれ独自のフィールドセットを持ちます(Hysteria2のup/down帯域指定など)。利用可否はクライアントに内蔵されたコアのバージョンに依存します。これはクライアント比較ページでmihomoコアベースのクライアント(全プラットフォーム対応のClash Plus、デスクトップ向けのClash Verge Revなど)を優先的に推奨している理由の1つでもあります。古いコアのクライアントは新しいプロトコルのノードに遭遇すると「unsupport proxy type」とエラーを返し、設定ファイル全体の読み込みを拒否してしまいます。

第5章 プロキシグループのフィールド:proxy-groupsの4種類

proxiesが原材料だとすれば、proxy-groupsはその原材料を「判断単位」としてまとめる層です。ルールはノードを直接指すのではなくプロキシグループを指し、グループ内のロジック(手動選択や自動速度測定)によって最終的な出口が決まります。この設計により、「ノードを切り替える」際にルールを1つも変更する必要がなくなります。4種類のグループの動作は以下の通りです。

type決定方式主なフィールド
selectクライアント画面でユーザーが手動選択proxies
url-test定期的に遅延を測定し、最速のメンバーを自動選択url、interval、tolerance
fallbackリスト順に最初に使える有効なメンバーを採用url、interval
load-balance接続を複数のメンバーに分散strategy
 
proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - 自動速度測定
      - 例-SS
      - 例-VMess
      - DIRECT

  - name: "自動速度測定"
    type: url-test
    url: http://cp.example.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - 例-SS
      - 例-VMess

フィールドの詳細とネストのコツ

自動系グループのurlには204ステータスコードを返す軽量なアドレスを指定します(各クライアントにデフォルトの測定用アドレスが内蔵されているため、未指定でもデフォルト値が使われます)。intervalは秒単位で再測定の周期を制御し、300が一般的な値です。toleranceは切り替えのしきい値で、新旧ノードの遅延差がこのミリ秒数未満なら切り替えません。遅延が近い2つの経路が頻繁に往復して接続が切れ続けるのを防ぐためです。lazy: trueにすると、グループが未使用の間は速度測定をスキップし、ノード数が多い場合はバックグラウンド通信を大きく削減できます。グループのメンバーにはノード名だけでなく、別のグループ名や組み込みのポリシーDIRECT(直接接続)、REJECT(接続拒否)も指定できるため、「手動グループの中に自動グループを入れる」といった階層構成も可能です。普段は「自動速度測定」に任せておき、必要なときだけ手動で特定のノードに固定する、という使い方ができます。避けるべきは2つのグループが互いを参照して循環を作ることで、コアは起動時にエラーを出して読み込みを拒否します。グループ名もファイル全体で一意である必要があり、ルールから直接参照されるため、グループ名を変更する際はそれを参照しているすべてのルール行も同時に修正してください。

第6章 ルール文法:rulesのマッチングと優先順位

rulesは振り分けを決定する層です。新しい接続が発生するたびに、コアはリストの先頭から1つずつ照合し、命中した時点で処理を止め、それ以降のルールは評価されません。したがってルールを書く順番そのものが優先順位であり、同じルール群でも順番を変えると振り分け結果がまったく変わることがあります。各ルールの共通フォーマットは種別,マッチ値,方針で、方針にはグループ名、ノード名、または組み込みのDIRECT/REJECTを指定できます。

rules:
  - DOMAIN,dl.example.com,ノード選択
  - DOMAIN-SUFFIX,example.org,ノード選択
  - DOMAIN-KEYWORD,tracker,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - RULE-SET,ads,REJECT
  - MATCH,ノード選択

ルール種別の対照表

種別マッチ対象説明
DOMAINドメイン名が完全一致最も厳密で、1つのドメインのみに命中
DOMAIN-SUFFIXドメイン名の接尾辞そのドメインとすべてのサブドメインに命中。最も一般的
DOMAIN-KEYWORDドメイン名にキーワードを含む適用範囲が最も広く誤爆しやすいので慎重に
IP-CIDR / IP-CIDR6宛先IPのネットワークセグメントno-resolveと組み合わせる使い方は後述
GEOIP宛先IPの地理的な帰属GeoIPデータベースに依存
GEOSITEドメイン分類データベースGeoSiteデータベースに依存
PROCESS-NAME接続元のプロセス名デスクトップ環境でソフト単位の振り分け
RULE-SET外部ルールセットrule-providersで定義した集合を参照
MATCH無条件に命中最終的な受け皿ルール。必ず最後に置く

no-resolveと並べ方の原則

IP系のルールはデフォルトで、宛先IPを取得するために一度ドメイン名解決を行ってから照合します。もしこのルールが「もともとIPで直接接続する」通信(LANのネットワークセグメントなど)だけを対象にしたいのであれば、この解決は無駄であるだけでなく、各接続を遅くする原因にもなります。ルールの末尾にno-resolveパラメータを追加すれば、「宛先がドメイン名の場合はこのルールをスキップする」と宣言できます。並べ方については2つの原則があります。厳密でコストの低いもの(DOMAIN系)を前に、解決やデータベース参照が必要なもの(GEOIP)を後ろに置くこと。拒否系のルールはできるだけ前に置き、広告リクエストがより重いマッチング処理に入る前に弾かれるようにすること。GEOSITEとGEOIPの判定精度はローカルデータベースの新旧に依存し、長期間更新しないと振り分けが不正確になります。更新方法の詳細はブログ記事「GeoIPとGeoSiteデータベースが古くなったときの対処法」を参照してください。

デバッグのコツある接続がどのルールに命中したかを確認したい場合は、log-levelを一時的にdebugにするか、クライアントの接続パネルで各アクティブ接続に表示されるルールの出典を確認するのが、1つずつ推測するより効率的です。

第7章 サブスクリプションとルールセット:proxy-providersとrule-providers

数百件のノードや数万行のルールを主設定ファイルに直接書き込むと、肥大化して更新もしづらくなります。Providerの仕組みはこれらを独立して取得・キャッシュし、周期的に自動更新できる外部リソースとして切り出します。主設定ファイルは「参照」のみを担当し、内容自体はリモートでホストされます。これは現代のサブスクリプションの標準的な形態で、あなたが使っているサブスクリプションリンクも、多くの場合はproxy-providersの意味でのノード一覧そのものです。

proxy-providers:ノードのホスティング元

proxy-providers:
  main:
    type: http
    url: "https://sub.example.com/subscribe?token=xxxx"
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: http://cp.example.com/generate_204
      interval: 600

type: httpはリモートから取得することを示し、urlとローカルキャッシュのパスpathを組み合わせて指定します。type: fileはローカルファイルを直接読み込む方式で、手動管理する自前のノード一覧に向いています。intervalは自動再取得の間隔を秒単位で制御し、health-checkを使うとコアが定期的に一覧内のノードの生存確認を行い、プロキシグループの選定に利用します。プロキシグループでProvider内のノードを使う場合は、proxiesフィールドの代わりに(または併用して)useフィールドを使います。

proxy-groups:
  - name: "サブスクリプションノード"
    type: url-test
    use:
      - main
    url: http://cp.example.com/generate_204
    interval: 300

rule-providers:ルールセットのホスティング

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

ルールセットで最も陥りやすい罠は、behaviorとファイルの内容が一致しないことです。値は3種類あります:domain(ファイルの中身が全てドメイン)、ipcidr(全てネットワークセグメント)、classical(各行が「種別,値」の完全なルール)。リモートファイルの実体がドメイン一覧なのにclassicalと宣言してしまっても読み込み時にエラーは出ませんが、1件も命中せず、原因がわかりにくくなります。formatはyamlとtextに対応し、mihomoではさらに容量が小さく読み込みも速いバイナリ形式のmrsにも対応しています。宣言した集合はRULE-SET,ads,REJECTのようなルール行として主ルール表に組み込まれ、ルールセットの更新に主設定ファイルの修正が不要になる点が長期運用における最大の利点です。例中のtoken=xxxxは仮の値で、実際には契約しているサブスクリプションサービスが提供する完全なリンクを使用してください。

第8章 オーバーライドと合成:サブスクリプション更新でローカルの変更を消さない方法

サブスクリプションから配信された設定ファイルを直接編集すると、致命的な問題が起こります。次回サブスクリプションが自動更新されると、リモートの内容がファイル全体を上書きし、手動で追加したルールやDNSの変更がすべてリセットされてしまいます。オーバーライド(Override)と合成(Merge)の仕組みは、まさにこの問題を解決するためのものです。「あなたの変更」と「サブスクリプションの内容」を別々に保存し、サブスクリプション更新のたびにクライアントが自動的に変更を再度重ね合わせます。設定を変更する前に、使っているクライアントがどの仕組みに対応しているかを確認しましょう。

クライアント仕組み説明
Clash Plus(第一推奨)オーバーライド設定全プラットフォームで統一されたオーバーライド機能。サブスクリプションごとに個別に適用
Clash Verge RevMerge + ScriptYAML宣言型の合成。複雑なロジックはスクリプトで書き換え可能
FlClashオーバーライドパネルよく使うフィールド(ポート/DNS/ルール)をGUIでオーバーライド
Clash Meta for Android設定の追加設定モバイル版では基本的なフィールド上書き機能を提供

宣言型合成の書き方

Clash Verge RevのMergeを例にすると、合成用ファイル自体も1つのYAMLです。トップレベルに直接書かれたフィールド(mixed-portなど)は、サブスクリプション内の同名フィールドを丸ごと置き換えます。prepend-/append-接頭辞が付いたフィールドは、サブスクリプション側の対応するリストの先頭または末尾に内容を挿入するもので、サブスクリプションのルールより前に自分の高優先度ルールを追加する際によく使われます。

mixed-port: 7893

prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - PROCESS-NAME,steam.exe,ノード選択

append-proxies:
  - name: "自前-バックアップ"
    type: ss
    server: node9.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

「ルール表の先頭にprependする」という点は特に重要です。ルールは命中した時点で処理が止まるため、サブスクリプションのルールより前に置かれてはじめて、あなたの独自ルールが先にマッチする機会を得られます。辞書型フィールド(dnsなど)の合成が丸ごと置き換えなのか、キーごとの合成なのかはクライアントの実装によって多少異なるため、設定後は必ず既知の通信で動作を検証してください。各クライアントのオーバーライド機能の位置や操作の違いはクライアント比較ページにまとめてあります。Windowsでのインストールからサービスモードまでの手順は、ブログ記事「Windows で Clash Verge Rev を使う」を参照してください。

おすすめオーバーライド用ファイルは「最小限の変更」に留めましょう。本当に変えたいフィールドだけを書き、サブスクリプション全体をコピーして書き換えるようなことは避けてください。変更が少ないほど、サブスクリプションの構造が変わったときの衝突も減り、問題がどの層で起きているかも見分けやすくなります。

第9章 よくあるエラーと設定チェックリスト

設定の読み込みに失敗した場合、コアのログに出るエラーは既に問題の種類を示していることが多いので、まずログを読んでからファイルを修正すると、あてもなく試行を重ねる時間を大幅に節約できます。頻出エラーの当てはめ方はこうです。yaml: line Nで始まるものは文法エラーなので、N行目付近のインデント(混入したTabを特に確認)とコロン後のスペースを確認してください。proxy not foundやproxy group ... not foundは、プロキシグループやルールが存在しない名前を参照していることを示しており、多くはノード名を変更した際に参照側を同期し忘れた場合や、名前中の空白・絵文字が完全一致していない場合です。unsupport proxy typeは、現在のコアが認識できないプロトコルが設定に含まれていることを示し、クライアントを更新するかそのノードを削除してください。bind: address already in useはポートが使用中であることを示し、第2章を参照してください。ルールセットが「読み込みは成功するが一度も命中しない」場合は、まず第7章で説明したbehaviorの宣言と内容の不一致を疑ってください。

設定変更の前後で行う7つのセルフチェック

  1. 変更前にバックアップを取る:現在正常に動作している設定ファイルを複製しておけば、変更で問題が起きても一手で元に戻せます。コストが最も低い保険です。
  2. 文法チェックを通す:保存したらすぐにクライアントで設定を再読み込みし、読み込みが成功してから効果を確認しましょう。読み込みに失敗したら、まずログの行番号に沿って文法を直し、文法エラーを残したまま変更を重ねないでください。
  3. 名前の一致を確認する:参照されているノード名やグループ名を全文検索し、proxies、proxy-groups、rulesの3箇所で表記が引用符内の空白まで含めて完全に一致しているか確認してください。
  4. ルールの並び順を確認する:MATCHが最後の行にあること、拒否系ルールが十分前に置かれていること、独自ルールがサブスクリプションのルールより前に来ていること(オーバーライド使用時はprependになっているか)を確認してください。
  5. DNSの挙動を確認する:Fake-IPを有効にした後、LAN内のプリンターや画面キャストなどのローカルサービスが正常に動くか確認し、動かない場合は該当ドメインをfake-ip-filterに追加してください。
  6. 3モードで切り分ける:「繋がらない」場合はまずdirectに切り替えてローカルネットワークの問題を除外し、次にglobalに切り替えてノードの問題を除外し、最後にruleに戻ってルールを確認する、という手順で一度に1つの変数だけを変えてください。
  7. 更新1サイクルを観察する:サブスクリプションが自動更新された後も、オーバーライドの内容が引き続き有効で、ポートやDNSの設定がデフォルト値に戻っていないか確認してください。

チェックリストを一通り確認しても原因が分からない場合は、使い方ガイドに戻って基本的な流れに漏れがないか確認してください。初回インストール時の一般的な確認項目はブログ記事「Clash 初回インストール時にやっておきたい7つの初期設定」を参考にしてください。クライアント自体のバージョンが古いことも様々な互換性トラブルを引き起こす原因になるため、ダウンロードページで最新版に更新してから再度確認するのは、トラブル対応の中でも特に効果の高いステップです。

Clash をダウンロード