В настройках Clash Verge перечислено сразу несколько портов: mixed, HTTP, SOCKS, redir, external controller. Большинство пользователей не трогает ни один из них — но как только вы упираетесь в конфликт портов или настраиваете консольную утилиту, понимать, что есть что, становится полезно.
Пять портов
Смешанный порт
Это тот порт, которым вы будете пользоваться в 99% случаев.
Его особенность — определение протокола на лету: пришёл HTTP-запрос — он работает как HTTP-прокси, началось рукопожатие SOCKS5 — как SOCKS5. То есть какой бы протокол ни требовала программа, вы указываете ей один и тот же номер порта.
HTTP-порт и SOCKS-порт
Наследие прошлого. До появления смешанного порта их приходилось настраивать по отдельности. Сегодня они нужны в основном старому софту, который умеет только один конкретный протокол.
Если они вам не нужны — выключите их (поставьте 0 или оставьте пустыми): одним открытым портом меньше.
Redir-порт (и TProxy-порт)
Для прозрачного проксирования на Linux и macOS, в паре с правилами iptables/nftables, перенаправляющими трафик. Настольному пользователю он ни к чему; он важен при сборке маршрутизатора.
External controller
По умолчанию 9090. Это RESTful API ядра Mihomo — именно через него интерфейс Clash Verge разговаривает с ядром.
Сторонние панели (metacubexd, yacd) подключаются к тому же порту.
Какой порт указывать каждому инструменту
Предположим, что смешанный порт — 7897:
| Инструмент | Как настроить |
|---|---|
| Системный прокси Windows | 127.0.0.1 : 7897 |
| Chrome / Edge | Берут системный прокси, настраивать нечего |
| Firefox | Настройки → Параметры сети → Ручная настройка, 7897 и для HTTP, и для SOCKS |
| Git | git config --global http.proxy http://127.0.0.1:7897 |
| npm | npm config set proxy http://127.0.0.1:7897 |
| pip | pip install --proxy http://127.0.0.1:7897 package |
| curl | curl -x http://127.0.0.1:7897 https://example.com |
| SSH | ProxyCommand в ~/.ssh/config (ниже) |
| Docker | Настроить прокси демона либо просто включить TUN |
SSH через прокси
# ~/.ssh/config
Host github.com
HostName github.com
User git
# Windows (нужен ncat или 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Переменные окружения покрывают почти всё
Большинство консольных инструментов их уважает:
# 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"Что делать при конфликте портов
Если при запуске вы видите «порт уже используется» или address already in use, значит, кто-то занял его раньше.
Выяснить, кто именно
Windows:
netstat -ano | findstr :7897
# PID берём из последнего столбца
tasklist | findstr <PID>macOS / Linux:
lsof -i :7897
# или
ss -tlnp | grep 7897Два выхода
Если меняете порт, берите свободный номер в диапазоне 1024–65535. Частые альтернативы: 7898, 7899, 10808, 10809.
Частое заблуждение: смена порта не ускоряет соединение
Иногда думают, что другой порт позволяет обойти ограничение скорости. Не позволяет. Порт — это всего лишь номер входа на вашей собственной машине, к скорости сети он отношения не имеет.
Скорость определяют качество линии узла, его полоса пропускания и сетевой путь между вами и им.
Как «доступ из локальной сети» связан с портами
Включение доступа из LAN меняет адрес прослушивания с 127.0.0.1 на 0.0.0.0:
Проверка:
netstat -an | findstr 78970.0.0.0:7897 — локальная сеть достучится; 127.0.0.1:7897 — только эта машина.
Две диагностические однострочные команды
Работает ли вообще порт прокси?
curl -x http://127.0.0.1:7897 -I https://www.google.comВернулся HTTP-статус — прокси в порядке. Connection refused — порт закрыт или указан неверно.
Поднят ли управляющий API?
curl http://127.0.0.1:9090/versionJSON с номером версии означает, что ядро работает.
Эти две команды особенно хороши для разделения «проблема в клиенте или в узле»: если API отвечает, а запросы через прокси падают — дело в узле или правилах; если API молчит — ядро вообще не стартовало.
Коротко
- Пользуйтесь только смешанным портом; отдельные HTTP и SOCKS можно выключить
- Консольные инструменты читают переменные окружения, и не забывайте
no_proxy - Не выставляйте управляющий порт наружу, а если пришлось — задайте secret
- Сначала разберитесь с конфликтом, потом меняйте порт — смена порта это крайняя мера
Смотрите также: раздача прокси по локальной сети и чтение журналов и страницы подключений.
