Running Mihomo on a home router or bypass router is not primarily about installing a desktop client on every device. The goal is to place proxy capabilities near the LAN gateway, allowing the network device to handle eligible connections centrally. This can cover TVs, game consoles, speakers, home servers, and other devices where installing a Clash client is impractical. It also concentrates configuration, forwarding, DNS, and troubleshooting on a single network node.
In practice, “router deployment” can refer to two completely different designs. In one, Mihomo runs directly on the main router that serves as the home gateway. In the other, a second device acts as a bypass router alongside the main router, with gateway settings, policy routing, or manual configuration directing some clients’ traffic through it. Both designs can provide transparent proxying, but their packet paths, outage impact, and maintenance requirements differ.
Choose the deployment model first: run the kernel on the main router or split traffic through a bypass router
Run Mihomo directly on the main router
Running Mihomo directly on the main router means that Mihomo operates on the default gateway for the local network. Clients receive the main router’s IP address as their default gateway through DHCP, so packets naturally reach that device first when accessing external networks. During forwarding, the router can pass traffic to Mihomo’s transparent proxy entry point, after which Mihomo determines the next hop according to its rule mode, proxy groups, and proxy nodes.
The advantage is a simple topology: the default gateway, LAN DHCP, DNS forwarding, and proxy service all run on one device, and rule coverage is straightforward. The drawback is that the main router has more responsibilities and the kernel consumes CPU, memory, and connection-table resources. A failed configuration update, router reboot, or crashed Mihomo process may affect the entire home network. Before modifying the main router, users with limited hardware, closed vendor firmware, or little experience with router startup services should confirm that the changes can be rolled back.
Run Mihomo independently on a bypass router
A bypass router is usually a second device on the LAN, such as a small computer running Linux, OpenWrt, or another router operating system. The main router continues to handle the WAN connection, wireless access, and DHCP, while the bypass router runs Mihomo and the required transparent-proxy components. Clients can use it in three common ways: make it the default gateway; point DNS to it and combine that with transparent forwarding; or manually configure the gateway and proxy entry point for selected devices only.
The value of a bypass router is risk isolation. The main router keeps its existing configuration, and devices that do not use the bypass router can still access the internet through the main router if the bypass router stops working. It also supports gradual testing: start with one computer, then expand to a TV, home server, or guest network. A bypass router does not automatically intercept all traffic, however. If clients still use the main router as their default gateway and the main router does not forward relevant traffic to the bypass router, Mihomo cannot see those connections.
Understand transparent proxying: traffic interception does not mean every connection is automatically proxied
A desktop client’s system proxy typically writes an HTTP, HTTPS, or SOCKS proxy address into the operating system or application settings. Applications that honor those settings send connections to the specified port; programs that do not support system proxies may bypass them entirely. Router-based transparent proxying works differently. It usually matches connections in the forwarding path and uses firewall redirection, policy routing, or TUN to pass traffic that would otherwise be forwarded directly to the proxy kernel.
Traditional transparent-proxy setups often rely on the system network stack and firewall rules. For example, TCP traffic can be redirected to a local transparent-proxy port as it passes through the router’s forwarding chain, after which Mihomo matches rules against the original destination address. UDP, ICMP, IPv6, and locally generated traffic may require separate handling. The fact that TCP websites open does not prove that every protocol has been intercepted.
TUN mode receives IP packets routed through a virtual network interface. The kernel processes TCP, UDP, and other connections from those packets, then completes forwarding with the configured DNS and routing settings. It is useful when more application protocols need coverage without configuring port redirection one item at a time, but it is more sensitive to system privileges, routing tables, DNS handling, and IPv6 settings. On a router, TUN availability also depends on kernel capabilities, permission to create virtual devices, and support in the installed Mihomo version.
Where a connection actually travels
- A LAN client resolves the domain name and uses its local routing table to determine the default gateway or DNS server.
- The packet reaches the main router or bypass router. If the bypass router is not the default gateway, additional forwarding rules are required to send traffic through it.
- The transparent-proxy entry point receives the connection. This may be a redirect port, a TProxy port, or a TUN virtual interface, depending on the system and configuration.
- Mihomo resolves the destination, handles DNS, and selects a direct connection, proxy, or policy group according to rule order.
- The connection leaves through a direct egress or proxy node, and the response follows a reachable return path back to the client.
If any link in this chain is missing, the symptom may simply be that “some websites do not open.” For example, the rules may select a proxy while the bypass router cannot reach the node; or the node may work while the client still sends DNS to the main router and receives an unsuitable address. Troubleshoot in order: first determine whether the connection reaches Mihomo, then identify the matched rule, and only afterward investigate the proxy node and remote network.
How Mihomo runs on a router: configuration, ports, and rules
Mihomo is the kernel implementation responsible for parsing configuration, matching rules, and establishing proxy connections. In a router deployment, at least three areas must be distinguished: kernel runtime parameters, the proxy configuration file, and system-level traffic interception rules. The configuration usually contains proxy nodes, proxy groups, rule sets, DNS, modes, and listening ports; the system layer sends client traffic to the correct entry point. Changing only one layer while leaving the other unsynchronized often produces an incomplete setup.
Configuration modes usually include Rule, Global, and Direct. For long-term home-network use, Rule mode is better for splitting traffic by domain, IP address, or rule set. Global mode can verify whether the proxy path works, while Direct mode helps determine whether a problem comes from the proxy node or rule selection. Changing modes only changes how Mihomo handles connections; it does not fix an incorrect default gateway, unreachable DNS, or a failed listening port.
Listening ports must also match the traffic type. HTTP and SOCKS ports primarily serve explicit proxy clients; transparent-proxy ports serve the system forwarding path; and the DNS listener handles domain-resolution requests. Do not use a regular HTTP proxy port as a transparent-proxy entry point, and do not start multiple services on the same port without checking for conflicts. On router systems, check the bind address as well: a listener bound only to loopback cannot be reached by LAN clients, while a listener bound to a LAN address should be protected with access controls.
mixed-port: 7890
mode: rule
allow-lan: true
external-controller: 127.0.0.1:9090
dns:
enable: true
listen: 0.0.0.0:1053The snippet above only illustrates how configuration options relate to one another; it is not a drop-in configuration for every router system. allow-lan permits LAN access to explicit proxy ports, but transparent proxying still requires forwarding on the system side. The DNS listening port must also match the router’s DNS-forwarding settings. The control-panel port should be restricted to the local machine or a trusted management subnet so that the management interface is not exposed to networks that do not need access.
Maintenance boundaries: subscription updates, DNS, IPv6, and fallback paths
Treat subscription updates separately
Subscription updates typically replace proxy nodes, policy groups, or rule-related content, but they do not understand your router topology automatically. If an updated configuration omits a policy-group name that existing rules depend on, those rules may target something that no longer exists. If the subscription provides nodes without complete DNS, TUN, or routing settings, the local configuration must still supply the missing transparent-proxy pieces. Save the currently working configuration before updating. Afterward, confirm that the file parses successfully and that the policy groups exist before testing with one client.
DNS is the easiest middle layer to overlook
Whether a client can open a domain depends on where its DNS request is sent and whether the returned address fits the active rules. The main router, bypass router, ISP DNS, encrypted DNS, and Mihomo’s built-in DNS may all participate. If the proxy connection itself works but domain resolution fails, test IP access, the LAN DNS port, Mihomo’s DNS listening port, and the domain-resolution strategy in the rules separately. Do not repeatedly switch proxy modes: changing modes does not change the DNS server the client actually uses.
IPv6 cannot be inferred from IPv4 behavior
After IPv6 is enabled on a home network, clients may prefer AAAA records and connect directly over an IPv6 default route. If transparent proxying is configured only for IPv4, some services may bypass the proxy or connections may take longer to establish. Check the IPv6 firewall, router advertisements, and Mihomo’s IPv6 capabilities as needed. If the IPv6 path has not been planned, you can temporarily disable IPv6 on a test subnet for comparison, but make clear that this is a network-policy choice rather than proof of a defect in the proxy kernel.
Keep a fallback path through the main router
When Mihomo runs directly on the main router, prepare a local management entry point, a known-good original configuration, and a way to disable transparent proxying. With a bypass-router setup, record the management addresses of both routers, DHCP ownership, and where the default gateway is changed. After changing the gateway or DNS distributed by DHCP, clients may retain an old lease and need to reconnect or renew it manually. Change one variable at a time whenever possible; avoid upgrading the kernel, replacing the subscription, and changing firewall rules simultaneously.
How to choose: weigh coverage, performance, and failure cost
If only a few devices need a proxy and those devices support a system proxy or Clash client, running the client on each device is usually easier for observing connections, rule matches, and logs. Router deployment is better when many types of devices need consistent coverage or the whole home network should follow the same traffic-splitting rules. Check hardware capacity first: insufficient memory can cause the system to terminate the kernel, while a weak CPU may add latency during heavy connection loads, rule-set parsing, and encrypted forwarding.
| Requirement | Recommended setup | Main considerations |
|---|---|---|
| Unified routing for all home devices | Mihomo on the main router or a bypass router used as the default gateway | Check DHCP, DNS, and both IPv4 and IPv6 paths |
| Test with a small number of devices first | A bypass router with a device-specific gateway | Keep the main router as the default exit and expand coverage gradually |
| Limited router hardware resources | A dedicated bypass router | Monitor memory, connection counts, rule-set size, and cooling |
| Browser proxy only | Explicit proxy on the client device | No need to change the home network’s forwarding topology first |
A reliable validation sequence is to confirm that the Mihomo process is running, then verify that the configuration file loaded successfully. Next, test the node connection from the bypass router itself, have one LAN client use the designated entry point, and only then push the gateway or DNS settings to more devices. Record the client IP, default gateway, DNS address, proxy listening port, and current mode at each step. If something fails, this makes it easier to determine whether the device bypassed the router, traffic never reached the transparent entry point, the selected rule was unexpected, or the node itself is unavailable.
Common symptoms and troubleshooting order
- No proxy effect on the client: Check the client’s default gateway first and confirm that it points to the device responsible for traffic interception. Then verify that the bypass router allows forwarding and that its firewall rules are loaded.
- Web pages open but an application fails: The application may use UDP, QUIC, its own DNS, or IPv6. Check the connection type and logs during testing instead of judging the setup solely by browser results.
- Proxy nodes are listed but all time out: Test connectivity from the router to the node server, and check the system time, outbound DNS, upstream firewall, and server addresses in the subscription.
- LAN devices cannot access one another normally: Check whether transparent proxying is incorrectly intercepting private-network addresses, and verify how the rules handle LAN ranges, reserved addresses, and management subnets.
- Configuration is lost after reboot: Check the startup service, mount paths, and configuration-file permissions. Confirm that the kernel starts after the network interfaces and storage mounts are ready.
Read logs together with packet captures or routing-table information. Seeing only “connection failed” is not enough to blame the node. If the logs contain no matching domain or destination address at all, the client probably never reached Mihomo’s entry point. Conversely, if a rule match and outbound connection are visible but the response times out, continue by checking the policy group, remote node, and return path.
Overall, deploying Mihomo on a router is a network-egress design task, not simply an application installation. Running it on the main router centralizes the path, while a bypass router separates responsibilities. Transparent proxying intercepts connections that pass through the designated node, rules determine how those connections are handled, and subscriptions mainly provide updateable nodes and configuration content. Clarify these boundaries first, then choose a design based on device count, hardware resources, and maintenance capacity for more predictable configuration and troubleshooting.