Why use a side router instead of Clash only on a PC?

A Windows or macOS machine running Clash can share a proxy on the LAN, which works well when every client supports manual HTTP or SOCKS settings. Many readers already follow that pattern; our LAN proxy tutorial covers allow-lan, firewalls, and phone configuration in depth. TVs, cheap Android boxes, and some IoT devices are awkward: they may lack per-app proxy fields, or they ignore system proxy for DRM video. A dedicated OpenWrt side gateway can perform transparent redirection or system-level DNS steering so traffic hits Clash without per-device tweaks.

The trade-off is operational: you maintain Linux networking on the box, flash size, and kernel modules for redirect or TUN. You also introduce a second hop for clients that opt in. If you only need one game console, a hotspot or shared Wi-Fi path can be simpler; see our Switch hotspot workflow for a console-oriented topology. When the whole living room—TV, phones, tablets—should reuse the same rule stack, the side router model scales more cleanly.

Topology: main router plus one side gateway

Picture two layers. The main router connects to the internet, runs NAT, and usually hands out DHCP to most of the house. The OpenWrt side router sits inside that LAN. It does not replace the ISP modem; it consumes a private address on the home network and offers its own downstream port or Wi-Fi for “Clash-managed” clients.

There are two common wiring patterns:

  • Gateway-on-a-stick (recommended for clarity): Connect the OpenWrt WAN port to a LAN port on the main router with Ethernet. Devices that should use Clash connect to the OpenWrt LAN port or the OpenWrt Wi-Fi SSID. The main router still serves everyone else unchanged.
  • Same-subnet bridge (advanced): OpenWrt acts more like a bump-in-the-wire appliance on the same IP subnet. This saves a second NAT layer but requires careful static routes and firewall rules on the main router. Beginners should avoid it until the gateway model is stable.

This article focuses on the gateway-on-a-stick layout because it maps cleanly to LuCI menus: WAN obtains an address from the main router’s DHCP pool (or uses a static reservation), LAN uses a different private segment such as 192.168.2.0/24, and only clients attached behind OpenWrt traverse Clash automatically when you enable redirect or TUN.

Physical wiring in plain language

Unpack the steps as if you are labeling cables:

  1. Main router unchanged: Leave WAN on the main unit connected to fiber or cable as today. Note the main LAN subnet, often 192.168.1.0/24 or 192.168.0.0/24.
  2. Patch cable to OpenWrt WAN: Plug one end into a free LAN jack on the main router and the other into the port labeled WAN on the OpenWrt device.
  3. Downstream to TV or switch: Use OpenWrt’s LAN ports—or Wi-Fi—to attach the TV box, phones (via Wi-Fi), and anything that should share the Clash policy.
  4. Avoid loops: Do not connect OpenWrt LAN back to the main router’s LAN without disabling DHCP on one side; loops and duplicate DHCP break the network quickly.

If the TV is far from the OpenWrt box, place a small gigabit switch behind OpenWrt LAN, or use OpenWrt’s Wi-Fi as the only path for wireless phones while the TV stays wired into the switch.

OpenWrt WAN and LAN: what to set

After first boot, assign roles deliberately:

  • WAN interface: Protocol DHCP client so OpenWrt pulls an IPv4 address from the main router. In the main router’s admin UI, create a DHCP reservation for the OpenWrt WAN MAC address so its address never drift—this matters when you forward ports or pin static routes later.
  • LAN interface: Use a distinct subnet, for example 192.168.2.1/24 on the OpenWrt LAN bridge. Enable OpenWrt’s DHCP server on LAN so phones and the TV receive addresses in that range.
  • Firewall zones: Default OpenWrt maps WAN to wan zone and LAN to lan zone with masquerading on WAN. Keep that unless you know you need a bridge-only design.

At this point, a phone connected to OpenWrt Wi-Fi should browse the internet even before Clash—OpenWrt NATs through its WAN like a miniature router behind your main router. If that basic path fails, fix IP addressing first; adding Clash will only obscure the underlying issue.

DHCP default gateway: who points where?

There are three common DHCP strategies. Pick one consciously:

  1. Split by SSID or cable (simplest): The main router keeps serving 192.168.1.0/24 with gateway 192.168.1.1. OpenWrt serves 192.168.2.0/24 with gateway 192.168.2.1. Devices that join the OpenWrt Wi-Fi or plug into OpenWrt’s LAN automatically get the side gateway. Everyone else stays on the main router. No manual per-phone gateway edits are required.
  2. Single DHCP on the main router with static routes: Advanced users keep DHCP centralized and push a route toward the OpenWrt WAN address for specific subnets. That pattern helps when you cannot move clients to a second SSID. It requires the main router to support static routing and you must disable conflicting NAT expectations.
  3. Manual static IP on a TV: Some set-top boxes let you set a static IPv4 with gateway 192.168.2.1 while DNS points to the same box. Use this when the TV must stay on the same Ethernet VLAN as other gear but only the TV should use Clash.

For most apartments, strategy one is enough: create a dedicated “Proxy” or “Clash” Wi-Fi on OpenWrt, leave the main mesh SSID untouched, and teach family members which network to join on phones.

DNS: why the side router must own resolution for split routing

Clash’s fake-ip and rule-based DNS steering work best when clients query DNS through the side box. If phones still use the main router’s DNS while HTTP traffic is redirected, you can see odd mismatches—pages load but policies do not trigger as expected.

Practical checklist:

  • In OpenWrt DHCP options for the LAN, set DNS to 192.168.2.1 (the OpenWrt LAN IP) or to 127.0.0.1 if dnsmasq forwards to Clash’s listener—follow your Clash package documentation.
  • Disable IPv6 on the Clash-managed LAN temporarily if your provider delegates IPv6 that bypasses Clash; mixed stacks confuse streaming apps.
  • After OpenClash or Mihomo starts, verify from a client that DNS queries resolve and that Clash logs show policy hits.

For background on DNS modes in desktop clients, the concepts overlap with our TUN mode guide, though router firmware surfaces different toggles.

Installing Clash on OpenWrt (high-level)

OpenWrt does not ship Clash in the base image. Typical paths:

  • OpenClash: Popular LuCI front-end that downloads cores such as Mihomo, manages subscriptions, and configures redirect or TUN. Fits users who want menus over SSH.
  • Manual Mihomo binary: Copy the correct architecture build to /usr/bin, supply config.yaml, and use a procd init script or systemd-style service. This mirrors what we describe for Linux hosts in Mihomo on Linux with systemd, adapted for OpenWrt paths.

Regardless of packaging, you will import the same subscription URL you already trust, then tune split routing rules: GEOSITE streaming lists, GEOIP for country buckets, and MATCH for the default outbound. The benefit of the side router is that one YAML update applies to every client behind OpenWrt without touching the TV remote’s hidden menus.

Transparent proxy versus explicit proxy on the router

Two mechanisms dominate:

  • iptables or nftables REDIRECT / TPROXY: Intercepts TCP (and sometimes UDP) from LAN clients and sends it to Clash’s listening port. Works well for browsers and many apps on Android TV when combined with correct DNS.
  • TUN device: Clash raises a virtual interface and routes selected traffic through it. Often smoother for UDP-heavy apps when the kernel module is available on your chip.

OpenClash exposes these as modes with different firmware requirements. If performance is poor on a low-end router, prefer wired Ethernet for the TV and reduce rule-set size so the CPU can keep up with decryption.

Split routing rules: one stack for TV and phones

Design rules once, inherit everywhere. A pragmatic order:

  1. LAN and RFC1918 destinations: DIRECT so local NAS and printer traffic never enters the tunnel.
  2. Streaming and app domains: Use maintained rule sets for the services you actually watch; tag them to the appropriate policy group.
  3. Geo rules: Send certain country IP ranges to a dedicated outbound if your provider offers multiple regions.
  4. Default: Fall back to a sensible proxy group for everything else.

Phones and TVs then behave consistently because they share the same decision tree. When a vendor changes CDN hostnames, you update YAML once on OpenWrt instead of chasing per-device workarounds.

Which devices should use the side gateway?

Use a simple decision matrix:

  • Put behind OpenWrt: Smart TVs and boxes where you want region-aware streaming, phones that should follow the same domestic versus international split, and guest devices you prefer to isolate on a separate SSID.
  • Keep on the main router: Work laptops subject to MDM, VoIP phones that hate double NAT, and IoT bulbs that only need cloud pings. Double NAT is usually fine for general browsing but can break exotic port-forwarding games; gamers may prefer port exposure on the main network.
  • Test first: Banking apps sometimes block known data-center IPs; if a phone app fails only on the Clash SSID, switch that device back to the main Wi-Fi for those sessions.

Troubleshooting common side-router issues

Clients behind OpenWrt have no internet at all

Verify OpenWrt WAN received an address from the main router, that firewall forwarding from LAN to WAN is allowed, and that DNS on LAN points to a resolver that works. Ping 192.168.2.1 from a phone, then ping a public IP like 1.1.1.1. If IP ping works but names fail, DNS is the culprit.

Internet works when Clash stops, dies when Clash starts

Open the Clash log on OpenWrt. Mis-imported YAML, missing CA certificates for TLS nodes, or a core crash loop can take the redirect path down. Temporarily set mode to DIRECT default to confirm forwarding works, then re-enable groups.

TV buffers but the phone is fine

Streaming sticks often use hard-coded DNS or IPv6. Force DNS to the side router, disable IPv6 for that VLAN, and prefer wired Ethernet for 4K.

Intermittent outages for the whole house

Look for cabling loops or two DHCP servers on the same Layer-2 segment. The side router must not advertise DHCP on the main router’s LAN unless you intentionally bridge with STP awareness.

Broader port and DNS debugging steps also appear in our general troubleshooting guide.

Security and maintenance notes

A side gateway is a powerful pivot point. Keep OpenWrt patched, use strong Wi-Fi passwords on the Clash SSID, and do not expose the Clash external-controller port to the WAN. Remember that every client behind the box trusts its TLS inspection policy—only bridge personal devices you actually control.

Back up /etc/config and your Clash profile before major upgrades. Flash storage on cheap routers wears out; exporting configs periodically saves weekend afternoons.

Summary

An OpenWrt side router running Clash gives you a dedicated soft router layer: wire WAN to the main LAN, give OpenWrt its own subnet on LAN, let DHCP place the default gateway on the side box for clients that join that network, align DNS with Clash, and maintain split routing rules once for TV boxes and phones together. Compared with replicating subscriptions across fragile TV apps, the approach is easier to audit and update.

When you pair that architecture with a well-tested desktop or router build of the client ecosystem, day-to-day tuning stops feeling fragile. → Download Clash for free and experience the difference