Share Your PC's Clash Proxy on LAN: Allow-Lan and Windows Firewall Setup

1. What “Share Clash on LAN” Solves

The user story behind searches like “Clash allow-lan” is refreshingly concrete. One machine already performs subscription refresh, policy-group selection, DNS alignment, and logging. Everyone else on the couch just wants Instagram, YouTube, or a work VPN tab to stop timing out, without learning YAML or importing a second subscription on five separate devices. A shared HTTP or SOCKS listener on the LAN is the smallest contract that still respects the mental model: “traffic enters my proxy, my rules decide the exit.”

This is intentionally different from “make my PC a router for the entire building.” You are not rebroadcasting Wi‑Fi or rewriting DHCP; you are advertising a single TCP port (commonly tied to mixed-port) that speaks HTTP CONNECT and SOCKS on behalf of clients that opt in. Guests still need to configure proxy settings or use a helper app; you are simply making that configuration possible across subnet boundaries inside the LAN.

The failure modes people hit first are almost never about subscription syntax. They are about three boring layers: the core is still bound to loopback, the OS firewall drops SYN packets from phones, or the access point enforces client isolation so “same Wi‑Fi” is a lie at layer two. This article addresses the first two directly and gives you a crisp checklist for the third.

2. Security Reality Check Before You Open the Port

Enabling allow-lan is not a cosmetic switch. Any device that can route packets to your Windows host on the chosen TCP port may attempt to use your proxy. On a trusted home LAN with a strong Wi‑Fi passphrase and up-to-date firmware, that is often acceptable. On hotel networks, conference Wi‑Fi, or coffee-shop captive portals, it is a hard no—treat those as hostile broadcast domains even when they hand you a password.

You should also understand what a shared HTTP proxy does not magically provide. It does not replace per-device TLS validation, disk encryption, or account hygiene. If someone on your LAN can reach the port, they can potentially funnel arbitrary TCP flows through your upstream nodes, which may have billing, rate limits, or acceptable-use constraints attached. Document who is allowed to use the machine, rotate Wi‑Fi credentials when roommates change, and consider turning the listener off when you leave the network.

Advanced operators sometimes combine LAN sharing with additional segmentation—binding only to a specific interface, using a dedicated VLAN, or fronting the listener with an authenticating forward proxy. Those patterns are out of scope here, but the guiding principle remains: expose the narrowest surface that still meets your household workflow, then verify with logs that unexpected clients are not appearing.

3. Listener Basics: mixed-port, port, and socks-port

Modern mihomo derivatives typically expose a mixed-port listener that accepts both HTTP proxying (including CONNECT for HTTPS) and SOCKS5 on the same TCP port. That single number is what you will type into a phone’s manual proxy field as http://192.168.x.x:7890 (scheme HTTP even when the remote site uses HTTPS). If your profile still defines separate port and socks-port entries without a mixed listener, pick one coherent story—mixed is easier to teach to family members—and delete ambiguity from your docs so nobody chases the wrong integer.

Keep the port stable across reboots. Random high ports look clever until every device profile drifts out of sync. Standardize on something memorable internally (7890 is a common community convention) and stick with it unless another service already owns that port. If you change it, update firewall rules, saved Wi‑Fi proxy profiles, and any automation scripts in the same edit—not next week when someone “mysteriously” loses connectivity.

Remember that the external REST controller port (often discussed around external-controller) is unrelated to client proxying. Opening the controller to the LAN is a separate risk decision; this guide focuses strictly on the data-plane listener your phone will use for browsing traffic.

4. mihomo Config: allow-lan and bind-address

At the YAML level, the two knobs that matter for LAN proxy sharing are allow-lan and bind-address. Setting allow-lan: true tells the core you intend to accept connections from non-loopback addresses. The bind address decides which local interfaces actually advertise the listener. A classic working pair for home use binds all IPv4 interfaces while keeping the policy explicit:

# Example skeleton — adjust ports and secrets to your profile.
mixed-port: 7890
allow-lan: true
bind-address: '*'

Some templates still document 0.0.0.0 explicitly; others accept '*' as “all interfaces.” The operational test beats memorizing release notes: from another device, attempt a TCP connection to <your-lan-ip>:<mixed-port>. If you receive immediate refusal before TLS is even in play, return to binding and allow-lan before you blame DNS or rules.

After editing configuration, reload the running core the way your client expects—apply in GUI, hot-reload API, or restart the service. Silent “saved file but old process” states cause endless forum threads where YAML is perfect yet nothing listens. Watch the log line that confirms the mixed listener is active and note the bound address it prints.

If you run multiple VPN or hypervisor virtual adapters, you may see surprising bind orders. In pathological cases, specifying a concrete LAN IPv4 address instead of a wildcard reduces ambiguity—at the cost of breaking sharing when DHCP renumbers your host. Pick the trade-off that matches how static your network is.

5. GUI Clients: Where the Toggle Usually Lives

Many users never touch raw YAML because Verge-style clients expose “Allow LAN” or equivalent wording beside the inbound port fields. Treat those toggles as thin UIs over the same allow-lan semantics: flipping the switch without restarting the core or without a matching bind-address still yields a beautiful green icon and zero remote connectivity.

When documentation disagrees between GUI labels and generated YAML, trust the generated file on disk and the listener log. Screenshots age quickly; the core’s startup banner does not. If your client writes a temporary config, confirm you are editing the instance the service actually reads—not an import preview that never landed in the runtime path.

For readers who prefer headless discipline on Linux servers, our Ubuntu Clash Meta + systemd guide complements this Windows-centric sharing scenario when the “always-on” machine is not a gaming laptop but a small form-factor PC.

6. Find the Correct LAN IP on Windows

Phones cannot use 127.0.0.1 to mean “the PC running Clash.” They need the Windows host’s IPv4 address on the same broadcast domain as the client—typically something like 192.168.0.42 or 10.0.0.17. On Windows 10 and Windows 11, ipconfig remains the fastest truth source: identify the active Wi‑Fi or Ethernet adapter, read the IPv4 Address line, and ignore autoconfiguration leftovers that are not actually routed.

If you have Hyper-V, WSL virtual switches, or VMware adapters listed, do not guess. The correct row is the one whose default gateway matches your router’s LAN address and whose subnet matches the phone’s Wi‑Fi details screen. When in doubt, compare the first three octets between devices; they must align for vanilla home setups.

DHCP renewals can change the last octet after router reboots. If family members save manual proxy profiles, consider binding a DHCP reservation on the router for the Windows host so the “Clash server IP” stops moving. That single router-side tweak eliminates more support chats than any amount of YAML polishing.

7. Windows Defender Firewall: Inbound Rule Step by Step

Even with perfect allow-lan settings, Windows may silently block inbound SYN packets to your mixed-port because the default profile favors denying non-explicit listeners. You need an inbound allow rule scoped narrowly to the proxy port and, ideally, to private networks only. The GUI path is deliberate; follow it once, name the rule clearly, and future-you will recognize why port 7890 is open.

Open Windows Security → Firewall & network protection → Advanced settings. Choose Inbound Rules → New Rule. Select Port → TCP → Specific local ports → enter your mixed-port value (example: 7890). Allow the connection. On the profile screen, prefer Domain and Private while leaving Public unchecked unless you genuinely tether through categorized public networks—most home users should not. Name the rule something explicit like “Allow Clash mixed inbound (7890)” so audits are painless.

If you also run third-party endpoint suites, duplicate the intent there. Windows Defender may allow traffic while another vendor stack still blocks “non-browser listener on high port.” Symptom-wise, both look identical from the phone: spinning loader, eventual timeout, no TLS error page because TCP never completes.

After creation, validate from the phone using a simple TCP check if you have a network utility, or jump straight to configuring the HTTP proxy and visiting a plain HTTP test endpoint that prints your egress IP. If the browser loads but policy is wrong, you have graduated from firewall issues to mihomo rules—congratulations and see the routing guide linked above.

Power users sometimes prefer netsh advfirewall scripting for repeatability across machines. That is excellent for IT-style rollouts; for one dorm PC, the GUI rule is fine as long as you document the port alongside your Wi‑Fi password sticky note—preferably not on the same sticky note.

8. Configure Phones, Tablets, and Other PCs

iOS and Android can both use manual HTTP proxy settings per Wi‑Fi network. Point server to your Windows IPv4, port to mixed-port, leave authentication blank unless you layered it yourself. Understand that only that SSID profile uses the proxy; switching to cellular data bypasses it entirely, which is usually what you want when leaving the apartment.

Modern Android variants hide manual proxy fields behind long-press network details; some OEM skins relocate them into “Connectivity” submenus. If manual mode is painful, consider a client app that manages local VPN tunnels—those apps are not Clash itself, but they illustrate why power users eventually install a native core on the phone. For occasional browser-only needs, manual HTTP remains the lowest moving part count.

On a second Windows or macOS laptop, set system HTTP/HTTPS proxies to http://<host-ip>:<mixed-port>. SOCKS-aware apps can alternatively target socks5://<host-ip>:<mixed-port> when separated ports exist; with a true mixed listener, HTTP mode is the least surprising teaching path. Remember to configure bypass lists for local RFC1918 printers and NAS web UIs if your rules do not already short-circuit them.

Games and chat apps that ignore system proxy settings will continue to ignore them; sharing the PC listener does not change application sandboxing. For those workloads you either run a local tun-capable client on the device or accept split connectivity. Setting expectations early prevents the “Clash is broken” narrative when the real issue is an Electron app that ships its own network stack.

9. Verify End-to-End Connectivity

Verification should be staged. First, from the Windows host itself, confirm the listener responds on loopback with your usual tools. Second, from another LAN device, attempt to open a TCP connection to the LAN IP and port—if you have Termux, netcat, or a portable port scanner, this is seconds of work. Third, configure the HTTP proxy and load a site that reports egress IP; it should match the node you expect from the PC’s Clash dashboard, not the phone carrier’s NAT.

Watch the PC’s live connections pane or log tail while the phone browses. You should see CONNECT requests with timestamps that correlate to taps. If logs stay silent while the browser spins, you are still in transport limbo—return to firewall and AP isolation before touching policy groups.

DNS deserves a quick mention: some phones will still resolve through their own resolver unless you steer them. If sites load but region-sensitive services behave oddly, compare DNS paths between host and client. Aligning them may mean advertising the PC as DNS on the LAN—a bigger topic—or simply accepting that HTTP proxy mode fixes most web flows without fixing every UDP-based DNS query.

10. Troubleshooting: Isolation, Binding, and Policy

Guest networks and many mesh-node “visitor” SSIDs enable client isolation by design. Two phones may show the same SSID name yet be forbidden from talking to your laptop’s TCP port. The fix is using the primary private LAN, disabling isolation if you control the AP, or cabling the PC to the router when Wi‑Fi options are limited. No amount of Clash allow-lan toggling overrides AP-level drops.

Another sneaky case is multiple active routes on Windows—Wi‑Fi plus Ethernet plus a USB tether. The listener might bind to an interface your phone cannot reach because traffic tries the wrong subnet first. Temporarily disable secondary adapters while testing; once stable, re-enable with a concrete bind plan.

If TCP succeeds but HTTP sites refuse to load, inspect whether an upstream captive portal intercepts HTTP before it reaches your proxy. Hotel networks love this failure mode. The workaround is authenticating on a non-proxied path first, then re-enabling the LAN proxy profile.

When TCP works and HTTP works but “only some apps break,” return to rules. Misordered GEOIP or DOMAIN-SUFFIX lines can send unexpected flows DIRECT while the browser tab you tested happened to hit a permissive branch. Our url-test and failover article helps when the issue is unstable nodes rather than LAN plumbing.

11. Closing Thoughts

Sharing a Windows PC’s Clash listener on the LAN is less about exotic tricks and more about boring correctness: turn on allow-lan, bind the mixed-port where other hosts can reach it, teach Windows Firewall to admit that one TCP port on trusted profiles, then verify with logs instead of vibes. Compared with cloning subscriptions across every gadget, you keep a single maintained mihomo brain on the machine that already stays awake and patched—fewer drifted rules, fewer late-night mysteries where one app behaves differently on each device.

The approach shines in dorms and small apartments where one desktop is the natural always-on anchor. It is weaker when AP isolation, captive portals, or aggressive endpoint software inserts itself between friends. Name those environmental constraints up front and nobody mistakes a core misconfiguration for a moral failure of proxies in general.

When you are ready to standardize installers and updates for the household anchor PC, start from our download center, then layer LAN sharing on top once the base profile behaves. → Download Clash for free and experience the difference