WebSocket transport (ws) — VPN over WS+TLS:443

Определение

WebSocket transport (часто просто ws) — это способ передачи VLESS / VMess / Trojan-payload’а внутри WebSocket-сессии поверх TLS на стандартном HTTPS-порту 443. Снаружи выглядит как long-polling веб-приложение к обычному сайту: WebSocket-handshake, валидный TLS-сертификат, типовой URL-путь.

Один из самых старых и до сих пор широко используемых транспортов V2Ray / Xray-core. Основное применение в 2026 — self-host через свой VPS с веб-сервером nginx или Caddy на фронте.

Как работает

Связка vless+ws+tls за nginx — это типовая конфигурация self-hosted VPN. Поток:

1. Клиент подключается по HTTPS к https://yourdomain.com:443/secretpath. TLS-handshake идёт с настоящим сертификатом Let’s Encrypt на ваш домен.
2. Nginx видит запрос на /secretpath и проксирует его на локальный xray-core (127.0.0.1:8443). Для всех остальных URL — отдаёт обычный веб-сайт.
3. Xray принимает WebSocket-upgrade и достаёт из WS-фреймов VLESS-payload.
4. VLESS-туннель прокидывает пользовательский трафик дальше в интернет.

Минимальная nginx-конфигурация:

location /secretpath {
    if ($http_upgrade != "websocket") { return 404; }
    proxy_pass http://127.0.0.1:8443;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 600s;
}

Любой посетитель, не знающий /secretpath, увидит обычный сайт. Без active probing узнать, что VPN там есть, нельзя.

Почему это важно для пользователя VPN

WS-transport — это «универсальный отверточный набор» self-hoster’а. Плюсы:

• CDN-проходимый. Можно поставить Cloudflare перед своим VPS — клиент подключается к CF, CF проксирует WebSocket на ваш origin. ТСПУ видит трафик к Cloudflare, blocked-by-IP не работает (CF — миллионы доменов).
• Универсальная клиент-поддержка. WS-режим есть в xray-core, sing-box, V2Box, Karing, AmneziaVPN, Hiddify, NekoBox — буквально в каждом современном клиенте.
• Дешёво в эксплуатации. Один VPS с nginx, один домен, один Let’s Encrypt cert.

Минусы 2026:

• TLS-in-TLS уязвимость. Поверх WS+TLS идёт пользовательский HTTPS — это классический паттерн TLS-in-TLS, который ТСПУ детектирует с 2024. Окно работы — недели, не годы.
• Поведенческий анализ. WS-сессии характеризуются длинной живучестью одного TCP-connection и редкими keep-alive пакетами. ТСПУ это паттерн ловит.
• Active probing. Если ТСПУ узнает /secretpath (утечка через шеринг конфига), сервер мгновенно палится.

Практический вывод 2026: WS+TLS — это fallback-транспорт, не primary. Primary — VLESS Reality (более устойчив). WS+TLS держат для совместимости и для CDN-front режимов. Если вы новичок и self-host’ите впервые — начинайте с Reality (vless+reality+xtls), не с WS.

Альтернатива в той же категории — gRPC transport. Он выглядит как обычный gRPC over HTTP/2, при правильной настройке детектируется хуже, чем WS.

Связанные термины

VLESS, VMess — что чаще всего оборачивается в WS. gRPC transport — альтернатива. TLS 1.3 — нижний слой. TLS-in-TLS — главная проблема. xray-core — основная реализация.

Источники

• RFC 6455 — The WebSocket Protocol.
• Xray-core transports documentation.
• v2fly documentation.
• Сообщество Project X discussions — best practices по WS-front.