What you are building: Clash as a LAN HTTP proxy for your phone

Many users already run Clash or Clash Meta (mihomo) on a Windows desktop with a working subscription. The next step is natural: put your phone on the same Wi-Fi and route its browser (or system proxy-aware apps) through the PC so you do not maintain a second full VPN profile on the handset. That pattern is a Clash LAN proxy: the core listens on an address reachable from your LAN, and the phone’s Wi-Fi settings point at your computer’s IP and port.

This is not the same thing as TUN mode capturing every packet on the PC, and it is not the same as turning the PC into a full gateway for all subnets. You are exposing a forward HTTP proxy (and often SOCKS on the same mixed port) to other devices you trust on the LAN. If you later need deep capture on Windows itself, pair this article with Fix Clash TUN on Windows: routing, firewall, and stack conflicts; for installing and daily use of a maintained GUI, start from Clash Verge Rev: Windows and macOS install and usage.

Before you start: same network, stable PC IP, and realistic expectations

Three facts keep support threads short. First, the phone and the PC must be on the same Layer-2 broadcast domain for a simple proxy setup—typically the same SSID on a home router, not a guest network that forbids client-to-client traffic. Second, your PC should keep a predictable IPv4 address while you test; DHCP reassignment mid-session changes the target your phone dials. Assign a DHCP reservation or a static IPv4 on the LAN subnet. Third, an HTTP proxy on the phone helps browsers and many apps, but it does not magically proxy every UDP game or every background service the way a full-tunnel VPN app might. Plan around that limitation instead of fighting it.

Write down the ports your profile actually uses. Modern cores often expose a single mixed port that speaks HTTP and SOCKS together; older configs split port and socks-port. Your phone’s manual proxy dialog usually wants the HTTP side—commonly aligned with whatever number the GUI labels as mixed or HTTP. If you are unsure, read the running config inside your client or skim Clash YAML: routing rules, proxy groups, and Fake-IP for how the mixed-port stanza relates to listeners.

Step 1: Find your Windows PC’s LAN IPv4 address

Open Command Prompt or PowerShell and run ipconfig /all. Locate the active adapter—Wi-Fi or Ethernet—that actually carries your internet path. Note the IPv4 Address (for example 192.168.1.42) and the Subnet Mask. Your phone must receive an address in that same subnet from DHCP; if it shows 169.254.x.x, fix DHCP before you blame Clash.

From the phone, ping the PC if your mobile OS allows it, or open a network utility that can reach the address. If ICMP is blocked, skip straight to the proxy test later—ping is a convenience, not a requirement. What you cannot skip is confirming both devices list the same default gateway and netmask family; cross-subnet browsing to a random private IP will fail no matter how perfect your YAML is.

Step 2: Bind the listen address and allow LAN connections

By default, many builds listen only on 127.0.0.1 so random strangers on a café network cannot send traffic through your proxy. That is safe—and exactly why your phone sees timeouts when you aim it at the PC. You must bind the listener to all interfaces on the machine or to your specific LAN IP, and you must explicitly allow LAN connections in the core.

In Clash Verge Rev and similar GUIs, look for toggles named along the lines of Allow LAN or Allow connections from the LAN. Turn that on before testing from another device. In parallel, open your generated YAML (or the profile editor) and confirm the core flags match what the GUI claims. A typical minimal pair looks like this:

allow-lan: true
bind-address: '*'

The asterisk form tells the stack to listen on all IPv4 interfaces; some users prefer 0.0.0.0 depending on core version and parser. Binding to a single LAN IP instead is fine when you want a narrower surface—just keep it aligned with the address you hand to the phone. After any change, restart the core so the listener actually rebinds; flipping switches without a restart is a frequent source of “it still says 127.0.0.1 in the log.”

Step 3: Windows Firewall must allow inbound TCP to your proxy port

Windows Defender Firewall treats unsolicited inbound TCP to a new program as suspect. Clash initiates most traffic outbound, but when your phone connects to the PC’s LAN IP, the first packet is inbound to the proxy port. Without a matching allow rule, the connection blackholes even though the core is listening.

Open Windows Security → Firewall & network protection → Advanced settings to reach the classic snap-in. Choose Inbound Rules → New Rule… → Port → TCP → Specific local ports, and enter the port number your mixed or HTTP listener uses (for example 7890). Allow the connection on the profiles you actually use—at home, Private is usually enough; checking Public as well widens exposure on untrusted networks, so only tick it deliberately.

Name the rule something you will recognize later, such as Clash mixed port LAN. If you change ports in YAML, update the rule or add a second one; stale rules are another silent failure mode. Third-party endpoint suites sometimes layer on top of Defender—if you run one, mirror the allow there or watch its packet filter logs when testing from the phone.

Advanced users can verify the allow quickly with PowerShell (elevated), substituting your real port:

netsh advfirewall firewall add rule name="Clash LAN mixed" dir=in action=allow protocol=TCP localport=7890

Remove or disable experimental rules when you are done debugging so you do not accumulate duplicate openings.

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, and set Server to your PC’s IPv4 and Port to the HTTP or mixed port. Leave authentication off unless you configured credentials in the core (most home setups do not). On Android, the exact path varies by OEM; look for the Wi-Fi network details → Advanced → Proxy → Manual, then enter hostname and port similarly.

Open a regular HTTPS site in the phone browser. The first load might be slower while TLS sessions spin up; if you see certificate errors only on domains your ruleset expects to intercept, back off transparent MITM ideas—this walkthrough assumes a normal forward proxy path, not custom root installs on the handset.

Some Android apps ignore system proxy settings entirely. That is not a Clash bug; it is an application design choice. For those cases you would use a per-app VPN on the phone or a different sharing strategy—outside the scope of a basic LAN HTTP proxy.

When it still fails: ordered troubleshooting for Clash LAN proxy setups

Work through the list instead of random toggles. (1) Confirm allow-lan is true and the listener is not bound to loopback only—grep the core log for bind errors. (2) Re-check the port number against YAML and the firewall rule; a typo between 7890 and 7892 wastes an hour. (3) Verify Windows network location is Private on home Wi-Fi so the narrower firewall profile still allows your rule. (4) Test from another PC on the LAN with curl -x http://192.168.1.42:7890 https://example.com to isolate phone-specific quirks. (5) Log into the router and disable AP isolation, client isolation, or guest network features that block device-to-device traffic. (6) Remember corporate or campus SSIDs often forbid peer talking; try a personal hotspot controlled by your phone as a negative control only if policy allows.

If the PC browser works through Clash but the phone does not, you have already proven the exit nodes; the break is almost always LAN reachability or the inbound path. If neither device browses, fix the upstream profile first—export diagnostics and compare with the documentation hub before you touch LAN sharing again.

Security and etiquette on shared networks

Opening even a forward proxy to the LAN increases risk: anyone who can ARP-spoof or join your Wi-Fi might attempt to use the port. Combine allow LAN connections with network you trust, keep Windows patched, and turn LAN sharing off when you leave the house. Do not broadcast instructional screenshots with your real LAN IP and ports if you later reuse them on public networks without adjusting rules.

Compared with running separate tunnel apps on every gadget, sharing one well-maintained Clash core from a desktop you already use daily keeps policy and rule order consistent—as long as you respect the limits of HTTP proxying on mobile OSes. When you want installers that match these guides, prefer the official download page over random mirrors so signatures and release notes stay aligned with what you read here.

Closing thoughts

Using Clash as a LAN helper for a phone is mostly plumbing: correct listen address, explicit allow LAN, a clean Windows Firewall allow on your mixed port, and a phone HTTP proxy aimed at the PC’s IPv4 on the same subnet. Once those pieces line up, the same routing intelligence you already trust on Windows serves mobile browsing without duplicate subscriptions. When you are ready to align your client build with this workflow, start from the maintained packages on the download page so drivers, cores, and docs stay in sync. → Download Clash for free and experience the difference.