Browse user guides
Daily use

Whitelists, domestic direct access, and traffic exceptions

Send selected domains or IPv4 addresses around normal routing rules through direct, WAN, VPN, node-group, or single-node paths.

Difficulty
Advanced beginner
Reading time
11 min
Verified version
V7.2.13 development and later
Updated
08/24/2026

Whitelists are exceptions to ordinary routing rules. Keep the list narrow and verify each exception from a test device before applying it to a larger subnet.

What you can configure

  • Domain entries or IPv4 entries.
  • Direct access, a WAN or VPN interface, one node, or a node group.
  • Domestic-address direct access as a separate policy.
  • Traffic exceptions for services that should not use the normal group.

Before you start

  • Record the current rule and DNS behavior.
  • Decide whether the exception is for a domain, an IP, or both.
  • Keep one test device and one management device outside the change.
  • Confirm that a strict kill switch will not block an intentional direct path.

1. Add a narrow whitelist entry

Open the whitelist settings and add one domain or IPv4 address. Use the smallest matching value: a hostname for a service, or a CIDR/IP only when the service requires it. Avoid adding a broad public suffix unless every subdomain should follow the same path.

Ordinary domain entries can be written as a hostname or a wildcard:

example.com
*.example.com
login.example.net

For a service on a non-default port, use an explicit protocol URL:

https://*.example.com:7003
http://api.example.com:7001
quic://game.example.com:9443

Only http, https, and quic are accepted. The format must be scheme://domain:port without a path, query, fragment, credentials, or an IP address. The entry matches only when both the sniffed domain and destination port match. For example, https://*.example.com:7003 does not match the same domain on port 443.

2. Select the destination

Use DIRECT for local direct access, a node name for one node, or Group_<name> for a node group. If the UI exposes a route interface, select the exact WAN, L2TP, or PPTP line. Whitelist entries do not use the Interface: prefix unless the specific UI field says it is a routing-rule target.

3. Verify the exception

From the test device, access the exact domain and check the public IP. Compare it with an ordinary domain that still follows the main rule. If the result is cached, open a new connection or use a fresh test request.

For an explicit port entry, reconnect to the exact protocol and port after saving. Test the same domain on another port as a control. A port entry extends only the corresponding Mihomo sniffer: http extends HTTP sniffing, https extends TLS sniffing, and quic extends QUIC sniffing.

4. Configure domestic direct access carefully

Domestic direct access changes the destination selection for matching addresses; it does not automatically make every overseas service direct. Test one known domestic address and one overseas address. Under strict protection, a direct path that is not explicitly allowed may be blocked.

Domain whitelists require the domain recognition engine. It is disabled by default. Enable it under Advanced settings → Traffic policy before testing a domain whitelist. Explicit protocol-port entries add only their declared ports to the matching sniffer; a connection without a Host, SNI, or usable DNS mapping cannot match a domain rule by IP alone.

5. Remove or narrow an exception

If a whitelist entry is too broad, replace it with a host or smaller CIDR. After deletion, verify that the normal rule resumes. A stale connection can make a removed entry appear active for a short time.

Common problems

The entry saved but traffic did not change

Check spelling, DNS resolution, rule order, and whether the device is using a cached connection. Confirm that the selected destination is healthy.

Domain entry fails but IP entry works

Check the domain recognition engine, DNS mode, and whether the application uses a different hostname or an encrypted resolver. For a non-default port, verify the scheme://domain:port syntax, the actual protocol, and the exact destination port. Test the actual hostname shown in the request rather than a parent domain.

An explicit protocol-port entry does not match

Confirm that http, https, or quic matches the actual protocol and that the destination port is exact. Reconnect after saving because an existing long-lived connection may not trigger a new sniff. If the connection has no Host, SNI, or usable DNS mapping, Mihomo cannot infer the whitelist domain from the destination IP alone.

A node target still uses direct access

Confirm that the whitelist field accepts a node or group target and that it is not being overwritten by a higher-priority domestic-direct policy.

Domestic direct access affected an overseas service

Remove the broad address range, add a specific exception, and retest the domestic and overseas control domains separately.

The old egress remains after deletion

Close the application connection, clear its DNS cache if appropriate, and run a new public IP check. Then inspect the active rule again.