Know the difference between the mixed port, your PC's IP, and the router gateway
Phones and TVs don't necessarily need their own proxy client. A Clash-compatible desktop client can expose a proxy endpoint on your local network. Other devices send requests to your PC, and the core running there routes them directly or through a proxy according to its current configuration. Your PC must stay on, the client core must be running properly, and the devices must be able to communicate directly.
This guide focuses on Clash desktop clients that use the mihomo core. Depending on the client, the setting may be called “Allow LAN,” “Allow connections from LAN,” or “Allow LAN connections.” The GUI may also override the port. Use the settings currently in effect in your client, not just the subscription file.
| Setting | Example | Where to enter it |
|---|---|---|
| PC's local IPv4 address | 192.168.1.20 | Proxy server address on your phone or TV |
| Mixed port | 7890 | Proxy port on your phone or TV |
| Router gateway | 192.168.1.1 | Keep this in your network settings; don't use it as the proxy server |
| Loopback address | 127.0.0.1 | For connections from apps on the same PC only |
Mixed port 7890: One port for HTTP and SOCKS5
mixed-port lets the core accept both HTTP proxy and SOCKS5 requests on the same port, distinguishing them by the protocol data at the start of each connection. You don't need to enable both proxy types in an app. Choose whichever type the app supports and enter the same port.
- HTTP proxy: Suitable for system Wi-Fi proxy settings on phones, browsers, and similar use cases. For HTTPS websites, the client typically establishes a tunnel using HTTP CONNECT; the TLS connection to the destination is still established between the app and the destination server.
- SOCKS5 proxy: Suitable for apps with their own proxy settings and command-line tools. Whether domain names are resolved locally or by the proxy depends on the app's options.
- 7890 is just a common default: If the client shows 7897 as the mixed port, use 7897. Don't confuse the HTTP port, SOCKS port, and mixed port.
The mixed port is not the core's management interface. The external-controller setting is for managing the core and must not be entered as the proxy port on your phone. Don't expose the management interface to your entire local network just to share the proxy.
A mixed port doesn't automatically route all traffic
After you set an HTTP proxy on your phone, only requests from apps that honor that setting go through your PC. Game UDP traffic, some video apps, and apps with their own network stack may still connect directly. SOCKS5 does support UDP ASSOCIATE, but forwarding UDP also requires support from the client app, core, and firewall. Enabling port 7890 does not mean all UDP traffic will be forwarded.
Likewise, enabling TUN mode on your PC doesn't put your phone on TUN automatically. TUN routes traffic from the PC itself through a virtual network interface. Without explicitly using a proxy, your phone continues to access the internet through its own default route.
Set up the PC: Enable LAN access and confirm the active port
- First, make sure the proxy works on the PC. Import a valid subscription or configuration, then select a rule mode and an available policy. Confirm that your PC's browser can reach the target website before setting up sharing. This helps avoid mistaking a node issue for a LAN problem.
- Find the mixed port. In the client's Settings, look under Port or Port Settings for Mixed Port, and note the value currently in use. If the field isn't shown, check the active client configuration and core logs.
- Enable Allow LAN. Find and turn on “Allow LAN” or “Allow connections from LAN.” Some clients require you to apply the configuration or restart the core. After switching it on, check the logs for listener errors.
- Check the bind address. If there's a Bind Address option, don't restrict it to
127.0.0.1. Listening on all addresses allows more devices to connect, so restrict access by source in your firewall.
Using YAML? Check these three fields
This minimal snippet shows the mihomo settings relevant to sharing. It includes only the required fields; it is not a complete subscription and should not replace your existing proxies, proxy groups, or rules:
mixed-port: 7890
allow-lan: true
bind-address: '*'
allow-lan: true allows LAN connections. bind-address: '*' binds to all addresses; the actual IPv4 and IPv6 listening behavior also depends on your operating system. To listen on a specific local IPv4 address, set the bind address to the IP of the relevant network adapter. If that address changes, update the setting too.
Find your PC's IP and allow inbound LAN connections
Windows: Check the network adapter and network profile
Press Win + R, enter cmd, then run ipconfig. Find the active “Wireless LAN adapter Wi-Fi” or “Ethernet adapter” and note its IPv4 address. Don't use the address for a TUN virtual adapter, virtual machine adapter, or disconnected adapter.
In Windows 11, go to Settings → Network & internet and select your current Wi-Fi or Ethernet connection to check its network profile. Set it to Private only if you're sure it's a trusted home network. Don't change a hotel, school, or other shared network to Private to get around restrictions.
The firewall must allow inbound connections to the PC's proxy port; allowing only outbound traffic from the client isn't enough. In Windows Security → Firewall & network protection → Advanced settings → Inbound Rules, create a port rule for TCP, local port 7890, and allow the connection on the Private profile only. Then open the rule properties and, under Scope, limit the remote IP addresses to the local subnet.
If you're comfortable with PowerShell, you can create a rule with the same scope from an elevated terminal. The example below applies only if 7890 is your actual mixed port:
New-NetFirewallRule -DisplayName "Clash LAN TCP 7890" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 7890 -Profile Private -RemoteAddress LocalSubnet
For a basic phone HTTP proxy test, allowing TCP is enough; there's no need to open a broad port range. If you later use SOCKS5 UDP, check UDP rules separately based on the actual listener and app requirements.
macOS and Linux: Check the address, then review app permissions
- macOS: Go to System Settings → Network → your current connection → Details → TCP/IP to find the IP address. Under System Settings → Network → Firewall → Options, check whether incoming connections are allowed for the client or the actual core process. The name may vary depending on how the client is packaged.
- Linux: Run
ip -4 addrto find the physical network interface's address, then usess -lntpto check whether port 7890 is listening. With UFW, firewalld, or another firewall, allow access to the actual port from trusted subnets only. Don't clear your firewall rules.
Consider setting up a DHCP reservation for your PC in the router. That way, it keeps the same IP after a restart, and you won't have to keep updating the proxy server address on your phone or TV.
Phones and TVs: Enter your PC's IP as the proxy server and 7890 as the port
iPhone and iPad
- Go to Settings → Wi-Fi and tap the info button next to your current network.
- Tap Configure Proxy and select Manual.
- For Server, enter your PC's local IP, such as
192.168.1.20. For Port, enter the active mixed port, such as7890. - If proxy authentication isn't enabled, leave Authentication off. Save the settings, then try opening a website in Safari.
This setting applies to the current Wi-Fi network, not cellular data. After testing, if you leave the network your PC is on or shut down the PC, go back to Configure Proxy and select Off. Otherwise, apps that honor the proxy setting may lose internet access.
Android phones
On stock Android, the usual path is Settings → Network & internet → Internet → current Wi-Fi network → Edit → Advanced options → Proxy → Manual. Some manufacturers put Edit at the bottom of the network details page. Enter your PC's IP as the proxy hostname and 7890 as the proxy port. Leave IP settings on DHCP.
Don't add http:// to the hostname or combine the address and port in one field. Android's manual Wi-Fi proxy setting is usually for HTTP, not SOCKS5. For apps that don't use the system proxy, check whether the app has its own proxy settings.
Android TV and other TV systems
On your TV, go to Settings → Network & Internet → your current network and look for Proxy settings. If Manual is available, enter your PC's IP and mixed port. Menus vary by system version: some TVs show advanced settings only when you add a Wi-Fi network, while others don't offer a proxy option at all.
If you can't find the setting, don't change the default gateway and hope for the best. Try the HTTP or SOCKS5 settings built into the TV app instead. If neither the app nor the system supports a proxy, you'll need a separate router- or gateway-level solution; turning on Allow LAN alone won't solve it.
Test in stages: Check connectivity first, then rules and nodes
Don't assume the setup has failed just because one website won't load. First test the proxy on the PC itself, then test the connection from another device to the PC, and finally check Connections and Logs in the Clash client. The addresses below are examples; replace them with your PC's actual local IP when you run the commands.
Test HTTP and SOCKS5 with curl
On the PC, test the HTTP proxy using the loopback address. On Windows, use curl.exe explicitly to avoid parsing issues caused by the same-name command alias in older PowerShell versions:
curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/
Next, test the PC's address from another device on the LAN that has curl installed. Use curl on macOS or Linux, and curl.exe on Windows:
curl -I --connect-timeout 5 --max-time 15 --proxy http://192.168.1.20:7890 https://example.com/
curl -I --connect-timeout 5 --max-time 15 --proxy socks5h://192.168.1.20:7890 https://example.com/
socks5h sends the target domain name to the proxy for resolution, unlike socks5, which resolves it locally. In an HTTP test, a successful CONNECT only confirms that the tunnel was established; check the destination site's response as well. Even a 403 from the destination should be interpreted alongside the logs to determine whether the site denied access or the proxy failed to connect.
| Symptom | Check first | Next step |
|---|---|---|
| Can't connect even through the loopback address | Is the core running? Is the port already in use? | Check the startup logs and the port actually listening |
| Works on the PC, but the phone request times out | Allow LAN, bind address, firewall, device isolation | Make sure the listener isn't limited to the loopback address, then check inbound rules |
| Connection refused | Is the target IP correct? Is anything listening on that port? | Double-check the PC's network adapter address and port |
| The client sees the request, but access fails | Matched rule, selected node, upstream DNS resolution | Check the policy chain under Connections, then review the error logs |
| Works in the browser, but not in one app | Does the app honor the HTTP proxy setting? | Check the app's proxy options and whether it relies on UDP |
Devices on the same Wi-Fi network name aren't necessarily able to reach each other. Guest networks, AP isolation, and different VLANs can all block device-to-device traffic. Conversely, using Ethernet on the PC and Wi-Fi on your phone isn't inherently a problem as long as the network allows them to communicate. A failed ping alone doesn't prove TCP port 7890 is unreachable, since a firewall may block ICMP.
Limit access, use authentication, and restore settings afterward
Allow LAN lets other devices access your PC's proxy endpoint. Even on a home network, restrict the firewall's allowed sources. Don't forward port 7890 to the public internet from your router or disable the entire system firewall to troubleshoot. If your PC has other network interfaces or a public IPv6 address, check the active listener and inbound rules carefully.
mihomo supports HTTP and SOCKS proxy authentication through authentication, but the connecting device must be able to enter and send a username and password. Some Android system Wi-Fi proxy screens don't provide these fields, and TV support varies, so test each device before enabling authentication. Authentication is not a substitute for an encrypted connection; a regular HTTP/SOCKS connection over a LAN is not a VPN tunnel.
- Before sharing: Confirm that the network is trusted, the PC's IP is reserved, the port is correct, and the firewall allows only necessary sources.
- While sharing: Check source addresses and traffic under Connections in the client to confirm requests are coming from the expected devices. Shared devices generally use the same rules and policy groups; they don't automatically get separate subscriptions.
- After sharing: Turn off the manual proxy on your phone and TV first, then turn off Allow LAN. Disable or delete any temporary firewall rules you created.
To remove the Windows rule created above after testing, run this command in an elevated PowerShell session. It deletes only the rule created with this name:
Remove-NetFirewallRule -DisplayName "Clash LAN TCP 7890"
Keep this troubleshooting order in mind: the proxy works on the PC → the LAN port is reachable → the device is using the proxy correctly → rules and nodes are working. Checking these four layers separately is more effective than repeatedly switching Global mode, TUN, and ports.