Clash Transparent Side-Router Fix:
Gateway and nftables Rule Checklist

1. Topology and mental model

In the simplest side-router story, your main home router still hands out DHCP on 192.168.1.0/24, but you set one Linux or OpenWrt box at 192.168.1.2 as the default gateway for selected clients. Those clients send every off-subnet packet to 192.168.1.2 first. The side-router is supposed to pick up TCP/UDP (and sometimes ICMP), hand it to Clash, and only then hairpin or NAT toward the WAN interface that still points at 192.168.1.1. If any hop in that story disagrees—wrong MAC, missing return route, or DNS that never touches the gateway—you observe “random” failures: some apps work, others hang, captive portals mis-detect online state, or streaming devices insist they are in the wrong country because their resolver never moved.

Separate three planes mentally. Forwarding is whether the kernel moves IP packets between interfaces at all. Policy routing is which table picks the next hop after a packet is allowed to be forwarded. Application-level proxying is what Clash does once a flow is actually delivered to its listening port or TUN device. Forum threads often jump straight to YAML while the machine still drops FORWARD traffic or answers ARP for a subnet it does not own. Walking the checklist below keeps those planes in order.

2. Client gateway and DHCP

Before you touch nftables, prove the client truly uses the side-router. On Windows run ipconfig; on macOS netstat -nr; on Linux ip route. The default route must be the side-router address on the same broadcast domain as the client. If the client still shows the ISP-facing router as gateway, no amount of Clash tuning will intercept flows except those few apps that manually point at a proxy URL.

DHCP complicates this because renewals can revert fields. If the main router still advertises itself as option 3 (router) while you manually set a static IP on a test host, that is fine for experiments, but production setups usually move DHCP to the side-router, run a relay agent, or push a static DHCP reservation per MAC with the new gateway. Document what happens to option 6 (DNS servers): if you only change the gateway but leave DNS as the ISP pair, many operating systems will happily resolve through the old resolver while HTTP traffic supposedly “should” go through Clash—yet SNI-based rules never see the hostname because DNS never hit the forwarder. Align DNS with the same policy path you expect for TCP.

Mobile OSes add their own bypasses. Android Private DNS (DNS-over-TLS) ignores your LAN resolver unless you disable it or steer it through policy. iOS can cache Wi-Fi profiles per SSID. Smart TVs sometimes ship hard-coded DNS and even alternate MAC addresses per streaming app. When “only one device fails,” suspect per-app DNS before rewriting global iptables.

3. Side-router routing and NAT

Once packets reach the side-router, the kernel must know how to send them upstream. A typical mistake is enabling Clash while the side-router’s own default route still points nowhere useful, or points out the wrong VLAN subinterface. Verify from the shell on the gateway: ip route show should include a default via the main router on the interface that actually carries upstream ARP. Ping the main router, then ping a public IP by address (for example 1.1.1.1) from the side-router itself. If that fails, Clash is irrelevant until basic routing works.

When LAN clients sit on the same subnet as the WAN leg of the side-router (one-armed LAN on br-lan while eth0 talks to the upstream router), you often need SNAT/MASQUERADE on traffic leaving toward the main router so return packets come back through the side-router statefully. Without NAT, the upstream router may try to deliver responses directly to the original client MAC, bypassing the connection tracking entry you expected. Conversely, double-NAT stacks can break certain VoIP or gaming flows; that is a trade-off, not a moral failure—just know which mode you are in.

If you run multiple VLANs, confirm each VLAN interface has consistent reverse-path filtering settings (rp_filter) compatible with policy routing. Strict RPF can drop asymmetric flows that are common when you split domestic and international tables across interfaces.

4. Kernel forwarding (ip_forward)

For any box that should move packets between two interfaces rather than only originate or terminate them locally, IPv4 forwarding must be on: net.ipv4.ip_forward = 1 in sysctl. Without it, the kernel accepts packets destined to other hosts on the LAN but never retransmits them, which looks like “Clash is running yet the LAN is dead.” Pair that with firewall zones: on OpenWrt, WAN and LAN must allow forwarding in the correct direction; on raw Debian, default nftables policies of drop on forward will still block everything even if ip_forward is enabled.

IPv6 has a parallel knob (net.ipv6.conf.all.forwarding) and its own neighbor-discovery story. If your LAN picks up IPv6 prefixes from the main router while you only transparently redirect IPv4, some clients will prefer AAAA records and silently bypass your IPv4-only redirect rules. Either extend your hijack to IPv6 or filter AAAA at the resolver—each approach has operational cost.

5. nftables and iptables redirect

Transparent proxy historically meant iptables REDIRECT or TPROXY in nat PREROUTING for TCP to a local port where Clash listens in redir mode. Modern distributions increasingly ship nftables as the frontend; tables map to families ip, ip6, inet, and you attach chains to prerouting, forward, or output hooks. The mental checklist is the same: which hook sees the packet first, which mark or verdict sends it to userspace, and whether DNS on UDP/53 and TCP/53 is duplicated.

Minimal pattern (illustrative)

The snippet below is deliberately generic—interface names, ports, and Clash build flags differ. Treat it as a template to compare against your live nft list ruleset output, not copy-paste gospel.

table ip clash_transparent {
  chain prerouting {
    type nat hook prerouting priority -100;
    # LAN clients → Clash redir port (example 7892)
    iifname "br-lan" tcp dport { 80, 443 } redirect to :7892
    iifname "br-lan" udp dport 53 redirect to :1053
  }
  chain postrouting {
    type nat hook postrouting priority 100;
    oifname "eth0" masquerade
  }
}

Notice the split between TCP web traffic and DNS. If you omit the DNS line, clients that ignore DHCP DNS still resolve through the ISP path while TCP flows hit Clash—exactly the “only Google works weirdly” class of bugs. If you redirect DNS but Clash’s DNS listener is not actually bound or allowed by bind-address, you create a resolver black hole.

When both iptables-nft and native nft rules coexist, ordering surprises appear. Some installers still inject legacy rules via iptables-legacy. Run iptables -V and nft list ruleset side by side; duplicates can send packets through the wrong chain or bypass your redirect entirely. After any change, validate counters on the relevant rules (nft list ruleset -a) while you generate test traffic from a laptop.

6. Clash TUN versus transparent mode

TUN mode lets Clash own a virtual interface and install routes so most traffic enters userspace without hand-written per-port REDIRECT rules. On a dedicated gateway it can be simpler than maintaining a giant nft set for every QUIC or obscure UDP game. The trade-offs are elevated privileges, MTU quirks, and interaction with other tunnels (WireGuard, Zerotier, corporate VPN). If TUN is enabled but the host never created the tun device, or routes did not install because auto-route conflicts with your manual tables, clients still “use the gateway” yet packets never traverse the policy engine you thought.

Classic redir-port plus nftables keeps the kernel forwarding path thinner but requires you to enumerate ports or use TPROXY for certain UDP flows. Meta-class cores document which features pair with which inbound. Whichever mode you pick, align the YAML tun, listeners, and dns sections with the actual listeners you can see via ss -lunpt on the router. For a Linux service layout similar to headless gateways, see Install Clash on Linux with systemd; for deep Windows-specific TUN routing overlap, compare Clash TUN on Windows: routing and firewall—many concepts translate once you map “Windows filter platform” to “nft forward chain.”

7. DNS hijack beyond “change gateway”

Changing the gateway alone does not magically retarget DNS if clients cache old servers, use DoH hard-coded lists, or ship with “secure DNS” toggles. A solid gateway setup usually combines: DHCP option 6 pointing at the side-router, nftables redirect of UDP/53 and TCP/53 from LAN to Clash’s DNS inbound, and a Clash dns stanza that listens on that address. If Clash uses fake-ip, also read fake-ip and DNS troubleshooting so LAN IoT devices that insist on real A records continue to work.

IPv6 Router Advertisements can still inject RDNSS pointing at the ISP. If you are not ready for a full dual-stack policy, consider RA filtering or at least monitoring with rdisc6 / packet captures on the LAN interface. Android’s Private DNS and Apple’s iCloud Private Relay are deliberate tunnels around your resolver; corporate policy sometimes blocks them outright, homelabs often flip the toggle during debugging.

Finally, confirm Clash’s own upstream DNS can reach the Internet through the same outbound policy as browser traffic. A circular mistake is forcing all DNS through a proxy group that itself needs working DNS to bootstrap.

8. Packet walks and tooling

When theory disagrees with reality, use short, repeatable experiments. From a LAN client, run traceroute to a well-known address: the first hop should be the side-router, the second the main router, then the ISP. If hop one is missing or loops, you still have a pure routing issue. On the side-router, capture with tcpdump -ni br-lan port 53 while you query from the client—do packets even arrive? If not, the client is not using the interface you think. If they arrive but no answer returns, walk Clash logs for DNS rejections.

nft monitor helps watch live rule hits; conntrack -L confirms NAT entries for forwarded flows. For YAML-level clarity, cross-check effective config against our configuration documentation so listener addresses in the file match what ss prints after reload.

Document outcomes in a small table: timestamp, client OS, test hostname, whether DNS and TCP each hit Clash, and which rule counters incremented. That discipline saves hours when you revisit the setup months later after a firmware upgrade reorders firewall tables.

9. Summary

Transparent proxy on a side-router is a networking project first and a Clash YAML project second. Verify the default gateway on each client class, enable ip_forward, make nftables or iptables redirect consistent with your chosen TUN or redir mode, and only then tune DNS hijack so queries cannot silently return to the ISP. Most “half the LAN still direct” reports collapse into one missing chain—usually FORWARD accept, missing NAT, or DNS that never touched the forwarder.

Compared with opaque one-tap VPN appliances, Clash-family cores reward operators who read logs and treat routing as version-controlled infrastructure. A maintained client with clear updates makes that sustainable; grabbing builds from a trusted channel matters as much as firewall hygiene. When you are ready to consolidate profiles across laptops and gateways, start from the same baseline rules and keep per-platform overrides small.

→ Download Clash for free and walk this gateway checklist on real hardware before you chase exotic node providers.