Clash設定ファイルYAMLマニュアル

01設定ファイル概要:YAML構文とトップレベル構造

Clashの設定はYAML形式です。YAMLはインデントで階層を表現し、規則は多くありませんがどれも破ってはいけません:インデントは統一してスペースを使い(習慣的には2スペースで1階層)、タブは禁止。キーと値の間のコロンの後には必ずスペースを1つ入れます。リストの項目は「ハイフン+スペース」で始まり、#から行末まではコメントです。文字列は通常引用符が不要ですが、値にコロンや井桁、波括弧などの特殊文字が含まれる場合、または数字や*、~で始まる場合は引用符で囲むべきです。そうしないと解析結果が期待と異なる可能性があります——パスワード、サブスクリプションURL、ワイルドカードドメインの3種類は必ず引用符で囲むことを推奨します。

設定ファイルはどこにあるか

GUIクライアント(Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなど)は設定ディレクトリを自前で管理します。サブスクリプションをインポートするとプロファイルとして保存され、確認や変更はクライアント内蔵のエディタや上書き機能で行うため、通常はファイルシステム上のパスを手動で探す必要はありません。コアを直接実行するユーザー(サーバーやルーターの用途)は、作業ディレクトリからconfig.yamlを既定で読み込みます。Linuxでの慣例的なパスは~/.config/mihomo/config.yamlで、-fパラメータでファイルを明示的に指定したり、-dで作業ディレクトリを指定することもできます。

トップレベルブロック一覧

完全な設定ファイルは複数のトップレベルブロックから構成され、それぞれが担当領域を持ち、互いに干渉しません。以下の表は全体の地図であり、以降の章はこの順序で解説していきます:

最小構成の例

以下の設定はすべての任意項目を取り除き、「1つのインバウンドポート、1つのノード、1つのプロキシグループ、3つのルール」だけを残した、文法チェックを通過し正常に動作する最小骨格です。これを理解すれば、以降の各章はこの骨格に肉付けしていく作業になります:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "サンプルノード"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この3つのブロックの連携関係:proxiesは「どの出口があるか」を定義し、proxy-groupsは出口を「どう選ぶか」に組織化し、rulesは「どのトラフィックをどのグループに渡すか」を決定します。ルールの出口はグループ名でも構わず、ノード名や組み込みのDIRECT(直接接続)、REJECT(拒否)を直接書くこともできます。この骨格をもっと分かりやすく段落ごとに解説した記事は、ブログの《Clash設定ファイル構造の段落別解説》を参照してください。

02共通フィールド:ポート、モード、動作制御

共通フィールドは設定ファイルの最上部にあり、どのブロックにも属さず、コアが「どのような姿勢で動作するか」を決定します。これらの誤りは振り分けの異常には直結しませんが、接続できない、間違ったポートに繋がる、あるいはログが延々と流れるといった問題を引き起こすため、1つずつ理解する価値があります。

インバウンドポートとLAN共有

portはHTTPプロキシを監視し、socks-portはSOCKS5を監視します。一方mixed-portは同じポートで両方のプロトコルを受け付けます——現代的な設定では基本的にmixed-port: 7890の1行だけを書き、2つのポートを維護するコストを省きます。Linux専用のredir-portとtproxy-portは透過プロキシの用途で使い、デスクトップユーザーは無視して構いません。allow-lanはLAN内の他デバイスからの接続を受け付けるかを制御します:trueにすると、同じWi-Fi上のスマートフォンやテレビがこの機器をプロキシの宛先に指定できます。bind-addressはさらに監視するネットワークインターフェースのアドレスを限定し、既定値の"*"は全てのインターフェースを表します。

mode:3つの動作モード

modeには有効な値が3つしかありません。ruleはrulesブロックに従って1件ずつマッチングして振り分ける、日常的に唯一推奨されるモードです。globalは全てのトラフィックを同じ出口に流すもので、単一ノードのテスト時に一時的に使うだけです。directは全て直接接続するモードで、監視ポートは維持しつつプロキシ処理は一切行いません。この3つのモードはクライアントの画面上にも対応するスイッチがあり、意味は設定フィールドと完全に一致します。操作面での選び方はチュートリアルページの第2ステップを参照してください。

ログ、外部コントロール、状態の永続化

log-levelは少ない方から多い方へsilent、error、warning、info、debugの順です。通常はinfoを使い、振り分けの問題を調査するときだけ一時的にdebugに切り替えます。すると各接続がどのルールにマッチしたかが見えるようになりますが、調査が終わったら戻すのを忘れないでください。そのままにするとログファイルが急速に肥大化します。external-controllerはRESTful API(慣例として127.0.0.1:9090で監視)を有効にし、Webパネルやサードパーティツールはこれを通じて状態を読み取りノードを切り替えます。secretはこのAPIへのアクセス用パスワードで、監視アドレスをローカルに限定しない場合は必ず設定してください。profileブロックは2つの永続化を制御します:store-selectedは各プロキシグループで前回手動選択したノードを記憶し、再起動しても失われません。store-fake-ipはfake-ipのマッピングテーブルをディスクに保存し、再起動後の解決のばらつきを減らします。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "your-secret"
profile:
  store-selected: true
  store-fake-ip: true

03dnsブロック:ドメイン名解決とfake-ip

振り分けルールの多くはドメイン名でマッチングしますが、ドメイン名解決自体が汚染されたり乗っ取られたりする可能性があります——コアがシステムDNSの結果をそのまま使ってしまうと、ルール判定も実際の接続も偏ってしまいます。dnsブロックはコア自身に解決を担わせるものです:どのアップストリームを使うか、暗号化通信を経由するか否か、fake-ipを有効にするかどうかを、すべてここで宣言します。TUNモードを有効にする場合はこのブロックを必ず有効化する必要があります。そうしないと乗っ取ったDNSクエリを処理する先がありません。

enhanced-mode:fake-ipとredir-host

fake-ipは現在の主流モードです:アプリケーションがドメイン名クエリを発行すると、コアは即座にfake-ip-range(慣例では198.18.0.1/16)から偽アドレスを1つ取って返し、同時に「偽アドレス↔ドメイン名」のマッピングを記録します。アプリケーションが偽アドレスに向けて接続を開始すると、コアはマッピングからドメイン名を復元してルールマッチングと実際の解決を行います。利点は前置の解決を1回省けること、ルールが常にドメイン名で正確にマッチできることです。代償は198.18で始まるアドレスを受け取って困惑するプログラムがあることです——LAN内デバイスの発見、NTPによる時刻合わせ、一部のゲームプラットフォームは典型的なケースで、これこそがfake-ip-filterが存在する理由です。ここに列挙されたドメインはfake-ipをスキップして直接実際のアドレスが返されます。redir-hostモードは常に実際のIPを返すため互換性は最も高いですが、ルールマッチングの精度と性能は劣ります。fake-ipが問題を引き起こすと確認できた場合にのみ切り戻して使用してください。

アップストリームサーバーの三層構造

default-nameserverはブートストラップ層で、後述のDoHサーバー自身のドメイン名を解決することだけを担うため、必ず純粋なIPを記入します。nameserverは主力層で、日常のクエリはすべてここに送られます。DoH(https://で始まる)またはDoT(tls://で始まる)のアドレスを書くことを推奨します。fallbackは予備層で、fallback-filterと組み合わせて動作します——典型的な戦略はgeoip: trueとgeoip-code: CNの組み合わせです:主力層の解決結果が中国本土のIPアドレス帯に収まっていればそれを採用し、そうでなければfallbackの結果を使うことで汚染に対抗します。もう1つ、精密照準用のツールnameserver-policyがあり、特定のドメインに専用のアップストリームを指定できます。例えば社内ネットワークのドメインを内部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"
    - "time.*.com"
    - "ntp.*.com"
  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
  fallback-filter:
    geoip: true
    geoip-code: CN

fake-ip-filterは2種類のワイルドカードに対応します:*は1階層にマッチし、+は任意の複数階層にマッチします(+.localはa.b.localもカバーします)。fake-ip関連のフィールドを変更した後は、コアを再起動しクライアントのfake-ipキャッシュをクリアして古いマッピングを無効化することを推奨します。また、TUNモードでのDNS処理とブラウザの証明書エラーの間には見落とされがちな因果関係があります。詳しい分析はブログの《プロキシ使用後にブラウザがHTTPS証明書エラーを表示する場合》を参照してください。

04tunブロック:仮想ネットワークカードとシステムレベルの制御

通常の「システムプロキシ」は、OSにHTTP/SOCKSポートを1つ登録するだけで、実際に使うかどうかはアプリケーション側の自主性に任されています——コマンドラインツール、一部のゲームクライアント、多くのバックグラウンドサービスはこの設定を一切参照しません。TUNモードは発想を変え、仮想ネットワークカードを作成してデフォルトルートをそこに向けることで、すべてのトラフィックをネットワーク層で捕捉し、アプリケーションに回避の余地を与えません。代償はより高いシステム権限が必要になることと、システムプロキシとは別の並行する仕組みになることです。

主要フィールド

stackはプロトコルスタックの実装を選択します:systemはシステムのネットワークスタックを使い、性能が最も良く、デスクトッププラットフォームでの既定推奨です。gvisorはユーザー空間での実装で、互換性が必要な場面の備えです。mixedは両者の折衷です。auto-routeはルーティングテーブルを自動的に書き換え、デフォルトルートを仮想ネットワークカードに向けるもので、ほぼ常に有効化すべきです。auto-detect-interfaceは実際の物理出口ネットワークカードを自動識別し、トラフィックが仮想ネットワークカード内でループしてしまうことを防ぎます。dns-hijackはハイジャック対象のDNS宛先を宣言するもので、any:53と書けば53番ポート宛の全クエリを捕捉し、コアのdnsブロックに応答させます——これが「TUNを開いたらdnsも開かなければならない」理由です。strict-routeはさらにルーティングを厳格化してバイパスを防ぎますが、一部の仮想マシンやコンテナ環境で通信不能を引き起こす場合があり、その場合は無効化してください。

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

各プラットフォームの権限と差異

05proxies:プロキシノードのフィールド

proxiesはリストで、各項目が1つのノードを完全に記述します。サブスクリプションのシナリオではこのブロックは配信元によって生成され、サブスクリプション更新に伴って更新されるため、通常は手書きの必要はありません。しかしフィールドを理解することは依然重要です——「あるノードに接続できない」を調査する第一歩は、ここのパラメータを確認することです。全プロトコルは4つの基本フィールドを共有します:name(ノード名。プロキシグループとルールがこれを参照するため、同一設定内で重複してはいけません)、type(プロトコルの種類)、serverとport(サーバーアドレスとポート)。udp: trueはそのノードがUDP転送に対応していることを宣言し、音声通話やゲームはこれに依存します。

Shadowsocks(ss)

フィールドが最も少ないプロトコルです:cipherは暗号化方式を指定します(aes-128-gcm、chacha20-ietf-poly1305などAEAD系が一般的)。passwordは事前共有鍵です。両端のcipherとpasswordは完全に一致していなければならず、いずれかを書き間違えた場合の症状は「即座に接続失敗」であり、明確なエラーメッセージが出るわけではありません。

VMess

uuidを識別情報として使い、alterIdは現代的な運用では0に固定され、cipherは通常autoと書きます。VMessは伝送層の偽装と組み合わせることが多いです:network: wsでWebSocket伝送を有効にし、対応するws-opts内のpathとheaders.Hostはサーバー側との約束と一致させる必要があります。tls: trueで外側にさらにTLSを1層かぶせます。この種のノードはパラメータが多く相互に絡み合っており、接続できない場合はまずフィールドを1つずつサブスクリプション元と比較することを優先してください。

Trojanと新しいプロトコル

Trojanは元々TLS上で動作するため、核心となるフィールドはpasswordとsni(TLSハンドシェイクで宣言するサーバー名)だけです。skip-cert-verifyは証明書検証をスキップするかどうかを制御します——下の警告を参照してください。VLESS、Hysteria2、TUICなどより新しいプロトコルはmihomoコアのサポートが必要で、従来のClashコアでは解析できません。本サイトのダウンロードページに掲載されているClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuはいずれもmihomoベースであり、これらのプロトコルはそのまま利用できます。

proxies:
  - name: "SS-香港-01"
    type: ss
    server: hk01.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

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

  - name: "Trojan-シンガポール-01"
    type: trojan
    server: sg01.example.com
    port: 443
    password: "your-password"
    sni: sg01.example.com
    udp: true

06proxy-groups:プロキシグループのフィールド

プロキシグループはノードとルールの間の中間層です:ルールは直接ノードを指すのではなく、グループを指し、グループ内で現在どのノードを使うかを決定します。この間接性により、「ノードを変える」ためにルールを変更する必要がなくなり、「ノードが失効する」場合も自動で切り替えられます。各グループには必ずname、type、メンバーリスト(proxies)があり、メンバーはノード名、他のグループ名、そして組み込みのDIRECTやREJECTを指定できます。

5種類のグループタイプ

selectは手動選択で、パネル上でクリックしたものが使われる、最も一般的な「メインスイッチグループ」です。url-testはurlで指定したテスト用アドレスに定期的にリクエストを送り、遅延が最も低いメンバーを自動選択します。intervalはテスト間隔(秒)、toleranceは切り替えの許容差を設定します——新旧ノードの遅延差がこのミリ秒数未満なら切り替えず、水準が近い2つのノード間で頻繁に往復するのを防ぎます。lazy: trueにすると、ルールで実際に使われるまでグループはテストを開始せず、通信量を節約できます。fallbackはメンバーリストの順序で最初に使えるノードを取り、第一候補が落ちると自動的に次へ、復旧すると自動的に戻ります。「メインを1つ、バックアップを複数」というシナリオに適しています。load-balanceは接続を複数のメンバーに分散させ、strategyにはconsistent-hashing(同一の宛先サイトは常に同じノードを経由)またはround-robin(順番に割り当て)を選べます。relayはメンバーを順にリレーとして連結し、トラフィックが各ホップを順に経由します。遅延と故障率がリンクの長さに応じて累積するため、特殊な要件がある場合のみ使用します。

グループのネスト

グループは他のグループを参照できます。よくある階層構造は、地域ごとにurl-testグループを1つ作成し(香港オート、日本オートなど)、それらの地域グループとDIRECTをまとめて1つの総合selectグループに入れる方法です。日常的には総合グループだけを操作し、地域内部の最適選択は自動速度測定に任せます。注意点として、url-testパネル上に表示されるミリ秒数は「テストアドレスとのハンドシェイク往復時間」を測っているものであり、実際の帯域幅とは別物です。ノードを選ぶ際は遅延だけで判断しないでください——仕組みの解説はブログの《Clashノード遅延テストの仕組み》を参照してください。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動テスト"
      - "フェールオーバー"
      - "SS-香港-01"
      - "VMess-日本-01"
      - DIRECT

  - name: "自動テスト"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - "SS-香港-01"
      - "VMess-日本-01"
      - "Trojan-シンガポール-01"

  - name: "フェールオーバー"
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - "SS-香港-01"
      - "VMess-日本-01"

07rules:ルール構文とマッチング順序

rulesは文字列のリストで、各行はタイプ,マッチ値,出口の形式です(一部のタイプにはマッチ値がない、または追加パラメータが付きます)。コアは新しい接続ごとに上から下へ1件ずつ照合し、最初にマッチしたルールが即座に適用され、それ以降のルールはすべて無視されます——順序がそのまま優先度であり、これがあらゆる振り分け動作を理解する鍵です。リストの末尾には必ずMATCHによるフォールバックが必要で、これがないとマッチしなかったトラフィックの挙動は未定義になります。

ルールタイプ早見表

no-resolve:IPルールで不要な解決をさせない

宛先がまだドメイン名の場合、IP系のルール(IP-CIDR、GEOIPなど)は既定でまずドメイン名をIPに解決してから照合します——この解決は不要な場合があり、マッチングも遅くなります。IPルールの末尾にno-resolveパラメータを追加すると、ドメイン名のトラフィックはそのルールをスキップし、元からIPを宛先とする接続だけが照合対象になります。経験則:ドメイン名ルールの後に置かれ、フォールバックとしてIPトラフィックだけを処理するIPルールには一律no-resolveを付けます。唯一の例外は、GEOIP,CN,DIRECTをドメイン名のトラフィックにも適用させたい場合です。

並び順の推奨と典型的な誤爆

推奨される配置順序:プロセスルールと厳密なドメイン名ルールを最前に、DOMAIN-SUFFIXの一括ルールを中間に、RULE-SETやGEOSITEの大規模な集合をその後に、GEOIP,CN,DIRECTを最後から2番目に、MATCHで締めます。よくある落とし穴は2つあります。1つはDOMAIN-KEYWORDのマッチ範囲が極めて広いことです。DOMAIN-KEYWORD,go,ノード選択のような短いキーワードは、無関係な多数のドメインを誤爆します。もう1つは、広いルールを狭いルールより前に置くことで、後ろにある細かいルールが永遠に評価されなくなることです——調査する際はlog-level: debugを有効にして接続が実際にどのルールにマッチしたかを確認すれば特定できます。GEOIPとGEOSITEはローカルのデータベースファイルに依存し、データベースのバージョンがマッチング結果に直接影響します。ダウンロード元の選び方と更新方法はブログの《Clash GeoIPとGeoSiteデータベース更新ガイド》を参照してください。

rules:
  - PROCESS-NAME,Telegram.exe,ノード選択
  - DOMAIN,dl.google.com,ノード選択
  - DOMAIN-SUFFIX,github.com,ノード選択
  - DOMAIN-SUFFIX,githubusercontent.com,ノード選択
  - DOMAIN-KEYWORD,youtube,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

08proxy-providersとrule-providers

Providerの仕組みは、「ノード一覧」と「ルールセット」をメイン設定から切り離し、独立してダウンロード・更新できる外部リソースにします。メリットは明確です:サブスクリプション更新はノードファイルだけを更新し、丁寧に管理してきたプロキシグループやルールには触れません。ルールセットはコミュニティが管理する既製のリストを参照でき、自分で数千行のドメインリストを維持する必要がありません。

proxy-providers:外部ノードソース

各providerには独自のキー名があります。type: httpはurlから定期的に取得することを表し(intervalの単位は秒。86400なら1日に1回)、取得結果はpathにキャッシュされます。type: fileはローカルファイルを直接読み込みます。health-checkサブブロックはこれらのノードにヘルスチェックを設定し、パラメータの意味はurl-testグループと同じです。プロキシグループはuseフィールドでproviderを参照し、proxiesリストと併用できます——手書きの常設ノードとサブスクリプションのノードを同じグループに混在させることは完全に問題ありません。サブスクリプションリンク自体にはBase64やClash YAMLなど複数の形式がありますが、providerが必要とするのはClash YAML形式のアドレスです。形式の識別と変換方法はブログの《Clashサブスクリプションリンクの主な形式解説》を参照してください。

rule-providers:外部ルールセット

フィールドはproxy-providersとほぼ同じ構造ですが、重要なbehaviorが追加されます:domainはファイルの内容が全てドメイン名であることを表し(コアはドメインツリーで効率的にマッチングします)、ipcidrは全てネットワーク範囲、classicalは各種ルールタイプを混在させられますがマッチングのコストが最も大きくなります——前の2つで済むならclassicalは避けてください。ルールファイルの形式はformatで宣言します(yamlまたはtext)。定義が済んだら、rules内でRULE-SET,キー名,出口の形式で参照します。この行の並び順の原則は通常のルールと完全に同じです。

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

proxy-groups:
  - name: "ノード選択"
    type: select
    use:
      - airport
    proxies:
      - DIRECT

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

rules:
  - RULE-SET,cn-domains,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

09上書きとマージ:変更を失わずに設定を編集する

サブスクリプションは配信元が生成する完全な設定であり、更新のたびにローカルのプロファイル全体を上書きします——サブスクリプションファイルを直接編集してdnsを変えたりルールを追加したりしても、次の更新で全て元に戻ってしまいます。上書き(Override / Merge)の仕組みはこの矛盾を解決します:あなたの変更は別に保存され、クライアントはサブスクリプションを読み込むたびに自動でそれを重ねて適用します。サブスクリプションが自由に更新されても、あなたの変更は常に反映され続けます。

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

本サイトのダウンロードページに掲載されている主要クライアント(Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu)はいずれもサブスクリプション上書き機能を備えていますが、入口の名称は少し異なり、よくある呼び方は「上書き」「グローバル拡張設定」「Merge」です。多くのクライアントは2つの形態を同時に提供します:宣言的なYAMLマージ(スニペットを書いてキー名で重ねる)と、スクリプト式の上書き(JavaScript関数で直接設定オブジェクトを加工する、自由度が高い)です。日常的な用途はYAMLマージで十分で、スクリプトは「条件付きで一括でノード名を変更する」といった手続き的なシナリオに残しておきます。

マージのルール:何が上書きされ、何が追記されるか

マージを理解する鍵は値の種類を区別することです:スカラーのキー(mode、log-levelなど)とマッピングのキー(dns全体など)は、上書きスニペットに出現するとサブスクリプション内の同名の内容を直接置き換えます。リストのキー(rules、proxiesなど)も既定では丸ごと置き換えられます——これはしばしば意図した結果ではないため、Clash Verge Rev風のマージではprepend-とappend-という接頭辞が用意されています:prepend-rulesはいくつかのルールをサブスクリプションのルールの最前に挿入します(「先にマッチしたものが有効」の性質を利用して優先度を確保する)。append-rulesはMATCHの直前の末尾に追加します。同様にprepend-proxies、prepend-proxy-groupsなどもあります。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,ssh,DIRECT

append-rules:
  - DOMAIN-KEYWORD,tracker,REJECT

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query

変更後はまず検証、それから反映

直接編集する場合も上書きする場合も、保存前に文法チェックを一度通す価値があります。GUIクライアントの内蔵エディタは通常エラー行をすぐに赤くマークします。コマンドライン環境では、mihomoに設定チェック専用のパラメータが用意されており、検証のみ行い起動はしません:

mihomo -t -f config.yaml

検証に通ったら設定を再読み込みするだけで反映され、クライアント全体を再起動する必要はありません。読み込み後の動作が期待と異なる場合は、本マニュアルのブロック順に自己診断してください:インバウンドポートは正しいか → dnsは有効になっているか → ルールの順序が広いルールに横取りされていないか → プロキシグループで現在選択されているのは誰か。それでも解決しない場合は、まずFAQの「トラブル対処」カテゴリを確認してください。ゼロから始める操作の全体像はクイックスタートガイドを振り返ってください。まだクライアントをインストールしていない方は、クライアントを入手ページへ進み、Clash Plusを第一候補にしてください。