Why Clash Looks “On” While Other Devices Still Fail
Most beginners get Clash working for the machine where it runs and assume the rest of the house should magically follow. In reality, a default Clash or mihomo profile is optimized for local loopback: the mixed HTTP and SOCKS listener binds to 127.0.0.1, allow-lan stays off, and the operating system firewall treats unsolicited inbound TCP to that port as hostile. Your tablet never gets a clean path—so Safari spins, Discord stays direct, and curl from another PC prints “connection timed out” even though the tray icon looks healthy.
This article is a field checklist for LAN proxy sharing: the scenario where one trusted computer runs Clash and other devices on the same subnet point their manual proxy settings (or per-app proxy) at that host’s LAN address. It complements our Windows setup tutorial and the deeper networking story in the TUN mode guide, but it focuses on the narrow problem statement “same Wi‑Fi, different device, still no proxy,” which those guides only touch in passing.
What You Are Building (and What TUN Does Not Solve by Itself)
TUN mode on the host captures traffic originating on that host and feeds it through Clash rules. It does not automatically re-route packets that originate on your phone unless you build a completely different topology (hotspot gateways, policy routing, or a dedicated gateway device). For a typical home user, the straightforward pattern is:
- Host PC runs Clash with a reachable
mixed-port(or separateport/socks-portif you split them). - Other devices configure an explicit HTTP or SOCKS proxy pointing to
192.168.x.y:7890(example values). - DNS on the client may still need thought: some apps use system DNS before the proxy handshake; others honor proxy-only resolution. If pages load but names fail, adjust client DNS or add split rules after the tunnel is proven.
Keep that mental model in mind when reading logs. If the remote device never completes a TCP handshake to your mixed-port, no amount of subscription tweaking will help—the failure is purely local networking.
Safety First: Treat a LAN Listener Like a House Key
Opening your proxy port to the LAN means anyone who can join that network—roommates, visitors on the Wi‑Fi password, a compromised IoT gadget—could attempt to relay traffic through your machine. That may violate your ISP terms, campus policy, or workplace acceptable-use rules. Before you proceed, decide whether you are on a trusted private LAN and whether you accept that risk.
Mitigations worth adopting in parallel with this guide include: using a guest SSID only when you must share, disabling legacy WEP, rotating Wi‑Fi passwords after parties, and keeping the external controller bound to 127.0.0.1 with a non-empty secret if your GUI ever tempts you to expose the REST API. Never forward the controller port through your router to the public Internet unless you are writing a deliberate remote-admin design and understand credential brute forcing.
Prerequisites: Same Subnet, Real IPv4, No Silly Typos
Confirm the basics before editing YAML. Both devices must join the same Layer-2 broadcast domain in consumer language: the phone should show an address like 192.168.1.43 while the PC shows 192.168.1.17, sharing the same /24 prefix. If the phone sits on a cellular data IP or a VPN interface, it will ignore your LAN instructions. Likewise, if the PC is on Ethernet and the phone on a “Guest” SSID that maps to a different VLAN, many routers deliberately block device-to-device traffic—more on that in a later section.
On Windows, run ipconfig and note the Wireless LAN adapter Wi-Fi or Ethernet adapter IPv4, not the 169.254.x.x autoconf address and not a virtual Hyper-V switch unless that is genuinely where your Wi‑Fi terminates. On macOS, hold Option while clicking the Wi‑Fi menu for your RFC1918 address. Write it down; you will paste it into mobile proxy settings verbatim.
Step 1 — Enable allow-lan and Fix bind-address
Clash-family cores gate LAN access behind allow-lan. When it is false, the daemon refuses connections sourced from other hosts even if the OS firewall permits them. Flip it to true in the profile your GUI loads (sometimes labeled “Allow LAN” in advanced settings, but the YAML remains the source of truth).
Next, inspect bind-address. Older examples used 0.0.0.0; newer mihomo templates often accept * to mean “all interfaces.” If the key is missing, the core may default to loopback-only behavior depending on version—when in doubt, set it explicitly after reading your engine’s release notes. A representative excerpt looks like this:
# LAN-sharing excerpt (adjust port to match your profile)
allow-lan: true
bind-address: '*'
mixed-port: 7890
If you intentionally separate listeners, you might see distinct port (HTTP) and socks-port entries instead of a single mixed-port. That is fine: your downstream devices simply use the appropriate scheme—HTTP proxy for port, SOCKS5 for socks-port. Mixed mode exists precisely so one number feeds both stacks, which keeps mobile configuration shorter.
After saving, reload the profile from your client. Many GUIs cache the old runtime until you explicitly restart the core; if unsure, quit the app completely and launch again so the listener table refreshes.
Step 2 — Prove the Port Is Actually Listening on the LAN Interface
Verification separates configuration bugs from firewall bugs. On Windows PowerShell, run netstat -ano | findstr 7890 (replace with your port). You want a line that shows LISTENING on 0.0.0.0:7890 or your specific NIC address—not only 127.0.0.1:7890. If you still see loopback-only binding, revisit bind-address or check whether the GUI injected an override JSON.
From a second device, try nc -vz 192.168.x.y 7890 on Linux or macOS, or PowerShell’s Test-NetConnection 192.168.x.y -Port 7890. A clean result reports TcpTestSucceeded : True. If this step fails, do not touch firewall rules yet—your core is still not publishing where you think it is.
Step 3 — Windows Defender Firewall: Inbound Rule the Patient Way
Once netstat shows the listener on 0.0.0.0 or * but remote tests still fail, Windows Firewall is the usual culprit. Windows treats inbound initiation to non-standard ports as public-network traffic unless you carve an exception. Create a rule that is as narrow as practical:
- Open Windows Security → Firewall & network protection → Advanced settings to launch the legacy snap-in.
- Choose Inbound Rules → New Rule….
- Select Port, then TCP, and specify Specific local ports with your
mixed-port(for example7890). - Action: Allow the connection.
- Profile: at minimum tick Private; only enable Public if you understand you are exposing the rule on coffee-shop networks too.
- Name it clearly, e.g. “Clash mixed-port 7890 LAN.”
If you also expose a separate SOCKS port, duplicate the rule or specify a comma-separated port list in one rule—just keep auditing easy next year when you forget why port 7891 was open.
Third-party security suites sometimes layer their own network filters above Windows Firewall. If packets still die after a correct rule, pause or whitelist the Clash core executable inside that suite’s UI, then retest with Test-NetConnection.
macOS and Linux Notes (Short but Honest)
On macOS, the built-in application firewall may block unsigned binaries until you approve them under System Settings → Network → Firewall. Linux desktops vary: ufw users run sudo ufw allow 7890/tcp from the LAN zone, while firewalld users attach a rich rule to the trusted interface. The diagnostic pattern is identical: confirm listen sockets with ss -lntp, then open the minimum port in the active firewall backend.
Step 4 — Configure Phones, Tablets, and Browsers
iOS and Android hide full-device HTTP proxying in different places, but both want the same tuple: host = your PC’s IPv4, port = mixed-port. On iOS, you typically set Wi‑Fi → ⓘ → Configure Proxy → Manual. Android 13+ often exposes Proxy on the advanced Wi‑Fi pane; vendor skins may relocate it. Remember that many mobile apps ignore system HTTP proxies—chat apps and games may need per-app tooling or a VPN profile instead.
Desktop browsers on the satellite machine should use the same endpoint. If you test with Firefox, open Settings → Network Settings and choose manual proxy with the LAN IP. Chrome on Windows generally follows the system proxy dialog; set it under Settings → System → Open your computer’s proxy settings and point HTTP/HTTPS to the LAN host.
When the Router Silently Blocks “Client-to-Client” Traffic
Enterprise-grade and some mesh kits ship with AP isolation, wireless client isolation, or “Guest network” modes that forbid Wi‑Fi stations from talking to each other—only to the Internet through NAT. Symptom: every LAN test fails even though Windows Firewall is wide open and netstat is perfect. Fix: log into the router, disable isolation for the SSID you actually use, or move both devices to a “Home” network that permits east-west traffic. There is no YAML knob for that; it is pure infrastructure.
Double-NAT scenarios (ISP modem + your router) rarely break same-subnet proxying, but they complicate port-forwarding if you ever mistakenly attempt to expose the proxy WAN-side. For LAN sharing you should not need port forwarding at all; if you thought you did, re-read the threat model section above.
Troubleshooting Matrix: Symptom → Likely Cause → Next Click
Immediate “Connection Refused” from Another Device
Refusal before a timeout means something actively rejected the SYN packet—either the core is not listening on that interface, allow-lan is still false, or a firewall dropped the handshake. Re-run the netstat check and temporarily disable the firewall profile as a diagnostic (re-enable seconds later) to see which layer lies.
Timeouts with No RST Packet
Timeouts often indicate Wi‑Fi isolation, wrong IP (you grabbed the Hyper-V virtual switch), or the phone is still on cellular with Wi‑Fi assistant blending connections. Airplane mode on for a second, then Wi‑Fi only, retest.
Browser Works on the Host but Not on the Guest
The guest may be using DNS that bypasses your rules, or the app ignores proxies. Swap DNS on the guest to a neutral resolver temporarily, and retest with a pure HTTP site. If only HTTPS fails, inspect certificate inspection tools or corporate SSL proxies—not usually Clash’s fault.
High Latency Only on LAN Clients
You might be hair-pinning through a slow node while the host browser used a different profile. Align both devices to the same outbound group and disable exotic uot experiments while benchmarking.
Optional Hardening: Authentication and Access Control
Plain HTTP proxies on a LAN trust whoever can reach the port. Some distributions support SOCKS or HTTP authentication parameters; if yours does, enable credentials after everything works unauthenticated, then update each client. Also consider binding to a specific interface IP instead of * if you multi-home and only want Wi‑Fi clients to participate.
Closing the Loop: LAN Sharing Is Wiring, Not Magic
When every checklist item lines up—correct IPv4, allow-lan, explicit bind-address, a verified mixed-port listener, a tight Windows Firewall (or OS equivalent) rule, and a router that is not isolating stations—other devices on the same Wi‑Fi can share one Clash instance without installing another full tunnel stack. Compared with ad hoc hotspot gateways, this pattern is boring, which is exactly why it stays reliable.
If you still live entirely on localhost, grab a maintained build, walk through the LAN steps once, and you will recognize the same symptoms instantly the next time a friend asks why “the proxy works on my laptop but not my iPad.” Compared with stitching together random forum snippets, a current Clash-compatible client plus disciplined firewall hygiene is noticeably calmer to operate day to day.
→ Download Clash for free and experience the difference when you are ready to standardize on one core across every device you actually use.