Mixed Ports and LAN Sharing: Use One Clash Proxy Across Devices on the Same Network

What mixed-port and allow-lan control

The basic setup for sharing a LAN proxy is simple: run Clash, Clash Meta, or mihomo on a computer and have it listen on a proxy port, then enter the computer’s private IPv4 address as the proxy server on a phone, tablet, or TV. Requests from other devices reach the computer first, where the core processes them according to the active rules and policy groups.

mixed-port is a mixed proxy port that accepts both HTTP proxy and SOCKS5 connections on the same port. For example, after setting it to 7890, a TV with manual HTTP proxy support can connect to that port, while apps that support SOCKS5 can use it too. Compared with separate port and socks-port settings, it is better suited to simple home-network sharing.

allow-lan determines whether the core accepts LAN connections from outside the local machine. When set to false, the computer’s browser may still use the proxy through 127.0.0.1:7890, while a phone connecting to 192.168.1.20:7890 will fail. Sharing usually requires checking the bind address, firewall, and Wi-Fi client-isolation settings together; changing one switch alone is not enough.

Configure the listening port for Clash, Clash Meta, or mihomo

Edit the YAML configuration directly

When using a client that supports configuration overrides, add the following settings to the active profile or global override file. Menu names vary slightly between GUI clients; common paths include “Settings” → “Preferences” → “Allow LAN connections” or “Profiles” → “Overrides” → “Global override.” After editing, reload the configuration or restart the core; otherwise, the old listening state will remain.

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

If the client already manages mixed-port automatically, change the port through its GUI settings first. This avoids different values being written to the main configuration, override file, and client preferences. When troubleshooting, use the listening port shown in the client log rather than relying only on the field in the subscription file.

Add authentication to the shared port

mihomo supports authentication for HTTP and SOCKS proxies through authentication. Set separate credentials if guest devices are present on the home network or the computer is connected to a network that is not fully trusted. Generate a dedicated username and password; do not reuse credentials from a subscription provider, email account, or system account.

mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  - "Replace this example with a strong password of your own"

Not every TV operating system provides username and password fields on its manual proxy screen. If a device does not support proxy authentication, restrict inbound firewall access to specific IPs—for example, allow only the phone at 192.168.1.35 to access TCP 7890—or assign trusted devices reserved DHCP addresses on the router.

Find the computer’s LAN address and verify the listener

Find the IPv4 address on Windows

In Windows 11, open “Settings” → “Network & internet” → “Wi-Fi” → “Properties,” then find “IPv4 address.” You can also run ipconfig in PowerShell and select the wireless LAN adapter currently in use. Do not accidentally use an address created by WSL, Hyper-V, Tailscale, or a virtual machine.

ipconfig

Wireless LAN adapter WLAN:
   IPv4 Address . . . . . . . . . . . : 192.168.1.20
   Subnet Mask  . . . . . . . . . . . : 255.255.255.0
   Default Gateway  . . . . . . . . . : 192.168.1.1

In this example, other devices should use 192.168.1.20 as the proxy server and 7890 as the port. 127.0.0.1 always refers to the device itself; entering it on a phone makes the phone try to connect to its own port 7890.

Find the address on macOS and Linux

• macOS: Open “System Settings” → “Network” → “Wi-Fi” → “Details” → “TCP/IP” and read the IPv4 address.
• Linux desktop: Open “Settings” → “Network” → “Current connection” → “Details,” or run ip -4 address.
• The address is usually within the private ranges 192.168.0.0/16, 10.0.0.0/8, or 172.16.0.0/12, but use the address actually assigned by the current network.

After confirming the address, check whether the port is listening. In Windows PowerShell, use Get-NetTCPConnection -LocalPort 7890; on Linux, use ss -lntp | grep 7890; on macOS, use lsof -nP -iTCP:7890 -sTCP:LISTEN. If the output shows only 127.0.0.1:7890, the listener is still local-only. An address such as 0.0.0.0:7890 or the computer’s LAN address is required to accept LAN connections.

Allow Clash through the Windows, macOS, or Linux firewall

Windows Defender Firewall

First, go to “Settings” → “Network & internet” → “Wi-Fi” → “Properties” and set the network profile to “Private.” Then open “Windows Security” → “Firewall & network protection” → “Advanced settings” → “Inbound Rules” → “New Rule.” Select “Port,” choose TCP, enter 7890 as the specific local port, choose “Allow the connection,” and select only the “Private” profile.

You can also create a rule in an elevated PowerShell that allows access only from the local subnet:

New-NetFirewallRule `
  -DisplayName "Clash mixed-port LAN" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 7890 `
  -RemoteAddress LocalSubnet `
  -Profile Private

HTTP proxy and SOCKS5 connections primarily use TCP. Allow UDP 7890 separately only when the client, app, and core explicitly use SOCKS5 UDP forwarding. Do not automatically blame UDP when a port test fails: the HTTP proxy configured on a phone’s Wi-Fi screen relies on TCP first.

macOS and Linux

The macOS firewall manages inbound connections by application. Go to “System Settings” → “Network” → “Firewall” → “Options” and make sure the active Clash client or core process is allowed to accept incoming connections. If a client upgrade changes the core file path, check the authorization entry again.

On a Linux host using UFW, restrict the source to the current subnet. Assuming the LAN is 192.168.1.0/24:

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

How to configure the proxy on phones, tablets, and TVs

iPhone and iPad

1. Open “Settings” → “Wi-Fi” and tap the info button next to the current Wi-Fi network.
2. Scroll to the bottom, open “Configure Proxy,” and select “Manual.”
3. Enter the computer’s LAN address as the server, for example 192.168.1.20.
4. Enter 7890 as the port. If authentication is configured, turn on “Authentication” and enter the username and password.
5. Save the settings, reopen the browser, and check for the new connection in the Clash client’s connection list.

This setting applies only to the current Wi-Fi network. It will not continue using this computer’s proxy after switching to another wireless network or mobile data. Some apps ignore the system HTTP proxy, and some UDP-based protocols will not be fully handled by a manual Wi-Fi HTTP proxy. These are limitations of the endpoint’s proxy method.

Android and TV devices

On standard Android, the usual path is “Settings” → “Network & internet” → “Internet” → “Current Wi-Fi” → “Edit” → “Advanced options” → “Proxy” → “Manual.” Some manufacturers place it under “WLAN” → “Connected network” → “Proxy settings.” Enter the computer’s address as the hostname and 7890 as the proxy port; you can leave local domains or internal addresses in the bypass list.

On Android TV, Google TV, and some TV boxes, the setting is usually under “Settings” → “Network & internet” → “Current Wi-Fi” → “Proxy settings.” Some TVs support HTTP proxies only and do not offer SOCKS5 or username/password authentication. These devices can use mixed-port’s HTTP capability, but whether an app follows the system proxy depends on the app.

Why TUN mode does not automatically share the proxy with other devices

TUN mode creates a virtual network interface on the computer running Clash and uses system routes to capture the computer’s own traffic. It solves the problem of local apps that do not read system proxy settings; it does not automatically turn the computer into the LAN’s default gateway. If the phone still uses the home router as its default gateway, enabling TUN on the computer will not route the phone’s traffic through it.

A manual LAN proxy and TUN can be used at the same time: the computer’s own traffic enters TUN, while the phone connects to 192.168.1.20:7890. Both traffic flows are ultimately handled by the same mihomo core, but they enter through different paths. In the connection page, LAN devices usually appear with the phone or TV’s private IP, which helps confirm that the shared request reached the core.

If the goal is to transparently route a game console, TV app, or IoT device that cannot configure a proxy through the computer, configure the computer as a gateway, enable IPv4 forwarding, and set up NAT, policy routing, and DNS forwarding. Windows Mobile Hotspot, Linux nftables, and a router-side gateway are separate network solutions. Adding allow-lan: true alone does not change other devices’ default routes.

A layered checklist for failed connections

Layer 1: Confirm that the devices are on the same reachable network

• Check the computer and phone addresses—for example, computer 192.168.1.20, phone 192.168.1.35—and make sure both use 255.255.255.0 as the subnet mask.
• Disable “AP isolation,” “client isolation,” or “guest network device isolation” on the router. Guest Wi-Fi commonly blocks access to devices on the main network.
• When the computer is connected by Ethernet, Wi-Fi, and virtual adapters at the same time, use the physical interface address on the same subnet as the phone.
• After DHCP assigns a new address, the old proxy address saved on the phone will stop working. Reserve a DHCP address for the computer on the router.

Layer 2: Confirm that the core is listening on the correct interface

• Check the runtime state of allow-lan, not just the original subscription file.
• Confirm that the actual mixed-port is 7890 and has not been changed automatically by the client to another port such as 7897 or 7893.
• Reload the configuration and check the logs to make sure the port is not already occupied by another program.
• If the listening address is still 127.0.0.1, check whether the client has a separate “Bind address” or “LAN connections” switch that overrides the YAML setting.

Layer 3: Confirm the firewall and proxy protocol

• Temporarily disable proxy authentication for a comparison test. If the connection succeeds, restore authentication and check whether the endpoint supports entering credentials.
• The Windows firewall rule must match the current network profile. If the rule allows only “Private” while the current connection is identified as “Public,” inbound traffic will still be blocked.
• When the endpoint is set to use an HTTP proxy, it can still connect to mixed-port; do not accidentally enter the control port 9090.
• Check the Clash connection list: if no source IP appears at all, the problem is usually on the LAN or firewall side. If the connection is visible but requests fail, check rules, DNS, nodes, and policy groups.

Layer 4: Determine whether everything fails or only certain apps

If a browser opens websites but a video app, game, or casting feature fails, the proxy port and LAN path are probably working. Check whether the app uses QUIC, UDP, LAN discovery, or certificate pinning instead of repeatedly changing allow-lan. A manual HTTP proxy does not proxy mDNS broadcasts or replace the device discovery required for local casting.

If every website fails but requests appear in the Clash connection list, inspect the matched rule and policy group. A request hitting REJECT, an unavailable node, an expired subscription, or a failed rule-provider load can all look like “the proxy is connected but the page will not open.” Temporarily set the log level to info, record the target hostname, matched rule, and egress policy, then troubleshoot based on those results.

Configuration tips for reliable sharing

1. Reserve a DHCP address for the computer running Clash, such as 192.168.1.20, to prevent the endpoint proxy address from changing after a router restart.
2. Open only the mixed-port actually in use, and restrict firewall sources to LocalSubnet or explicitly approved device IPs.
3. Keep the computer awake and connected. Shared devices immediately lose the proxy connection when the computer sleeps, switches Wi-Fi, closes the client, or restarts the core.
4. After changing the configuration, test with one phone first, then add TVs and tablets one at a time. This avoids troubleshooting differences across multiple endpoints simultaneously.
5. Use the connection list to verify the source address and matched rule. Under normal conditions, a request from the phone should show its LAN IP, target hostname, and egress policy within a few seconds.

A maintainable home-sharing setup usually needs only four clearly defined values: the computer’s LAN address, the mixed-port number, the allowed device scope, and the active firewall rule. Make these four consistent first, then handle higher-level questions such as whether an app follows the system proxy or whether UDP needs a separate solution. This keeps troubleshooting shorter.