What you are building: PC as a LAN forwarder
Think of your desktop as a tiny forward proxy for the subnet. Mobile browsers and many apps honor the operating system’s per‑Wi‑Fi HTTP proxy settings when you set them explicitly; they open a TCP connection to your.pc.ip:port and ask the Meta core to relay TLS bytestreams. That is different from transparent redirection on a router and different from TUN capturing every socket on the phone itself. The upside is simplicity—no OpenWrt flash, no DHCP surgery—while the downside is coverage: apps that ignore manual proxies will still go direct unless you adopt a heavier capture mode elsewhere. For readers comparing game consoles, our Nintendo Switch and PS5 LAN proxy guide covers DHCP and gateway angles that rhyme with this article but target Ethernet-first devices.
Clash Verge Rev sits on top of a Meta-class core. The knobs that matter for LAN sharing are almost always mixed-port (single listener for HTTP and SOCKS), allow-lan (listen on non-loopback interfaces), and sometimes bind-address when you need to be explicit. The GUI may mirror these YAML keys with toggles; the names vary slightly across builds, but the semantics do not: if the listener stays on 127.0.0.1, your phone will never attach even when the IP address is correct.
Prerequisites: same L2 network and a stable PC address
Confirm the boring facts before touching firewall rules. Phone and PC must join the same SSID and the same VLAN if your mesh splits IoT traffic. Guest networks frequently forbid client-to-client communication; that symptom looks identical to a bad proxy port even though the icon shows full Wi‑Fi bars. On Windows, open Settings → Network & Internet → Ethernet or Wi‑Fi → your adapter and note the IPv4 address, subnet mask, and default gateway. You want something like 192.168.1.42/24 with a gateway at 192.168.1.1, not a carrier-grade NAT double stack that changes every hour.
If the PC uses both Ethernet and Wi‑Fi, disable the unused adapter or pin a metric so the phone always targets the interface that actually carries traffic. Mixed adapters confuse documentation because people copy the wrong IP from ipconfig output. Write the chosen address in a sticky note; you will type it repeatedly on mobile.
Mixed port: one listener for HTTP and SOCKS
The mixed-port entry tells the core to accept HTTP proxy requests (including HTTPS via CONNECT) and SOCKS5 on the same TCP port. That matters for phones because Android’s manual proxy UI historically speaks HTTP; some advanced tools want SOCKS. A single mixed listener keeps the mental model small: one number to memorize, one firewall rule to open. Typical community profiles still default near 7890, but your subscription vendor may ship something else—never assume from a screenshot.
# Excerpt — adjust port to match your profile
mixed-port: 7890
allow-lan: true
# bind-address: "*" # optional explicit form in some coresAfter editing, reload the profile inside Clash Verge Rev and verify the core actually started. A silent YAML mistake leaves you debugging phones while the service never bound. Cross-check the UI’s port display against the file on disk; GUI editors occasionally race with external merges.
Allow LAN: why loopback breaks phone access
allow-lan is not cosmetic. When it is false, the Meta core may bind its inbound proxy socket only to 127.0.0.1, which is reachable from browsers on the same machine but invisible to other hosts. Setting it true (or the equivalent GUI toggle) expands the bind so other devices on the LAN can complete TCP handshakes. If you prefer minimal exposure, some advanced users pair allow-lan with interface-specific routes or bind to a single NIC address instead of all interfaces; that is optional hardening once the basic path works.
Security: Any device on the LAN can attempt to use an open mixed port. Use this on networks you trust; avoid coffee-shop Wi‑Fi with allow-lan wide open.
Verify the listener on Windows before touching the phone
On the PC, confirm the port is listening where you expect. In PowerShell, Get-NetTCPConnection -LocalPort 7890 -State Listen (replace the port) should show a listener. If you only see 127.0.0.1, return to allow-lan and profile reload. If you see 0.0.0.0 or the LAN IP, you are ready for cross-host tests. A quick loopback curl from the PC—curl -x http://127.0.0.1:7890 https://example.com—establishes that the proxy path works locally; repeat using the LAN IP from another shell if you want an extra sanity check before picking up the phone.
Windows Defender Firewall: allow inbound on the mixed port
Even with a correct bind, Windows Firewall may block the first inbound SYN from your phone because the connection originates from a remote private address. Create an inbound rule scoped to the Clash-related executable you trust—often the Verge helper or the embedded core binary—not a blind “allow port 7890 from anywhere on Earth” unless you fully understand the tradeoff. GUI path: Windows Security → Firewall & network protection → Advanced settings → Inbound Rules → New Rule. Choose Program, browse to the executable, allow the connection, and restrict profiles to Private when you are on home Wi‑Fi.
If you prefer port-based rules for lab testing, you can allow TCP on the specific mixed port while you validate connectivity, then tighten later. Document which rule you added; duplicate rules are a classic reason people “fixed firewall” three times without removing the stale deny. Third-party security suites may layer on top of Defender—temporarily pause them only if you accept the risk and remember to re-enable.
Android: Wi‑Fi proxy fields that match mixed mode
Open Settings → Network → Wi‑Fi, long-press your SSID, choose Modify network or the advanced gear, expand proxy options, and select Manual. Set the hostname to your PC’s IPv4 address and the port to the mixed-port value. Leave bypass blank unless you need local RFC1918 hosts to skip the tunnel; a minimal bypass list might include localhost,127.0.0.1 and your router’s management IP so you do not lock yourself out of the admin page through a broken rule upstream.
Android’s manual proxy applies to many apps but not all; some vendors ship per-app VPN frameworks instead. If only Chrome works while the system browser fails, suspect app-specific behavior rather than your YAML. For debugging, open Chrome and visit an IP echo service; you should see egress through the node profile attached to the PC’s Clash Verge Rev policy, not the phone carrier.
iOS and iPadOS: HTTP proxy on the Wi‑Fi detail screen
Navigate to Settings → Wi‑Fi → ⓘ next to the network → Configure Proxy → Manual. Fill Server with the PC LAN IP and Port with the mixed listener. iOS applies this to many system frameworks but, like Android, not absolutely every app—especially those that pin certificates or build custom QUIC stacks. If something still leaks direct, you are bumping into application policy, not a missed mixed-port line.
When you still need SOCKS explicitly
Mixed mode covers most browser-shaped traffic. SOCKS-only clients need socks5://ip:port URIs inside apps that support them; they may bypass the global Wi‑Fi HTTP proxy entirely. If you maintain separate port entries for HTTP and SOCKS in YAML, align each tool with the correct scheme—mislabeling produces opaque handshake errors. Most home users should consolidate on mixed-port unless a niche tool forces a split.
Troubleshooting: ordered checks that save hours
Start from the wire, not from ideology. Can the phone ping or reach the PC IP at all? If ICMP is blocked, try a browser to http://pc.ip:debugport only if your core exposes a local dashboard; otherwise use a port-scan app cautiously on your own LAN. No TCP reachability means subnet, isolation, or firewall—not subscription quality.
- IP drift: Did DHCP assign a new PC address? Update the phone proxy host.
- AP isolation / guest SSID: Move both devices to the primary LAN; disable “client isolation” on the AP if you control it.
- Loopback bind: Re-read
allow-lan; confirm listening address with PowerShell. - Firewall: Temporarily allow the port for private profile testing, then narrow.
- Rule mismatch: If TCP works but sites fail, inspect Clash logs on the PC—maybe the phone’s traffic hits
DIRECTwhile DNS is odd; pair with Meta core DNS leak prevention when symptoms look resolver-related. - Multiple NICs: Phone traffic might hairpin through the wrong interface; disable unused adapters briefly.
When LAN HTTP proxy is not enough
Some workloads ignore manual proxies: streaming apps, games with custom stacks, or system services that pin interfaces. In those cases, moving capture to TUN on the PC helps local apps, but phones still need either per-device VPN, a router-level transparent proxy, or a hotspot forwarded through the PC. Read the Clash Verge Rev TUN mode guide for host-side capture details; it complements rather than replaces LAN sharing.
Open source, downloads, and trust
Meta-class cores and Verge Rev publish sources for audit and issue tracking. For installers and update channels, prefer the official Clash download page; treat GitHub as the engineering home while keeping end-user packages aligned with the site’s release policy.
Summary
Sharing Clash Verge Rev to phones on the same Wi‑Fi is a small set of deliberate steps: enable mixed-port and allow-lan, confirm a LAN-visible listener, add a Windows Firewall inbound path for the trusted executable, then aim the handset’s manual Wi‑Fi proxy at pc-ip:port. Compared with opaque “it worked yesterday” threads, this sequence is testable at every layer—bind address, firewall, reachability, then policy logs. Compared with one-size-fits-all VPN apps on every device, it keeps configuration centralized on a machine you already trust for your subscription.
When the PC stays healthy and logs stay readable, mobile browsing through the tunnel stops feeling like magic and starts feeling like ordinary routing—with fewer mystery disconnects after router reboots or DHCP renewals.