Выход сервера в интернет через внешний прокси: sing-box-клиент на VPS

Приложение на VPS тянет образы с Docker Hub, ставит пакеты из npm, дергает API LLM-провайдера - и упирается в то, что из вашего дата-центра эти ресурсы недоступны или тормозят. Решение - поднять на сервере прокси-клиент, который перенаправит его исходящий трафик через выбранный маршрут.

Важно с самого начала: VPS тут - клиент, а не сервер. Он не раздает VPN людям, а сам ходит наружу через апстрим-прокси по вашей подписке. Это управляемый исходящий канал для одной коробки, а не сервис для третьих лиц.

Happ, v2rayN, Nekoray - это приложения с окном и треем для телефона и десктопа. На headless-сервере им нечего показывать, они там просто не запускаются. Нужен тот же движок, но без интерфейса. Мы берем sing-box - один бинарь, современные протоколы (VLESS, Reality, Trojan, Shadowsocks), работает как systemd-сервис и умеет как локальный SOCKS/HTTP-прокси, так и прозрачный режим на всю машину.

bash <(curl -fsSL https://sing-box.app/install.sh)

Или скачайте бинарь с релизов проекта и положите в /usr/local/bin/sing-box. Проверка: sing-box version.

Возьмите один узел из своей подписки (ссылка вида vless://...) и перенесите его параметры в /etc/sing-box/config.json. Локальный вход mixed слушает только 127.0.0.1 - наружу его не видно.

{
  "inbounds": [
    { "type": "mixed", "listen": "127.0.0.1", "listen_port": 2080 }
  ],
  "outbounds": [
    {
      "type": "vless",
      "tag": "proxy",
      "server": "ВАШ_ПРОКСИ_ХОСТ",
      "server_port": 443,
      "uuid": "ВАШ_UUID",
      "flow": "xtls-rprx-vision",
      "tls": {
        "enabled": true,
        "server_name": "ВАШ_SNI",
        "utls": { "enabled": true, "fingerprint": "chrome" },
        "reality": { "enabled": true, "public_key": "ВАШ_PBK", "short_id": "ВАШ_SID" }
      }
    }
  ]
}

# /etc/systemd/system/sing-box.service
[Unit]
Description=sing-box egress client
After=network-online.target

[Service]
ExecStart=/usr/local/bin/sing-box run -c /etc/sing-box/config.json
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl daemon-reload && systemctl enable --now sing-box

Локальный прокси поднят на 127.0.0.1:2080. Дальше три сценария - от точечного к сквозному.

Точечно (одна команда или сессия):

export ALL_PROXY=socks5h://127.0.0.1:2080
export HTTPS_PROXY=http://127.0.0.1:2080

Docker (чтобы образы тянулись через прокси) - частая боль в РФ:

# /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:2080"
Environment="HTTPS_PROXY=http://127.0.0.1:2080"
Environment="NO_PROXY=localhost,127.0.0.1"

systemctl daemon-reload && systemctl restart docker

Вся машина (прозрачный режим): добавьте в sing-box inbound типа tun с авто-маршрутизацией - тогда весь исходящий трафик коробки идет через прокси без правки каждого приложения. Мощно, но требует аккуратности с маршрутами (см. оговорки ниже).

curl --proxy socks5h://127.0.0.1:2080 https://api.ipify.org ; echo

В ответ должен прийти IP апстрим-прокси, а не вашего VPS. Если так - трафик пошел через выбранный маршрут.

Мы не пишем с потолка. Подняли два сервера в РФ-сети: один как апстрим-узел (VLESS + Reality на sing-box), второй как клиентский VPS с той же настройкой, что выше. Версия - sing-box 1.14.1.

# без прокси - сервер ходит от своего адреса
$ curl -s https://api.ipify.org
45.15.159.111

# через локальный sing-box (SOCKS) - выход уже с адреса апстрима
$ curl -s --proxy socks5h://127.0.0.1:2080 https://api.ipify.org
45.15.159.114

# то же по HTTP-прокси (этот путь использует Docker)
$ curl -s --proxy http://127.0.0.1:2080 https://api.ipify.org
45.15.159.114

Трафик клиентской коробки реально ушел через выбранный узел: адрес сменился с ...111 на ...114. Задержка через прокси - около 0,34 с, ответ 200. И SOCKS, и HTTP-вход работают из одного локального порта 2080, так что и приложения через ALL_PROXY, и Docker через HTTP_PROXY идут одним каналом.