Router and Bypass Router Clash Deployment Overview: OpenWrt, Raspberry Pi Options, and DNS Interception

Choose the topology first: main router or bypass router

Putting Clash Meta (now commonly known as mihomo) on a home network is very different from running a desktop client on a computer. A desktop client usually handles only local traffic; a router setup must also handle forwarding, policy routing, DNS, IPv4, and IPv6, while preventing the proxy from intercepting its own upstream connections. Map the traffic path before deployment—it matters more than installing a plugin first.

Option 1: Run the Clash core on the main router

The main router handles the WAN connection, DHCP, NAT, firewall, and transparent proxying. End devices naturally use it as their default gateway, so you do not need to change network settings one device at a time. With OpenWrt, for example, the router's LAN address might be 192.168.10.1, its DHCP pool 192.168.10.100–192.168.10.249, and DHCP can automatically assign 192.168.10.1 as both the client gateway and DNS server.

• Advantages: traffic enters through one point, so rules apply as soon as devices connect; guest networks and separate VLANs can also be managed independently.
• Limitations: the proxy, WAN connection, Wi-Fi, and NAT share the same CPU and memory, so a configuration error can affect the entire LAN.
• Best for: x86 OpenWrt systems with ample performance, compact software routers, or quad-core ARM64 router hardware.

Option 2: Run the Clash core on a bypass router

The bypass router and main router share the same LAN. Assume the main router is 192.168.10.1 and the bypass router is 192.168.10.2; the bypass router itself still uses 192.168.10.1 as its default gateway. Devices that need proxying use 192.168.10.2 as both their default gateway and DNS server. Traffic enters the bypass router first, passes through transparent proxy rules, and then reaches the internet through the main router.

This single-interface bypass router sends inbound and outbound traffic through the same Ethernet adapter. On a gigabit network, one internet transfer creates traffic in both directions on that interface, but this does not usually cut throughput in half by itself. Encryption throughput, rule matching, USB adapter quality, and the return path through the main router are more common bottlenecks.

Choosing between an OpenWrt plugin and a bare-metal Raspberry Pi setup

An OpenWrt plugin puts the core, subscription configuration, rule updates, firewall integration, and runtime logs in one management interface. A bare-metal Raspberry Pi setup typically runs the mihomo binary directly, then combines systemd, nftables, and dnsmasq into the full traffic path. Their core capabilities are similar; the main differences are maintenance and the level of detail available for troubleshooting.

OpenWrt plugin setup

Using the OpenWrt 24.10 series and the OpenClash interface as an example, the usual path is “Services” → “OpenClash” → “Profile Subscription.” Add the subscription URL and set the update interval, then open “Services” → “OpenClash” → “Plugin Settings” to choose the operating mode, DNS interception method, and access controls. Menu names may vary slightly between plugin versions, but the configuration logic is largely the same.

1. Check the device architecture, such as x86_64, aarch64_cortex-a53, or mipsel_24kc; the core binary must match it.
2. Reserve persistent storage. Rule sets, Geo data, logs, and multiple configuration files can use more than 80 MB, so older devices with only 16 MB of flash are unsuitable for storing large amounts of data long term.
3. Start in rule mode, then test TCP, UDP, and DNS separately; do not enable every experimental option at once.
4. In “Runtime Status” or “Debug Logs,” confirm that the configuration parsed successfully, transparent proxy rules were installed, and the DNS listening port is not already in use.

The plugin approach suits environments that want to manage subscriptions and access controls through LuCI. Before upgrading OpenWrt, record the plugin settings, configuration paths, and custom firewall rules, because firewall3 and firewall4 use different underlying implementations. Since OpenWrt 22.03, mainstream releases use firewall4 and nftables; many iptables commands from older tutorials cannot be copied directly.

Bare-metal Raspberry Pi or Debian setup

A Raspberry Pi 4B, Raspberry Pi 5, or small ARM64 computer running Debian 12 can serve as a bypass router. A 64-bit OS, wired networking, and a stable power supply are recommended. The Raspberry Pi 4B's built-in gigabit Ethernet is suitable for typical home connections; if you add a USB 3.0 network adapter, verify that its chipset driver is stable and monitor packet loss and reconnect logs.

With a bare-metal setup, place mihomo at /usr/local/bin/mihomo, use /etc/mihomo as the configuration directory, and keep it running under systemd. The service file below shows the required structure; in production, also create a dedicated user and grant it read/write access to the configuration directory:

[Unit]
Description=mihomo proxy core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

After saving it as /etc/systemd/system/mihomo.service, run systemctl daemon-reload, systemctl enable --now mihomo, and journalctl -u mihomo -n 100 in that order. Before adding transparent proxy rules, run mihomo -t -d /etc/mihomo to check the YAML syntax. If parsing fails, do not continue by installing firewall rules at boot; otherwise traffic may be redirected while the core is not listening, leaving the network offline.

Transparent proxying: REDIRECT, TProxy, and TUN compared

The key to a router deployment is not opening an HTTP or SOCKS port, but making rules work for TVs, game consoles, and IoT devices that cannot use manual proxy settings. Common approaches include REDIRECT, TProxy, and TUN. All three require correct exclusions for LAN addresses, the core's own connections, and proxy server addresses; otherwise proxy loops are likely.

REDIRECT: mainly for TCP

REDIRECT redirects TCP connections passing through the firewall to mihomo's transparent proxy port, such as redir-port: 7892. It is simple to implement and works well for first testing web and application traffic over TCP. It does not fully cover every UDP scenario that requires the original destination information, so voice calls, games, and QUIC may still require TProxy or TUN.

TProxy: handles TCP and UDP

TProxy typically uses a dedicated port, such as tproxy-port: 7893, and depends on policy routing, packet marks, and kernel modules. The firewall assigns an fwmark, then passes traffic to mihomo through ip rule and a local routing table. Transparent UDP proxying, DNS queries, and some real-time communications require more complete rules.

• Exclude loopback addresses, multicast addresses, LAN subnets, and router management addresses.
• Connections to proxy node servers must go directly upstream and must not re-enter the transparent proxy.
• Exclude mihomo's own traffic, or use routing marks to distinguish packets that have already been processed.
• Check that the kernel includes support for TPROXY, policy routing, and the relevant nftables features.

TUN: receives IP traffic through a virtual interface

TUN mode creates a virtual network interface through which mihomo receives IP-layer traffic. It is more common on desktop systems, but it can also be used on a bypass router; forwarding, routing, and DNS still need to work together. A basic configuration may include the following:

mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  strict-route: true

mixed-port: 7890 is for testing explicit HTTP and SOCKS proxying; transparent proxying uses a REDIRECT, TProxy, or TUN path. Bind the management interface to 127.0.0.1:9090 to avoid exposing it directly to the entire LAN. If other devices truly need access, use the firewall to allow only the management subnet and set a controller secret.

TUN's auto-route and auto-redirect can reduce manual rules, but that does not mean they are safe to enable directly in every router environment. OpenWrt plugins often already manage the firewall, and having the core write routes automatically as well can create conflicting control. During deployment, decide whether the plugin, a startup script, or mihomo itself owns routing, and keep only one source of control.

DNS interception: prevent leaks, poisoning, and resolution loops

Transparent proxying decides how connections are forwarded; DNS decides which address a domain resolves to first. If devices continue querying the main router or the ISP's DNS, rules may see only the destination IP, reducing domain-rule match accuracy. If DNS requests repeatedly re-enter through both proxy and direct paths, pages may hang and some domains may fail intermittently.

Recommended traffic path

The bypass router can have dnsmasq listen on LAN port 53 and forward requests to mihomo at 127.0.0.1:1053. Alternatively, the firewall can redirect TCP/UDP 53 requests from devices to other DNS servers back to the local host. mihomo's DNS module then chooses a direct or proxy resolver according to the domain rules.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

default-nameserver uses IP addresses and is mainly used to resolve the domains of DoH servers themselves, avoiding a startup dependency loop over which comes first: the domain or DNS. nameserver is the actual query entry point. More complex configurations can use nameserver-policy to choose different resolvers for specific domains, but first confirm that basic resolution is stable.

Choosing between fake-ip and redir-host

fake-ip returns temporary addresses from a reserved pool, and mihomo restores the original domain from the mapping, making domain-rule matching more direct. The 198.18.0.1/16 range in this example is reserved for benchmarking and normally does not conflict with public addresses. Add LAN domains, printer discovery, NTP, and applications that require real IP addresses to fake-ip-filter.

redir-host returns real DNS results and offers a more straightforward compatibility path, but transparent proxying may rely more heavily on sniffing or IP rules. If LAN device discovery fails, do not immediately disable all DNS interception; first check the target domain and add a precise filter entry.

IPv6 requires separate testing

Taking over IPv4 while continuing to advertise an IPv6 default route can let IPv6-capable applications bypass existing policies. The answer is not simply to delete all AAAA records. Choose based on network capability: proxy IPv6 fully, allow selected IPv6 ranges to connect directly, or stop advertising an IPv6 default route to the test network until support is ready. At minimum, perform separate A and AAAA queries and test one IPv4-only site and one IPv6-capable site.

Bypass router rollout: from one-device testing to network-wide control

Bring a bypass router online in stages. Start with one computer, then expand to a dedicated device group; this is easier to troubleshoot than changing DHCP for the entire network at once. The examples below continue to use main router 192.168.10.1 and bypass router 192.168.10.2.

1. Assign a fixed bypass router address: Set the LAN address to 192.168.10.2/24 and the default gateway to 192.168.10.1. Keep the address outside the main router's dynamic DHCP range.
2. Enable IP forwarding: On Linux, check sysctl net.ipv4.ip_forward; the result should be 1. Check the corresponding IPv6 setting separately if IPv6 forwarding is required.
3. Test ordinary forwarding: Leave Clash disabled for now and set the test computer's gateway to 192.168.10.2. If it cannot access the internet, fix routing, NAT, or the return path first; do not blame the proxy configuration.
4. Test the explicit proxy: After starting mihomo, manually set the test computer's HTTP or SOCKS proxy to 192.168.10.2:7890 and confirm that the node, subscription, and rules work.
5. Enable transparent proxying: Start with TCP, then test UDP. Watch the logs for the inbound type, destination address, matched rule, and final proxy group.
6. Take over DNS: Set the test computer's DNS to 192.168.10.2, then use nslookup or dig to check the responding server, latency, and A and AAAA results.
7. Expand the scope: Once stable, assign the bypass router's address as the gateway and DNS server for selected devices through the main router's DHCP, or use a VLAN to take over one test subnet only.

Record concrete measurements during testing. Wired LAN latency to the bypass router should generally stay below 1 ms; if the first DNS query consistently takes more than 2 seconds, check the DoH connection, upstream routing, and loops. After changing rules, run 20 consecutive resolution and connection tests to confirm there are no intermittent timeouts. A speed test shows throughput at one point in time; it does not replace packet-loss, latency, or sustained-connection testing.

Two ways to assign settings through DHCP

• Network-wide assignment: Set DHCP option 3 to 192.168.10.2 as the default gateway and option 6 to 192.168.10.2 as the DNS server. This suits networks where the bypass router is already stable.
• Per-device assignment: Create static leases for the test computer, TV, or game console and assign the bypass router as their gateway and DNS server. Office and management devices can continue using the main router.

Some home routers allow only one gateway assignment for the entire network and cannot set it per device. In that case, configure test devices manually or create a separate guest network. Do not combine double NAT, bridging, and policy routing to patch the same problem; the more layers the path has, the harder an inconsistent return path is to diagnose.

Common failures and troubleshooting order

The device can reach the bypass router but not the internet

Stop mihomo and the transparent proxy rules first, then check basic forwarding. Confirm that the bypass router's default route points to the main router, IP forwarding is enabled, and the main router knows how to return traffic to the client subnet. A single-interface bypass router usually remains on the same /24 subnet; with a separate subnet, add a static route on the main router or perform source NAT on the bypass router.

Web pages open, but games or voice calls fail

This usually means the TCP path works but UDP is not entering the proxy, or the proxy node does not support the required UDP traffic. Check whether TProxy or TUN is enabled, whether UDP rules were installed, whether the firewall loaded the required modules, and whether UDP inbound traffic appears in the connection logs. QUIC uses UDP 443; disabling browser QUIC can help isolate the issue, but it is not a substitute for correct UDP configuration.

Mainland China sites take a longer route, or LAN devices cannot be reached

Check the rule order. LAN subnets, router management addresses, and private addresses should connect directly before the fallback proxy rule. Rules are matched from top to bottom, and the final MATCH rule receives every request that matched nothing earlier. If LAN domains use .lan or .local, also check fake-ip filtering and local DNS forwarding.

A brief loss of connectivity after reboot

The firewall rules may load before mihomo finishes parsing its configuration and initializing DNS. The systemd service should wait for network-online.target, and the firewall script should take over traffic only after the core's listening ports are available. Also confirm that the configuration, Geo data, and cache are stored persistently rather than in temporary directories cleared on reboot.

High CPU usage or a noticeable throughput drop

First distinguish encryption performance, rule processing, and log writes. Keep the log level at info, switching briefly to debug only for troubleshooting; check for large numbers of regular-expression rules, continuous connection sniffing, or repeated DNS queries. On a gigabit connection, a low-frequency dual-core router may hit a single-core bottleneck first; normal memory usage does not mean forwarding performance is sufficient.

Deployment takeaway: get routing right before adding rule features

A main-router OpenWrt deployment provides one unified entry point and suits networks with capable hardware that want centralized policy management. An OpenWrt bypass router keeps LuCI and plugin management while allowing devices to switch back to the main router during failures. A bare-metal Raspberry Pi or Debian setup provides clearer control over systemd, nftables, and logging, making it a good fit for users willing to maintain a Linux networking stack.

Whichever approach you choose, follow this order: verify ordinary Layer 3 forwarding, test the 7890 explicit proxy, enable TCP transparent proxying, add UDP and DNS, then handle IPv6 and network-wide DHCP assignments. Clash Meta or mihomo is only one component in the traffic path; stability ultimately depends on the gateway, return path, firewall, and DNS remaining consistent.