設定リファレンス / YAML · MIHOMO

Clash YAML設定項目リファレンス

ファイル構造から実際の動作まで：ポート、名前解決、出口、ルールの設定関係。

このページでは、設定項目を体系的に確認し、マージ後の状態を調べる方法を解説します。初期設定、サブスクの追加、接続の確立は、まずクイックスタートに沿って進めてから、該当する章でパラメーターを確認してください。例は主にmihomoの設定仕様に基づいています。GUIクライアントの画面上の設定、設定ファイルの生成方法、コアの対応範囲は、それぞれ個別に確認が必要です。

項目の説明 YAMLの例 マージ時の注意点 クライアントとプラットフォーム

YAML構造の概要

設定ファイルは、自由に組み合わせられるパラメーターの一覧ではなく、接続を処理する一連の関係を記述したものです。共通項目で待ち受け方法を指定し、DNSで名前解決を設定し、プロキシノードで実際の出口を用意します。プロキシグループで出口の選択肢をまとめ、ルールで接続を適切なポリシーに振り分けます。ファイルを読むときは、まずトップレベルの各セクションを把握し、次に名前の参照関係を追ってください。構文を解析できても、ルールの参照先グループが存在しない場合や、グループが誤ったノード名を参照している場合は、読み込み時または接続時に失敗することがあります。

マップ、リスト、インデント

YAMLのマップはキーと値で構成され、リスト項目はハイフンで始まり、階層はスペースによるインデントで表します。スペースは2つに統一し、タブは使わないようにしましょう。コロンの後にはスペースを1つ入れ、同じ階層の項目は位置をそろえます。次の設定は組み込みのDIRECTポリシーだけを使い、トップレベルの構成を示す例です。リモートのプロキシ出口は設定されていません。設定の読み込み確認には使えますが、ノードを含むサブスク設定として扱わないでください。

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

proxies: []

proxy-groups:
  - name: 出口の選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口の選択

ここでのproxies: []は空のリストを表し、項目がない状態や空文字列とは異なります。proxy-groupsはリストで、その各項目はマップです。一方、グループ内のproxiesは名前のリストです。トップレベルでノードを定義する場合と、グループ内で名前を参照する場合では、同じ項目名でも意味が異なります。変更時は項目の階層も確認してください。単語だけを検索して一括置換するのは避けましょう。

シャープ記号、コロン、特殊文字を含む文字列は、特にパスワード、サブスクURL、数字に見える識別子では引用符で囲むのが安全です。引用符がないシャープ記号は、位置によってコメントの開始として扱われます。また、二重引用符の誤用でバックスラッシュのエスケープが発生することもあります。通常の文字列にはシングルクォートを使えます。文字列自体にシングルクォートが含まれる場合は、YAMLの仕様に従って2つ連続させてください。真偽値はtrueまたはfalse、ポートは整数で記述します。すべての値を機械的に文字列へ変更する必要はありません。

ファイル、設定プロファイル、実行設定

GUIクライアントの設定プロファイルは、通常、入力元となるデータにすぎません。クライアントが待ち受けポート、コントロールインターフェース、TUNのパラメーター、ユーザーによる上書きなどを追加し、最終的にコアへ渡す実行設定を生成することがあります。そのため、サブスクの元データと実際の実行設定に差があっても、必ずしもインポート失敗とは限りません。項目が反映されない理由を調べるには、まず有効な設定プロファイルを確認し、次にクライアントの実行設定プレビューや該当ログを確認してください。

同じマップ階層で同じキーを重複して定義しないでください。たとえば、先にdnsを記述し、ファイル末尾にもう一つdnsを記述しても、設定の追加を確実に表現できるわけではありません。パーサーによっては重複キーを拒否したり、片方だけを残したりします。意図を明確にするには、必要な子項目を1つのマップにまとめてください。リストの追加やマップの再帰的なマージは、クライアントやスクリプトの動作であり、YAML形式そのものが共通仕様として提供する機能ではありません。

ファイルはUTF-8で保存し、正常に起動できるコピーを1つ残しておきましょう。エラーが発生したら、まずコピーを復元し、変更範囲を絞ってください。クライアントを何度も再インストールするより、原因を特定しやすくなります。コマンドラインでテストできる環境では、次のコマンドで設定を確認できます。実行ファイルと設定ファイルのパスは、各自の環境に合わせてください。テストに成功しても、リモートノード、DNS、ネットワーク権限が利用可能とは限りません。

mihomo -t -f ./config.yaml

オリジナル版Clash、mihomo、各GUIクライアントでは、対応する設定項目が異なります。例をコピーする前に、アプリ名だけで判断せず、実際に使用しているコアを確認してください。GUIとコアの役割分担については、Clashのオープンソースエコシステムとクライアントの関係をご覧ください。このハンドブックでは、引き続き設定項目間の依存関係を軸に解説します。

共通項目と通信の取り込み方

共通項目では、通信をコアに取り込む方法と、コアが接続を処理する方法を設定します。待ち受けポート、システムプロキシ、TUNは関連していますが、それぞれ別の仕組みです。ポートはコアが提供するローカルの接続口、システムプロキシはOSがアプリに通知する接続先、TUNは仮想ネットワークインターフェースを通してルーティング条件に合うパケットを受け取る仕組みです。待ち受けポートを設定しただけでは、OSがアプリの通信をそのポートへ送るとは限りません。

待ち受けポートとアクセス範囲

項目用途確認ポイント
portHTTPプロキシの接続口アプリがHTTPプロキシとして接続する
socks-portSOCKSプロキシの接続口アプリのプロキシ種類とポートが一致している
mixed-portHTTPとSOCKSで共用する接続口クライアントが設定したシステムプロキシのアドレスと一致している
allow-lanLANからのプロキシ接続を許可待ち受けアドレス、ファイアウォール、認証を確認する
mode通信の処理モードを選択通常のルール振り分けにはruleを使用
log-levelログの詳細度を設定トラブル対処後は通常のログレベルに戻す

ポート番号が固定で使えるとは限りません。例の値は一般的な設定例です。ローカルで別のプロセスが同じポートを使用していると、コアが待ち受けできない場合があります。ログでアドレスとポートを確認し、競合している項目を変更してください。クライアントがシステムプロキシを設定する場合は、新しいポートがシステム側にも反映されたことを確認します。サブスクの数字だけを変更し、クライアントが古い接続先を使い続けると、コアは正常に動作しているのにブラウザーが接続できないことがあります。

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

待ち受けアドレスは、サービスをどのローカルインターフェースにバインドするかを指定します。ローカルでのみ使う場合は、ループバックの範囲内で待ち受ける設定にできます。LAN内の端末と共有する場合は、待ち受けアドレス、LANからのアクセス許可、ファイアウォールルールを確認してください。コントロールインターフェースはコアの管理用であり、ブラウザーに入力するプロキシポートではありません。他の端末に管理インターフェースを公開する前に、認証情報を設定してネットワーク範囲を制限してください。どちらもポートとして表示されるからといって、混同しないようにしましょう。

ルール、グローバル、DIRECTモード

ruleモードではルールリストに従ってポリシーを選択します。globalモードでは接続をグローバルポリシーに渡し、directモードでは通信を直接接続として処理します。モードの選択はノードへの接続確認に代わるものではなく、グローバルモードにしてもすべてのアプリの通信が自動的に取り込まれるわけではありません。システムプロキシを使用しないアプリは、通常、グローバルモードに切り替えても通信の入口は変わりません。まず通信が取り込まれているか確認してから、振り分け結果を調べてください。

TUNモードとプラットフォームの権限

TUNは、システムプロキシ設定を参照しないアプリの通信を扱うのに適していますが、仮想インターフェース、システムルート、実行権限が関係します。クライアントによって、サービスプロセス、管理者権限、プラットフォームのネットワーク拡張機能などを使ってインターフェースを作成します。あるプラットフォームの権限手順を別の環境にそのまま適用しないでください。以下はmihomoでよく使われる項目の関係を示しています。GUIクライアントがこれらの項目を管理している場合は、設定画面から操作し、設定生成時に互いの変更が上書きされないようにしてください。

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

auto-routeは関連ルートの自動設定、auto-detect-interfaceは送信インターフェースの検出、dns-hijackは条件に合うDNSリクエストの受け取りに関係します。これらの設定があらゆるネットワーク環境で機能するとは限りません。別のVPN、仮想マシンのネットワークアダプター、企業ネットワークのソフトウェア、手動設定したルートなどによって経路が変わることがあります。有効化後にLAN内のリソースへアクセスできなくなった場合は、ルートと除外範囲を確認してください。すべてのDNS設定を無効にして問題を覆い隠すのは避けましょう。

システムプロキシとTUNは併用できますが、トラブル対処では、まず通信を取り込む方法を1つに絞るのがおすすめです。ローカルの接続口を使ってブラウザーが接続できることを確認してからTUNを有効にし、ほかのアプリの動作を調べます。有効化後に問題が起きた場合は、権限、インターフェース、ルートの変化を重点的に確認してください。元に戻す前に現在の設定を記録し、特にクライアント終了時にシステムプロキシが自動で復元されるかを確認しましょう。アプリ終了後も、待ち受けが停止したポートがシステムプロキシに残る事態を防げます。

Windowsのアプリコンテナーからのアクセス、AndroidのVPN権限、デスクトップ版のバックグラウンドサービスは、プラットフォーム側の通信取り込みに関する問題であり、YAMLの構文エラーとは異なります。各プラットフォームの操作はクイックスタートを入口に確認し、症状に応じてヘルプセンターもご覧ください。クライアントを選ぶ際は、まずダウンロードセンターのClash Plusプラットフォーム別オプションを確認し、必要な通信取り込み機能に対応しているかを確かめましょう。

DNS名前解決

DNS設定では、3つの点を確認します。誰がコアに名前解決を依頼するのか、どの上流DNSサーバーに問い合わせるのか、問い合わせがどのネットワーク経路を通るのかです。DNSアドレスを1組変更しただけでは、ブラウザー内蔵の暗号化DNS、システムキャッシュ、ほかのネットワークサービスまで自動的に制御できません。DNSリークを調べるときは、まず本来コアで処理すべきリクエストを明確にし、通信の取り込み方法とログで検証してください。検査ページに表示された地域だけで結論を出すのは避けましょう。

待ち受け、上流DNS、初期名前解決

enableはコアのDNS機能を有効にし、listenは待ち受けアドレス、nameserverは通常の問い合わせに使う上流DNSサーバーを指定します。上流DNSのアドレスにドメイン名が使われている場合、コアはまずその名前のIPアドレスを取得する必要があります。この初期名前解決にはdefault-nameserverを指定できます。初期名前解決に使うDNSサーバーへ現在のネットワークから実際に接続できないと、暗号化された上流DNSに接続する前に停止する循環依存が発生します。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://cloudflare-dns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - localhost

この例は項目の構造を示すものであり、掲載したパブリックDNSサービスがすべてのネットワークに適しているという意味ではありません。1053番ポートも、設定するだけでシステムDNSになるわけではありません。クライアントのDNS取り込み設定や、明示的な転送の仕組みが必要です。標準以外のポートをシステムリゾルバーに指定できないデスクトップ環境では、待ち受けアドレスをそのままシステム設定に入力しないでください。問い合わせが実際に届いているかは、コアのログとアプリの接続結果で確認しましょう。

fake-ipと実IPアドレスの応答

fake-ipモードでは、アプリにマッピング用のアドレスを返し、コアがアドレスとドメインの対応関係を保持します。その後、接続がコアに入ると、対応関係を使ってドメインルールを判定します。これは振り分けに必要なドメイン情報を維持する仕組みであり、接続先サーバーを実際にマッピング用のアドレス範囲へ変更するものではありません。アプリがマッピングアドレスを受け取った後、コアを経由せずに接続すると失敗することがあります。DNS応答の経路と接続の取り込み経路をあわせて確認してください。

fake-ip-filterを使うと、一部のドメインにはマッピングアドレスを返さないようにできます。LAN内のサービス、実アドレスが必要なデバイス検出、互換性に問題のあるアプリなどは、必要に応じて個別にフィルターへ追加します。1つのドメインへの対処を理由に、すべてのドメインへフィルターを広げないでください。ほかのルールがドメイン情報を取得する条件まで変わることがあります。追加後は関連キャッシュを消去するか、影響を受けるアプリを再起動し、古いマッピングと新しい応答が混在しないようにしましょう。

実アドレスを返す方式では、アプリは実際のIPアドレスを受け取ります。ドメインルールを利用できるかどうかは、コアが保持している情報と接続の入口によって異なります。IPルールが追加の名前解決を発生させることがあり、ドメインスニッフィングもすべてのプロトコルから名前を復元できるとは限りません。2つの方式を比較する際は、実際に適用されたルール、対象アプリの動作、ログを確認してください。一方が常に速く、他方が常に安全だと決めつけることはできません。

ドメイン別の上流DNSと問い合わせ経路

nameserver-policyを使うと、特定のドメインに対して上流DNSサーバーを指定できます。たとえば、内部ドメインをそのネットワークのDNSサーバーに問い合わせる場合に便利です。ただし、これは名前解決に使うサーバーの指定であり、最終的な通信の出口を決める設定ではありません。実際の通信は引き続きルールとプロキシグループで処理されます。respect-rulesを使ってDNS通信にもルールを適用する場合は、プロキシサーバーのドメインをどの経路で名前解決するかも確認してください。利用できる前段のプロキシに依存して名前解決が止まるのを防げます。

dns:
  enable: true
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - 192.168.1.1

ここでのLAN内アドレスは、「現在のネットワークにあるDNSサーバーへ問い合わせる」例にすぎません。実際に使用できるアドレスに置き換えてください。社内ドメインを誤ってパブリックDNSへ送ると、レコードが見つからないことがあります。逆に外部ドメインをすべて社内DNSへ送ると、そのネットワークのポリシーの影響を受けることがあります。ドメインサフィックスで振り分ける場合は、マッチする範囲に注意してください。まず明確なテスト用ドメインで動作を確認し、その後で範囲を広げましょう。

トラブル対処は、ドメイン名とIPアドレスを比較するところから始められます。同じ接続先でIPアドレスには到達できるのに、ドメイン名ではアクセスできない場合は、まずDNSログを確認します。特定のアプリだけに問題がある場合は、そのアプリ独自の名前解決設定を確認してください。ノードのドメイン名が解決できない場合は、初期名前解決とノードの名前解決経路を先に直します。変更後は新しい接続で再試行し、必要に応じてシステムとアプリのキャッシュを消去してください。詳しい手順はノードのタイムアウト・接続失敗のトラブル対処をご覧ください。

プロキシノードの設定項目

プロキシノードには、リモートサービスへ接続するためのプロトコルパラメーターを定義します。ノード名、地域ラベル、速度テストの結果とは別のものです。名前は参照と識別に使われ、接続動作を決めるのはプロトコル、アドレス、ポート、認証、トランスポートの設定です。記述する前にサービス提供元から必要な情報をすべて入手してください。サーバーアドレスだけからプロトコルを推測したり、別のクライアントの項目名をそのままYAMLへ移して同じ意味だと判断したりしないでください。

共通項目とプロトコル固有の項目

共通項目にはname、type、server、portなどがあります。nameはプロキシグループから参照する名前と完全に一致させ、重複を避けて見分けやすくしましょう。typeによって有効な項目が決まります。serverにはドメイン名またはIPアドレスを指定できます。portはリモートサービスの接続口で、ローカルの待ち受けポートではありません。2種類のポートを取り違えると、YAMLの解析エラーではなく接続失敗としてログに現れることがあります。

proxies:
  - name: SSの例
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: 'your-password'
    udp: true

この設定例はShadowsocksノードの項目構成を示しています。例のドメイン名とパスワードでは実際に接続できません。cipherとパスワードはサーバー側の設定に合わせてください。「セキュリティを高める」目的で暗号方式の名前だけを変更しても意味はありません。ポートが443だからといって、HTTPSやTLSを使うとは限りません。暗号化や難読化の有無は、ポート番号ではなくプロトコルとトランスポートの項目で確認してください。

項目意味よくある間違い
nameノードを参照する名前名前を変更してもプロキシグループ内の参照を直し忘れる
serverリモートサーバーのアドレス共有リンクやWebページのURL全体を誤って入力する
portリモートサービスのポートローカルの混合プロキシポートを誤って入力する
udpノードでUDPを使う設定サーバー、プロトコル、接続口の実際の対応状況を考慮しない
servername一部のTLSプロトコルで使うサーバー名トランスポート層のHost項目と混同する

TLS、SNI、トランスポートの設定

TLSを使うプロトコルでは、サーバー名と証明書の関係も確認が必要です。接続先アドレス、TLSのSNI、WebSocketのHost、パスは、それぞれ異なる役割を持つ場合があります。サーバー構築時にたまたま同じドメイン名を使っていても、各項目を相互に置き換えられるとは限りません。一部のプロトコルではservernameを使いますが、ほかのプロトコルでは異なる項目を使うことがあります。プロトコルごとの設定構造を確認し、汎用の設定項目一覧を作って、実際には認識されないパラメーターを使うことのないようにしてください。

proxies:
  - name: Trojanの例
    type: trojan
    server: proxy.example.com
    port: 443
    password: 'your-password'
    sni: proxy.example.com
    skip-cert-verify: false
    udp: true

証明書エラーが発生した場合は、検証を無効にするのではなく、まずシステム時刻、ドメイン名、証明書チェーン、サーバー側の設定を確認してください。検証を無効にすると接続時の本人確認条件が変わるだけで、SNIの入力ミスは直りません。サービス提供元から特殊な証明書や専用のトランスポート設定を指定されている場合は、案内の出所を確認し、該当プロトコルに合わせて設定してください。プロトコル固有の項目は多数あります。このハンドブックでは確認方法を示し、異なるプロトコルのすべての項目を1つの例に詰め込むことはしません。

ノード定義と実際の接続

udp: trueは、該当機能を設定上許可するだけです。もともとUDPに対応していないサーバーが対応するようになるわけではありません。アプリのプロキシ種別、TUNによる通信の取り込み、通信事業者のネットワーク、ファイアウォールによる制限も考えられます。Webページは表示できても、音声通話やゲームに問題がある場合は、TCPとUDPの経路をそれぞれ確認してください。HTTPテストが一度成功したからといって、すべての通信方式が利用できるとは限りません。

ファイルにノードを追加しただけでは、プロキシグループやルールから実際に参照されるとは限りません。proxiesの下に項目を追加しても、現在の出口が自動で切り替わるわけではありません。接続画面では、適用されたルール、通過したプロキシグループ、最終的に選ばれたノードを確認してください。ルールがDIRECTを選んでいるなら、まず新しいノードのパスワードを疑う必要はありません。逆に、ポリシーがノードを選択しているのにハンドシェイクに失敗する場合は、アドレス、認証、プロトコルの設定を確認します。

サブスクにはアクセス認証情報が含まれていることが多く、スクリーンショットやログにも完全なノードアドレスが記載される場合があります。トラブル対処のために共有する場合は、必要な項目だけを残し、パスワードやサブスクURLの機密部分を隠してください。元のリンク、YAML、ほかの設定形式を比較するときは、プロトコルの情報がすべて保持されているかを項目ごとに確認します。「変換に成功した」ことだけで、すべての機能が維持されたとは限りません。詳しくはサブスク形式の比較と変換をご覧ください。

プロキシグループ

プロキシグループはルールとノードの間に位置します。ルールに特定のリモートノードを直接指定せず、用途が変わらないグループ名を参照させ、そのグループで出口を選ぶ方法が一般的です。サブスクを変更したりノードを切り替えたりしても、ルールはそのまま使えます。グループを設計するときは、地域名の階層を大量に追加するより、選択の仕組みと参照関係を明確にすることを優先してください。入れ子を1段増やすごとに、その階層が何を解決するのかを説明できるようにしましょう。

手動選択、自動テスト、フェイルオーバー

selectは手動選択を提供し、ユーザー向けの総合的な入口に適しています。url-testは指定した接続先へのテスト結果から出口を選び、fallbackは候補の順序に従って利用可能な項目を選択します。load-balanceは設定した方式で接続を振り分けます。それぞれ目的は異なります。テスト時間が短くても、特定のサービスで最適な使い心地になるとは限りません。また、フェイルオーバーは複数ノードの帯域を合算する機能ではありません。

proxy-groups:
  - name: 出口の選択
    type: select
    proxies:
      - 自動選択
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - メインサブスク
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

この例は、後述するメインサブスクプロバイダーに依存します。useはリモートノードの集合を参照し、proxiesは個別のノード、組み込みポリシー、ほかのプロキシグループを参照します。どちらも名前が表示されるからといって相互に置き換えられるわけではありません。設定ファイル内のトップレベル項目は読みやすい順に並べられますが、最終的な設定内にすべての参照先が存在する必要があります。名前のスペース、記号、大文字・小文字も一致させてください。

urlはテスト先、intervalは確認間隔、toleranceはわずかなテスト結果の差による頻繁な切り替えを抑えるための項目です。例の値は単位と項目間の関係を示すものです。テスト先が現在のネットワークや一部のノードから制限されている場合、結果はノード全体の品質ではなく、そのテスト先への到達性を主に反映します。1つのテストサイトに接続できないだけで、サーバーが完全に利用不能だと判断しないでください。

候補範囲と名前の安定性

サブスクに含まれるノードが多い場合は、対応するフィルター項目を使って候補を絞り込めます。フィルターは通常、名前で判定されるため、サブスク提供元の命名規則に依存します。地域名、記号、ラベルが変わると、以前の条件ではノードが見つからないことがあります。変更後はYAMLのテスト結果だけでなく、グループ内の実際のメンバーを確認してください。正規表現を使う場合は、YAMLの引用符と正規表現自体のエスケープ規則の両方に注意が必要です。

同じ設定内に、意味が異なるグループやノードを同じ名前で複数登録しないでください。ルールを長く安定して使うには、「仕事用サービス」や「メディアサービス」のような用途が明確なグループ名を使い、実際のノード選択は下位の出口グループに任せる方法があります。ノードの取得元を変更しても、大量のルールを書き直さずに済みます。ただし、どの用途も最終的に同じ出口を使うのであれば、入口グループを1つ用意すれば十分です。見た目を分類するためだけに重複した構造を増やす必要はありません。

種類選択の基準利用時の注意点
selectユーザーが手動で選択現在の選択肢を手動で管理する必要がある
url-testテスト時間と接続可否テスト先によって結果が変わる
fallback候補の順序とヘルス状態明確な予備候補の順序を表すのに適している
load-balance接続の振り分け方式1つの接続の帯域を合算する機能ではない

入れ子、選択状態の保存、切り替えの確認

グループは別のグループを参照できますが、たとえばAグループがBグループを参照し、BグループがAグループに戻るような循環参照は作れません。複雑な参照関係はルールの宛先から始め、最終的にノードまたは組み込みポリシーに到達するまで、実際の出口経路を順に書き出してください。すでに通ったグループへ戻る場合は構成を見直します。起動時のコアエラーで初めて循環に気づくのは、保守上望ましくありません。特に複数の上書きファイルが別々にグループメンバーを追加している場合は注意が必要です。

クライアントは手動選択を記憶することがあります。また、設定ではprofile.store-selectedを使って関連状態を保存できます。ただし、状態を保存しても、グループ名の変更後に正しく復元されるとは限りません。古い名前がなくなると、クライアントやコアが既定の候補に戻ることがあります。サブスクを更新した後は、現在の選択が意図した出口を指しているか確認してください。用途別にグループを分けている場合は特に、選択先の変更をルール順の異常と取り違えないようにしましょう。

ポリシーを切り替えても、影響するのは主に新しい接続です。確立済みの長時間接続では、切り替え前の出口が引き続き使われることがあります。確認時はアプリのセッションを更新するか、新しい接続を作成してから、接続画面で実際の経路を確認してください。古い接続を閉じる必要がある場合は、ダウンロード、会議、ほかの継続中の作業への影響も考慮しましょう。画面上のボタンの場所は、クライアントのプロキシ画面・プロファイル画面・接続画面の見方をご覧ください。

ルールの書式

ルールは上から順に判定され、最初に一致したルールで処理方法が決まります。保守ではルールの数より順序が重要です。具体的な例外を広範囲のルールより前に置き、最後に最終ルールを配置します。ルールの宛先にはプロキシグループ、ノード、組み込みポリシーを指定できますが、実行設定内で有効な宛先でなければなりません。正しいルールでも、前にある広範囲のルールに先に一致すると、期待どおりには処理されません。

ドメイン、IPアドレス、最終ルール

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,出口の選択
  - DOMAIN-KEYWORD,example,出口の選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,出口の選択

DOMAINは完全一致でドメインを判定するため、1つのホストを個別に扱うのに適しています。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン内のキーワードで判定するため、対象範囲が広く、慎重に使う必要があります。例では、まずログイン用ドメインをDIRECTにし、次にドメイン全体のサフィックスを処理しています。サフィックスルールを先に置くと、ログイン用ドメインが後の個別ルールまで到達しません。

IP-CIDRは宛先IPアドレスが属するネットワーク範囲で判定し、LAN内アドレスや固定サービスのアドレスによく使われます。no-resolveは、このルールに一致させるためのドメイン解決を新たに行わない設定です。DNS全体を無効にする意味でも、宛先IPがすでにある場合に比較を省略する意味でもありません。不要な名前解決を抑えるのに役立ちますが、名前解決で得たIPアドレスにルールを一致させる設定では、判定できる範囲にどのような影響があるかを理解しておきましょう。

MATCHは最終ルールで、それ以前のどのルールにも一致しなかった接続を受け取ります。リストの先頭に置くと、後続の大半のルールが使われなくなります。最終ルールでは、明確な既定の経路を指定してください。「未分類」をエラー扱いする必要はありません。保守を始めるときは、検証しやすい少数のルールと最終ルールで動作を確認してから、大規模なルールセットを追加しましょう。通信の入口、DNS、ノード、ルールを一度に変更するのは避けてください。

プロセスルールとプラットフォームごとの違い

プロセスルールを使うと、アプリごとに通信を振り分けられます。ただし、使用中のプラットフォーム、権限、通信の取り込み方法が、コアによるプロセス情報の取得に対応している必要があります。別の端末から転送された接続では、リモート端末上のアプリと関連付けられない場合があります。プラットフォームによってネットワークインターフェースから取得できる情報も異なります。そのため、別のPCで有効なプロセスルールが、スマートフォンやルーターでも使えるとは限りません。

ルールの種類必要な情報確認方法
DOMAIN完全な宛先ドメイン名接続記録にドメイン名が残っているか確認する
IP-CIDR宛先IPアドレスアドレス、サブネットマスク、名前解決の条件を確認する
PROCESS-NAME識別可能なプロセス名プラットフォームの対応状況と実際のプロセス名を確認する
RULE-SET読み込み済みのルールプロバイダーリソースの形式と読み込み状態を確認する
MATCHそれ以前のルールに一致しなかった接続リストの末尾に配置する

ドメインルールにも必要な情報があります。アプリがIPアドレスへ直接接続する場合、独自の名前解決を使う場合、または特定の転送方法でコアに接続する場合、接続記録に期待したドメイン名が残らないことがあります。このようなときは、ドメインサフィックスのルールを追加し続けても効果がない場合があります。まずDNSの取り込みと接続メタデータを確認してください。スニッフィングで名前を補える場合もありますが、プロトコルや暗号化方式による制約があるため、明確な名前解決とルーティング設計の代わりにはなりません。

ルールプロバイダーと実際の一致状況

RULE-SETはrule-providersで定義したルールセットを参照します。ドメインの集合、IPアドレスの集合、従来形式のルール集合などに使用できますが、リソースの形式とプロバイダーの動作タイプを一致させる必要があります。完全な設定ファイルをドメインリストとして読み込んだり、ポリシーの宛先を含むルールをドメイン専用リソースに1行ずつ入れたりすると、形式の問題が発生します。リソースの定義と読み込み方法は次の章で説明します。

振り分けミスを調べるときは、安定していて判定しやすい接続先を1つ選び、新しい接続を作成して、一致したルール名とポリシーの経路を確認します。意図しない前のルールに一致している場合は、そのルールの範囲を狭めるか順序を変更してください。正しいルールに一致しているのに接続できない場合は、最終ノードと名前解決結果を確認します。この手順なら「出口の選択ミス」と「出口が利用できない状態」を切り分けられ、ノードの問題をルールの構文のせいにせずに済みます。

大規模なルールセットは、提供元の更新によって内容が変わります。保守ではローカルの例外を少数に絞り、挿入位置を明確にしてください。リモートのルールリソースを一時的に手修正しても、更新後に変更が残るとは限りません。長期的に維持したいルールは独立した上書き設定またはローカルリソースに置き、サブスク更新後に最終的な順序を確認しましょう。モードやルールに関するよくある誤解は、ヘルプセンターもご覧ください。

サブスクとリモートリソース

サブスクの内容は、すべて同じ形式とは限りません。完全なClash設定を返すURLもあれば、ノードの集合だけを返すものや、ノード共有リンクをエンコードしたテキストを返すものもあります。GUIクライアントにはサブスクの変換や前処理機能がある場合がありますが、コアのproxy-providersがあらゆる形式を自動的に利用可能なノードとして認識するわけではありません。設定前にレスポンスの構造を確認し、クライアントで完全な設定として読み込むのか、コアでリモートノードリソースとして読み込むのかを決めてください。

ノードプロバイダー

proxy-providers:
  メインサブスク:
    type: http
    url: 'https://subscription.example.com/nodes.yaml'
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 出口の選択
    type: select
    use:
      - メインサブスク

rules:
  - MATCH,出口の選択

type: httpはリモートアドレスからリソースを取得する設定です。urlはリソースのアドレス、pathはローカルキャッシュの保存先、intervalは更新間隔を指定します。例のアドレスは説明用です。ノードの集合を返す互換性のある実際のサブスクに置き換えてください。キャッシュのパスは通常、コアの作業ディレクトリを基準とするため、サブスク設定ファイルの場所からの相対パスとは限りません。デスクトップとスマートフォンでは、書き込み可能なディレクトリも異なる場合があります。

ノードプロバイダーのリソースには通常、トップレベルにproxiesのリストが含まれ、ポート、DNS、ルールを含む完全な設定は含まれません。以下はリソースファイルの形式を示すもので、実際には接続できない説明用の値を使っています。サブスクの応答がWebページ、ログイン案内、エラーメッセージの場合、HTTPリクエスト自体が成功しても利用可能なノードは取得できません。クライアントのログでレスポンスの内容と解析エラーを確認してください。

proxies:
  - name: サブスクのノード例
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: 'your-password'
    udp: true

更新間隔とヘルスチェックの間隔は、別々の仕組みです。前者はノード設定の変更を取得し、後者は既存ノードの利用可否をテストします。ヘルスチェックの間隔を短くしても、サブスクに新しいノードが早く追加されるわけではありません。ノード数が多いと、頻繁なテストによってネットワークリクエストも増えます。リソースの更新頻度、端末のバッテリー、実際の選択要件を考慮し、すべての間隔を必要以上に短くしないでください。

ルールプロバイダー

rule-providers:
  サービス用ドメイン:
    type: http
    behavior: domain
    format: yaml
    url: 'https://rules.example.com/business.yaml'
    path: ./rules/business.yaml
    interval: 86400

rules:
  - RULE-SET,サービス用ドメイン,出口の選択
  - MATCH,DIRECT

behaviorはルールリソースの解釈方法を指定します。よく使われるdomain、ipcidr、classicalは、それぞれ異なる内容に対応します。formatはファイル形式を指定する項目です。拡張子だけで判断しないでください。ドメイン形式のYAMLリソースでは、通常、項目をpayloadで囲みます。従来形式のルールリソースではより多くのルール種別を記述できますが、所定の形式に従う必要があります。完全な設定ファイルのトップレベル項目を混在させないでください。

payload:
  - '+.example.com'
  - api.example.net

リソース名とキャッシュパスは、それぞれ重複しないようにします。2つのプロバイダーが同じローカルファイルを使うと、後から更新した内容が先の内容を上書きし、リソースは読み込まれたように見えても、実際のルールが別の集合のものになっていることがあります。リソースの種類や形式を変更した後は、古いキャッシュが引き続き使われていないかも確認してください。クライアントのデータディレクトリ全体を直接削除するのは避けましょう。まずログから対象のキャッシュファイルを特定し、復元用のコピーを残してください。

更新失敗、初期接続の依存関係、プライバシー

リモートリソースの更新に失敗した場合、コアは既存のキャッシュを使い続けることもあれば、初回起動時に利用可能なファイルがなく読み込みを完了できないこともあります。具体的な状態はログで確認してください。サブスクの取得に特定のプロキシが必要なのに、そのプロキシをこのサブスクからしか取得できない場合、起動時の依存関係が循環します。解決するには、到達可能な更新経路か独立した初期接続用の出口を用意します。まだ存在しないノードがダウンロードできることを期待して、更新ボタンを何度も押すのは避けてください。

サブスクURLにはアクセス認証情報が含まれることが多いため、公開リポジトリや公開変換サービスに掲載しないでください。形式を変換する場合は、変換サービスがどの情報にアクセスできるかを確認し、出力にプロトコル、トランスポート、グループ情報が保持されているかを確かめましょう。複数端末間の同期では、「同じサブスクURLを同期する」ことと「実行設定全体を同期する」ことを区別してください。後者では、別のプラットフォームに適さない待ち受け、ルーティング、パスの設定まで持ち込むことがあります。

複数端末で使う場合は、ノードの取得元とサービスのルールを共有し、プラットフォーム固有の設定は各クライアントに任せる方法が安定しています。プライベートリポジトリ、サブスクURL、上書きファイルの組み合わせについては、PCとスマートフォンで設定を共有する際の選択肢をご覧ください。リソースの最終的なマージ順序は、次の章で紹介する方法で実行結果を確認してください。

上書き・マージ・検証

上書きを使うと、長期的に保持したいローカル設定と、定期更新されるサブスクの内容を分けられます。たとえば、サブスクにはノードと基本ポリシーを任せ、ローカルの上書きにはLANの例外、サービス向けルール、プラットフォーム固有の通信取り込み設定を記述できます。上書きは、YAMLで統一された共通のトップレベル項目ではありません。クライアントが設定を生成する際に実行する処理です。「マージ」「上書き」「スクリプト」といった同じ名前の機能でも、クライアントごとに処理段階やリストの扱いが異なる場合があります。

まずマージのルールを確認

マップのマージとリストのマージは、それぞれ分けて理解する必要があります。スカラー項目は通常、後から書かれた値で置き換わります。入れ子のマップは再帰的にマージされる場合も、全体が置き換わる場合もあります。リストは追加、先頭への挿入、全体置換など、実装によって異なります。あるクライアントでDNSの既存の子項目が保持されたからといって、既存のルールリストも保持されるとは限りません。操作前にクライアントの説明とプレビューを確認し、機能名ではなく最終結果で動作を判断してください。

# 基本設定の例
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://cloudflare-dns.com/dns-query

# 追加したい項目の例
# クライアントが対応するマージ方法で処理し、dnsキーをそのまま重複して貼り付けないでください。
# dns:
#   fake-ip-filter:
#     - '*.lan'

クライアントがdnsを全体置換する場合、fake-ip-filterだけを追加すると、既存の上流DNS設定が消えることがあります。再帰的にマージする場合でも、リストが保持されるかどうかは実装によります。安全に確認するには、まず影響の小さい項目で試し、実行設定のDNSセクション全体を確認してから、必要な変更を適用してください。テスト中は基本設定と上書きファイルを別々に保存しておきましょう。

ルールの先頭への挿入と名前の変更

ローカルルールは通常、リモートルールより前に挿入する必要があります。特に、サブスクに最終ルールが含まれている場合は注意が必要です。クライアントがローカルのリストを末尾に追加するだけだと、新しいルールがMATCHの後ろに置かれます。構文に問題がなくても、そのルールには一致しません。クライアントが対応する先頭挿入の機能を使うか、スクリプトで挿入位置を指定してください。変更後は、上書きエディター内の内容だけでなく、最終的なルールリストの先頭と末尾を確認しましょう。

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,出口の選択
  - MATCH,出口の選択

上記は、求める最終的な順序を示したもので、すべてのクライアントで使える共通の上書き指示ではありません。ローカルルールが「出口の選択」を参照していて、サブスクの更新後にそのグループ名が変更または削除されると、参照が無効になります。ローカルで安定したグループ名を維持し、サブスクが提供するノード集合へ接続する方法があります。あるいは、更新後に参照関係を確認してください。画面に以前その名前が表示されたことだけで、現在の実行設定にも存在すると判断しないでください。

変更を最小限にして段階的に検証

変更は一度に1つの領域に絞ることをおすすめします。まずファイルを解析できるか確認し、次に名前の参照関係、待ち受けと通信の取り込み、最後にサービスの振り分けを検証します。DNS、TUN、ノードのプロトコル、ルールの順序を同時に変更すると、問題が一時的に解消しても、どの変更が効いたのか判断できません。変更の目的、対象項目、テスト対象を記録しておくと、次回のサブスク更新後に同じトラブルを調べ直す手間を減らせます。

  1. 現在利用できる設定を保存し、有効な設定プロファイルと主なスイッチの状態を記録する。
  2. YAMLのインデント、重複キー、データ型、名前の参照関係を確認する。
  3. 生成後の実行設定を確認し、ローカルの項目が上書きされていないことを確かめる。
  4. 新しいテスト接続を作成し、ルール、プロキシグループ、最終ノードを確認する。
  5. サブスクを更新して再読み込みし、ローカル設定が意図どおり保持されていることを確認する。

テストには、DIRECTの経路とプロキシの経路を最低1つずつ含めてください。Webページが1つ開けるかだけを試すと、すべての通信が誤ってDIRECTまたはプロキシに振り分けられている状態を見落とすことがあります。DNSを変更した場合は、名前解決と接続先が一致しているか確認します。TUNを変更した場合は、LAN、ほかのVPN、スリープからの復帰後の動作も確認してください。設定テスト用コマンドで確認できるのは構文と一部の意味的な整合性です。実際のネットワーク検証は別途行う必要があります。

プラットフォーム間で設定を移行する場合は、ローカルファイルのパス、ネットワークインターフェース名、コントロールポート、プラットフォーム固有の通信取り込み設定を取り除いてください。共有するのは、ノードの取得元と通信を振り分ける意図です。1台の端末の実行環境をすべて別の端末にコピーすることではありません。Clash PlusなどのGUIクライアントでは、まずダウンロードセンターで対象プラットフォームのオプションを選び、基本環境を整えてから必要な設定を移行してください。インストールと設定項目の互換性を同時に持ち込まずに済みます。

保守しやすい設定とは、関係性を説明できる設定です。各リモートリソースの取得元が明確で、各グループ名の用途が安定し、例外ごとにテスト対象があり、マージの結果を毎回確認できる状態を目指しましょう。初めて利用する場合はクイックスタートに戻り、接続までの手順を進めてください。設定を読み込めることは確認できたのに問題が残る場合は、ヘルプセンターまたは接続失敗のトラブル対処記事に進み、通信の入口、名前解決、ルール、出口の順に確認します。