一度読み込み、更新元ごとに管理
クライアントの設定画面でサブスクリプションURLを貼り付けて読み込み、成功したら使用する設定として選択します。リモート設定の更新ではYAMLを再取得します。プロキシプロバイダーとルールプロバイダーは、それぞれ設定した間隔で更新できます。この3種類の更新は別々に考える必要があります。ローカルファイルはオフラインでのバックアップに便利ですが、通常はリモートの変更が自動反映されません。ダウンロードした設定を直接編集すると、次回の更新で上書きされることがあります。変更を維持するには、クライアントのオーバーライドまたはマージ機能を使いましょう。更新に失敗した場合は、まずURLが有効か確認し、リクエストログとサブスクリプション取得時のネットワーク経路を調べてください。
サブスクリプションの読み込み手順を見る →
# 設定ファイルのプロキシプロバイダー設定例
# interval の単位は秒
proxy-providers:
remote:
type: http
url: "https://example.com/proxies.yaml"
path: ./providers/remote.yaml
interval: 86400
ルールの順序でマッチ結果が決まる
ルールモードでは、設定リストを上から順に照合し、最初に一致したルールのポリシーを適用します。そのため、特定のドメイン向けルールは広範囲に一致するルールより前に、フォールバックルールは末尾に配置します。ルールの振り分け先には、DIRECT、REJECT、定義済みのプロキシグループなどを指定します。任意の文字列は指定できません。グローバルモードと異なり、ルールモードではアプリごとに異なる経路へ振り分けられますが、動作はドメインの識別方法、名前解決の方式、ルールリソースの状態に左右されます。変更後は新しい接続を作成し、接続画面でマッチしたルールを確認してください。Webページが開くかどうかだけで判断するのは避けましょう。サブスクリプションに含まれるルールとローカルのオーバーライドを統合した最終的な順序も確認してください。
ルールとオーバーライドの解説を見る →
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- DOMAIN-SUFFIX,example.org,REJECT
- MATCH,DIRECT
モードと通信の取り込みは別々の設定
ルールモードはルールリストに従って通信を振り分けます。グローバルモードでは、コアに届いた接続をグローバルポリシーで処理し、ダイレクトモードでは接続先へ直接アクセスします。これらが決めるのは、接続がコアに入った後の処理方法です。アプリがクライアントを使うかどうかを決めるものではありません。システムプロキシはシステムのプロキシ設定に従うアプリに作用し、TUNは仮想ネットワークインターフェースを通じてより多くの通信を取り込みます。Webページが開かない場合は、まずアプリのリクエストが接続画面に表示されるか確認し、その後でモードとプロキシグループを調べましょう。グローバルモードに何度切り替えても、コアに届いていないリクエストは解決できません。確認後は普段使うルールモードに戻し、一時的な調査設定をそのままにしないようにしてください。
プロキシモードと通信の取り込み方法の違い →
# 3つのモードから1つを選んで設定
mode: rule
# システムプロキシとTUNはクライアント内の独立した設定
# グローバルモードは mode: global に対応
# ダイレクトモードは mode: direct に対応
より広範囲の通信を取り込む場合にTUNを有効化
ゲームやコマンドラインツール、バックグラウンドサービスの中には、システムプロキシを参照しないものがあります。TUNは仮想ネットワークインターフェースとルーティング設定を使い、こうした通信をコアに取り込めます。有効にする前に、クライアントに必要な権限があること、別のVPNが同時にデフォルトルートを変更していないことを確認してください。自動ルート設定とDNSの取り込みは相互に関係するため、スイッチをオンにしただけですべてのプロトコルが正常に動くとは限りません。アプリにプロキシポートを手動設定する方法よりもTUNは適用範囲が広い一方、ネットワークインターフェース、LANのルーティング、セキュリティソフトの影響を受けやすくなります。まず通常のWeb接続を確認し、その後TUNを有効にして項目ごとにテストしてください。競合が発生したら、通信の取り込みを停止してネットワークを復旧し、ログから原因を特定しましょう。
TUNの設定とトラブル対処の手順を見る →
# mihomo の設定例。該当するシステム権限が必要
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
Fake-IPを変更する前に名前解決の経路を確認
DNSはドメイン名をIPアドレスに変換します。名前解決の経路は、コアがドメインを正しく識別してルールに照合できるかにも影響します。Fake-IPは予約済みアドレスを使ってドメインとの対応付けを行うもので、新しいネットワーク出口を提供する機能ではありません。通信の取り込み方法と組み合わせて使う必要があります。実IPアドレスを返す方式に比べ、Fake-IPはドメインとの関連付けを維持しやすい一方、LAN内のサービスや一部のアプリでは除外設定が必要です。名前解決に問題がある場合は、まずDNSリクエストがコアに届いているか、上流DNSサーバーに接続できるかを確認し、その後でアプリのキャッシュやOSの暗号化DNS設定を調べてください。上流サーバーの変更、モードの切り替え、除外リストの編集を同時に行うと、どの変更が効果をもたらしたのか判断しにくくなります。
DNS設定の解説を見る →
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost"