Clash LAN Proxy Sharing: mixed-port and Allow LAN Settings

Understand how LAN proxy sharing works first

LAN proxy sharing turns a computer running Clash into a proxy server. TVs, phones, tablets, and other computers stay connected to the original router and send only their apps’ HTTP or SOCKS traffic to Clash’s listening port on that computer. Clash applies its rules to choose DIRECT, a proxy node, or another policy group, then returns the result to the device.

This does not turn the computer into a full router, nor does it automatically take over every device on the same Wi-Fi network. Connected devices must support manual proxy settings, or their browsers, download tools, and other apps must be configured individually. Some games, voice services, UDP video, and system updates bypass HTTP proxies, so check device and app support first.

What mixed-port, allow-lan, and the bind address control

mixed-port combines HTTP and SOCKS5 entry points

mixed-port is a mixed proxy port. It can identify both HTTP proxy and SOCKS5 requests on the same TCP port. Set it to 7890, and an HTTP-capable TV can connect to 192.168.1.23:7890; desktop software that supports SOCKS5 can use the same address.

If the configuration contains port: 7890, socks-port: 7891, and mixed-port: 7890 at the same time, startup may fail because multiple listeners conflict. In most cases, one mixed-port is enough. If separate entry points are required, use different ports—for example, 7890 for HTTP and 7891 for SOCKS5.

allow-lan determines whether LAN connections are accepted

allow-lan: true allows other devices to connect to the proxy port. When set to false, local apps may still use Clash through the loopback address, but connections from 192.168.x.x or 10.x.x.x networks are rejected. Many graphical clients label this setting “Allow LAN,” “LAN access,” or “Allow LAN.”

bind-address limits the listening interface

Clash Meta (mihomo) can use bind-address to specify the listening address. * listens on available interfaces and is suitable for home LAN testing; specifying 192.168.1.23 binds Clash only to that address. If DHCP changes the host address, a fixed binding may stop working, so consider reserving a DHCP address for the computer in your router for long-term use.

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

The location of these settings varies by client. A common path is “Settings” → “Preferences” → “Allow LAN,” followed by checking that “Mixed Port” is set to 7890. If the client offers “Configuration Override” or “Global Extended Configuration,” set these fields in the override layer so subscription updates do not replace them. After saving, reload the configuration or restart the core, then check the logs for port-listening errors.

Find the host’s LAN address and check the port

Check the Wi-Fi address on Windows

Open “Settings” → “Network & Internet” → “Wi-Fi” → “Hardware properties” and find the IPv4 address. You can also run this in PowerShell:

ipconfig

Under the active wireless adapter, find an IPv4 address such as 192.168.1.23. Do not choose a virtual adapter, TUN adapter, Docker adapter, or an automatically assigned address beginning with 169.254. Then use PowerShell to check whether port 7890 is listening:

Get-NetTCPConnection -LocalPort 7890 -State Listen

If LocalAddress in the output is 0.0.0.0 or the host’s LAN address, the port is listening on the relevant interface. If only 127.0.0.1 appears, check allow-lan and bind-address again.

Check the address on macOS and Linux

On macOS, open “System Settings” → “Network” → “Wi-Fi” → “Details” → “TCP/IP” and read the IPv4 address. You can also run ipconfig getifaddr en0 in Terminal; if the Wi-Fi interface is not en0, use networksetup -listallhardwareports to confirm its name first.

On a Linux desktop, open “Settings” → “Network” → “Wi-Fi” → the current connection to view the IPv4 address. In a terminal, run:

ip -4 address
ss -lntp | grep 7890

After confirming the address, test port reachability from another device. In Windows PowerShell, run Test-NetConnection 192.168.1.23 -Port 7890. On macOS or Linux, run nc -vz 192.168.1.23 7890. Continue to proxy rules and nodes only after the TCP test succeeds.

Set up the proxy on computers, phones, TVs, and game consoles

Another Windows or macOS computer

In Windows 11, go to “Settings” → “Network & Internet” → “Proxy” → “Manual proxy setup” → “Set up.” Enter 192.168.1.23 as the server and 7890 as the port. After saving, test with a browser before testing the target app. This configures the system HTTP proxy, which not every desktop app will use.

On macOS, go to “System Settings” → “Network” → “Wi-Fi” → “Details” → “Proxies.” Enable “Web Proxy (HTTP)” and “Secure Web Proxy (HTTPS),” enter the Clash host address for both servers, and use port 7890 for each. Disable them when finished to prevent requests from waiting indefinitely if the host goes offline.

Android and iPhone

A common Android path is “Settings” → “Network & internet” → “Internet” → the current Wi-Fi network → Edit → “Advanced options” → “Proxy” → “Manual.” Enter 192.168.1.23 as the proxy hostname and 7890 as the port. Menu names vary slightly by manufacturer, but the setting is usually saved for the current Wi-Fi network.

On iPhone and iPad, go to “Settings” → “Wi-Fi” → the info button beside the current network → “Configure Proxy” → “Manual.” Enter the host’s LAN address as the server and 7890 as the port. The HTTP proxy mainly affects apps that follow the system proxy settings; some apps create their own connections and bypass this entry point.

TVs and streaming devices

Android TV and Google TV usually support manual proxy settings under “Settings” → “Network & internet” → the current Wi-Fi network → “Proxy settings.” Enter 192.168.1.23 as the server hostname and 7890 as the proxy port. If the TV connects but apps still report a region or network error, check the Clash logs for requests from the TV’s address.

The proxy handles only traffic that apps actually send to the proxy port. A TV’s DNS probes, time synchronization, local-network casting, and some UDP traffic may connect directly. To avoid disrupting casting, keep RFC1918 private addresses and LAN domains DIRECT in the Clash rules.

PlayStation, Nintendo Switch, and Xbox

On PlayStation 5, go to “Settings” → “Network” → “Settings” → “Set Up Internet Connection,” select the current network, open “Advanced Settings,” set “Proxy Server” to Use, and enter the host address with port 7890. On Nintendo Switch, go to “System Settings” → “Internet” → “Internet Settings” → the current network → “Change Settings” → “Proxy Settings.”

A console’s proxy settings usually cover only downloads, the store, or some HTTP requests. Online multiplayer relies heavily on UDP, and NAT type detection does not fully pass through an HTTP proxy. When Xbox has no general manual HTTP proxy entry, mixed-port alone cannot capture all traffic; use a side-router or set a device that supports transparent proxying as the gateway.

Configure the firewall to allow only trusted LAN access

Clash listening on 7890 does not mean the operating system firewall allows other devices to connect. The right approach is to allow TCP 7890 only on Home or other trusted network profiles and restrict the source subnet. Do not keep LAN proxy sharing enabled on airport, hotel, campus, or other public Wi-Fi.

Windows Defender Firewall

Go to “Windows Security” → “Firewall & network protection” → “Advanced settings” → “Inbound Rules” → “New Rule.” Choose “Port,” select TCP, and enter 7890 for the specific local port. Allow the connection and select only the “Private” profile. Under “Scope,” restrict remote IP addresses to your home subnet, such as 192.168.1.0/24.

If Windows identifies the current Wi-Fi as a public network, open “Settings” → “Network & Internet” → “Wi-Fi” → the current network and change the network profile to “Private.” Do this only on a trusted home network.

Restrict the source with UFW on Linux

sudo ufw allow from 192.168.1.0/24 to any port 7890 proto tcp
sudo ufw status numbered

If your home network uses 192.168.50.0/24, update the subnet in the command as well. When macOS asks whether to allow incoming connections, verify that the program is the Clash client or mihomo core currently in use, then allow connections from the home network.

Secure authentication, rules, and DNS settings

Add authentication to the proxy on shared networks

mihomo supports setting a username and password for HTTP and SOCKS entry points through authentication. Authentication is recommended on dorm, shared-rental, or guest-heavy Wi-Fi networks; enter the credentials in the client’s proxy settings.

mixed-port: 7890
allow-lan: true
bind-address: "*"
authentication:
  - "lanuser:change-this-password"

Authentication details are sensitive configuration. Do not commit them to a public repository or write them directly into a subscription file that will be shared. Some TVs do not support authenticated proxies; in that case, restrict the device IP with the firewall instead of widening port access.

Keep direct rules for LAN traffic

When sharing a proxy, printers, NAS devices, casting receivers, and router admin pages should remain direct. Rules are matched from top to bottom, so place private networks before general proxy rules and keep MATCH as the final fallback.

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,local,DIRECT
  - MATCH,PROXY

If you use rule sets from a subscription, confirm that they include direct rules for private addresses. Do not rely only on the client’s displayed “Rule mode”; inspect the policy that actually matches. Open Clash’s connections page or live logs and use the source address, destination domain, and policy name to verify how traffic is handled.

DNS behavior depends on the client app

HTTP proxy requests usually include the destination hostname, allowing Clash to resolve the domain on the proxy side, but the connected device may still perform its own DNS queries. With SOCKS5, whether DNS is resolved by the proxy depends on whether the app uses remote or local resolution. If a browser works but an app fails, check whether the app follows the system proxy, whether DNS works, and whether it relies on UDP.

Troubleshoot connection failures in order

1. Confirm that the host is online. The computer running Clash must not be asleep. After switching Wi-Fi networks, verify the LAN address again.
2. Confirm that the core is working. On the host itself, first test the proxy at 127.0.0.1:7890 to rule out subscription, node, and rule problems.
3. Confirm the listening scope. Check allow-lan: true and verify that port 7890 listens on 0.0.0.0, *, or the correct LAN address.
4. Confirm Layer 2 connectivity. Both devices should be on the same network and able to reach each other. AP isolation and guest-network isolation on the router can block device-to-device connections.
5. Check the firewall rules. Temporarily disabling the firewall is appropriate only for brief diagnosis. Once the cause is confirmed, restore it and create an inbound rule limited to the required subnet.
6. Confirm that the app uses the proxy. Filter the Clash logs for the connected device’s IP. If there are no entries at all, the issue is usually the device’s proxy settings or network isolation, not the node.

On another device with curl installed, run the command below. The expected result is a successful connection to port 7890 on the Clash host followed by HTTP response headers:

curl -I -x http://192.168.1.23:7890 https://www.gstatic.com/generate_204

If you see Connection refused, the port is usually not listening or allow-lan is disabled. If the request times out continuously, check the firewall, guest network, and AP isolation first. If the proxy connects but the destination request times out, check the Clash logs, node latency, and matched rule.