Why run Clash on the router instead of every device
A desktop or phone client can steer its own traffic, but households rarely standardize on one OS, one vendor, or one willingness to install utilities. When you promote Clash to the gateway, you centralize policy: streaming boxes, guest Wi-Fi, and game consoles inherit the same split-routing behavior without per-device maintenance. On OpenWrt, that role pairs naturally with firewall zones, dnsmasq, and scheduled tasks—components you already maintain for DHCP and port forwards.
OpenClash is a LuCI-centric integration that wraps a Mihomo-class core with subscription management, rule providers, and toggles for redir/TUN style forwarding. It is not “magic routing dust”; it is orchestration on top of Linux networking. The payoff is operational: one place to update subscriptions, one place to read logs when a TV app misbehaves, and one place to back up before firmware upgrades. If you are still comparing clients, start with choosing the right Clash client for desktops, then map the same policy ideas back to the router.
This article assumes you own the network you configure and that running a proxy stack is permitted where you live and work. Open source tooling can be audited, but responsibility for lawful use stays with the operator—treat upstream documentation as authoritative for flags that change between releases.
Prerequisites: OpenWrt build, storage, and realistic expectations
Before you flash anything, confirm the hardware matches a maintained OpenWrt target with enough flash and RAM for a modern rule stack. Lightweight travel routers may lack space for large GeoIP databases and rotating rule providers; undersized devices thrash on I/O and produce “random” timeouts that look like bad nodes. Prefer wired management during setup: reconfiguring bridges or DNS while on Wi-Fi is how people lock themselves out until they factory-reset.
Install a sane baseline: stable firmware, working WAN, correct timezone, and NTP reachability. Snapshot your working /etc/config/network and /etc/config/dhcp before touching bridge toggles. If you dual-stack IPv6, decide early whether you will steer IPv6 through the same policy path or defer IPv6 entirely during first bring-up—half-enabled IPv6 often surfaces as “some sites work, some hang” because DNS returns AAAA records your policy never matched.
Expect to spend real time on DNS. Router guides that skip resolver order are the ones that strand users with working pings and broken names. Pair this walkthrough with Clash Meta DNS: nameserver, fallback, and fake-ip-filter when you tune the YAML side; here we focus on how OpenWrt hands queries to OpenClash.
Install OpenClash and align the Mihomo-class core
Installation paths differ by feed and maintainer: some users add custom package repositories, others sideload ipk builds matched to their exact kernel and architecture. The invariant is that kernel modules for TUN/redir must match the running kernel—mixing feeds from unrelated snapshots is a common source of insmod failures. After installation, confirm services start without silent crashes: use logread and the OpenClash log view rather than assuming a green toggle in LuCI means packets flow.
Import your subscription URLs carefully. Airport panels often rotate tokens; store them like secrets, not like memes in screenshots. After the core downloads profiles, validate that proxy groups resolve to real nodes and that health checks behave—mis-imported UTF-8 or user-agent quirks show up as empty providers long before you debug bridges. For ongoing hygiene, borrow habits from subscription management and node maintenance so your router is not the only device that “suddenly has no nodes” after a silent 403.
If you need compile-time details, issue trackers, or packaging sources, consult the upstream OpenWrt and OpenClash repositories directly. For end-user installers on desktops and phones, keep downloads anchored to this site’s download page so you do not confuse firmware packages with application bundles meant for PCs.
Bridge mode versus routing mode: where NAT actually happens
Bridge mode in home setups usually means your ISP-facing device remains the primary router performing NAT, while the soft router becomes a downstream appliance on the LAN. In that layout, the soft router may not own the default gateway for clients unless you deliberately repoint DHCP on the upstream router—many beginners expect “bridge” to behave like a switch while still wanting full transparent proxying for everyone, which only works if traffic actually traverses the Clash box.
When the OpenWrt device is the main router (WAN on OpenWrt, LAN switched internally), policy routing is easier to reason about: every LAN client uses OpenWrt as its gateway, and firewall marks can classify flows consistently. When OpenWrt sits behind another NAT layer, you must track double-NAT port mapping needs and avoid conflicting DHCP servers. Draw the diagram on paper: circle where DNS queries originate, where default routes point, and which interface carries forwarded LAN traffic.
If you truly bridge LAN and WAN at layer two for a specific experiment, remember that you may bypass the very hooks OpenClash relies on unless frames still pass through the CPU path you expect. For most readers, the robust pattern is routed mode with a clean LAN subnet, not a fragile “everything bridged” topology that duplicates addresses. Document the chosen mode in your notes so future you does not toggle mystery switches during a 2 a.m. outage.
Make the soft router the LAN gateway (DHCP and static clients)
Pointing clients at the wrong gateway is the fastest way to create “OpenClash shows running, nothing changes” support threads. In /etc/config/dhcp (LuCI: DHCP and DNS), set the LAN gateway option to this router’s LAN address and keep a single DHCP authority per broadcast domain. If another router still serves DHCP upstream, disable one side—two DHCP servers handing different gateways is a lottery for mobile devices that roam between APs.
For static servers (NAS, printers), reserve addresses and push the same gateway and DNS fields deliberately. Some IoT firmware caches DHCP options aggressively; after changes, power-cycle problematic gadgets instead of assuming they renewed immediately. If you segment VLANs, repeat the gateway audit per VLAN: guest networks that bypass the Clash router will look “fast but region locked,” while trusted VLANs follow your policy.
When you expose management on nonstandard ports or split management VLANs, ensure your own laptop still hits the intended path. A laptop with a VPN client enabled can accidentally tunnel “around” the home router’s policy even though LAN routing looked perfect from the wire.
DNS redirect: dnsmasq, OpenClash DNS listen, and hijack order
DNS hijack on a router rarely means “one checkbox fixes civilization.” It means: clients ask dnsmasq, which forwards to local or remote resolvers; OpenClash may listen on a dedicated port; firewall rules redirect raw 53/udp and 53/tcp toward that listener; the core resolves names according to dns settings and fake-ip policy; finally, applications may cache results independently. If any hop disagrees, you see oddities like “browser works, app fails” or “IPv6 only breaks.”
Practical sequencing: first make plain DNS resolution reliable without OpenClash (ping a domain, inspect nslookup from a LAN PC). Then enable OpenClash DNS with conservative upstreams—encrypted resolvers are attractive, but latency and blocking lists can interact badly on low-end CPUs. Align dnsmasq forward rules so every LAN client ends up querying through the path OpenClash expects; stray hard-coded DoH inside mobile apps can bypass your router entirely, which looks like “policy leaks” but is really application independence.
When using fake-ip, pair router-level settings with the guidance in Fake-IP, LAN, and router admin access so local destinations stay reachable. If you prefer fewer moving parts on constrained hardware, redir-host may trade a bit of mapping cleverness for simpler mental models—choose deliberately, not by whichever forum post has the prettiest screenshot.
Deep YAML for nameserver, fallback, and fake-ip-filter belongs in the dedicated DNS article; here the lesson is order: fix forwarding loops before you tune obscure policy groups. A redirect loop on port 53 can stall the entire household with symptoms that resemble “bad nodes.”
# Forward local domain queries to OpenClash DNS listener — example only
# list server '127.0.0.1#7874'
# list server '/lan/192.168.1.1'Keep China mainland traffic on DIRECT: GEOIP, rule sets, and LAN exceptions
The user goal “domestic sites stay domestic” is a policy routing problem, not a raw throughput problem. Start from a sane baseline profile that includes CN GEOIP or maintained rule providers, then place DIRECT ahead of broad proxy groups for Chinese domains and CDNs. Remember that “China” is not one monolithic network path: DNS answers may steer you to on-net caches; sending those flows through an overseas node can increase latency and break access controls—even when the proxy itself is healthy.
Treat streaming and banking apps as special cases: they often pin certificates, detect region mismatches, or require specific SNI paths. A coarse “proxy everything except CN” profile may still break a domestic app if its API endpoints were mis-tagged. Maintain small local overrides for intranet hosts and NAS names; rule routing best practices explains how to keep overrides readable as they grow.
Logging helps: when a domain lands in the wrong policy group, capture the domain name from the core log, classify it, and add a precise rule rather than turning global knobs randomly. If you see TLS failures only on certain domains, cross-check with timeout and TLS log interpretation so you do not blame routing when the remote endpoint is flaky.
Performance tip: aggressive auto-url-test groups on a router CPU can starve control-plane tasks. Rate-limit health checks, prefer stable groups for always-on devices, and schedule subscription updates off peak hours. A “perfect” config that maxes the router every thirty seconds is worse than a boring config that stays smooth.
Fake-IP versus redir-host on a household gateway
Fake-IP can reduce leaks and speed domain classification because applications receive synthetic addresses quickly, but it also changes how LAN and upstream DNS interact. On a shared gateway, misconfigured fake-ip ranges can make local hostnames or captive portals behave oddly. Redir-host keeps real addresses at the cost of different trade-offs. There is no universal winner—only pairs of choices that must match your DNS hijack plan.
If teenagers on your network play games with anti-cheat, expect occasional friction with aggressive transparent paths—sometimes the fix is a narrower bypass rule, not a new airport subscription. Document the mode you picked so the next firmware upgrade does not silently reset assumptions.
Troubleshooting ladder: ping, DNS, then policy logs
Work top-down. First confirm layer-three connectivity from a LAN client to the router and WAN without OpenClash steering (temporarily stop the service if needed during controlled tests). Second, verify DNS resolution for both a domestic and an international domain using tools you trust (dig or nslookup), explicitly noting which server answers. Third, enable core logging at a verbosity that shows which rule matched and which outbound was chosen—guesswork is expensive.
Common pitfalls: duplicate DHCP gateways, two DNS resolvers fighting for port 53, IPv6 path bypassing IPv4 policy, MTU issues on PPPoE links masquerading as proxy failures, and clock skew breaking TLS. Capture one failing flow end-to-end rather than screenshotting twenty unrelated warnings.
When you change bridge or VLAN settings, keep a serial console or failsafe recovery path. Routers are easy to brick with a bad uplink configuration; soft routers are not exempt from that reality. After each change, run a short automated check from a wired client: ping gateway, ping WAN DNS, fetch an HTTPS site through the policy, fetch a domestic site that must stay direct.
Upstream projects, updates, and trust boundaries
OpenWrt, LuCI, Mihomo-class cores, and OpenClash each move on independent cadences. Pin versions in your lab notes, read release notes before major jumps, and keep backups of working /etc trees. GitHub remains the right place to read source, file issues, and verify checksums—but consumer installers for desktop and mobile clients should still flow through this site’s download funnel to avoid mixing firmware artifacts with app bundles.
If something in this article disagrees with your on-device help text, trust the device: embedded manuals track fork-specific flags better than any blog snapshot.
Wrap-up
OpenWrt plus OpenClash is a credible way to lift Clash-style policy to the gateway, but success belongs to the boring layers: correct LAN default routes, a single coherent DNS chain, and explicit DIRECT paths for China mainland and intranet destinations before you chase exotic node features. Sketch your topology, fix port 53 loops early, and only then tune flashy rule providers.
Routers reward patience. A stable home network with readable logs beats a fragile masterpiece that falls over whenever a phone joins the guest SSID. Once the router path is dependable, desktop and mobile clients become optional overlays—helpful for travel, not mandatory for every screen at home. For a wider view of ecosystem choices, revisit choosing the right Clash client and keep desktop workflows aligned with the same policy language your gateway enforces.
Compared with one-off hacks, an organized gateway deployment scales: you add VLANs, not chaos. Keep backups, measure twice before bridge experiments, and treat subscription URLs like credentials—because they are.
→ Download Clash for free and experience the difference—use a maintained desktop or mobile client when you need visual editing, then mirror the same rules on your OpenWrt router for a household-wide baseline that stays consistent.