Clash 設定ガイド

構造の基本 / 01

YAMLの構造と設定ファイルの参照元

マップ・リスト・参照の違い

設定ファイルは表示順に実行するコマンド列ではなく、カーネルが読み込む構造化データです。コロンの左側が項目名、右側が値です。値をその場に書かない場合、次の階層のインデントが子項目を表します。トップレベルの dns はマップ、rules はリスト、proxies は複数のノードマップからなるリストです。まずデータ型を見分けてから編集すれば、画面上の位置から項目を推測するより確実です。

インデントには半角スペースを使い、タブを混在させないでください。読みやすさのためにスペース2つがよく使われますが、すべての箇所で必須というわけではありません。重要なのは同じ階層を揃え、子階層を一段深くすることです。リスト項目のハイフンの後と、通常の項目のコロンの後にはスペースが必要です。全角のコロンやスペース、チャットアプリからコピーしたスマートクォートは見た目が似ていても、解析エラーの原因になることがあります。

mixed-port: 7890
mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

上の例では、name、type、proxies が同じプロキシグループに属しています。グループ内の proxies に記述するのはノード名のリストであり、接続パラメーターではありません。末尾のルールにある「手動選択」はグループ名と完全に一致させてください。スペース、大文字・小文字、記号も区別されます。YAMLとして解析できても、参照先の名前が存在しなければカーネルが読み込みを拒否する場合があります。

文字列と重複項目の注意点

名前に特殊な記号が含まれる場合は、引用符で囲むのがおすすめです。パスワードにシャープ記号、コロン、前後の空白が含まれる場合も、文字列として明示しましょう。ダブルクォートではバックスラッシュによるエスケープが処理されます。内容をそのまま記述するならシングルクォートが便利ですが、シングルクォート自体は適切にエスケープする必要があります。ポート番号は整数、真偽値は true または false とし、見た目を揃えるためにすべての値を引用符で囲まないでください。

同じマップ内で項目を重複して定義しないでください。たとえばファイルの先頭に dns があるのに、末尾にもう一つ dns を追加すると、解析方法によっては読み込みが拒否されたり、後の項目だけが残ったりします。重複キーによる上書きに頼るより、既存のマップに項目を追加するほうが安全です。コメントはシャープ記号から始まり、変更理由などの説明に使います。コメントは実行設定にはならず、エラー行をコメントアウトして参照先の不整合を隠すこともできません。

編集対象の設定ファイルを確認する

クライアントは通常、サブスクリプションの元データ、ローカル編集用のコピー、実際に使う最終設定をそれぞれ保持します。元データはリモート更新の入力、ローカルコピーは編集専用の場合があります。最終設定はクライアントがポートや管理インターフェース、上書き内容などを追加して生成します。まずクライアントで現在有効なプロファイルを確認し、実行設定またはカーネルログに表示される読み込みパスを調べましょう。エクスプローラーに config.yaml があるからといって、それが現在使用中のファイルとは限りません。

編集前に元ファイルをコピーし、用途が分かる名前で保存してください。編集後は保存してから、クライアントの再読み込みを実行します。エディターを閉じただけでは、カーネルが設定を読み直すとは限りません。画面上で保存できても動作が変わらない場合は、選択中のプロファイル、生成先、再読み込み結果を先に確認してください。すぐにルール自体を疑う必要はありません。サブスクリプションの更新で元ファイルが再生成されることがあるため、継続して使う変更はクライアントが対応する上書き機能に設定しましょう。

このページは設定項目の意味ごとに整理しており、すべてのクライアントで全項目を変更できるとは限りません。まずカーネルがmihomoであることを確認し、現在のバージョンが対応する項目と照らし合わせてください。旧Clashクライアントを現在のmihomo実装と同じものとして扱うことはできません。

不明な項目があれば、まず設定範囲を一つのセクションに絞り、カーネル、クライアント、外部ツールのどれに属するかを確認します。クライアント固有の項目をカーネル設定に入れると、無視されたり不具合の原因になったりすることがあります。基本用語を確認したい場合は、用語の早見表を読んでから該当する章に戻りましょう。すべての設定を一度に理解する必要はありません。

起動と動作 / 02

ポート・動作モード・管理インターフェース

ローカルの待ち受けとシステムプロキシは別の設定

mixed-port は一つのポートでHTTPプロキシとSOCKS5プロキシの両方を受け付けるため、デスクトップアプリの設定をまとめやすくなります。port はHTTPプロキシ専用、socks-port はSOCKSプロキシ専用の入口です。通常の利用では混合ポート一つで足りることが多く、すべての入口を同時に有効にする必要はありません。ポート番号はローカルの待ち受け位置を示すだけで、サーバーのアドレスやノードの品質、対応プロトコルを表すものではありません。

カーネルが待ち受けを開始しても、OSが通信を自動的にそこへ送るとは限りません。システムプロキシの切り替えは通常クライアントが管理し、OSのプロキシ設定を更新します。その設定を参照するアプリもあれば、個別のプロキシ設定を使うものや、直接接続するものもあります。トラブル対処では、まず待ち受けが成功しているかを確認し、次にアプリがその入口を使っているかを調べてください。「システムプロキシが有効」と「すべてのアプリがプロキシ経由で通信する」は同じ意味ではありません。

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

ルール・グローバル・直結の違い

mode: rule はルールの順序に従って接続先を決めます。振り分け設定を理解する出発点です。グローバルモードでは通常の接続がグローバルポリシーに渡されますが、適切な出口を選ぶ必要があり、使えないノードを自動で直す機能ではありません。直結モードは一時的にプロキシを介さず比較するときに使えます。モードを変更しても、確立済みの長時間接続は以前の経路を使い続ける場合があります。動作を確認する際は、接続を再利用しているページを更新するだけでなく、新しいリクエストを発行してください。

log-level: info は起動や接続状態を日常的に確認するのに適しています。調査中は一時的に詳細度を上げられますが、ログの量が増え、アクセス先などの機密情報が含まれる可能性もあります。確認が終わったら元の設定に戻し、ログを共有する前にサブスクリプションURLや認証情報を削除してください。ipv6: false はOS全体でIPv6を無効にする設定ではなく、アプリが別経路でIPv6を使うのを単独で防ぐものでもありません。DNSと通信の取り込み範囲もあわせて確認してください。

LAN共有と管理インターフェースは別々に設定

allow-lan はLANからのアクセスを制御し、bind-address は待ち受けアドレスを指定します。例ではループバックアドレスに限定しているため、接続できるのは同じ端末だけです。LANアクセスを許可しても、待ち受けアドレスが他の端末から到達可能かを確認する必要があります。共有する場合は、使用するローカルインターフェースや必要な待ち受け範囲を明示し、自宅やオフィスなどの環境に応じてファイアウォールの接続元を制限してください。

LAN共有を有効にしたら、スマートフォンにはPCのLAN内アドレスとプロキシポートを設定します。127.0.0.1 は使いません。スマートフォン上のループバックアドレスはスマートフォン自身を指します。PCのアドレス変更、ゲストネットワークの端末間通信制限、スリープ、ファイアウォールによって共有できなくなることがあります。設定方法は混合ポートとLAN共有の解説を参照してください。共有する前にネットワークの利用ルールを確認し、信頼できないネットワークでアクセスを許可しないでください。

external-controller はクライアントや管理パネルからカーネルを操作するためのインターフェースで、ブラウザーがインターネットに接続するためのプロキシ入口ではありません。通常、デスクトップクライアントではループバックでの待ち受けで十分です。リモート管理が必要な場合は、強固な認証を設定し、アクセス可能なネットワーク範囲を制限してください。スマートフォンでプロキシを共有するために管理インターフェースまで公開しないでください。画面からカーネルに接続できない場合は、管理ポートとプロキシポートを分けて確認し、変更箇所を間違えないようにしましょう。

ポートが使用中の場合は、まず別のプロキシプロセスを終了してから設定を再読み込みしてください。ポートを変更する必要がある場合は、システムプロキシ、アプリ個別のプロキシ設定、LAN内の端末設定もあわせて変更します。YAMLだけ変更してシステム側に古い入口を残すと、カーネルは正常でもブラウザーが接続できないことがあります。一度に関連する項目だけを変更すれば、原因を特定しやすくなります。

名前解決 / 03

DNS・fake-ip・名前解決の経路

まず、どこが名前解決しているか確認

DNSはドメイン名をIPアドレスに変換しますが、実際の名前解決はアプリ、OS、ブラウザー、プロキシカーネル、リモートのプロキシサーバーのいずれかで行われます。カーネルのDNSを有効にしても、すべてのアプリの問い合わせがカーネルに届くとは限りません。システムプロキシだけでは、通常OS全体のDNS問い合わせは自動的に取り込まれません。TUNによるDNSハイジャックにも対象範囲があります。まず通信経路を整理してから設定を選び、カーネルDNSを変更しながら、それを迂回するブラウザー内蔵の名前解決を試すようなことを避けましょう。

dns.enable はカーネルのDNSモジュールを有効にし、listen は待ち受けアドレスを指定します。例ではループバックアドレスと高めのポートを使い、一般的なシステムポートとの競合を避けています。待ち受け項目を記述しただけでは、OSが自動的にそのアドレスを使うようにはなりません。デスクトップクライアントではTUNなどの連携機能を通じて問い合わせをカーネルに送る場合があります。実際の設定を確認し、以下をシステムDNS全体の取り込み設定としてそのまま使わないでください。

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

fake-ipと実アドレスモード

fake-ip は問い合わせを受けたドメインに仮想アドレスを割り当てます。その後の接続がカーネルに届くと、対応関係からドメイン名を復元できるため、ドメインによるルール振り分けがしやすくなります。例のアドレス範囲はこの機能用に予約されたもので、ノードの server に指定できる公開サーバーアドレスではありません。名前解決結果がこの範囲にある場合は、fake-ipモードかどうかを確認してから、DNS汚染と判断してください。

redir-host は通常、実際に名前解決したアドレスを返します。実アドレスが必要な場合に適していますが、あらゆる名前解決の問題を解決する設定ではありません。モードを切り替えるとアドレスのキャッシュや接続動作が変わりますが、古いキャッシュが確認結果に影響する場合があります。変更後は設定を再読み込みし、OSやアプリに応じてキャッシュを消去するか、関連アプリを再起動してください。まず対象を一つに絞って試し、モード、上流DNS、ルールを同時に変更しないようにしましょう。

fake-ip-filter は指定したドメインに仮想アドレスを割り当てないようにする設定です。LAN内サービス、デバイス検出、実アドレスが必要なアプリなどを個別に追加できますが、対象を広げすぎるとドメインマッピングの利便性が損なわれます。フィルターモードやマッチ構文にはそれぞれ意味があり、すべてを通常の正規表現として解釈することはできません。問題が確認されたドメインから追加し、理由を記録して、説明できないフィルターが増えないようにしましょう。

上流DNSとノードのドメイン解決

nameserver は通常の問い合わせに使う上流DNSの一覧です。default-nameserver は上流DNSサービス自体のドメイン名を解決するための初期DNSとして利用できます。すべての上流をドメイン名で指定し、最初の名前解決経路を用意しないと、起動時に依存関係の問題が発生する場合があります。proxy-server-nameserver はプロキシサーバーのドメイン名を解決し、まだ確立していないプロキシ接続にノードのアドレス解決が依存するのを避けるために使います。上流は接続元ネットワークから到達できるものを選び、数を増やせば安定するとは考えないでください。

nameserver-policy では、特定のドメインやマッチ範囲に応じて上流を選べます。fallback と関連するフィルター条件は、条件に応じて名前解決結果を判断するための設定です。単純に「最初が失敗したら次へ問い合わせる」という仕組みではありません。明確な要件がなければ、挙動を把握しやすい単一の経路から始めてください。ルーティングルールに沿ってDNSの上流接続を制御する場合は、関連項目が現在のバージョンでサポートされているか、ノードのドメイン解決をどう行うかも確認し、DNSとプロキシが互いの起動を待ち続けないようにしましょう。

暗号化DNSを使うと変わるのは、名前解決の一部で使う通信方式です。アプリの問い合わせを自動的に取り込む機能ではなく、すべての通信出口を統一する設定でもありません。検出結果はOSのDNS設定、ブラウザーの設定、現在の接続ログとあわせて確認してください。

トラブル対処では、まずドメインを名前解決できるか、次に返されたアドレスへ接続できるか、最後に通信がどの出口を通ったかの順に確認します。ドメインだけ失敗してアドレスには接続できる場合は、名前解決が原因である可能性が高くなります。証明書エラーやサーバーからの拒否を、すぐDNSの問題と判断しないでください。詳しい手順はDNSテストとfake-ip設定の実践ガイドを参照してください。設定を一つずつ比較して元に戻せるよう、現在の上流設定を保存しておきましょう。

接続先の定義 / 04

プロキシノードとリモートノードの集合

ノード項目には実際のサービス情報を設定

proxies にはノードの接続パラメーターを記述します。各ノードには、参照可能な名前に加え、プロトコルに必要なアドレス、ポート、認証情報などが必要です。ノードは実際の出口であり、プロキシグループは出口を選ぶ仕組みです。両者を混同しないでください。サブスクリプションにノードが含まれている場合、通常は一つずつ手入力する必要はありません。項目を確認するとき、自分のサーバーを追加するとき、最小構成を試すときにノード部分を編集し、元の内容も保存してください。

以下ではHTTPプロキシを例に項目の構造を示します。ドメイン名と認証情報は架空の値であり、このままでは接続できません。server にはホスト名またはアドレスだけを指定し、https:// やWebページのパスを付けないでください。port はリモートサービスのポートであり、ローカルの混合ポートではありません。認証情報はサービス提供元から取得した値を使います。名前を変更したり別のポートを試したりして、有効な設定を推測することはできません。

proxies:
  - name: "サンプル用の出口"
    type: http
    server: proxy.example.com
    port: 443
    username: "your-username"
    password: "your-password"
    tls: true
    sni: proxy.example.com
    skip-cert-verify: false

name は設定内でノードを識別するために使います。名前を変更したら、プロキシグループやノードを直接指定するルールも更新してください。同じ名前で異なるパラメーターを設定すると、統合時に判別しにくくなります。ローカルで追加するノードには区別しやすい接頭辞を付けると便利ですが、パスワード、サブスクリプションの識別情報、個人の連絡先は名前に含めないでください。ノード名は画面やログ、スクリーンショットに表示されることがあるため、共有される可能性のある情報として扱いましょう。

プロトコルと通信方式の項目を混同しない

プロトコルごとに必要な項目は異なります。Shadowsocksでは暗号化方式とパスワード、Trojanでは認証とTLSの設定が関係します。VMessやVLESSなどには、それぞれ固有のIDや通信方式の項目があります。他人の設定に uuid、network、通信方式の項目があっても、現在のノードに必要とは限りません。まずプロトコルを確認し、次にサーバー側の通信方式、最後にカーネルの対応範囲を照合します。異なるプロトコルの設定例を組み合わせて一つのノードにしないでください。

TLSのサーバー名と証明書検証は別途確認が必要です。アドレスで接続していても、サーバー証明書はドメイン名に対して発行されている場合があるため、サービスに合わせて sni を設定します。値を適当に決めることはできません。証明書検証を無効にすると重要な認証情報を確認できなくなるため、日常的なトラブル対処の近道として使わないでください。証明書エラーが発生したら、システム時刻、サーバー名、サーバー証明書のチェーンを確認します。詳しくはプロキシ利用時のHTTPS証明書エラーの原因と対処を参照してください。

ノード設定のUDP対応も、要素ごとに確認が必要です。カーネルが通信方式に対応していても、リモートサービス、利用中のネットワーク、接続先アプリが同じ経路をサポートするとは限りません。HTTPプロキシの例を任意のUDP出口として使うことはできません。Webサイトは見られても通話、ゲーム、ほかのアプリに問題がある場合は、実際に使われているプロトコルとリモート側の対応状況を確認してください。クライアントに接続済みと表示されるだけでは判断できません。サブスクリプションに未知のプロトコル拡張があっても、確認せず削除しないでください。

providerはノードの集合であり、選択ルールではない

proxy-providers はファイルやリモートリソースからノードの集合を読み込みます。プロキシグループは use でその集合名を参照し、含まれるノードを選択肢に追加します。リモートリソースはカーネルが解釈できるノード集合の形式である必要があります。完全なサブスクリプションファイルとprovider用のファイルは、必ずしも互換性がありません。ダウンロードに成功しても、形式、項目、ノード一覧が有効かどうかは別に確認してください。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: "サブスクリプションの出口"
    type: select
    use:
      - local-nodes

上の例ではローカルファイルが必要で、ファイル内に対応する proxies リストが含まれている必要があります。相対パスは通常、カーネルの作業ディレクトリかクライアントが指定した設定ディレクトリを基準に解決されます。エディターで開いているディレクトリとは限りません。ダウンロード、更新、ヘルスチェックはそれぞれ別の処理です。更新はノード情報の取得、ヘルスチェックは接続可能性の確認、選択ポリシーは実際に使うノードの決定を行います。一つの処理が成功しても、ほかの結果を保証するものではありません。

実際のサブスクリプションURLには、個人用のアクセス情報が含まれていることがあります。公開設定、問題報告のスクリーンショット、コードリポジトリに載せないでください。構造を示すときは、明らかな架空の値に置き換えます。更新に失敗した場合は、まずネットワーク、サブスクリプションの有効状態、取得した内容の形式を確認してからYAMLを調べましょう。サーバーがログイン画面やエラーメッセージを返している場合、拡張子がYAMLでも正常なノード集合として読み込むことはできません。

出口の選択 / 05

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

まず手動選択の経路を動かす

proxy-groups ではノードやほかのポリシーをまとめ、接続先として選択できるようにします。初めて設定する場合は、まず select グループを作り、動作確認済みのノードを画面から手動で選んでください。こうすれば「ノードに接続できない」問題と「自動選択の挙動が想定と異なる」問題を切り分けられます。ルールからグループ名を指定し、グループから実際のノードを選ぶ参照関係にすれば、ドメインごとにノード名を繰り返し記述する必要がありません。

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - サンプル用の出口
      - DIRECT

  - name: "Webアクセス"
    type: select
    proxies:
      - 手動選択
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Webアクセス
  - MATCH,手動選択

この例は前の章で定義した「サンプル用の出口」を使います。例のドメインにアクセスすると、ルールはまず「Webアクセス」グループに通信を渡します。そのグループで「手動選択」を選んでいれば、次に手動選択グループで選択中のメンバーが使われます。グループを入れ子にすると管理しやすくなりますが、循環参照は作らないでください。AグループがBグループを参照し、BグループがAグループを参照すると、出口を決められません。設定を確認するときは、ルールの宛先からノードまたは組み込みポリシーまで順にたどりましょう。

自動テストの結果は実際の使い勝手とは限らない

url-test はテスト結果に応じてメンバーを選び、fallback は候補順に利用可能なメンバーを使います。load-balance は設定した方式で接続を振り分けます。それぞれ役割が異なるため、自動で動くという理由だけで置き換えないでください。速度テストのURLでの結果は、その接続先までの状況を示すもので、特定の動画サイト、業務サービス、アカウントへのログインも同じように動くとは限りません。特定のサービスで問題が起きた場合は、実際の用途に合わせて確認してください。

proxy-groups:
  - name: "自動テスト"
    type: url-test
    proxies:
      - サンプル用の出口
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

構造を示すため、例には候補を一つだけ記載しています。実際に比較するには、利用可能なメンバーが複数必要です。interval はテスト間隔、tolerance はわずかな差による切り替えを抑えるための設定、lazy はグループを使用していない間のテスト動作に影響します。テスト頻度を上げるとバックグラウンド通信も増えますが、必ず使い勝手が良くなるわけではありません。モバイル端末ではバックグラウンド制限やバッテリー消費も考慮し、まずクライアントの標準設定を使って、具体的な問題がある場合に調整してください。

自動グループが切り替わっても、既存の長時間接続は以前の出口を使い続けることがあり、新しいリクエストから新しい選択が適用されます。確認時は新しい接続を作り、接続一覧で実際の経路を確認してください。サービスによってはログイン状態と接続元の環境が関連付けられているため、頻繁に切り替えると再認証を求められることがあります。セッションを安定させたい場合は、すべての接続で同じ自動切り替えを使うのではなく、そのサービス用の手動グループを作る方法があります。

集合の参照・フィルター・選択状態の保存

グループ内の proxies はメンバー名を明示し、use はprovider名を参照します。フィルター式は通常、名前を条件にメンバーを絞り込むもので、ノードが名前どおりの場所にあることや、ネットワーク上の属性を保証するものではありません。サブスクリプション側で名前が変わると、フィルター結果が空になることがあります。まず最終的なメンバー一覧を確認してから式を調べてください。グループ名が存在するだけで、利用可能なノードが含まれているとは限りません。

組み込みの DIRECT は直結、REJECT は接続拒否を表し、どちらもリモートノードではありません。直結を自動テストグループに入れると、候補として比較されます。障害時だけ手動で切り替えたい場合は、外側の手動グループに追加してください。自動フォールバックと直結へのフォールバックも同じではありません。プロキシを迂回してよいかはルーティングの判断なので、用途に応じて明確に設定してください。

クライアントによってはグループの選択状態を保存し、設定の再読み込み後も以前の選択を復元します。通常はグループ名、メンバー名、状態の保存方法に依存します。グループ名を変えたり、サブスクリプションからノードが削除されたりすると、以前の選択を復元できない場合があります。カーネルの profile.store-selected は選択状態の保存に関係しますが、クライアント側で独自に管理している場合もあります。YAMLの並び順だけで選択中の項目を判断せず、画面上の現在の値を確認してください。

プロキシグループを追加したら、メンバーが存在するか、循環参照がないか、ルールが正しく参照しているか、現在の選択肢が利用可能かを順に確認します。4項目すべてを確認して初めて、グループが実際の通信経路に組み込まれたと言えます。

「ルール」「プロキシグループ」「ノード」の違いは、マッチ条件、出口の選択、接続パラメーターの3段階で考えると分かりやすくなります。ルールが通信を渡す先を決め、グループが出口を選び、ノードがリモートへの接続方法を決めます。構造をシンプルに保てば、ノードを入れ替える際も通常はメンバーの変更だけで済み、業務用ルール全体を書き直す必要がありません。

通信の振り分け / 06

ルールの順序・ルールセット・最終ルール

上から順に照合し、マッチしたルールのポリシーを適用

ルールモードでは、通常のルーティングルールを上から順に照合し、マッチしたルールに指定された宛先を使います。より具体的な例外は、一般的なルールより前に置くのが基本です。どのルールにもマッチしなかった接続を受ける MATCH は末尾に配置します。最終ルールを先に置くと、その後のルールが使われなくなります。ドメイン名が一覧にあっても、そのルールが実際に適用されるとは限りません。前にあるサフィックスルール、IPアドレスルール、ルールセットが先にマッチしている場合があります。

rules:
  - DOMAIN,login.example.com,手動選択
  - DOMAIN-SUFFIX,example.com,DIRECT
  - 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,手動選択

上の例では、まずログイン用のドメインだけをプロキシに送り、その後、残りの例示ドメインを直結にしています。最初の2行を入れ替えると、ログイン用ドメインも先にあるサフィックスルールにマッチします。例にある「手動選択」は、定義済みのポリシー名である必要があります。ルール構文のカンマは項目の区切りなので、全角カンマに置き換えないでください。宛先名に説明文を付け足すこともできません。ルールを編集したら、まず対象を一つ決めて、マッチしたルールの種類とポリシーを確認してから、ほかのサイトも検証しましょう。

ドメイン情報とIPアドレス情報が常にそろうとは限らない

ドメインルールを適用するには、カーネルが接続先のドメイン名を取得できる必要があります。HTTPプロキシやSOCKSのドメイン名リクエストでは情報を確認しやすい一方、アプリが先に名前解決してからIPアドレスへ接続する場合、カーネルに届く情報は異なることがあります。fake-ipの対応関係やスニッフィングでドメイン名を復元できる場合もありますが、暗号化された通信をすべて識別できるとは限りません。まず接続一覧に何が表示されているか確認し、ドメインルールにマッチしない理由を判断してください。

no-resolve は対象となるIPアドレスルールに指定し、そのルールを試すためだけに名前解決を開始するのを防ぎます。接続にすでにマッチするアドレス情報が含まれていれば、ルールに該当する場合があります。この設定はDNS全体を無効にするものでも、アプリ自身が行う問い合わせを変更するものでもありません。IPアドレスルールを前方に置く場合、名前解決の有無が通信経路や所要時間に影響することがあります。ドメインルールとの優先順位も考慮し、すべてのルールに機械的に同じ設定を追加しないでください。

ルールセットは定義と利用をセットで設定

rule-providers で再利用可能なルールセットを定義し、RULE-SET でルール一覧に組み込みます。定義しただけでは通信は振り分けられません。behavior はドメイン、IPアドレス範囲、クラシック形式のどれとして内容を解釈するかを指定し、format はファイル形式を指定します。どちらも実際のファイルに合わせる必要があります。リモートの更新URLとローカルのキャッシュパスは別々に確認してください。キャッシュがあるからといって、直近の更新に成功したとは限りません。

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,手動選択

この設定に対応するローカルルールファイルは、以下のような形式で記述できます。ここにあるのはドメインの集合であり、ルーティングルールの完全な1行ではないため、ポリシー名は付けません。ドメインセットにクラシック形式のルールを入れると、解析エラーになったり、想定外のマッチが起きたりする場合があります。外部のルールソースを移行するときは、ファイル名だけで形式を判断せず、実際の内容を確認してください。

payload:
  - "example.com"
  - "+.example.org"

ルーター、コンテナ、TUNの通信にプロセスルールを使う場合は、実行環境がプロセスを識別できるか確認してください。デスクトップアプリ名を使ったルールを、そのままルーターでも使えるとは限りません。ルーターから見えるのは、接続元端末からの通信です。構成の背景はOpenWrtのバイパスルーター構築ガイドを参照してください。ルールは実際に取得できる情報に基づいて設定し、環境から得られない項目に依存させないようにしましょう。

最終確認では、接続先ドメイン、マッチしたルール、実際の出口の3点を記録してください。Webページが開くだけでは、プロキシ接続に成功したのか直結で到達できたのか区別できません。問題が起きたら、まず一時的にドメインを完全一致するルールで確認し、その後に対象範囲を広げるか判断します。キーワードやアドレス範囲を広く指定すると、ほかの通信に影響したり、後から問題を再現しにくくなったりします。

変更の永続化 / 07

サブスクリプションの上書き・統合・更新後の保持

設定が生成される流れを確認

サブスクリプションを更新すると、リモートの内容が再取得されます。ダウンロードしたファイルを直接編集しても、その変更は更新時に失われる可能性があります。クライアントの上書き、統合、拡張設定、スクリプトは通常、元の内容に追加の処理を行いますが、実行順序や統合方法は共通ではありません。元のサブスクリプション、クライアント共通設定、サブスクリプションごとの上書き、最終的な実行設定の順序を確認してから、どの階層に変更を加えるか決めましょう。

ポート、システムプロキシ、TUNなどはクライアントの画面から管理され、サブスクリプションに同じ項目があっても上書きされることがあります。ルールやプロキシグループは、サブスクリプションごとの拡張設定で追加される場合があります。同じ項目を複数の場所で変更しないでください。再読み込み後にどの値が採用されたか分かりにくくなります。変更箇所を一つに決め、実行設定で結果を確認しましょう。画面上の入力内容は設定意図を示すものであり、カーネルが最終的に読み込む値とは限りません。

マップとリストの統合方法を分けて確認

マップは項目ごとに再帰的に統合する場合も、全体を置き換える場合もあります。たとえば上書き設定に dns.enable だけを記述したとき、方式によっては既存の上流DNSが維持されますが、DNSセクション全体が置き換わることもあります。リストはさらに注意が必要です。ルール、ノード、プロキシグループは、追加、先頭への挿入、名前による統合、全体置換など、さまざまな方法で処理されます。「YAMLを統合すれば既存のリストは必ず残る」とは限りません。使用中のクライアントの仕様と生成結果を確認してください。

# 元の設定にある一部
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

# 上書きの意図：この項目だけ変更
# クライアントの独立した上書き欄に記入し、元ファイルには追加しない
# dns:
#   enhanced-mode: redir-host

上の例では、同じマップ内に重複キーができないよう、上書きの意図をコメントとして示しています。実際の操作では、クライアントの独立した上書き欄に該当項目を記入し、nameserver が維持されているか確認してください。消えている場合、現在の方式では想定どおりに再帰統合されていないため、DNSセクション全体を明示的に残す必要があります。テスト中に上流DNSまで同時に変更すると、統合動作との因果関係を確認できなくなります。

ルールの先頭挿入・重複排除・名前の競合

ローカルの例外ルールは、広範囲のルールや MATCH より前にマッチするよう、通常はサブスクリプションのルールより前に置きます。ツールが末尾への追加しかできない場合、最後に例外を追加しても機能しないことがあります。生成後の順序を確認し、最終ルールが末尾にあることを確かめてから実際のマッチをテストしてください。「重複排除」のためにルールを安易に並べ替えないでください。ルーティングリストは順番自体に意味があるため、アルファベット順にすると動作が変わります。

プロキシグループを追加する場合は、サブスクリプション側と名前が重複しにくいものにします。更新後に同名のグループが現れると、名前による統合でメンバー構成が変わったり、全体置換で既存の選択肢が消えたりする場合があります。ノード名によるフィルターを使う場合は、リモート側で名前が変更されることも考慮してください。重要な通信には、安定したローカルのプロキシグループを指定し、そのグループからサブスクリプションのグループを選ぶ方法が、各ルールをリモートのノード名に直接依存させるより管理しやすくなります。

スクリプトによる上書きは柔軟ですが、設定の構造を壊すリスクも高くなります。変更前に、スクリプトが取得する値がオブジェクトかテキストか、返却値に設定全体が必要か、エラー時にクライアントが旧設定を維持するか読み込みを停止するかを確認してください。出所が分からず、外部リソースを読み込むスクリプトを安易にコピーしないでください。設定にはサブスクリプションURLや認証情報が含まれる場合があります。拡張スクリプトは単なるコメントではなく、それらにアクセスできるプログラムとして扱ってください。

更新を一度実行し、変更が保持されるか確認

上書き設定を作成したら、まず再読み込みして動作を確認し、その後サブスクリプションを手動で一度更新してください。更新前後の実行設定を比較し、カスタムルール、グループ名、上流DNS、ポートが想定どおりか確認します。更新に成功しても上書きに成功したとは限りません。古い設定で動作を続けていても、新しい設定が読み込まれたとは限りません。ログに表示される生成と再読み込みの結果を確認し、更新失敗で残った古いプロセスではなく、現在の設定ファイルを対象にテストしてください。

次の3点を保存しておくことをおすすめします。利用可能な元設定、独立した上書き内容、変更理由の記録です。元に戻すときは、まず元設定に戻してから上書きを個別に有効にすると、サブスクリプションの変更とローカルの編集を分けてトラブル対処できます。

記録は短くても構いませんが、変更した項目、期待する結果、確認対象を明記してください。たとえば「DNSを最適化」より、「LAN内の端末で実アドレスの名前解決結果を維持する」のほうが役立ちます。後で問題が再発したとき、変更がまだ必要か判断しやすくなります。目的が分からない古い上書きは、パッチを重ね続けるのではなく、一つずつ無効にして必要性を確認してください。

クライアントを移行する際、生成後の実行ファイルだけをコピーしないでください。旧クライアントが追加した管理インターフェース、ファイルパス、パネル設定は、新しい環境では使えない場合があります。まずクライアントのダウンロードページで対応プラットフォームを選び、一般ユーザーにはClash Plusがおすすめです。元のサブスクリプションを再登録し、本当に必要なローカルの上書きだけを移行してから、このページの手順で一つずつ確認してください。

動作確認と復旧 / 08

設定の検査・接続確認・復元

構文を確認してから、通信の取り込み範囲を確認

ファイルを保存したら、まずクライアントの検査機能または再読み込み機能を使い、構文エラー、参照先の不整合、ファイルパスの問題がないか確認してください。mihomoを単独で起動する場合は、正しい作業ディレクトリで以下のテストコマンドを実行できます。実行ファイル名とパスは端末の環境に合わせてください。コマンドの検査に成功しても、すべてのリモートノードへの接続が保証されるわけではありません。また、システムプロキシやTUNによる通信の取り込み確認にもなりません。

mihomo -t -d . -f ./config.yaml

行番号付きのエラーが出たら、その行から前に戻って、同じ階層のインデントや直前の行の引用符、コロンを確認してください。パーサーが示す位置はエラーを検出した場所にすぎず、原因はもっと前の閉じていない文字列にある場合があります。ポリシーが見つからないというエラーなら、ノード、グループ、ルールの各段階で名前を照合します。リソースファイルが見つからない場合は、作業ディレクトリ、相対パス、アクセス権を確認してください。赤いエラー表示を見て、設定全体をすぐに置き換えないでください。

最小限の直結設定でローカルの問題を切り分ける

以下は、カーネルの待ち受けと基本的なルール経路を確認するための、独立した最小限の直結テスト設定です。リモートプロキシは含まず、対象の通信を自動的にプロキシ経由にはしません。元のサブスクリプション設定を上書きしないよう、別ファイルに保存して個別に読み込んでください。元のクライアントが同じポートを使っている場合は、停止するか、テスト用ポートを変更してテストコマンドも合わせてください。

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

rules:
  - MATCH,DIRECT

最小構成でも起動しない場合は、まずポートの競合、アクセス権、実行ファイルを確認してください。起動したら、現在のネットワークから通常アクセスできるアドレスに、明示的なプロキシリクエストを送ります。OSによって curl コマンドの割り当てが異なることがあるため、Windowsでは curl.exe を明示して実行できます。以下のコマンドはシステムプロキシを変更せず、指定したローカルHTTPプロキシの入口だけをテストします。

curl --proxy http://127.0.0.1:7890 --head https://example.com

HTTPレスポンスを受け取れた場合、そのリクエストが対応する経路を通ったことは確認できますが、レスポンスの状態は接続先に応じて判断してください。ローカルポートへの接続が拒否されたら、待ち受けとポートを確認します。プロキシへの接続後にタイムアウトする場合は、DNS、ルーティング、出口を確認してください。証明書検証エラーが発生した場合は、証明書とシステム時刻を調べます。すべての失敗を「ノードが使えない」と決めつけたり、原因を隠すために証明書検証を無効にしたりしないでください。

実際の設定へ段階的に戻す

最小テストに成功したら元の設定に戻し、まず動作確認済みのノード一つと手動グループ一つを確認してから、DNS設定、ルールセット、上書きを追加します。階層を一つ追加するたびに同じ接続先をテストし、ログの違いを記録してください。こうすれば、どの段階から問題が発生したかを特定できます。明示的なプロキシ接続ではアクセスできるのに通常のブラウザーでは失敗する場合、アプリのプロキシ設定や通信の取り込み範囲が原因と考えられます。すぐにノード設定を書き直す必要はありません。

TUNでは仮想ネットワークアダプター、ルーティング、アクセス権、DNSの取り込みも関係します。有効にしたら、ドメイン名への接続とIPアドレスへの接続を別々に試し、LAN内の機器にも引き続きアクセスできるか確認してください。別のVPN、仮想マシン、セキュリティソフトがルートを変更する場合もあるため、複数のネットワークツールを同時に切り替えないでください。デスクトップのシステムプロキシとTUNは利用場面が異なります。まず経路を一つ選んで検証し、必要に応じて組み合わせてください。

ルールを検証するときは、新しく作成した接続に適用されたルールと最終的な出口を確認してください。全体の有効・無効表示だけでは判断できません。ブラウザーのキャッシュ、接続の再利用、バックグラウンド通信により、ページを一度更新しただけでも複数の結果が混在する場合があります。必要であれば対象アプリを終了してから再試行してください。スクリーンショットを共有する際は、アカウント情報、サブスクリプションURL、ノードの認証情報を隠し、トラブル対処に必要な項目、エラーメッセージ、関連する設定部分だけを残しましょう。

通信できない場合は、先に復元してから原因を調べる

復元するときは、新しく有効にした通信の取り込み機能を停止し、次にシステムプロキシを元に戻し、最後に保存済みの利用可能な設定を読み込みます。クライアントを終了しても接続できない場合は、停止したポートを指すプロキシ設定がOSに残っていないか確認してください。TUNやほかのツールが追加したルートも、それぞれの通常の終了手順で元に戻す必要があります。問題を上書きしようとして複数のクライアントを続けてインストールすると、ポートやシステム設定の競合が増えるおそれがあります。

ネットワークが復旧したら、直近の変更から一つずつやり直してください。サブスクリプションの更新、カーネルの切り替え、ルールの変更、OSのネットワーク設定は、できるだけ分けて行います。「接続済みなのにWebページが開かない」状態が続く場合は、ネットに接続できないときの8項目チェックリストで、サブスクリプション、出口、システムのプロキシ設定、DNSを確認してください。基本操作をやり直す場合は、サブスクリプションの追加・接続ガイドに戻ってください。

設定変更の完了基準は、設定ファイルを読み込めること、対象の通信が想定どおりにマッチすること、サブスクリプション更新後も変更が残ること、そして復元方法が分かっていることです。この4点を確認してから、次の変更に進みましょう。