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

What You Are Building in Depth

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 principal router, but sitting beside it so every device on the LAN by itself sends Internet-bound traffic through mihomo (the maintained Clash Meta core) with transparent proxy and a single DNS path.

We assume your principal router still handles WAN, Wi-Fi, and DHCP, but you will set toggle 3 (stock gateway) and toggle 6 (DNS server) to the OpenWrt box’s LAN address.

The OpenWrt unit operates 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 + everything-home layer.

Mechanically:You are not reading yet another generic “install Clash” post; you are wiring stock gateway, DHCP toggles, firewall redirects, and DNS hijacking so split rules, fake-ip pools, and upstream resolvers stay consistent for the everything house.

Bypass Versus Principal Router: Roles and Risks Mechanically

In a bypass topology the principal 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 principal unit, while policy, logging, and outbound tunnels concentrate on OpenWrt.

Another risk is double NAT. If the principal router already performs NAT and the bypass also masquerades, certain peer-to-peer games or port-forwarding setups behave oddly. Plenty home users accept double NAT for simplicity; advanced readers can switch the bypass to pure routing without NAT when their address plan allows.

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

More strictly:The risk is plain: 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 principal router (stored, not active) or a documented one-click way to obvious custom toggles.

Step 1 — Freeze an Address Plan Step by Step

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

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

Until you have time to mirror DHCPv6 and NDP settings, plenty households temporarily disable IPv6 on the principal 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.

At a different level: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 front-end.

Step 2 — Install and Open the Mihomo Control Plane Internals and Practice

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

Add your subscription or local YAML the same way you would on a PC client, but pay attention to front-end 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.

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.

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

Step 3 — Enable Transparent Proxy on OpenWrt in Depth

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.

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 certain clients cached a fake address while others did not.

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.

First, a clarification:OpenClash can generate the firewall integration by itself; if you hand-roll nftables, you typically mark packets destined to certain ports and send them to a tproxy port such as 7895.

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 it makes sense to show the proxy egress IP, and the mihomo log it makes sense to list the domain rule that matched.

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

Step 4 — DNS Redirect (Hijack) on the Bypass Mechanically

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.

Mechanically:Certain users instead point DHCP toggle 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.

More strictly: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.

On OpenWrt the robust pattern is: operate 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 you pick UDP and TCP to port 53 that is not destined to the router itself and redirect it to local dnsmasq.

Step 5 — Point the Principal Router’s DHCP at the Bypass Step by Step

Log into the principal router admin UI and edit the LAN DHCP server. Set stock gateway (DHCP toggle 3) to the OpenWrt static address. Set DNS server (toggle 6) to the same address unless you intentionally split DNS and gateway for testing.

If the principal router does not expose numeric DHCP toggles, look for “Gateway” or “Custom DHCP toggles” fields; certain vendors hide them under advanced toggles.

At a different level: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 operate a dedicated SSID from OpenWrt with its own DHCP scope. There is no magic third toggle.

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

Step 6 — Align mihomo Rules With Everything-LAN DNS Internals and Practice

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.

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.

Thinking it through:Document which Ethernet ports belong to which VLAN at the switch.

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

Step 7 — Verification Checklist in Depth

Work in layers. First, from a test PC with a renewed lease, confirm ip route shows the OpenWrt address as stock via. Second, nslookup example.com it makes sense to hit the same router IP.

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

First, a clarification: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.

Third, visit an IP-check site and compare the WAN IP with mihomo’s outbound front-end. 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.

Step 8 — Troubleshooting Shortcuts Mechanically

Symptom: only certain devices work. Cause: static IP clients still using the old gateway. Fix reservations or one at a time re-sync those hosts.

Re-operate the LuCI wizard and confirm which Linux front-end name OpenWrt assigned (br-lan versus a VLAN sub-front-end).

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

Mechanically:Flush DNS on the client, lower 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.

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

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

Closing Thoughts Step by Step

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

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

More strictly: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.

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 whichever you pick user’s packets.