01 · 設定の適用順と変更の基本
クライアント、コア、実行時設定
クライアントの画面では、サブスクリプションのインポート、オプションの保存、バックグラウンドサービスの起動を行います。コアはルールを解析し、接続を確立してトラフィックを転送します。画面にスイッチがあっても、サブスクリプションファイルに同名の項目があるとは限りません。反対に、ファイルに項目を書いても、クライアントが実行時設定を生成する際に上書きされる場合があります。トラブル対処では、まずクライアントのコア情報やログで実際に使用中のコアを確認し、サブスクリプションの編集画面だけでなく、コアに渡される最終設定を特定してください。
当サイトではプラットフォーム別にクライアントを紹介しています。選ぶ際はまずClash Plusを確認し、OSや必要な機能に応じてほかのクライアントも比較してください。Clash Verge Rev、Clash Meta for Android、FlClashなどでは、設定画面やマージ方法がそれぞれ異なります。インストール先を選び直す場合は、クライアントのダウンロードページをご覧ください。このページでは、特定のクライアントの画面操作をすべてのプラットフォームに共通する手順として扱いません。各項目の対応状況は、実際に動作しているコアに基づいて確認してください。
元に戻せる最小限の変更手順
変更前に、サブスクリプションの配布元、ローカル上書き設定、現在動作している実行時設定をそれぞれ保存し、システムプロキシとTUNの元の状態も記録してください。サブスクリプションURLにはアクセス用の認証情報が含まれる場合があるため、公開リポジトリやスクリーンショット、質問投稿に載せないでください。一度に変更する設定レイヤーは一つに絞り、まずファイルが読み込まれること、次にルールが一致すること、最後にトラフィックの取り込み方法を確認します。DNS、ルーティング、ルールセットを同時に変更すると、接続に失敗した際にどの変更が経路に影響したのか特定しにくくなります。
以下は基本項目を理解するための例で、プロキシノードを含む完全なサブスクリプションではありません。ルールモードとmixed-portを使用し、ルールに一致しない接続は直接外部へ出します。既存設定に統合する場合は、同名のトップレベル項目を編集し、ファイル末尾に二つ目の rules を追加しないでください。YAMLの重複キーは解析方法によって扱いが異なるため、後から書いた内容が必ず前の内容を上書きするとは限りません。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECTインデントにはスペースを使い、リスト項目のハイフンと所属する項目の階層を揃えてください。コロンやシャープ記号を含む文字列、特殊な型として解釈される可能性のある文字列は、引用符で囲むのがおすすめです。よくある形式エラーは設定項目が複雑だからではなく、例をコピーした際にインデントが崩れたり、設定全体を子項目の中に貼り付けたりすることで起こります。エディター上で問題がなくてもコアが解析できるとは限りません。保存後は読み込み結果も確認してください。
構文チェックと動作チェックを分ける
独立したMihomo実行ファイルがある場合は、下記のテストコマンドを実行できます。コマンドで指定するファイルは現在のディレクトリに置いてください。ルールセットやデータベースなどの依存ファイルを相対パスで指定している場合は、テスト時の作業ディレクトリを実際の実行環境と揃える必要があります。構文テストに通っても、ノードの利用可否、DNSの接続性、システムルートの設定まで保証されるわけではありません。
mihomo -t -f ./config.yaml新しい接続を一つ作成し、動作を順番に確認します。アプリからコアへ接続が届いているか、対象ドメインを認識できているか、どのルールに一致したか、最終的にどのアウトバウンドが選ばれたかを調べてください。ブラウザーの既存の長時間接続は古いポリシーを使い続ける場合があります。テストには新しいリクエストを使い、必要ならアプリを終了して再接続してください。プロキシグループを切り替えた後も古いタブでページが表示できるからといって、新しいルールが反映されたとは限りません。
最小限の設定でも起動できない場合は、ルールの構文を調べる前に、ポートの競合、ファイル権限、パスを確認してください。アドレスが使用中というメッセージが出る場合は、7890の競合確認とmixed-portの変更手順を参照してください。ポートを変更したら、手動プロキシの設定も合わせて変更します。変更後のポートでコアが待ち受けているのに、ブラウザーが古いポートへ接続する事態を防げます。
02 · プロキシグループの種類と実践的な階層化
ルールの宛先と実際のアウトバウンドを区別する
ルールは「この接続をどこで処理するか」を決め、プロキシグループは「候補となるアウトバウンドからどれを選ぶか」を決めます。ルールの参照先には、個別のノードもプロキシグループも指定できます。日常的な設定では、ルールから変更の少ないグループ名を参照し、ノードの追加や削除はグループ内で管理すると便利です。サブスクリプション更新でノード名が変わっても、各ルールを修正せずに済みます。グループ名は参照用の識別子です。空白、大文字・小文字、文字列を完全に一致させてください。
select は手動選択用のグループで、ユーザーが直接操作する入口に適しています。url-test はテスト結果に基づいて候補を選びます。fallback は候補が利用可能な場合、リストの先頭に近いアウトバウンドを優先します。load-balance は選択した分散方式に基づいて、異なる接続に候補のアウトバウンドを割り当てます。それぞれ解決する課題が異なるため、名称だけを見て「自動」があらゆる用途で「手動」より適切だと判断しないでください。
| 種類 | 用途 | 注意点 |
|---|---|---|
select | 出口を明示的に指定 | 現在の選択肢を手動で管理する必要がある |
url-test | テスト結果の良い候補を自動選択 | テスト先の結果が実際の用途を反映するとは限らない |
fallback | メインと予備の順序が明確 | 候補の順番が選択に影響する |
load-balance | 複数の接続に振り分け | 単一接続の帯域を複数回線分に増やすことはできない |
入口グループと自動選択グループを分ける
管理しやすい構成の一例は、ルールから「ネットワーク出口」を参照し、入口グループから自動選択グループ、手動選択候補、直接接続を選べるようにする方法です。以下の例では組み込みの DIRECT だけを参照するため、グループ間の参照関係を示すものであり、プロキシ接続先は提供しません。実際に使うには、適切に取得したサブスクリプションやローカルのノード定義から実際の候補を追加し、その名称を自動選択グループに指定してください。例をノードの入手先と誤解しないようにしましょう。
proxy-groups:
- name: ネットワーク出口
type: select
proxies:
- 自動選択
- DIRECT
- name: 自動選択
type: url-test
proxies:
- DIRECT
url: https://example.com/
interval: 300
tolerance: 50
rules:
- DOMAIN-SUFFIX,example.com,ネットワーク出口
- MATCH,DIRECTここでの interval は定期テストの間隔を示し、tolerance は小さなテスト差による頻繁な切り替えを抑えます。テスト先には、候補のアウトバウンド経由でアクセスでき、応答が明確なエンドポイントを選んでください。例に記載したドメインは項目の理解を目的としたもので、実運用では自身のネットワーク環境に合ったテスト先を選びます。テスト結果が示すのはその宛先までの経路であり、ダウンロード速度、動画の視聴可否、アカウントを使うサービスの安定性を保証するものではありません。
ログインセッション、決済ページ、出口IPに敏感なサービスでは、新しい接続ごとに出口が変わらないよう、通常は手動選択グループに固定します。スティッキー方式を使っても、関連するすべてのドメインが必ず同じIPアドレスになるとは限りません。ページが複数のサービスに依存していたり、候補が変わったりするためです。出口の安定性が必要な場合は、グループ名だけで判断せず、実際の接続記録を確認してください。
循環参照と候補不足を避ける
プロキシグループから別のグループを参照できますが、循環参照は作れません。たとえば入口グループが自動選択グループを参照し、自動選択グループが入口グループを参照すると、選択処理の終点が定まりません。安全な方法は、業務ルールから入口グループ、入口グループから機能別グループ、機能別グループから実ノードまたは組み込みアウトバウンドへと、一方向の階層を保つことです。プロバイダー参照では、use に記載した名称が存在するか、プロバイダーが正常に読み込まれたかを確認してください。
グループは表示されるのに選択できるノードがない場合は、まずフィルター条件ですべての候補が除外されていないかを確認し、次にサブスクリプションの読み込み履歴を確認してください。フィルター条件をいきなり複雑にするのは避けましょう。ノード名が重複していると、表示や参照が曖昧になることもあります。複数のサブスクリプションを統合する場合は、あらかじめ一意の命名規則を決めてください。自動選択グループの候補がすべて失敗する場合は、既知の候補を一つ選んで個別にテストし、ノードの接続性とテスト先への到達性を切り分けます。
グループの選択を変更した後は、新しい接続で動作を確認してください。一部のクライアントは前回の選択を保存し、再起動後に復元します。これはYAML内のリスト順とは別の動作です。画面上の選択が想定と異なる場合は、クライアントの永続化設定と現在の実行状態を両方確認してください。操作画面を比較するにはクライアント比較ページをご覧ください。状態保存の仕組みを避けるために、グループ名を何度も変更するのはおすすめしません。
03 · ルールセットの管理とマッチ順序
ルールの内容と振り分け先を分ける
ドメインやIPレンジの項目が増えてきたら、すべてをメイン設定に詰め込むと更新や確認が難しくなります。rule-providers はルールの配布元を定義し、RULE-SET はメインのルール一覧からそれを参照して、一致したときのポリシーを指定します。ルールセットは「対象に何が含まれるか」、メイン設定は「その対象をどこへ通すか」を管理します。分けておけば、同じ業務ドメインのリストを異なるデバイスで別々のプロキシグループに振り分けられます。
プロバイダーの behavior は、ルールの内容と一致させてください。domain はドメインの集合、ipcidr はIPレンジ、classical は従来のルール形式を含む項目に対応します。ダウンロード先にアクセスできても、ファイル形式が正しいとは限りません。payload を含むYAMLを単純なテキスト一覧として読み込んだり、完全なルール行をドメイン解析用の形式として渡したりすると、読み込みに失敗したり、想定外の結果になったりする可能性があります。
まずローカルファイルで参照関係を確認する
以下ではローカルファイルを使い、リモートダウンロードに依存せずにルールセットを検証します。まずコアの作業ディレクトリに rules フォルダーを作成し、local-domains.yaml を保存してください。このファイルにはルールの内容だけを記述し、プロキシポリシーは記述しません。例のドメインはマッチ確認用です。実際の用途に合わせて、管理する必要のあるドメインに置き換え、変更履歴も残してください。
# rules/local-domains.yaml
payload:
- '+.example.com'メイン設定にファイルの配布元を定義し、通常のルールから参照します。相対パスはコアの作業ディレクトリを基準に解決され、クライアントで現在開いている編集ファイルの場所を基準とするとは限りません。デスクトップクライアントでは、コアに割り当てられた設定ディレクトリを先に確認してください。ファイルをダウンロードフォルダーに置いても、実行時に別の場所を参照して見つからない場合があります。
rule-providers:
local-domains:
type: file
behavior: domain
format: yaml
path: ./rules/local-domains.yaml
rules:
- RULE-SET,local-domains,DIRECT
- MATCH,DIRECTHTTPの配布元に切り替える場合は、実際にアクセスできる url、キャッシュ用の path、更新間隔の interval を設定し、サーバーから返される内容がルール本体であり、プレビュー画面やログインページではないことを確認してください。キャッシュパスは重複しないようにし、異なるプロバイダーが同じファイルに書き込まないようにします。ファイル形式にはコアが対応するYAML、テキスト、コンパイル形式などを使用できますが、内容と宣言を一致させてください。拡張子だけの変更では対応できません。
ルールの順序が適用結果を決める
ルールは通常、上から順に照合され、最初に一致したルールでその接続の選択が確定します。特定ドメインの例外は幅広い分類より前に置き、最後に MATCH で残りのトラフィックを受けます。MATCH の後ろにルールセットを追加しても、想定した動作にはなりません。同様に、対象範囲の広いドメインサフィックスのルールが前にあると、後続の細かな分類ルールが一度も適用されないことがあります。
IPルールによってドメインの名前解決が行われる場合があります。ルール末尾に no-resolve を指定すると、対象がドメイン名のときに、そのIPルールのためだけの追加の名前解決を行わないようにできます。これは「接続全体でDNSを禁止する」設定ではありません。ドメインルールを優先したい場合は、名前解決が必要なネットワークレンジのルールより前に配置してください。不必要な問い合わせを減らすためにこのパラメーターをあちこちに追加すると、名前解決結果に依存するルールが機能しなくなる可能性があります。
リモートルールセットの更新に失敗した場合は、まずコアに利用可能なキャッシュが残っているか確認し、次にダウンロード先とアクセス条件を調べます。初回起動と通常の更新では条件が異なります。通常の更新なら古いキャッシュを使って起動できますが、初回起動時には利用できる内容がない場合があります。ルールのダウンロードにプロキシが必要で、そのプロキシの選択がまだダウンロードできていないルールに依存していると、起動時の依存関係が循環します。基本の起動経路はシンプルに保ちましょう。
頻繁に更新されるルールの配布元は、変更前の内容を保存し、更新後に重要な業務ドメインが新しい分類に含まれていないか確認してください。GeoIP、GeoSite、通常のルールプロバイダーは、同じ仕組みで保存されるものではありません。関連データベースの形式、パス、更新条件は、GeoIP・GeoSiteデータベースの更新方法もご覧ください。名称を統一するために、異なる仕組みのファイルを互いに置き換えないでください。
04 · DNSの名前解決経路と設定の最適化
アプリの問い合わせ、コアの名前解決、ノードの名前解決を区別する
DNSの問題は、単に「DNSサーバーを設定したか」ではなく、誰が問い合わせを送信しているかに起因することがよくあります。ブラウザーが独自の暗号化DNSを使用していたり、OSが古い結果をキャッシュしていたり、コアがプロキシサーバーのドメイン名を解決する必要があったりします。システムプロキシは、プロキシ設定に従うアプリのリクエストに影響しますが、すべてのDNS問い合わせが自動的にコアへ送られるわけではありません。設定を変更する前に、アプリがシステムDNS、コアのDNS、または独立した経路のどれを使っているか確認してください。
nameserver は通常の名前解決に使う上流サーバーです。default-nameserver はDNS上流サーバー自身のドメイン名解決など、起動時の基本処理に使用します。proxy-server-nameserver では、プロキシサーバーのドメイン名を解決する上流を別に指定できます。設定を分けることで、ノードのアドレスを解決するために、まだ確立していないプロキシ接続を経由する事態を避けられます。上流をすべてHTTPSに変更するだけでは、この依存関係は自動的に解消されません。
まず仕組みを把握しやすい基本の名前解決を設定する
以下の例では、ループバックアドレスの標準外ポートでコアのDNSサービスを待ち受け、Fake-IPを使用します。この設定だけでOSのDNS設定が変更されることはありません。実際に問い合わせをこの待ち受けポートへ送って初めて効果を確認できます。デスクトップクライアントの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
default-nameserver:
- 1.1.1.1
- 8.8.8.8
nameserver:
- https://1.1.1.1/dns-query
proxy-server-nameserver:
- https://1.1.1.1/dns-query上流アドレスは設定例であり、あらゆるネットワーク環境で到達できることを保証するものではありません。上流を選ぶ際は、ローカルでのアクセス条件、問い合わせのプライバシー要件、結果が用途に合うかを考慮してください。ipv6: false はここで設定するDNSのAAAA応答を制御する項目で、システム全体のIPv6通信を無効にするものではありません。ネットワークでIPv6が使える場合、無効にすると既存の接続経路が変わる可能性があります。明確な問題がある場合にのみ変更してください。
ドメイン別に名前解決のポリシーを指定する
社内ドメイン、家庭内デバイス名、特定サービスのドメインは、指定したDNSサーバーでなければ正しく応答できない場合があります。その場合は nameserver-policy を使って、対象ドメインに専用の上流サーバーを指定できます。内部ドメインを安易にパブリックDNSへ送信すると、名前解決できないだけでなく、イントラネット内でしか使わない名前を外部へ漏らす可能性があります。設定前に対象のドメイン範囲を確認し、広すぎるサフィックスによって多くのパブリックドメインの問い合わせまで社内サーバーへ送らないようにしてください。
respect-rules を使ってDNS上流への接続にも振り分けルールを適用する場合は、プロキシサーバーのドメイン名をどう解決するかも考慮してください。この設定が変更するのは、コアからDNS上流へアクセスする経路であり、DNS応答すべてに正しい分類を自動で付与するものではありません。まず独立して到達できるノードの名前解決経路を確保し、次に上流への接続がどのルールに一致するか確認してください。ノードの名前解決とノード接続が互いに待ち合う循環を防げます。
fallback と fallback-filter は、単純に「プライマリが故障したら予備へ切り替える」ためのスイッチではありません。有効にすると、ドメインやアドレス範囲などの条件に応じて応答がフィルタリングされます。明確なフィルター対象がなければ、信頼できる単一の名前解決経路を維持してください。特定のドメインで具体的な問題が確認できた場合にのみ、フォールバック機能を追加します。上流サーバーを増やせば必ず安定するわけではなく、トラブル対処の範囲が広がることもあります。
dig @127.0.0.1 -p 1053 example.com Aテストでは、問い合わせ時間、返されたアドレスの種類、コアのログを併せて記録してください。Fake-IPモードで予約済みアドレス範囲のIPが返されても、正常な場合があります。パブリックIPではないという理由だけで、名前解決の失敗と判断しないでください。モード変更後もアプリやシステムのキャッシュに古い結果が残る場合があります。新しいリクエストを作成し、必要に応じてOSの手順でキャッシュを更新してください。DNS上流を次々に追加するだけでは解決しません。
ドメインを解決できるのにウェブページを開けない場合は、接続に適用されたルールとアウトバウンドを引き続き確認してください。ブラウザーだけ挙動が異なる場合は、ブラウザー独自のDNS設定とプロキシ拡張機能を確認します。関連する症状は、接続済みなのにウェブページを開けない場合の確認リストに沿って順に確認できます。DNS設定の最適化で目指すのは経路が明確で検証可能な状態であり、設定項目の数を増やすことではありません。
05 · TUNによるトラフィックの取り込みとFake-IPマッピング
それぞれの仕組みが扱う範囲
TUNは仮想ネットワークインターフェースを作成し、ルーティング条件に一致するIPトラフィックをOSからコアへ渡します。Fake-IPはDNSの段階で制御された仮想アドレスを返し、コア内にそのアドレスと元のドメイン名の対応を保存します。TUNは「トラフィックをどうコアに取り込むか」、Fake-IPは「このトラフィックが本来どのドメインに接続していたか」を把握する手助けをします。併用されることは多いものの、同じ機能ではなく、一方を有効にすればもう一方が不要になるとは限りません。
システムプロキシはアプリがプロキシ設定に従うことを前提としているため、設定に従わないプログラムには効果がない場合があります。TUNはルーティングによってより多くのトラフィックを取り込めますが、権限、仮想NIC、システムDNS、ほかのVPNとの調整も必要です。取り込み範囲が広がっても、すべてのプロトコルを自動的にリモート側で利用できるわけではありません。最終的な利用可否は、アウトバウンドノードのプロトコル対応にも左右されます。特にUDPは、アプリからコア、リモート側までの全経路が対応している必要があります。
クライアントの権限付与手順に沿って有効にする
デスクトップでは、まずクライアントが提供するサービスのインストールまたは認証手順を実行してからTUNを有効にしてください。Windowsではバックグラウンドサービスや管理者権限が必要になる場合があります。macOSではクライアントの実装に応じたシステム認証が必要です。Linuxではサービス権限、ネットワーク管理、ルーティング設定によって異なります。Androidでは通常、システムのVPNサービスを許可します。設定項目が画面に直接表示されるかどうかはクライアントによって異なります。iOSのネットワーク制御はアプリとシステム拡張機能で管理されるため、デスクトップの生のNIC設定をそのまま適用しないでください。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53この例は、前章のコアDNSを有効にしてあり、クライアントが該当するTUN設定に対応していることを前提とします。auto-route は必要なルートの追加を試み、auto-detect-interface は出口インターフェースの検出を試みます。複数のNIC、コンテナ、リモートデスクトップ、企業ネットワークでは、自動検出が実際のネットワーク構成に合わない場合があります。stack はプラットフォームの対応状況とアプリの挙動を踏まえて選んでください。すべてのデバイスに共通する正解はありません。
dns-hijack の例は従来のDNSポートを対象とするもので、ブラウザーのDoHなどの暗号化DNSが復号または置き換えられることを意味しません。一部のアプリは固定IPへ直接接続したり、独自の名前解決サービスを使ったりするため、接続記録を確認する必要があります。アプリがコアの接続一覧にまったく表示されない場合は、ドメインルールを何度も変更するのではなく、まずルーティングとトラフィックの取り込み経路を調べてください。
Fake-IPフィルターは必要な例外に絞る
実際のアドレスを必要とするアプリでは、Fake-IPを受け取ると正常に動作しないことがあります。たとえば、一部のLAN内検出、デバイス接続、特定の認証処理が該当します。fake-ip-filter に対象ドメインの例外を追加すると、実際の名前解決結果を返せます。追加する前に、現在の fake-ip-filter-mode の意味を確認してください。フィルターモードによって、同じリストの意味が逆になる場合があります。出所が不明な長いリストをそのままコピーしないでください。
フィルター範囲が広すぎると、コアがマッピングを使ってドメイン名を復元する機会が減り、ルールのマッチ条件が変わる可能性があります。まず問題が起きているドメインを一つに絞り、問い合わせがコアに届いているか、返されたアドレスの種類、実際の接続が本物のアドレスに依存するかを確認してください。デバイス検出にはブロードキャストやマルチキャストも使われる場合があり、ドメインのフィルターを追加するだけですべてのLANアクセスの問題が解決するわけではありません。
ほかのVPNと併用する場合は、デフォルトルートとDNSをそれぞれどちらが管理するか、トラフィックが二重に取り込まれていないかを明確にしてください。二つの仮想NICが似たルートを設定すると、リクエストの迂回やループ、一部の宛先だけ接続できないといった問題が起こる場合があります。片方のトラフィック取り込みを停止して再テストすると、競合の原因を切り分けやすくなります。ネットワーク構成が不明なまま、より厳しいルート設定を追加しないでください。
元に戻すときは、まずTUNを無効にし、システムプロキシとDNSが想定した状態に戻ったか確認してください。Fake-IPと実際の名前解決を切り替えた後は、関連するキャッシュを更新し、接続を作り直します。クライアント画面を閉じてもネットワークの異常が続く場合は、バックグラウンドサービスが動作中か、システムに手動プロキシ設定が残っていないかを調べてください。一般的な問題はヘルプセンターもご覧ください。障害が起きる直前に変更したネットワークレイヤーも記録しておきましょう。
06 · ドメインスニッフィングと識別の範囲
スニッフィングで接続情報を補う
接続がコアに届いた時点で宛先IPしか含まれていないと、ドメインルールの照合に必要な情報が不足する場合があります。ドメインスニッフィングは、HTTPリクエストのホスト情報やTLSハンドシェイクのサーバー名など、プロトコルの初期通信からホスト名を取得し、後続の処理に利用しようとする機能です。任意のHTTPS本文を復号する機能でも、すべてのIPアドレスを一意のドメインに戻す機能でもありません。一つのIPアドレスが複数のウェブサイトをホストしている場合、IPアドレスだけからサービス名を特定することはできません。
スニッフィングとFake-IPはどちらもドメイン情報の保持に役立ちますが、情報の取得元は異なります。Fake-IPはコアが処理するDNSマッピングに依存し、スニッフィングは接続の初期段階で観測できるプロトコルデータに依存します。アプリがコアのDNSを通らない場合、スニッフィングで一部の情報を補えることがあります。一方、ハンドシェイクから利用可能なドメイン名を取得できない場合や、プロトコルが非対応の場合は、スニッフィングでドメインを生成することはできません。
プロトコルとポートの範囲を絞る
以下の例では、HTTPとTLSの基本的なスニッフィング設定を示し、元の接続先も保持します。最初は対象ポートを絞って動作を確認し、必要に応じて実際のアプリに合わせて範囲を広げると、最初からすべてのポートを対象にするより原因を特定しやすくなります。例のポート範囲は設定条件であり、そのポートの全トラフィックが必ず該当プロトコルを使用するわけではありません。
sniffer:
enable: true
force-dns-mapping: true
parse-pure-ip: true
override-destination: false
sniff:
HTTP:
ports:
- 80
- 8080-8880
override-destination: false
TLS:
ports:
- 443
- 8443parse-pure-ip を有効にすると、IPアドレス宛ての接続も解析対象になる場合があります。force-dns-mapping はDNSマッピングに関係します。これらの動作が本当に必要か、元の接続情報を踏まえて判断してください。override-destination は、識別結果で接続先を書き換えるかを決める項目で、ドメイン情報を補うだけの設定ではありません。使用前に、「ルールでドメインを識別したい」のか「最終的な接続先を変更したい」のかを区別してください。
元のアドレスを保持しておくと、設定を有効にする前後の動作を比較しやすくなります。特定のアドレス、プライベートDNS、専用線の入口に依存する用途では、接続先を書き換えることで追加の名前解決が必要になり、リクエストが本来のサーバーから外れる可能性があります。接続先の書き換えが必要な場合は、まずアプリ一つ、ドメイン一つで検証してから適用範囲を広げてください。あらゆる接続障害に対する汎用的な解決策として使うべきではありません。
除外範囲と識別できないケース
スニッフィングに適さない用途では、コアが対応するドメインまたはアドレスの除外項目を使って例外を設定できます。例外は再現可能な互換性の問題に基づいて設定し、出所の不明な除外リストをコピーしないでください。除外前後の宛先アドレス、識別されたドメイン、一致したルールを記録すると、問題が識別処理と後続のポリシー選択のどちらで起きているかを判断できます。
QUICは通常のTLSとは通信方式が異なり、対応する解析機能を有効にしてコアがサポートしている場合に限り、関連情報を取得できる可能性があります。対応していても、暗号化されたハンドシェイクの情報がすべて見えるわけではありません。ECHなどを有効にした接続では、利用可能なホスト名が公開されない場合があります。独自プロトコル、IPアドレスを直接使うアプリ、ホスト情報を含まない接続も、ドメインルールに使える情報をスニッフィングで取得できないことがあります。
ログにドメイン名を表示させるためだけに、特定のプロトコルを安易に遮断しないでください。UDPを遮断すると、一部のアプリが別の通信方式に切り替わる場合もあれば、サービス自体が使えなくなる場合もあります。互換性テストが必要な場合は、テスト条件を明確にし、終了後に元の設定へ戻してください。通常の設定はアプリの要件に基づいて設計し、接続一覧を見やすくすることを目的にしないでください。
接続記録で変更前後を比較する
検証ではまずスニッフィングを無効にし、対象への新しいリクエストを一度作成して、宛先の種類、ルール、アウトバウンドを記録します。次にスニッフィングを有効にし、同じ用途で新しい接続を作成してください。ドメインが表示されても振り分けが変わらない場合は、先にIPルールが適用されているか、ドメインルールの対象範囲にその宛先が含まれているかを確認します。有効にして接続できなくなった場合は、接続先が書き換えられたか、追加の名前解決に成功したかを優先して比較してください。
テストログの保存範囲は必要最小限にしてください。ドメイン、リクエストパス、ノード名、コントローラー情報には、個人や組織のネットワーク活動が含まれる場合があります。質問するときは必要な項目だけ残し、個人情報を伏せてください。「すべてのノードがタイムアウトする」といった基本的な障害では、スニッフィングは通常、最初に確認する項目ではありません。まずサブスクリプション、システム時刻、プロトコル互換性の確認手順に沿って、アウトバウンド接続が確立できることを確認してから、ドメイン識別を調整してください。
07 · ローカル上書きと複数サブスクリプションの統合
更新対象の設定とデバイス固有の設定を分ける
サブスクリプションでは、ノードやグループ、プロバイダー管理のルールを扱い、ローカル設定にはデバイスのポート、TUN、LANアクセス制限、個人用の振り分け例外などを保存するのが適しています。サブスクリプション本文を直接変更すると、次回更新時に内容が失われることがあります。クライアントの上書き、マージ、拡張設定機能を使えば、サブスクリプションを更新しながらデバイス固有の設定を独立して保持できます。
クライアントによって「上書き」の仕様は異なります。項目をマージするもの、項目全体を置き換えるもの、スクリプトを実行するもの、最後に画面上の設定を強制適用するものがあります。特に rules や proxy-groups のような配列が、項目単位で追加されるとは限りません。設定前に適用順序を確認し、変更後は最終的な実行時設定を確認してください。上書き用のエディターを見るだけでは、最終結果は判断できません。
プロキシプロバイダーで複数の配布元を管理する
複数のサブスクリプションを、完全な設定ファイルごと直接結合する必要はありません。適切な形式のノード配布元なら、proxy-providers で個別に管理し、プロキシグループから use で参照できます。以下では、構成の確認に適したファイル形式の配布元を例にします。コアの作業ディレクトリに実際のノードファイルを用意してください。ファイルを作成するまでは、そのまま起動できる完全な設定として扱わないでください。
proxy-providers:
personal-nodes:
type: file
path: ./providers/personal.yaml
work-nodes:
type: file
path: ./providers/work.yaml
proxy-groups:
- name: 個人用回線
type: select
use:
- personal-nodes
- name: 仕事用回線
type: select
use:
- work-nodesプロバイダーファイルには、コアの要件を満たす proxies リストを含めてください。ルール一式を含むクライアント設定を適当に保存しただけのファイルでは代用できません。エンコードされた共有リンクの一覧、Clashの完全な設定ファイル、プロキシプロバイダーファイルはそれぞれ異なる形式です。インポート前に、クライアントや配布元が該当形式の変換に対応しているか確認してください。個人用サブスクリプションを不明なオンライン変換サービスに渡さないでください。管理外の環境へサブスクリプションURLやノードの認証情報を送ると、アクセス権まで漏れる可能性があります。
配布元がHTTPプロバイダーに対応している場合は、ソースごとにキャッシュパスと更新間隔を設定できます。個人用と仕事用を分けると、プロキシグループの境界が明確になり、一方の配布元だけ無効にしてテストすることも容易です。ただし、配布元の利用許諾範囲を確認してください。技術的に統合できるからといって、ほかのデバイスやユーザーへアクセス権を移してよいとは限りません。
名前、追加位置、優先順位を整理する
統合する前に命名規則を決めます。プロバイダー名は一意にし、プロキシグループ名は安定させ、異なる配布元のノード名が重複しないようにしてください。参照は名前に基づくため、画面に同じ名称が表示されれば配布元を自動的に区別できるとは限りません。接頭辞を付けたり名前を変更したりする場合は、クライアントまたはコアが明確に対応する方法を優先し、変更後のノードにフィルター条件が一致するかも確認してください。
ローカルルールは通常、先に適用する例外と、最後に適用するフォールバックに分けます。優先する必要がある社内ドメインは、幅広いルールより前に配置してください。最後の MATCH は残りのトラフィックを受ける役割に限ります。マージ機能によってローカルリストがサブスクリプションの後ろに追加される場合、サブスクリプションに MATCH がすでにあると、追加したルールは実行されません。マージ方法を変更するかルール順を明示的に組み直してください。末尾に似たルールを追加し続けても解決しません。
サブスクリプションの更新後も動作を再確認する
更新後は、配布元が正常に読み込まれているか、グループの参照先が存在するか、先行ルールが想定した位置にあるかを確認してください。サブスクリプションに新しい項目が追加されても、古い上書き設定によって項目全体が置き換えられる場合があります。ローカルに保存されたグループ選択が、すでに削除されたノードを参照している可能性もあります。問題の切り分けでは、まず個人用の上書きを無効にして元のサブスクリプションが動作するか確認し、その後、設定を少しずつ戻すと競合を特定しやすくなります。
クライアントで最終設定を確認しにくい場合は、少なくとも読み込みログ、ノード一覧、重要な接続のルール記録を保存してください。古いスナップショットへ戻す際は、ノードの認証情報がすでに無効になっている可能性にも注意しましょう。設定を読み込めることと、古いノードを使えることは別です。通常の操作ではクイックスタートガイドのインポート・接続手順をご覧ください。この章は、更新後にマージ結果を再確認する理由を説明するもので、接続のたびにファイルを手動編集するよう求めるものではありません。
08 · 外部コントローラーと保守の流れ
管理インターフェースはプロキシポートではない
external-controller はコアの管理インターフェースを提供し、ステータスの取得、ポリシーの切り替え、各種管理操作に使われます。HTTPやSOCKSのリクエストを受け付けるmixed-portとは異なり、DNSの待ち受けポートでもありません。プロキシポートをパネルの接続先に指定しても、管理機能は利用できません。コントローラーポートをネットワークプロキシとして設定しても、正しい転送経路にはなりません。
コントローラーはネットワークの動作に影響を与えられるため、初期設定ではループバックアドレスにバインドし、ローカルからのみアクセスできるようにしてください。別のデバイスから管理する必要がある場合は、まずアクセス範囲を設計し、そのうえで待ち受けアドレス、認証、通信の保護、ファイアウォールを検討します。スマートフォンからパネルを開くためだけに全NICへインターフェースを公開し、推測しやすいサンプルパスワードに頼るのは危険です。コントローラーの情報が漏れると、ステータスの閲覧だけでなく、実行中の選択を変更される可能性もあります。
ローカルパネルと認証の設定
以下の例では、ループバックでの待ち受けとローカルパネルのディレクトリを示します。your-password は説明用の例です。実際に有効にする際は、自分で生成した強度の高いキーに必ず置き換えてください。実際の値を公開の質問投稿に書かないでください。external-ui は準備済みの静的パネルファイルのディレクトリを指定します。パネルのファイルがない場合、この項目だけで利用可能なページが自動的に表示されるわけではありません。
external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./uiクライアントにパネルやコントローラーの設定が組み込まれている場合は、ローカル上書きと画面設定が競合しないよう、クライアントの管理機能を優先してください。管理インターフェースを手動でテストする場合は、信頼できるローカル端末からリクエストを送信できます。以下のコマンドはキーを対話形式で読み込み、シェルの履歴に実際の値を残しません。使用後は、現在の端末の環境変数を消去します。
read -r -s -p "コントローラーのキー: " MIHOMO_SECRET
printf '\n'
curl --fail --silent --show-error \
-H "Authorization: Bearer $MIHOMO_SECRET" \
http://127.0.0.1:9090/configs
unset MIHOMO_SECRETこのコマンドはBash環境向けです。ほかの端末では、それぞれの安全な入力方法を使用してください。キーの読み込みに成功すれば、現在の端末からコントローラーまでの接続経路が使えることを確認できますが、ブラウザーのパネルも同じ条件で利用できるとは限りません。ブラウザーではページのオリジン、混在コンテンツ、クロスオリジン制御、ネットワークアドレスなどの制約も受けます。インターフェースへの接続とページの表示は分けて確認してください。
リモートアクセスではアドレスの意味を確認する
パネルページの 127.0.0.1 は、ブラウザーを開いているデバイスを指し、コアを動かしているリモートホストを指すものではありません。別のPCからパネルへアクセスする際にループバックアドレスを入力すると、ブラウザーは自分自身への接続を試みます。安全性の高いリモート管理方法として、管理された暗号化トンネル、または認証とアクセス制限を設定したリバースプロキシを使用し、コアのコントローラーはローカルで待ち受ける状態を保つことをおすすめします。
リバースプロキシを使う場合は、通常のHTTPリクエストとWebSocket接続の両方を確認してください。接続一覧やログでは、通信が継続している必要があります。ページは開けるのに状態が更新されない場合、プロキシがUpgradeヘッダーを転送していない、認証設定が一致しない、ブラウザーが接続を遮断しているなどの原因が考えられます。クロスオリジンの許可範囲は必要なページのオリジンに限定してください。エラーを消すために無条件で許可範囲を広げないでください。
パネルの静的ファイルも保守対象です。更新元を明確にし、アップグレード前に動作中のファイルと設定を保存して、更新後はログイン、ポリシーの切り替え、ログ接続をテストしてください。コントローラーにはアクセスできるのに新しいパネルが正常に動作しない場合は、コア設定全体を変更する前にパネルファイルを元に戻してください。クライアント内蔵パネルはクライアントが一括管理するため、更新方式に従い、手動置き換えによるパスの競合を避けてください。
変更内容を検証できる記録にまとめる
設定後は、変更した項目、期待する動作、新しい接続での検証方法、失敗時に戻すファイルを簡潔に記録してください。プロキシグループでは最終的なアウトバウンド、ルールセットでは適用順、DNSでは問い合わせ経路、TUNでは取り込み口とルーティング、パネルでは認証とアクセス範囲を検証します。このような記録は、出所のわからない設定画面のスクリーンショットを大量に保存するより、長期的な保守に役立ちます。
異常が起きたら、同じ順序で確認します。まず設定の読み込み、次にトラフィックの取り込み、その後に名前解決、ルール、アウトバウンドを確認してください。パネルに接続できないからといって、すぐにノード障害と判断しないでください。ウェブページが開けない場合も、コントローラー設定をすぐに変更しないでください。症状から解決方法を探すにはヘルプセンターをご覧ください。クライアントを変更する場合は、ダウンロードページでプラットフォーム別の入手先を確認できます。保守では各レイヤーの役割を明確にし、すべての変更を説明、検証、復旧できる状態に保つことが重要です。