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

YAMLの構造と設定の基本

Clashの設定は、順番に実行するコマンドの羅列ではなく、待ち受け、名前解決、送信先、ルーティングの関係を記述する構造化ドキュメントです。トップレベルのdns、proxies、proxy-groups、rulesにはそれぞれ役割があります。名前の参照先とデータ型が正しくなければ、コアはそれらを連携できません。見慣れない設定を読むときは、まずトップレベルの項目を確認し、ルールの送信先からグループをたどり、次にグループ内のプロキシを確認しましょう。先頭から末尾まで一行ずつ読むだけでは、こうした依存関係を見落としがちです。

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

YAMLではインデントで親子関係を表します。半角スペース2つに統一し、タブは使わないようにしましょう。コロンの後にスペースがあればキーと値の区切り、ハイフンの後にスペースがあればリスト項目を表すのが一般的です。同じnameでも、プロキシの下にある場合とプロキシグループの下にある場合では意味が異なります。エディターの自動整形は位置をそろえるのに役立ちますが、参照先が正しいかまでは判断できません。設定例を貼り付けるときは親項目も確認し、dns内に置くべき項目をルート階層に置かないよう注意してください。

# 構造の例：リスト内の各項目が独立したプロキシグループ
proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

文字列、数値、真偽値は明確に書き分けてください。ポートは通常数値、オン・オフはtrueまたはfalseで指定します。引用符で囲んだ文字列にすると、パーサーによっては拒否されたり、別の値に変換されたりするため、挙動の違いに頼らないでください。特殊記号を含む文字列、先頭にゼロがある値、誤読される可能性のあるテキストには、引用符を使うと安全です。パスワードも引用符で囲み、シングルクォートやダブルクォートを含む場合はYAMLのエスケープ規則に従ってください。通常のコメントは#以降に記述しますが、文字列中のシャープが内容かどうかは引用符と位置によって異なります。

サブスクリプション、編集内容、実行時設定を区別する

デスクトップクライアントでは、通常複数のファイルが管理されています。リモートのサブスクリプション原文、ローカル編集や上書きの内容、そしてコアに渡される最終的な実行時設定です。画面に表示されるポート、システムプロキシ、TUNの設定も、クライアント側の設定によって最終結果に反映されることがあります。サブスクリプションのテキストを変更しても、現在の実行時設定が変わるとは限りません。再読み込みやサブスクリプションの切り替え、上書きの適用によって初めて反映される場合があります。調査時は選択中の設定名と実際に読み込んだ時刻を記録し、古いファイルを編集しながら別の設定の接続結果を見てしまわないようにしてください。

トップレベル項目の順序は通常マップの意味に影響しませんが、リストの順序は動作を直接変える場合があります。たとえばルールは上から順に照合され、手動選択グループの先頭項目が初期表示に影響することもあります。整形ツールの「アルファベット順」をすべてのリストに適用しないでください。重複キーにも注意が必要です。同じ階層にdnsやrulesが重複すると、ツールによってエラーになったり、後の項目だけが残ったりします。設定を統合する場合は、内容を同じキーの下に整理し、ファイル末尾にブロック全体をそのまま貼り付けないでください。

最小構成と設定の互換性

新しい設定を作るときは、まず起動できる最小構成を用意し、プロキシ、グループ、ルールを一つずつ追加してください。あるサブスクリプションを特定のクライアントで読み込めても、ほかのクライアントも同じ項目に対応しているとは限りません。古いコアは新しいプロトコルやDNS項目を認識しない場合があり、クライアントがオプションを除外することもあります。未対応の項目が見つかったら、現在のコアのドキュメントとログを確認してください。警告を消すために内容をむやみに削除すると、ドメイン解決や送信先選択に必要な機能まで失う可能性があります。

YAMLのアンカーとエイリアスは重複を減らせますが、上書きツール、サブスクリプション変換ツール、手動レビューが複雑になります。個人管理の小規模な設定なら、適度に重複させても各項目を単独で理解できる形にするのが無難です。設定を他の人に見てもらう場合は、階層、項目の型、参照関係を維持したまま、サーバーアドレス、パスワード、サブスクリプションURLだけを置き換えてください。プロキシやグループを丸ごと削除すると問題発生時の状態が再現できず、構文エラー、項目の非互換、接続失敗の切り分けが難しくなります。

ポート、プロキシモード、通信の取り込み範囲

共通項目では、コアが接続を受け付ける場所、ルーティング方法、アクセスを許可するデバイスを設定します。よくある間違いは、待ち受けポートとサーバーのポートを混同することです。mixed-portは端末上のアプリがプロキシに接続するための入口で、プロキシ項目のportはリモートサーバーが接続を受け付けるポートです。両者の値は異なっていてもよく、そろえる必要はありません。ローカルの待ち受けポートを変更したら、システムプロキシやアプリ内のプロキシアドレスも更新してください。更新しないと、コアが正常に動作していてもアプリは古いポートへ接続しようとします。

待ち受け項目の役割

端末上のアプリだけがプロキシを使う場合、通常は混合ポートを1つ残せば十分です。HTTP、SOCKS、混合ポートをすべて有効にする必要はありません。同じアドレス上の同じポートを複数の待ち受け項目で使うこともできません。「アドレスが使用中」と表示されたら、別のプロキシやバックグラウンドサービスが動作していないか確認してください。LANからのアクセス許可は、単に真偽値をオンにするだけではありません。待ち受けアドレス、システムのファイアウォール、アクセス制御も関係するため、信頼できないネットワークにプロキシポートを公開しないでください。

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

ルール、グローバル、直接接続

mode: ruleでは、通信をルール一覧に渡し、照合結果に応じて送信先を選びます。グローバルモードでは通常、グローバル選択項目で送信先を決めます。直接接続モードでは、カスタムルールに基づくプロキシ選択を行いません。モードはルーティングの入口を決めるもので、通信を取り込む方法とは別です。グローバルモードでも、システムプロキシ、アプリ内設定、TUNで受け取られていない通信が自動的にコアへ入るわけではありません。逆にルールモードでDIRECTに一致した場合、接続はコアに取り込まれたうえで、最終的な送信先が直接接続になります。

システムプロキシは通常、OSがアプリ向けに提供するプロキシ設定を変更しますが、それに従うかどうかはアプリ次第です。TUNは仮想ネットワークアダプターとルーティングを使って通信を取り込み、より広い範囲をカバーしますが、権限、ルートの競合、DNSの取り込みが関係します。TUNを「より強力なグローバルモード」と考えたり、有効にすればすべてのネットワーク問題が解決すると考えたりしないでください。ゲーム、仮想マシン、コンテナ、企業VPNでは通信経路がそれぞれ異なります。有効にする前に現在の状態を保存し、元のデフォルトルートと名前解決の設定へ戻せることを確認してください。

TUNとクライアント設定の役割分担

# TUNの設定例：有効化する前にクライアントの権限とルーティング環境を確認
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

上の例は、自動ルーティングと従来のDNSリクエストを取り込む意図を示しています。アプリ独自の暗号化DNSや、すべてのプラットフォームのネットワークスタックを必ずカバーするものではありません。仮想ネットワークアダプター、サービス権限、ファイアウォールの要件はOSごとに異なり、クライアントがこれらの項目を一元管理する場合もあります。画面のスイッチと設定ファイルが互いに上書きする場合は、どちらを管理元にするか決めてください。具体的な有効化手順は入門ガイドを参照してください。このページでは項目間の関係を説明しており、クライアントの実装を理解せずにネットワーク設定全体を置き換えることは推奨しません。

ログレベルは通常infoに設定し、問題を再現するときだけ一時的に詳細度を上げるのが適切です。デバッグログには接続先ドメイン、接続情報、設定ファイルのパスが含まれる可能性があるため、共有前に機密情報を伏せてください。ルート階層のipv6とDNS内の同名項目は、それぞれ異なる処理に影響します。片方だけを変更してIPv6の経路全体を設定できたと判断しないでください。リモート制御インターフェイスを使う場合は、制御プレーンとプロキシ通信の違いも理解しておきましょう。管理用インターフェイスは状態の変更に使うもので、一般アプリのプロキシ入口ではありません。

自動起動、サイレント起動、テーマ、トレイの動作は、ほとんどの場合GUIクライアント固有の設定であり、すべてのコアで共通に使えるYAML項目ではありません。設定を移行するときは「ネットワーク動作」と「画面表示の動作」を分けて記録してください。クライアント選びはインストーラーページをご覧ください。一般ユーザーはまず推奨のClash Plusを検討し、OSや設定の互換性に応じてClash Verge Revなどを選べます。画面が似ているからといって、設定ファイルをそのまま相互利用できるとは限りません。

DNS項目と名前解決の経路

DNSはドメイン名をIPアドレスに変換しますが、プロキシ環境では名前解決が複数の段階に分かれます。アプリが自分で名前解決する場合もあれば、ルール照合のためにコアが接続先を検索する場合もあります。プロキシサーバーへの接続時に、サーバーのドメイン名を解決する必要もあります。対象を分けて考えると、ブラウザーでは開けるのにコマンドラインでは失敗する理由や、プロキシにホスト名を指定したときに接続できない理由を理解しやすくなります。暗号化DNSサーバーを設定しても、すべてのアプリがそれを使うとは限らず、ルーティングでプロキシが選ばれるとも限りません。

待ち受け、上流DNS、起動時の名前解決

dns.enableはコアのDNS機能を有効にし、listenはDNSの待ち受けアドレス、nameserverは通常の問い合わせ先を指定します。DoHのURLにホスト名を使う場合、そのDNSサーバー自体のIPアドレスを先に取得する必要があります。これが起動時の名前解決の問題です。default-nameserverはこうした基礎的な名前解決に使えるため、明確なIPアドレスを指定するのが適切です。プロキシサーバーにホスト名を使う場合は、proxy-server-nameserverで名前解決先を指定できます。プロキシサーバーの名前解決と接続先ドメインの振り分けを混同しないでください。

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
  nameserver:
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

これは項目間の関係を示す例で、あらゆるネットワークに適した名前解決の設定ではありません。上流DNSへの接続可否はネットワーク環境によるため、使用前に到達できるか確認してください。コアが1053番ポートで待ち受けても、システムのDNSリクエストが自動的にそこへ送られるわけではありません。クライアントまたはOSのネットワーク設定で接続する必要があります。TUNを使う場合は、DNSのリダイレクトとルーティングが実際に機能しているか確認してください。アプリ独自のセキュアDNSが従来のポートを使った取り込みを迂回することもあるため、切り分け時は別の要因として記録しましょう。

fake-ipと実アドレスによる名前解決

fake-ipモードでは、アプリに予約済みアドレス範囲内のマッピングアドレスを返し、コアがその対応関係からドメイン名を復元して接続を処理します。ドメイン情報を保ちやすい一方、通信が同じコアを通ることが前提です。アプリがマッピングアドレスを取得した後にプロキシ経路を迂回すると、接続できない可能性があります。LAN内サービス、デバイス検出プロトコル、アドレスに特別な前提を持つソフトウェアでは、この応答が適さない場合があります。必要に応じてフィルターで除外してください。ひとつのアプリの問題を解決するためにすべてのドメインを除外すると、fake-ipを選ぶ本来の利点が失われます。

redir-hostは通常、名前解決で得た実アドレスを返します。fake-ipとは動作が異なりますが、すべての環境でより安定するわけではありません。複数のドメインが同じ実アドレスを共有していたり、接続がコアに入った時点でドメイン情報が失われていたりすると、ルールの照合結果が変わる場合があります。モードを切り替えた後は、アプリのキャッシュを消すか接続を作り直してください。以前のアドレスが観察結果に影響し続けることがあります。予約済みアドレスが表示されても、それだけでネットワーク異常とは判断できません。また、実在するWebサイトのサーバーアドレスとして地理情報を調べないでください。

ドメインごとにDNSサーバーを指定する

nameserver-policyを使うと、特定のドメインに対して名前解決先を指定できます。社内ドメイン、家庭内デバイス名、明確な名前解決要件があるサービスに適しています。これは「どのDNSサーバーに問い合わせるか」を決める項目で、「どの経路で接続するか」は決めません。通信経路を変えるには別途ルールが必要です。内部DNSサーバーは特定のLANやVPN内でしか使えないことが多く、ネットワーク外で使い続けるとタイムアウトの原因になります。適用するネットワークを記録し、関係のないパブリックDNSに内部ドメインを問い合わせないようにしてください。

# 既存のdnsマップに追加し、トップレベルのdnsを重複して定義しない
dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

fallbackとフィルター条件は別の選択機能であり、メインDNSが失敗したときだけ使う予備サーバー一覧と単純に考えることはできません。結果を採用するかどうかは、アドレス範囲や関連するフィルター設定にも左右されます。明確な要件がなければ、「設定を完全にする」ためだけに複数のDNSサーバーを追加する必要はありません。設定が複雑になるほど、キャッシュ、ポリシー、フォールバックのどれが結果に影響したか判別しにくくなります。まず利用可能な上流DNSを1つに絞り、通信の取り込み経路を確認してからポリシーを段階的に追加すると、問題の発生箇所を特定しやすくなります。

DNSリークを確認する前に、どのリクエストをOSが解決し、どれをコアに渡し、どれをプロキシサーバーに処理させるのか、期待する動作を明確にしてください。そのうえで実際の接続と名前解決の記録を確認します。検査サイトに表示されるDNSの出口は一度のテスト結果にすぎず、アプリの動作確認の代わりにはなりません。名前解決が正常でもHTTPSエラーが出る場合、証明書検証をすぐに変更しないでください。プロキシ接続時の証明書エラー対処を参考に、システム時刻、信頼チェーン、ネットワーク環境を確認し、DNSと証明書の問題を分けて対処しましょう。

プロキシ項目と接続パラメーター

proxiesは静的な送信先の定義リストで、各項目に具体的な接続方式を記述します。プロキシ名はプロキシグループやルールから参照され、サーバーアドレス、ポート、プロトコル、認証項目によって接続できるかが決まります。名前に地域が含まれていても、管理者が付けたラベルにすぎず、サーバーの所在地や接続品質を証明するものではありません。接続失敗を調べるときは、表示名を何度も変更するのではなく、実際のプロトコルとサーバー側のパラメーターを確認してください。名前を変えると参照関係は変わりますが、リモートサーバーの問題は解決しません。

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

多くのプロキシ項目にはname、type、server、portがありますが、認証や通信方式の項目を別のプロトコルからそのまま流用することはできません。Shadowsocksでは暗号化方式とパスワードを使い、ほかのプロトコルではユーザー名、識別子、異なるTLSパラメーターを使う場合があります。同じ名前の項目でも、プロトコル実装によって対応状況が異なることがあります。サーバー側から提供されたパラメーターと現在のコアの対応範囲に従ってください。共有リンクの各部分を推測でYAMLに入力するのも避けましょう。エンコード、エスケープ、任意項目にはそれぞれ決まった規則があります。

# 構造の例：アドレスとパスワードは説明用の仮値
proxies:
  - name: サンプル出口
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上の例は静的プロキシの基本的な構成を示すもので、実際の接続には使えません。udp: trueはその送信先で該当機能を許可する指定ですが、通信経路全体がUDPに対応する保証ではありません。サーバー、プロトコル、ルーティング、アプリの接続方法が制限になる場合があります。TCPでWebページを開けても、音声通話、ゲームなどのUDP通信が使えるとは限りません。テストでは実際のアプリと同じ通信経路を使い、接続がコアに入ったか、対象の送信先が選ばれたか、サーバーが受け付けたかをそれぞれ確認してください。

TLS、サーバー名、トランスポート層

TLSを使うプロトコルでは、servernameなどのサーバー名項目がよく使われます。これはTLSハンドシェイクや証明書の名前照合に関係し、ローカルで表示する名前とは異なります。また、実際の接続先IPアドレスと一致するとも限りません。サーバーが特定の名前を要求する場合は正確に指定し、エラーを回避するために別のドメインへ変更しないでください。証明書エラーが発生したら、まずシステム時刻、証明書チェーン、パラメーターの整合性を確認します。証明書検証の無効化はセキュリティ上の前提を変えるため、通常のトラブル対処として使わず、複数の端末に配布する共通設定にも含めないでください。

トランスポートの種類、パス、リクエストヘッダーなどは別のレイヤーでネゴシエーションされます。WebSocket系のトランスポートでは、パスやHostがリバースプロキシの設定で決まることがあります。下位層のポートでTCP接続が確立しても、その後のトランスポートのハンドシェイクが成功するとは限りません。ログに接続リセットやハンドシェイク失敗が記録されたら、サーバーから提供された情報と照らし合わせて一つずつ確認してください。ドメイン、ポート、トランスポートを同時に変更するより、変更を一つに絞って失敗時のログを残すほうが原因を特定しやすく、一時的なネットワーク変動を設定修正の効果と誤認することも防げます。

プロキシプロバイダーとサブスクリプション形式

プロキシが多い場合は、proxy-providersでプロキシデータをメイン設定から分離できます。プロバイダーが返すのは通常、proxiesリストを含むYAMLで、任意の共有リンク集ではありません。また、Clashの完全な設定と同じ形式とも限りません。プロバイダーの種類、パス、更新間隔でデータの取得方法を指定し、プロキシグループからuseで参照します。読み込みに失敗したら、返された内容が想定した形式か確認してください。ログインページ、エラーメッセージ、HTMLページは、ダウンロードに成功していても有効なプロキシデータではありません。

# ローカルプロバイダー。pathsはコアの作業ディレクトリとクライアントの制約に合わせて設定
proxy-providers:
  ローカルプロキシ:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: プロバイダー選択
    type: select
    use:
      - ローカルプロキシ

ローカルプロバイダーの例を使うには、実際のデータファイルを事前に用意してください。パスは通常コアの作業ディレクトリを基準に解決され、クライアントによるパス制限の影響を受ける場合もあります。エディターで開いているフォルダーからの相対パスとは限りません。リモートプロバイダーでは更新失敗、キャッシュ、アクセス認証情報も関係します。サブスクリプションURLにはアクセス権限が含まれることが多いため、機密情報として扱ってください。スクリーンショット、ログ、エラー文を共有する際は、パスワードだけでなく完全なサブスクリプションURLとクエリパラメーターも削除し、他の人が同じサービスデータを取得できないようにしましょう。

設定全体でプロキシ名はできるだけ一意にし、プロキシグループ名や組み込みの送信先名との重複も避けてください。一括で名前を変更したら、静的な参照先もすべて更新します。プロバイダーを使う場合は、フィルター式が引き続き名前に一致するか確認してください。サービスの更新によって名前が変わったり、プロキシが削除されたりすることがあります。長期的に使うルールを頻繁に変わる個別プロキシに直接結び付けないでください。安定した名前のプロキシグループをルールの送信先にし、グループ側でプロキシの変更に対応すると、通信ルールとサーバー一覧を分けて管理できます。

プロキシグループの種類と参照関係

プロキシグループを使うと、「特定の通信にどの送信先を使うか」と「現在どのプロキシを選べるか」を分けて管理できます。ルールは安定したグループ名を参照したまま、グループ内のプロキシをサブスクリプション更新に応じて変更できます。グループを理解するには、種類、候補、参照元を合わせて確認してください。自動選択グループは通信が実際にそのグループを参照している場合にのみ機能します。画面上でテスト結果が表示されても、すべての接続がそのグループを使うとは限りません。トップレベルの手動選択グループが直接接続を選んだままなら、下位の自動選択グループが正常でも、その通信経路は変わりません。

手動選択、自動テスト、障害時の切り替え

selectは挙動を予測しやすく、接続先の変化に敏感なログインや業務用途に適しています。url-testはテスト用URLへの接続結果を比較しますが、測定されるのは特定のリクエストの完了状況であり、実アプリのスループットとは限りません。fallbackは候補の順序を重視し、主系と予備系を使い分ける用途に向いています。負荷分散を使っても、1つのファイルがすべてのプロキシを同時に使って速度を合算するわけではありません。方式によってはセッション中の送信先の安定性にも影響します。自動化の度合いを性能の順位と見なさず、用途が許容できる動作に合わせて選んでください。

ネストした構造と追跡しやすい経路

# 既存のプロキシ設定に追加して使用。サンプル出口は実際に存在する必要がある
proxy-groups:
  - name: 用途別プロキシ
    type: select
    proxies:
      - サンプル出口
      - 自動選択
      - DIRECT

  - name: 自動選択
    type: url-test
    proxies:
      - サンプル出口
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,用途別プロキシ

上の例では、ルールが「用途別プロキシ」を参照し、その先をユーザーが静的プロキシ、自動選択グループ、直接接続から選びます。ネストすると再利用しやすくなりますが、階層が深くなるほど最終的な送信先を追いにくくなります。グループ名には用途と役割を反映させ、「デフォルト」「その他」のような曖昧な名前を繰り返さないようにしましょう。AグループがBグループを含み、Bグループが再びAグループを参照するような循環参照も避けてください。循環参照は予備経路ではなく、送信先を決定できない依存関係のエラーです。コアやクライアントが読み込みを拒否する場合もあります。

自動テストのurl、interval、許容誤差はサービスの動作に合わせて設定してください。テスト先にアクセスできないと、本来は正常な複数のプロキシが同時に失敗と表示されることがあるため、一度のテストだけでプロキシを削除しないでください。テスト頻度が高すぎると、接続数やモバイル端末のバックグラウンド消費が増えます。低すぎると状態の変化を検知するのが遅れます。テスト先には単純で予測しやすい応答を返すものが適していますが、実際の接続先サービスとはネットワーク経路が異なることもあります。テスト結果からすべてのサイトでの使い勝手を推測しないでください。

プロバイダー、フィルター、選択状態の保持

グループがuseでプロキシプロバイダーを参照すると、候補はプロバイダーの内容に応じて変わります。さらに名前で絞り込む場合は、実際の名前に一致する式を設定し、更新後に候補が空になる可能性も考慮してください。すべての振り分けグループを脆弱な命名規則に依存させないでください。サーバー側でラベルが変更されると、設定全体で候補がなくなるおそれがあります。フィルターを使う場合は、テスト用設定で一致結果を確認してから本番のグループに反映してください。復旧しやすいよう、明確に利用できる手動の入口も残しておきましょう。

クライアントは手動選択を記憶することがありますが、設定の切り替え、名前の変更、キャッシュの再構築後に初期項目へ戻る場合もあります。グループの先頭項目に、文書化されていない安全上の役割を持たせないでください。通信の送信先を固定する必要がある場合は、設定の読み込み成功だけでなく、更新後の選択状態も毎回確認しましょう。既存の接続がグループの選択変更ですぐにすべて切り替わるとは限りません。接続の再利用、長時間接続、クライアントの動作が結果に影響するため、検証時は新しいリクエストを作成して実際の経路を確認してください。

モバイル端末で設定を管理する場合は、不要なヘルスチェックを減らし、同じプロバイダーに対するチェックとグループ内のテストがそれぞれ目的を持つようにしてください。各グループが同じプロキシ群をすべてテストすると、バックグラウンド通信が大幅に増えることがあります。バッテリーやバックグラウンド動作の設定については、スマホのプロキシアプリの電池消費とバックグラウンド設定もご覧ください。プロキシグループは送信先の選択を明確にするためのものです。すべての種類を使う必要はありません。2階層で説明できるルーティングを、何層もの選択ツリーにしないでください。

ルールの構文、順序、ルールセット

ルール一覧は、接続がコアに入った後のルーティング判断に使われ、通常は上から順に照合します。最初に一致したルールが送信先を決めます。すべての一致結果を合算して評価したり、具体的なルールを自動で上に移動したりすることはありません。ルールを管理するときは、個々の内容だけでなく、その前にどんなルールがあるかも確認してください。「ルールが効かない」という問題は、前方の広い条件に先に一致しているか、クライアントが別の設定を読み込んでいるケースがよくあります。接続ログで一致したルールを特定してから修正するほうが、対象サイトの地域から推測して変更するより確実です。

ドメイン、IPアドレス、最後のフォールバック

# 用途別プロキシは、実在するプロキシグループを指定する必要がある
rules:
  - DOMAIN,service.example.com,用途別プロキシ
  - DOMAIN-SUFFIX,example.net,用途別プロキシ
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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はドメイン名に完全一致し、DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。これらが照合するのは完全なWebページURLではありません。ルールにスキーム、パス、クエリパラメーターを含めないでください。DOMAIN-KEYWORDはキーワードで照合するため、範囲が広く、同じ文字列を含む別のドメインにも誤って一致することがあります。サービスのドメイン名が分かっている場合は、完全一致またはサフィックスのルールを優先してください。ひとつのサイトでも画像、ログイン、APIに複数のドメインを使う場合があります。メインページのルールが正しくても、すべての通信が同じ送信先になるとは限りません。

IP-CIDRとIP-CIDR6は、それぞれIPv4とIPv6のアドレス範囲を処理します。no-resolveは、この種類の照合のために対象ドメインの名前解決を新たに行わない指定です。直接接続を強制したり、DNSを遮断したりするものではありません。接続にすでに対象アドレスが含まれる場合は、該当するアドレスルールが照合されることがあります。広い範囲のIPルールをドメインルールより前に置くと、サービス名に基づいて処理したい接続が先に確定する可能性があります。ルールの種類ごとに機械的にまとめるのではなく、優先順位に合わせて並べてください。

ルールの照合には見えている情報が必要

ドメインルールが一致するかどうかは、コアが対象ドメインを認識しているかに左右されます。アプリがIPアドレスへ直接接続する場合、独自の名前解決結果を使う場合、通信の取り込み経路でドメイン情報が失われる場合は、ブラウザーのプロキシ通信とは結果が異なることがあります。対応する場面ではスニッフィングで一部の情報を補える場合がありますが、あらゆるプロトコルで元のドメインを復元できるわけではなく、暗号化を回避する機能でもありません。まずログにドメイン名とIPアドレスのどちらが表示されているか確認し、そのうえでドメインルール、IPルール、DNSや通信の取り込み方法のどれを調整すべきか判断してください。

MATCHは最後のフォールバックで、通常はリストの末尾に置きます。その後に通常のルールを追加しても照合されません。組み込みの送信先DIRECTは直接接続、REJECTは通信の拒否を表します。カスタムの送信先はプロキシ名またはグループ名と一致させてください。大文字・小文字の違い、見えない空白の混入、名前変更後の参照更新漏れによって、読み込みに失敗する場合があります。拒否ルールの範囲には特に注意し、まず対象を絞ったテストで確認してください。曖昧なキーワードをサブスクリプション全体に適用しないでください。

ルールプロバイダーとデータ形式

rule-providers:
  社内ドメイン:
    type: file
    behavior: domain
    path: ./rules/internal.yaml

rules:
  - RULE-SET,社内ドメイン,DIRECT
  - MATCH,用途別プロキシ

# ./rules/internal.yamlの内容
payload:
  - "+.home.arpa"
  - "+.lan"

ルールセットを使うと、大量のルールをメインファイルから分離して更新や再利用がしやすくなります。behavior: domainのデータにはドメインルールを記述します。IPアドレス用やクラシック形式のデータとは形式が異なるため、behaviorの値だけ変えて元のテキストを流用することはできません。クラシック形式では通常、照合条件を記述し、送信先はメイン設定のRULE-SETルールで指定します。完全な設定のルールを形式にかかわらず、すべての種類のデータにそのまま入れないでください。選択した形式に合わせて内容を確認してください。

リモートルールの更新には管理上の注意点があります。配布元がルールの範囲を追加・削除することがあり、キャッシュによって古い結果が使われ続ける場合もあります。ダウンロードに失敗しても既存ファイルが残ることがあります。ルールセットの配布元と用途を記録し、適用範囲が大きく重複するルールセットが異なる送信先を指定する場合は、優先順位を明確にしてください。プロキシのサブスクリプションと同様、ファイルの更新成功はデータを取得できたことを示すだけで、期待どおりに通信が処理される保証ではありません。更新後は、ルールに一致するリクエストと一致しないリクエストを最低1つずつ確認し、適用範囲が変わっていないか確かめましょう。

プロセスルールはOSやプロセス識別機能に依存するため、複数のシステムで共通設定を行う場合に唯一の振り分け方法として使うのは適切ではありません。ランチャー、子プロセス、コンテナ環境によってアプリ名が変わることもあります。Windows Storeアプリの接続記録がまったく見つからない場合は、まずリクエストがプロキシの入口に到達しているか確認してください。UWPのループバック除外設定も参考になります。通信がコアに入っていない状態で、ルーティングルールを繰り返し追加しないでください。ルールが処理できるのは受信済みの接続であり、入口側の隔離は解決できません。

サブスクリプションの上書き、マージ、更新順

サブスクリプション更新とローカルカスタマイズは、競合が起きやすい組み合わせです。リモートのサブスクリプションがプロキシ、プロキシグループ、ルールを配布し、ローカルではポートの固定、社内ネットワークへの直接接続の追加、一部通信の送信先変更などを行いたいことがあります。ダウンロード済みのサブスクリプション原文を直接編集すると、次回更新時に新しい内容で置き換えられる可能性があります。リモートの配布元はそのまま保持し、ローカルの変更はクライアントがサポートする上書き機能に記述してください。編集内容が保存されたかだけでなく、最終的な実行時設定のどこに反映されたかも確認しましょう。

最終的な設定を決める仕組みを確認する

クライアントによって処理の流れは異なります。サブスクリプションのダウンロード、解析と変換、設定単位の上書き、グローバルな上書き、GUI設定の反映、コアによる読み込みなどが行われる場合があります。このページでは、すべてのクライアントに共通する処理順を示すことはできません。使用中のクライアントでプレビューまたは実行時設定を確認し、観察できる項目を使って結果を検証してください。たとえばログレベルだけを変更して適用し、最終的な値を確認します。その上書き機能が現在のサブスクリプション生成に使われることを確かめてから、複雑なルールやDNS設定へ進みましょう。

上書きはYAMLに共通する固定の仕様ではなく、クライアントやツールが設定を変換する処理です。スカラー値は置き換え、マップは再帰的にマージ、リストは全体置換、追加、先頭挿入など、実装によって動作が異なります。「ディープマージ」でも、順序に依存するルールの優先順位は自動で解決されません。rulesの断片が2つあっても、自動的に連結されるとは限りません。また、特定クライアント専用の先頭挿入用キーを、コア標準の項目として別のクライアントへコピーしないでください。

マップとリストを分けて確認する

# 目標とする最終構造の例。すべてのクライアントで使える上書き構文ではありません
dns:
  enable: true
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - MATCH,用途別プロキシ

上の例は最終的に目指す構造を示しています。上書きツールがdns全体を置き換える場合、元の待ち受け、起動時の名前解決、フィルター項目もまとめて削除される可能性があります。nameserverに追加する動作なら、削除したかった上流DNSが残ることがあります。ルールは挿入位置も確認してください。カスタムの社内ネットワーク用ルールは、先に一致するフォールバックより前に置き、既存のMATCHの後ろへ追加しないでください。最終設定のプレビューでは項目の値とリスト内の位置を両方確認し、文字列検索だけで存在を確かめないようにしましょう。

参照の安定性と競合への対処

サブスクリプションで生成されるグループ名をカスタムルールが参照していると、配布元で名前が変わったときに参照が切れます。安定した名前のローカルグループをルールの送信先にし、そのグループから更新可能なプロキシやプロバイダーを参照する方法があります。ただし、使用する上書き機能がそのグループを確実に作成・保持できることが前提です。サブスクリプションと同じ名前のグループを作り、単純に「上書き」しようとしないでください。マージ方式によっては置換されず、同じ名前が重複することがあります。置き換える場合は、古い項目を明示的に削除するか、ツールの項目変換機能を使い、最終リストで名前が一意か確認してください。

同じサブスクリプションでも、プラットフォームごとに異なる初期値を持つ場合があります。上書き設定を複数の端末で同期するときは、端末固有の違いを無視しないでください。DNSの待ち受けアドレス、LANのアドレス範囲、TUNの権限、ローカルファイルのパスは端末環境に依存するため、そのまま共有するのに適していません。カスタム設定を共通の業務ルールと端末固有の設定に分け、用途と依存条件をコメントに記載することをおすすめします。これにより、PCやクライアントを変更してもルールの意図は保ちつつ、入口や権限を環境に合わせて調整できます。古い実行時設定全体を新しいサブスクリプションとして扱わないでください。

スクリプトによる上書きは、別のコメント形式ではなく設定全体を変更できるコードとして扱ってください。スクリプトの例外で生成が中断したり、誤ったオブジェクト参照で項目が削除されたり、型が変わったりする可能性があります。変換の対象を絞り、入力が空の場合、リストが存在しない場合、名前が一致しない場合の処理を明確にしてください。ルールを1つ追加するためにプロキシ一覧全体を再構築しないでください。不要な書き換えが増えるほど、サブスクリプション更新後の故障範囲が広がります。問題がどの段階で起きたか分かるよう、スクリプトとYAMLは別々にバックアップしてください。

更新後の回帰テストと移行

上書き設定を終えたら、少なくとも一度は更新テストを行ってください。まずバックアップを取り、サブスクリプションを更新した後、実行時設定と接続経路を確認し、カスタムルール、グループの選択状態、DNS項目が残っていることを確かめます。手動で適用したときに動作しても、自動更新の処理が正しいとは限りません。更新後に問題が出たら、まずローカル上書きを一時的に無効にし、元のサブスクリプションが動くか確認してから、上書きを段階的に戻してください。開発が終了したクライアントからの移行については、Clash Verge Revへの移行方法の比較を参照してください。古い画面のキャッシュ状態ではなく、設定の意図を引き継ぐことが大切です。

設定の検証、トラブル対処、メンテナンス

設定は段階的に検証します。まずテキストを解析できるか、次にコアが項目と参照関係を受け付けるかを確認し、待ち受けの入口、名前解決、ルーティング、アプリの動作へ進みます。設定テストに合格したことが示すのは、現在のコアがファイルを解釈できることだけです。サーバーに接続できる、パスワードが正しい、対象サービスにアクセスできるとは限りません。Webページが開いても、そのリクエストが成功したことしか分かりません。LAN、UDP、バックグラウンドアプリ、サブスクリプション更新など、別の経路も確認してください。テストごとに入力、期待する結果、実際の観察結果を記録すると、「正常」とだけ記録するより役立ちます。

オフライン検証から実行時の確認まで

# Mihomoをインストール済みでコマンドを実行できる場合は、設定ファイルのあるディレクトリで実行
mihomo -t -f ./config.yaml

# Windows PowerShellで実行ファイルが現在のディレクトリにある場合
.\mihomo.exe -t -f .\config.yaml

コマンドはコアプログラムを実際にインストールした環境でのみ使えます。GUIクライアントは独自の作業ディレクトリ、アクセス制限付きパス、生成ファイルを使うことがあります。外部のコアで実行中のインスタンスをむやみに上書きしないでください。ローカルプロバイダーをテストする場合は、相対パスの基準と作業ディレクトリが一致しているか確認してください。メイン設定の構文が正しくても、データファイルが見つからず失敗することがあります。エラーには項目名、名前、行番号が含まれる場合があります。まず最初の意味のあるエラーから対処してください。後続のエラーは同じ階層の問題に起因する連鎖反応かもしれません。

テストに合格したら、現在のクライアントが実際にその設定を選択し、読み込んでいるか確認してください。ログで読み込み結果、待ち受けアドレス、権限エラーの有無を確認します。ポートの競合、TUNデバイスの作成失敗、サブスクリプションの取得失敗はそれぞれ別の段階で起きるため、すべてをプロキシの問題と決めつけないでください。設定の読み込みが拒否された場合、クライアントによっては以前の状態を保つことがあります。「ネットワークがまだ使える」からといって、新しい設定が適用されたとは限りません。変更した項目を1つ選んで実際の値と照らし合わせ、古い状態を新しい結果と取り違えないようにしましょう。

最小限の接続経路でリクエストを検証する

# HTTPプロキシの入口を明示し、アプリがシステムプロキシに従うかどうかの影響を除外
curl -I --proxy http://127.0.0.1:7897 https://example.com/

# SOCKSの入口。hは接続先ドメインの名前解決をプロキシ側に任せる指定
curl -I --proxy socks5h://127.0.0.1:7897 https://example.com/

これらのコマンドは、明示したプロキシの入口を確認するためのものです。例に使うテストサービスは、常に同じステータスコードを返すことを保証していません。HTTPエラーレスポンスが返ることと、プロキシ接続自体を確立できないことは別の結果です。前者なら少なくとも何らかのHTTPサービスまでリクエストが届いています。後者では待ち受け、プロトコル、通信経路を確認してください。Windowsでcurlが別コマンドのエイリアスになっている場合は、curl.exeを呼び出す必要があるか確認しましょう。コマンドが成功したからといって、ブラウザーでも同様に動くとは限りません。ブラウザーは拡張機能、内蔵の名前解決、既存の接続プールを使う場合があります。

元に戻せる変更手順を作る

一度に変更する項目は1つに絞り、変更前のファイルと簡単な説明を保存してください。バックアップにはメイン設定だけでなく、ローカルプロバイダー、ルールデータ、上書きスクリプトも含めましょう。含まれていないと、メインファイルを復元しても変更済みのデータを参照してしまう可能性があります。ファイル名には用途と保存日を含めても構いませんが、機密性の高いサブスクリプションURLは記載しないでください。システムプロキシ、DNS、TUNを変更する場合は、無効化後に元へ戻す方法も記録します。リモート接続中の端末でデフォルトルートを変更する前は、プロキシに依存しない復旧経路を必ず用意してください。

問題を再現するときは、関係のないプロキシのインスタンスを停止し、テスト先を固定して、直接接続とプロキシを明示した接続をそれぞれ比較してください。特定のアプリだけで発生する場合は、サブスクリプション全体をすぐに置き換えず、通信の取り込み方法、名前解決の方法、プロセスの経路を記録します。すべてのプロキシが同時に失敗する場合は、ローカルネットワーク、上流DNS、テスト先を確認してください。一部のプロキシだけが失敗する場合は、サーバー側とプロトコルのパラメーターを調べます。この順序で切り分けると不要な変更を減らし、ログと実際の問題を対応させやすくなります。

長期的なメンテナンスでは、不要になったカスタム設定も確認してください。使わなくなったルールセット、古いネットワーク範囲、名前変更後のグループ参照、一時的なトラブル対処のために追加した例外などが対象です。サブスクリプションやクライアントを更新した後は、すべてのWebページを再テストするのではなく、まずこうした境界を確認しましょう。他の人に相談する場合は、機密情報を削除した最小構成、エラーメッセージ、通信の取り込み方法、期待する経路を共有してください。よくある入口の問題はトラブル対処を、初回接続の問題は入門ガイドを参照し、手順に沿って確認してください。