Clash Mixed-Port & Allow-LAN Setup: Full Configuration for Sharing a Proxy Across Devices

Why One Computer Can Get an Entire Household Online

Most people's first impression of Clash is that it "reroutes a browser's traffic," but in reality Clash's proxy core has no fixed tie to the system firewall — it's fundamentally a network service listening on a port on the local machine, and any device that can reach that port, whether or not it's the same computer, can hand its traffic off for processing. That means as long as another device on the LAN knows this computer's internal IP address and the port Clash is listening on, and points its own network requests at that address, it can borrow the subscription nodes and routing rules already configured on that computer to get online, without having to repeat the configuration on devices that are awkward to install a client on, like TV boxes or game consoles.

This pattern is common in home networks: a computer or NAS that's always powered on runs Clash, while phones, tablets, smart TVs, and consoles all connect to it over the LAN, sparing you from installing a client and maintaining a subscription on every single device. Pulling this off boils down to two fields in the configuration file: mixed-port, which decides the listening port, and allow-lan, which decides whether connections from outside the local machine are accepted. Get these two fields right and one computer becomes the exit gateway for the whole household; get them wrong and, at best, other devices simply can't connect — at worst, you've exposed an unauthenticated proxy port to the entire LAN or beyond.

What the mixed-port Field Actually Controls

In earlier versions of Clash, HTTP and SOCKS5 proxies listened on separate ports, and the config file had two independent fields, port (HTTP) and socks-port (SOCKS5). That split was fine when a client only needed to forward browser traffic, but once more device types got involved — some clients only support HTTP proxies, others only recognize SOCKS5 — maintaining two separate ports became tedious. mixed-port is the later, merged solution: the same port accepts both HTTP and SOCKS5 connections, and the Clash core automatically detects which protocol a client is speaking and handles it accordingly.

In the default configuration of most mainstream clients today, the mixed port is commonly set to 7890, which is why that number keeps showing up in tutorials. The field itself is simple to write:

mixed-port: 7890

Tell other devices about this port and all they need to do is enter "this computer's internal IP + 7890" as the proxy address in their Wi-Fi or network settings, and their traffic gets forwarded through. Note that mixed-port only decides "which port accepts client connections" — it says nothing about whether devices elsewhere on the LAN are allowed to reach that port. That permission is governed entirely by another field, which is the allow-lan field discussed next.

allow-lan: Deciding Whether the Port Is Open to the Outside

By default, for security reasons, Clash's allow-lan field is set to false. Under this setting, even though mixed-port is listening on port 7890, that port only accepts connection requests from the local machine itself (127.0.0.1); connection attempts from other devices on the LAN are rejected outright, showing up as a connection timeout or refused connection. This is a protective mechanism: without it, any computer running Clash while connected to a public Wi-Fi network could end up exposing its proxy port to strangers' devices on the same Wi-Fi.

To let other devices on the LAN connect, this restriction needs to be explicitly lifted:

allow-lan: true
bind-address: "*"

bind-address determines which network interface the listener binds to. Setting it to * means it listens on all of the machine's network interfaces (both wired and wireless), so no matter which network segment other devices connect through on the router, they can still reach the Clash service on this computer. If this computer has both an Ethernet cable plugged in and a Wi-Fi connection active, and the two sit on different subnets, binding to * avoids missing connection requests coming in on either interface.

Building a Multi-Device Shared Exit From Scratch

Using a home network as an example, the full process breaks down into roughly four steps.

1. Find the Internal IP of the Host Device

   On Windows, open Command Prompt and run ipconfig; on macOS or Linux, run ifconfig or ip addr, and look for an address like 192.168.x.x or 10.x.x.x. This address should stay reasonably fixed — it's worth going into the router's admin panel and binding a static IP to this device's MAC address (often called "static DHCP" or "IP-MAC binding"), otherwise this computer could get a different IP after a router restart, and the proxy settings on every other device would need updating to match.

2. Configure mixed-port and allow-lan

   Add the three lines mentioned above to the Clash client's config file: mixed-port: 7890, allow-lan: true, bind-address: "*". Most graphical clients also offer a matching toggle, so there's no need to hand-edit the file — just find "LAN Connection" or "Allow LAN" in the settings panel and switch it on; the effect is identical.

3. Open the Local Firewall

   Windows' system firewall and macOS' application firewall block incoming requests to unknown ports by default, so even if Clash is already listening on port 7890, devices on the LAN still can't connect unless the firewall lets them through. On Windows, you need to grant private network access to the Clash program under "Allow an app through Windows Firewall"; on macOS, a system permission prompt usually appears the first time it starts listening — just choose to allow it.

4. Enter the Proxy Address on Other Devices

   On the Wi-Fi details screen of a phone or tablet, choose manual proxy configuration and enter this computer's internal IP along with port 7890. Smart TVs and game consoles usually have a similar "HTTP Proxy" option in their network settings, filled in the same way. After setup, open a web page to test — if it loads normally, the link is working.

Mixed-Port Authentication: Don't Leave a Back Door Open to the Whole Subnet

Once allow-lan is turned on, without any further restrictions every device on the same network segment — including a neighbor freeloading on your Wi-Fi, or a coworker's computer on an office network — could in theory forward traffic through this computer's Clash instance, riding your node bandwidth for free, and in extreme cases could be used for network behavior you have no control over. Adding username/password authentication to the mixed port is a low-cost line of defense:

authentication:
  - "homeuser:a-strong-password"

Once this line is in effect, devices need to supply this username and password in addition to the proxy address to authenticate. On most systems, the proxy settings screen pops up a username/password prompt after the proxy address is entered, so this works fine; clients that don't support an authentication prompt (some TV boxes' network settings menus) may not be able to use an authenticated proxy at all, in which case you're stuck weighing convenience against security and relying on network segmentation or looser authentication instead.

A more thorough isolation approach is to place the computer running Clash on its own VLAN, or on a trusted segment outside the router's "guest network," so only devices your household already trusts can reach that segment — meaning it stays hidden from outside strangers even without authentication turned on. Users who are comfortable customizing their router's network topology will find this more solid than relying on a username and password alone.

Common Connection Failures When Sharing Over a LAN

In practice, the most common issues aren't config file typos but overlooked details in the network environment. Here they are, listed roughly by how likely they are to be the culprit:

• The two devices aren't on the same network segment: If the router has AP isolation turned on (common on guest Wi-Fi), or the phone is on cellular data rather than the same Wi-Fi network, internal IPs simply can't reach each other, no matter how the configuration is tweaked. Confirm both devices are on the same LAN first.
• The firewall is blocking inbound connections: Even if allow-lan is enabled at the client software level, the system firewall's default rules may still block the connection first, and you'll need a separate inbound allow rule for the Clash process or port 7890.
• bind-address is bound to the wrong network interface: If the config specifies a particular IP instead of *, and the network interface tied to that IP currently has no active connection (say the computer also has a virtual machine network adapter installed), the listener ends up bound to a "dead" interface, so outside devices can never reach it.
• The client's UI toggle conflicts with the config file: Some clients maintain a separate "LAN Connection" toggle in the graphical interface that runs on independent logic from the fields in the subscription config file. The config file may be correct while the UI toggle isn't synced on, which likewise causes connection failures — it's worth double-checking against the actual toggle state in the client UI.
• The port is already taken by another program: If some other proxy software or database service on this computer is already using port 7890, Clash may fail to bind on startup or fall back to a different port. Check the client logs to confirm the port it's actually listening on matches what's entered on the other devices.

How Mixed-Port Sharing Relates to Other Routing Methods

It's worth noting that connections shared through mixed-port travel via the system proxy path: rule group logic and DNS handling all happen inside the core on the host device (the computer running Clash), and the connecting phone or TV box doesn't need to understand any Clash concepts at all — it just hands its traffic to the proxy port as-is and gets the result back as-is. That's a different approach from installing a Clash client directly on the device itself and turning on TUN mode: TUN mode takes over all network-layer traffic on the local machine, including UDP and programs that don't support proxy protocols; LAN sharing, by contrast, is still fundamentally an application-layer HTTP/SOCKS5 proxy handoff, so certain apps or games that force traffic through the low-level system network stack and don't recognize proxy settings may still bypass the shared proxy entirely, even when the device is connected to it.

For that reason, LAN sharing works best for browsers, video clients, and other software that respects system proxy settings. If a particular app on a TV box or console can't connect or seems to bypass the proxy, it's usually because that app doesn't read the system proxy configuration — that's not a Clash misconfiguration. In those cases, fully solving the problem generally requires the device to support global transparent proxying, or a router-level bypass gateway setup, which is exactly why many households eventually settle on running the core directly on the router.