Use Clash on Your Phone via Windows 11 PC: Enable LAN Proxy and Firewall Rules
You already run Clash on a Windows 11 desktop and it works in the browser—then you pick up your phone and realize the same subscription does nothing until you install another client or tunnel. A practical middle path is simpler than it sounds: expose the PC’s HTTP or mixed proxy listener to the local network, flip allow-lan (or the equivalent GUI toggle), punch a narrow hole in Windows Defender Firewall with an inbound rule for the exact TCP port, and point the phone’s Wi‑Fi proxy at the PC’s LAN IP. This guide is the Windows-first walkthrough that our first-install article does not emphasize: multi-device, same subnet, firewall reality, and the security trade-offs of turning a personal proxy into a household LAN service.
What you are building (and what you are not)
This pattern is a classic LAN HTTP(S) proxy hop: the phone’s apps that honor manual proxy settings send TCP connections to your PC; Clash terminates the local proxy leg and forwards according to your profile’s rules and proxy-groups. You are not cloning the PC’s full TUN experience onto the phone—mobile operating systems still decide per-app compliance, and many games or first-party stacks ignore manual proxies entirely. If you need phone-wide capture, you typically run a maintained mobile client with platform VPN semantics; see our Android Clash setup guide for that story. Here the goal is narrower and extremely searchable: same Wi‑Fi, Windows 11 as the gateway you already trust, minimal moving parts.
Also be explicit about trust boundaries. The moment you bind a proxy to 0.0.0.0 on a laptop named Family-PC, anyone who can join the same LAN—or exploit a weak guest network—could attempt to use that listener. Pair technical steps with household hygiene: guest Wi‑Fi isolation where available, strong router admin passwords, and turning allow-lan off when you leave a café table. This article shows the responsible defaults: scope firewall rules to private networks where Windows supports it, document the port you opened, and close the feature when you do not need it.
Prerequisites you should verify before touching firewall rules
Walk this checklist once; it prevents the demoralizing loop where you add inbound rules, reboot the router, and discover the PC was on Ethernet while the phone fought with a cellular assist feature.
- One LAN, one subnet: Phone and PC must obtain IPv4 addresses from the same router segment, e.g.
192.168.1.x. If the PC uses wired Ethernet and the phone uses Wi‑Fi, that is fine as long as the router does not isolate wireless clients (some “AP isolation” modes break LAN printing and break this trick too). - Clash already works locally: Confirm a browser on the PC loads pages through your profile. If local proxy mode is confused, fix that first with our Windows 11 first-setup guide so you are not debugging two layers at once.
- Know the real listener port: Many guides still chant
7890from legacy Clash for Windows muscle memory. Modern Clash Verge Rev builds often expose a mixed port such as7897for HTTP and SOCKS on one TCP entry. Open your client’s settings or the active YAML and write downmixed-port, or the pairport+socks-port, before you configure the phone. - Identify the PC’s IPv4 address: You will type this into the phone. Prefer a DHCP reservation or static LAN IP on the router so the address does not drift weekly.
If vocabulary like proxy-groups still feels abstract, skim the site Clash tutorial so the log lines you will read later actually map to mental objects.
Step 1 — Find your Windows 11 PC’s LAN IPv4 address
Open Terminal or Command Prompt and run ipconfig. Under the active adapter—Wi-Fi or Ethernet—note IPv4 Address, for example 192.168.1.42. Ignore 169.254.x.x autoconfiguration addresses; those indicate DHCP failure, not a usable LAN host route.
If you see multiple adapters because of Hyper-V, WSL virtual switches, or VPN clients, pick the one that shares the default gateway with your phone. A quick sanity check from the phone’s browser is to ping or open a simple LAN service if you run one; absent that, proceed to proxy testing after firewall work.
Step 2 — Enable allow-lan (and understand bind-address)
Clash defaults to listening on loopback (127.0.0.1) so random café neighbors cannot attach to your proxy. To accept connections from other devices on the LAN, you enable allow-lan in configuration—often surfaced as a toggle labeled Allow LAN / 局域网连接 in GUI clients.
In YAML terms the idea is:
allow-lan: truepermits non-loopback interfaces to reach the listeners defined byport,socks-port, and/ormixed-port.bind-address: '*'or0.0.0.0(depending on core and schema version) listens on all IPv4 interfaces; some users bind to a single LAN IP for tighter scope—either approach can work if it matches how Windows routes packets.
After you toggle the setting, restart the core or apply the profile if the UI requires it. Then verify from the PC itself with a loopback test still passing; if local browsing breaks, you flipped the wrong control or the profile failed to reload.
GUI nuance: Clash Verge Rev may mirror settings into generated runtime YAML. If a subscription refresh overwrites your file wholesale, prefer the client’s dedicated override or merge panes for persistent allow-lan—the same discipline we describe in the custom rules tutorial for surviving provider template churn.
Step 3 — Windows Defender Firewall: add an inbound rule for the proxy port
Even with allow-lan correct, Windows Defender Firewall often blocks incoming TCP to unfamiliar listening ports. You need a deliberate inbound rule that allows the Clash listener port for Private networks at minimum.
-
1
Open Windows Defender Firewall with Advanced Security
Press Win + R, type
wf.msc, press Enter. You should see Inbound Rules in the left tree. -
2
Create a new inbound rule
Choose New Rule… → Port → TCP → Specific local ports → enter the port your mixed listener uses (example:
7897). If you expose separate HTTP and SOCKS ports, create one rule per port or a comma-separated list only if the wizard accepts it cleanly—two explicit rules are easier to audit. -
3
Allow the connection
Select Allow the connection. Avoid “Allow if secure” unless you operate IPSec in the home—most readers do not.
-
4
Scope to Private (recommended)
On the profile screen, check Private and uncheck Public unless you truly need airport-hotspot sharing—leaving Public enabled widens exposure when you join untrusted Wi‑Fi later.
-
5
Name it like an adult
Use a descriptive name such as Clash mixed port 7897 inbound. Future you should recognize the rule in six months without guessing.
Third-party endpoint suites sometimes supersede Windows Firewall with their own prompts. If connections still fail after a correct rule, check whether a security product maintains a parallel network filter and add a matching allow entry for the verified Clash binary path—not a blanket “disable antivirus” maneuver.
Quick local test before involving the phone
From another LAN device—or temporarily from the PC using the LAN IP instead of 127.0.0.1—attempt a TCP connection to YOUR_PC_IP:PORT. If you are comfortable with command-line tools, Test-NetConnection 192.168.1.42 -Port 7897 in PowerShell on a second machine is decisive: TcpTestSucceeded : True means firewall and bind succeeded; False means you are still fighting policy or the listener is loopback-only.
Step 4 — Configure the phone’s Wi‑Fi HTTP proxy
On iOS, open Settings → Wi‑Fi, tap the ⓘ next to your network, scroll to HTTP Proxy, choose Manual, set Server to the PC’s IPv4 address, and Port to your HTTP or mixed port. Authentication fields usually stay empty for default Clash listeners.
On Android, the path varies by vendor; look under the Wi‑Fi network’s advanced options for Proxy → Manual, then enter hostname and port. Some OEMs hide this behind a pencil icon or “Modify network.”
What you should expect: Safari or Chrome begins routing many (not all) HTTPS sessions through the PC via HTTP CONNECT tunneling. You will still see TLS to remote sites; the proxy does not magically decrypt HTTPS without enterprise trust implants—Clash forwards bytes based on hostnames gleaned from TLS SNI and your rule stack.
Step 5 — Validate with logs, not vibes
Open your desktop client’s log or connections view while you load a website on the phone. You should see incoming connections from the phone’s LAN IP. If nothing appears, the failure is earlier: wrong PC address, wrong port, firewall, or allow-lan still false. If connections appear but pages fail, read which rule matched and whether traffic exited REJECT or an unexpected group—beginners often assume the phone inherits a selected node when an earlier rule still sends certain domains DIRECT.
For a structured refresher on how groups interact with rules after traffic reaches the PC, open the proxy-groups guide; the mental model is identical whether the entry connection originated from Edge on the desktop or Chrome on a tablet.
Common failure modes and fixes
“Connection refused” from the phone
Listener not bound externally, wrong port, or Clash not running. Re-check mixed-port versus legacy 7890 assumptions.
Timeouts despite correct IP and port
Firewall profile mismatch—rule enabled only for Domain while your Wi‑Fi is marked Public. Either reclassify the network in Settings → Network & internet or adjust the rule’s profile checkboxes deliberately.
Some apps work, others never use the proxy
Expected. Many mobile apps bypass manual proxies. Games and video clients are frequent offenders. That limitation is why LAN proxy sharing complements—but does not replace—dedicated mobile clients when you need broader coverage.
Works on HTTP sites, “weird” on HTTPS
Investigate certificate pinning or apps that use QUIC/UDP paths around your TCP proxy. Toggling experimental QUIC in Chromium-based browsers occasionally clarifies symptoms, but treat that as signal, not a permanent crutch.
PC sleeps, everything stops
Laptops suspend; listeners vanish. For a household hub, adjust power settings or use a small always-on desktop. This is operational reality, not a Clash defect.
Security and housekeeping
Treat LAN proxy exposure like leaving a window cracked: fine on a trusted porch, questionable facing a sidewalk. Disable allow-lan when you travel. Remove or disable the inbound rule if you uninstall Clash. If you share a co-working space, do not run this pattern at all on their SSID—use a local client on the phone instead.
For readers who want deeper packet-capture semantics on the desktop side—including how TUN differs from application proxies when stubborn Win32 apps refuse settings—read Clash TUN mode explained. That background clarifies why phones and PCs diverge even when both say “proxy.”
How this fits next to subscription hygiene
LAN sharing does not change the fact that remote subscription URLs expire, throttle, or rotate. If the PC suddenly cannot refresh nodes, phones piggybacking on the same core will fail in sync. When fetch errors spike, consult subscription links FAQ before you assume firewall regression.
Closing: a deliberate LAN hop beats mystery toggles
Sharing Clash from Windows 11 to a phone on the same Wi‑Fi is a small set of coherent actions: enable allow-lan and correct binding, open a narrowly scoped firewall inbound rule for the real mixed or HTTP port, aim the handset’s Wi‑Fi proxy at a stable PC IPv4 address, and confirm with logs. Compared with opaque “it should just work” expectations, that sequence turns a high-intent search—Clash, allow-lan, firewall, LAN proxy—into a reproducible household setup you can retire when risk profile changes.
When you need a maintained desktop build to anchor the workflow, use this site’s download page as the primary install path—Download Clash for free and experience the difference.