Platforms 15-minute read

How to Run the mihomo Core Directly on a Router: Main Router, Bypass Router, and Transparent Proxy Trade-offs

A practical overview of running the mihomo core directly on a router or bypass router, covering firmware and hardware requirements, main-router versus bypass-router setups, transparent proxy traffic flow, and when router-based deployment makes sense.

Define the goal first: what should router-based proxying solve?

Putting mihomo on a router is not simply moving a desktop client to another device. The key change is moving the proxy entry point to the LAN gateway. Traffic from phones, TVs, game consoles, and smart devices reaches the gateway first, which then uses the destination domain, destination IP, source device, and protocol type to choose DIRECT, REJECT, or a proxy group. End devices can keep ordinary network settings while routing logic stays centralized on the router.

This setup works best for networks with many devices, devices that cannot install a client, shared rules, or source-device-based routing. For example, a TV can use a streaming node, a work computer can use a fixed exit, printers and NAS devices can always connect directly, and the guest network can bypass the proxy entirely. Rules are maintained in one place instead of being edited device by device.

A router-based transparent proxy also expands the blast radius of failures. A failed mihomo configuration, unreachable upstream DNS server, missing policy route, or incorrectly ordered firewall rule can disconnect multiple devices at once. Before deploying, write down three goals: which devices need proxying, which protocols must work, and whether automatic direct access is allowed when mihomo stops. The answers determine the trade-offs between a main router, bypass router, and transparent proxy.

Firmware, architecture, and hardware requirements

Check the CPU architecture first—not just the router model

mihomo provides Linux core files for different architectures. Common software routers use x86_64, newer ARM routers commonly use aarch64, and some older devices use armv7 or mipsle. With the wrong architecture, the executable will usually fail immediately with Exec format error. Check it over SSH:

uname -m
cat /etc/openwrt_release
ubus call system board
df -h
free -m

The discussion below uses the capabilities commonly found in OpenWrt 24.10.0, Linux 6.6, and mihomo 1.19.3 as a reference. It does not mean every firmware includes the same modules. Third-party firmware may change the kernel, nftables, DNS service, and startup manager, so actual deployment should follow the command output from the device itself.

Leave memory and storage headroom for rule sets

Running only the mihomo core with a small YAML configuration does not require much. GeoIP, GeoSite, rule sets, Fake-IP mappings, connection tables, and control panels will all consume additional memory. A practical hardware plan can start with these ranges:

Device resources Suitable use cases Deployment assessment
128 MB RAM, 16 MB flash Small rule sets, few devices Very limited space; upgrades and rollbacks are difficult. Not recommended for whole-home transparent proxying.
256 MB RAM, 128 MB storage 10–20 devices, standard rule sets Usable, but keep log levels and the number of rule sets under control.
512 MB RAM or more TUN, larger rule sets, concurrent traffic from many devices More practical maintenance headroom
x86_64, 1 GB RAM or more Gigabit access, containers, complex policies Suitable as a main router or dedicated gateway

Do not calculate storage based only on the mihomo executable. Configuration files, runtime logs, rule databases, and temporary update files also need room. Reserve at least 50 MB of writable space; if rule data and logs stay on the device, 100 MB or more is a safer target. When flash space is tight, move the data directory to a mounted disk, but make sure the startup script waits for the mount to become available.

Throughput depends on single-core performance, protocols, and encryption

The “gigabit” figure on a router box usually describes forwarding with hardware NAT enabled; it does not equal proxy throughput. Transparent proxying moves traffic into user space, while protocol encryption, rule matching, and connection reuse consume CPU. A quad-core ARM device that reaches 940 Mbps under ordinary NAT will not necessarily achieve the same figure when mihomo sends traffic through an encrypted node.

Record at least three measurements: direct throughput, throughput with a client running on the end device, and throughput through the router’s transparent proxy. Also check whether one core approaches 100% in top. If transparent proxying reaches only 180 Mbps while the end-device client reaches 600 Mbps, the bottleneck is usually the router CPU, virtual-interface handling, or protocol implementation—not the subscription node itself.

Run mihomo on the main router: shortest path, widest blast radius

The main-router setup is the most direct architecture. The main router handles the upstream connection or dial-up, DHCP, DNS, firewall, NAT, and mihomo. Every end device uses the main router as its default gateway, so traffic naturally passes through the proxy rules without changing the next hop.

End devices
  ↓ Default gateway
Main router: DHCP / DNS / Firewall
  ↓ Transparent proxy rules
mihomo: rule matching
  ├─ DIRECT → WAN
  ├─ REJECT → Drop
  └─ Proxy group → Remote node → Destination

Advantages of the main-router setup

  • The network topology is simple, with a single default gateway.
  • Source IPs, MAC-to-address mappings, and guest-network interfaces are easier to identify.
  • DNS interception, IPv4 policy routing, and firewall rules are managed centrally.
  • Paths between end devices, NAS systems, printers, and casting devices are easier to control.

Costs of the main-router setup

  • A configuration error can affect the entire network, so recovery must be possible without the proxy.
  • A firmware upgrade may reset custom firewall rules or installed packages.
  • The main-router CPU must handle PPPoE, SQM, Wi-Fi, NAT, and proxying at the same time, making resource contention more noticeable.
  • Some hardware NAT, traffic offloading, and software-flow offloading features may bypass the transparent proxy chain and must be disabled or revalidated.

If you run mihomo directly on the main router, keep at least one management path available. Leave an SSH path restricted to LAN access, or assign the management computer a static address and prepare commands to stop mihomo, remove policy routes, and restore DNS. Do not send the management domain, the router’s own update traffic, or proxy-node addresses back through the proxy, or you may create a routing loop.

Bypass-router deployment: fewer changes, but return paths must be mapped

A bypass router is usually a separate device connected to the main router’s LAN. It may not handle dial-up and may not provide DHCP for the whole network. mihomo runs on the bypass router, while selected devices use it as their default gateway or policy-routing next hop; the bypass router then forwards traffic to the main router for Internet access.

Test computer 192.168.10.50
  ↓ Gateway 192.168.10.2
Bypass router 192.168.10.2: mihomo
  ↓ Upstream gateway 192.168.10.1
Main router 192.168.10.1
  ↓
Internet

Method 1: Set the bypass-router gateway manually on the end device

This is the easiest bypass-router setup to troubleshoot. Set the main router to 192.168.10.1, the bypass router to 192.168.10.2, and change the test computer’s default gateway to 192.168.10.2. The bypass router’s own default route should still point to 192.168.10.1. If the test fails, simply change the computer’s gateway back to the main router.

You can first set DNS explicitly to the bypass-router address, then distribute it through DHCP after confirming that mihomo DNS works. The bypass router must enable IPv4 forwarding and allow LAN traffic to be forwarded from the incoming interface to the main router. If both devices are on the same subnet, check carefully that the return path does not bypass the bypass router; being able to open a webpage is not enough to prove that transparent proxying is complete.

Method 2: Assign different gateways by device from the main router

A main router that supports DHCP options or policy routing can assign the bypass-router gateway to selected devices by MAC address. This avoids manually entering static settings on TVs and phones. Give the bypass router a fixed lease so its address cannot change. Also decide which device supplies DNS: if the gateway points to the bypass router while DNS continues to point to a public resolver, domain-based rules may fail or the DNS path may leak.

Common bypass-router routing loops

The most common issue is the bypass router’s own proxy connection being captured by the transparent proxy rules. When mihomo connects to a remote node, the traffic enters mihomo again and eventually times out. Solutions include bypassing by process identity, bypassing by firewall mark, adding node-server IPs to a direct-connection set, and placing router-local traffic and forwarded traffic in separate chains.

Another issue occurs when the main router sends return packets directly to the end device even though the outbound path went through the bypass router. Ordinary TCP may still work sometimes, but flows that depend on connection tracking, source NAT, or TProxy marks can become inconsistent. A more reliable design is to have the bypass router perform the necessary SNAT, or use a separate subnet to clearly divide the upstream and downstream sides and avoid asymmetric routing on one subnet.

Three ways to implement transparent proxying

Transparent proxying is not a single switch. Common options on Linux routers include Redirect, TProxy, and TUN. All three can pass end-device traffic to mihomo, but they differ in protocol support, routing behavior, and troubleshooting priorities.

Redirect: a practical starting point for TCP

Redirect typically uses NAT rules to redirect TCP connections to mihomo’s redir-port. Example configuration:

redir-port: 7892
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

Its main advantage is simplicity, making it useful for validating HTTP, HTTPS, and most TCP applications. The limitation is equally clear: TCP Redirect cannot fully handle UDP. QUIC, some games, voice traffic, and UDP-based DNS require additional solutions. For a basic web-access test, Redirect is a reasonable starting point; for whole-network interception, TProxy or TUN is usually needed as well.

TProxy: preserve destination addresses for TCP and UDP

TProxy uses policy routing, packet marks, and a transparent-proxy firewall target to send TCP and UDP traffic to mihomo’s tproxy-port. The kernel needs the relevant transparent-proxy modules, and on OpenWrt, nftables or iptables rules must match the active firewall framework.

tproxy-port: 7893
mixed-port: 7890
allow-lan: true
mode: rule

TProxy is not just a port rule. Packets are normally marked first, then ip rule selects a dedicated routing table that sends them back to the local transparent-proxy port. If you add firewall rules without policy routing, connections will fail outright. If proxy-node IPs, LAN subnets, and reserved addresses are not bypassed in advance, routing loops or loss of local services may result.

When troubleshooting TProxy, check the listening port, nftables counters, policy rules, and routing tables in sequence:

ss -lntup
nft list ruleset
ip rule show
ip route show table all
conntrack -L | head

TUN: broader interception, more routing conflicts

mihomo’s TUN mode creates a virtual network interface and sends matching traffic into a user-space protocol stack. It can generally handle TCP and UDP together and makes configurations easier to reuse across Linux environments. A minimal example looks like this:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053

Whether auto-route and auto-redirect work as expected depends on the operating system, mihomo version, and firewall environment. On devices with multi-WAN, VPN, WireGuard, policy routing, or container networks, automatically added routes may conflict with existing rules. Before deployment, save the output of ip rule, ip route, and nft list ruleset for comparison.

TUN is not a performance guarantee either. The user-space network stack, GRO, MTU, and UDP handling all affect throughput. If some sites stop loading halfway through, check the path MTU. PPPoE interfaces commonly use an MTU of 1492, and tunneling can reduce the usable value further; do not set an extreme TUN MTU without packet-capture evidence.

DNS determines whether domain rules can match

DNS is the most underestimated part of transparent proxying. Writing DOMAIN-SUFFIX in a rule does not mean the router knows which domain belongs to a connection. If end devices query external DNS directly, use encrypted DNS, or provide only a destination IP to the transparent proxy, domain-rule match rates will drop.

Fake-IP traffic flow

  1. The end device queries the router for the domain.
  2. mihomo DNS returns a Fake-IP address and stores the domain mapping.
  3. The end device connects to that Fake-IP.
  4. The transparent proxy intercepts the connection, and mihomo restores the original domain from the mapping.
  5. The rule engine chooses DIRECT, REJECT, or a proxy group based on the domain.

Fake-IP works well for networks that rely on domain-based routing, but LAN domains, printer discovery, some games, and specialized applications may need to be added to the filter list. Router management domains, local suffixes, and private-address lookups should go to local DNS first rather than through a remote proxy.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.lan"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver resolves proxy-node server domains. This resolution chain must work before the proxy is established; otherwise it creates a dependency loop where a node connection is needed for resolution and resolution is needed to connect to the node. In practice, choose reachable upstream servers based on the network instead of copying addresses mechanically.

The interception boundary at port 53

Traditional DNS uses UDP or TCP port 53 and can be redirected on the router to mihomo DNS, for example to the local 1053. DoH uses HTTPS and DoT commonly uses TCP 853, so a single port-53 rule cannot intercept them. If a device has system-level encrypted DNS enabled, disable it through device management, restrict known endpoints with rules, or accept that the device will not use enhanced domain resolution.

Rule design: bypass first, then intercept

The first job of router rules is not to send more traffic into the proxy, but to clearly define what must never enter it. LAN addresses, multicast, broadcast, DHCP, router-management addresses, proxy-node servers, and necessary time synchronization should be bypassed first. Otherwise device discovery, casting, NAS access, or the node’s own connection may break.

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,224.0.0.0/4,DIRECT,no-resolve
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

Source-device routing can be implemented with source-IP subnets. For example, assign the TV a fixed address of 192.168.10.60, use 192.168.30.0/24 for the guest network, and choose policies by source. Fixed leases are more reliable than depending on dynamic addresses. Rules still match from top to bottom, so LAN bypass rules should come before source-device proxy rules.

IPv6 requires a separate decision. If you intercept only IPv4 while leaving IPv6 direct, applications may prefer AAAA records, making rules appear unreliable. Three options are available: configure full IPv6 transparent proxying; stop advertising an IPv6 default route to controlled devices during testing; or explicitly accept direct IPv6 access and include it in the security boundary. Do not merely set ipv6: false in mihomo while allowing end devices to obtain public IPv6 through the router.

A deployment sequence you can roll back

  1. Record the current state. Save the main-router address, DHCP range, DNS, default routes, firewall rules, and existing VPN configuration.
  2. Verify the binary. Run mihomo -v over SSH to confirm the architecture, then use mihomo -t -d /etc/mihomo to validate the configuration.
  3. Start with the control port only. First enable mixed-port: 7890, configure an HTTP or SOCKS5 proxy manually on the test computer, and confirm that nodes and rules work.
  4. Connect DNS. Point one test device’s DNS to the router, then use nslookup or dig to inspect the returned results.
  5. Add transparent proxying. Initially process only the test device’s source IP and keep every other device on a direct connection.
  6. Test TCP, UDP, and local services. Check webpages, video, voice, games, NAS, printers, and casting devices instead of running a single speed test.
  7. Configure startup and rollback. If mihomo fails to start, do not leave forced redirection rules enabled; stopping the service should restore ordinary forwarding.
  8. Expand gradually. Move from one device to one VLAN, and only then consider intercepting the entire network.

Set runtime logs to info during debugging and briefly use debug when tracing rule matches. Keeping a high log level permanently increases storage writes and CPU usage. Once stable, configure log rotation and regularly monitor memory, connection counts, and process restart counts.

Which workloads belong on the router—and which should stay on the device

Good candidates for router deployment

  • TVs, game consoles, and smart devices that cannot install a proxy client.
  • Homes or small offices that need centrally maintained rules and subscriptions.
  • Networks that need different policies by device, VLAN, or source subnet.
  • Routers with sufficient hardware performance and a stable SSH management path.
  • Administrators who understand DHCP, DNS, routing tables, nftables, and connection tracking.

Cases better served by an end-device client

  • Only one or two computers need proxy access while every other device connects directly.
  • The main router is an ISP-provided device that cannot install software or expose firewall rules.
  • The network depends on an enterprise VPN, complex multi-WAN routing, or strict endpoint authentication.
  • Configurations must be switched frequently and failures should affect only one device.
  • The router’s memory, storage, or single-core performance is already near its limit.

In practice, this does not have to be an either-or choice. A common combination is to use the router only for TVs, the guest network, and devices that cannot install a client, while the development computer continues running a desktop client. This preserves device-level control without concentrating every complex policy on one gateway.

The final decision comes down to one principle: the main router prioritizes simple topology, the bypass router prioritizes controlled changes, TProxy prioritizes native Linux transparent forwarding, and TUN prioritizes unified interception. Evaluate the failure boundary before counting features. A setup that can be disabled quickly, restore DNS, and bypass node loops is the one suited to long-term operation.

Continue configuring the client

First verify the subscription, nodes, and rules on the computer, then decide whether to migrate the same traffic-splitting logic to the router.

Go to downloads View the guide
Download Clash