Clash LAN Proxy: Enable mixed-port, allow-lan, and Add Phones or PCs

Why LAN sharing instead of per-device installs

Running Clash on one trusted machine is often simpler than maintaining identical profiles across iOS, Android, and multiple desktop OS builds. A phone might not expose the same rule-editing experience as your desktop GUI, yet it still benefits from the same node selection and policy groups if traffic is forwarded through the host. The trade-off is architectural: you are centralizing trust and bandwidth on that host, and you must keep its firewall posture sane because you are deliberately exposing a proxy listener to the local network segment.

Another motivation is consistency. When your subscription, rule providers, and policy groups already behave well on Windows or macOS, pointing other devices at the same inbound port means they inherit that behavior without duplicating YAML merges or remote-rule sync logic. The mental model is simple—the Clash process listens on a TCP port; LAN clients connect to your computer’s private IPv4 address on that port, and Clash forwards outbound according to its rules. What changes is only who may open that listener: localhost by default, or the whole LAN when allow-lan is true and the bind address permits it.

If you have never completed a baseline install on desktop, start with the Clash for Windows setup guide or the macOS-focused Clash Verge Rev article before you tune LAN access. The steps below assume your profile loads, nodes respond, and you can browse in Rule mode on the host itself.

People also ask whether they should share Clash at all when every platform has its own client. The honest answer is workload-dependent. If you only need one phone browser occasionally, installing a lightweight mobile client might be cleaner. If you maintain a household with mixed ages and skill levels, a single well-instrumented desktop that already carries your subscription and rule hygiene can reduce support burden—provided you document the LAN IP and port on a sticky note and teach everyone to stay on the home SSID. Enterprise administrators sometimes mirror a similar pattern for lab VLANs: one jump host terminates policy, endpoints consume a simple forward proxy. The home version is smaller in scale but shares the same topology vocabulary.

What mixed-port does for multi-client sharing

Historically Clash exposed separate listeners for HTTP and SOCKS. A mixed port unifies them: one TCP port speaks both HTTP proxy and SOCKS5 on the same socket, which keeps instructions short when you configure phones—many mobile Wi‑Fi proxy screens only accept a host, port, and sometimes an authentication block, not a long explanation of two different ports. When documentation says “point the device at port 7890,” that single number is often the mixed listener in a default Meta-class profile.

If your config still sets port and socks-port separately, you can keep using those; just tell each client whether it expects HTTP or SOCKS semantics. Mixed mode simply reduces friction: browsers, system proxy panels, and generic “manual proxy” fields frequently default to HTTP CONNECT on the same numeric port that SOCKS clients also use in mixed setups. Verify the actual value in your running config—GUI wrappers sometimes display a merged port while the YAML still lists legacy keys until you save.

From a network-engineering angle, mixed ports do not change how Clash applies rules after the session is accepted. They only change how many listening sockets you maintain and how you document the port number for family members. If you ever script health checks—say, a cron job that curls through the proxy—use the same port your phone uses so you are not testing a different code path than the rest of the household. When performance tuning, remember that every device funnels through one host NIC; saturated Wi‑Fi airtime or a slow USB Ethernet dongle on the Clash machine becomes the shared choke point, not an upstream node issue.

Some Meta-class profiles also expose an external-controller REST or WebSocket endpoint for dashboards. That is separate from the mixed proxy port: do not confuse the two when writing firewall rules. Locking down the controller to localhost while the proxy port is LAN-visible is a common hardening pattern—your phone needs the proxy listener, not the management API, unless you deliberately browse the dashboard from another device.

allow-lan, bind-address, and who may connect

By default many builds bind proxy listeners to loopback only, which blocks phones from reaching your PC even when everyone shares the same SSID. Setting allow-lan: true tells Clash it should accept connections from non-local addresses, subject to how bind-address is set. The common pairing is allow-lan: true with bind-address: '*' or an explicit 0.0.0.0 style wildcard so the service listens on all IPv4 interfaces that are up—including your Wi‑Fi adapter’s address.

Some users tighten this by binding only to the LAN-facing NIC’s address. That can work, but it breaks silently if DHCP gives you a new lease after a router reboot. For home labs, wildcard bind plus host firewall rules is often easier to reason about than chasing a moving per-interface IP in YAML. Enterprise or multi-homed servers are different: there you might bind explicitly to avoid leaking a listener onto the wrong VLAN.

Remember that allow-lan is not authentication. Anyone who can reach your laptop on that TCP port may send traffic through your Clash instance unless you add another layer (separate SSID, MAC filtering at the AP, VPN overlay, or application-level auth where supported). Treat the LAN as a trust zone, not a public internet edge.

Find the host IPv4 address and confirm one subnet

Other devices need the private IPv4 of the machine running Clash—typically something like 192.168.x.x or 10.x.x.x. It must live on the same broadcast domain as the client: same router, no Layer-3 hop in between unless you really know what you are doing. On Windows, ipconfig under the active Wi‑Fi adapter shows the address; on macOS and Linux, ipconfig getifaddr en0 or ip addr for the wireless interface are common shortcuts.

Double-check that you are not quoting a virtual adapter from a VPN or from Clash’s own TUN stack. If the GUI shows multiple addresses, pick the one that matches your router’s DHCP range for Wi‑Fi. If the address changes often, consider a DHCP reservation on the router so documentation you write for family members does not rot every week.

While you are collecting numbers, note whether your Clash dashboard or tray icon shows System Proxy enabled on the host. System proxy affects only local applications; it does not replace allow-lan for remote clients. Conversely, turning on TUN on the host does not magically proxy other devices—you still need explicit inbound listeners and routing on each client unless you run a full gateway, which is outside this article’s scope.

Multihomed laptops deserve a short warning. If you simultaneously connect Ethernet and Wi‑Fi, the operating system may pick a preferred route that does not match where your phone sits. Either disconnect the unused interface during testing or pin Clash’s bind behavior so you know which subnet is authoritative. Corporate VPNs that add a virtual NIC with a lower metric can also make your “Wi‑Fi IP” look correct in the UI while return traffic prefers another path—symptoms include intermittent half-open sessions from phones. Simplify the network graph during debugging: one radio, one subnet, one gateway.

Sanity-check the listener before involving other devices

On the host, confirm the mixed port is open locally. From a terminal, curl -x http://127.0.0.1:7890 https://www.example.com (replace the port) should return HTML if your rules permit that host. If that fails, remote clients will not fare better. On Windows, netstat -ano | findstr 7890 shows which PID owns the socket; on Linux/macOS, ss -lntp or lsof -iTCP:7890 -sTCP:LISTEN does the same. You want to see LISTEN on 0.0.0.0 or your LAN address after allow-lan—not only on 127.0.0.1.

From a second device, if you have a terminal (Termux on Android, SSH into a Linux box), try curl -x http://<host-ip>:<port> https://www.example.com. That isolates Wi‑Fi from browser quirks. If curl works but Safari does not, you are dealing with application proxy bypass, not Clash. If curl fails with a timeout, return to ping and port reachability before touching YAML again.

Minimal YAML shape (illustrative)

Exact keys vary slightly between Clash Premium, Meta, and GUI forks, but the following pattern is widely recognized. Adjust the port to match your profile; avoid conflicting with other services.

# Illustrative — align with your core and GUI
mixed-port: 7890
allow-lan: true
bind-address: '*'
# Optional explicit IPv4 bind:
# bind-address: 0.0.0.0

If your editor merges remote snippets, confirm these lines survive the merge and are not overridden by a profile fragment that resets allow-lan to false. Some subscription packs ship conservative defaults; your local override file should win after you understand the merge order your client uses.

Setting	Role
mixed-port	Single inbound for HTTP and SOCKS-style clients sharing one number
allow-lan	Permit connections from other machines on the LAN
bind-address	Which local interfaces expose the listener—wildcard vs specific IP

When you paste snippets from forums, watch for duplicate keys. YAML’s last-wins behavior means a hidden allow-lan: false at the bottom of a merged file can undo your toggle. GUI editors that show a pretty form may still serialize a full document on save—diff before and after to ensure your LAN intent persisted. If you rely on a provider’s remote config for proxies and rules but keep a local config.yaml for inbound, understand whether your client merges them as a single document or overlays patches; either way, the effective runtime view is what matters, not what you think you typed.

GUI clients: where these switches hide

Commercial forks wrap the same concepts under different labels. You might see “Allow connections from the LAN,” “Bind to all interfaces,” or a toggle for “Mixed port” alongside numeric fields. If the UI offers both a switch and raw YAML, prefer one source of truth—flip the switch and let the editor write YAML, or manage YAML exclusively and reload the core. Mixing manual edits with unsynchronized GUI state is how you end up with allow-lan true in the file but a stale process that never restarted.

After any change, watch the log window for “RESTful API” or “proxy listening” lines that echo the bound address. Some builds print 192.168.x.x:7890 explicitly when LAN is enabled; others only say “started” without detail, which is your cue to use ss or Task Manager networking tabs. If your GUI supports “Open config folder,” keep a backup of the last known-good YAML before experimenting—rollback is faster than reconstructing merges from memory.

Per-OS firewall: the usual reason LAN works on localhost only

Windows: Windows Defender Firewall defaults to blocking unsolicited inbound connections on public profiles. Mark your home Wi‑Fi as private when appropriate, then create an inbound rule allowing TCP on your mixed port for at least the private profile scope. The quick path is Windows Defender Firewall with Advanced Security → Inbound Rules → New Rule → Port → TCP → specific local ports → allow the connection → apply to Private. If you still see blocks, check whether a third-party suite replaced the stack. Hyper-V virtual switches and WSL sometimes add extra interfaces—your rule should target the Wi‑Fi NIC context if you scope by interface.

macOS: Application firewalls prompt when a binary first listens. If you denied Clash earlier, open System Settings → Network → Firewall → Options and allow incoming connections for your Clash helper. The macOS application firewall is stateful; if you moved Clash between App Store and standalone builds, the signature may have changed and you might need to re-approve. If you use Little Snitch or similar tools, create a LAN-only allow rule for TCP to your mixed port from the local subnet—avoid global “allow any” unless you understand the trade-off.

Linux desktop or headless server: ufw allow from 192.168.0.0/16 to any port 7890 proto tcp is a blunt but readable starting point; tighten the source CIDR to your actual DHCP range. For firewalld, use a rich rule that references your zone. Remember that Docker and LXC can publish their own iptables rules—if Clash runs in a container, map the port with -p and ensure the host firewall still allows the forwarded traffic. On systemd-based units, confirm Restart=always so a failed reload does not leave you with a closed port and no obvious error on phones.

Phones and tablets: where to type the proxy

Android (varies by vendor) usually exposes Wi‑Fi advanced options: long-press the network, edit, expand advanced settings, set manual proxy with hostname 192.168.x.x (your host) and port 7890 or your mixed port. Some builds label HTTP proxy fields; if only HTTP is available, mixed ports still work for many apps that honor the system proxy hook.

iOS and iPadOS historically focused on HTTP proxies in the Wi‑Fi detail screen. Pick manual configuration, server equals your host LAN IP, port equals the mixed port. Not every app respects the system proxy—banking apps and some media stacks may bypass it—so validate with Safari or a simple fetch tool first.

For apps that ignore system proxy, you may need per-app VPN solutions or a dedicated client on the device; this article stays with the standard “same Wi‑Fi manual proxy” path that matches most search intent. If pages load but DNS behaves oddly, revisit the DNS and fake-ip walkthrough on the host—remote clients inherit resolver behavior through the tunnel Clash builds.

Android versions differ in whether they apply per-network proxy to mobile data when you switch away from Wi‑Fi. After testing at home, turn the manual proxy off or switch to a different saved profile before you leave—otherwise applications may stall looking for a proxy that only exists on your LAN. iOS exposes similar foot-guns if you forget which SSID still carries manual proxy settings; the symptom is “everything broke” when you arrive at the office because the device still points at a 192.168 address that is not there.

Game consoles and smart TVs rarely offer full HTTP proxy forms; they are not the target audience for mixed-port LAN sharing. For those platforms you would need transparent routing or DNS-level steering on the router—topics that belong in a dedicated gateway guide, not a quick LAN proxy checklist.

Another computer: browsers and environment variables

On a second PC, configure the browser or OS network settings to use an HTTP or SOCKS proxy pointing to <host-LAN-IP>:<mixed-port>. Command-line tools often respect HTTP_PROXY and HTTPS_PROXY variables; SOCKS may need ALL_PROXY depending on the tool chain. Keep encryption expectations straight: traffic hops to your Clash host in cleartext on the LAN segment unless you add TLS layers yourself—another reason to stay off untrusted networks when testing.

If the second machine already runs its own Clash, disable double-proxying. Either pause the local client or point only specific applications at the shared host so you do not nest tunnels unintentionally and confuse latency measurements.

On Linux, desktop environments may read proxy settings from GNOME or KDE control panels; those often map to gsettings keys. On Windows, only the current user’s WinINET profile may update when you toggle “Use a proxy server” inside Edge—other services might ignore it. Documenting a single approach (curl with explicit -x for tests, browser extension for browsing) keeps your support story consistent when something “works in Terminal but not in Chrome.”

Security posture: what you are really opening

LAN-wide listeners increase blast radius if malware lands on any device in the household. Combine allow-lan with sensible habits: patch the OS, avoid public SSIDs with the same config, and disable LAN access when you leave the house if your firewall rules are hard to toggle. Some users bind only while at home and flip allow-lan off in a scripted workflow—practical if your GUI exposes a quick toggle.

Do not confuse this setup with outbound VPN marketing language. You are not “encrypting the Wi‑Fi” to the router; you are offering a proxy port on one host. Anyone with access to that port could abuse your egress policy if your rules permit broad destinations. Narrow policy groups and logging help detect surprise usage.

If your household includes children’s devices, consider a separate SSID with parental controls and do not point those devices at a wide-open proxy unless you understand what they can reach through your policy groups. Logging on the Clash host—when available—helps identify unexpected domains or volume spikes that could indicate a neighbor borrowed your Wi‑Fi password and is now funneling traffic through your laptop because you left allow-lan on during a party.

Troubleshooting when devices cannot connect

Symptom: timeout from phone, host browser still works via localhost. First ping the host IP from the second device if the OS allows it. Failure usually means wrong IP, different VLANs, or AP isolation. Success without proxy working points to blocked TCP to the mixed port—check OS firewall on Windows (wf.msc inbound rule for TCP on your port), macOS application firewall prompts, and ufw or firewalld on Linux.

Symptom: connection refused. Clash is not listening on that interface, or another process seized the port. Verify the running config actually shows allow-lan true after reload. Restart the core after YAML edits; many GUIs cache until you apply.

Symptom: partial apps work. Some binaries bypass proxies by design. Test with a known proxy-aware browser. If HTTPS errors mention certificates, you might be hitting a middlebox rather than Clash—rare on LAN tests but worth noting when corporate SSL inspection exists on another network.

Symptom: works briefly then stops after sleep. Laptops may drop Wi‑Fi power states or change interface metrics. Disable aggressive sleep during long sessions or pin the wireless adapter power settings on Windows. On macOS, wake cycles sometimes reorder service precedence—recheck the IPv4 you advertise to phones.

Symptom: phone can browse HTTP sites but HTTPS fails with certificate errors. You might be pointed at the wrong port (HTTP-only listener) or a captive portal is intercepting. Rarely, an enterprise root on the phone conflicts with inspected traffic—test with a simple GET to a well-known host. If only one app fails, suspect proxy bypass, not Clash.

Symptom: extremely high latency on the phone only. The phone’s Wi‑Fi radio might be on a crowded channel, or the Clash host is CPU-throttling encryption. Compare speed tests with proxy off versus on. If the host CPU is pegged, consider a lighter ruleset or a faster node group—LAN sharing amplifies any bottleneck on the machine doing the work.

Symptom: “works for my roommate’s Android but not my iPhone.” Compare whether both use the same manual proxy screen, whether either uses a VPN profile that overrides Wi‑Fi settings, and whether iCloud Private Relay is enabled—Relay can interfere with split tunnel expectations. Disable one variable at a time.

FAQ

Should I use IPv6 between devices?

If your LAN uses IPv6 ULAs and clients prefer them, ensure Clash listens appropriately and your addresses stay stable. Many home setups still document IPv4 only; start there to reduce variables.

Does TUN on the host replace LAN sharing?

No. TUN redirects traffic originating on that machine. Other devices still need their own proxy settings or a router-level gateway strategy.

Can I change the mixed port?

Yes—pick any free TCP port, update YAML, restart, and propagate the new number to every client. Avoid collisions with development servers or database defaults.

Does Clash support username/password on the inbound proxy?

Core capabilities depend on your fork. Some Meta builds expose authentication hooks for inbound proxies; many home setups skip auth and rely on physical LAN trust. If you need auth, consult your client’s documentation—do not assume a random snippet from an old thread applies to your current binary.

What about mesh routers or repeaters?

Mesh backhaul should still present one subnet to wireless clients if configured in bridge-like modes. If a satellite creates a double NAT or a different VLAN, you may need to adjust routing or place the Clash host on the same mesh node as the test phone for initial debugging. Simplify: connect both devices to the primary router’s Wi‑Fi once to rule out mesh oddities.

Checklist before you ask why it fails

Get a maintainable client on the host

LAN sharing works best when the machine running Clash stays updated and its configuration is easy to diff. If you are new to the ecosystem, the beginner guide covers subscription import and modes at a slower pace.

Download Clash for free and experience the difference