Running the Clash Core Directly on a Router: OpenWrt and Bypass-Router Deployment Explained
Run mihomo on a main or bypass router: firmware choice, transparent proxy, DNS hijacking, autostart, and comparison with desktop client setups.
Why move the Clash core onto a router at all
A desktop client only proxies traffic on the machine it's installed on. Phones, TV boxes, and consoles that want the same routing rules either need their own client installed—or simply can't run one at all. Deploying the mihomo core directly on a router pushes proxy capability down to the network gateway itself: every device on the home network gets rule-based routing automatically, with nothing to install anywhere. This matters most for multi-device households, smart TVs, and hardware that can't run apps at all (certain TV boxes, network-connected printers, and so on).
The cost is a configuration bar noticeably higher than any desktop client: you're dealing with firmware flashing, the transparent proxy chain, and DNS hijacking—fairly low-level territory where a single misconfigured step can knock the entire household offline. This isn't a good starting point if you're completely unfamiliar with the command line or basic networking. For day-to-day use on a single device, a desktop or mobile client's graphical setup is clearly less effort. The router route is only worth the investment once "every device in the house needs the same routing rules" becomes a hard requirement.
Two topologies: flashing the main router vs. adding a bypass router
Running the Clash core on a router splits into two main topologies. Figure out your hardware situation and appetite for tinkering before picking one.
Main-router route: flash your home router to OpenWrt
This approach reflashes your existing home router (or a model you buy specifically because it supports flashing) with OpenWrt firmware, then installs the mihomo core and its management plugins inside that firmware, letting the router itself handle all proxy forwarding. The upside is the shortest possible chain—no extra hardware needed, and every device on the LAN naturally passes through this router's egress. The downside is that it places real demands on the router's CPU and memory: running mihomo alongside rule matching and DNS resolution is a meaningful load for an entry-level router's processor, and if the original router isn't powerful enough, speeds can drop noticeably—or stutter outright—once the proxy is active. Flashing itself carries a bricking risk, so confirm which firmware versions your specific model supports ahead of time, and keep the stock firmware and flashing tools on hand for recovery.
Bypass-router route: add a small dedicated proxy gateway
The bypass-router approach leaves your existing router untouched (still handling basic connectivity as before) and adds a separate small device—dedicated to running the mihomo core—alongside it. By changing the gateway or DNS settings on other LAN devices, traffic that needs to be proxied is redirected to this bypass unit. Common hardware choices are a Raspberry Pi, a mini x86 box, or a second router flashed with OpenWrt, bridged into the existing network. This route doesn't touch the main router's firmware, so both the risk and the barrier to entry are lower than flashing the main router—and if the bypass unit ever runs out of headroom, you can upgrade just that piece of hardware without disturbing basic connectivity. For most households on the fence about "should I mess with my main router," the bypass-router route is the safer place to start.
Flashing third-party firmware usually wipes the device's existing configuration and can raise warranty concerns, so confirm your router model's support status on OpenWrt's official device list first, and back up the stock firmware image. The bypass-router route involves no flashing at all, which makes it a much lower-risk option worth trying first.
The transparent proxy chain: how the router takes over traffic
The core mechanism behind router-level proxying is transparent proxying—conceptually similar to a desktop client's system proxy or TUN mode, but implemented differently. The device itself (phone, TV box) has no idea its traffic is being proxied; it sends requests normally, and the router silently redirects that traffic at the network layer into the local mihomo process, which processes it and forwards it onward. The client device never notices, and there's no need to configure a proxy address on each individual device.
Transparent proxying relies on the router OS's traffic-redirection capabilities. On OpenWrt, the usual approach is firewall rules (iptables or nftables) that steer traffic on specific ports or protocols into the transparent proxy port mihomo is listening on, paired with the tproxy-port field (or similar) in the mihomo config. This layer is the easiest part of the whole setup to get wrong—a bad rule can leave devices connected to the internet as normal but with routing rules doing nothing at all, or conversely block all outbound traffic entirely. Validate the chain on a single test device first before rolling it out to the whole household.
| Component | Role | Common pitfalls |
|---|---|---|
| Firewall redirect rules | Steer LAN traffic into mihomo's transparent proxy port | Wrong rule ordering lets some traffic bypass the proxy |
| mihomo transparent proxy port | Receives redirected traffic and applies routing rules | Port not listening, or insufficient permissions |
| Routing table / policy routing | Ensures proxied traffic returns correctly | Routing table conflicts on multi-NIC setups |
DNS hijacking: a prerequisite for rules to actually work
Transparent proxying only solves the forwarding path. For rules to route accurately by domain, DNS also needs to cooperate. If a device queries the ISP's DNS directly, it gets back a real IP address, and mihomo can only make coarse decisions based on IP ranges or GeoIP data—fine-grained domain-based rules (like routing a specific site to a particular proxy group) simply won't apply. The fix is to hijack every LAN device's DNS queries at the router level and redirect them to mihomo's built-in DNS server, letting mihomo handle resolution itself and decide—based on the result and the configured rules—whether that traffic goes direct or through the proxy.
On OpenWrt, this is usually done either by modifying the dnsmasq configuration or by using firewall rules to force port 53 queries over to mihomo's DNS listening port. The relevant fields in the mihomo config include the DNS server addresses and whether fake-ip mode is enabled. Fake-ip further improves domain-routing accuracy, but can cause compatibility issues in scenarios that need real IP addresses (certain LAN service-discovery protocols, for instance), so weigh this against your actual use case when configuring it.
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.29The block above is a simplified example of the DNS section in a mihomo config. In real deployments you'll also want to fine-tune fields like fake-ip exclusion ranges and domestic-domain direct-connect lists—the exact meaning of each field is covered in detail on the concepts reference page.
Boot-time autostart and staying stable long-term
Routers are used differently from desktop machines—they're effectively powered on 24/7, and after a power loss the proxy service has to come back up automatically with no human intervention expected. On OpenWrt, setting up autostart for mihomo generally means writing a procd-compliant startup script under /etc/init.d/ and registering it with service mihomo enable, so the process comes back up automatically after a firmware reboot. If the bypass-router setup runs a general-purpose Linux distro instead, the usual approach is a systemd .service file with Restart=on-failure, so the process restarts automatically if it crashes.
Beyond autostart, a few other details matter for long-term stability: whether subscription updates are on a scheduled task, whether log files are capped so they don't grow unbounded and fill up storage, and whether memory usage creeps up over time (memory leaks have shown up in some older core versions, so keeping the core updated is worth doing). For a standalone bypass-router box in particular, it's worth setting up a watchdog script that periodically checks the mihomo process and restarts it if it's down—otherwise a service crash overnight can go unnoticed until the whole household wakes up to broken internet.
Once deployment is done, verify things in this order: first confirm mihomo is actually listening on its port, then confirm the firewall redirect rules are working (test from a device by visiting a site known to be routed through the proxy), and finally confirm the DNS hijacking chain is correct (use an nslookup-style tool to check whether results land in the fake-ip range). Only switch every device's gateway over once all three checks pass.
Router setup vs. desktop client: how to choose
The router approach and the desktop client approach aren't really competing options—they're better thought of as complementary, depending on the scenario. If only one or two everyday devices in the house need proxying, installing a desktop client (Clash Verge Rev or FlClash, for example) and configuring it through its GUI takes a few minutes and never touches the command line or firmware. But if the household has a large, varied mix of devices—especially TV boxes, consoles, and smart speakers that can't run a client at all—and all of them need the same routing rules, the router approach is the only way to cover everything at once.
Maintenance cost is another factor worth weighing: updating a desktop client is just downloading and reinstalling the new version, whereas upgrading the core on a router often means manually swapping binaries or reflashing a firmware package—a fiddlier process that's harder to troubleshoot when something goes wrong. Test any significant router changes on a spare device or test environment before touching the one in production. For most households, the more practical combination is: desktop clients on your main devices for flexibility and quick updates, and a dedicated bypass router set up separately only when there's a genuine need for unified routing across multiple devices—the two complement each other rather than being an either/or choice.
Where the rules and config actually come from
Whether it's mihomo on a router or on a desktop client, rule sets, proxy groups, and subscription links all follow the exact same mihomo configuration syntax—there's no separate router-specific format. That means a config file that already works on a desktop client can, in principle, be moved straight over to a router's mihomo instance, with just a few router-specific fields added on top (the transparent proxy port, the DNS listen address, and so on). If you're new to concepts like proxy groups and rule categories, it's worth working through the configuration logic on a desktop client first, then migrating to a router environment—that way, if something breaks, it's much easier to tell whether the issue is a bad rule or a router-side chain misconfiguration.