Эталонные схемы размещения

Когда протоколов на ноде становится больше одного, появляется вопрос: как разложить их по портам. От ответа зависит, насколько нода похожа на обычный сервер при сканировании, доходит ли до вас реальный IP клиента и переживёт ли всё это обновление сертификата.

Ниже три схемы, которые реально используют, с честным сравнением. Материал сверен с открытой библиотекой эталонных конфигов integrated-examples и адаптирован под РФ: там ориентир на Китай, у нас другой DPI и другие доноры.

📖 Незнакомые слова есть в Словаре терминов.

Три схемы: чем платите за удобство

Вывод коротко. Если нода одна и протоколов два, берите порт на протокол, не усложняйте. Если хотите, чтобы при сканировании нода выглядела как обычный веб-сервер, берите SNI-разделение. Fallback-цепочка нужна там, где фронт ставить нельзя, а маскировка под сайт обязательна.

Схема 1. Порт на протокол и главная ловушка

Самое простое: Reality на 443, XHTTP на 2096, Hysteria на 2053. Работает, ставится за минуту.

Ловушка в том, что лишние порты видно. Обычный сайт не слушает 2096 и 2443. Массовые сканеры это собирают, и нода получает «профиль» непохожий на веб-сервер.

Вторая ловушка бывает неожиданной: порт может быть закрыт файрволом, и протокол просто не работает, хотя в панели всё зелёное. Проверять надо снаружи, а не по ss -lntp на самой ноде:

терминал

# с ДРУГОГО сервера, а не с самой ноды
for p in 443 2096 2443; do
  timeout 5 bash -c "echo > /dev/tcp/ВАШ_IP/$p" 2>/dev/null \
    && echo "$p открыт" || echo "$p ЗАКРЫТ"
done

Схема 2. SNI-разделение: всё на 443

Фронт (Caddy или Nginx) слушает 443, смотрит SNI (имя домена в начале TLS-рукопожатия) и раздаёт соединения по назначению. Сам сайт, Reality, XHTTP, Trojan живут за ним на локальных портах, наружу не торчат.

Ключевая деталь: инбаунды должны слушать только localhost, иначе смысл теряется.

nginx.conf

stream {
    map $ssl_preread_server_name $upstream {
        lab.example.com      reality;     # ваш Reality
        cdn.example.com      xhttp;       # туннель под CDN
        site.example.com     website;     # обычный сайт
    }
    upstream reality { server 127.0.0.1:2443; }
    upstream xhttp   { server 127.0.0.1:2096; }
    upstream website { server 127.0.0.1:8080; }

    server {
        listen 443;
        ssl_preread on;          # читаем SNI, не расшифровывая
        proxy_protocol on;       # передаём реальный IP дальше
        proxy_pass $upstream;
    }
}

Со стороны Xray нужно разрешить приём этого заголовка, иначе вместо адреса клиента в логах будет 127.0.0.1:

inbound

"streamSettings": {
  "network": "raw",
  "security": "reality",
  "rawSettings": {
    "acceptProxyProtocol": true
  }
}

Схема 3. Fallback: Xray сам решает, куда отдать

Xray слушает 443, и если соединение не наше (не тот UUID, не тот пароль), он молча передаёт его дальше: на сайт или другой протокол. Снаружи это неотличимо от обычного веб-сервера: активное зондирование получает настоящую страницу.

inbound

"settings": {
  "clients": [{ "id": "ВАШ_UUID", "flow": "xtls-rprx-vision" }],
  "decryption": "none",
  "fallbacks": [
    { "dest": 2023 },                        // чужой трафик → XHTTP-инбаунд
    { "alpn": "h2", "dest": 8082, "xver": 1 },  // HTTP/2 → сайт
    { "dest": 8081, "xver": 1 }                 // остальное → сайт
  ]
}

xver: 1 это тот самый PROXY protocol: сайт-заглушка увидит реальный IP посетителя, а не локалхост. Мелочь, которая делает логи сайта правдоподобными.

Hysteria и сайт на одном UDP 443

Про это почти не пишут, а приём полезный. Hysteria обычно вешают на отдельный UDP-порт, и он торчит наружу как единственный UDP, что само по себе примета. Между тем QUIC тоже передаёт SNI, а значит UDP 443 можно делить между Hysteria и HTTP/3-сайтом.

Умеет это Caddy с модулем caddy-l4 (в стандартной сборке его нет, нужна сборка через xcaddy):

терминал

# проверить, есть ли модуль в вашей сборке
caddy list-modules | grep -c layer4     # 0 = нет, нужна пересборка

go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
xcaddy build --with github.com/mholt/caddy-l4

caddy.json

"udpsni": {
  "listen": ["udp/:443"],
  "routes": [
    {
      "match": [{ "quic": { "sni": ["hy.example.com"] } }],
      "handle": [{ "handler": "proxy",
                   "upstreams": [{ "dial": ["udp/127.0.0.1:3443"] }] }]
    },
    {
      "handle": [{ "handler": "proxy",
                   "upstreams": [{ "dial": ["udp/127.0.0.1:8443"] }] }]
    }
  ]
}

Результат: снаружи открыт TCP 443 и UDP 443, ровно как у обычного сайта с HTTP/3. Отдельного «странного» порта нет.

Четыре грабли, которые ломают ноду не сразу

1. Hysteria не перечитывает сертификат. Она не следит за файлом: сертификат обновился, а Hysteria продолжает отдавать старый, и через 90 дней клиенты получают ошибку TLS. Лечится перезапуском после обновления: плагином caddy-events-exec, параметром reloadcmd в acme.sh или просто по расписанию.

2. Больше пяти доменов на один ACME-аккаунт: проблемы с продлением. Разводите домены между Let's Encrypt и ZeroSSL, если их много.

3. На VPS без AES-NI шифрование упирается в процессор. Помогает явный выбор ChaCha20 вместо AES, заметно на дешёвых тарифах:

tlsSettings

"cipherSuites": "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
"minVersion": "1.2"

4. В Xray 26 транспорт tcp называется raw. Оба варианта валидны для ядра, но сторонние генераторы подписок могут не понимать raw: инбаунд при этом работает, а из подписки молча пропадает. Если протокол поднялся на ноде, но не появился у клиента, первым делом проверьте это имя.

Что из этого брать в свою инфраструктуру

• Одна нода, два протокола → порт на протокол, не усложняйте.
• Хотите, чтобы нода выглядела веб-сервером → SNI-разделение плюс acceptProxyProtocol.
• Ставите Hysteria → сразу решите вопрос перезапуска при обновлении сертификата, иначе вернётесь к этому через три месяца.
• Есть свой сайт на ноде → включайте xver, чтобы в логах был реальный IP клиента.

Дальше: готовые профили всех протоколов ищите в статье Профили подключений, а маскировку под свой сайт смотрите в Self-steal с nginx.