Clash Mixed Port and LAN Proxy Sharing: Listen Addresses, Firewalls, and Device Access

The short version: proxy sharing requires four links to work together

Run Clash on one computer, then let a phone, tablet, or another computer on the same local network use it as a proxy. The process involves more than simply enabling “Allow LAN connections.” Four conditions must be met: the Clash core must listen on a network address reachable by other devices; LAN access must be enabled; the host firewall must allow inbound connections on the port; and each client must use the host’s correct LAN address and port. If any link fails, clients may time out, refuse the connection, or work only in some apps.

A common, easy-to-manage setup enables one mixed-port so HTTP and SOCKS5 proxies share the same port. A phone’s manual Wi-Fi proxy setting usually uses the HTTP proxy option, while desktop apps and network tools that support SOCKS5 can connect to the same port and complete a SOCKS5 handshake. A mixed port is simply a unified entry point; it does not confuse ordinary HTTP requests with SOCKS5 traffic. The core identifies each connection by its protocol.

A basic configuration can look like this. Different GUI clients may create these fields through interface switches, or overwrite them when a subscription refreshes. After making changes, reopen the configuration that is actually running and verify the result instead of checking only the original subscription file.

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

mixed-port sets the proxy entry point, allow-lan permits LAN connections from other hosts, and bind-address determines which local addresses accept connections. An asterisk means listening on all available interfaces, which is simple but broad. A tighter deployment can bind Clash to the LAN address of the network adapter it should use, such as 192.168.1.20, provided that address remains stable.

What does a mixed port solve?

Traditional Clash configurations can declare port and socks-port separately: the first provides an HTTP proxy entry point and the second provides a SOCKS5 entry point. This makes it easy to control each protocol independently, but devices become harder to manage because users must remember two ports and can easily enter the wrong one in system proxy settings. mixed-port combines both entry points on a single TCP port, making it suitable for home LANs, test devices, and temporary sharing.

A mixed port does not automatically take over all traffic from LAN devices. Each client must explicitly enable an HTTP or SOCKS5 proxy, or an app on that device must connect to the proxy itself. A phone’s “Manual proxy” Wi-Fi setting usually covers only apps that follow the system HTTP proxy; some apps use their own network stack, connect directly to destinations, or ignore the system proxy. When a browser works but a particular app does not, first check whether the app supports system proxy settings instead of immediately changing nodes or rules.

SOCKS5 UDP forwarding also depends on the client app, core version, and protocol implementation. A TCP request succeeding through a mixed port does not mean that all UDP traffic will be handled the same way. Games, real-time communications, and apps that rely on QUIC require separate testing. If the goal is to capture most of a device’s traffic, use a compatible TUN mode on that device rather than treating a remote mixed port as a complete virtual network adapter.

How the mixed port relates to rule mode

The port only accepts connections. Whether traffic is sent directly, routed through a proxy node, or rejected is still determined by Clash’s operating mode, rule sets, and proxy groups. In rule mode, domain names or destination addresses from LAN clients go through the same rule-matching process; in global mode, traffic generally goes to the global proxy group; in direct mode, a request may access its destination directly even after the device successfully connects to the mixed port.

When testing a shared proxy, record the current mode and proxy-group selection as well. If a phone can open websites but its apparent egress address does not change, check whether the rules matched DIRECT and whether local DNS resolved the destination to an unexpected address. A reachable port only proves that the client path is working; it does not mean a proxy rule was matched.

Check allow-lan and the listen address together

allow-lan: true permits other hosts to access the proxy listener, but the network adapter that can actually receive connections is determined by the listen address. If the process listens only on 127.0.0.1, the port is available only through the local loopback interface. Other devices cannot connect even if they can ping the computer. If it listens on 0.0.0.0, or a wildcard setting covers all interfaces, the port appears on multiple IPv4 interfaces. Binding a specific LAN IP exposes the service only through that interface.

A safer approach is to define the sharing scope first. With one home network adapter and a controlled environment, listening on all interfaces can be acceptable if the firewall limits the source subnet. When a computer is connected to a corporate VPN, virtual machine adapters, container networks, and a hotspot at the same time, bind Clash to the actual LAN address so the proxy entry does not appear on unnecessary interfaces. After binding to a specific address, a DHCP change may prevent Clash from listening on the old address. Configure a DHCP reservation on the router, or update the configuration whenever the address changes.

How to find the address other devices should use

• On Windows, check the current Wi-Fi or Ethernet IPv4 address in Network settings, or run ipconfig and identify the active adapter with a default gateway.
• On macOS, view the details of the current connection in system network settings, or use ifconfig to check the address of an active interface.
• On Linux, run ip address and use the default route shown by ip route to identify the actual outbound interface.

Do not enter 127.0.0.1 on your phone. A loopback address always points to the current device itself, so when the phone connects to 127.0.0.1:7890, it looks for a service on the phone rather than on the computer running Clash. Also avoid choosing a virtual machine, Docker, VPN, or temporary hotspot adapter address unless the client device is actually on that network.

Confirm that the core is really listening

A GUI showing “Allow LAN” does not replace a system-level listener check. On Windows, use PowerShell to query the port; on macOS and Linux, inspect listening sockets. If the output shows only a loopback address, remote devices still cannot connect. If it shows a LAN or wildcard address, continue with the firewall checks.

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

If another program is using the port, Clash may fail to start, switch to a client-defined fallback port, or report a listen error in its logs. Use the current core log and the system socket output as the source of truth during troubleshooting. After changing the port, update every client as well; existing Wi-Fi proxy settings will not discover the new port automatically.

Open only the networks and ports you need in the firewall

When Clash is already listening on a LAN interface but other devices time out, the host firewall is usually the next checkpoint. The firewall should allow inbound TCP connections to the mixed port and, where possible, restrict them to the current home or office subnet. For example, if the computer is 192.168.1.20 with subnet mask 255.255.255.0, a common source range is 192.168.1.0/24. Determine the actual subnet from the router and system network information rather than copying the example.

On Windows, first confirm whether the current connection is identified as a private or public network. An inbound rule can target the Clash client executable or a specific TCP port; port rules are easier to verify but require maintenance when the port changes. Limit the rule scope to the local subnet or explicit addresses instead of all remote addresses. On macOS, the system may prompt when an app first accepts inbound connections; allow only the client process currently in use. On Linux, configure inbound policy according to the nftables, firewalld, ufw, or distribution firewall actually in use.

After allowing the port through the firewall, test the TCP connection from another device. If TCP connects but proxy requests fail, the issue has usually moved from the network layer to the proxy protocol, authentication, rules, or upstream node. A complete timeout commonly indicates firewall drops, client isolation, or an incorrect address; an immediate “connection refused” response more often means the destination is reachable but no process is listening on that port.

Router client isolation can block connections too

Guest Wi-Fi, wireless client isolation, and some enterprise wireless networks prevent devices on the same access point from communicating with each other. A phone may still reach the internet and appear to be on a similar subnet as the computer, yet be unable to connect to the computer’s port. Check that both devices are on the same primary network, that neither is on a guest network, and that AP isolation is disabled on the router. Dual-router setups can also create two subnets with only one-way routing from the upstream network to the downstream network, preventing direct device access.

How phones and computers connect to a mixed port

Before connecting, note the LAN IPv4 address of the computer running Clash, the mixed port, and the current network name. Suppose the computer is 192.168.1.20 and the mixed port is 7890. The other device should connect to the same router, use 192.168.1.20 as its proxy server, and use 7890 as the port. Do not copy the example address; it must belong to the host actually running Clash.

Manual Wi-Fi proxy settings on Android and iOS

1. Open the detailed settings for the current Wi-Fi network and choose manual proxy configuration rather than an automatic configuration script.
2. Enter the Clash host’s LAN address as the server or hostname, and enter the mixed port as the port.
3. After saving, first visit a regular HTTPS website in a browser, then check Clash’s connection list and logs for requests from the device.
4. Turn off the manual proxy when testing is complete so the device does not keep trying to reach an unreachable private-network address after leaving the current network.

A mobile system’s manual Wi-Fi proxy primarily handles HTTP and HTTPS connections. HTTPS requests are usually forwarded through an HTTP CONNECT tunnel, so Clash can process the connection using the destination host and rules without decrypting web content. Some apps do not read system proxy settings, while others use UDP or custom transports, so one app’s result cannot represent the whole system.

Connecting from Windows, macOS, and Linux

Another desktop computer can use the system network settings to configure an HTTP proxy, or set a proxy only in a browser, terminal tool, or specific app. Apps that support SOCKS5 can select SOCKS5 and use the same host address and mixed port. Whether a command-line tool reads system proxy settings depends on its implementation; when necessary, set proxy environment variables for the current terminal session.

HTTP_PROXY=http://192.168.1.20:7890
HTTPS_PROXY=http://192.168.1.20:7890
ALL_PROXY=socks5://192.168.1.20:7890

These variables are format examples only. Tools differ in how they handle uppercase and lowercase variable names and socks5 versus socks5h; socks5h generally means domain resolution is also delegated to the proxy. Check the relevant tool’s documentation before use, and avoid setting conflicting system-level and application-level proxies at the same time.

How DNS is handled

When a LAN device connects through a mixed port, the DNS path depends on the proxy protocol and the app’s behavior. An HTTP proxy request usually sends the destination hostname to the proxy server; a SOCKS5 client may send the domain name or resolve it locally to an IP before requesting the connection. Apps that bypass the proxy on a phone continue to use the system DNS. The DNS module in a Clash configuration does not automatically become a network-wide DNS server just because the mixed port is open, and Clash’s DNS listen port should not be confused with its mixed proxy port.

If rules depend on domain names but the client resolves them to IP addresses first, the information available for core matching may change. mihomo can improve some scenarios through sniffing, DNS, and rule features, but whether to enable them should depend on the configuration source and privacy boundary. For basic sharing, get HTTP proxying working reliably first, then address domain-identification issues in specific apps.

Troubleshoot connection failures by network layer

The key to efficient troubleshooting is to verify each layer in order instead of repeatedly switching nodes. First confirm that the computer itself can access the proxy through the mixed port, then verify the listen address, LAN connectivity, and firewall, and finally inspect Clash rules and the upstream proxy. The sequence below distinguishes most issues.

1. Check the core status. Confirm that the current configuration loaded successfully, the mixed port is not conflicting, and the logs contain no listen failure or YAML parsing error.
2. Check the local proxy. On the computer running Clash, connect to 127.0.0.1:7890. If the local test also fails, fix the core, configuration, or node first instead of continuing with LAN settings.
3. Check the actual listen address. Confirm that the port listens on the LAN IP or a wildcard address rather than only on the loopback interface.
4. Check both devices’ networks. Verify the IP address, subnet mask, default gateway, and Wi-Fi name, and rule out guest networks, client isolation, and dual-router issues.
5. Check the host firewall. Allow the current network range to access the specified TCP port, and confirm that the rule applies to the correct network profile.
6. Check the client format. Enter only an IP address or hostname in the server field and put the numeric port in its separate field. Do not put http://, a path, and the port all into the hostname field.
7. Watch the connection list. Seeing requests from the device means the LAN path is basically working; use the destination domain, matched rule, proxy group, and error logs to locate the next issue.

What to do when a subscription update overwrites the configuration

Subscriptions usually provide proxy nodes, proxy groups, and rules, while LAN listening is a local runtime setting. Clients merge subscription configurations differently: some preserve the port and LAN switch set in the interface, some use fields from the subscription directly, and others generate the final configuration through overrides, patches, or global settings. Prefer the client’s override feature to manage mixed-port, allow-lan, and bind-address, rather than editing temporary files manually after every update.

Before making changes, copy the current working configuration and note the actual configuration path shown by the client. After refreshing the subscription, check the listening status and connection logs again to quickly determine whether the nodes changed or local listen parameters were reset. If you use the Clash Meta (mihomo) core, also verify the configuration support range for the client and core versions; do not assume that identical labels in another client’s interface behave the same way.

TUN mode does not replace LAN listen configuration

TUN mode mainly captures traffic from the computer running Clash by coordinating a virtual network interface, routes, and DNS. Enabling TUN on the host does not make other LAN devices send traffic to that computer automatically, nor does it configure gateway forwarding. Other devices still need a proxy configuration to use the mixed port. Making the computer a LAN gateway involves a different network design covering IP forwarding, routing, NAT, and DNS, with substantially different complexity and security boundaries.

In a home environment, a mixed port with manual proxy settings is usually enough for temporarily providing proxy access to a phone browser or test device. For long-term access from multiple devices, reserve the host address, restrict firewall sources, record port changes, and periodically check which devices still use the entry point. This keeps the problem within four clear layers: listening, networking, proxy protocol, and rules.