How LAN proxy sharing works and when to use it
LAN proxy sharing lets other devices connect to a proxy listening on your computer, provided by Clash or the Clash Meta (mihomo) core. Traffic flows from your phone or TV to your computer's LAN address and port, through the core's rules, and then to the selected outbound. The computer and client core must stay running; when the computer sleeps, the connection path is interrupted.
This guide uses the following example settings: the computer's IPv4 address is 192.168.1.20, the mixed port is 7890, and the home subnet is 192.168.1.0/24. These are configuration examples, not values detected from your network. Replace the computer address with the one assigned to your active network adapter.
- Works for devices or apps that let you configure an HTTP or SOCKS5 proxy manually.
- Requirements: The device must be able to reach your computer's LAN address, and the computer's firewall must allow the inbound connection.
- Limit: An HTTP proxy set for Wi-Fi usually doesn't cover every app and is not a transparent proxy for the entire device.
- Note: Sharing a listening port doesn't require making the computer the default gateway or enabling TUN mode.
mixed-port, allow-lan, and bind-address
These three settings address different things: which protocols to listen for, whether to accept LAN connections, and which local address to bind to. They belong at the top level of the configuration, alongside proxies, proxy-groups, and rules—not nested under an individual proxy node.
| Setting | Example value | Purpose |
|---|---|---|
mixed-port | 7890 | Accepts both HTTP and SOCKS proxy requests on the same port. |
allow-lan | true | Allows the core to accept proxy connections from LAN devices. |
bind-address | "*" | Binds to all addresses; use firewall rules to restrict which sources can connect. |
port | 7891 | A separate HTTP proxy listener; not required when using a mixed port. |
socks-port | 7892 | A separate SOCKS proxy listener, which you can configure if needed. |
Minimal settings for sharing
mixed-port: 7890
allow-lan: true
bind-address: "*"
Merge these settings into your existing configuration; this is not a complete subscription configuration. Keep your existing nodes, proxy groups, DNS settings, and rules. If a top-level mixed-port is already present, change its value rather than adding a duplicate. Also make sure port or another listener isn't already using 7890.
Keep the quotes around "*" so YAML doesn't interpret the asterisk as an alias. To listen on just one network adapter, set bind-address to 192.168.1.20. This requires a stable address; if the computer changes networks or its DHCP address changes, the listener may fail. Update the configuration if that happens.
external-controller is the control interface, not the proxy entry point for devices. On your phone, enter the 7890 value configured for mixed-port—not the control interface port. Exposing the control interface on your LAN is not necessary for proxy sharing.
On the computer: confirm the address, apply the settings, and check the listener
1. Find the active LAN IPv4 address
On Windows, go to Settings → Network & Internet → Wi-Fi → your current network's properties and check the IPv4 address. For a wired connection, look under Ethernet. Or open a terminal, run ipconfig, and find the IPv4 address and subnet mask for the active network adapter.
On macOS, go to System Settings → Network → your current connection → Details → TCP/IP. Don't use the loopback address 127.0.0.1, a virtual adapter address, or an address for a disconnected adapter. On another device, 127.0.0.1 points to that device itself, not your computer.
2. Edit the configuration that's actually in use
- In your client, confirm which configuration is active and note the current port and LAN access setting.
- Use the client's supported configuration editor, override, or merge feature to add the three top-level settings above.
- Save and reload the configuration. If the client asks you to restart the core, follow the prompt.
- Check the runtime log for YAML parsing errors or port conflicts.
Setting names and override precedence vary between clients. The UI option “Allow LAN connections” usually maps to allow-lan, but directly editing a generated subscription file may not survive an update. Use the client's persistent override feature where possible, then check the effective runtime configuration—not just the original subscription text in the editor.
3. Check that the port listens on a reachable address
In Windows PowerShell, run the command below to see the TCP listening address. On macOS, you can use the second command:
# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890
# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN
If you only see 127.0.0.1:7890, other devices can't reach the listener through your computer's LAN IPv4 address. When bound to all IPv4 addresses, you'll commonly see 0.0.0.0:7890; when bound to a single address, you should see 192.168.1.20:7890. If the listener is shown as an IPv6 wildcard, verify IPv4 reachability with a remote test and account for your system's dual-stack behavior; the listener notation alone isn't enough to tell.
Firewall and Wi-Fi isolation
allow-lan: true doesn't automatically open your operating system's firewall. If the port is listening but another device times out, check the network profile, inbound rules, and wireless client isolation before changing proxies.
Windows: Allow TCP 7890 on private networks only
On a trusted home network, first confirm Windows identifies the current connection as a Private network. Open Windows Security → Firewall & network protection → Advanced settings, then create a port rule under Inbound Rules: select TCP, enter 7890 as the specific local port, allow the connection, and select Private only. Under the rule's Properties → Scope, restrict remote IP addresses to your actual home subnet.
You can also create a restricted rule from an elevated PowerShell prompt. This example allows only 192.168.1.0/24 to reach TCP 7890 on 192.168.1.20; update the addresses to match your network before running it.
New-NetFirewallRule -DisplayName "Clash LAN TCP 7890" `
-Direction Inbound -Action Allow -Protocol TCP `
-LocalAddress 192.168.1.20 -LocalPort 7890 `
-RemoteAddress 192.168.1.0/24 -Profile Private
This rule is for the HTTP proxy connection test in this guide; it doesn't configure SOCKS5 UDP forwarding. Check any existing broad allow rules too—a new restrictive rule doesn't automatically narrow other allow rules. Don't leave the firewall disabled as a workaround.
Check macOS and your router
- On macOS, check inbound access for the client or the core that's actually running under System Settings → Network → Firewall → Options. “Block all incoming connections” may prevent sharing.
- Even when your phone and computer use Wi-Fi with the same network name, they may be on a guest network or different VLANs, or blocked by AP isolation.
- Using Ethernet on the computer and Wi-Fi on the phone isn't inherently a problem; what matters is whether the router allows them to communicate.
- You don't need to set up port forwarding from the internet, and you shouldn't add the proxy port to the DMZ.
What to enter on phones, TVs, and game consoles
iPhone and iPad: Set an HTTP proxy for the current Wi-Fi network
- Go to Settings → Wi-Fi and tap the info button next to the current network.
- Tap Configure Proxy and select Manual.
- Enter
192.168.1.20for Server and7890for Port. - The basic configuration in this guide doesn't use proxy authentication, so leave authentication off. Save the settings and test in a browser.
Enter only the IP address in the Server field—not http://, and not the port. This setting applies to the current Wi-Fi network; it won't keep using this LAN address when you switch to mobile data.
Android: Set a manual proxy for the current network
A common path is Settings → Network & internet → Internet → current Wi-Fi network → Edit → Advanced options → Proxy → Manual. Names vary by device manufacturer. Set the proxy hostname to 192.168.1.20 and the proxy port to 7890. During testing, leave the bypass list simple so the test domain isn't excluded.
Android Wi-Fi proxy settings also rely on apps honoring the system proxy. If a browser works but one app doesn't, that doesn't necessarily mean the port is misconfigured. Check whether the app supports HTTP proxies or has its own network settings.
TVs and game consoles: Use the proxy type the device supports
If the network settings offer an “HTTP proxy server” option, enter the same address and port. If they offer only SOCKS5, the mixed port can accept those proxy requests too, but the app must actually support SOCKS5. A device without a manual proxy setting can't gain HTTP proxy support just by changing its DNS.
After setting an HTTP proxy on a game console, store pages, downloads, or sign-ins may behave differently, but multiplayer game traffic may not use that port. UDP traffic in particular means a successful web page test doesn't prove all game traffic is being proxied. Don't set your computer as the default gateway unless you've separately configured IP forwarding, routing, and a transparent proxy.
Test each layer: the port, proxy request, and outbound route
First verify that the connection reaches the listening port, then check the destination website and routing rules. Run the commands below from another computer on the LAN. Testing on the proxy computer itself only checks the local path; it doesn't adequately test the firewall or wireless isolation.
# Windows PowerShell: check the remote TCP port
Test-NetConnection 192.168.1.20 -Port 7890
# Use curl.exe on Windows; use curl on macOS or Linux
curl.exe -I --connect-timeout 5 --max-time 15 \
--proxy http://192.168.1.20:7890 https://example.com/
The backslash line continuation above works in common Unix shells. On Windows, use the following curl command as a single line to avoid differences in PowerShell continuation syntax:
curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://192.168.1.20:7890 https://example.com/
https://example.com/ is a connectivity test target, not a service specifically designed to verify your proxy's exit route. A 200 Connection established response confirms only that the HTTP CONNECT tunnel was established; also check the subsequent TLS connection and destination response. Then check the client's connection list for the source IP, matched rule, and outbound chain to see whether the request went DIRECT or through a proxy policy.
| Symptom | Check first | Next step |
|---|---|---|
| Connection refused | The core isn't running, the port is incorrect, the listener is bound only to loopback, or the firewall is actively rejecting connections | Check the effective configuration and TCP listener. |
| Connection timed out | The firewall is dropping traffic, the guest network is isolated, or the computer's address has changed | Check that both devices are on reachable subnets and review inbound rules. |
| HTTP 407 response | The active configuration requires proxy authentication | Check the authentication settings and device support; don't keep changing proxy nodes. |
| Port is reachable, but the website fails | Rules, proxy nodes, destination DNS resolution, or the upstream connection | Check the request log and actual outbound route. |
| Browser works, game doesn't | The app bypasses the proxy or uses UDP traffic the proxy doesn't cover | Verify the protocol and the device's proxy support. |
To test SOCKS5, run curl --proxy socks5h://192.168.1.20:7890 https://example.com/. With socks5h, the proxy resolves the domain; with socks5, curl usually resolves it locally. The two can produce different results, but that alone doesn't mean the mixed port is misconfigured.
Rules, DNS, TUN, and ongoing maintenance
Shared devices still use the computer's rules
With mode: rule, requests coming in through the mixed port are matched against rules in order and use the outbound selected by the computer's current policy group. Enabling LAN sharing doesn't create a separate set of rules for phones or force every site through a remote node. To verify the exit route, check the match result for the specific request—not just whether the desktop client says “Connected.”
A proxy listener is not a DNS listener
After setting an HTTP proxy on your phone, you don't need to change its DNS address to the computer's IP. mixed-port is not a DNS listening port; whether the built-in DNS is enabled and which address it listens on are controlled by settings such as dns.enable and dns.listen. Offering DNS to LAN devices is a separate deployment decision, with its own UDP/TCP ports and firewall rules to consider.
For HTTPS requests that pass a domain through HTTP CONNECT, the proxy usually handles the subsequent DNS lookup. However, apps may query DNS themselves, make direct connections, or use another network stack. So a manual HTTP proxy doesn't prove that all DNS traffic reaches the core.
TUN isn't required for sharing a proxy port
TUN takes over traffic entering a virtual network adapter and is commonly used for transparent proxying on the local computer. A phone connecting to your computer's 7890 port doesn't require TUN. Even if TUN is enabled on the computer, it won't automatically take over traffic from every device on the same Wi-Fi network; those devices still need routing that sends traffic to the appropriate gateway.
Keep the address stable and document how to undo the setup
- Set a DHCP reservation for the computer in your router to reduce the chance that the phone's proxy address stops working after a restart.
- After subscription updates, confirm that persistent overrides are still active, especially
allow-lan, the listening address, and the port. - For ongoing use, check whether your client supports the
authenticationsetting. Devices such as TVs may not support authentication, so confirm compatibility first. - When you stop sharing, set the devices' Wi-Fi proxy to Off or None, then set the computer's
allow-lantofalseand reload the configuration. - Remove firewall inbound rules you no longer need so other processes using the same port can't remain accessible from the LAN.
Sharing is working when a remote device can reach the specified port, its request appears in the core's connection list, the expected rule matches, and the app you need on the device supports that proxy type. Checking these four things separately makes troubleshooting easier than changing DNS, TUN, the gateway, and proxy nodes all at once.