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

What You Are Building

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 main router, but sitting beside it so every device on the LAN automatically 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 default gateway, DHCP options, firewall redirects, and DNS hijacking so split rules, fake-ip pools, and upstream resolvers stay consistent for the whole house.

We assume your main router still handles WAN, Wi-Fi, and DHCP, but you will set option 3 (default gateway) and option 6 (DNS server) to the OpenWrt box’s LAN address. The OpenWrt unit runs 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 + whole-home layer.

Bypass Versus Main Router: Roles and Risks

In a bypass topology the main 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 main unit, while policy, logging, and outbound tunnels concentrate on OpenWrt. The risk is simple: 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 main router (stored, not active) or a documented one-click way to clear custom options.

Another risk is double NAT. If the main router already performs NAT and the bypass also masquerades, some peer-to-peer games or port-forwarding setups behave oddly. Many 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 main 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

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

For IPv6, decide early whether you will delegate prefixes through the main router or run IPv6 only after IPv4 is stable. 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, many households temporarily disable IPv6 on the main 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

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

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

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 usually exposed as “Redir-Host” or “Fake-IP” mode plus a firewall rule checkbox that injects nftables or iptables rules depending on whether you run 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 some 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 automatically; 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 should show the proxy egress IP, and the mihomo log should list the domain rule that matched.

Step 4 — DNS Redirect (Hijack) on the Bypass

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

Some users instead point DHCP option 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 Main Router’s DHCP at the Bypass

Log into the main router admin UI and edit the LAN DHCP server. Set default gateway (DHCP option 3) to the OpenWrt static address. Set DNS server (option 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 main router does not expose numeric DHCP options, look for “Gateway” or “Custom DHCP options” fields; some 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 run a dedicated SSID from OpenWrt with its own DHCP scope. There is no magic third option.

Step 6 — Align mihomo Rules With Whole-LAN DNS

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

Work in layers. First, from a test PC with a renewed lease, confirm ip route shows the OpenWrt address as default via. Second, nslookup example.com should hit the same router IP. Third, visit an IP-check site and compare the WAN IP with mihomo’s outbound interface. 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: run 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

Symptom: only some devices work. Cause: static IP clients still using the old gateway. Fix reservations or manually update 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-run the LuCI wizard and confirm which Linux interface name OpenWrt assigned (br-lan versus a VLAN sub-interface).

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

An OpenWrt bypass gateway running mihomo is one of the cleanest ways to get whole-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 everyone’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.