Running the Clash Core on Routers and Bypass Gateways: mihomo Deployment Overview

Why push the proxy down to the router layer

Desktop clients and mobile apps only cover the device they're installed on. TV boxes, game consoles, smart speakers, and tablets at home usually can't be configured one by one, and system proxy or TUN implementations vary across platforms — if a device doesn't support custom DNS or a virtual network adapter, you're stuck. Moving the proxy down to the router or a bypass gateway means traffic is taken over uniformly at the network's exit point: every device on that network automatically gets routing/split-tunneling capability, with no need to install a client on each one or worry about an obscure device architecture that can't run the software. That's the core reason so many home networks end up deploying the mihomo core at the gateway layer.

mihomo is the core implementation carried forward from the Clash Meta project. Compared with the earlier Clash core, it supports more protocols, has a more flexible rule engine, and offers native TUN mode plus rich process-level routing — a great fit for being baked into firmware and left running on a router long-term. The sections below cover the deployment approach for both the main-router and bypass-gateway topologies.

Main router vs. bypass gateway: which topology to choose

A "main router" setup means flashing custom firmware that supports third-party software (commonly OpenWrt-based) directly onto the router, so the router itself hosts the mihomo runtime. A "bypass gateway" setup means adding a small extra device alongside your existing router — a mini PC, a spare router reflashed as a plain gateway, or even a VM on a NAS — and pointing the devices that need proxying at it via gateway hijacking or a LAN DHCP option.

• Main-router setup: simple topology — one device handles both routing and proxying, no extra hardware needed. Downside: it demands more of the router's firmware compatibility and CPU headroom, and if the proxy process misbehaves it can affect routing for the whole network, since the risk is concentrated on a single device.
• Bypass-gateway setup: your main router keeps its stock firmware, so stability and support aren't affected; the bypass device is dedicated to proxying, so if something goes wrong you only need to restart that one box, and the troubleshooting boundary is clear. Downside: an extra piece of hardware and an extra layer of network config (gateway pointing, DHCP distribution), which raises the initial setup bar slightly.

If you only have one router capable of running third-party firmware and you're fine with concentrating all the risk on a single device, the main-router setup is the more convenient option. If you'd rather decouple the proxy environment from your basic network — so you can reset or swap the proxy device anytime without affecting internet access — a bypass gateway is the safer choice, and it's also the more common approach in home networks today.

Hardware selection and firmware basics

mihomo itself is a single Go binary and isn't particularly resource-hungry, but transparent proxying means handling NAT forwarding, DNS lookups, and rule matching simultaneously. When choosing hardware, focus on three dimensions:

1. CPU architecture and power: prefer a multi-core ARM or x86 platform with hardware acceleration support. Low-power single-core router-grade chips tend to introduce rule-matching latency under heavy concurrent connections.
2. Memory: loading rule sets and maintaining the connection table both consume memory — plan for at least 512MB available to the proxy process and firmware, and leave more headroom if you run a lot of rules or enable connection logging.
3. Storage and firmware ecosystem: main-router setups typically depend on OpenWrt or a derivative, so confirm the target device has stable third-party firmware support and community maintenance. Bypass-gateway setups have more freedom — a mini PC running a Linux distro, or an old router reflashed to plain-gateway OpenWrt, are both common choices.

On the firmware side, the mihomo project and community provide OpenWrt packages with a LuCI management UI that can be installed via the package manager, or you can drop in a precompiled binary and run it with an init script — both approaches are covered in the boot-persistence section below.

Transparent proxy modes: TUN, TPROXY, or REDIRECT

Taking over traffic at the gateway layer essentially means transparently redirecting TCP/UDP traffic from LAN devices into the port mihomo listens on, then letting the core decide — based on rules — whether to allow, proxy, or block it. The three common implementations each have trade-offs:

• TUN mode: mihomo creates a virtual network adapter and takes over traffic at layer 3 directly. Configuration is straightforward, UDP support is complete, and it's the recommended default today — especially useful when you need precise control over IPv4/IPv6 routing.
• TPROXY: relies on the Linux kernel's transparent proxy mechanism, using iptables/nftables on the gateway device to redirect traffic to mihomo. It preserves the original destination address and has good compatibility, and it's common in mature OpenWrt split-tunneling scripts.
• REDIRECT: an older implementation that only supports TCP redirection — UDP (especially for games and some video protocols that depend on it) needs extra handling, so it's generally not the first choice for new deployments anymore.

Whichever mode you choose, you need to enable the corresponding transparent-proxy toggle in the config file and declare the listening port. For example, the key fields for enabling TUN mode look roughly like this (check the current version's docs for exact parameters):

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

auto-route writes routing table entries automatically, and auto-detect-interface helps the core identify the outbound network interface. Together they save you from a lot of manual route-table editing, and this combination is the most commonly used setup in bypass-gateway deployments.

DNS takeover and anti-pollution

Transparent proxying only solves traffic forwarding. If DNS queries still go through the ISP's default path, domain-based rules will fail because they end up matching against the "wrong" resolved result — the typical symptom is that some sites are still painfully slow or unreachable even though a rule was configured for them. Gateway-layer deployments therefore need to take over DNS at the same time:

1. Enable mihomo's built-in DNS server in the config, and set it to listen on an address and port reachable from LAN devices.
2. Combine fake-ip or redir-host mode so the core sees the domain name first and then decides which upstream resolver to use, letting the rule engine split traffic by domain rather than by IP range alone.
3. In the router's DHCP settings, point the DNS server address handed out to LAN devices at the gateway itself (the device running mihomo), so devices can't bypass the gateway and query external DNS directly.

For a bypass-gateway topology, you also need to confirm on the main router that DHCP option 6 (DNS) actually points to the bypass device's address — otherwise, even if the bypass device is configured correctly, LAN devices will still get the main router's default DNS, and your routing rules will effectively do nothing. This step is the most commonly overlooked one when troubleshooting "rules are configured but not working."

Boot persistence and long-term stability

The proxy process at the gateway layer needs to recover automatically after a router reboot — otherwise a single power outage could knock out internet for the whole house, or leave it running without any routing rules applied. A few things worth setting up:

• Init scripts or system services: on OpenWrt you can write a procd service script to register mihomo as a system service, supporting standard operations like enable, start, and stop — procd will bring it back up automatically after firmware restarts.
• Watchdog and self-healing: pair it with a simple scheduled task (cron) that checks whether the process is alive, restarting it automatically if it crashes, so a core crash doesn't silently leave the network unrouted for hours.
• Keep config and rule sets separate: reference subscription-generated node configs and locally customized rules from different files, so refreshing a subscription doesn't overwrite manually tuned routing rules — saving you from re-checking everything after every subscription update.
• Log retention: turn on a reasonable amount of connection and core logging to local files, so you can trace back which rule or which DNS lookup caused a problem when a device goes offline or routing misbehaves.

Because a bypass gateway runs independently of the main router, it's usually easier to set up log retention and process supervision on it, and it's a better place to try experimental rule changes. For a main-router setup, it's best to keep the configuration relatively conservative, and back up your current working config before any major change.

A pre-deployment checklist

Here's a summary of the decision points above as a simple checklist you can run against your own home network:

1. Does your existing router support stable third-party firmware, and are you okay accepting concentrated risk? → Lean toward a main-router setup.
2. Do you have a spare mini PC, old router, or small NAS that can be dedicated to running the proxy? → A bypass gateway makes troubleshooting cleaner and spreads out the risk.
3. Do you have smart devices at home that don't support custom DNS (TV boxes, speakers, etc.)? → Plan out a gateway-level DNS hijacking strategy ahead of time.
4. Do you need to swap proxy hardware or reflash firmware frequently for testing? → A bypass gateway lets you swap things out anytime without touching the main network.
5. Are there long unattended periods (travel, being away)? → Make sure boot persistence and a watchdog are set up, so a power outage doesn't leave you unable to recover remotely.

Whichever topology you settle on, the core approach is the same: consolidate traffic and DNS into the mihomo core at the gateway layer, describe the routing logic with clear rule files, then use system services and logging to keep it stable long-term. Get those three layers solid, and every device on the home network genuinely shares the same proxy policy — without anyone having to fuss with per-device configuration.