Installing Clash on every laptop and phone works until your household grows: game consoles, smart TVs, guest devices, and IoT gadgets rarely offer a first-class proxy UI, and even where they do, keeping profiles and DNS behavior aligned across platforms turns into unpaid IT work. The alternative is to treat one OpenWrt box as the policy engine for the entire LAN—phones and PCs inherit the same Clash Meta (Mihomo) rules, transparently, because traffic leaves the subnet through a gateway that already speaks your subscription language. This guide explains the side-router pattern (a secondary OpenWrt gateway beside your main router), gateway mode, transparent proxy on the router, and policy-based LAN splitting without duplicating clients on each device. It complements our Linux TUN and systemd tutorial, which covers the same core on a single host rather than at the network edge.
1. Why a Side-Router Gateway Beats Per-Device Clients
Per-device Clash clients shine when you want portable control: a developer can switch nodes on a laptop without touching the rest of the family. A gateway deployment shines when you want consistency: every DHCP client receives the same default route and DNS path, so streaming boxes, tablets, and work laptops all evaluate identical DOMAIN-SUFFIX and RULE-SET logic. You still keep desktop clients where they help—testing, split tunnels for a single app—but the “house rules” live on OpenWrt.
The trade-off is operational: you are now running network infrastructure. Updates, disk space for rule providers, and firewall ordering become your responsibility. The upside is massive: you eliminate the class of bugs where one phone used system DNS while another used fake-ip, or where a TV silently ignored HTTP proxy settings. The router becomes the single place where transparent proxy hooks into forwarding paths, so applications that never understood proxies still traverse your policy graph.
mihomo binary; LuCI front-ends exist but vary by fork. This article stays core-centric so your YAML skills transfer between environments.
2. Topology: Main Router + OpenWrt Side Gateway
The most common home pattern keeps the ISP or fiber main router untouched (Wi-Fi, port mapping, SIP, whatever vendor firmware demands) and hangs an OpenWrt mini PC or router off a LAN port. The OpenWrt device receives a LAN address from the main router’s DHCP or uses a static lease; it then offers its own downstream switch or Wi-Fi AP for “managed” clients. In pure side-router setups, the OpenWrt box is not the Internet default for the main subnet until you deliberately point clients at it.
An alternative is full replacement—OpenWrt as the only router—but that is a different migration with PPPoE, VLAN, and hardware offload considerations. Here we focus on gateway mode where selected devices use the OpenWrt IP as default gateway and DNS, which maps cleanly to “I want Clash for the study and guest VLAN, not for the NAS management port.”
Draw the data path before you configure anything: WAN-facing traffic from managed clients should hit OpenWrt’s LAN interface, enter the Clash redirect or TUN pipeline, exit through your outbound per rules, then hairpin back toward the main router if that is still the true Internet path. Confusion at this layer—double NAT expectations, asymmetric routes—is the root cause of many “it works on ping but not in browser” tickets.
3. Addressing, DHCP, and the Default Gateway Handoff
Pick a stable IPv4 for the OpenWrt LAN interface that does not collide with the main router’s pool if both participate in the same broadcast domain; many homelabbers place the side gateway on a dedicated 192.168.x.0/24 segment behind a downstream switch. If you bridge everything flat, use static DHCP leases on the main router for the OpenWrt box and for any “full tunnel” clients you want to point at it.
To send phones and PCs through Clash without manual per-OS settings, set their default gateway to the OpenWrt LAN IP and supply DNS that resolves through Clash’s DNS stanza—either the router’s dnsmasq forwarding to Clash’s listener, or the Clash DNS port directly if you expose it safely. Consumer routers vary: some let you push a different gateway per DHCP scope; others require turning off DHCP on the main unit and delegating to OpenWrt entirely on one VLAN. The principle is always the same: whoever answers DHCP controls which machine is the policy choke point.
For mixed households, keep a “bypass” SSID or static client that still uses the main router only. That gives you a quick A/B test when debugging rule changes without unplugging hardware.
4. Running Clash Meta on OpenWrt: Packages, Paths, and Reality
OpenWrt is not a single frozen distro; feeds differ between releases and targets. You may install a maintained community package, cross-compile Mihomo, or drop a static binary under /usr/bin with an init script. Whichever route you choose, mirror the discipline from bare-metal Linux: a dedicated directory for config.yaml, writable paths for caches, and log rotation so flash wear stays reasonable on embedded storage.
LuCI integrations and projects such as OpenClash are popular because they bundle iptables or nft rules with the UI. Even if you use them, understanding the underlying Clash Meta YAML remains essential—UIs generate files, but when something breaks at 11 p.m., you will read the same dns, tun, and rules sections described in our Ultimate Clash Meta 2026 guide. Treat the router like a headless server: version your configuration, document which WAN interface name maps to which physical port, and keep checksums for any binary you sideload.
Resource planning matters: full RULE-SET downloads and GEOIP databases consume RAM; on 128 MB class devices you may need leaner lists or external storage. If your hardware is marginal, prefer REDIRECT-based transparent proxy over heavy userspace stacks until you confirm headroom.
5. Transparent Proxy on the Router: REDIRECT, TPROXY, and TUN
Transparent proxy means clients speak normal TCP/UDP to the Internet; the router intercepts eligible flows and forwards them to Clash’s inbound without configuring proxy settings on endpoints. On Linux routers this is traditionally implemented with iptables REDIRECT or TPROXY for TCP, plus companion rules for DNS if you need port-53 hijack. Modern OpenWrt often exposes nftables; the names change, but the contract does not: mark or match traffic, hand it to the local Clash port, let the core apply policy, then emit via the selected outbound.
TUN mode on OpenWrt is powerful because it mirrors what we teach for desktops: a tunnel interface participates in routing, and the core can steer flows that ignore classic proxy ports. It also demands more kernel cooperation and careful exclusion of management traffic—SSH to the router, LuCI, and local DNS loops should hit DIRECT rules so you do not lock yourself out when a rule misfires.
Practical guidance: start with a documented community recipe that matches your firewall backend (fw3 vs fw4) and kernel, then diff your way to minimal customizations. Copy-pasting desktop TUN blocks without adjusting interface names is a frequent foot-gun. When in doubt, verify with tcpdump on the LAN bridge that traffic actually reaches the Clash inbound after rule changes.
6. DNS for the Whole House: Alignment Beats Cleverness
Routing without DNS alignment fails in subtle ways: clients cache A records obtained outside fake-ip, CDNs pin you to the wrong POP, or DoH inside browsers bypasses dnsmasq entirely. For a gateway deployment, aim for one coherent resolution path for devices you expect Clash to own. Typical patterns include dnsmasq on OpenWrt forwarding to Clash’s DNS inbound, or pushing Clash as upstream with explicit cache sizes and no surprise forwards to ISP resolvers.
Decide early whether you rely on fake-ip for performance or prefer redir-host semantics for easier debugging; both work when subscriptions and RULE-SET coverage match your traffic. Document which devices use DoH locally—gaming PCs often do—and add rules so those flows still pass through policy or are explicitly marked DIRECT when you intend split tunneling.
If you expose a public resolver from the router, tighten access lists so your guest network cannot abuse it. DNS amplification is not theoretical on misconfigured homelab gear.
7. LAN Policy Routing: Splitting Devices Without Duplicate Clients
Traffic splitting at the gateway is mostly policy routing expressed as YAML: DOMAIN-SUFFIX for services, IP-CIDR for stubborn endpoints, RULE-SET bundles for maintenance-free coverage. Beyond that, you can combine network facts with Clash features:
- Static DHCP reservations give predictable client IPs on the OpenWrt LAN, which pairs well with source-based iptables/nft sets if you need to mark traffic before it enters Clash.
- Multiple SSIDs or VLANs let you map entire classes of devices to different Clash profiles—kids’ tablets vs. work laptops—by running separate config fragments or using
sub-ruleswhen supported. - Policy groups (selector, url-test, fallback) behave the same as on desktop; the difference is that every device inherits the group choice unless you expose a Web UI or API for household members to switch nodes.
For advanced setups, some operators run lightweight control panels on the router LAN to flip selectors; others prefer a small Raspberry Pi controller. Keep secrets out of log lines when you expose anything beyond localhost.
8. Firewall, Forwarding, and NAT Expectations
OpenWrt’s firewall assigns zones: LAN, WAN, guest, VPN. Your transparent proxy chain must permit forwarding from the client zone toward the Clash process and from Clash toward the true WAN, without creating hairpin loops. If the side gateway sits behind another NAT, understand that port forwards on the main router still terminate there—Clash does not magically replace upstream mapping for inbound services.
Enable software offloading cautiously; some offload paths bypass the netfilter hooks your redirect rules rely on. If upgrades suddenly “break transparency,” compare release notes for firewall fast-path changes. When using IPv6, repeat the same intentionality: allocate prefixes thoughtfully and ensure ICMPv6 neighbor discovery still behaves with your tunnel interfaces.
9. Verification: Layered Checks That Save Hours
Work top-down. First confirm basic connectivity: managed clients ping the OpenWrt LAN IP and obtain DNS answers. Next, hit a known geo-sensitive endpoint and compare against expectations from your outbound. Inspect Clash logs for policy hits—silent mismatches often mean DNS handed you an IP that bypassed domain rules.
Use traceroute and curl with verbose TLS to separate routing issues from application quirks. For Wi-Fi-only devices, remember power-save behaviors can delay DNS refresh; rebooting the client clears stale states faster than arguing with the router.
Cross-read our rule syntax deep dive if you need sharper DOMAIN versus DOMAIN-SUFFIX coverage—gateway scale magnifies small rule gaps.
10. Troubleshooting Shortlist
Partial site loads: chase DNS first—fake-ip misalignment and split DoH are prime suspects. Everything is slow: check CPU on the router during peak usage; RULE-SET updates and TLS handshakes cost cycles. Only some devices affected: compare DHCP options; a static IP may still point at the old gateway. Works wired but not wireless: different SSIDs may land on VLANs without the same redirect chain. Intermittent drops: inspect thermal throttling on passively cooled boxes and verify power supplies—brownouts masquerade as software bugs.
11. Closing Thoughts
Moving Clash Meta to an OpenWrt gateway is less about new YAML features than about network discipline: stable addressing, transparent interception that matches your firewall backend, and DNS that does not fight the policy graph. Done well, every screen in the house inherits the same thoughtful split tunnel you would have crafted on a workstation—without asking relatives to import subscriptions on their phones.
Compared with maintaining half a dozen device-specific clients, a router-centered deployment trades a steeper setup for calmer day-two operations: one place to rotate keys, one log stream to read when streaming services change CDNs, and one mental model for how traffic leaves your home. The Clash blog index lists more focused tutorials—load balancing, AI service routing, desktop clients—that pair well once your gateway baseline is stable. When you still need a polished desktop experience for testing or travel, the same Meta-class builds are available from our download hub—pair them with this gateway story and you cover both “whole-house defaults” and “just this laptop” without conflicting philosophies.