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

What You Are Building Key Takeaways

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

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 central router, but sitting beside it so every device on the LAN without you 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 preconfigured gateway, DHCP choices, firewall redirects, and DNS hijacking so split rules, fake-ip pools, and upstream resolvers stay consistent for the entire house.

The key point:The OpenWrt unit works 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.

Bypass Versus Central Router: Roles and Risks in Brief

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

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

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

Let me put it this way:This guide keeps the common case: OpenWrt WAN is a static client on the central 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 A Closer Look

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

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

Concretely:Until you have time to mirror DHCPv6 and NDP settings, countless households temporarily disable IPv6 on the central 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 What Matters

Load 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.

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

Where this lands: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 Key Takeaways

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

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 as a rule exposed as “Redir-Host” or “Fake-IP” mode plus a firewall rule checkbox that injects nftables or iptables rules depending on whether you work 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 fair few clients cached a fake address while others did not.

Do not skip this: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.

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 are best off show the proxy egress IP, and the mihomo log are best off list the domain rule that matched.

Step 4 — DNS Redirect (Hijack) on the Bypass in Brief

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

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: work 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 no matter which UDP and TCP to port 53 that is not destined to the router itself and redirect it to local dnsmasq.

The key point:A fair few users instead point DHCP choice 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.

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 Central Router’s DHCP at the Bypass A Closer Look

If the central router does not expose numeric DHCP choices, look for “Gateway” or “Custom DHCP choices” fields; a fair few vendors hide them under advanced toggles.

Let me put it this way:Log into the central router admin UI and edit the LAN DHCP server. Set preconfigured gateway (DHCP choice 3) to the OpenWrt static address. Set DNS server (choice 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.

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 work a dedicated SSID from OpenWrt with its own DHCP scope. There is no magic third choice.

Step 6 — Align mihomo Rules With Entire-LAN DNS What Matters

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.

Concretely: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.

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

Step 7 — Verification Checklist Key Takeaways

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

Where this lands:Work in layers. First, from a test PC with a renewed lease, confirm ip route shows the OpenWrt address as preconfigured via. Second, nslookup example.com are best off hit the same router IP.

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.

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 in Brief

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.

Symptom: only a fair few devices work. Cause: static IP clients still using the old gateway.

Do not skip this:Fix reservations or yourself upgrade 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-work 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.

Flush DNS on the client, bring 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.

The key point:Sometimes the fix is simply choosing a lighter node group for LAN policy.

Closing Thoughts A Closer Look

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

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.

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 all of us’s packets.

Let me put it this way: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.