Clash Mixed Port and LAN Proxy: Share Proxy Access with Phones and Other Devices

How shared proxy access works

Once Clash or Mihomo starts on a computer, it creates one or more local proxy listening ports. Normally, these ports are available only to applications on the same machine. After LAN access is enabled, phones, tablets, TV boxes, and other computers on the same network can send requests to the listening port. The host running Clash then applies its rules and forwards traffic through the selected proxy node.

The full path is straightforward: the client device sends a request, the home router or LAN switch passes it to the Clash host, and Clash decides whether to use a proxy node or connect directly according to the active mode and rules. The response then returns along the same path. The remote device does not need to read the Clash configuration or connect directly to nodes from the subscription. It only needs the host's LAN IP address, listening port, and proxy protocol.

This setup does not turn the computer into a full router. When an HTTP proxy is entered manually, only applications that honor the system proxy settings will use Clash. Apps that ignore system proxy settings, establish connections directly, or use their own VPN interface may continue to connect directly. To route all traffic from a device, use a side-router, transparent proxy, or a client with TUN support on the device itself rather than relying only on the Wi-Fi proxy field.

mixed-port accepts both HTTP and SOCKS5

mixed-port is a combined proxy port. It accepts both HTTP proxy and SOCKS5 connections on one port, reducing the need to maintain separate port and socks-port values. Port 7890 is common, but it is only a conventional default, not a requirement. Any unused port can be used as long as no other program has claimed it.

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

This configuration means that HTTP and SOCKS5 requests are accepted on port 7890, LAN devices are allowed to connect, and traffic is processed according to the rules mode. YAML is sensitive to indentation and syntax: keep a space after each colon, and preferably put the asterisk in quotes so it is not parsed as a YAML alias.

If the configuration contains port, socks-port, and mixed-port at the same time, first confirm which values the client interface actually writes to the core. Different ports can coexist, but the port entered on the phone must match an actively listening port. In graphical clients, “mixed port” and “allow LAN connections” usually map to these fields. Applying the configuration or restarting the core may also be required after changes.

Which should you use: HTTP or SOCKS5?

The “Proxy” setting in a phone's Wi-Fi panel usually means an HTTP proxy, so enter the Clash host's LAN IP and the mixed-port value. When a browser opens an HTTPS site, it creates a tunnel with HTTP CONNECT, which works through the same port. Apps that support SOCKS5 can use the same address and port as a SOCKS5 server.

HTTP proxying is easier to deploy through system network settings, but not every application follows those settings. SOCKS5 supports more application-layer connection patterns and can let the proxy resolve domain names, but system settings pages often provide no SOCKS5 field, so the app must offer its own proxy configuration. For a quick check of the shared path, HTTP proxying is the clearest starting point.

Shared requests still pass through the rule system

After a remote device connects to the mixed port, its requests do not automatically use the global proxy. Clash still processes traffic according to the active rules, global, or direct mode. In rules mode, the domain, destination IP, visible network characteristics, and rule order in the configuration all affect the final policy. If a test site matches DIRECT, the exit address may remain unchanged even when proxy sharing is configured correctly.

During troubleshooting, inspect the connection list or rule-match results in the logs instead of judging only by whether a page opens. After testing, restore the mode used for everyday traffic so global mode does not hide configuration problems in the rules.

Allow LAN access and bind addresses

allow-lan: true controls whether other devices can access the proxy port. If only the mixed port is configured but LAN access is not enabled, the core may accept connections only from the local machine, causing the phone to time out or receive an immediate refusal. In graphical clients, this option may be labeled “Allow LAN,” “LAN connections,” or “Allow LAN.”

bind-address determines which local addresses accept connections. "*" lets the core listen on available addresses according to its implementation, which is convenient on home networks where the host address may change. For IPv4-only sharing, 0.0.0.0 listens on all IPv4 interfaces. To narrow the listening scope, enter the host's current LAN IPv4 address, such as 192.168.1.20. If DHCP assigns a new address, update the configuration accordingly.

Client devices must not use 127.0.0.1, localhost, or 0.0.0.0. On a phone, 127.0.0.1 points back to the phone itself, while 0.0.0.0 is a wildcard address for listening, not a connectable destination. Enter the actual LAN address of the computer running Clash in the phone's proxy server field.

Find the host's LAN IP address

• On Windows, run ipconfig and find the IPv4 address of the active Wi-Fi or Ethernet adapter.
• On macOS, check the IP address of the connected interface in Network settings, or run ipconfig getifaddr en0. If the interface is not en0, replace it with the correct interface.
• On Linux, run ip addr and find the LAN address under the interface currently connected to the network.

Common home-network addresses begin with 192.168., 10., or a range from 172.16. to 172.31.. A host may have wired, wireless, virtual-machine, and VPN interfaces at the same time. Choose the physical interface on the same LAN as the phone. Comparing the gateway and subnet on both devices is the simplest way to verify this.

Firewall rules and Wi-Fi client isolation

A core listening on a LAN address does not guarantee that traffic can reach the port. Windows Defender Firewall, the macOS firewall, and Linux nftables, iptables, or firewalld may block inbound connections. Create a rule for the actual TCP port in use, and restrict the source to the home or office LAN subnet whenever possible.

When a relevant client starts for the first time on Windows, the system may ask which network types should allow communication. Usually, “Private networks” is sufficient. If the current Wi-Fi is classified as a public network, connections may still be blocked even when the app has permission for private networks. Check the network profile type first, then verify that the app or port rule covers the process running the core.

On a Linux host, confirm the listening state before investigating the firewall. For example, use the following command to inspect port 7890:

ss -lnt | grep 7890

If the result shows only 127.0.0.1:7890, the problem is still in Clash's listening configuration. If it shows 0.0.0.0:7890, the host's LAN address, or a corresponding IPv6 listening address, continue with the firewall and router-isolation checks. Do not disable the entire firewall just for testing. A narrowly scoped temporary inbound rule makes the cause easier to identify and can be removed after testing.

Devices on the same Wi-Fi may still be unable to communicate

Some routers enable AP isolation, client isolation, or wireless client isolation on guest networks. In that case, a phone and computer may appear to be connected to the same router but still be unable to establish a direct LAN connection. Businesses, hotels, and public hotspots often use similar policies. Try connecting to the proxy port from another computer, or check whether the phone can reach another LAN service on the host.

Dual-band Wi-Fi does not usually block communication by itself, but some routers place guest SSIDs, IoT SSIDs, and the main network in separate subnets. If the devices are not on the same subnet, check whether the router permits traffic between those networks. Enabling allow-lan alone cannot bypass the router's access controls.

Setup for phones, tablets, and other computers

iPhone and iPad

1. Connect the device to the same Wi-Fi network as the Clash host, with client-to-client communication allowed.
2. Open the details for the current Wi-Fi network, select HTTP Proxy, and change the configuration method to Manual.
3. Enter the Clash host's LAN IP as the server and the mixed-port value as the port.
4. If the core has proxy authentication enabled, enter the corresponding username and password. Otherwise, leave authentication disabled.
5. Save the settings, open a browser to a site expected to match a proxy rule, and watch Clash's connection list at the same time.

Manual HTTP proxy settings in iOS and iPadOS are saved per Wi-Fi network. They do not carry over automatically when switching to cellular data, another Wi-Fi network, or a different network configuration. Some apps may ignore the system HTTP proxy, so a successful browser test does not mean every app will use the same path.

Android devices

1. Open the network modification or advanced settings page for the current Wi-Fi network.
2. Set the proxy mode to Manual and enter the computer's LAN IP as the proxy hostname.
3. Enter the mixed port as the proxy port, for example 7890.
4. Save the settings, reconnect to Wi-Fi, and verify requests in both the browser and Clash logs.

Android manufacturers use different names for these settings, and some systems require you to long-press the Wi-Fi network name before proxy options appear. System-level Wi-Fi HTTP proxy settings usually do not cover every app and are not equivalent to a VPN or TUN. For an app that requires SOCKS5, enter the same host address and mixed port in the app and select the SOCKS5 protocol.

Another computer

Windows, macOS, and Linux can use an HTTP proxy configured in system network settings, or you can configure one only for a browser, terminal, or development tool. To verify the HTTP proxy with curl, run:

curl -x http://192.168.1.20:7890 https://example.com

To verify SOCKS5 and have the proxy resolve domain names, use:

curl --socks5-hostname 192.168.1.20:7890 https://example.com

Replace the example IP with the actual host address. If the first command succeeds but an application fails, check whether the app reads system proxy settings, whether it has a proxy bypass list, and whether it creates another network tunnel on its own.

Access control, authentication, and exposure boundaries

Listening on all interfaces allows other devices on the same reachable network to attempt connections to the proxy port. On a trusted home network, restrict the source subnet with firewall rules. On a large office, dormitory, or public network, further restrict the bind address or use the authentication features supported by the core.

Implementations such as Mihomo support configuring a username and password for HTTP and SOCKS entry points. A common configuration looks like this:

authentication:
  - "lanuser:replace-with-a-strong-password"

Authentication fields vary by core and client version, so confirm which core the current client actually uses before making changes. The username and password must be provided to devices that need proxy access, making them useful as one layer of LAN access control, but they should still be combined with firewall source restrictions. Do not map the proxy port to a router's public address or expose it to the internet through a cloud security group.

If you share the proxy only occasionally at home, disable “Allow LAN” or remove the temporary firewall rule when finished. For long-term sharing, reserve the host's IP, document the port's purpose, and avoid using the same port as a development server, database, or other local service.

Troubleshooting order for failed sharing

Troubleshoot layer by layer, starting at the listening host and moving toward the client. Change one variable at a time and record what happens at each step. Repeatedly switching nodes or reinstalling the client usually does not identify a LAN connectivity problem.

Step 1: Confirm that the core is running and the port is available

On the host itself, test the proxy with 127.0.0.1 and the mixed port. If the connection fails locally too, check whether the core started, the configuration loaded successfully, the port is already in use, and the logs contain YAML parsing or listening errors. If there is a port conflict, choose a new unused port and update the remote device settings as well.

Step 2: Confirm the listening scope

Check that allow-lan is set to true, then inspect the address where the port is actually listening. Listening only on a loopback address prevents requests from arriving through the network adapter. After changing an option in a graphical client, confirm that it was written to the active configuration rather than an unused configuration file.

Step 3: Confirm the IP, port, and network

Verify that the phone uses the host's current LAN IP, not the gateway address, a virtual adapter address, or an old address from a previous connection. Confirm that both devices are on a network that permits peer access, and disable mobile-data assistance that could change the network path before testing again. If the router has guest isolation enabled, switch to the main network or adjust the isolation policy.

Step 4: Check the firewall

When the port is listening but remote connections time out, an inbound firewall is a common cause. Create a rule that allows the target TCP port only from the local subnet, then test connectivity from another computer. On Windows, run the following in remote PowerShell:

Test-NetConnection 192.168.1.20 -Port 7890

A true TcpTestSucceeded value only confirms that the TCP port is reachable; it does not prove that proxy rules and nodes are working. A false value means you should continue checking the address, listening state, firewall, and network isolation.

Step 5: Inspect connections and rule matches

When the port is reachable but pages do not open, check Clash's runtime logs or connection list. If there are no new connections at all, the client app may not be using the system proxy or the settings may not have been saved. If connections appear but fail, continue by checking DNS resolution, node status, policy-group selection, and rule-match results.

In rules mode, the test target may match a direct connection. In global mode, the active global policy may point to an unavailable node. In direct mode, all requests bypass proxy nodes. Mode and policy-group issues belong to the forwarding layer and should be evaluated separately from whether the LAN port is reachable.

Step 6: Distinguish HTTP, DNS, and UDP limitations

The HTTP proxy in a phone's Wi-Fi settings mainly handles TCP requests that use the HTTP proxy mechanism. App-generated DNS, QUIC, game UDP, and other traffic from apps that ignore system proxy settings may not enter this port. If a browser works but a particular app does not, do not immediately conclude that sharing has failed. First confirm which proxy methods the app supports.

If a SOCKS5 client offers a “resolve domain names remotely” option, enable it to let the proxy resolve the destination, reducing differences caused by local DNS behavior. HTTP CONNECT requests may also pass the domain to the proxy, depending on the client implementation. Apps using UDP require support from the client, entry protocol, node, and firewall together; a normal web-page test cannot substitute for that verification.

Post-setup verification checklist

1. The host can access the network normally through mixed-port.
2. allow-lan is enabled, and the port is not listening only on 127.0.0.1.
3. The phone uses the host's current LAN IP and the correct port.
4. The firewall allows inbound connections only from the required local subnet.
5. The router has not enabled client isolation between the two devices.
6. Clash's connection list shows new requests from the LAN device.
7. The test target matches the expected rule and policy group rather than accidentally using a direct connection.
8. When finished, disable LAN access or keep a restricted rule according to your needs.

The key to sharing through a mixed port is not a single switch. The entry point, network path, and forwarding layer must all work: Clash must listen correctly, the LAN must be able to reach it, and the rules and nodes must complete the connection. Checking these layers in order turns “my phone cannot connect to the proxy” into a set of specific configuration questions instead of repeated guesswork across ports, nodes, and system settings.