On this page
When a page opens but images or login fail, find the actual domain of the failed request rather than adding a rule only for the address in the browser bar. A change also depends on rule order, whether the selected policy exists, and whether a subscription update will overwrite it. Write a few custom rules directly; use rule sets for large lists that need ongoing updates.
Only Part of a Page Fails: Which Domain Should the Rule Match?
A page may request its main domain, login domain, image CDN, and API separately. Rules match the domain, IP, or process in the actual connection; the address shown in the browser may not identify the resource that failed.
Keep Rule mode and find the failed request in Connections. Pin a verified working node when proxying is required. Compare the current and intended policies, change only the rule needed for that request, then send it again. A request intended to connect directly does not require a proxy node.
Connection Information Needed to Change a Rule
- The failing connection's full domain or destination IP
- The rule type and rule content currently shown
- The policy group or DIRECT action ultimately used
- The policy this connection should actually use
Rule Order: Put Specific Conditions Before Broad Rules
Mihomo checks rules from top to bottom and stops at the first match. Specific conditions usually belong before broader rules.
The api.example.com placeholder illustrates rule order; it cannot test your actual service. In an existing Profile, use the real domain recorded in Connections and a target group already defined in that profile. Group names must match exactly. Select a working node in the group when proxying is required; use DIRECT only when you intend a direct connection.
proxy-groups:
- name: 代理选择
type: select
include-all: true
proxies:
- DIRECT
rules:
- DOMAIN,api.example.com,代理选择
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,代理选择After applying the change to your own profile, save and reload it, close pre-change connections, and request the real destination again. In Connections, check the real domain, newly matched rule, and final outbound route. If the old result remains, check connection reuse and whether the active Profile loaded the change.
Add a rule in Clash Verge Rev and check that it survives an update
Direct edits to a remote subscription file may be overwritten by the next update. To keep custom rules, use the client’s rule override feature to add them when the subscription is loaded.
The steps below use Clash Verge Rev. Right-click the active subscription card and open Edit Rules. Add the rule to the prepend list, before the subscription’s broader rules and MATCH. For other clients, follow their own documentation.
Apply a custom rule and keep it through subscription updates
Record the real request and intended result
Find the failed request’s domain and matched rule in Connections, then decide whether it should connect directly or use an existing policy group.
Check the target policy is usable
Use a group name already defined in the current Profile. When proxying is required, select a working node within that group. Seeing a group name alone does not prove the request used a proxy.
Add a prepended rule
In Clash Verge Rev, right-click the active subscription, open Edit Rules, and add an entry. For an exact domain match, choose DOMAIN, enter the domain recorded in Connections, choose an existing group or DIRECT as the policy, and select Prepend Rules as the position. Use the relevant documentation for other clients; do not overwrite the remote subscription cache.
Reload and send a new request
Close connections opened before the change, repeat the same action, and read the newly matched rule and final outbound route. Check that the resource that actually failed now works.
Check again after updating the subscription
Update the current subscription manually, send a new request, and check the same rule, actual outbound route, and page result. If it fails, disable the newly added override and retain the working original profile.
Only when both requests match the same custom rule have you proven both “works now” and “survives an update.” Finding the text in the editor does not mean it has entered Mihomo's runtime configuration.
prepend-rules in older guides and the current rule editor
Older guides may use prepend-rules to add custom rules before the subscription’s rules. The example below is only for recognizing that syntax; the note explains the current editor and field limitations.
prepend-rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,intranet.example,DIRECTUse rule-providers when you need maintained lists
For a few custom rules, save them using an override supported by your client and check that they survive a subscription update. For larger lists maintained by a project, store the rule data in rule-providers and reference it with RULE-SET. The target in rules still determines the policy used after a match.
A provider supplies rule data; it does not choose a node on its own. In the example, “RULE-SET,work-domains,代理选择” sends matches to the already defined “代理选择” group. If you use your own group name, it must match exactly in proxy-groups and 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 and format: list contents, file formats, and allowed combinations
rule-provider behavior
| Value | What the file contains | What does not belong in the file |
|---|---|---|
| domain | Collections of domains, domain suffixes, and similar domain entries | IP ranges and complete classic rule lines |
| ipcidr | IPv4 / IPv6 CIDR | Conditions such as DOMAIN and PROCESS-NAME |
| classical | Typed matching conditions, such as DOMAIN-SUFFIX,..., without an outbound policy | Overly verbose when you only want to maintain plain domains |
behavior defines the list’s contents, while format defines the file format. yaml, text, and mrs cannot be combined arbitrarily: mrs supports only domain and ipcidr, not classical. Check the rule source’s documented behavior and format against its actual contents. A successful download does not prove that the combination is correct or that the file has loaded.
Do not infer the format from the URL suffix. After a rule source changes formats, the client may still have an old cached file. Use the provider name and parsing error in the logs to identify what is being loaded.
Ruleset Download Failures: Address, Interval, Proxy, and Cache
- type
- http updates from a remote source, file reads a local file, and inline places content directly in the configuration.
- url
- Remote rule-source address; handle 401, 403, 404, and timeout according to the HTTP response.
- interval
- Update interval in seconds. Setting it too short only adds requests; it does not make the rules more accurate.
- proxy
- Specifies the proxy used to download the rule source; if the origin is reachable locally, the configuration can also connect directly.
- path
- Cache-file path. Mihomo limits it to HomeDir by default; external paths require SAFE_PATHS.
When a provider download fails, the old cache may still be used, so “the website still opens” does not mean today's update succeeded. Check the provider's latest update time and logs. Keep the old cache until the new source recovers instead of deleting every rule file.
Rules Have No Effect: Download, Format, Reference Names, and Order
provider download 401 / 403 / 404
Address the remote address, permissions, or a migrated path; rule syntax is not involved yet.
provider parse error
Compare behavior and format with the source file's actual contents.
RULE-SET not found
The name referenced in rules does not match the key in rule-providers.
proxy group not found
The rule's target group is missing from the current subscription or has been renamed.
The rule loads but an earlier rule always matches
Reorder the rules so that specific ones come before broad rules and MATCH.
Custom entries disappear after a subscription update
Stop editing the remote file directly; use an override attached to the current Profile.
Check Other Connections on the Same Page After Adding a Rule
The more rules you add, the more opportunities they have to shadow one another. After verifying the target domain, check whether the other connections on the same page still use direct or proxied routing as intended. If you need only three rules, there is no reason to import a list with tens of thousands of entries from an unknown source.
Keep a record of each added rule’s domain, matching condition, and target group so references can be checked after node or Profile names change.