OpenWrt Bypass Gateway With mihomo: Transparent Proxy and DNS Redirect Steps

What You Are Building Demystified

The OpenWrt unit executes mihomo through a common integration such as OpenClash or a community Mihomo package, exposes a mixed or redir port, and uses dnsmasq or nftables rules to make sure nothing on the LAN can skip your resolver. For desktop-only workflows, our Ubuntu Clash Verge guide remains the better fit; this page complements it at the router + entire-home layer.

This article is for people who already own a small x86 or ARM OpenWrt device and want it to act as a bypass gateway: not replacing the primary router, but sitting beside it so every device on the LAN on its own sends Internet-bound traffic through mihomo (the maintained Clash Meta core) with transparent proxy and a single DNS path.

You are not reading yet another generic “install Clash” post; you are wiring out of the box gateway, DHCP settings, firewall redirects, and DNS hijacking so split rules, fake-ip pools, and upstream resolvers stay consistent for the entire house.

One more angle:We assume your primary router still handles WAN, Wi-Fi, and DHCP, but you will set setting 3 (out of the box gateway) and setting 6 (DNS server) to the OpenWrt box’s LAN address.

Bypass Versus Primary Router: Roles and Risks at a Glance

This guide keeps the common case: OpenWrt WAN is a static client on the primary LAN, OpenWrt LAN is the same subnet (bridge mode / dumb AP style) or a dedicated transit subnet—pick one scheme and stay consistent.

In a bypass topology the primary router keeps issuing IP addresses, but the next hop to the Internet for those addresses is your OpenWrt gateway. That means ARP and L2 switching still happen on the primary unit, while policy, logging, and outbound tunnels concentrate on OpenWrt.

The risk is straightforward: if the bypass box reboots or its mihomo process dies, the entire LAN may lose outbound connectivity until you revert DHCP or power-cycle with a fallback profile. Mitigate that with a secondary DHCP profile on the primary router (stored, not active) or a documented one-click way to plain custom settings.

A detail worth adding:Another risk is double NAT. If the primary router already performs NAT and the bypass also masquerades, a number of peer-to-peer games or port-forwarding setups behave oddly. Numerous home users accept double NAT for simplicity; advanced readers can switch the bypass to pure routing without NAT when their address plan allows.

Step 1 — Freeze an Address Plan Broken Down

Until you have time to mirror DHCPv6 and NDP settings, numerous households temporarily disable IPv6 on the primary router for the test VLAN or SSID used for validation. That is a trade-off, not a moral stance—re-enable once your nftables rules cover ICMPv6 and DHCPv6 as needed.

Pick a static IPv4 on the primary LAN for the OpenWrt WAN or bridged UI, for example 192.168.1.2 while the primary router stays 192.168.1.1. Reserve that address in the primary router’s DHCP static lease table so a random phone never steals it.

If you bridge OpenWrt into the same broadcast domain, you still need a single management IP for LuCI and SSH; document which physical port maps to which UI.

Said differently:For IPv6, decide early whether you will delegate prefixes through the primary router or execute IPv6 only after IPv4 is steady. mihomo’s DNS and rule logic is easiest to reason about when IPv6 does not silently bypass your DNS hijack.

Step 2 — Install and Open the Mihomo Control Plane From the Ground Up

Transparent modes instead bind redirect targets locally while iptables/nftables rewrites flows on the forwarding path. If you are new to the difference between system proxy and kernel capture, read our Clash TUN mode guide first; on a router, redir/TUN is closer to that document than to a browser PAC file.

On a fresh OpenWrt snapshot or steady release, install your preferred frontend. OpenClash remains the the majority of documented path: it pulls a compatible mihomo/clash meta binary, offers subscription bring in, and toggles redir/TUN modes from LuCI.

Alternative feeds ship a slimmer Mihomo LuCI app; the firewall steps differ slightly but the ideas stay the same. After installation, confirm the service launchs cleanly from SSH with /etc/init.d/openclash restart or the equivalent, then watch logread for missing kernel modules.

In practice that means:Bring in your subscription or local YAML the same way you would on a PC client, but pay attention to UI binding: the core must listen on the LAN bridge address that clients use as their gateway, not only on 127.0.0.1, when you expect other devices to use an explicit HTTP or SOCKS port.

Step 3 — Enable Transparent Proxy on OpenWrt Demystified

Do not duplicate rules from LuCI and from custom /etc/nftables.d unless you enjoy loops. After toggling transparent mode, test from a wired PC: curl https://ifconfig.me ought to show the proxy egress IP, and the mihomo log ought to list the domain rule that matched.

Transparent proxy means LAN devices do not need proxy environment variables. Their ordinary TCP connections to public IP addresses get REDIRECT or TPROXY treatment in the router’s forward chain, and the mihomo listener accepts them as redirected flows.

In OpenClash this is typically exposed as “Redir-Host” or “Fake-IP” mode plus a firewall rule checkbox that injects nftables or iptables rules depending on whether you execute fw3 or fw4.

When you use fake-ip, mihomo synthesizes short-lived answers for domain lookups so that applications immediately open sockets to addresses the core can map back to domain names for rule evaluation. That behavior must match how you configure DNS in the next section; otherwise you will see “sites open but wrong region” or random timeouts because a number of clients cached a fake address while others did not.

Worth noting:If you prefer predictable public addresses in local caches, redir-host mode trades a bit of rule precision for simpler mental models. Either way, keep UDP in mind: not every upstream supports full UDP transparent proxy; games and QUIC may need split exceptions or TUN. Document each bypass you add.

OpenClash can generate the firewall integration on its own; if you hand-roll nftables, you typically mark packets destined to certain ports and send them to a tproxy port such as 7895.

Step 4 — DNS Redirect (Hijack) on the Bypass at a Glance

On the primary LAN, a softer approach is to route those IPs through the same proxy group as normal HTTPS and rely on mihomo’s sniffing where appropriate; see our Sniffer and streaming rules article when IP-only flows break your DOMAIN rules.

DNS pollution and split anomalies often come from hard-coded DNS: smart TVs, Android “Private DNS”, and browsers with DoH ignore whatever you put in DHCP unless you block their escape paths.

On OpenWrt the robust pattern is: execute dnsmasq on 0.0.0.0:53 for the LAN bridge, forward upstream to mihomo’s DNS inbound (commonly 127.0.0.1:7874 in OpenClash, but verify your build), then add dstnat rules that catch whichever UDP and TCP to port 53 that is not destined to the router itself and redirect it to local dnsmasq.

One more angle:A number of users instead point DHCP setting 6 straight at mihomo’s DNS port without dnsmasq in the middle; that works until a client insists on port 53 only.

Keeping dnsmasq as a thin front preserves caching, handles local .lan names, and still lets mihomo apply fake-ip logic uniformly. Align dnsmasq’s “DNS rebinding protection” settings with private fake-ip ranges documented in your mihomo profile; otherwise LuCI may discard answers.

For public resolvers on port 443 (DoH), blocking outright is aggressive but sometimes necessary on a child VLAN.

Step 5 — Point the Primary Router’s DHCP at the Bypass Broken Down

Consumer mesh kits sometimes disallow custom DNS entirely—in that case either put the mesh nodes behind OpenWrt as DHCP client (OpenWrt becomes true edge) or execute a dedicated SSID from OpenWrt with its own DHCP scope. There is no magic third setting.

A detail worth adding:Log into the primary router admin UI and edit the LAN DHCP server. Set out of the box gateway (DHCP setting 3) to the OpenWrt static address. Set DNS server (setting 6) to the same address unless you intentionally split DNS and gateway for testing.

Shorten the DHCP lease time temporarily to 120 seconds so clients pick up changes quickly. Renew leases on a phone by toggling airplane mode.

If the primary router does not expose numeric DHCP settings, look for “Gateway” or “Custom DHCP settings” fields; a number of vendors hide them under advanced toggles.

Step 6 — Align mihomo Rules With Entire-LAN DNS From the Ground Up

Document which Ethernet ports belong to which VLAN at the switch.

Said differently:Once every client uses your resolver, rule order matters more than on a single laptop. Put explicit DOMAIN-SUFFIX rows for services you care about ahead of broad GEOIP catches, as we explain in the rule-based split traffic guide.

Remember that televisions and game consoles generate noisy telemetry domains; logging them for a week before tightening rules prevents accidental breakage.

For families mixing adults and guests, consider two SSIDs: one VLAN whose DHCP still points at the bypass, and one “clean” VLAN for devices that legally must not traverse a personal proxy.

Step 7 — Verification Checklist Demystified

If WebRTC exposes an unexpected ISP address, your UDP path is bypassing the tunnel or the STUN server is pinned to DIRECT by rule. Adjust before you declare victory.

In practice that means:Work in layers. First, from a test PC with a renewed lease, confirm ip route shows the OpenWrt address as out of the box via. Second, nslookup example.com ought to hit the same router IP.

Third, visit an IP-check site and compare the WAN IP with mihomo’s outbound UI. Fourth, tail the live log while loading a blocked page you expect to match a REJECT rule—if nothing prints, traffic is not traversing the core.

UDP-heavy apps deserve a separate pass: execute an online WebRTC leak test from a browser and a console game if applicable.

Step 8 — Troubleshooting Shortcuts at a Glance

Sometimes the fix is simply choosing a lighter node group for LAN policy.

Symptom: only a number of devices work. Cause: static IP clients still using the old gateway. Fix reservations or by hand refresh those hosts.

Symptom: DNS works but TCP hangs. Cause: transparent redirect not installed for the bridge you actually use, or mihomo listening on the wrong inbound.

Worth noting:Re-execute the LuCI wizard and confirm which Linux UI name OpenWrt assigned (br-lan versus a VLAN sub-UI).

Symptom: fake-ip sites load once then fail. Cause: TTL and cache mismatch between dnsmasq and clients.

Flush DNS on the client, cut down cache where safe, and verify you did not point half the network at 1.1.1.1 while the other half uses the bypass.

Symptom: CPU pegged at 100 Mbps. Cause: software flow steering on a weak ARM core; enable hardware offload only if your transparent stack supports it, or lower encryption ciphers with provider permission.

Closing Thoughts Broken Down

Compared with constantly toggling OS proxy settings, Clash-style apps on each machine stay predictable for travel and coffee-shop networks. → Download Clash for free and experience the difference.

An OpenWrt bypass gateway running mihomo is one of the cleanest ways to get entire-home proxy behavior: DHCP hands out one gateway, DNS redirect stops silent resolver swaps, and transparent proxy removes per-device proxy toggles.

One more angle:It pairs naturally with the same subscription files you already curate for PC clients, as long as you respect the extra responsibility that comes from sitting in the middle of anyone’s packets.

When you also need a polished desktop experience with fewer router-side experiments, a maintained GUI client still wins on ergonomics.