Port settings explained — mixed, SOCKS, HTTP and the control API

Clash Verge settings list a pile of ports: mixed, HTTP, SOCKS, redir, external controller. Most people never touch any of them — but the moment you hit a port conflict or need to configure a command-line tool, it helps to know what they are.

The five ports

Mixed port

This is the one you will use 99% of the time.

What makes it special is protocol detection: send it an HTTP request and it acts as an HTTP proxy; open a SOCKS5 handshake and it acts as SOCKS5. So whatever a given tool wants, you give it the same port number.

HTTP port and SOCKS port

Historical. Before the mixed port existed they had to be configured separately. They remain mainly for old software that insists on one specific protocol.

If you do not need them, turn them off (set to 0 or leave blank) — one fewer open port.

Redir port (and TProxy port)

For transparent proxying on Linux and macOS, paired with iptables/nftables rules that redirect traffic. Desktop users have no use for it; it matters when building a router.

External controller

9090 by default. This is Mihomo's RESTful API, and it is how the Clash Verge interface itself talks to the core.

Third-party panels (metacubexd, yacd) connect to this port as well.

Which port each tool wants

Assuming your mixed port is 7897:

SSH through the proxy

# ~/.ssh/config
Host github.com
  HostName github.com
  User git
  # Windows (needs ncat or connect.exe)
  ProxyCommand ncat --proxy 127.0.0.1:7897 --proxy-type http %h %p
  # macOS / Linux
  # ProxyCommand nc -X connect -x 127.0.0.1:7897 %h %p

Environment variables cover most of it

Most command-line tools honour these:

# macOS / Linux
export http_proxy=http://127.0.0.1:7897
export https_proxy=http://127.0.0.1:7897
export all_proxy=socks5://127.0.0.1:7897
export no_proxy="localhost,127.0.0.1,::1,*.local,192.168.0.0/16"

# Windows PowerShell
$env:HTTP_PROXY  = "http://127.0.0.1:7897"
$env:HTTPS_PROXY = "http://127.0.0.1:7897"
$env:NO_PROXY    = "localhost,127.0.0.1,::1,*.local"

Dealing with a port conflict

If startup reports "port already in use" or address already in use, something else got there first.

Find out what

Windows:

netstat -ano | findstr :7897
# take the PID from the last column
tasklist | findstr <PID>

macOS / Linux:

lsof -i :7897
# or
ss -tlnp | grep 7897

Two ways out

If you change the port, pick something between 1024 and 65535 that is free. Common alternatives: 7898, 7899, 10808, 10809.

A frequent misconception: changing the port does not make it faster

People sometimes think a different port avoids throttling. It does not. A port is just an entry number on your own machine; it has no relationship to your network speed.

What actually determines speed is the node's line quality, its bandwidth, and the network path between you and it.

How "allow LAN" relates to ports

Enabling LAN access changes the listening address from 127.0.0.1 to 0.0.0.0:

To check:

netstat -an | findstr 7897

0.0.0.0:7897 means the LAN can reach it; 127.0.0.1:7897 means local only.

Two diagnostic one-liners

Is the proxy port actually working?

curl -x http://127.0.0.1:7897 -I https://www.google.com

An HTTP status back means the proxy is fine. Connection refused means the port is closed or wrong.

Is the control API up?

curl http://127.0.0.1:9090/version

JSON with a version number means the core is running.

These two are particularly useful for separating "is this the client or the node": if the API answers but proxied requests fail, the problem is the node or the rules; if the API does not answer at all, the core never started.

In short

• Use the mixed port only; the separate HTTP and SOCKS ports can be turned off
• Command-line tools take environment variables, and remember no_proxy
• Do not expose the control port, or set a secret if you must
• Investigate conflicts before changing ports — changing is the last resort

Related: sharing the proxy over your LAN and reading logs and connections.