Clash Multi-Device Sharing: Home Network Setup Guide

Clash can serve more than the computer on which it is installed. With the right listener, firewall rule, and client configuration, a desktop, mini PC, or router can become a shared proxy gateway for phones, tablets, televisions, game consoles, and other devices on the same home network. The important distinction is that sharing a proxy is not the same as sharing a subscription. The device running Clash must accept connections from the LAN, and every client device must be configured to send traffic to that device.

A reliable home-network design has four separate parts: the Clash core, the listening port, the local network path, and the routing policy. A configuration may contain valid nodes and still fail for other devices because allow-lan is disabled, the listener is bound to loopback only, the operating-system firewall blocks the port, or the client device is connected to an isolated guest network. Start with a small, controlled setup, verify one device at a time, and only then add TUN mode, DNS interception, or more complex rules.

Choose the device that will provide the shared proxy

There are three common ways to provide Clash access to multiple devices. The first is to run Clash on a computer and configure the computer’s LAN address as the proxy server for other devices. This is the fastest method for testing because graphical clients usually expose port settings, LAN access, and connection logs in one place. Its limitation is availability: the computer must remain powered on, connected to the home network, and allowed to accept inbound LAN connections.

The second method is to run Clash or mihomo on a router, home server, or always-on mini PC. This is more suitable when phones, televisions, and smart devices should use the proxy without depending on a personal laptop. It requires more network knowledge, because the service may run in a container, a separate VLAN, or a router operating system with its own firewall and policy-routing rules.

The third method is to use the Clash host as a gateway rather than an ordinary HTTP or SOCKS proxy. In this model, clients send their traffic through the host at the IP layer, commonly through TUN, transparent proxy, or router-level redirection. This can cover applications that ignore manual proxy settings, but it also introduces route conflicts, DNS handling decisions, permission requirements, and a larger troubleshooting surface. For most households, explicit HTTP or SOCKS proxy settings should be the first stage.

For the host address, prefer a DHCP reservation on the router, such as 192.168.1.20, instead of relying on a temporary address assigned by DHCP. A reservation keeps the address stable while allowing the router to manage the lease. Avoid choosing an address that is already in use. From another device, confirm the address with the router’s connected-device list or by checking the host network interface.

Understand LAN access, listener ports, and bind addresses

Clash does not automatically become a network proxy merely because the desktop client is running. The core normally exposes listeners for local applications, and many default configurations bind those listeners to 127.0.0.1. Loopback is reachable only from the same host. A phone attempting to connect to 127.0.0.1:7890 is connecting to itself, not to the computer running Clash.

For a shared setup, the configuration must permit LAN access and bind the listener to an address reachable from the home network. A common mihomo-style baseline looks like this:

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

external-controller: 127.0.0.1:9090

proxies: []
proxy-groups: []
rules:
  - MATCH,PROXY

mixed-port lets a listener accept both HTTP and SOCKS5-style client connections in clients that support the mixed-port feature. If the core or client uses separate listeners, configure an HTTP port such as 7890 and a SOCKS port such as 7891 instead. Do not assume that every Clash client exposes exactly the same fields. Clash Verge, Clash Verge Rev, and other mihomo-based clients may place these controls under Settings, General, Profiles, or Proxies, while some router packages edit the YAML directly.

allow-lan: true permits connections from other local interfaces. It does not by itself guarantee that every interface is reachable. bind-address: "*" listens on available interfaces, but a more restrictive address is preferable when the client supports it. Binding to the host’s LAN address, for example 192.168.1.20, reduces accidental exposure through another interface such as a public Wi-Fi adapter, VPN adapter, or virtual machine bridge.

The external-controller port is different from the proxy port. It is used by management interfaces and APIs, not by ordinary client traffic. Keep it on 127.0.0.1 unless remote management is specifically required. Never publish the controller API to the LAN without authentication and a clear reason, because access to the controller may allow configuration changes or proxy-group switching.

Hands-on setup: connect one device through the Clash host

The following procedure uses a computer or home server at 192.168.1.20 and a mixed proxy listener at port 7890. Replace both values with the actual address and port shown by the client. The example assumes that the phone or test device is connected to the same non-guest Wi-Fi network as the host.

1. On the Clash host, import a configuration that already starts successfully. Confirm that the selected proxy group contains usable nodes and that the host itself can load a test website through Rule mode.
2. Open the client’s settings or profile editor and enable LAN access. If a YAML editor is available, confirm allow-lan: true and set a suitable bind-address. Save the profile and reload the core.
3. Record the actual listener port. In many desktop installations the value is 7890, but a previous application, a client override, or a router package may use another port.
4. Allow inbound TCP access to that port on the host firewall, limited to the home subnet if possible. For a typical network, the allowed range may be 192.168.1.0/24. Add UDP only when the selected client and traffic mode explicitly require it.
5. On the test phone or tablet, open the current Wi-Fi network settings. Choose manual proxy configuration and enter the host address 192.168.1.20 and port 7890. Leave proxy authentication empty unless the listener is configured to require it.
6. Open a normal HTTPS website and watch the Clash connections or logs. A request from the test device should appear with the selected rule and policy group. If the device reports a connection failure immediately, check the address, port, Wi-Fi isolation, and firewall before changing nodes.
7. After confirming the phone works, test a second device. Use a separate browser or application so that cached results do not conceal a routing failure.

Some platforms distinguish between HTTP proxy and SOCKS proxy fields. If the listener is a mixed port, start with the HTTP proxy field because many operating systems and televisions support it more consistently. If the application specifically supports SOCKS5, use the SOCKS listener and select the correct protocol. Do not enter a URL such as http://192.168.1.20:7890 into a field that expects only a hostname or IP address.

For a computer host, prevent sleep during testing and check whether the network profile is marked Private or Trusted. Windows Defender Firewall, macOS application permissions, Linux nftables, container port publishing, and router ACLs can each block the same connection at a different point. A local test on the host proves only that the core is running; a successful test from another LAN device proves that the listener, route, and firewall are working together.

Build a predictable routing and DNS policy

Once LAN forwarding works, decide whether all household traffic should use the same policy. A shared proxy does not require every device to follow an identical route. Phones may need common domestic services to go DIRECT, while selected overseas domains use a proxy group. A television may need a narrower policy because streaming services react differently to shared exits. Keep the policy understandable before adding device-specific exceptions.

A typical rule order places private networks and local services before broader domain rules, with a final MATCH rule at the end:

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - RULE-SET,private,DIRECT
  - RULE-SET,proxy,PROXY
  - MATCH,DIRECT

The exact rule providers and policy names must exist in the active configuration. If the rule references a group called PROXY but the configuration defines Proxy or Auto, matching may fail or the core may reject the profile. Keep local subnets direct so that printers, router dashboards, NAS interfaces, and casting devices do not leave the home network unnecessarily.

DNS deserves separate attention in a multi-device design. When a phone sends a domain query to the normal router DNS but sends the subsequent connection to Clash, the returned address may not align with the intended rules. When the Clash host handles DNS, decide whether clients should use the router’s DNS, a dedicated DNS listener, or a gateway-level DNS redirect. Do not advertise a DNS address that is not actually listening. A DNS listener on 1053 is not the same as a regular DNS service on port 53, and ordinary devices usually cannot use an arbitrary port in their Wi-Fi DNS field.

Fake-IP mode and redirection can improve compatibility with some rule systems, but they also affect local discovery, printers, games, and applications that expect real address responses. Begin with a tested DNS mode and preserve the original profile. If only domain-based applications fail while direct IP tests work, inspect DNS logs and the selected resolver path rather than replacing the proxy node immediately.

Match each household device to the right connection method

Manual proxy settings are appropriate for devices that clearly expose an HTTP or SOCKS field. Desktop operating systems, Android Wi-Fi settings, some media players, and many browsers can use this approach. It is easy to disable and usually affects only traffic generated by that device. The main limitation is that applications may ignore the operating-system proxy or use a separate network stack.

Do not assume that a device configured for the home Wi-Fi proxy will continue using it on mobile data, another access point, or a mesh node with client isolation. Guest networks commonly block access to private LAN addresses by design. Some mesh systems also place wireless clients and wired clients into separate segments. If a phone can browse the internet but cannot reach 192.168.1.20:7890, inspect the network topology before editing Clash rules.

Router-level sharing is useful when a device has no proxy controls, but it should be introduced after explicit proxy forwarding is proven. A router may use policy-based routing, transparent redirection, or a TUN-like tunnel. These methods can affect every device simultaneously, including banking applications, local services, firmware updates, and work systems. Add device groups or bypass rules where the router platform supports them, and keep an emergency path for disabling the policy if the gateway configuration interrupts normal internet access.

Secure, monitor, and maintain the shared setup

A LAN proxy listener should be treated as a network service, not as a harmless local switch. Anyone who can reach an unauthenticated listener may be able to consume bandwidth, use your proxy exit, or send requests through your household connection. The first control is network scope: bind to the trusted LAN interface when practical, restrict the firewall to the home subnet, and keep the router’s guest and IoT networks separated unless they genuinely need access.

The second control is management isolation. Keep external-controller on loopback, set an authentication secret when remote management is necessary, and do not forward either the proxy port or controller port from the router to the public internet. UPnP and automatic port-mapping features should be reviewed because they can create exposure without an obvious manual firewall rule.

• Use a stable host address: Create a DHCP reservation and document the address, proxy port, and host device.
• Limit firewall scope: Allow the proxy port from the trusted home subnet instead of from every interface and network.
• Protect the controller: Keep the management API on loopback or require strong authentication and restricted access.
• Watch connection logs: Unexpected source addresses, repeated authentication failures, or unexplained bandwidth usage deserve immediate investigation.
• Preserve a known-good profile: Export the working configuration before changing DNS, TUN, rule providers, or gateway routes.
• Update deliberately: Verify core compatibility after a client update, especially when the profile uses mihomo-specific fields.

When the first device stops working, identify the failure boundary instead of switching every setting. If the client device cannot establish a TCP connection to the host port, inspect Wi-Fi isolation, the host address, firewall rules, and whether the core is listening. If the TCP connection succeeds but no website loads, check the proxy protocol, selected policy group, DNS behavior, and logs. If only local devices fail while the host works, review LAN rules and bind settings. If all devices fail after enabling TUN or transparent routing, restore the explicit proxy baseline and investigate route conflicts separately.

A practical household configuration should remain reversible. Record the original Wi-Fi proxy setting on each device, keep the router’s direct-access path available, and label the shared host clearly. Test after a node switch, subscription update, host reboot, and router reboot. When a client reports an unchanged public exit address, confirm that the application actually uses the manual proxy; when a local printer disappears, confirm that private subnets and multicast-dependent discovery were not forced through the proxy.