Enable Clash LAN Proxy on Windows and macOS: Share Your Proxy With Multiple Devices

Why share Clash over the LAN?

Many households and small offices have one machine that is always on and already configured with a working Clash profile—rules, DNS, and node groups tuned for daily browsing. Smaller devices may not support your client of choice, or you may prefer not to paste subscription URLs into every phone. Pointing other devices at the same host’s proxy port is a practical pattern: one maintained configuration, multiple clients.

Clash listens on localhost by default so that random devices on the internet cannot reach your proxy. To accept connections from other machines on the same subnet, you must explicitly opt in with allow-lan: true and ensure the operating system firewall permits inbound traffic on the listener port. Skipping either step produces the classic symptom: the phone shows “proxy server refused connection” while the PC browser still works fine.

This article assumes you use a mainstream GUI such as Clash Verge Rev or a similar Mihomo-based client on Windows or macOS. The underlying ideas map to raw config.yaml as well; if you are still setting up the app itself, start with our Clash Verge Rev beginner guide before you layer LAN sharing on top.

Prerequisites: same network, stable host, correct port

Every device that should use the shared proxy must join the same Layer-2 network in practice. For most readers that means the same Wi-Fi SSID or the same Ethernet VLAN. Guest networks often isolate clients from each other; if your phone is on “Guest” and the PC is on “Home,” they may not see each other at all. Move both to a trusted SSID or disable client isolation for that segment if your router allows it.

Identify the host computer’s LAN IPv4 address. On Windows, open PowerShell or Command Prompt and run ipconfig; look for the active adapter’s “IPv4 Address,” often something like 192.168.1.42. On macOS, hold Option and click the Wi-Fi icon, or run ipconfig getifaddr en0 for typical Wi-Fi. Write this down; phones will point their HTTP or SOCKS proxy setting at this address, not at 127.0.0.1.

Decide which port Clash should expose. Modern configs usually define mixed-port, which serves both HTTP proxy and SOCKS5 on a single TCP port—commonly 7890. Some older files split port (HTTP) and socks-port (SOCKS). For simplicity, prefer a single mixed port so every client uses the same number for both schemes unless an app requires otherwise.

Enable allow-lan in configuration

Open your active profile in the client’s editor or navigate to the equivalent toggle in settings. At the top level of the YAML, set:

allow-lan: true
mixed-port: 7890

If your file still uses separate listeners, you might see port: 7890 and socks-port: 7891 instead. That is valid; just document both numbers for clients that only speak HTTP or only SOCKS. After saving, restart the core or apply the profile so the listener binds to 0.0.0.0 (all interfaces) rather than 127.0.0.1 only.

Some UIs expose “Allow LAN” as a switch that writes the same key behind the scenes. When in doubt, search the merged runtime config for allow-lan and confirm it reads true. If the key is missing or false, remote devices will always fail to connect even when the firewall is wide open.

Advanced users sometimes set bind-address to a specific interface IP instead of the default. That can tighten exposure on multi-homed machines, but misconfiguration here is a frequent cause of “works on the host, fails from the phone.” Until everything is stable, stick with defaults plus allow-lan: true.

Windows: allow inbound connections on the mixed port

Windows Defender Firewall blocks unsolicited inbound TCP connections by default. Clash binds locally without triggering a prompt in many builds, but LAN peers count as inbound from the firewall’s perspective. Create an explicit allow rule for the mixed port.

• Open “Windows Defender Firewall with Advanced Security” from the Start menu.
• Choose Inbound Rules → New Rule.
• Select Port, TCP, and specify the port number (for example 7890).
• Allow the connection, apply it to Private (and Domain if you use it); avoid Public profiles on untrusted hotspots.
• Name the rule clearly, e.g. “Clash mixed port LAN.”

If you use third-party security suites, mirror the same exception there; they often wrap Windows Firewall with stricter defaults. After the rule exists, test from another device using a browser or curl through the proxy. If it still fails, temporarily disable the suite to isolate whether the block is OS-level or product-level—then re-enable and adjust.

Corporate-managed PCs may apply Group Policy that forbids inbound rules. In that environment you cannot safely “share Clash” without IT approval; treat this guide as for personal or self-administered hardware only.

macOS: Application Firewall and listener access

On macOS, open System Settings → Network → Firewall (exact path varies slightly by OS version). If the firewall is off, inbound connections to Clash are only limited by the app itself. If the firewall is on, you may need to allow incoming connections for your Clash client binary when macOS prompts, or add it under the allowed list.

“Block all incoming connections” mode is the strictest profile. It can interfere with any daemon that should accept LAN peers. For home use, consider switching to the standard firewall mode and approving Clash once, or temporarily relax the setting while you test. As on Windows, prefer rules scoped to private networks when the OS offers that distinction.

Remember that Apple’s Application Firewall is not identical to a perimeter router firewall. You still need correct allow-lan settings in Clash. macOS updates occasionally reset firewall prompts; if LAN sharing suddenly breaks after an upgrade, re-check whether Clash still has permission to accept inbound traffic.

Configure phones, tablets, and other PCs

On iOS and Android, open the Wi-Fi details for the current network and find the HTTP proxy section. Choose manual configuration, set the server to your PC’s LAN IP, and set the port to the mixed port (for example 7890). For SOCKS-aware apps, supply the same host and port but select SOCKS5 if offered separately.

System-wide HTTP proxy settings on mobile OSes affect Safari and many built-in apps, but some applications ignore them and use their own stacks. Chat apps, games, or custom browsers may need in-app proxy fields or a per-app VPN solution instead. Expect “mostly works” rather than perfect coverage everywhere.

On another Windows or macOS machine, you can either mirror manual system proxy settings or install a lightweight client that points upstream to your host’s HTTP/SOCKS port without importing the full subscription. Either way, the remote machine is now a consumer of the first PC’s Clash instance; policy, rules, and node selection happen on the host.

For command-line tools on a secondary laptop, export HTTPS_PROXY=http://192.168.1.42:7890 and ALL_PROXY=socks5://192.168.1.42:7890 in the shell profile, adjusting the IP to match. Some CLI utilities respect only one scheme; consult each tool’s documentation when downloads still go direct.

LAN security: what you expose when you enable allow-lan

Turning on allow-lan effectively advertises an open HTTP and SOCKS endpoint on your private subnet. Anyone who can reach that IP and port—family members, roommates, or a compromised device on the same Wi-Fi—may route traffic through your Clash instance. That can impact bandwidth, violate acceptable-use expectations for your exit nodes, or leak browsing metadata to whoever controls the host.

Stock Clash-family cores do not ship with per-user passwords on the proxy port the way some enterprise HTTP proxies do. Authentication is usually handled upstream by your provider, not at the SOCKS layer on your LAN. Treat LAN sharing as suitable for trusted networks only: your home SSID with a strong WPA3 passphrase, not the coffee shop.

If you need stricter isolation, consider segmenting IoT gadgets to a VLAN that cannot reach your PC, or run Clash only when guests are offline. Some advanced setups combine firewall rules so only certain client MAC addresses may connect to the mixed port; that is outside the scope of this tutorial but worth exploring on routers that support static DHCP reservations and ACLs.

Never expose the mixed port directly to the public internet through port forwarding on your router. If you require remote access, use a VPN back into the home network first, then connect to the proxy as if you were on LAN. The external-controller REST API, if enabled, should remain bound to localhost or protected behind authentication; accidentally publishing 9090 to WAN is a separate class of risk covered in our broader troubleshooting guide.

Troubleshooting common LAN sharing failures

Clients cannot connect at all

Verify the phone and PC share the same subnet, re-check allow-lan: true, and confirm Windows or macOS firewall rules. Ping the PC from another device; if ICMP fails, fix routing or isolation before blaming Clash.

Works until DHCP renews

Consumer routers may reassign addresses. Set a DHCP reservation or static IP for the host so clients do not silently point at a stale IP after a reboot.

Hotel or public Wi-Fi blocks peer-to-peer

Many public networks prevent device-to-device communication altogether. LAN sharing cannot work there; use a local client or a different connectivity strategy.

Sites load but DNS looks wrong

Remote clients might still use their own DNS servers while HTTP traffic flows through Clash. If you rely on fake-ip or encrypted DNS on the host only, expect differences in resolution behavior on phones. Aligning DNS settings on the client—or accepting that split—reduces confusion.

When in doubt, collect logs from the Clash core and compare timestamps with connection attempts from the secondary device. Our troubleshooting article walks through port conflicts, subscription issues, and log interpretation that also apply when LAN sharing is enabled.

Summary

Sharing Clash on a LAN is a three-part problem: tell the core to accept non-local peers with allow-lan, publish a clear mixed-port (or matching HTTP/SOCKS pair), and teach the operating system firewall to allow that TCP port on trusted profiles. Point other devices at the host’s IPv4 address and port, understand that mobile apps vary in proxy support, and treat the feature as a convenience for trusted networks—not a substitute for perimeter security or authenticated enterprise proxies.

Compared with juggling separate subscriptions on every gadget, a single well-maintained Clash instance on a PC is easier to audit and update. When you pair that stability with a clean official client build, routine maintenance stops feeling like a chore. → Download Clash for free and experience the difference