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

What You Are Building from Practice

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 key router, but sitting beside it so every device on the LAN hands-free 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 built-in gateway, DHCP entrys, firewall redirects, and DNS hijacking so split rules, fake-ip pools, and upstream resolvers stay consistent for the full house.

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

The OpenWrt unit be up and runnings 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 + full-home layer.

Bypass Versus Key Router: Roles and Risks Lessons Learned

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

The risk is uncomplicated: 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 key router (stored, not active) or a documented one-click way to easy to follow custom entrys.

Another risk is double NAT. If the key router already performs NAT and the bypass also masquerades, a handful of peer-to-peer games or port-forwarding setups behave oddly. A good number of 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 key LAN, OpenWrt LAN is the same subnet (bridge mode / dumb AP style) or a dedicated transit subnet—pick one scheme and stay consistent.

Step 1 — Freeze an Address Plan in the Wild

Pick a static IPv4 on the key LAN for the OpenWrt WAN or bridged control panel, for example 192.168.1.2 while the key router stays 192.168.1.1. Reserve that address in the key 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 control panel.

For IPv6, decide early whether you will delegate prefixes through the key router or be up and running IPv6 only after IPv4 is settled. 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, a good number of households temporarily disable IPv6 on the key 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.

Step 2 — Install and Open the Mihomo Control Plane Hands-On Notes

On a fresh OpenWrt snapshot or settled release, install your preferred frontend. OpenClash remains the nearly all documented path: it pulls a compatible mihomo/clash meta binary, offers subscription pull 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 bring ups cleanly from SSH with /etc/init.d/openclash restart or the equivalent, then watch logread for missing kernel modules.

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

Step 3 — Enable Transparent Proxy on OpenWrt from Practice

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 by built-in exposed as “Redir-Host” or “Fake-IP” mode plus a firewall rule checkbox that injects nftables or iptables rules depending on whether you be up and running 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 handful of 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.

OpenClash can generate the firewall integration hands-free; 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 will want to show the proxy egress IP, and the mihomo log will want to list the domain rule that matched.

Step 4 — DNS Redirect (Hijack) on the Bypass Lessons Learned

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: be up and running 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 either UDP and TCP to port 53 that is not destined to the router itself and redirect it to local dnsmasq.

A handful of users instead point DHCP entry 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.

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.

Step 5 — Point the Key Router’s DHCP at the Bypass in the Wild

Log into the key router admin UI and edit the LAN DHCP server. Set built-in gateway (DHCP entry 3) to the OpenWrt static address. Set DNS server (entry 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 key router does not expose numeric DHCP entrys, look for “Gateway” or “Custom DHCP entrys” fields; a handful of vendors hide them under advanced toggles.

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 be up and running a dedicated SSID from OpenWrt with its own DHCP scope. There is no magic third entry.

Step 6 — Align mihomo Rules With Full-LAN DNS Hands-On Notes

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. Document which Ethernet ports belong to which VLAN at the switch.

Step 7 — Verification Checklist from Practice

Work in layers. First, from a test PC with a renewed lease, confirm ip route shows the OpenWrt address as built-in via. Second, nslookup example.com will want to hit the same router IP.

Third, visit an IP-check site and compare the WAN IP with mihomo’s outbound control panel. 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: be up and running an online WebRTC leak test from a browser and a console game if applicable. 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.

Step 8 — Troubleshooting Shortcuts Lessons Learned

Symptom: only a handful of devices work. Cause: static IP clients still using the old gateway. Fix reservations or step by step pull the latest 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. Re-be up and running the LuCI wizard and confirm which Linux control panel name OpenWrt assigned (br-lan versus a VLAN sub-control panel).

Symptom: fake-ip sites load once then fail. Cause: TTL and cache mismatch between dnsmasq and clients. Flush DNS on the client, trim 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.

Closing Thoughts in the Wild

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

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 whoever you are’s packets.

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

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.