Choose how Clash will serve your home network
Sharing Clash with phones, computers, and televisions is less about installing the same app everywhere and more about deciding which device will act as the proxy gateway. A desktop client normally listens on its own machine; other devices cannot use that listener unless the network allows them to reach it and the client is configured to accept LAN connections. A router-based setup moves the proxy role closer to the network edge, but it also changes how gateways, DHCP, DNS, and device selection work.
There are three practical patterns. A proxy host is an always-on computer running Clash or Mihomo; devices that support a manual HTTP or SOCKS proxy point to that computer. A Clash-capable main router runs the proxy core itself and can apply policy to clients on the home network. A bypass router sits behind the existing router and offers a second path: devices connected to it use the proxy, while devices that remain on the original network keep the ordinary route. The best choice depends on your router firmware, how much control you need, and whether you want every device to be affected.
For a small household, a proxy host is often the easiest way to test the idea. It requires no change to the main router, but the host must stay powered on and each device must support the proxy protocol you expose. A router installation can be more convenient for devices that do not offer proxy settings, including many televisions and game consoles, but router support varies substantially. A bypass router is a useful middle ground when the main router is supplied by an internet provider, locked down, or already carries settings you do not want to disturb.
Before buying hardware or changing firmware, check the exact model and revision, CPU architecture, available memory, supported firmware, and whether the build includes a compatible Mihomo or Clash core. “Can run a VPN client” does not automatically mean “can run this proxy core,” and a router’s advertised Wi-Fi speed says little about its capacity to process encrypted traffic. Also check whether your provider’s device policies and local rules permit the intended use.
Plan addresses, subnets, and gateways first
Write down the current network before changing it. Record the main router’s LAN address, subnet mask, DHCP range, Wi-Fi names, and any static addresses used by printers, NAS devices, cameras, or smart-home controllers. For example, if the main router is 192.168.1.1 and leases addresses from 192.168.1.100 through 192.168.1.240, keep that information available while configuring a second router. A screenshot of the existing settings can save considerable recovery time.
The most straightforward bypass-router layout uses a separate subnet. Connect the main router’s LAN port to the bypass router’s WAN port. Give the bypass router a LAN range that does not overlap with the main network, such as 192.168.50.0/24, and set its LAN address to 192.168.50.1. The bypass router’s WAN interface receives an address from the main router, while its own DHCP service assigns addresses to devices connected to its LAN or Wi-Fi. In this arrangement, the bypass router is the default gateway for its clients.
Separate subnets make the gateway choice easy to understand: a laptop connected to the original Wi-Fi uses the main router, while a laptop connected to the bypass router’s Wi-Fi uses the bypass router. The trade-off is that the second router may perform NAT in addition to the main router’s NAT. This is usually adequate for everyday browsing and streaming, but can complicate inbound connections, some multiplayer games, remote access, and port forwarding. If one of those services matters, check the router’s documentation and test it before moving every device.
A LAN-to-LAN connection has different behavior. It is commonly used when a second router is configured as an access point on the same subnet. That can improve Wi-Fi coverage, but it does not automatically make the second box a separate gateway or create a proxy-only path. In a same-subnet design, DHCP is normally provided by one device, and clients may continue using the main router as their default gateway. Use this layout for access-point coverage, not as a shortcut for selective routing unless the firmware explicitly supports the required policy routing.
Keep a recovery path throughout the change. Configure the bypass router while connected directly to it, and do not disconnect the main router’s administration path until you have confirmed both networks work. If a client receives an unexpected address, renew its lease or reconnect Wi-Fi before assuming the proxy core is at fault. A correct proxy configuration cannot repair an overlapping subnet, an unreachable gateway, or a DHCP lease that points to the wrong router.
Configure Clash or Mihomo on a supported router
Router support is the first gate. Some OpenWrt-based builds provide a maintained proxy interface and a compatible core; others require manual installation, have limited storage, or cannot run the required binary. Confirm that the firmware and core come from a source you trust, that the build supports the router’s processor, and that upgrades will not silently remove configuration files. Avoid flashing firmware based only on a generic model name: hardware revisions can use different flash layouts or wireless chipsets.
Once the core is available, import a configuration from a provider you trust or build a policy configuration appropriate to your network. Start with a small, understandable policy: a default group, a direct route for traffic that should remain local, and specific rules only where you have a clear reason for them. Do not assume that a router’s web interface translates every desktop option in the same way. Check which core version is running and whether the interface exposes the relevant settings for that version.
To let other devices use a listener on the router, confirm that the listener binds to an address reachable from the client network. A listener bound only to loopback is available to software on the router itself, not to a phone on Wi-Fi. Depending on the firmware, this may involve enabling LAN access, choosing an appropriate bind address, and allowing the listener port through the router’s firewall. Use the interface’s documented controls when possible rather than adding broad firewall exceptions by guesswork.
Treat a LAN-accessible proxy port as a service exposed to every device that can reach it. Do not forward it from the router’s WAN side to the public internet. If the core supports authentication for the listener, use it when appropriate; otherwise restrict access with the firewall to the intended LAN or client subnet. A guest Wi-Fi network may be isolated from the main LAN, so a phone on guest Wi-Fi might not be able to reach a listener even when both devices appear to be connected to the same physical router.
Decide whether router-wide handling or a listener-based setup is the better fit. A listener-based setup is explicit: a compatible device is configured to use the router’s HTTP or SOCKS endpoint. Router-level policy routing can cover more applications, including those without manual proxy controls, but it depends on the firmware’s support for client selection and traffic handling. DNS behavior, IPv6, local destinations, and traffic that does not use ordinary TCP can differ between implementations. Read the firmware’s documentation and test the traffic types your household actually relies on instead of assuming that one toggle captures everything.
Build a bypass-router path for selected devices
A bypass router is useful when you want a clear choice between the normal home connection and a proxy-managed connection. Connect the main router’s LAN to the bypass router’s WAN, assign the bypass router a non-overlapping LAN subnet, enable DHCP on that subnet, and create a distinct Wi-Fi name such as “Home-Proxy.” Configure Clash or Mihomo on the bypass router, then connect one test device to that network. Leave the original Wi-Fi name unchanged so household members can select the normal route without changing global settings.
If the router’s firmware supports per-client policy routing, you may be able to select devices by address, MAC address, or a named client entry. Reserve addresses for devices whose policy should remain stable; otherwise a DHCP lease change can make a rule appear to stop working. Keep the policy simple at first: choose a small number of test clients, select the intended route, and verify the result before adding televisions, consoles, or smart-home equipment.
A dedicated Wi-Fi network is often easier to explain and troubleshoot than a long list of address-based rules. A phone can join the proxy network when needed and return to the regular network afterward. For a television in a fixed location, the separate SSID can provide a stable choice, provided that the bypass router’s signal and throughput are sufficient. If the television cannot configure a proxy itself, placing it behind a router that performs the required network-level routing may be more practical than trying to enter a proxy address in an unsupported settings menu.
Avoid making an access point and a gateway do the same job accidentally. If you connect the second router by LAN-to-LAN, disable or carefully configure its DHCP service and verify the default gateway clients receive. If you connect by WAN-to-LAN, expect a separate subnet and possibly double NAT. Neither arrangement is universally superior; the right one follows from whether you need a second gateway, simple Wi-Fi coverage, or specific firmware features. Label the cables and router interfaces so a later reboot or household move does not turn a working layout into a guessing game.
For devices that need to move between rooms, check roaming behavior as well as routing. Two routers with different SSIDs make the path obvious but require a manual network switch. Matching SSIDs may encourage roaming, yet it can hide which gateway a device selected, especially when the networks are actually separate subnets. For the first deployment, distinct names are usually easier to diagnose. You can revisit a unified Wi-Fi design after you have confirmed that the gateway and policy behavior are reliable.
Choose which devices use the proxy
Think in terms of household roles rather than assuming every device needs the same treatment. A work laptop may need a direct corporate VPN and should not be moved behind another gateway without approval. A phone may be convenient to switch between networks. A smart television may need a stable route for streaming applications, while a printer or local file server should remain easy to reach from computers on the main LAN. Write down the desired path for each device before implementing rules; the list often reveals that only a few clients need the bypass network.
Consider local communication as carefully as internet access. A client on the bypass router’s separate subnet may not automatically discover a printer or NAS on the main network. Discovery protocols often rely on local broadcast or multicast traffic that does not cross a routed boundary by default. You might need a documented firewall allowance, a supported route, or simply to keep that device on the original LAN. Do not disable isolation or open every port merely to make discovery work; identify the required service and the two networks involved.
DNS should be part of the policy decision. A device can send web traffic through the selected proxy while still using a resolver from another network, producing confusing results or inconsistent access to local names. Check which DNS server the client receives, whether the router forwards DNS as intended, and whether the core’s configuration supports the DNS mode you plan to use. When testing, compare the client’s assigned gateway and DNS settings with the values expected for that Wi-Fi network. Avoid declaring success based only on one webpage loading.
IPv6 also deserves an explicit decision. Some home networks advertise IPv6 even when the proxy policy has been designed only for IPv4. In that situation, a device could use one path for IPv4 and another for IPv6, or lose connectivity when the routes do not match. Check whether the router and core support the intended IPv6 behavior. If they do not, use the firmware’s documented network controls to make a deliberate choice rather than assuming that an IPv4 test describes all traffic.
Keep an exception list for devices that should remain local or direct, and review it when network equipment changes. Guest devices, IoT equipment, work-managed endpoints, and devices with vendor-specific connectivity requirements may need separate treatment. A policy that works for a browser is not necessarily appropriate for a camera, printer, or console. Small, observable groups of devices are easier to manage than a household-wide rule whose side effects become visible only when someone is trying to print or join a game.
Test the path and troubleshoot in layers
Start with one client on the new network. Confirm that it receives an address from the expected subnet, has the intended router as its default gateway, and can reach the router’s management interface. Then verify that the Clash or Mihomo core is running and that the selected listener or routing policy is active. If the client cannot reach the gateway, investigate Wi-Fi association, cabling, DHCP, and subnet configuration before changing proxy rules.
Next, test ordinary connectivity and compare it with the expected route. Use the core’s connection log or dashboard, where available, to see whether the test device’s traffic reaches the router and which policy handles it. Test a local service as well as an internet destination. If internet access works but the printer disappears, the issue may be inter-subnet discovery or firewall policy rather than the proxy. If the device can reach the router but no traffic appears in the core, check listener binding, firewall rules, and whether the client is actually configured to use that listener.
When one application fails, test another application and another device before changing several settings at once. A browser may honor a manual proxy while a game or television application ignores it; that difference can be expected in a listener-only design. If every client on the bypass network fails, inspect the bypass router’s WAN address, default route, DNS settings, and core status. If only one client fails, compare its lease, DNS configuration, local proxy settings, and any private relay or VPN feature that could be overriding the route.
Make one change at a time and keep a brief record of the previous value. Router interfaces often combine DHCP, firewall, DNS, and policy settings on nearby pages, making it easy to solve one symptom while introducing another. After a configuration change, renew the affected client’s lease or reconnect it, then repeat the same test. Save a backup of the working router configuration and note the firmware and core versions; this is especially useful before upgrades, resets, or profile changes.
Desktop clients such as Clash Verge or Clash Verge Rev are usually simpler when only one computer needs a proxy, but they do not automatically provide a reliable household gateway, and exposing a desktop listener adds firewall and uptime responsibilities. Generic VPN-router features can be easier to find, yet they may not offer the per-device proxy policies or core visibility you need. A supported router or a carefully isolated bypass-router setup can give the household a clearer choice of gateway and device policy; for a maintained client workflow and downloads, visit Clash V.CORE downloads and choose the option that fits your devices and network.