OpenWrt mihomo Router and Side-Router Setup: Deployment Options and Hardware Requirements

Understand the difference between the core, management interface, and transparent proxy

mihomo is a proxy core that continues the Clash configuration ecosystem and was formerly known as Clash Meta. It reads YAML configuration to handle node connections, proxy groups, DNS, and routing rules. OpenWrt manages network interfaces, routing, the firewall, and services. Copying the binary to a router does not mean LAN devices are already using the proxy.

A router deployment involves three separate checks: whether the service starts, whether client traffic reaches the core, and whether the core selects the right outbound route. LuCI management packages usually tie these pieces together; with a manual core installation, you need to connect them yourself.

• Explicit proxy: Enter the router's address and HTTP or SOCKS port on a computer or in a browser. Only apps that follow this setting will use the proxy.
• Transparent proxy: The gateway captures traffic using redirection, policy routing, or TUN, so you don't have to configure a proxy address on every device.
• DNS routing: Determines which resolver answers a domain and provides information for rule matching. It relates to traffic forwarding, but it's a separate function.

How main-router and side-router topologies differ

Deploying on the main router: centralized entry point, centralized impact

The main router connects to the upstream network and typically handles the internet connection, DHCP, DNS forwarding, and NAT. Client devices use it as their default gateway, making the traffic path for transparent proxying relatively straightforward. Configuration updates, rule loading, and proxy processes also compete for resources with the internet connection, Wi-Fi, and other services.

Internet
  │
OpenWrt main router: LAN 192.168.1.1
  │
Switch / wireless access point
  │
Computer: 192.168.1.100, gateway 192.168.1.1

A good fit if you already have a supported OpenWrt device and want to manage traffic across the network centrally. Keep a local management path available before going live. Whether normal forwarding falls back to a direct connection if the proxy service fails depends on the plugin's firewall cleanup and recovery behavior—don't assume it will happen automatically.

Single-interface side router: test one device at a time and watch the return path

A typical side router has one LAN interface and shares a switched network with the main router. The main router remains responsible for internet access. Set the test computer's default gateway to 192.168.1.2; the side router's own default gateway remains 192.168.1.1. Enable IP forwarding on the side router and configure firewall rules to allow the required forwarding.

Main router: 192.168.1.1, provides internet access and existing DHCP
  │
Shared LAN switch network
  ├─ Side router: 192.168.1.2, default gateway 192.168.1.1
  └─ Test computer: 192.168.1.100, default gateway 192.168.1.2

With this topology, outbound traffic may pass through the side router while return traffic goes straight from the main router to the client. Whether the side router needs source NAT depends on the plugin's requirements and connection-tracking behavior. Enabling SNAT can route some return traffic through the side router, but it also hides the original client address. Don't treat “masquerade on every interface” as a universal fix.

Three deployment options and their maintenance costs

Packages often make subscriptions, proxy groups, and runtime logs easier to manage, but check which core and firewall backend they support. OpenWrt 22.03 and later use firewall4, which is based on nftables. An older package that only generates traditional iptables rules may install successfully without making transparent proxying work. Custom firmware may also replace components, so check what's actually installed.

Running the core natively suits users who want control over configuration sources and update timing. Start by testing the configuration with the core's validation command, then use procd to manage the service. If the subscription file lacks router-side DNS, listener, or traffic-capture settings, you'll need to merge in a local configuration; otherwise, an update may overwrite your local settings.

Containers can work well on devices with more resources, but they don't make transparent proxying any less complex. TUN typically requires an available /dev/net/tun and the necessary network-management permissions. A listener address on a bridged container network is not the same as the host's LAN address. Don't grant every permission just to get the container running.

# Assuming the core is at /usr/bin/mihomo
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

The path above is an example for manual deployment, not a standard directory used by every package. When testing, use the configuration file the package actually loads. Some packages generate the final configuration in a temporary directory instead of using the downloaded subscription file directly.

Choosing an architecture and planning memory and storage

Check the CPU and firmware target before choosing a core build

ubus call system board
uname -m
cat /proc/cpuinfo
free -m
df -h /overlay /tmp

Use ubus call system board to check device and firmware target information; uname -m can help identify the runtime architecture. Common mappings include aarch64 for ARM64 and x86_64 for AMD64. MIPS builds can also differ by endianness, soft-float support, and other build options, so “MIPS” alone isn't enough to pick the right file.

ARMv7 builds and x86 builds that require specific CPU instruction sets must also match your hardware. If you see Exec format error, check the architecture and file format first. For Illegal instruction, check the CPU instruction-set requirements. Neither issue can be fixed by changing the subscription URL.

Capacity figures are for planning, not performance guarantees

These figures are for capacity planning, not measured throughput or minimum system requirements. Actual usage depends on rule providers, geodata formats, connection counts, DNS caching, and the package implementation. A low “free” value in free output doesn't automatically mean the system is out of memory; also check available memory, process resident memory, and kernel logs.

• Storage: Budget for the core, configuration, and rule data. Updates may also temporarily require space for the old files, downloaded package, and extracted files.
• Temporary files: OpenWrt's /tmp typically uses a memory-backed filesystem, so downloading large files competes with runtime memory.
• Write frequency: Avoid continuously writing verbose debug logs to small flash storage. Use an appropriate log level day to day, and enable detailed logging briefly when troubleshooting.
• CPU: Proxy encryption, user-space forwarding, and rule matching all consume compute resources. A gigabit Ethernet port doesn't mean every proxy protocol can reach gigabit speeds.

Gateway, DNS, and port configuration boundaries

Be clear about the role of each address

In the side-router example above, the test computer's gateway is 192.168.1.2. If the side router provides LAN DNS, you can also set the computer's DNS server to that address—but only if the side router is actually listening on port 53 on the LAN. Changing DNS alone won't route ordinary internet traffic through the side router. Changing the gateway alone doesn't guarantee that DNS queries will use the core's resolver logic.

One common setup has dnsmasq serve LAN clients on port 53, then forward selected queries to the core at 127.0.0.1:1053. Make sure queries can't loop back on themselves: for example, if the core uses dnsmasq as its upstream and dnsmasq sends every request back to the core, DNS resolution will loop indefinitely. If a management package already handles DNS, change its settings rather than adding a second set of rules.

Check fake-IP and IPv6 together

Fake-IP mode typically returns mapped addresses from a reserved range such as 198.18.0.0/16. Receiving one of these addresses doesn't mean DNS resolution failed, but subsequent connections must be handled by the same proxy-capture setup. If a client gets a fake IP but bypasses the side router, the domain may resolve while the connection times out.

Changing the IPv4 gateway doesn't automatically affect IPv6. The main router may still advertise an IPv6 default route and DNS servers, sending some connections along a different path. Either configure IPv6 traffic capture fully or explicitly limit IPv6 on test clients during the pilot, then verify each case separately. Don't assume dual-stack traffic is covered just because one IPv4 test succeeds.

How transparent proxying, TUN, and the firewall work together

Common traffic-capture methods include TCP redirection, TPROXY, and TUN. TCP redirection primarily handles TCP. TPROXY can handle TCP and UDP, but requires the relevant kernel modules, policy routing, and firewall rules. TUN receives IP packets through a virtual network interface and also needs correct routing, permissions, and forwarding settings.

mihomo's tun.auto-route automatically configures related routes, while auto-redirect involves automatic redirection on Linux. Confirm availability against your kernel version and system dependencies. Neither setting independently guarantees that “all LAN devices” are covered. In particular, don't enable a second automatic routing setup alongside rules already generated by a package.

• Preserve the correct path for LAN management and necessary private-network traffic so that access to the router's interface isn't sent out through the proxy.
• Make sure connections to proxy nodes don't re-enter the same traffic-capture path and create a loop.
• Check whether software or hardware flow offloading bypasses the current traffic-capture setup. Disable offloading for an initial baseline test, then re-enable it according to the package's compatibility guidance.
• Run only one transparent proxy management service. Two packages may compete for DNS ports, overwrite routes, or intercept the same connection twice.

# Check the current setup on OpenWrt; exact commands depend on the installed components
ip route show
ip rule show
nft list ruleset
logread | grep -i mihomo
dmesg | grep -i -E 'oom|out of memory'

ip route show displays the main routing table by default. If policy rules refer to other tables, check those tables too. A log entry showing that a service started only confirms the process is running; it doesn't verify LAN forwarding, DNS, or UDP traffic.

Test and roll back one client at a time

1. Save a baseline. Back up the OpenWrt configuration and record the main router, side router, DHCP range, and management addresses. Keep one management device using the main router as its gateway.
2. Test the core first. Run a configuration test and confirm the subscription loads, proxy groups have usable nodes, and the service doesn't exit repeatedly. Node connections also depend on time synchronization and upstream connectivity.
3. Test the explicit proxy first. If the example port 7890 is enabled and accessible from the LAN, run the request below on the test computer to distinguish node issues from transparent proxying issues.
4. Then change the test computer's gateway. Set it to 192.168.1.2 and configure DNS according to your setup. Check that LAN management, direct-access sites, and proxy rules all work as expected.
5. Check rules and connections. In the management panel, inspect the target domain, matched rule, proxy group, and selected node. A page loading successfully doesn't prove it went through the proxy; it may have matched DIRECT.
6. Expand the test last. Check UDP, IPv6, rule updates, and device restarts. Once everything passes, adjust DHCP settings or move more devices over.

# Run on the test computer; enable the corresponding HTTP proxy listener first
curl -I --proxy http://192.168.1.2:7890 https://example.com/

# Run this only after confirming the side router provides LAN DNS
nslookup example.com 192.168.1.2

The first command tests the HTTP proxy path; it doesn't prove that all apps, UDP, or transparent proxying work. The second only checks whether the specified DNS server responds, not whether the answer came from the expected upstream. Cross-check with the core's query logs and actual connection records.

To roll back, first restore the test computer's original gateway and DNS settings, then stop the proxy service and confirm the package has removed its traffic-capture rules. If you changed DHCP settings, renew the clients' leases. Don't just stop the core while leaving firewall redirection pointed at a closed port.

Choosing a deployment approach

If you already have a stable OpenWrt main router with enough resources, central deployment can reduce the need to maintain another gateway. If you want to test gradually and keep your existing network setup, start with a side router—but be prepared to manage client gateway settings, DNS ownership, and the return path. “Side router” doesn't mean a device that automatically takes over the whole network; it describes a specific forwarding topology.

First check the CPU architecture, available memory, and persistent storage, then choose a management approach compatible with the firmware's firewall. Roll out in this order: explicit proxy → transparent proxy on one device → DNS and dual-stack → expand to the whole network. Each step has a clear scope, so if something breaks, you can return to the last verified stage instead of changing the subscription, gateway, and firewall all at once.