Fix Clash Allow LAN on Phone: Binding, Mixed Port, and Firewall Checklist

What This Guide Covers

You already run Clash (or a Mihomo-based GUI such as Clash Verge Rev) on a Windows PC or Mac. The subscription updates, nodes show latency, and the browser on that machine uses the proxy as expected. Then you open Wi-Fi settings on a phone or tablet, point manual HTTP or SOCKS proxy to the computer’s LAN IP and port, and nothing loads—or pages work briefly, then stall until you toggle airplane mode. That pattern is extremely common, and it rarely needs exotic YAML. It needs a clean pass through listen scope, Clash Allow LAN, which port actually speaks which protocol, and whether the operating system or router silently blocks inbound LAN connections.

This article complements platform-specific walkthroughs. After the LAN path is stable, you can deepen desktop setup with our Clash Verge Rev on Windows and macOS tutorial, or move the proxy entirely onto the handset using FlClash on Android and Stash on iPhone when you prefer a device-local tunnel instead of a shared PC hop.

Step 1: Prove the Phone and PC Are on the Same Routed LAN

Before touching Clash, confirm the phone can reach the PC at the IP you plan to use. Many “Allow LAN is on but nothing works” tickets are actually different Layer-3 networks: the phone on guest Wi-Fi while the laptop sits on the primary SSID, corporate split tunneling that isolates BYOD, or a mesh satellite that hands out a guest VLAN without obvious labeling. On the computer, note the IPv4 address of the active interface (for example 192.168.1.42 on Wi-Fi or Ethernet). On the phone, compare the first three octets—or, on IPv6-only setups, verify you are not accidentally mixing a ULA prefix on one side with a global address on the other.

If the phone cannot open even a simple LAN service—try pinging from another device or visiting a temporary static file the PC serves—you are not ready to debug Clash. Fix routing or SSID choice first. AP isolation (sometimes labeled “client isolation” or “station isolation”) on the access point prevents wireless clients from talking to each other; consumer routers often enable it by default on guest networks. Moving both devices to the main SSID, or disabling isolation for a trusted segment, is mandatory for LAN proxy sharing.

Step 2: Bind Address and Clash Allow LAN

By default, many profiles bind the HTTP and SOCKS listeners to 127.0.0.1, which intentionally rejects remote peers. For LAN proxy access you need listeners on 0.0.0.0 (all interfaces) or explicitly on the LAN IP. GUI clients usually expose this as “Allow connections from the LAN” or Allow LAN; flipping the toggle without restarting the core sometimes leaves stale sockets, so after you change bind settings, restart the Clash or Mihomo process once.

In raw YAML, look for bind-address at the top level and per-listener overrides. Mixed mode has its own listener: if you aim the phone at mixed-port while only port is opened to the LAN, the symptom is an immediate connection refused. Symmetrically, sending HTTP CONNECT to a port that only speaks SOCKS fails with protocol errors that browsers surface as generic timeouts. Align the GUI toggle, the numbers shown in the dashboard, and what you type into the phone.

Step 3: HTTP Port, SOCKS Port, and Mixed Port

Clash exposes separate concepts: a plain HTTP proxy listener, a SOCKS5 listener, and optionally a mixed port that accepts both families on one TCP port. Mobile operating systems ask you to pick a scheme: iOS manual proxy is HTTP/HTTPS oriented; some Android builds expose separate SOCKS fields in advanced menus. If your documentation says “use port 7890” but your active profile moved HTTP to 7892 and mixed to 7890, you will chase ghosts until you read the live status panel.

When you standardize on mixed port for phones, you reduce configuration drift: one number on the LAN, one inbound firewall rule, one mental model. Document that port on a sticky note near the router; future you will not have to rediscover whether the household rule was written for legacy HTTP only. If you must keep separate ports for compatibility with older scripts, duplicate firewall allowances rather than reusing a single ambiguous rule name.

Step 4: Quick Reachability Tests Before Blaming Rules

From a second laptop on the same subnet, run nc -vz PC_LAN_IP MIXED_PORT or use PowerShell’s Test-NetConnection on Windows. If TCP SYN completes there but the phone fails, suspect phone-side proxy fields or per-app VPNs that bypass manual proxy settings. If both fail, return to bind address and firewalls. These checks intentionally precede Clash policy debugging: no MATCH rule matters until the TCP session reaches the listener.

Remember that system proxy on iOS does not tunnel UDP games the way a full VPN client does, and some apps ignore manual proxy entirely. That can look like “Clash is broken” when the browser works through the proxy but a chat app uses a direct socket. For full-device capture you either install a VPN-style client on the phone—see again the Stash and FlClash guides—or enable TUN on the PC and route phones through that PC as a gateway, which is a different topology than a simple HTTP hop.

Step 5: Windows Defender Firewall Inbound Rules

On Windows, enabling Allow LAN inside Clash does not automatically create a matching inbound rule. Defender Firewall may still block external profiles or even private networks if the interface was classified as Public after a driver update. Open Windows Security → Firewall & network protection → Advanced settings → Inbound Rules, and look for existing entries tied to your GUI executable or mihomo.exe. If none exist, create a rule that allows TCP on your mixed or HTTP port, scoped to private subnets (for example 192.168.0.0/16, 10.0.0.0/8) rather than the entire internet.

Corporate laptops sometimes ship with a third-party endpoint agent that superseded Defender. In that case the UI path differs, but the logic repeats: permit inbound TCP to the Clash listener from the LAN segment. After you add a rule, disable it once to confirm you actually fixed the right layer—if behavior is unchanged, you were chasing a red herring and should return to bind address or guest Wi-Fi isolation.

Also verify the Wi-Fi network is classified as Private on Windows 11. A profile flipped to Public after joining a café hotspot can tighten firewall policy even when you are back home, because Windows caches the category per SSID. Reclassify the home network, then retest from the phone without rebooting the router first; if that alone fixes the issue, document the SSID category so the next OS upgrade does not surprise you.

Step 6: macOS Application Firewall and Stealth Mode

macOS combines application firewall decisions with code signature prompts the first time a binary listens widely. If you previously clicked “Deny” for incoming connections on a Clash helper, the OS will continue blocking until you reset the decision under System Settings → Network → Firewall → Options (wording varies slightly by macOS version). Toggle the specific app to allow incoming, or temporarily disable the firewall for a controlled test on a trusted home LAN only—then re-enable with explicit allowances.

Stealth mode ignores ICMP echo requests; that does not block TCP proxy ports, but it confuses users who ping the Mac from the phone, conclude the host is offline, and never attempt a TCP connection. Prefer nc or a browser test against the proxy port instead of ping for validation. If Little Snitch, Lulu, or another filter runs, add bidirectional rules for Mihomo and your GUI bundle IDs; silent drops there mirror Defender symptoms.

Step 7: Router Guest SSIDs, VLANs, and IPv6 Surprises

Guest networks exist to keep visitors away from printers and NAS devices. That is exactly the behavior that breaks LAN proxy sharing with a trusted phone. Move the phone to the primary LAN or create a dedicated IoT-style SSID without isolation if your vendor supports it. On advanced setups with VLANs, ensure mDNS or broadcast is not required for your test—Clash uses unicast TCP—but inter-VLAN firewall ACLs must still permit phone subnet → PC IP:port.

IPv6 adds a twist: if the phone prefers AAAA records and attempts a direct path while your proxy entry only covers IPv4 literals, some stacks half-connect or fall back slowly. For deterministic tests, temporarily configure the phone proxy using the PC’s v4 address only, or add v6 listeners and mirrored firewall scopes if you run dual-stack intentionally.

Step 8: Intermittent Drops, Sleep, and Roaming

Laptops that sleep close the Wi-Fi radio; phones keep retrying against a silent host. Desktop PCs with aggressive “modern standby” can exhibit the same. If your symptom is “works for an hour, then dead until I wake the PC,” adjust power settings or move Clash to a small always-on box such as a home server. Roaming between mesh nodes can also change subtle ARP timings; usually TCP survives, but if you see bursts of failures, static DHCP reservations for the PC reduce churn.

Another intermittent pattern is port collision after an update: a second process grabs 7890, Clash silently shifts, and the phone still targets the old number. After each upgrade, glance at the listener list in the GUI log panel and update the phone field the same day.

Step 9: Authentication, Logging, and Household Safety

Open LAN listeners without credentials mean anyone on the café Wi-Fi could use your proxy if you repeat this setup outside the home. Prefer home-only SSIDs, consider enabling secret-based auth if your build supports it, and turn off Allow LAN before you join untrusted networks. Logging on the core helps you notice unexpected source IPs; a sudden burst of flows from a neighbor’s device is a strong hint that isolation failed or your SSID is shared too widely.

Step 10: When the LAN Path Works but Apps Still Ignore It

Once TCP reaches Clash and you see access logs from the phone’s IP, yet certain apps still bypass, you have crossed into per-app networking behavior, not Allow LAN. Android OEM battery tools, iOS Low Data Mode, and VPN profiles can all coexist oddly with manual proxy. Our Clash Android troubleshooting guide walks battery and VPN interactions; iOS-specific tunnel behavior is covered in the Stash article linked earlier. For desktop-only transparent routing concepts that inspire hybrid designs, see the Clash TUN mode guide.

Copy-Paste Checklist Summary

Use this order on every ticket: confirm same subnet and no AP isolation; set listeners to 0.0.0.0 or LAN IP with Clash Allow LAN; align phone fields with HTTP, SOCKS, or mixed port; verify TCP with a second machine; add Windows inbound rules or macOS incoming allowances; re-check router guest SSIDs; rule out sleep and port drift; lock down when leaving trusted LANs. That sequence mirrors how experienced operators triage without rewriting provider rules first.

Closing Thoughts

Sharing a desktop Clash instance to phones is a neat way to reuse one curated profile, but it depends on boring infrastructure: correct bind, correct port type, and an OS that agrees to accept neighbor TCP. Compared with hunting obscure GEOIP edge cases, fixing the LAN path is fast once you stop mixing guest Wi-Fi with primary LAN assumptions. After connectivity is boringly reliable, you can invest time in split rules and DNS polish knowing the transport layer will not undermine every test.

When you want an up-to-date client bundle without comparing scattered release notes, start from one place. → Download Clash for free and experience the difference.