Mixed Port and allow-lan Setup Guide: Share Your Proxy with LAN Devices

Understand mixed-port, port, and socks-port first

mihomo can provide HTTP, SOCKS5, and mixed proxy endpoints at the same time. They all send connections through the same proxy rules and policy groups, but clients connect through different entry points. For LAN sharing, the simplest approach is usually to open one mixed-port: a phone can use it as an HTTP proxy port, while apps that support SOCKS5 can connect to the same port. The server identifies the protocol during the connection handshake.

mixed-port does not convert HTTP data into SOCKS5, nor does it add another forwarding layer. It simply detects the client handshake type on a single listening port. When a computer runs Clash and a phone uses the computer’s IP address and port, this reduces port conflicts and the number of firewall rules needed.

What enabling allow-lan does

When only the loopback address is listened on by default, the proxy endpoint can be accessed only from the machine running mihomo. allow-lan: true allows LAN devices to connect to the inbound proxy, but it does not change phone settings automatically or turn the computer into a default gateway. Clients must still specify the proxy server address, or traffic must be handled by router or transparent-proxy rules.

Here is a basic configuration for initial testing. Assume the computer’s IPv4 address on the home network is 192.168.50.23, the phone and computer are connected to the same router, and the port is 7890.

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

authentication:
  - "livingroom:change-this-password"

bind-address: "*" means listening on available addresses. The actual reachable range is still controlled by the OS firewall, router guest-network isolation, and client isolation on the access point. If the computer uses a stable LAN address, you can narrow the listener to a specific interface, for example:

mixed-port: 7890
allow-lan: true
bind-address: 192.168.50.23
mode: rule

authentication:
  - "phone:use-a-long-password"

Binding to a specific address makes the boundary clearer, but mihomo may fail to start after DHCP assigns a different address because that address no longer belongs to the machine. For long-term sharing, reserve 192.168.50.23 for the computer’s network adapter in the router’s DHCP settings, or continue listening on all addresses and restrict the source subnet through the OS firewall.

How GUI switches relate to YAML

Clash GUI clients use slightly different labels. A common path is “Settings” → “Preferences” → “Allow LAN connections,” with “Mixed Port” or “Port” shown nearby. After enabling the switch, return to the configuration or runtime log and verify that the final value is allow-lan: true, while noting the actual port. Some clients preserve global parameters when reloading a subscription; others follow override settings. Do not rely only on the fields in the subscription file.

You must also distinguish the proxy port from the control port. external-controller: 127.0.0.1:9090 is used for dashboard or API control, not as the phone’s HTTP proxy. Entering 9090 in the phone’s proxy field will usually result in a connection failure or an HTTP status error.

Find the computer’s correct LAN address

The phone must use the computer’s LAN address, not 127.0.0.1 and not the public address assigned by the ISP. On the phone, 127.0.0.1 refers only to the phone itself. Common private address ranges include 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12.

Find the address on Windows 11

1. Open “Settings” → “Network & internet.”
2. Select the active “Wi-Fi” or “Ethernet” connection.
3. Open “Hardware properties” and find “IPv4 address.”
4. Record an address such as 192.168.50.23; do not copy the default gateway 192.168.50.1.

You can also run ipconfig in a terminal and check the “IPv4 Address” under the adapter currently connected to the network. If wired, wireless, virtual-machine, and VPN adapters are all present, choose the physical adapter on the same subnet as the phone. If the phone is 192.168.50.88, the computer will usually be 192.168.50.x as well.

Find the address on macOS

1. Open “System Settings” → “Network.”
2. Select the Wi-Fi or Ethernet connection marked “Connected.”
3. Click “Details” → “TCP/IP.”
4. Read the IPv4 address, for example 192.168.50.23.

How to configure proxy settings on phones and TV boxes

iPhone and iPad

1. Go to “Settings” → “Wi-Fi.”
2. Tap the information button next to the current network.
3. Scroll to “Configure Proxy” and select “Manual.”
4. Enter the computer’s address as the server, for example 192.168.50.23.
5. Enter 7890 as the port.
6. If authentication is configured, enable authentication and enter the corresponding username and password.

iOS manual Wi-Fi proxy settings primarily configure an HTTP proxy; they are not the same as a system-wide TUN. Most apps that follow the system proxy can connect, but apps that create their own network stack, ignore the system proxy, or send only UDP traffic may bypass the computer. This is a common reason why browser access works while a particular game or streaming app still connects directly.

Android and TV boxes

1. Open “Settings” → “Network & internet” → “Internet” or the current Wi-Fi network.
2. Choose to edit the network and expand “Advanced options.”
3. Set the proxy to “Manual.”
4. Enter 192.168.50.23 as the proxy hostname and 7890 as the proxy port.
5. Add local domain names to the bypass list if needed, save the settings, and reopen the app for testing.

Android vendor interfaces may place the option under “Wi-Fi” → “Connected network” → “Modify network.” If a TV box provides only “Proxy server” and “Proxy port,” enter the computer’s address and mixed port in the same way. Some TV apps do not follow the system HTTP proxy, so changing only the box’s Wi-Fi proxy will not cover all traffic.

If the goal is to route games, UDP traffic, smart TV apps, and programs that ignore system proxy settings through the same path, deploy mihomo on the main router or a secondary router, or configure TPROXY/TUN on a Linux host with forwarding support. Simply changing the phone’s default gateway to the computer’s address will not create a working route unless the computer also has IP forwarding, NAT, and transparent-proxy rules enabled.

The computer’s rules still determine the exit after sharing

When a LAN device connects to mixed-port, its requests enter mihomo on the computer. The nodes, policy groups, DNS settings, and rules from the subscription are determined by the configuration currently loaded on the computer. The phone does not need to import the subscription again, and it cannot bypass the computer’s rule mode to select a node directly.

For example, when the configuration uses mode: rule, traffic is matched against rules from top to bottom. LAN addresses should usually go direct, preventing access to router admin pages, NAS devices, or casting devices from being sent through a proxy node:

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,Proxy

If Fake-IP is enabled, domain requests from the phone through the HTTP proxy are usually resolved by the proxy side. However, DNS requests made by the phone outside the proxy still use the DNS server configured for the current Wi-Fi network. When a webpage opens but an app reports domain-resolution errors, first determine whether the app is actually using the system proxy instead of immediately changing subscription nodes.

Run a repeatable test first

1. First confirm that the computer itself can access the target website through 127.0.0.1:7890.
2. Turn off cellular data on the phone so test traffic cannot bypass the proxy over the mobile network.
3. Enter 192.168.50.23:7890 on the phone and open a webpage that has not been cached previously.
4. Check the Clash connection list and confirm that the phone’s IP, such as 192.168.50.88, appears as the source address.
5. Check which rule and policy group matched the connection, along with the final node.

On the same Wi-Fi network, round-trip latency between the phone and computer should usually be around 1–10 ms. If it stays above 50 ms, check the wireless signal, 2.4 GHz congestion, and whether the computer is sleeping. This measures only the LAN link, not the cross-network quality of the proxy node.

Authentication, firewalls, and listening boundaries

Opening a LAN listener means any device on the same network that can reach the port may initiate a connection. Even on a small home network, use a username and strong password, and restrict sources with the OS firewall. Networks with many unknown users, such as offices, dormitories, and hotels, are not suitable for exposing a proxy to the entire subnet.

mihomo inbound authentication

mixed-port: 7890
allow-lan: true
bind-address: "*"

authentication:
  - "phone:V7k9m2Qp4s8L"
  - "tvbox:R6w3n8Hx5c2A"

Assign separate accounts to different devices so you can disable one device by deleting only its entry. Passwords stored in YAML require restricted local read permissions for the configuration file. If a GUI client generates the runtime configuration automatically, maintain these fields through its “Override” or “Global extension configuration” feature to prevent them from disappearing after a subscription update.

Allow only the home subnet through the OS firewall

When creating an inbound rule in Windows Firewall, choose TCP and local port 7890, enable only the “Private” profile, and restrict the remote IP range to 192.168.50.0/24. Do not leave the entire firewall disabled after troubleshooting. On macOS, when using a third-party firewall or pf, allow traffic by subnet and port as well.

Regular HTTP and SOCKS TCP connections through mixed-port require at least a TCP port. If SOCKS5 is used for UDP, also verify client support, mihomo’s listener, and UDP rules in the OS firewall. TV boxes typically use HTTP proxying rather than SOCKS UDP, so opening TCP 7890 is enough for basic web and app testing.

A layered troubleshooting sequence for connection failures

Layer 1: Confirm that mihomo is listening

First check the client runtime log and port settings. On Windows, run netstat -ano | findstr :7890; on macOS or Linux, run lsof -nP -iTCP:7890 -sTCP:LISTEN. If you see only 127.0.0.1:7890, the service is still limited to the local machine. Seeing 0.0.0.0:7890, *:7890, or the computer’s LAN address means remote connections are possible.

Layer 2: Check the local network and firewall

• Are the phone and computer connected to the same regular Wi-Fi rather than a guest network?
• Has the computer’s address changed after a DHCP update?
• Is Windows identifying the current network as “Public,” preventing the private-network allow rule from taking effect?
• Has the router enabled AP isolation, client isolation, or blocking between VLANs?
• Is another process using the port, causing Clash to use a different port?

Layer 3: Distinguish “cannot connect” from “wrong rule”

If the phone immediately reports that the proxy server refused the connection, the problem is usually the listening address, port, or firewall. If the request appears in the Clash connection list but the website times out, continue by checking the node, DNS, and matched rules. A 407 Proxy Authentication Required response means the proxy is reachable, but the username or password is missing or incorrect.

If only certain apps fail, use a browser as a baseline. Browser success indicates that the LAN link, HTTP proxy, and authentication are basically working. The failing app may ignore the system proxy, use QUIC/UDP, or have its own network settings. Repeatedly switching allow-lan usually will not change the result.

Configuration trade-offs for long-term use

To temporarily connect one phone through the computer, mixed-port: 7890, allow-lan: true, authentication, and a LAN firewall rule are enough. The computer must stay awake and the Clash client must keep running; when it sleeps, changes Wi-Fi networks, or exits the core, downstream devices immediately lose their proxy connection.

If multiple TVs, game consoles, and IoT devices need stable routing, computer-based sharing is limited by shutdowns, address changes, and app compatibility with proxy settings. In that case, run mihomo on the router or a secondary router and use TUN, REDIR, or TPROXY to handle forwarding, then route traffic by source IP, destination domain, and rule sets. The mixed port can remain available for devices that require manual proxy settings, but it should no longer be the only entry point for the entire home network.

The final check has four parts: the proxy port must match the value entered on the device; allow-lan and the listening address must permit remote connections; the OS firewall should allow only trusted subnets; and private addresses should remain direct in rule mode. Verifying these four items separately makes problems easier to locate than changing the port, DNS, TUN, and subscription all at once.