Centralizing proxy rules at the router level is a common approach to solving multi-device traffic splitting. Instead of installing a client on every device, running the mihomo core directly on the router lets every device on the LAN — including TVs, smart speakers, and game consoles that can't install a client — follow the same rule set. Change the config once and it takes effect network-wide. This article walks through the overall approach to running mihomo directly on a router. It doesn't cover screen-by-screen steps for any specific firmware; instead it focuses on the decisions that matter and the pitfalls people commonly hit.
Why run mihomo on the router
Installing a client separately on each phone, tablet, and computer is flexible, but it has two clear drawbacks. First, devices that can't install apps — smart TVs, robot vacuums, some game consoles — simply can't join the proxy network. They'd have to rely on manually entering a proxy server address, and many devices don't even offer that option. Second, maintaining a separate config on each device means rule and subscription updates have to be synced device by device, which easily leads to version mismatches and inconsistent routing.
Deploying the mihomo core on the router solves both problems. Every device on the LAN routes its traffic through the router by default, so as long as the router handles transparent proxying correctly, devices get rule-based splitting with zero extra setup, and config maintenance is centralized in one place. This approach is often called "gateway proxying" or "bypass router proxying," the difference being whether the proxy runs on the main router that already handles network egress, or on a separate device sitting alongside the main router that takes over traffic via policy routing.
Main router vs. bypass router
Running directly on the main router means flashing third-party firmware that supports mihomo (commonly OpenWrt or a derivative) and running the proxy core right at the network egress, with all traffic passing through by default. This has the shortest path and needs no extra hardware, but it demands more from the router's firmware compatibility and performance — a bad config can take down internet access for the whole house, and troubleshooting is harder. Think through your rollback plan before making any experimental changes.
The bypass router approach adds a separate small device to the existing network (commonly a Raspberry Pi, mini PC, or a flashed secondhand router) that only runs the proxy core, without handling the main router's DHCP, Wi-Fi, or other base duties. The main router then forwards part of the traffic to the bypass device via policy routing or a DHCP gateway pointer. The upside is that the main router's stable config stays untouched — if something goes wrong, just point the gateway back to the main router, keeping the risk contained. The downside is one extra hop in the path, slightly higher theoretical latency, and the need for an extra device plus some networking know-how to wire up policy routing.
For most home networks, a bypass router is the safer starting point: validate the routing rules on a small scale first, and once things are stable, decide whether to fold it into the main router. If you're already running high-performance, flashable router hardware and are confident troubleshooting network issues yourself, deploying directly on the main router keeps the path simpler.
Basic hardware and firmware requirements
Whichever approach you take, there are a few hardware thresholds you can't skip.
- CPU architecture and performance: mihomo has real CPU demands. With a large rule set and heavy concurrent connections, low-power single-core devices tend to show forwarding lag or packet loss. When choosing or repurposing a device, favor multi-core ARM or x86 platforms, and avoid asking an underpowered old router to handle high-concurrency proxy work.
- Memory: rule sets and GeoIP/GeoSite databases take up real memory once loaded. Devices with too little RAM (under roughly 128MB) can suffer core crashes or slow responses once the rule count grows — plan for at least 256MB of usable memory.
- Storage: the firmware itself, the mihomo binary, rule databases, and log files all need somewhere to live. If the device's built-in storage is too small, attach a USB drive or pick a model that supports expandable storage.
- Firmware support: the mainstream choice is OpenWrt or a well-supported community derivative. These firmware ecosystems are mature, and their plugin repositories usually have a packaged mihomo or a compatible component ready to go, saving you from compiling manually. Stock router firmware generally can't run a proxy core at all — you'll need to flash third-party firmware that supports custom software installs first.
Flashing firmware carries a real risk of bricking the device. Before you start, make sure the firmware build exactly matches your device model, and back up the stock firmware and key partitions in advance.
Choosing the right binary
mihomo publishes separate binaries for different CPU architectures and instruction sets, with common labels like amd64, arm64, and armv7. Picking the wrong architecture means the program either won't run at all or crashes immediately. Beyond matching the architecture, keep two other things in mind:
- Version stability: router deployments should prioritize stability over chasing the newest release. Pick a version that's been vetted over time rather than something just published, so you don't expose your network egress to unknown compatibility issues.
- Feature alignment: confirm the version you're picking actually supports what you plan to use — TUN mode, specific rule syntax, a particular transport protocol implementation. Binaries from different distribution channels sometimes trim features to keep size down, so check the release notes for that version before deploying and confirm the feature coverage meets your needs.
A packaged mihomo component from a firmware plugin store has usually already handled architecture matching for you, making it the easier starting point if you're not familiar with manual deployment. Manually downloading a binary and writing your own startup script only makes sense when you need custom build flags or a newer version that hasn't made it into the plugin repository yet.
Transparent proxy and DNS hijacking essentials
The core value of running directly on the router is being "transparent" — LAN devices don't need to know a proxy exists at all; everything is intercepted automatically at the gateway. Making that work relies on two mechanisms working together.
Transparent traffic redirection
mihomo supports creating a virtual network interface at the system level via TUN mode, redirecting traffic passing through the router into that virtual interface, where the core applies rule-based routing. This approach has good protocol compatibility and covers both TCP and UDP. Some firmware environments also support a transparent proxy setup based on iptables/nftables rules, which works by redirecting specific port ranges — or all traffic — to a local port the core is listening on. Both approaches have their place: TUN mode is relatively straightforward to configure but demands more from kernel version and firmware network stack compatibility; the iptables approach has broader compatibility but more complex rule syntax, and troubleshooting requires familiarity with the redirection chain.
DNS hijacking and pollution avoidance
Rule-based splitting largely depends on domain resolution results to make decisions. If a device's DNS requests bypass mihomo and go straight to an ISP's DNS server, they may get polluted or inaccurate results, throwing off routing accuracy. That's why router deployments typically need an extra step: force-redirect all port-53 DNS requests from every device on the LAN to mihomo's built-in DNS server, so the core handles resolution and the subsequent routing decision itself.
An incomplete DNS hijack setup usually shows up as "some apps route through the proxy fine, others go direct on the raw network" — often because those apps ship their own DNS resolution logic that bypasses the system DNS settings, and the hijack rule along with it. When debugging this, first confirm the router-level DNS redirect rule covers every subnet and both directions of the relevant ports, then check whether the specific app is using encrypted DNS (like DoH) to connect directly to a specific server.
Two common ways for LAN devices to connect
Getting mihomo running is just step one. The bigger question is making sure other devices on the LAN actually "know" to route through it. The two common connection methods each have their trade-offs.
| Approach | How it works | Pros | Limitations |
|---|---|---|---|
| Direct gateway pointer | The DHCP-assigned default gateway points directly to the device running mihomo | Simple to set up; new devices are covered automatically with no per-device config | That device becomes a single point of failure — if it goes down, every downstream device loses internet access |
| Policy-routed splitting | The main router forwards traffic from specific devices, matched by source IP or MAC address, to the bypass device | Lets you control which devices route through the proxy on a per-device basis, containing the blast radius of a failure | Requires maintaining policy routing rules on the main router; new devices have to be added manually |
A direct gateway pointer fits scenarios where you want the whole household on the proxy — configure it once and every newly connected device is covered, which suits homes with lots of devices where setting each one up individually isn't practical. Policy-routed splitting fits scenarios where only some devices need the proxy and others should stay on a direct connection — for example, routing only the smart TV and game console through the proxy while other work devices keep their original network path, avoiding unnecessary side effects. Which one to pick depends on how you weigh "cover everything" against "fine-grained control." You can also start with policy routing on a small scale, and once it's stable, switch to a direct gateway pointer.
A few things to check before you deploy
Before diving in, it's worth confirming a few things — it'll save you a lot of troubleshooting time later.
- Confirm your device's architecture and firmware version, and download the matching mihomo binary or plugin package ahead of time, so you're not stuck looking things up while offline.
- Have your subscription link and base rule set ready. Validate the config file syntax and rule matching on a small scale (say, just your own device) before rolling it out to the whole household.
- Plan where logs will be stored. Router storage is limited, so for long-term operation, set up log rotation or periodic cleanup to avoid storage filling up and causing device issues.
- Confirm your rollback path: if the whole household loses internet after deployment, can you quickly point the gateway back to the main router, or use a backup connection (like a phone hotspot) to temporarily access the router's admin interface and fix things?
Proxying at the router level pays off clearly, but the cost of getting it wrong is also higher than with a single-device client — a mistake affects the whole household's network. It's worth deploying and testing during off-peak hours, running it as a long-term setup only once it's stable, and keeping a backup of your original network config that you can restore quickly.