目次
実際に経路を誤っている一つの接続からルールを見直す
ルールはウェブサイトのトップページのタイトルではなく、実際の接続に含まれるドメイン、IP、プロセスなどの情報と照合されます。一つのページがメインドメイン、ログイン用ドメイン、画像 CDN、API へ同時にリクエストすることもあります。アドレスバーだけを見て一つのルールを書くと、ページの一部しか直らないことが少なくありません。
ノードを固定して Rule モードを維持し、失敗する操作を繰り返します。Connections で接続先、現在一致しているルール、出口を記録してください。修正すべきなのは「この接続がなぜ最初にここへ一致したのか」であり、インターネット上のルール表を丸ごと設定へ詰め込むことではありません。
変更前に残す四項目
- 失敗した接続の完全なドメインまたは接続先 IP
- 現在表示されているルールの種類と内容
- 最終的に使用されたポリシーグループまたは DIRECT
- この接続が本来使用すべきポリシー
Mihomo は上から順に照合し、最初に一致したルールで停止する
通常は、より具体的なルールを広いルールより前に置きます。次の例では api.example.com を、すでに定義済みの「プロキシ選択」へ渡し、より広い example.com のルールは DIRECT のままにします。末尾の MATCH は、それまで一致しなかった接続を処理します。
proxy-groups:
- name: 代理选择
type: select
include-all: true
proxies:
- DIRECT
rules:
- DOMAIN,api.example.com,代理选择
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,代理选择設定を保存して再読み込みしたら、古いページ接続を閉じ、新しいリクエストを送ります。Connections に DOMAIN,api.example.com と「プロキシ選択」が表示されれば、ルールと順序の両方が機能しています。以前の結果が表示されたままなら、接続が再利用されているか、現在の Profile にこの変更が読み込まれていない可能性があります。
同じ情報源の長いリストだけを rule-providers に任せる
ローカルドメインが数件だけなら、直接記述するルールのほうが読みやすくなります。あるプロジェクトが数十、数百のドメインや IP を保守し、定期更新が必要な場合に限り、rule-providers でデータソースとメイン設定を分離します。メインの rules から RULE-SET で provider を参照し、セット全体にポリシーを指定します。
provider はルールデータを提供するだけで、単独でノードを選ぶことはありません。例の「RULE-SET,work-domains,プロキシ選択」は、一致した結果を定義済みの「プロキシ選択」へ渡します。独自のグループ名を使う場合は、proxy-groups と rules の両方で完全に一致させてください。
proxy-groups:
- name: 代理选择
type: select
include-all: true
proxies:
- DIRECT
rule-providers:
work-domains:
type: http
behavior: domain
format: yaml
url: https://rules.example.com/work.yaml
path: ./ruleset/work.yaml
interval: 86400
rules:
- RULE-SET,work-domains,代理选择
- MATCH,代理选择behavior はファイルの内容と一致させる
rule-provider の behavior
| 値 | ファイルに含める内容 | ファイルに含めるべきでない内容 |
|---|---|---|
| domain | ドメイン、ドメインサフィックスなどのドメイン集合 | IP 範囲と完全な classic ルール行 |
| ipcidr | IPv4 / IPv6 CIDR | DOMAIN、PROCESS-NAME などの条件 |
| classical | DOMAIN-SUFFIX,... など、種類を含む完全なルール | 純粋なドメインだけを管理するには冗長 |
format はファイルのエンコード形式を示し、一般的な値には yaml、text、mrs があります。behavior と format は別の項目です。一方はルールの意味を、もう一方はファイルの保存形式を示します。純粋なドメインテキストを ipcidr として宣言すると、ダウンロードに成功しても読み込み時にエラーになります。
URL の拡張子から推測せず、まずルール配布元が公開している形式の説明を確認してください。配布元が形式を変更した後も、クライアントに古いキャッシュファイルが残る場合があります。ログ内の provider 名と解析エラーが確認の手掛かりになります。
ルールセットを更新できない場合は url、interval、proxy、path を確認する
- type
- http はリモートから更新し、file はローカルファイルを読み込み、inline は内容を設定内へ直接記述します。
- url
- リモートルール配布元のアドレス。401、403、404、timeout は HTTP の結果に応じて対処します。
- interval
- 更新間隔を秒単位で指定します。短くしすぎてもリクエストが増えるだけで、ルールの精度は上がりません。
- proxy
- ルール配布元のダウンロードに使用するプロキシを指定します。配布元へローカルから到達できる場合は、設定に従って直接接続することもできます。
- path
- キャッシュファイルのパス。Mihomo はデフォルトで HomeDir 内に制限し、外部パスには SAFE_PATHS が必要です。
provider のダウンロードに失敗しても古いキャッシュが使われる場合があるため、「ウェブサイトがまだ開く」からといって今日の更新が成功したとは限りません。provider の今回の更新日時とログを確認し、新しい配布元が復旧するまで古いキャッシュを残してください。すべてのルールファイルをいきなり削除しないでください。
リモートサブスクリプションは上書きされるため、カスタムルールはオーバーライドに入れる
Profiles ディレクトリへダウンロードされたリモート YAML を直接編集すると、その時点では機能しても、次のサブスクリプション更新で置き換えられます。Clash Verge Rev などのクライアントには、リモート設定の読み込み時にローカル内容を挿入するマージ、スクリプト、ルールオーバーライド機能があります。具体的な入口はバージョンによって異なるため、現在のクライアントの Profile オーバーライド画面を使用してください。
優先して実行する必要があるカスタムルールは、prepend または同等の前方マージを使い、サブスクリプションの広いルールより前に挿入します。MATCH の後ろへ追加しただけでは、ファイル内に見えていても実行時には決して到達しません。
prepend-rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,intranet.example,DIRECT再読み込み後は、エディターにその行があるかだけでなく、実行時に一致したルールを確認する
一つのオーバーライドルールを検証する
オーバーライドを保存して有効にする
使用中のリモート Profile に関連付けられていることを確認します。
設定を再読み込みする
ログに rule、provider、proxy group の解析エラーがないことを確認します。
古い接続を閉じる
変更前に確立されたセッションをブラウザが再利用しないようにします。
対象の操作を繰り返す
Connections で新しいルールと最終ポリシーを確認します。
サブスクリプションを手動更新する
更新後にもう一度リクエストし、オーバーライドが消えていないことを確認します。
二回のリクエストが同じカスタムルールに一致して初めて、「現在機能している」と「更新後も残る」の両方を確認できます。エディター内で文字列が見つかるだけでは、Mihomo の実行時設定に入った証明にはなりません。
ルールが機能しない場合は、ダウンロード、解析、参照、順序の四層を確認する
provider download 401 / 403 / 404
リモートアドレス、権限、移行済みパスを修正します。この段階ではルール構文は関係しません。
provider parse error
behavior、format と配布元ファイルの実際の内容を照合します。
RULE-SET not found
rules で参照する名前と rule-providers のキー名が一致していません。
proxy group not found
ルールの対象グループが現在のサブスクリプションに存在しないか、名前が変更されています。
ルールは読み込まれるが、常に前のルールへ一致する
具体的なルールが広いルールと MATCH より前に来るよう、順序を調整します。
サブスクリプション更新後にカスタム項目が消える
リモートファイルの直接編集をやめ、現在の Profile に関連付けたオーバーライドを使用します。
追加する各ルールで実行結果を説明できるようにする
ルールが増えるほど、互いを隠す可能性も高まります。対象ドメインを検証した後は、同じページの他の接続も想定どおり直接接続またはプロキシ経由になっているか確認してください。必要なのが三つのルールだけなら、出所不明の数万件を含むリストを導入する必要はありません。
最後に、実行結果を一文で説明します。どの接続がどの条件に一致し、どのポリシーグループへ入り、サブスクリプション更新後も同じ結果になったかを記録してください。説明できないルールはいったん追加しないほうが、後でノードや Profile の名前が変わったときも保守しやすくなります。