Share Clash on Windows LAN for Your Phone: Ports, Firewall, and a One-Sitting Setup

Who this guide is for—and what it is not

The search pattern is simple: only the PC is on, Clash already moves browser traffic the way you like, and you want the phone on the same network to ride the same exit without standing up a second subscription workflow. That is a LAN proxy share, not a router default gateway, not a USB tethering hack, and not a cloud relay. You will keep managing rules, DNS mode, and policy groups on Windows; the handset merely becomes another HTTP or SOCKS client that dials your PC’s IPv4 address on a TCP port Clash publishes.

If you expected “make every device automatic without touching proxy settings,” you are describing DHCP gateway + DNS capture on a router, which is a larger design. Our OpenWrt gateway write-up covers DHCP, dnsmasq, and Fake-IP at LAN scale. Stay here if you specifically want a quick phone hop through an existing Windows Clash—the steps are shorter, but you must accept manual proxy fields or a mobile client that knows how to talk to your PC.

Pre-flight checks before you touch firewall rules

Start boring and stay boring. Confirm Clash on Windows is healthy with the profile you intend to share: subscription refresh succeeds, nodes answer, and the desktop browser can reach a test host that demonstrates the proxy path. If the PC itself is half-configured, exposing the same inbound to a phone only duplicates confusion across two screens.

Write down three facts you will reuse verbatim on the phone: the PC LAN IPv4, the mixed or HTTP inbound port, and whether you expect HTTP CONNECT or SOCKS5 for the mobile stack you chose. Most manual Wi‑Fi proxy forms speak HTTP; SOCKS usually appears in dedicated clients. Mixed ports in Clash-family cores commonly accept both, but the phone UI still wants you to pick a mode that matches what you type.

Finally, decide whether you are testing on private profile Wi‑Fi in Windows. Firewall prompts and Defender defaults treat public networks more harshly. If your SSID is classified as public, switch to private while you test, then tighten again deliberately rather than fighting silent drops.

Find the Windows IPv4 your phone can actually route to

Open Command Prompt or PowerShell and run ipconfig /all. Locate the adapter that corresponds to how the PC reaches the access point—often “Wi‑Fi” or “WLAN” when both machines are wireless, or “Ethernet” when the PC is cabled while the phone is not. Copy the IPv4 Address, not the link-local fe80:: story, not the VPN virtual adapter unless that is genuinely the shared path.

Multi-homed PCs are the classic pitfall. A docked laptop might show a corporate Ethernet address unrelated to the café Wi‑Fi your phone joined. The rule is empirical: from the phone, the address must be reachable on TCP to your Clash port. If you are unsure, ping is a weak signal but a fast first poke; absence of ping does not disprove reachability because some PCs block ICMP while still allowing TCP to application ports.

When the PC rotates addresses after sleep, consider a DHCP reservation on the router or note the pattern. Teaching family members to re-check ipconfig beats mysterious “it worked yesterday” reports. Static IPv4 on the PC is optional; reservations are usually gentler for laptops that move between sites.

Clash on Windows: Allow LAN, bind scope, and the mixed port

GUI clients surface this as Allow LAN or language to that effect. Under the hood you are asking the core to accept inbound connections from non-loopback interfaces on the mixed HTTP/SOCKS listener. If the toggle is off, the phone’s SYN packets never reach a listening application even when the firewall is wide open—Windows will refuse or Clash will not bind broadly, depending on configuration.

Open your profile or the live connection view and read the mixed-port (or separate port and socks-port if you intentionally split them). Examples in documentation often use 7890; your bundle may differ. The phone must target the numeric port you truly run, not a remembered default from an old screenshot.

If you edit YAML directly, semantics cluster around allow-lan: true and the inbound section. After changes, restart the service or apply from the GUI so the listener rebinds. Advanced users sometimes pair Allow LAN with explicit bind-address; if you set something tighter than 0.0.0.0, verify it still includes the interface facing the phone. For how TUN mode on the desktop differs from “just exposing a port,” see the TUN versus system-proxy guide—TUN helps the PC itself; it does not magically proxy a phone unless you build a separate path.

Windows Defender Firewall: one clean inbound allow for the Clash port

Even with Allow LAN, Defender may block inbound TCP to your mixed port on profiles you care about. The fix is boring but precise: create an Inbound Rule that allows TCP to the specific local port Clash uses, scoped at least to Private networks. Prefer tying the rule to the executable if your client binary is stable—when Clash updates, the path stays consistent in many installers—or fall back to a port-only rule when you know the port is unique enough on that host.

Walkthrough in words: Windows Security → Firewall & network protection → Advanced settings → Inbound Rules → New Rule → Port → TCP → “Specific local ports” with your mixed port → Allow the connection → check Private (and Domain only if that matches reality) → name it clearly like “Clash mixed inbound 7890.” Avoid duplicating shadow rules you will forget; one explicit allow beats three overlapping experiments.

If a third-party suite replaced Defender, translate the same intent: allow inbound TCP listener on the Clash process or port for the profile that matches your Wi‑Fi. Corporate laptops with centralized policy may block this entirely—then no amount of YAML editing on your user account will help until IT permits a listener.

After the rule exists, verify from another machine if possible. A second laptop on Wi‑Fi can run curl -I --proxy http://PC_IP:PORT https://example.com. Phones make poor debug consoles; borrow any shell you have before blaming iOS.

Configure the phone: manual HTTP proxy on iOS and Android

On iOS, open Settings → Wi‑Fi → tap the ⓘ on your network → scroll to HTTP Proxy → Manual → Server: your PC IPv4 → Port: your mixed HTTP port. Authentication fields usually stay empty for default Clash inbounds without auth. iOS applies this proxy to many system frameworks, but not every third-party app honors Wi‑Fi proxy settings consistently; streaming apps and some games may still bypass. For stubborn apps, a VPN-style per-app tunnel on the phone is the next lever—outside today’s YAML, but the symptom pattern is documented in the iOS 18 client guide.

On Android, Wi‑Fi details vary by OEM. Long-press the SSID → Modify → Advanced options → Proxy → Manual → hostname and port. Newer Material builds bury the path; search settings for “proxy” if the sheet moved. Android’s global Wi‑Fi proxy is similarly imperfect for apps that use their own network stacks, which is why many users import the same subscription URL into Clash for Android and point an outbound chain at the PC—different UX, same physics.

When manual proxy works in Safari or Chrome but not in random apps, you are usually seeing split stack behavior, not a failed PC configuration. The PC side can still be correct.

Optional: dedicated mobile clients and the same subscription URL

Manual HTTP proxy is the lowest common denominator. Power users often install a Clash-compatible mobile client and paste the same subscription URL they already trust on Windows. That path gives rule UI on the handset and avoids typing IP:port into the OS sheet—but it also means the phone fetches the subscription directly and runs its own core, which is operationally a second node, not a pure “reuse Windows RAM” model.

A middle ground some networks use: mobile client in proxy-only mode with upstream still aimed at the PC. That returns centralized rule execution to Windows while letting the phone speak SOCKS more naturally. Document whichever hybrid you pick for your household so the next troubleshooting session starts from one architecture, not three.

Whenever you mention subscriptions out loud, repeat the hygiene from our subscription auto-update article: HTTPS fetch, sane clock, user-agent expectations, and no routing loops that block the profile URL itself.

DNS reality check on phones

LAN HTTP proxy forwards TCP connections once the phone decides where to connect. DNS on the handset may still be local or carrier-flavored unless you push a different resolver or run a full-tunnel mobile client. If domains resolve to unexpected addresses—common with streaming or split intranet names—symptoms look like “proxy up, site down.” Align expectations: Windows Clash’s DNS stanza governs the PC’s view; the phone has its own resolver chain unless you integrate them.

For deep DNS mode comparisons that matter when Fake-IP interacts with LAN names, read the fake-ip versus redir-host guide. Phones add another resolver hop, so keep logs on Windows open while you test to see whether failures are DNS-shaped or TLS-shaped.

Security and housekeeping on untrusted networks

Allow LAN exposes a powerful relay. Anyone who can ARP-scan your café table segment could send traffic through your exit unless additional controls exist. Default Clash inbounds often ship without authentication for simplicity on loopback; the moment you listen on LAN, that innocence disappears. Treat this recipe as trusted LAN only, disable Allow LAN when you pack up, and prefer Windows network profiles that match reality.

If you need port exposure but want guardrails, explore whether your client supports authenticated inbound or IP allowlists—many home users skip this; corporate labs should not. Also remember the PC must stay awake; sleeping laptops drop listeners. Power settings and lid behavior matter as much as YAML.

Triage matrix: narrow the failure in minutes

Short answers to the questions people actually type

Do I enter the gateway IP or the PC IP? The PC’s IPv4 as seen on the LAN segment, not the router’s address, unless you have an unusual reverse proxy in front of Clash—which this guide does not assume.

Does the phone need its own subscription URL? For manual HTTP proxy, no; traffic funnels to Windows Clash, which already consumes your subscription. For standalone mobile cores, yes, you typically import the same URL again.

What about Windows 11 “Metered connection” quirks? They affect background tasks, not inbound TCP to a port, but sleep timers do—verify power policy if listeners vanish randomly.

Can I share to an iPad the same way? Yes—iPadOS presents the same Wi‑Fi proxy sheet; larger screens do not change the network path.

Closing: one PC, many handsets, deliberate exposure

Sharing Windows Clash to a phone is mostly network plumbing: confirm a stable LAN IPv4, turn on Allow LAN, align the mixed port, grant Windows Firewall inbound permission on that TCP listener, then teach the phone where to send HTTP CONNECT. Compared with all-in-one consumer VPN apps, Clash keeps the policy surface on a machine you can grep and log—once the inbound is reachable, phones inherit the same selective exits as your desktop without maintaining parallel rule files, unless you choose to.

Compared with flashing OpenWrt, this pattern trades automation for immediacy: you will touch per-device proxy fields or mobile clients, but you skip router risk and DHCP surgery. Pick the tool to match the room—home office tonight, gateway project on the weekend. For installers and updates across platforms, start from the site download center instead of chasing release pages mid-setup.

Browse more tutorials in the tech column index or open the help page if you want a broader map before editing YAML again.