Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
VLESS через CDN: WebSocket или XHTTP на своём домене
Jason Chen
14 октября 2026 г.· 13 мин чтения
Схема VLESS через CDN ставит пограничный узел CDN между клиентом и вашим VPS на Ubuntu: клиент подключается к вашему домену на краю сети, CDN передаёт один секретный путь на исходный сервер, а Xray принимает его только на loopback. В инструкции используются Xray v26.3.27, Nginx как обратный прокси на исходном сервере и Cloudflare как пример CDN; транспорт выбирается один — WebSocket или XHTTP.［1］
Ключевые выводы
- Прочитайте актуальные условия CDN до настройки: работающий туннель ещё не значит, что такое использование разрешено.
- Используйте строгий режим TLS до исходного сервера, например Cloudflare Full (strict), а не режим без проверки сертификата.
- Держите Xray на
127.0.0.1, а Nginx пусть передаёт только один секретный путь на каждый транспорт.- XHTTP в режиме
packet-up— осторожный выбор для CDN, WebSocket — более простой и старый вариант.- Отделяйте «клиент подключился» от «трафик прошёл через CDN»: проверьте отказ при прямом обращении к серверу, неверном пути и неверном UUID.
Инструкция подготовлена по официальным источникам ниже; полный сквозной тест не выполнялся. Номера версий указывают на использованную документацию, а не на окружение, проверенное автором. Перед началом определите владельца, доступ и восстановление по чек-листу планирования собственного сервера.
Нужна ли вам схема VLESS через CDN?
Выполняйте эти шаги только на VPS и домене, которыми вы владеете или управляете. Нужны консольный доступ, не зависящий от прокси, SSH со строгой проверкой ключа хоста по проверенному known_hosts и резервные копии текущих файлов Nginx, файрвола и Xray. Не используйте чужой домен, бесплатные сервисы поддоменов или сторонний Worker для размещения своей точки входа.
CDN меняет то, кто видит и завершает ваш трафик. Пограничный узел расшифровывает TLS от клиента и открывает второе TLS-соединение к исходному серверу, поэтому оператор CDN обрабатывает поток прокси посередине. Если вам нужен только надёжный ежедневный выход и вы не хотите сами обслуживать сертификаты, Nginx и Xray, сравните обязанности при VPS и управляемом VPN, прежде чем добавлять ещё одно звено. Как в целом связаны край сети и исходный сервер, объясняет материал о том, как CDN стоит между вами и сайтом.
Проверьте условия CDN до настройки
Особые условия сервисов Cloudflare оставляют за компанией право отключить или ограничить использование CDN, если без соответствующих платных услуг через него раздаётся видео или непропорционально большая доля крупных файлов.［2］ Прокси, через который идут стриминг или массовые загрузки, может подпасть под это описание. Прочитайте действующие условия и лимиты своего тарифа и сохраните прямую точку входа, например сервер VLESS REALITY, если нужен путь, не зависящий от политики CDN.
Ничто здесь не делает маршрут неблокируемым. CDN может перезапускать пограничные серверы, применять тайм-ауты простоя или менять функции, а Cloudflare прямо указывает, что выпуски обновлений могут обрывать открытые соединения WebSocket.［3］
WebSocket или XHTTP: какой транспорт подходит для пути через CDN?
Оба транспорта переносят VLESS внутри HTTP, поэтому CDN, проксирующая HTTP, может их пропустить. Различаются они способом передачи потока и тем, что должна разрешать CDN.
| Вопрос | Настройка VLESS WebSocket TLS | VLESS XHTTP через CDN (packet-up) |
|---|---|---|
| Как идут данные | Одно соединение HTTP/1.1 после Upgrade | Отправка — пронумерованными POST-запросами, получение — потоковым GET |
| Требование к CDN | WebSockets включены для зоны | Обычное проксирование HTTP, без Upgrade |
| Рекомендации Project X | Документация советует перейти на XHTTP, потому что у WebSocket ALPN http/1.1 | packet-up назван самым совместимым режимом за CDN и прокси |
| Что нужно от прокси | Заголовки Upgrade и Connection | Тела запроса и ответа без буферизации |
| Главный компромисс | Просто и поддерживается многими клиентами | Новее; поддержка нужна и в клиентском, и в серверном ядре |
Страница WebSocket в документации Project X рекомендует перейти на XHTTP, чтобы избежать характерного ALPN http/1.1.［4］ Раздел транспорта XHTTP отсылает к обсуждению XHTTP в проекте, где packet-up рекомендуют, когда CDN или обратный прокси не пропускают другие режимы, и отмечают, что stream-up через Cloudflare требует включённой поддержки gRPC.［5］［6］ В этой инструкции XHTTP остаётся в режиме packet-up, чтобы исходный сервер оставался обычным прокси HTTP/1.1. Если у вас уже есть прямая точка входа XHTTP, держите её отдельно от этой точки входа через CDN.
Шаг 1: подготовьте домен, сертификат и файрвол исходного сервера
Создайте DNS-запись, например proxy.example.com, указывающую на VPS, и включите для неё проксирование через CDN. В Cloudflare выберите для зоны режим SSL/TLS Full (strict): тогда пограничный узел проверяет сертификат исходного сервера, выпущенный публичным УЦ или Cloudflare Origin CA.［7］ Не используйте Flexible или Full: первый вообще не шифрует участок до сервера, второй принимает недействительные сертификаты.
Если выбран WebSocket, включите WebSockets в разделе Network настроек зоны.［3］ Разместите сертификат и ключ исходного сервера в /etc/ssl/vless-cdn/fullchain.pem и /etc/ssl/vless-cdn/privkey.pem, владелец root, права на ключ 0600.
Ограничьте TCP 443 на исходном сервере опубликованными диапазонами адресов CDN, чтобы клиенты не могли обойти край сети.［8］ Сохраните правило для SSH и путь продления сертификата, если ему ещё нужен доступ к серверу. Перепроверяйте диапазоны при их обновлении: устаревший список может незаметно сломать точку входа.
Шаг 2: запустите входящие подключения Xray только на loopback
Скачайте архив Linux 64-bit из официального выпуска v26.3.27, проверьте примечания к выпуску и опубликованные материалы для проверки и установите бинарный файл в /opt/xray-cdn/v26.3.27/xray с владельцем root и правами 0755. Сгенерируйте UUID командой /opt/xray-cdn/v26.3.27/xray uuid и выберите случайный сегмент пути для каждого транспорта. Создайте служебную учётную запись без входа xray-cdn и сохраните файл /etc/xray-cdn/server.json с правами 0640 и владельцем root:xray-cdn.［1］
{
"log": {"loglevel": "warning"},
"inbounds": [
{
"tag": "vless-ws",
"listen": "127.0.0.1",
"port": 10001,
"protocol": "vless",
"settings": {"clients": [{"id": "REPLACE_UUID"}], "decryption": "none"},
"streamSettings": {"network": "ws", "wsSettings": {"path": "/ws-REPLACE_SECRET"}}
},
{
"tag": "vless-xhttp",
"listen": "127.0.0.1",
"port": 10002,
"protocol": "vless",
"settings": {"clients": [{"id": "REPLACE_UUID"}], "decryption": "none"},
"streamSettings": {"network": "xhttp", "xhttpSettings": {"path": "/xh-REPLACE_SECRET/", "mode": "packet-up"}}
}
],
"outbounds": [{"tag": "direct", "protocol": "freedom"}]
}
Оставьте только входящее подключение для выбранного транспорта. Ни одно из них не включает TLS, потому что TLS завершается в Nginx на этом же хосте; это безопасно, только пока оба слушают 127.0.0.1. Параметр VLESS decryption: none означает, что сам VLESS не добавляет шифрования. Проверьте конфигурацию командой sudo -u xray-cdn /opt/xray-cdn/v26.3.27/xray run -test -config /etc/xray-cdn/server.json, затем запустите Xray как службу systemd от имени xray-cdn.
Шаг 3: передавайте через Nginx только секретные пути
Добавьте блок server для proxy.example.com. Любой путь, кроме секретных, возвращает 404, поэтому сканер на исходном сервере видит обычный HTTPS-сайт, за которым ничего нет.
server {
listen 443 ssl;
server_name proxy.example.com;
ssl_certificate /etc/ssl/vless-cdn/fullchain.pem;
ssl_certificate_key /etc/ssl/vless-cdn/privkey.pem;
location = /ws-REPLACE_SECRET {
proxy_pass http://127.0.0.1:10001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_read_timeout 300s;
}
location /xh-REPLACE_SECRET/ {
proxy_pass http://127.0.0.1:10002;
proxy_http_version 1.1;
proxy_buffering off;
proxy_request_buffering off;
proxy_set_header Host $host;
proxy_read_timeout 300s;
}
location / { return 404; }
}
Блок WebSocket передаёт заголовки Upgrade и Connection, которые промежуточный прокси иначе отбрасывает.［9］ Блок XHTTP отключает буферизацию в обе стороны; при proxy_http_version 1.1 Nginx может передавать тело запроса в Xray по мере поступления, не собирая его целиком.［10］ Для XHTTP используется префиксное сопоставление, потому что каждый запрос добавляет к пути свой суффикс. Выполните sudo nginx -t и перезагружайте Nginx только после успешной проверки.
Шаг 4: настройте клиента на имя хоста в CDN
На клиенте Ubuntu установите ту же версию Xray и сохраните закрытый client.json (права 0600) для маршрута WebSocket:
{
"inbounds": [{"listen": "127.0.0.1", "port": 1083, "protocol": "socks", "settings": {"auth": "noauth", "udp": false}}],
"outbounds": [{
"tag": "cdn-ws",
"protocol": "vless",
"settings": {"vnext": [{"address": "proxy.example.com", "port": 443, "users": [{"id": "REPLACE_UUID", "encryption": "none"}]}]},
"streamSettings": {
"network": "ws",
"security": "tls",
"tlsSettings": {"serverName": "proxy.example.com", "allowInsecure": false},
"wsSettings": {"path": "/ws-REPLACE_SECRET"}
}
}]
}
Для XHTTP оставьте тот же исходящий блок и замените поля транспорта:
"network": "xhttp",
"xhttpSettings": {"path": "/xh-REPLACE_SECRET/", "mode": "packet-up"}
Адрес и serverName — это ваш домен, а не IP исходного сервера, поэтому TLS-сессия клиента завершается на краю сети, а проверка сертификата остаётся включённой. Выполните xray run -test -config ./client.json, затем запустите клиента в интерактивном режиме и направьте одно тестовое приложение на SOCKS5 127.0.0.1:1083.
Как убедиться, что трафик действительно идёт через CDN?
Загрузившаяся через прокси страница доказывает лишь то, что работает какой-то путь. Проверяйте каждую границу отдельно, меняя одно условие за раз и возвращая рабочий файл между проверками.
| Способ проверки | Ожидаемое поведение | Если результат другой |
|---|---|---|
curl --proxy socks5h://127.0.0.1:1083 https://check.example.net/health к своему эндпоинту | Ожидаемый ответ через прокси | Прочитайте журналы Nginx и Xray, прежде чем менять транспорт |
dig +short proxy.example.com | Возвращаются адреса узлов CDN, а не IP вашего VPS | Запись не проксируется; исправьте DNS, прежде чем доверять остальным результатам |
С внешнего хоста: curl --resolve proxy.example.com:443:ORIGIN_IP https://proxy.example.com/ | Тайм-аут или отказ в соединении | Файрвол исходного сервера всё ещё пропускает клиентов не из CDN |
Запрос https://proxy.example.com/wrong-path через край сети | Ответ 404 от Nginx | Слишком широкий блок location передаёт лишнее |
| Копия клиента с другим действительным UUID | Запрос через прокси не проходит | Убедитесь, что старый процесс клиента остановлен, а список UUID верен |
Копия клиента с serverName, которого нет в сертификате края сети | Проверка TLS не проходит | Оставьте allowInsecure: false; не «чините» это отключением проверки TLS |
Затем откройте инструмент проверки IP-адреса в браузере, настроенном на локальный SOCKS-порт. Он должен показать адрес выхода вашего VPS: CDN несёт входящий участок, а исходящий freedom в Xray выходит с сервера. Этот результат относится только к запросу браузера, а не к DNS, IPv6 или UDP других приложений.
Если запросы WebSocket не проходят, а обычный HTTPS через тот же край сети работает, диагностика сбоев WebSocket при работающем HTTPS помогает отделить настройки CDN, прокси и ошибки клиента. Для XHTTP обрыв загрузок после простоя проявляется как падение длинных запросов; в обсуждении XHTTP отмечено, что Cloudflare обрывает HTTP-ответы, по которым 100 секунд не идут данные.［6］
Как откатить или вывести точку входа через CDN из работы?
Перед изменениями сохраните закрытые копии server.json, файла сайта Nginx, правил файрвола и клиентского файла. Откат на клиенте — это восстановление прежнего профиля и проверка нового запроса. На сервере отключите новый сайт Nginx и службу xray-cdn, перезагрузите Nginx и убедитесь через sudo ss -lntp, что порты 10001 и 10002 никто не слушает.
Чтобы вывести точку входа из работы, удалите проксируемую DNS-запись или отключите для неё CDN, удалите UUID из оставшихся конфигураций и отзовите или удалите сертификат исходного сервера, если он больше нигде не нужен. Правила файрвола только для CDN снимайте последними, когда станет ясно, каким ещё сайтам на сервере нужен порт 443. Обновления выполняйте так же: подготовьте каталог новой версии, проверьте оба файла через -test и повторите таблицу проверок, прежде чем переключать службу.
Итоги
- Перед настройкой проверьте условия CDN и собственный резервный доступ к серверу.
- Используйте строгий режим TLS до исходного сервера и оставляйте Xray доступным только через Nginx на loopback.
- Выберите WebSocket ради простоты или XHTTP
packet-upкак осторожный путь через CDN, но не оба на одном клиенте. - Подтверждайте путь через CDN проверками отказов, а не одной успешно загруженной страницей.
Часто задаваемые вопросы (FAQ)
Делает ли CDN перед VLESS подключение приватнее прямой точки входа?
Не автоматически. CDN завершает TLS клиента и открывает собственное соединение к исходному серверу, поэтому видит проксируемый поток HTTP, внутри которого идёт ваш трафик VLESS.
Почему бы не выбрать режим Flexible в Cloudflare ради экономии времени?
Flexible передаёт трафик от края сети до исходного сервера без TLS. Full (strict) проверяет сертификат сервера, защищает второй участок и не даёт выдать себя за ваш сервер.
Можно ли запустить WebSocket и XHTTP на одном домене?
Да, с отдельными секретными путями и отдельными блоками location в Nginx, как в примере. Каждому клиенту назначайте один транспорт, чтобы понимать, к какому пути относится сбой.
Почему здесь XHTTP работает в режиме packet-up, а не auto?
В рекомендациях проекта packet-up назван самым совместимым режимом за CDN и обратными прокси, и он позволяет оставить исходный сервер обычным HTTP/1.1 без настроек gRPC.
Защищает ли CDN исходный сервер от всех прямых сканирований?
Только если файрвол исходного сервера пропускает одни лишь диапазоны адресов CDN. Без этого правила любой, кто узнает адрес VPS, подключится к Nginx напрямую в обход края сети.
Сохранит ли такая схема доступность прокси при любых сетевых ограничениях?
Нет. Точку входа за CDN всё равно могут замедлить, отфильтровать или ограничить на стороне самой CDN, а перезапуски пограничных узлов закрывают открытые соединения. Держите отдельный путь восстановления.
Как часто обновлять диапазоны адресов CDN в файрволе?
Проверяйте опубликованные диапазоны CDN по расписанию и после каждого уведомления провайдера. Устаревший список разрешённых адресов может незаметно отклонять законные подключения от края сети к серверу.
Отказ от ответственности: Данная статья носит исключительно информационный характер и не является юридической, технической или иной профессиональной консультацией. Мы не гарантируем точность, полноту или актуальность содержания.
Источники:
- Xray-core release v26.3.27 — https://github.com/XTLS/Xray-core/releases/tag/v26.3.27
- Cloudflare Service-Specific Terms — https://www.cloudflare.com/service-specific-terms-application-services/
- Cloudflare Docs: WebSockets — https://developers.cloudflare.com/network/websockets/
- Project X: WebSocket transport — https://xtls.github.io/en/config/transports/websocket.html
- Project X: XHTTP (SplitHTTP) transport entry — https://xtls.github.io/en/config/transports/splithttp.html
- Project X: XHTTP: Beyond REALITY — https://github.com/XTLS/Xray-core/discussions/4113
- Cloudflare Docs: SSL/TLS encryption modes — https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/
- Cloudflare IP ranges — https://www.cloudflare.com/ips/
- NGINX: WebSocket proxying — https://nginx.org/en/docs/http/websocket.html
- NGINX: ngx_http_proxy_module — https://nginx.org/en/docs/http/ngx_http_proxy_module.html
Sources checked 14 октября 2026 г.
Рекомендуемые статьи:
