VPN·HUB·CRACK
Маркет 0 ₽ +
Выйти?
VPN·HUB·CRACK Спрятать сервер за CDN: обзор и общая база · VPN HUB CRACK
Все статьи
CDN и др. обходы PRO

Спрятать сервер за CDN: обзор и общая база

Обновлено 11 августа 2026 Проверено

CDN-фронтинг: спрятать ноду за CDN

⚠️ Актуально с 28.07.2026 (Yandex CDN): ориджин должен быть на российском сервере: зарубежные источники Яндекс начал резать (подсети play2go и aeza уже забанены). За границу трафик уводите каскадом с РФ-ориджина. Подробности: гайд по Yandex CDN.

Зачем. Когда блокируют по IP (а не по SNI, имени сайта в начале защищённого соединения), помогает CDN: клиент идёт на адрес CDN, а тот тянет трафик с вашей ноды (это ваш сервер, он же «origin»). Снаружи виден только IP CDN: забанить вашу ноду по IP больше нельзя, пока живёт CDN.

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

Что прячем. Для CDN подходят транспорты поверх HTTP: XHTTP (современный транспорт под CDN; рекомендуем) и WebSocket(WS). Reality‑Vision (raw TCP) за CDN не работает: flow: xtls-rprx-vision через CDN использовать нельзя. XHTTP создавался именно под CDN, в т.ч. под те, что не умеют WS/gRPC.

🇷🇺→🇪🇺 Куда вешать CDN: на РФ-ноду, выход за рубежом. РФ-CDN (Yandex / Timeweb / Selectel / Beget) фронтят российский origin, поэтому CDN ставится на РФ-ноду (вход), а не на заграничную. Чтобы при этом трафик выходил из-за рубежа (а не с РФ-IP), РФ-нода делает мост (каскад) РФ→ЕУ. Итоговая цепочка:

клиент → CDN (рос. IP эджа) → РФ-нода (origin) → хоп → загран-выход → интернет

Снаружи виден только IP CDN; вход российский (РФ-CDN свои подсети не банят); а реальный egress заграничный. CDN на загран-ноду вешать смысла нет: РФ-CDN её не зафронтят, а западные (Cloudflare) в РФ ненадёжны. Как поднять мост РФ→ЕУ, смотрите в статье «Каскад RU-вход → загран-выход» (там же готовый генератор конфига хопа).

Что такое «через GET» и «через POST»

XHTTP разделяет канал на две HTTP-транзакции: - download (вниз) = длинный GET: сервер долго отдаёт тело ответа; - upload (вверх) = POST: клиент шлёт данные (в режиме packet-up: много коротких POST; в stream-up: одно длинное тело).

Поэтому «настроить CDN через POST» = режим packet-up (максимально CDN‑совместимый: дискретные POST вверх + длинный GET вниз). «Через GET» = режим stream-up/stream-one (упор на длинные потоковые соединения, меньше запросов, ниже задержка, но CDN должен уметь long‑lived стримы).

От ЛЮБОГО CDN для XHTTP нужно 4 вещи (без них рвётся): 1. Разрешены методы GET и POST (часто POST выключен по умолчанию). 2. Кеш отключён на пути прокси (иначе CDN закеширует поток, всё ломается). 3. Проброс Host и заголовков к origin, без переписывания. 4. Большие таймауты, без буферизации ответа (long‑lived GET не должен обрываться).

Честно про РФ‑CDN (актуально на июнь 2026): проверенных «из коробки» рецептов мало. Timeweb CDN документированно рвёт ws/xhttp‑сессии. Selectel не подтверждает потоковое проксирование без кеша. Beget даёт методы/заголовки/HTTP3, но не даёт явного «no‑cache по пути». Самый предсказуемый из РФ: Yandex Cloud CDN (GET-only); зарубеж: Cloudflare. РФ‑CDN рассматривайте как резервный канал и обязательно тестируйте.

База: XHTTP‑inbound на ноде (origin)

Один inbound, два пресета режима: выберете под «GET» или «POST».

Вариант «через POST» (packet-up, рекомендуемый для CDN):

{
  "tag": "vless-xhttp-cdn",
  "listen": "0.0.0.0", "port": 8080, "protocol": "vless",   // origin слушает HTTP, TLS терминирует CDN
  "settings": { "clients": [{ "id": "UUID" }], "decryption": "none" },
  "streamSettings": {
    "network": "xhttp",
    "xhttpSettings": {
      "host": "cdn.your.domain",
      "path": "/xh",
      "mode": "packet-up",
      "extra": { "xPaddingBytes": "100-1000" }
    }
  }
}

⚠️ Это фрагмент, а не готовый профиль. Добавьте его в массив config.inbounds[] вашего config profile. Если вставить в панель только этот кусок, свежая Remnawave ответит Config doesn't have inbounds — она ждёт профиль целиком (log + inbounds + outbounds + routing).

Вариант «через GET» (stream-up, длинные потоки): тот же блок, но

"xhttpSettings": { "host": "cdn.your.domain", "path": "/xh", "mode": "stream-up" }

mode: "auto" сам подберёт вариант: за TLS‑H2 это stream-up, за Reality это stream-one, иначе packet-up. Для жёстких/капризных CDN надёжнее явный packet-up.

В Remnawave: этот inbound добавляется в Config Profile; затем Host с Address = cdn.your.domain, портом CDN (443), path = /xh, host = cdn.your.domain. TLS обеспечивает CDN, поэтому на самом inbound security можно не ставить (origin за CDN по HTTP), но тогда трафик CDN→origin идёт без шифрования; безопаснее закрыть origin от всех, кроме IP CDN (ufw).

Команды на ноде (origin): копируйте

Чтобы CDN тянул трафик с ноды, перед Xray на ноде ставим nginx: он отдаёт сайт-обманку на /, а секретный путь /xh проксирует в Xray без буферизации (это критично для XHTTP, иначе CDN/nginx «съест» поток).

Установка nginx + сертификат для origin-домена:

apt update && apt -y install nginx certbot python3-certbot-nginx
ufw allow 80/tcp && ufw allow 443/tcp
certbot --nginx -d node1.your.domain --non-interactive --agree-tos -m you@example.com

Конфиг nginx /etc/nginx/sites-available/node-origin (поменяйте node1.your.domain и путь /xh):

server {
    listen 443 ssl http2;
    server_name node1.your.domain;
    ssl_certificate     /etc/letsencrypt/live/node1.your.domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/node1.your.domain/privkey.pem;

    location /xh {                         # секретный путь XHTTP -> Xray
        proxy_pass https://vpn-hub.nubonet.ru;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_request_buffering off;       # не буферизуем upload (POST) — обязательно
        proxy_buffering off;               # не буферизуем download (long GET) — обязательно
        proxy_read_timeout 300s;
        client_max_body_size 0;
        chunked_transfer_encoding on;
    }
    location / { root /var/www/decoy; try_files $uri /index.html; }   # сайт-обманка
}

Подключить конфиг и перезагрузить:

mkdir -p /var/www/decoy && echo '<h1>It works</h1>' > /var/www/decoy/index.html
ln -s /etc/nginx/sites-available/node-origin /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Теперь в CDN-панели Origin (источник) указывайте node1.your.domain:443 (HTTPS). Дальше идёт настройка самого CDN по провайдеру (каждый разобран отдельной статьёй ниже).

Разбор по CDN-провайдерам

Каждый провайдер разобран отдельной статьёй (что/✅/❌/пошаговая настройка/грабли). База выше общая для всех:

  • ⭐ Yandex CDN (рекомендую): самый предсказуемый РФ-фронт, «своя» для ТСПУ сеть. Засада: режет POST (405), лечится GET-only. Полный рецепт из реального внедрения (8 шагов).
  • 🟢 Beget CDN: методы/заголовки/HTTP3 есть, лоялен к VPN; засада с кешем (нет no-cache по пути).
  • 🔵 Selectel CDN: простая панель, но потоковое без кеша не подтверждено; только резерв + тесты.
  • 🟠 Timeweb CDN: документированно рвёт потоковые сессии; держать сугубо резервом.
  • 🟧 Cloudflare CDN: эталон предсказуемости, но из РФ медленный DNS и оплата недоступна → для зарубежа/резерва.

Итог: какой CDN выбрать

  • Основной канал РФ: прямой Self‑steal Reality (маскировка под свой сайт-заглушку; без CDN), см. «Профили подключений».
  • Резерв по IP‑блокировкам: XHTTP за CDN. Из РФ‑CDN рабочий выбор: Yandex Cloud CDN (GET-only): «своя» для ТСПУ сеть, стабильный домен. Зарубеж: Cloudflare/Gcore/EdgeCenter. Beget (методы+HTTP3), с осторожностью по кешу; Timeweb/Selectel только после тестов на обрывы.
  • Всегда давайте клиенту подписку с несколькими хостами (Reality + XHTTP‑CDN): один канал лёг, работает второй.

Связано: «Профили подключений» (настройка самих XHTTP/Reality-inbound), «Заблокировали IP?» (что делать при блокировке IP/подсети), «Один хост → тысячи юзеров» (раздача нескольких транспортов).