What “My Phone Cannot Reach Clash” Usually Means
You already started a Mihomo-class Clash stack on a Windows 11 laptop or mini PC. The subscription validates, browsers on the PC work, yet the iPad, Android phone, or streaming box sitting on the same Wi‑Fi reports proxy connection refused, endless loading, or only a subset of websites opening. That pattern screams “traffic never reaches the listener” long before you should touch routing rules or swap airport nodes.
Clash LAN sharing is nothing exotic: the core exposes an HTTP and/or SOCKS port on your PC. Mobile apps that support manual proxies point at YOUR_PC_LAN_IP:PORT. The fragile part is the chain from Wi‑Fi to process: the core must bind to an address other devices can reach, allow-lan must permit non-local clients, and Windows 11 firewall must accept inbound TCP (and occasionally UDP) on those ports. Miss any link and you will chase DNS red herrings for an hour.
If you use a GUI such as Clash Verge Rev, many toggles mirror the YAML keys. Our Clash Verge Rev tutorial explains where those controls live relative to system proxy and TUN; keep that page open while you align LAN settings with this checklist.
Step 0: Prove the Phone and PC Share a Real LAN
Before editing configs, confirm both devices obtain addresses from the same IPv4 subnet. On Windows, run ipconfig and note the Wireless LAN adapter Wi‑Fi IPv4 address and subnet mask—typically something like 192.168.1.42 on 255.255.255.0. On the phone, open Wi‑Fi details and compare. If the third octet differs, you might be on a guest SSID, a VLAN, or a hotel portal that sandboxes clients.
From the phone, ping the PC address using a network utility or Termux. If ICMP is blocked, try opening http://PC_IP:PORT in a browser once the proxy port is known—failure to connect at TCP level is still informative. If you cannot reach the PC at all, fix router AP isolation (sometimes labeled “client isolation,” “WLAN partition,” or “guest network”) before touching Clash. No amount of allow-lan: true fixes a router that forbids station-to-station traffic.
Corporate and university networks often block device-to-device chatter entirely. In those environments, LAN sharing may be impossible without a travel router you control. Recognize that constraint early.
Step 1: Enable allow-lan (and Know What It Unlocks)
In Clash/Mihomo YAML, allow-lan is the master switch that tells the core it may accept inbound connections from addresses other than loopback. When it is false, binding to 0.0.0.0 still will not help—policy-wise the stack is local-only. Set allow-lan: true, apply the profile, and restart the core if your GUI does not hot-reload the flag cleanly.
GUI users should find an equivalent “Allow LAN” or “Allow connections from LAN” toggle. If the toggle exists but flips back after reboot, check whether you are running portable mode without permission to rewrite the profile on disk, or whether a sync tool reverts YAML from another machine.
Do not confuse allow-lan with TUN mode. TUN captures traffic originating on the PC. LAN sharing concerns inbound proxy sessions initiated by other hosts. You can run both, but they solve different problems. If you recently enabled TUN and suddenly question every symptom, read the Windows TUN troubleshooting guide for adapter-level issues that masquerade as proxy failures on the desktop side.
Step 2: Bind Address, Loopback, and Why “Listen on All Interfaces” Matters
Even with allow-lan: true, a listener bound only to 127.0.0.1 remains invisible to your phone. Mihomo honors bind-address at the top level; common values are * (all interfaces), 0.0.0.0 for IPv4 any, or a specific LAN IP if you want to minimize exposure. Many distribution profiles default to loopback for safety, which is perfect for solo PC use and wrong for phone through PC proxy scenarios.
If you bind to a specific NIC address, remember DHCP may change it after sleep or router renewal. Binding to * or 0.0.0.0 avoids that fragility at the cost of appearing on every interface—including public hotspots if you forget to disable sharing later. Travel tip: flip allow-lan off when you leave trusted home Wi‑Fi.
Separate listeners—port for HTTP, socks-port for SOCKS—each follow the bind rules. mixed-port merges both protocols on one TCP port, which simplifies mobile setup: one number in the proxy field instead of two. Note the actual integer your running config uses; screenshots from Reddit rarely match your YAML.
Step 3: Pick the Right Port on the Phone (HTTP vs SOCKS)
Most Android browsers accept HTTP proxy settings pointing at IP:mixed-port or IP:port. SOCKS-aware apps want socks-port or the mixed listener if the client understands protocol negotiation there. Apple’s global HTTP proxy UI (per Wi‑Fi network) also expects HTTP semantics first.
If your mobile app asks for “SOCKS5 host and port,” feed it the SOCKS listener or mixed port according to what your core actually exposes— mismatch here produces instant failure that looks like a “bad node” even though no outbound connection started yet.
When everything is ambiguous, test from another PC on the LAN with curl using --proxy to the same IP and port. Identical failure modes narrow the blame to Windows or the router, not the phone vendor.
Step 4: Windows 11 Firewall—Add Inbound Allow Rules for the Exact Ports
Windows Defender Firewall treats unsolicited inbound TCP to a new listening process as hostile unless a rule says otherwise. After you confirm the core listens on 0.0.0.0:7890 (example), create an inbound rule allowing that TCP port for Private networks at minimum.
GUI path: Windows Security → Firewall & network protection → Advanced settings → Inbound Rules → New Rule. Choose Port, TCP, specific local ports (your mixed or HTTP port), allow the connection, and scope it to profiles you actually use—usually Private when your Wi‑Fi is marked Private. Repeat for SOCKS if it is a distinct port. UDP is rarely needed for classic HTTP/SOCKS proxying unless your client explicitly uses QUIC through that path; skip UDP until you have evidence you need it.
Alternatively, program-based rules targeting the Mihomo executable can survive port edits, but they fail if the binary path changes after updates. Port rules are crude yet predictable. If you run multiple cores, prefer port specificity to avoid accidentally exposing unrelated services.
Third-party endpoint security suites may layer their own firewall on top of Defender. If connections work briefly then die, check vendor logs for blocked clash.exe or verge-mihomo.exe as separate from Defender entries.
Step 5: Network Location—Private vs Public Profiles
Windows applies stricter defaults to interfaces classified as Public. If your Wi‑Fi is Public, rules scoped only to Private never trigger—exactly the “it works on Ethernet but not Wi‑Fi” class of bugs. Open Settings → Network & internet → Wi‑Fi → (your SSID) properties and set Network profile type to Private for home labs.
After changing the profile, revisit the firewall rule and confirm it applies to the active category. When in doubt, temporarily build a wide allow rule for testing, verify connectivity, then tighten scope. Document what you loosened so you remember to restore it before café Wi‑Fi.
Step 6 (Optional): external-controller and the Dashboard From Your Phone
Some users want the web dashboard or API on the phone browser for quick mode switches. external-controller listens on a management port (often 9090) and must also bind beyond loopback, with allow-lan already true. Treat this as higher risk: it exposes control-plane access to your LAN.
Set a strong secret, keep the port off the public internet, and never forward it blindly on your router. If you do not need remote dashboard access, leave the controller on 127.0.0.1 and operate the GUI locally only. Defense in depth beats convenience when guests regularly join your Wi‑Fi.
Step 7: Router-Side AP Isolation, Guest Wi‑Fi, and VLAN Surprises
Consumer mesh systems sometimes enable client isolation by default on “IoT” SSIDs. Guest networks almost always block access to RFC1918 space except the gateway. If your phone sits on Guest while the PC uses Main, they will not talk. Move both to the same SSID or disable isolation for testing.
IPv6 adds another wrinkle: if the phone prefers IPv6 routes that bypass your expectations while Clash listens only on IPv4, symptoms look random. For a controlled test, force IPv4-only on one device or temporarily disable IPv6 on the interface—only as a diagnostic, not a permanent crutch.
Powerline adapters with Wi‑Fi repeaters occasionally bridge subnets poorly. If ping fails intermittently, suspect hardware before YAML.
Step 8: Verify From the Phone Without Ambiguity
After firewall and bind fixes, set the phone’s HTTP proxy manually to PC_IP:PORT and load an IP echo site over HTTPS. If the page loads and shows the proxy egress IP, you have end-to-end confirmation. If plain HTTP works but HTTPS times out, suspect TLS inspection or an antivirus HTTPS proxy conflicting—rare on phones but common on PCs running parallel security tools.
For Android power users, Termux plus curl --proxy removes browser quirks. On iOS, Safari with per-network proxy settings is usually enough; for app-level SOCKS, use a client that exposes explicit SOCKS5 fields.
If you need mobile-specific subscription workflows after LAN works, cross-read the Android complete guide and the iPhone subscription troubleshooting article; they focus on tunnel apps rather than manual LAN proxies but share DNS vocabulary.
When LAN Works but Only Some Sites Load
Once the phone reaches the listener, new failures usually belong to rules, DNS, or node health, not firewall ports. Typical signatures: foreign sites load, domestic CDNs fail, or vice versa—pointing to split rules rather than transport. Compare Rule versus Global mode temporarily. If Global fixes everything, return to policy tuning and DNS alignment.
Fake-IP setups can produce “some domains stall” effects even when the LAN path is perfect. Our fake-ip versus redir-host article walks through that distinction on desktop; the same logic applies to mobile clients consuming the same profile through your PC.
When Another VPN on the PC Hijacks Routes
If the PC runs a commercial VPN or corporate Always-On VPN alongside Clash, default routes may shift such that the LAN listener accepts connections yet return traffic takes an unexpected path. Symptom: intermittent stalls or MTU black holes. Pause the other VPN during testing, or configure split tunneling so the LAN interface remains stable.
A Repeatable LAN Sharing Mental Model
Clash LAN sharing on Windows 11 succeeds when four layers agree: the Wi‑Fi actually allows peer traffic, allow-lan and bind-address expose the listener beyond loopback, firewall rules admit the inbound TCP ports you use, and your mobile client targets the correct protocol and port. Work that stack top-down every time a family member’s tablet “randomly” stops using the PC proxy after an OS update silently reset network profiles or after a router firmware toggle re-enabled guest isolation.
Compared with juggling one-off SOCKS utilities, a maintained Mihomo-based build keeps HTTP, SOCKS, DNS, and rules in one coherent profile—so once LAN connectivity is proven with curl, you can focus on policy quality instead of reinventing listeners. When you are ready to deploy a current Windows GUI with sane defaults for both desktop and occasional LAN clients, start from our download page and pair it with the configuration reference for fine-tuning. → Download Clash for free and experience the difference.