mihomo 高度な設定ガイド

01 / 設定の基本

設定の取得元、実行ファイル、検証の手順

クライアントの設定画面を開き、まず現在有効な設定を確認してから、実行設定またはコア設定の項目を探します。購読からダウンロードしたファイル、ローカルで編集したファイル、mihomo に渡される最終ファイルは、別々のことがあります。画面上のシステムプロキシ、ポート、DNS、TUN の設定が生成処理に関わる場合もあります。問題を調べる前に、設定名、設定ディレクトリ、実際の待受ポートを記録してください。購読エディターの項目だけでは、コアがその値を使っているか判断できません。反映結果の確認は、実行ログと最終生成ファイルから始めましょう。

元に戻せる設定の基準を作る

まず、接続できている現在の設定を書き出し、ローカルオーバーライドの内容も別に保存します。バックアップには購読 URL、サーバーのパスワード、コントローラーの認証情報が含まれることがあります。端末内のアクセス制限された場所に保存し、スクリーンショットを共有する際は情報を隠してください。変更は、まずプロキシグループ、次に DNS、最後に TUN のように、毎回ひとつのモジュールに絞るのがおすすめです。問題が起きたとき、直前の変更と原因を結び付けやすくなります。コアを直接実行する場合は、起動コマンドと作業ディレクトリも記録してください。相対パスは設定ディレクトリに左右されるため、別の場所から起動するとルールファイルやパネルのリソースを見つけられないことがあります。

YAML を読むときは、まず階層とキーの重複を確認します。インデントにはスペースを使い、同じ階層では幅を統一してください。リスト項目の先頭にはハイフンを付けます。キー名に含まれるハイフンと、リストを示すハイフンは役割が異なります。特殊文字を含む文字列、特にパスワード、クエリパラメーター付き URL、コロンを含む文字列は、引用符で囲むと安全です。ファイル末尾に dns や rules のトップレベルキーを重ねて追加し、設定を上書きしようとしないでください。解析方法によってはエラーになったり、片方だけが残ったりして、編集時の想定と異なる結果になることがあります。

# 既存の動作中の設定に統合し、元の出力先とルールを残す
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

まず構文を確認し、次に実際の通信を確認

コアを単独で使う場合は、以下のコマンドでファイルをテストできます。パスは実際の環境に合わせて変更してください。テストでは、YAML の解析エラー、一部の項目の誤り、参照エラーを検出できますが、接続先サービスに到達できることや、システムの通信がそのプロセスを通ることまでは確認できません。GUI クライアントに設定チェック、再読み込み、ログの機能がある場合は、そちらを優先してください。チェックに失敗したら、ログに最初に現れる意味のあるエラーから確認します。後続のエラーは同じ階層の問題から派生していることがあり、手当たり次第に修正すると正しい箇所まで壊すおそれがあります。

mihomo -t -f ./config.yaml

構文チェックに通ったら設定を再読み込みし、テスト対象アプリの既存の接続を閉じてから新しいリクエストを送ります。接続画面で対象ドメイン、適用されたルール、プロキシグループの経路、出力先の名前を確認してください。ページを再読み込みするだけでは、ブラウザーが既存の接続を再利用し、新しいルールが反映されていないように見えることがあります。ローカルの接続口とリモートの出口を分けて確認するには、ローカルのプロキシポートを明示してテストできます。以下のコマンドで検証できるのは HTTP プロキシの入口であり、TUN のルーティング検証にはなりません。ポートは実行設定に合わせ、対象サイトは調査中の公開サイトに変更してもかまいません。

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

クライアントによって設定画面の場所も異なります。新しく導入する場合は、クライアントのダウンロードページでおすすめの Clash Plus を選び、システムのチップに合ったパッケージを選択してください。すでに Clash Verge Rev や FlClash を使っている場合は、そのまま利用し、実際に動作しているコアと対応項目を確認しましょう。設定ファイルの構造を詳しく知りたい場合は、config.yaml の構造解説をご覧ください。ポートの競合、アクセス権限の拒否、起動失敗が起きた場合は、設定ガイドの続きに進む前にヘルプセンターで基本的な問題を解決し、環境の問題をルールの問題と取り違えないようにしてください。

02 / 出力先の選択

プロキシグループの種類と自動選択の使い方

プロキシ画面を開き、まずルールが最終的にどのプロキシグループを参照しているか確認してから、そのグループのメンバーを表示します。プロキシグループは出力先を選ぶ層であり、通信を識別する層ではありません。ルールが接続先のグループを決め、そのグループが出力先を選びます。グループ内の選択肢を変更しても、通常はルール一式を書き換える必要はありません。用途と具体的な購読内容を分けて管理するのに便利です。たとえば、業務用ルールは「業務用出口」を参照し、そのグループに手動選択と自動選択の両方を用意できます。グループ名は自由に付けられますが、参照箇所ではスペース、大文字・小文字、句読点も含めて完全に一致させてください。

手動選択、自動選択、フォールバックを使い分ける

select は出力先を明示的に選ぶ場合や、複数の子グループを切り替える上位メニューに適しています。url-test は応答テストの結果から、遅延の小さい利用可能なメンバーを選びます。fallback はメンバーの並び順を重視し、通常は先頭にある利用可能なメンバーを優先します。どの方式も、実際の業務での通信品質がテスト結果と一致することを保証するものではありません。テスト先への接続条件を示すだけで、動画、ダウンロード、社内システムでは異なる経路を使うことがあります。問題を調べるときは、まず動作確認済みのメンバーを固定して業務通信を確認し、自動切り替えでテスト条件が変わらないようにしましょう。

load-balance は新しい接続を指定した方式で振り分ける機能であり、複数の出口の帯域をひとつの接続にまとめるものではありません。ログインセッション、決済画面、出口の一貫性が求められるサービスでは、出口が頻繁に変わると再認証を求められることがあります。そのため、通信の特性が明確な用途に向いています。安定した接続が必要な用途には、専用の select グループを作り、出口を固定できます。グループ構成が複雑になるほど接続経路の把握に手間がかかります。まずは手動選択グループと自動選択グループをひとつずつ用意し、実際の使い方に応じて段階的に分けてください。

ローカルのプロキシ一覧から二段階の選択を作る

以下の例では、設定ディレクトリに providers/nodes.yaml があり、正しい形式の proxies リストが含まれていることを前提とします。内容は既存の購読またはローカル設定から用意してください。この例でリモートアカウントを作成したり、購読を置き換えたりすることはできません。まずプロキシ一覧を読み込めることを確認し、既存の設定にふたつのグループを追加します。use はプロキシ一覧を参照し、proxies は個別の出力先または別のグループを参照します。どちらも購読 URL を記入する項目ではありません。テスト先には安定してアクセスでき、現在のネットワークにも適したアドレスを指定してください。

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

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 業務用出口
    type: select
    proxies:
      - 自動選択
      - DIRECT
    use:
      - local-nodes

interval はテスト間隔（秒）、tolerance は切り替えの許容差（ミリ秒）です。結果が近い場合に頻繁に切り替わるのを抑えます。間隔を短くしすぎると、テストリクエストや端末の動作頻度が増え、モバイル回線では余分な通信量も発生します。同じプロキシ一覧でヘルスチェックを有効にし、複数のプロキシグループでも個別にテストしている場合は、重複していないか確認してください。テストの層ごとに目的は異なります。すべてを同時に有効にするのではなく、結果を説明しやすく、観察できる構成を優先しましょう。

検証するときは、明確なテスト用ドメインをルールで「業務用出口」に割り当て、「自動選択」と特定のメンバーをそれぞれ選びます。新しい接続を作成し、プロキシグループの経路を確認してください。上位グループが自分自身を間接的に参照すると循環します。また、購読の更新後に削除済みのメンバーだけがグループに固定されていると、グループが空になったり参照に失敗したりすることがあります。一覧を絞り込むにはフィルター項目を使えますが、まずプロキシ画面で結果にメンバーが含まれることを確認してください。自動選択で解決できるのは候補となる出力先の選択です。DNS、認証、接続先サービスの制限は、それぞれ別に調べる必要があります。

03 / ルールの管理

ルールセットの購読とマッチ順序

実行設定の rules セクションを開き、カスタムルールが購読ルールの前後どちらにあるかを確認します。mihomo は通常、上から順にルールを照合し、接続先を決められるルールに一致するとその結果を採用します。そのため、具体的な業務上の例外は前方に、広い地域ルールや最後のフォールバックは後方に置きます。ルール一覧をルールセットに分けると、ルールの管理とルーティングの意図を分離できます。ルールセットにはドメインやネットワーク範囲を記述し、メイン設定で対象を直接接続、プロキシ経由、拒否のいずれにするか決めます。

ルールの内容と behavior を合わせる

rule-providers でルールの取得元を定義し、メインルール一覧から RULE-SET で呼び出します。behavior: domain はドメイン一覧、ipcidr は IP アドレス範囲、classical はタイプ付きの従来形式ルールを対象にします。ファイル形式と behavior は別の概念です。YAML、テキスト、バイナリーはファイルの保存形式を示し、behavior は各項目の解釈方法を示します。ルールの購読を追加する際は、まず形式の説明を確認してください。拡張子だけで内容を判断したり、クライアント設定一式をルールセットとして読み込んだりしてはいけません。

リモートから直接取り込むより、まずローカルファイルで最小限のテストを行うほうが問題を切り分けやすくなります。最初の例は rules/local-direct.yaml に保存します。このファイルは設定ディレクトリ内に置いてください。次の例はメイン設定に追加します。例では classical behavior を使用し、各ルールにタイプと照合内容を記述します。ルールファイルには最終的なポリシーを書きません。メイン設定の RULE-SET で、セット全体を DIRECT に割り当てます。最後のフォールバックには前の章で作成した「業務用出口」を使います。別のグループ名を使う場合は、参照先も合わせて変更してください。

# rules/local-direct.yaml
payload:
  - DOMAIN-SUFFIX,apple.com
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

# メイン設定に統合
rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,業務用出口

リモートの更新とローカルの例外を分ける

ローカルルールが一致することを確認したら、継続的に更新が必要なセットを type: http に変更し、信頼できる提供元の実際のルール URL、キャッシュパス、更新間隔を設定します。interval の単位は秒です。頻繁な更新を求めて極端に小さな値にする必要はありません。ルールセットごとに異なるキャッシュパスを指定し、上書きを防いでください。初回起動時にキャッシュがない場合は、リモートのルールを取得できる必要があります。キャッシュがある場合の動作はファイルの状態やコアの処理に左右されるため、ダウンロードログとルールセットの読み込み結果の両方を確認してください。

ルールセットのダウンロードにも通信経路が必要です。ダウンロード URL への接続にプロキシが必要で、そのプロキシの経路が未読み込みの同じルールセットに依存していると、起動時に依存関係の循環が生じることがあります。クライアントのリソースダウンロード設定で利用可能な出口を指定するか、ルール提供元のドメインへの明確で動作する経路を設定してください。ルール画面にセット名が表示されるだけで判断せず、読み込みログ、更新日時、実際にルールが適用されているかを確認しましょう。ダウンロードに成功しても、項目数の異常、behavior の不一致、内容の空欄などがあれば、ルーティング結果は想定と異なります。

no-resolve は主に IP 系ルールで使い、そのルールとの照合のためにドメイン名を積極的に IP アドレスへ解決しないことを示します。接続全体の DNS を無効にしたり、その後の接続にアドレス情報がなくなったりするわけではありません。IP アドレスへのリクエストは引き続きアドレスで照合できます。ドメインルールは挙動が分かりやすく、IP ルールはネットワーク範囲やドメイン名がない接続に適しています。範囲の広い IP ルールを業務用ドメインルールより前に置くと、接続が意図せず直結やプロキシに振り分けられることがあります。接続画面に表示されるルールタイプを確認し、実際の照合順序を判断してください。

さらに細かく設定する場合は、カスタムルールの構文と優先順位と中国国内・海外の振り分け設定をご覧ください。購読の更新後に例外が消える場合は、リモートで生成されたファイルを繰り返し編集するのではなく、オーバーライドの統合位置を調整します。設定を共有する前に、ルールの提供元が信頼できるか、機密性の高い通信が意図しない出口に送られないかも確認してください。ルールを正常に解析できることは、構造が読み取れることを示すだけで、用途に合ったポリシーであることを保証しません。

04 / ドメインの名前解決

DNS の最適化と名前解決経路の分離

DNS を変更する前に、失敗しているのがドメインの名前解決、プロキシサーバーへの接続、接続先サイトの応答のどの段階かをログで確認します。DNS はドメイン名を後続処理に使える情報へ変換しますが、ブラウザー、OS、クライアント、リモートプロキシが名前解決に関わることがあります。コマンドラインでは開けるのにブラウザーでは開けない場合、ブラウザー独自の暗号化 DNS が使われている可能性があります。プロキシサーバーのドメインを解決できなくても、接続先サイトの名前解決に問題があるとは限りません。「何を解決するか」と「リクエストをどこへ送るか」を切り分けてから、変更する項目を決めてください。

起動時の名前解決と通常の DNS クエリを分けて考える

nameserver は主な上流 DNS、default-nameserver は上流 DNS 自体のドメイン解決など起動時の名前解決、proxy-server-nameserver はプロキシサーバーのドメイン解決に使います。ドメイン名を使った暗号化 DNS を設定すると、コアは接続を確立する前にそのサーバーの IP アドレスを取得する必要があります。その名前解決が未確立のプロキシに依存していると、起動時に行き詰まることがあります。以下は役割を理解するための最小構成です。実在する公開 DNS を使っていますが、どのネットワーク環境からも同じように接続できることを示すものではありません。

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

待受アドレスをループバックインターフェースに設定すると、ローカルプロセスや TUN のリダイレクト経路から利用でき、LAN への公開も抑えられます。ポート 1053 は任意の例です。実行設定と関連するリダイレクト設定でポートを一致させてください。listen を設定しても、macOS 上のすべての DNS クエリが自動的にコアへ送られるわけではありません。システム DNS、TUN の DNS リダイレクト、アプリ独自の名前解決をそれぞれ確認する必要があります。ほかのデバイスからローカルの DNS を利用する場合は、待受アドレス、ファイアウォール、アクセス範囲、戻り経路も確認してください。すべてのインターフェースで待ち受ける設定に変えるだけでは不十分です。

DNS サーバーをやみくもに増やさず、ドメインごとに選ぶ

nameserver-policy では、特定のドメインや一致するセットに上流 DNS を指定できます。社内ドメイン、家庭内ネットワークのドメイン、特定の DNS で解決したい業務に適しています。まず対象をひとつに絞って設定し、検証してから適用範囲を広げてください。上流 DNS を一度に大量に追加すると、同時リクエストが増え、経路が不明確になり、問題の切り分けも難しくなることがあります。ルールセットを DNS の照合条件に使う場合は、現在のコアが対応する構文をサポートしていることと、ルールセットが読み込み済みであることを確認してください。ルーティングルールのポリシー名と DNS の上流設定では構文が異なるため、一方の文字列をそのまま他方に使うことはできません。

respect-rules を有効にすると、上流 DNS への接続が対応するルーティングルールに従います。この場合、プロキシサーバーのドメインを個別に解決できることが特に重要です。利用可能な出口ができる前から名前解決をプロキシに依存させると、循環する可能性があります。まず、明確に到達可能な DNS でプロキシサーバーのドメインを解決できる状態にしてから、通常のウェブサイトのクエリを設定してください。fallback とフィルター条件を併用する場合は、実際の判定方法を確認しましょう。「最初のサーバーが失敗したら次を使う」という単純な仕組みではないため、従来の優先 DNS と予備 DNS の感覚だけで判断できません。

名前解決を検証するときは、実 IP モードと Fake-IP モードを区別してください。Fake-IP でマッピング用のネットワーク範囲のアドレスが表示されるのは通常の動作であり、サイトの公開 IP と異なるからといって名前解決のエラーとは限りません。DNS を変更したら新しい接続を作成し、必要に応じて関連キャッシュを消去します。すべてのキャッシュを消すと診断の手掛かりが失われ、一時的な不安定さを招くこともあります。DNS サーバーは、現在のネットワーク、プライバシー要件、アクセス先に応じて選び、公開設定を機械的にコピーする必要はありません。ローカルネットワークのサービスを使う場合は、作業ネットワークへの影響を避けるため、元に戻せるよう既存の DNS 設定を保存してください。

05 / システムへの接続

TUN、システムプロキシ、Fake-IP の連携

システムプロキシを有効にしたら、まず対象アプリがシステムプロキシに従うか確認します。一部のアプリやコマンドラインツールだけが対象の場合は、その後で TUN を検討してください。システムプロキシは HTTP、HTTPS、SOCKS の接続情報をアプリに提供するもので、実際に使うかどうかはアプリの実装によります。TUN は仮想ネットワークインターフェースとルートを使い、より広範囲の IP 通信を取り込みます。どちらも同時に有効にすべき「高速化」スイッチではありません。まず動作確認済みの接続方式をひとつ残し、対象アプリの通信がコアに届くことを確認してから、必要に応じて対象範囲を広げてください。

TUN を有効にする前にシステム権限を確認

macOS クライアントで TUN またはサービスモードの項目を探し、画面の案内に従って補助サービスのインストールとシステムの許可を行ってから、実行ログを確認してください。ボタン名や許可手順はクライアントや OS のバージョンによって異なるため、現在の画面に従います。許可の問題を解決するために、システムのセキュリティ機能を無効にしないでください。コアを単独で実行する場合も、十分なネットワーク権限が必要です。有効化に失敗したら、まず権限、仮想インターフェースの作成、ルート設定を確認してください。リモートプロキシに接続できるかどうかは後の段階であり、この二種類の問題は分けて検証する必要があります。

# 既存の動作中の設定に統合し、DNS には前章の有効な設定を使う
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route はルートを自動的に設定し、auto-detect-interface は出力インターフェースを検出し、stack は TUN で使うネットワークスタックを指定します。例の mixed は選択肢のひとつです。互換性の問題が起きた場合は、MTU、DNS、ルール、システムルートを一度に変更せず、コアの対応状況を踏まえてほかのスタックと比較してください。dns-hijack は対象経路に入る通常の DNS クエリを取り込みますが、暗号化 DNS サービスへ直接送る HTTPS リクエストが、宛先ポートを理由に通常の DNS クエリへ自動変換されるわけではありません。

Fake-IP のアドレスからサイトに接続できる理由

Fake-IP はドメインにマッピング用のアドレスを割り当て、接続時にその対応関係からドメイン名を復元してルールを適用します。接続先の実 IP を事前に取得しなくてもドメイン情報を維持できるため、ドメイン単位の振り分けに役立ち、一部のローカル名前解決経路が結果に与える影響も抑えられます。マッピング用のネットワーク範囲が実際のウェブサイトのネットワークになるわけではなく、最終的な接続が不要になるわけでもありません。プロキシ経由と直接接続でリモート接続をどう名前解決し、確立するかは、プロトコル、DNS 設定、出力先の動作によって異なります。

fake-ip-filter は、指定したドメインを仮想アドレスへのマッピング対象外にします。実 IP の名前解決結果が必要な業務、たとえば一部の LAN サービス検出やアドレス結果に依存するアプリに適しています。まず問題が起きている特定のドメインを例外にして、機能が回復するか確認してください。見かけの問題を解消するために、すべてのドメインをフィルターに追加しないでください。Fake-IP の範囲を変更する場合は、既存のネットワーク、社内 VPN、ほかの仮想インターフェースと競合しないことを確認します。古いマッピングをキャッシュしたアプリが引き続き古いアドレスに接続することもあるため、変更後は接続と DNS キャッシュの有効期間も考慮してください。

TUN の検証に --proxy を指定したコマンドだけを使うのは避けてください。明示的なプロキシリクエストでは、確認対象のシステム側の経路制御を迂回することがあります。個別にプロキシを設定していないアプリを選び、新しい接続を作成してクライアントの接続画面で確認します。さらに、LAN 内の機器、スリープからの復帰、ネットワーク切り替えもテストしてください。Wi-Fi から有線に切り替えた後もログに古いインターフェースが表示される場合は、インターフェース検出とルート復旧を確認します。複数のプロキシクライアントで TUN を同時に有効にすると、ルートの競合、DNS の二重リダイレクト、ループが発生することがあります。テスト中は必要な接続制御をひとつだけ有効にしてください。

有効化後に端末全体がオフラインになった場合は、逆の順で元に戻します。まず TUN を無効にし、システムプロキシの状態を確認してから、元の DNS とネットワーク接続を復元してください。すべての設定をすぐ削除すると、原因を特定できる問題が再インストール作業になってしまいます。画面のスイッチが有効でも、それは設定上の意図を示すだけで、仮想インターフェース、ルート、DNS がすべて正常とは限りません。許可ログ、インターフェースの状態、対象接続の記録を合わせて確認し、問題が接続の入口と出力先のどちらにあるか判断してください。基本的な復旧手順はヘルプセンターでも確認できます。

06 / 接続の識別

ドメインスニッフィングの用途、範囲、トラブルシューティング

接続画面を開き、ドメイン情報が本当に不足している接続を見つけてから、スニッフィングが必要か判断します。アプリによっては IP アドレスを直接指定したり、独自の名前解決経路を使ったりするため、コアが接続を受け取った時点で元のドメイン名が分からないことがあります。ドメインスニッフィングは、一部のプロトコルのハンドシェイクや平文のリクエスト情報からドメイン名を取得し、ルール照合の情報を補います。すべての暗号化通信を解析する汎用ツールではなく、有効にすればすべての IP 通信をドメイン名に戻せるわけでもありません。識別可能な情報が含まれているか、プロトコルに対応しているか、ハンドシェイクを読み取れるかによって結果は変わります。

まず控えめに有効化し、対象を上書きするか判断

HTTP リクエストにはホスト情報が含まれることがあり、TLS ハンドシェイクではサーバー名を確認できる場合があります。QUIC の一部のハンドシェイクにも識別の手掛かりが含まれることがあります。現代的な暗号化ハンドシェイク、独自プロトコル、IP アドレスのみのサービス、読み取れないハンドシェイクでは、識別できる情報が限られます。設定の sniff は識別を試みるプロトコルとポートの範囲を指定するもので、そのポートのすべての通信が指定プロトコルを使うことを意味しません。以下の設定例では接続先を維持したまま識別条件だけを追加し、スニッフィングによってルール判定が改善するか観察できます。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip を有効にすると、ドメイン名がない IP 接続の識別を試みます。force-dns-mapping は DNS マッピングの状況に応じた処理に関わります。宛先アドレスを上書きするかどうかは override-destination で制御します。「ルール照合のためにドメイン名を得る」こととは別の判断です。元の宛先を維持すれば、アプリが選んだアドレスを置き換えることで生じる差異を抑えられます。上書きが必要な場合は、対象の業務を個別に検証してください。特定の CDN アドレス、専用ゲートウェイ、固定の接続経路に依存するアプリでは、ドメインを正しく識別できても、宛先を変更するのが適切とは限りません。

同じ接続でルールの根拠を比較する

調査では、まずプロキシグループのメンバーを固定し、特定の用途をひとつ選びます。スニッフィングを無効にして新しい接続を作り、宛先、ルールタイプ、出力経路を記録します。次にスニッフィングを有効にし、同じ操作を繰り返します。異なるウェブページや再利用済みの接続を直接比較しないでください。ログにドメインが表示されなくても、項目が反映されていないとは限りません。通信がコアを通っていない、ポートが識別対象外、プロトコルから情報を取得できない可能性もあります。まず接続の入口、次にプロトコルの識別、最後にルールの順で確認してください。逆の順序で進めると、問題が複雑になることがあります。

スニッフィングの結果は DNS クエリの代わりにはなりません。接続に含まれるサーバー名が入口のドメインで、その後アクセスするサービスのドメインは別の場合があります。また、ひとつの IP アドレスで複数のドメインが使われることもあります。アドレスから名前を逆引きしても、アプリ本来の意図を安定して復元することはできません。ルールには、検証できる業務用ドメインの一覧を使い、一度取得したホスト名をサービス全体の固定範囲として扱わないようにしてください。ログイン、メディア、更新サービスでは、リダイレクト先やリソースのドメインが別の出口を使う場合も考慮します。

有効化後にアプリのハンドシェイクが失敗する、接続待ちが長くなる、誤った接続先にアクセスする場合は、まず宛先の上書きを無効にし、その業務に限ってスニッフィングの範囲を絞ります。コアが対応している場合は、ドメインをスキップする項目などで個別の例外を設定できますが、構文は使用中のコアのドキュメントに合わせてください。ひとつの業務で問題が起きただけなのに、DNS、TUN、スニッフィングをまとめてリセットすると、比較の基準を失います。動作していた経路を残し、識別動作をひとつだけ変更して、接続に実際の影響があったかログで確認するほうが効果的です。

トラブルシューティング情報を共有する際は、必要な対象ドメイン、ルールタイプ、エラー情報だけを切り出し、接続履歴全体のアップロードは避けてください。ドメインやアクセス時刻から、仕事や個人の利用状況が分かる場合もあります。ルールの書き方を詳しく確認するには、ルールセットの章に戻り、ドメインルールより前に IP ルールが一致していないか確認してください。接続自体が一覧に表示されない場合は、TUN とシステムプロキシの章に戻り、アプリの通信経路を確認します。スニッフィングは明確な識別情報の不足を補うために使い、あらゆる接続問題に対する既定のスイッチにしないでください。

07 / 設定の保守

ローカルオーバーライドと複数購読の統合

設定管理画面を開き、クライアントにオーバーライド、拡張、統合の機能があるか確認してから、カスタム設定の保存先を決めます。リモートの購読は継続的に更新されるデータ源です。ダウンロードしたファイルを直接編集すると、次回の更新で変更が消えることがあります。購読でプロキシ情報を管理し、ローカルオーバーライドでポート、DNS、業務ルール、グループ構成を保つ方法がより確実です。クライアントによって機能名や処理順序は異なるため、オーバーライドファイルをコピーしただけで、どのクライアントでも同じように処理されるとは限りません。

オブジェクトの統合とリストの統合を区別する

設定内のマップオブジェクトとリストでは、処理方法が異なります。マップオブジェクトは項目ごとに再帰的に統合される場合も、全体が置き換わる場合もあります。リストは先頭または末尾への追加、連結、全置換など、クライアントによって動作が異なります。ルールリストは順序が優先順位を決めるため、「追加できた」ことと「例外が適用された」ことは同じではありません。カスタムの直接接続ルールが MATCH の後ろにあると、通信に適用されません。DNS の項目もクライアントの設定で再度上書きされる場合があります。調査では、オーバーライドエディターの内容だけでなく、最終的な実行ファイルを確認してください。

まず小さなローカル例外をひとつ作り、実行設定のどこに反映されるか確認してから、すべてのルールを追加します。以下は完成後のルール順を理解するための例であり、すべてのクライアントで使えるオーバーライドファイル形式ではありません。前の章で作成した「業務用出口」を使い、ローカルアドレスとプライベートネットワークを範囲の広いルールより前に配置します。これらのアドレスを直接接続するかどうかは、実際のネットワーク要件に応じて判断してください。社内ネットワークの専用範囲、ほかの VPN が割り当てるアドレス、コンテナネットワークも個別に確認し、広すぎる範囲で本来のルーティング要件を覆い隠さないようにします。

# 最終的な実行設定でのルール順序
rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,業務用出口

複数の購読を独立したプロキシ一覧に分ける

複数の購読を統合する場合は、提供元の内容が完全な Clash 設定なのか、プロキシ一覧として直接読み込める形式なのかをまず確認します。完全な設定には DNS、ルール、その他のトップレベル項目が含まれるため、プロキシ一覧だけを受け付ける場所にそのまま入れることはできません。各提供元を独立した proxy-providers に整理してから、ローカルのプロキシグループで参照すると管理しやすくなります。各提供元には異なるセットキーとキャッシュパスを設定し、業務ルールからは変更されにくいローカルのグループ名だけを参照してください。上流のサーバー一覧が変わっても、メインルールを頻繁に変更せずに済みます。

プロキシ名の重複は、統合時によくある問題です。複数の提供元で同じ名前が使われていても、別のサーバーを指していることがあります。proxies を手動で連結すると、重複や参照先の曖昧さが生じることがあります。まず提供元ごとの分離を保ち、独立した一覧でメンバーを確認してから、対応している名前の処理方法が必要か判断してください。ノード名だけを変更し、プロキシグループでは古い名前を参照し続けないでください。複数ファイルにある同名のトップレベルキーをそのまま連結するのも避けます。スクリプトによる変換が避けられない場合は、使用中のクライアントが明確に対応するインターフェースを使い、元ファイルも復旧用に保管してください。

変更が完了したら、購読を手動で更新し、カスタム設定が残っているか確認してください。数日後にルールが動作しなくなってから気付くより、問題を切り分けやすくなります。書き出した実行設定に、保守に必要な情報がすべて含まれるとは限りません。統合後の結果だけが含まれ、オーバーライドの順序、スクリプト、外部セットの取得元が含まれないことがあります。そのため、バックアップには設定データだけでなく生成方法も含めてください。機密性のある購読 URL は安全に保管します。他人に設定を見せるときは、アカウント情報を除いた最小限の再現ファイルを使い、個人用バックアップ全体を共有しないでください。

クライアントに必要な統合機能がない場合は、内容を把握できない変換チェーンを自動化のために導入するのではなく、安定したメイン設定とローカルファイルの一覧を使う方法を検討してください。変換が必要な場合は、第三者サービスが購読情報を扱えることを理解しておきましょう。URL、クリップボード、ローカルファイルからの読み込みの違いは、購読形式と読み込み方法をご覧ください。このページでは、読み込み後の長期的な管理方法を扱います。保守方法を選ぶ際は、更新を繰り返し実行できるか、例外を保てるか、最終結果を説明できるかを重視してください。設定ファイルを複雑にすることが目的ではありません。

08 / ローカルコントローラー

外部コントローラーパネルと設定変更の確認

外部コントローラーパネルを使う場合は、実行設定の external-controller の待受アドレスを確認し、次にパネルがどこで動作しているか確かめます。コントローラーは接続の確認、プロキシグループの切り替え、コアの実行状態の管理に使います。アプリがウェブサイトに接続するためのプロキシポートではありません。7890 のような mixed-port に接続しても、通常はコントローラーの応答を得られません。ローカル利用ではループバックアドレスでの待受を優先し、現在のクライアントの管理方法も残してください。GUI クライアントが同じインターフェースを利用する場合もあり、ポートを不用意に変更すると画面とコアが接続できなくなります。

ローカルの制御インターフェースと静的パネルを別々に設定

external-ui はローカルの静的パネルファイルがあるディレクトリを指定します。ディレクトリには、対応するパネルのページリソースをあらかじめ用意してください。ディレクトリを指定するだけで、コアに完全なフロントエンドが追加されるわけではありません。以下はローカルでの待受とディレクトリの関係を示す例です。追加する前にポートが空いていることと、クライアントでコントローラーの設定を変更できることを確認してください。認証が必要な場合は、クライアントが対応する安全な方法で、十分に強度のある専用のパスワードをローカルに設定し、パネル側にも同じ値を設定します。実際のパスワードを公開例、スクリーンショット、同期共有される設定リンクに記載しないでください。

# ローカル利用専用。対応するディレクトリにパネルの静的ファイルを置く
external-controller: 127.0.0.1:9090
external-ui: ./ui

パネルには通常、インターフェースのアドレス、ポート、認証情報を設定します。接続が拒否された場合は、まず待受があるか確認してください。認証エラーが出たらパスワードを照合します。ブラウザーだけでアクセスに失敗し、コマンドラインからは到達できる場合に限り、クロスオリジン、セキュアコンテキスト、混在コンテンツの制限を確認します。ループバックアドレスは、アクセス元の端末自身を指します。スマートフォンのブラウザーで 127.0.0.1 を指定しても、パソコンには接続できません。複数端末から制御する必要がある場合は、管理された安全なアクセス方法を使い、待受範囲を広げるリスクを理解してください。管理ポートをそのままインターネットに公開してはいけません。

書き込み操作の前に読み取り専用で確認

初めてパネルに接続したら、まず現在のモード、プロキシグループ、接続一覧を確認し、想定したコアのインスタンスに接続しているか確かめます。パソコンでクライアントをふたつ同時に動かしていると、パネルが古いプロセスにつながり、プロキシグループを切り替えても現在の通信に影響しないことがあります。待受ポート、現在の設定、新しい接続を照合すれば、この誤認を防げます。以下はローカルのバージョン情報 API に読み取り専用リクエストを送る例です。応答があればインターフェースへの到達性を確認できます。認証を有効にしている場合は、ローカルの設定に応じた認証ヘッダーを付けてください。認証情報を付けずに拒否されたからといって、コアの故障と判断してはいけません。

curl --fail --silent --show-error \
  http://127.0.0.1:9090/version

パネルでグループのメンバーを切り替えた後は、変更を永続化する必要があるか確認してください。実行中の状態、クライアントの設定、リモート購読は別々の層です。再起動後に選択が復元されるかは、コアの設定とクライアントの管理方法によって異なります。API への一度の書き込みが、ローカルオーバーライドファイルの更新を意味するわけではありません。スクリプトで自動操作する場合は、まず応答と対象グループ名を確認し、変更範囲を絞ってから実行します。API エラー、グループ名の変更、設定の切り替えによって、スクリプトが誤った対象を操作する可能性があります。自動化の価値は、確認を省くことではなく、繰り返し確実に実行できることです。

接続一覧はドメイン、ルール、プロキシグループの経路の確認に、ログはダウンロード、名前解決、ハンドシェイクのエラー確認に使えます。調査中は一時的にログの詳細度を上げてもかまいませんが、終わったら通常のレベルに戻し、アクセス記録が過剰に蓄積されないようにしてください。パネルの提供元も慎重に選ぶ必要があります。制御インターフェースを呼び出せるページは接続情報を読み取ったり、管理操作を実行したりできるため、信頼できるローカルリソースか、構成を把握した環境だけを使ってください。ブラウザーで証明書、クロスオリジン、コンテンツセキュリティの警告が出た場合は呼び出し元と接続先を確認し、パネルを開くためにすべての接続元を許可するような広範な設定は避けましょう。

最後に一通り動作確認します。購読を更新できること、プロキシ一覧とルールセットを読み込めること、システムプロキシまたは TUN が想定どおり通信を取り込むこと、DNS でよく使うドメインを解決できること、社内ネットワークのサービスに引き続き接続できること、パネルが現在のインスタンスを操作していることを確認してください。さらにスリープからの復帰とネットワークの切り替えも試し、起動直後だけ動作する状態ではないことを確かめます。問題があれば、このガイドの該当章に戻って原因を絞り込んでください。初回インストールと基本的な読み込み方法はクイックスタートガイド、クライアントの選択はダウンロードページ、一般的なトラブルはヘルプセンターをご覧ください。すべての高度な機能を一度に有効にするより、説明できて復旧可能な設定を保つほうが、長期的な管理に役立ちます。