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