Clash LAN Sharing Fails on Your Phone? Fix Firewall, Bind Address, and Subnet

Why “Allow LAN” Alone Does Not Guarantee Reachability

The phrase allow LAN connections (or equivalent wording in your GUI) is doing one specific job: it tells the Clash core that inbound connections from non-local addresses should be accepted at the application layer, assuming the process is already listening on an address the kernel will route to. It does not automatically rebind listeners from 127.0.0.1 to your Ethernet or Wi-Fi interface, and it does not create firewall exceptions in Windows Defender or pf on macOS. Think of it as flipping an internal permission bit, not as punching every hole the operating system might still block afterward.

That distinction matters because many users follow a believable but incomplete story: “I toggled LAN, so the proxy must be reachable.” If the mixed port is still bound to loopback, your phone can ping the PC and still fail to open a TCP session to the proxy port, because nothing is listening on the LAN IP at all. Likewise, if the listener is correct but the firewall drops SYN packets from Wi-Fi clients, the symptom is identical from the phone’s perspective: endless loading, captive-portal-like behavior, or instant connection refused depending on timing and caching. Separating routing reachability, socket binding, and host firewall policy is the whole game.

If you are new to splitting those concerns, pairing this walkthrough with a client that exposes clear connection diagnostics helps. Our guide to choosing a Clash client highlights platforms where ports, bind modes, and logs are easy to inspect, which shortens the feedback loop when something on the LAN behaves oddly.

Same Subnet, Correct Gateway: Map the Network First

Before touching Clash again, confirm the boring network facts. Your phone and your computer must participate in a single Layer-3 environment where the phone’s default gateway can forward traffic toward the PC’s address, and where no intermediate device is filtering client-to-client forwarding. On a typical home router, both devices obtain addresses in something like 192.168.1.0/24, and the phone’s traffic to 192.168.1.42 is switched locally without crossing the ISP. That is the happy path for a manual HTTP or SOCKS configuration aimed at the PC.

Things go sideways when you mix topologies. A phone on cellular data while the PC sits on Ethernet is not going to use the PC as a gateway unless you have deliberately engineered tethering or VPN routes—do not expect magic. Similarly, some mesh systems or “smart” APs expose a separate IoT VLAN or guest SSID that looks like the same Wi-Fi name with a different password but actually lands on a different subnet with client isolation enabled. If the phone shows an address in 192.168.50.x while the PC is on 192.168.1.x, you are not dealing with a subtle Clash bug; you are on the wrong network segment for naive LAN proxying.

Write down three numbers from the PC side: IPv4 address, subnet mask or prefix length, and default gateway. Repeat on the phone. If they disagree in ways you did not intend, fix Wi-Fi association or disable guest mode before spending an hour editing YAML. For broader connectivity triage when proxies are involved, the FAQ section on connectivity and DNS explains how split stacks and resolver settings interact with rule-based tools, which becomes relevant once basic LAN reachability is restored.

Hotspot and USB tethering wrinkles

When the PC shares its connection by hosting a mobile hotspot, Windows and macOS often assign the phone an address on a small private range served by the PC itself. That can work beautifully with Clash as long as you target the PC’s hotspot-facing IP, not the address you remember from Ethernet. After switching between “PC joins Wi-Fi” and “PC creates hotspot,” re-read the adapter list: the relevant IPv4 for phone-to-PC tests is the one on the same interface the phone uses.

Bind Address: Loopback, All Interfaces, or a Specific LAN IP

Clash-family cores expose inbound listeners for the mixed port, HTTP, and SOCKS according to your profile. The crucial YAML fields are commonly named along the lines of bind-address or appear alongside mixed-port, port, and socks-port in Meta-compatible configurations. When bind-address is 127.0.0.1 or localhost, only local processes on the PC may connect. That is appropriate for a single-user workstation and disastrous for LAN sharing. Setting it to *, 0.0.0.0, or an empty value (depending on the core’s documented default) asks the stack to listen on all IPv4 interfaces, which is what you want when other devices must dial in.

Some users prefer binding explicitly to one LAN IP, especially on laptops that simultaneously carry Wi-Fi, Ethernet, and VPN tunnels. Pinning the listener to 192.168.1.42 avoids accidental exposure on an interface you did not intend to share. The trade-off is operational: if DHCP gives you a different address tomorrow, the phone profile breaks until you update both sides. For home labs with static DHCP leases, explicit binding is tidy; for cafés and hotels, all-interfaces binding plus a firewall scoped to the active subnet is often less brittle.

After editing the configuration, restart the core and verify with a local command that shows listening sockets. On Windows, netstat -ano | findstr <port> is enough to see whether you are bound to 0.0.0.0 or 127.0.0.1. On Linux, ss -lntp tells the same story without ambiguity. If you still see loopback-only while the GUI claims LAN is allowed, you have found the mismatch: policy toggles do not override an explicit restrictive bind in the file.

mixed-port: 7890
bind-address: '*'

HTTP, SOCKS, and Mixed Ports: What the Phone Must Match

Manual proxy settings on iOS and Android ask for a host, a port, and a type. If you aim the phone at the SOCKS port but only the HTTP listener is enabled—or you copied the mixed port while the profile actually split services across 7890 and 7891—your symptom will be immediate failure or partial breakage where only some apps work. Mixed ports exist precisely to reduce that confusion by exposing one inbound port that negotiates both HTTP proxy and SOCKS semantics according to what connects, but not every third-party stack documents that clearly on the phone side.

When you standardize on a mixed port, keep the number consistent in three places: the YAML or GUI on the PC, the Wi-Fi advanced proxy dialog on the phone, and any per-app override inside alternative clients. A surprisingly common mistake is updating the GUI while an old config.yaml on disk still pins a different port for headless runs. If you alternate between a tray app and a background service, confirm which file each launcher reads. For Android-only workflows that eventually move between LAN proxying and on-device cores, the per-app proxy overview for Clash Meta on Android explains how UID routing interacts with your rules once packets actually reach the proxy.

Authentication is another footgun. If you enabled secret tokens or user-password pairs for the inbound listener, the phone must supply them. An unauthenticated phone connecting to an authenticated port looks like random failure unless you read the core log lines about auth rejection. Keep testing simple while you prove connectivity: disable optional inbound auth temporarily, establish stable LAN access, then reintroduce secrets deliberately.

Firewall Rules on Windows, macOS, and Linux

Assuming bind settings and subnets are sane, host firewalls are the next high-probability blocker. Desktop operating systems default to a posture that treats unsolicited inbound TCP to random application ports as suspicious. Clash is not special-cased in those policies unless you add an allow rule or approve a prompt the first time the listener comes up on a new network profile.

On Windows, open Windows Defender Firewall with Advanced Security and look for inbound rules tied to your Clash executable or the specific TCP ports you expose. A quick diagnostic test is to toggle the firewall off very briefly for the active profile—if LAN sharing instantly works, you have confirmed the category of problem and should replace that experiment with a narrow allow rule targeting only your LAN subnet and only the needed ports. Avoid leaving the firewall fully disabled; document the rule you added so future upgrades that change binary paths do not silently revert access.

On macOS, Application Firewall and third-party security tools can both interfere. Because the listener is local to your user session, check whether “Block all incoming connections” is enabled globally. If Little Snitch or similar tools prompt for each new build, approve the Clash binary explicitly for incoming connections from local networks. For command-line verification, lsof -iTCP:<port> -sTCP:LISTEN combined with a LAN-side nc -vz <pc-ip> <port> test from another machine tells you whether packets reach the process.

On Linux desktops, ufw, firewalld, and distribution defaults vary widely. A minimal pattern is to allow the relevant TCP ports from your LAN bridge only, for example using ufw allow from 192.168.1.0/24 to any port 7890 proto tcp after substituting your actual range. If you run Clash inside a container or namespace, remember that published ports must map through Docker or Podman rules as well—what works on bare metal fails silently when the process listens inside a bridge network. Server-oriented readers who also manage transparent modes may cross-check with the Ubuntu TUN and systemd guide for how kernel-level forwarding interacts with application ports, even though this article focuses on explicit HTTP/SOCKS hops.

Hotspots, Guest Wi-Fi, and Client Isolation

Enterprise and retail access points sometimes implement AP isolation (also called client isolation or guest protection). Under that mode, two phones on the same SSID cannot talk to each other—or to a laptop sharing proxies—even though both have valid DHCP leases and internet upstream. The router enforces it on purpose to keep untrusted guests from scanning each other. Home gear occasionally exposes the same toggle under “Wi-Fi security enhancements.” If every LAN test from another wireless client fails while Ethernet-to-Ethernet tests succeed, suspect isolation before Clash.

Carrier-branded hotspots embedded in routers may also perform symmetric NAT tricks that complicate return traffic for uncommon port-forwarding scenarios. Explicit HTTP/SOCKS from a phone to a PC on the same /24 is usually unaffected, but if you layered additional tunnels or tried to chain multiple proxies, the failure modes multiply. Simplify: one hop from phone to PC, one listener, one subnet, then add complexity back.

IPv6 deserves a short mention. If your network advertises global IPv6 but your Clash listener is IPv4-only, some mobile stacks might prefer AAAA records and stall in ways that look like proxy failure. While debugging, forcing the phone to IPv4-only Wi-Fi or disabling IPv6 temporarily on a test interface can isolate that class of issues. Longer term, align listener families with what your LAN actually routes.

Sanity Checks From the PC and From the Phone

Work through this ladder deliberately; skipping steps is how people end up editing DNS rules when the firewall was the entire problem.

1. Confirm addresses on PC and phone; ensure they share a routable path without guest isolation.
2. Ping the PC from the phone; ICMP success proves basic L3 adjacency, though some devices block ping—interpret carefully.
3. Probe the TCP port with a network utility from the phone or from another LAN host using curl or nc; you want a quick connect or an HTTP 400-series response from the proxy, not a timeout.
4. Test from the PC against its own LAN IP using a browser or curl; if that fails, fix bind and firewall before involving mobile stacks.
5. Read the core log while attempting a phone connection; rejected handshakes and auth failures are explicit once logging is verbose enough. For log vocabulary beyond LAN issues, see the timeout and TLS log guide.
6. Retest with security software temporarily relaxed only to identify the responsible layer, then restore protection with narrower rules.

Document what changed when it finally works: the bind line, the exact port integer, and the firewall wording. Future-you troubleshooting at midnight will appreciate the precision.

Wrap-Up: Evidence Before Tweaking Rules

LAN sharing problems feel opaque because phones do not surface socket-level errors as clearly as desktop browsers. Yet the failure modes are finite: wrong subnet, loopback bind, mismatched port type, host firewall, or isolated Wi-Fi. Once you verify each layer with small, repeatable tests, Clash’s rule engine becomes relevant again—until reachability is sound, no amount of DOMAIN-SUFFIX polish will make the phone’s packets appear at the mixed port.

Compared with opaque one-click tools that hide how listeners are bound, a maintained client with transparent settings and readable logs lets you treat LAN sharing as a network engineering task with a checklist instead of a superstition. That transparency pairs well with profiles that evolve over time, because you can separate infrastructure fixes from subscription issues cleanly.

→ Download Clash for free and experience the difference once your bind address, firewall, and subnet checks are aligned.