Clash設定完全ガイド

1. YAMLの構造と設定間の依存関係

設定ファイルはまずYAML文書であり、そのうえでClashが解釈するネットワーク設定です。パーサーが階層、リスト、データ型を正しく読み取ってから、カーネルが各項目を検証します。エディターで開けるからといって、構造が正しいとは限りません。コメントに日本語を書くのは通常問題ありませんが、キーと値を区切るコロン、引用符、リストのハイフンには半角文字を使ってください。ファイルはUTF-8で保存し、エディターで空白文字を表示すると、見た目は揃っていてもタブが混入している、といった問題を避けやすくなります。

ルート項目、マッピング、リスト

同じ階層のキーは同じ列に揃えます。dnsはマッピングで、その下に子項目をインデントして記述します。proxies、proxy-groups、rulesは通常リストで、各項目をハイフンから始めます。次の設定は、ローカルで構造を検証するための出発点として使えます。ループバックアドレスのみで待ち受け、グループには直接接続だけを設定し、すべての通信を最終的に直接接続します。参照関係を説明する例であり、接続可能なリモートプロキシは含まれていません。

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

dns:
  enable: false

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

ここでのProxyは予約語ではなく、プロキシグループの名前です。最後のルールがこの名前を参照するため、大文字・小文字、空白、記号も含め、名前を完全に一致させる必要があります。DIRECTは直接接続を表す組み込みポリシーです。設定を読むときは、ルールがどのグループを参照し、そのグループにどのノードが登録され、ノード定義が実際に存在するかを逆にたどると確認しやすくなります。どこかが欠けていると、読み込みエラーや想定と異なる接続経路につながることがあります。

インデントだけでなくデータ型も確認

読みやすさのために半角スペース2つで揃える方法が一般的ですが、YAMLで重要なのは同じ階層のインデントが一致していることであり、すべての位置を2つにすることではありません。ポートは整数、スイッチはtrueまたはfalse、名前やパスワードは文字列として記述します。コロン、シャープ記号、特殊文字を含むパスワードは引用符で囲みます。ダブルクォート内のバックスラッシュはエスケープ文字として扱われます。一般的な文字をそのまま保持するにはシングルクォートが便利ですが、シングルクォート自体を含める場合は重ねて記述します。

コメントはYAMLの構文に沿ったシャープ記号の位置から始め、パスワードの一部を誤ってコメントにしないようにしてください。同じマッピング内でdnsやrulesを重複定義しないでください。重複キーを受け付けるパーサーでも、後の値だけが残る場合があります。空リスト[]と空のマッピング{}は用途が異なります。前者は項目がない状態、後者はキーと値がない状態です。必要な構造は各項目の定義を確認してください。

元の設定と実行設定を区別する

GUIクライアントでは、サブスクリプション、全体設定、上書き用の設定を組み合わせて実行設定を生成することがよくあります。そのため、サブスクリプション内のmixed-portが現在の待ち受けポートとは限らず、ダウンロード済みのキャッシュを編集しても変更が保存されない場合があります。編集前に、サブスクリプションの元データ、クライアントに保存されたカスタム設定、カーネルが現在読み込んでいるファイルの3つを確認してください。保存先はクライアントによって異なるため、他のクライアントのディレクトリから推測せず、設定詳細、実行情報、ログなどで確認しましょう。

メンテナンスでは、1回の変更を1つのテーマに絞るのがおすすめです。まず待ち受け項目を調整し、次にDNS、最後にルールを変更します。種類ごとに検証すれば、エラーの原因を限られた差分から特定できます。各設定項目を読む順序をさらに知りたい場合は、config.yamlを項目ごとに解説をご覧ください。このページの以降の章では、各項目の範囲を個別に説明しており、すべての機能を決まった順序で同時に有効化する必要はありません。

2. ポート、モード、アクセス範囲

共通項目では、接続を受け付ける場所、接続の処理方法、接続を許可するデバイスを設定します。トラブル時は、「アプリからのリクエストがカーネルに届いているか」と「カーネルがどの出口を選ぶか」を分けて考えましょう。ルールモードを有効にしても、カーネルに届いたリクエストにしか影響しません。また、すべてのアプリが自動的にプロキシを使うようになるわけではありません。システムプロキシ、アプリ内プロキシ、TUNはそれぞれ異なる接続方法であり、modeだけで相互に置き換えることはできません。

ポート項目の役割

一般的なデスクトップ利用なら、mixed-portを1つ設定するだけで十分です。「設定を網羅する」ためにすべての待ち受けを有効にする必要はありません。同一アドレス上の同じポートは複数の入口で共有できません。別のプロセスがそのポートを使っていると、カーネルが待ち受けを開始できない場合があります。ポートを変更したら、システムプロキシ、ブラウザー拡張、ターミナルの環境変数、アプリ内設定も更新してください。古いアドレスに接続し続けると、ノードが使えないように見えることがあります。

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"

3種類のモードで変わるのは出口の選択

ruleはルール一覧を上から順に適用して接続先を決定し、globalは全体ポリシーで接続済みの通信を処理し、directは接続済みの通信を直接接続します。グローバルモードにしてもシステム全体の通信が自動で取り込まれるわけではなく、ダイレクトモードでもアプリがローカルカーネルを迂回するとは限りません。モードをクライアント側で保存する場合もあるため、切り替え後に最終設定や管理画面で有効な値を確認してください。具体的な違いはルール・グローバル・ダイレクトモードの違いをご覧ください。

log-levelの主な値は、debug、info、warning、error、silentです。通常は情報レベルにしておき、問題を再現するときだけ一時的に詳細度を上げ、記録後に元へ戻すとよいでしょう。詳細ログにはアクセス先のドメインや接続情報が含まれることがあります。スクリーンショットやテキストを共有する前に、サブスクリプションURL、認証情報、公開したくない接続先を削除してください。

LANからのアクセスは個別に設定する

スマートフォンや別のPCからこのPCのプロキシを使う場合、allow-lanをtrueにするだけでは不十分なことがあります。待ち受けアドレスがLANインターフェースを含むこと、システムのファイアウォールが受信接続を許可していること、接続する側の端末でプロキシPCのLANアドレスを指定していることを確認してください。モバイル端末で自身の127.0.0.1を指定しても、その端末自身に接続するだけでPCにはつながりません。公共のネットワークや共有ネットワークでは、待ち受けの公開範囲を慎重に設定し、必要に応じて認証を追加して接続元を制限しましょう。

管理インターフェースとプロキシの入口は別々に扱ってください。コントローラーから状態の取得や一部の実行設定の変更ができますが、インターネットに直接公開すべきではありません。リモート管理が必要な場合は、認証、アクセス制御、保護された通信経路を組み合わせて設計してください。例ではローカルホストにバインドし、ローカルツールからのみ利用します。コントローラーポートをブラウザーのプロキシ設定に入力しないでください。また、管理画面が開くことだけでプロキシの待ち受けやリモート接続が正常だと判断しないでください。

トップレベルのipv6とDNS配下の同名項目も区別が必要です。前者はカーネルでのIPv6の使用に関わり、後者は内蔵DNSがAAAAレコードにどう応答するかを制御します。別々の設定であり、同じスイッチではありません。ネットワークでIPv6が必要なら、一般的な最適化として無効にしないでください。問題が名前解決、接続、ルーティングのどの段階で起きるかを記録してから変更しましょう。ポート競合の詳しい確認コマンドは、7890番ポートの競合確認とmixed-portの変更方法をご覧ください。

3. DNS、Fake-IP、名前解決の経路

DNS設定では、ドメイン名からアドレスを取得する方法と、カーネルがドメイン名と接続の関連付けを保つ方法を設定します。プロキシルールとは別の機能であり、アプリが必ず名前解決リクエストをカーネルに送るとも限りません。内蔵DNSを有効にしても、システムやアプリが従来のリゾルバーを使うことがあります。システムDNS、TUNによるDNSの横取り、アプリのプロキシプロトコルなどを通じてリクエストがDNS経路に入る場合があります。確認前に、「アプリ、システムの名前解決、カーネル、上流DNS」の実際の関係を整理してください。

基本項目とブートストラップDNS

enableは内蔵DNSを有効にし、listenは待ち受けアドレス、nameserverは通常の上流DNSを指定します。暗号化DNSのアドレスにホスト名が含まれる場合、その上流DNS自身のホスト名を先に解決する必要があります。default-nameserverはこのブートストラップに使う項目で、現在のネットワークから到達でき、カーネルの要件を満たすアドレスを指定してください。次の例はテスト用に標準以外のポートでローカル待ち受けしますが、OSの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"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

例に記載した上流DNSは設定の書き方を示すものです。現在のネットワークに適しているかは実際に確認してください。暗号化DNSは該当する名前解決経路の通信を保護しますが、その後の通信が必ずプロキシ経由になるわけではありません。標準のDNSクエリは通常53番ポートを使いますが、例では1053番ポートを使用しています。アドレスだけを指定する一般的なシステム設定に、ポート付きの文字列をそのまま入力することはできません。クライアントのDNS取り込み機能や、対応するフォワーダーを利用してください。

Fake-IPとRedir-Hostの違い

fake-ipは対象ドメインに合成アドレスを割り当て、後続の接続をカーネルが元のドメインに対応付けます。これにより、実際のアドレスを事前に取得する必要がある経路を減らし、ドメインルールの判定条件も保持できます。redir-hostは実際の名前解決結果をもとに接続を処理します。実アドレスが必要な場面に適していますが、ルール判定の結果は接続方法、キャッシュ、ドメインとの関連情報にも左右されます。どちらか一方が常に速いとは言い切れません。

fake-ip-filterでは、合成アドレスを使わないドメインを指定します。LAN内の名前や実アドレスが必要なアプリなどに利用します。例外は、実際に互換性の問題が起きたドメインに絞り、よく使うサイトをまとめてすべて除外しないようにしましょう。DNSの合成アドレスを除外しても、直接接続ルールが追加されるわけではありません。実アドレスを取得したドメインでも、ルールによってプロキシグループへ送られることがあります。DNSの例外と出口ポリシーは別々に確認してください。

拡張モードを切り替えた後も、システム、ブラウザー、アプリに古いキャッシュが残り、既存の接続が以前の経路を再利用する場合があります。検証時は、テスト対象アプリの関連接続を終了し、必要であればDNSキャッシュを更新してから新しいリクエストを送ってください。合成アドレスが表示されても、ただちに名前解決の障害とは判断できません。ただしクライアント終了後もシステムに合成アドレスが残っていると、一時的に接続できなくなることがあります。その場合は通常の名前解決経路に戻し、キャッシュを更新してください。

ドメイン別の名前解決とプロキシ接続先の名前解決

より詳細な設定では、nameserver-policyで特定のドメインに別の上流DNSを指定したり、proxy-server-nameserverでプロキシサーバーのドメインを個別に解決したりできます。後者は起動時の循環依存を避けるのに役立ちます。プロキシ接続先の名前解決が終わっていないのに、そのプロキシ経由でリゾルバーへアクセスしようとする状態です。これらの項目が必要かどうかは、ネットワークとカーネルの対応状況によります。まず基本の名前解決を動作させてから設定を追加すると、DNS設定一式を一度にコピーするより問題を特定しやすくなります。

respect-rulesを有効にすると、DNS上流への通信も該当ルールに従ってルーティングされます。設定時は、プロキシ接続先の個別の名前解決と起動順序も考慮してください。リモートDNS、プロキシグループ、プロキシのホスト名が互いを参照し、起動に自分自身の完了が必要となる循環を作らないようにしましょう。ルールセットでDNSポリシーを選ぶ場合は、ルールセットが正常に読み込まれていることも確認してください。名前解決先の選択自体の失敗は、通信ルールの振り分けより前に発生することがあります。

4. プロキシノードの項目とプロトコルの違い

proxiesにはリモートプロキシの接続先を記述します。各項目には、使用するプロトコルに必要なフィールドを指定します。ノード名はローカルで参照するための識別名、サーバーアドレスは接続先、ポートはリモートサービスの待ち受けポートです。これらはローカルのmixed-portとは別の項目です。手動で設定する前に、サービス提供元から必要な情報をすべて入手してください。サーバーアドレスとパスワードだけでは、暗号化方式、トランスポート層、証明書検証に必要な情報までわかるとは限りません。

名前、タイプ、アドレス、認証情報

nameは重複を避けて識別しやすい名前にします。プロキシグループはこの名前を使ってノードを参照します。typeによって後続の項目の意味が決まるため、あるプロトコルのパスワードを別のプロトコルの例にそのまま設定してはいけません。serverにはドメイン名またはアドレス、portには有効なポート番号を整数で指定します。次の例ではShadowsocksのノード構造を示します。アドレスとパスワードは説明用の値なので、実際に使う際はサーバー提供元の情報に置き換えてください。

proxies:
  - name: "サンプル SS"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

cipherはサーバー側の設定と一致させてください。新しそうな名前だからといって、独自に変更してはいけません。パスワードに空白、シャープ記号、コロンが含まれる場合は適切に引用し、解析後に文字列が変わらないようにします。udp: trueは該当ノードでUDPを利用できるようにする設定です。すべてのアプリのUDP通信が取り込まれるとは限らず、非対応のリモートサービスにUDP機能を追加するものでもありません。実際の動作は接続方法、プロトコル、サーバー設定にも左右されます。

TLSの識別情報とトランスポート項目

TLSを使うノードでは、実際の接続先アドレスと、証明書の検証に使うサーバー名を区別します。プロトコルによってsniを使う場合もあれば、servernameを使う場合もあり、すべてのプロトコルで同じフィールド名が使えるわけではありません。次のTrojanの例では、serverが接続先、sniがTLSハンドシェイクで想定するホスト名です。両者が同じかどうかはサーバーの構成に基づいて判断し、ブラウザーでアクセスするアドレスから推測しないでください。

proxies:
  - name: "サンプル Trojan"
    type: trojan
    server: gateway.example.com
    port: 443
    password: "your-password"
    sni: gateway.example.com
    skip-cert-verify: false
    udp: true

skip-cert-verify: falseは証明書の検証を有効にする設定です。証明書エラーが出たら、設定の誤りと判断する前に、システム時刻、想定ホスト名、サーバー証明書のチェーン、接続先のリダイレクトを確認してください。検証を無効にすると、接続先の識別ミスを隠す可能性があるため、TLSの問題に対する一般的な解決策として使わないでください。WebSocketやgRPCなどを使う場合は、プロトコルに応じてパス、サービス名、リクエストヘッダーも確認しましょう。ポートに接続できても、上位層のパラメーターが一致しているとは限りません。

サブスクリプションのノードと外部ノードプロバイダー

サブスクリプションによってはproxiesを直接生成する場合と、proxy-providersを通じてノード一覧を提供する場合があります。後者は名前の付いたリソースで、通常はプロキシグループのuseから参照します。proxiesリストにノード名を1つ書くのとは異なります。プロバイダーにはリモートURL、キャッシュパス、更新間隔、ヘルスチェックなど、それぞれ異なる設定があります。ダウンロードに成功してもノードに接続できるとは限らず、取得できたことがわかるだけです。

外部ノードを使う場合は、まずリソースがカーネルで受け付けられる形式か確認し、次にプロキシグループが正しいプロバイダー名を参照しているか確認してください。サービスによってはクライアントにインポートするための完全な設定を返すことがあり、ノードだけを含むプロバイダーファイルとして直接使えません。クライアントのサブスクリプション変換機能を使う場合は、変換後もプロトコルや設定項目が保持されているか確認しましょう。特にトランスポート設定、証明書名、専用オプションに注意してください。ノード数が同じ程度だからといって、内容も一致しているとは限りません。

ノード名を手動で変更すると、その名前を参照しているすべてのプロキシグループに影響します。ノードを削除する前に、設定内で名前を検索してください。一括置換では、同じ文字列がルールや説明文にも含まれていないか注意しましょう。サブスクリプション更新でノード名が変わることもあるため、特定のノードを参照するカスタムグループは定期的に確認してください。設定を公開したり、サポートを求めたりする際は、サーバー、パスワード、サブスクリプションURL、アカウントを特定できる情報を必ず伏せてください。多くの初期調査では、項目の構造とエラーの種類がわかれば十分です。

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

プロキシグループを使うと、出口の選択とルール判定を分けられます。ルールは安定した名前のグループを参照し、ノードの変更や選択方法の調整はグループ内で行えます。proxy-groupsの各項目には、名前、タイプ、候補の参照元を指定します。候補にはノード、組み込みポリシー、別のプロキシグループを指定できます。グループ名は画面上のラベルだけでなく、参照関係をつなぐ識別子です。名前を変えるときはルールや上位グループも合わせて変更しないと、参照が切れてしまいます。

手動選択と自動テスト

selectはクライアントの画面で候補を選ぶ方式で、出口を明示的に制御したい場合に適しています。url-testはテスト結果をもとに候補を選び、fallbackは候補の順番に沿って利用可能な出口を維持することを重視します。load-balanceは設定した方式に従って接続を振り分けます。これらは同じ機能の別名ではありません。手動で固定する、自動で比較する、優先順位に沿って切り替える、接続を分散する、のどれを求めるか決めてから設定してください。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - "サンプル SS"
      - "サンプル Trojan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

この設定例は前の章で定義した2つのノードを参照しているため、実際のノード定義と合わせて使ってください。ここでのintervalはテストの間隔を秒単位で指定し、toleranceは候補間の小さな差で切り替わるのを抑えます。画面に表示されるリアルタイムの測定結果とは異なります。テスト先には、現在のネットワークからアクセスでき、応答が安定するURLを選んでください。テストに失敗しても、そのURLが制限されているだけで、すべての通信が使えないとは限りません。

テスト結果だけでは実際の通信品質はわからない

ヘルスチェックで測定するのは通常、特定のURLへのアクセス結果です。ダウンロード速度、動画の再生品質、すべての接続先への到達性を直接表すものではありません。テストに成功した出口から特定サービスに接続できない場合は、接続先の制限、プロトコル、地域、リモート側のネットワーク経路などが関係している可能性があります。テスト間隔を何度も変更したり、1回の成功をすべてのネットワーク階層が正常な証拠と見なしたりせず、実際の通信で新しい接続を試し、接続情報を確認してください。

候補にDIRECTが含まれている場合、ユーザーの操作やグループの動作によって直接接続が選ばれる可能性があります。必ずプロキシ経由にしたい通信のグループには、手軽だからといって直接接続を候補に加えないでください。反対に、ローカルサービス用のグループでは、リモートプロキシを許可するか明確にしましょう。グループ名には用途や選択方式を反映させてください。「自動」「予備」「直接接続」が似た名前に混在すると、画面で誤った項目を選んでも気付きにくくなります。

プロバイダー参照、グループのネスト、循環参照

useでプロバイダーを参照する場合は、サブスクリプションの表示名ではなく、proxy-providersで定義したキーを指定します。フィルター式でノードを絞り込む場合は、結果に有効な候補が1つ以上含まれることも確認してください。ノード名のルールが変わると、フィルター結果が空になることがあります。編集後はグループ内に実際に表示された候補を確認してからルールを検証しましょう。ルールが目的のグループに適用されていても、グループに使用可能なノードがないケースを避けられます。

グループから別のグループを参照して、たとえば「通信別グループから手動グループまたは自動グループを選ぶ」という階層を作れます。ただし、参照先は最終的にノードまたは組み込みポリシーに到達しなければなりません。グループAがBを参照し、BがAを参照するのは循環参照です。名前を変えても解決しません。複雑な設定では、「通信ルール、用途別グループ、出口グループ、ノード」のように短い経路図を作ると便利です。階層が深いほど、各階層で現在選択されている候補を確認してください。最上位の選択表示が実際の出口とは限りません。

クライアントは手動で選んだ候補を保存できることが一般的ですが、その選択状態はYAML上の並び順ではなく、実行データに保存されている場合があります。設定の再読み込み後も選択が維持されるかは、クライアントやカーネルの保存方法によります。ノードをリストの先頭に移しても、保存済みの選択が変わるとは限りません。調査時は現在の選択値を確認し、必要なら手動で選び直して新しい接続で検証してください。ファイル上の並び順から実行状態を推測しないでください。

6. ルール構文、優先順位、フォールバック

rulesは順序のある判定リストであり、順不同のタグ一覧ではありません。カーネルは上から順に、現在の接続で利用できる情報を使って判定し、最初に一致したルールのポリシーを適用します。後続の「より具体的な」ルールを探し続けることはありません。そのため、優先順位はまず記述位置で決まります。通信の振り分けを調べる際は、ルールの内容だけでなく、その前に範囲の広いドメイン、アドレス、フォールバックのルールがないか確認してください。サブスクリプションで生成されたルールとカスタムルールの統合位置にも注意しましょう。

よく使われるルールタイプとマッチ範囲

ドメインルールにはホスト名を記述し、https://、パス、クエリパラメーターは含めません。特定のWebサイトをプロキシ経由にしたい場合でも、ブラウザーのアドレス欄に表示されたURL全体をDOMAINに貼り付けないでください。1つのページが複数のドメインにリクエストを送る場合もあります。メインページのホスト名だけでは、静的ファイル、認証、APIの通信をカバーできません。接続ログから対象のホスト名を確認し、完全一致かサフィックス一致かを選びましょう。

rules:
  - DOMAIN,router.home.arpa,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-KEYWORD,github,Proxy
  - DOMAIN-SUFFIX,googleapis.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

アドレスルールとno-resolve

no-resolveは該当するアドレス系ルールで使う設定です。そのルールの判定のために追加の名前解決を行わないという意味であり、DNS全体を無効にするものではありません。接続先がすでにアドレスなら、カーネルはそのアドレスを照合できます。ドメイン名しかなく、判定に使えるアドレスがない場合は、一致しないことがあります。追加するかどうかは、そのルールの判定で名前解決を発生させたいかに応じて決めてください。すべてのルールに付けるべき性能向上設定ではありません。

GEOIPの判定はアドレスの割り当て情報を収録したデータベースに依存し、企業の所在地やユーザーの居住地域を判定するものではありません。ドメインが海外のサービス事業者のアドレスを使っていたり、ローカルサービスがパブリックネットワークを利用したりすると、想定と実際の判定が異なることがあります。データベースの更新で結果が変わる場合もあるため、必ず特定の経路にしたい通信は、広範囲の地域ルールより前に明示的なドメイン例外を追加してください。データファイルが利用可能かどうかは、カーネルログで確認しましょう。

ルールセット、プロセス照合、適用範囲

RULE-SETを使うと、複数のルールをrule-providersが管理するリソースにまとめ、更新や再利用ができます。プロバイダーの動作タイプとファイルの内容は一致させる必要があります。ドメインの一覧、アドレスの一覧、従来のルール一覧は、自由に相互置換できません。リモートのルールセットを定義しただけでは、ダウンロード済みとは限りません。初回起動時やネットワーク制限、キャッシュパスの誤りが疑われる場合は、参照ルールを確認する前に読み込みログを調べてください。

プロセスルールが使えるかどうかは、OSと接続方法がプロセス情報を提供できるかによります。ルーター機器で他の端末の通信を受けても、通常は接続元端末内のアプリ名まではわかりません。プロセス名の照合が、どのプラットフォームでも同じように使えるとは限らない点にも注意してください。利用する前に、現在のクライアントの対応範囲を確認しましょう。一般的なWebサイトの振り分けなら、明示的なドメインルールのほうが再現しやすく、異なる端末間でも設定を共有しやすい場合があります。

最後に記述するMATCH,Proxyは、残りの通信をプロキシグループに送ります。MATCH,DIRECTにすると、残りの通信は直接接続されます。どちらも異なるデフォルトポリシーを表すため、例をそのまま流用せず、実際の要件に合わせて選んでください。このルールを一覧の先頭に置くと、それ以降のルールは適用されません。変更後はテストアプリの既存接続を終了するか、新しいリクエストを送ってください。確立済みの接続は、ルールを再読み込みしても通常は出口が切り替わりません。

ルールに一致したことは、接続先ポリシーが決まったという意味であり、出口への接続成功を示すものではありません。ログでProxyへの一致後にハンドシェイクエラーが出た場合は、同じルールを何度も追加するのではなく、グループで選択されている候補やノード設定を確認してください。反対にリクエスト自体が記録されない場合は、システムプロキシやTUNなど、接続の取り込み段階に戻って確認しましょう。まだカーネルに届いていない通信に対して、ルールだけを繰り返し変更しないでください。

7. サブスクリプションの上書きと設定の統合

サブスクリプションはリモートから設定を更新し、カスタム設定はローカルの使い方を反映します。両者を直接混ぜて編集すると、次回更新時に競合しやすくなります。上書き機能を使えば、ポート、DNS、通信ルール、カスタムグループなどを安定した場所に保存し、クライアントに最終設定を生成させられます。まず現在のクライアントが、全置換、項目ごとの統合、ルールの先頭追加、スクリプト処理のどれをサポートしているか確認してください。似た名前の機能でも統合方法が異なるため、別のクライアントの操作手順をそのまま使わないでください。

スカラー、マッピング、リストはそれぞれ扱いが異なる

ポートやモードなどのスカラーは、通常、最終的に1つの値を持ちます。後から処理された設定で前の値が上書きされる場合があります。DNSはネストされたマッピングで、ツールによって再帰的に統合する場合と、全体を置き換える場合があります。ルールやプロキシグループはリストで、全置換、先頭への追加、末尾への追加などの動作があります。YAMLはデータを記述する形式であり、こうした統合方法をクライアントに指示するものではありません。次の例は追加したい項目の一例で、すべてのクライアントで同じ結果になるとは限りません。

mixed-port: 7890
mode: rule

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

rules:
  - DOMAIN,router.home.arpa,DIRECT

ツールがrulesを全置換する場合、上の例を使うと元のサブスクリプションルールがすべて失われます。既存のMATCHの後ろに追加する動作なら、新しいルールに到達できない可能性があります。クライアントが明示的に対応しているルールの先頭追加機能を使うか、制御可能なスクリプトでリスト内の位置を調整し、生成結果を確認してください。上書きエディターに「保存しました」と表示されただけで、ルールが正しい位置で有効になったと判断しないでください。

統合後も参照関係を保つ

用途別のグループを追加する場合は、参照先のノードやプロバイダーがサブスクリプション更新後も存在することを確認してください。ルールを追加する場合も、適用先のポリシー名が統合によって削除または変更されていないか確認します。サブスクリプションにProxyというグループがすでにある場合、同じ名前のカスタムグループを追加すると競合したり、上書きされたりする可能性があります。用途がわかる別の名前を使い、生成のたびに重複がないことを確認するほうが、統合機能の自動処理に頼るより安全です。

DNSの上書きでは、ネストされた項目を特に確認してください。enhanced-modeだけ変更するつもりでdns全体を置き換えると、元の上流DNS、ドメイン別ポリシー、プロキシ接続先の名前解決設定も失われる場合があります。逆に再帰統合では、不要になった古い項目が残る可能性があります。変更した行だけを検索するのではなく、統合後のDNS設定全体を確認し、新旧の項目が一貫した名前解決経路を構成しているか確かめましょう。

同じ注意点はノードプロバイダーやルールプロバイダーにも当てはまります。キャッシュパスの競合でリソース同士が上書きされたり、名前の変更で参照先がなくなったり、ファイル形式が変わって従来の動作タイプが合わなくなったりすることがあります。サブスクリプションの更新前に、動作する設定を保存しておきましょう。更新後は読み込みログとグループの内容を確認します。問題が起きたら、まず既知の正常な状態に戻してから差分を比較してください。失敗した状態に修正を重ね続けるのは避けましょう。

ローカルでの管理手順と共有時の注意

「リモートのサブスクリプション元」「ローカルのカスタム設定」「最終的な実行設定」の3つを保存しておくのがおすすめです。最初の2つから設定の出所がわかり、3つ目から実際の動作内容を確認できます。比較時は、トップレベルのキーとリストの件数を見たうえで、重要なルールの位置、グループ名、DNS経路を確認してください。リモートノードをすべてカスタム設定にコピーする必要はありません。そうすると、サブスクリプション更新によるアドレス変更やノードの追加・削除が反映されず、手動での保守が増えてしまいます。

上書きスクリプトでコードを実行できる場合は、設定を操作する権限を持つプログラムとして扱ってください。処理内容を理解できるコードだけを使い、ルールを1つ追加するために、出所不明のスクリプト全体を受け入れないようにしましょう。例を共有する際は、実際のサブスクリプションURL、認証項目、個人のパスを削除してください。スクリーンショットでも、クエリ文字列全体にアカウント情報が含まれることがあります。実アカウントを公開せずに構造上の問題を再現できるよう、項目の位置を示す説明用の値を使いましょう。

8. 設定の検証と段階別のトラブル対処

検証は構文、参照関係、待ち受け、名前解決、ルール、リモート接続の順に進めましょう。この順序なら不要な変更を減らせます。ファイルを正常に読み込めていない段階でノードの選択を変えても意味がなく、リクエストがカーネルに届いていなければルールを調整しても影響しません。開始前に、クライアント名、使用中のカーネル、接続方法、直前に変更した項目を記録してください。実際のサブスクリプション内容を公開する必要はありません。最初に発生したエラーを控えてください。その後に続く大量の接続エラーは、同じ基本問題から連鎖している可能性があります。

まず静的チェックを行い、次に起動ログを確認

mihomoを単独で実行している場合は、テスト用のオプションで設定を確認できます。以下のコマンドは、実行ファイルが現在のディレクトリにあり、設定ファイルが指定のディレクトリにある前提です。設定が参照する外部リソースもテスト対象になる場合があるため、エラーがインデントの誤りだけとは限りません。GUIクライアントでは、別のインスタンスを同時起動してポートを奪わないよう、クライアント内の検証・再読み込み機能を優先してください。どの方法でも、有効化する予定の設定ファイルそのものを検証していることを確認しましょう。

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

構文エラーでは、該当行やその近くの項目が示されることがありますが、原因が直前の行にある場合もあります。引用符の閉じ忘れ、リストのインデント変更、ルート項目の重複などを確認してください。参照エラーは名前をたどって調べます。ルールの適用先が存在するか、グループの候補が存在するか、プロバイダー名が一致しているか確認しましょう。非対応の項目が見つかった場合は、現在のカーネルがその機能を実装しているか確認してください。同じ名前のクライアントでも、OSやインストール元によってカーネルの機能が異なることがあります。

ポートとリクエストの取り込みを確認

設定を読み込んだら、待ち受けが正常に開始しているか確認します。デスクトップ環境では、画面上で1つしかクライアントを開いていなくても、バックグラウンドサービスが以前のポートを使用している場合があります。まずプロセスを特定し、古いインスタンスを停止するか、新しい設定のポートを変更するか判断してください。正体のわからないシステムプロセスを終了しないでください。次に、プロキシを明示的に指定したリクエストを送ってHTTP接続を検証します。こうすれば、システムプロキシの設定が正しいかどうかという要因を一時的に切り分けられます。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

このコマンドではローカルの混合ポートを使用し、接続経路を確認するための例示サイトにアクセスします。HTTPレスポンスが返れば、このリクエストが指定した入口を通ったことはわかりますが、すべてのアプリが接続されているとは限りません。接続が拒否された場合は、まず待ち受けとポートを確認してください。プロキシがリクエストを受け取った後にタイムアウトする場合は、ルール、グループの選択、リモート側のエラーを調べます。接続先からアクセス制限のレスポンスが返ることと、ローカルの入口に接続できないことは別の問題です。成功以外のレスポンスを一律にプロキシの故障と判断しないでください。

ログから名前解決と出口の問題を特定

名前解決エラーは、どのドメインで失敗したかを確認してください。通信先のドメイン、プロキシサーバー、DNS上流自身のドメインのいずれかで原因が異なります。プロキシ接続先を解決できない場合は、ブートストラップDNSと循環依存を確認してください。LAN内の名前だけが解決できない場合は、ローカルリゾルバー、Fake-IPフィルター、接続方法を確認します。通信先の解決とルール判定が済んでいる場合は、実際に選ばれたポリシーとノードを確認し、複数階層のグループ選択によって別の出口に送られていないか調べましょう。

TLSエラーでは時刻、ホスト名、証明書チェーンを確認します。認証エラーではパスワードとプロトコル項目を照合し、接続タイムアウトではアドレス、ポート、トランスポート設定、ネットワーク経路を調べます。証明書検証を無効化し、DNSを変更し、モードを切り替えるといった操作を同時に行わないでください。新しい条件に元の問題が隠れてしまいます。1回に変更する項目の種類を絞り、同じ接続先への新しい接続で再テストすれば、結果を比較できます。既存接続の再利用、キャッシュ、バックグラウンドでの再試行が観察に影響することもあります。

設定の切り戻し、記録、継続的なメンテナンス

問題が解決したら、どの項目を変更したか、どのエラーを解消したか、特定のネットワークに依存するかを簡潔に記録して保存してください。クライアントやサブスクリプションの更新後は、上書きされやすいこれらの項目を優先して確認します。デバッグ中に変更したログレベル、一時的に公開した待ち受けアドレス、テスト用の入口も、日常利用に必要な設定に戻してください。設定が複雑になるほど、動作が確認できている基本構成を保存しておくことが重要です。環境の変化と新機能による問題を切り分けやすくなります。

コマンドラインでの導入とGUIクライアントではサービスの管理方法が異なります。特に、システムサービスとデスクトップアプリから同じカーネルを同時に起動しないようにしてください。Linuxでの手順はmihomoのデスクトップ利用とsystemdでの導入方法をご覧ください。よくある問題からはよくある質問へ、クライアントを変更する場合はダウンロードページでプラットフォームに合ったものを選べます。検証の完了とは、設定が正しく読み込まれ、テスト通信の経路を説明でき、日常的なアプリの動作が想定どおりであることです。画面に「起動中」と表示されるだけでは不十分です。