Why Routing Misses Expectations: From Rule Matching to Geosite Checks

“The rule did not work” is not one problem

When users say a routing rule failed, the real cause could be any of the following:

• the target never matched the expected rule
• the rule matched, but a later policy group selected something else
• DNS, TUN, or a rule provider rewrote the path
• the GEOSITE, GEOIP, or remote rule-set data itself does not match expectations

That is why routing should be debugged by layer.

Separate Clash / Mihomo from sing-box

Both perform routing, but the config structures differ enough that the debugging path should also differ.

Clash / Mihomo

Start by checking:

• rules
• proxy-groups
• tun
• dns
• rule-providers

For a target address, confirm the matched rule and the final policy-group chain.

sing-box

Start by checking:

• route.rules
• rule_set
• outbounds
• selector
• urltest
• dns

The key question is not only which rule matched, but also which outbound was chosen at the end.

Pull geosite issues out into a dedicated step

If the rule references GEOSITE,category-name, the problem may not be in the main config at all. It may be inside the geosite dataset.

Use Geosite.dat Inspector to confirm:

• the category really exists
• the target hostname is actually included
• the dataset version matches what you expect

Separating geosite verification from main-config debugging usually saves time.

A more stable debugging sequence

1. identify whether the config is Clash / Mihomo or sing-box
2. run the target through the corresponding route inspector
3. confirm the matched rule, chain, and final outbound
4. if GEOSITE or remote rule sets are involved, inspect the data source separately
5. only then go back and edit routing rules or node policy

Example: a domain expected to use a proxy matches a direct rule

Suppose you are inspecting example.com and the result matches DOMAIN-SUFFIX,example.com,DIRECT, while you expected a proxy group:

1. Load the actual config into Clash / Mihomo Route Inspector, enter the domain and identify the matched rule and its position.
2. Check whether the intended proxy rule appears after the direct rule. An earlier domain rule that also matches may already determine the destination.
3. Keep a copy of the original config. Change only the relevant rule order or match scope, then analyze the same domain again and compare results.
4. If analysis now selects the expected group but real traffic still fails, confirm that the client loaded the updated config. Inspect the group’s selected node and the connection log.

The domain is illustrative. Static rule analysis does not replace runtime DNS, remote rule-set loading or connection tests in the client.

Recommended Tools and Follow-Up Reading

• Start directly with Clash / Mihomo Route Inspector, Sing-box Route Inspector, and Geosite.dat Inspector.
• If the routing issue still looks like bad source data, go back to A Practical Workflow from Node Inspection to Subscription Delivery.
• If the final goal is a reusable client subscription, continue with How to Turn Conversion Results into Stable Subscription Links.