VPN·HUB·CRACK Timeweb CDN · VPN HUB CRACK
Все статьи
CDN и др. обходы PRO

Timeweb CDN

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

Timeweb CDN

🟠 Что делаем. Прячем ноду за CDN Timeweb: наружу торчит домен CDN, реальный IP сервера не виден, а блокировка по IP перестаёт работать. Транспорт: XHTTP в режиме packet-up, инбаунд слушает localhost, наружу его публикует Caddy.

✅ Плюсы: дёшево, ресурс поднимается за пять минут, доступны все HTTP-методы кроме PUT, значит работает и GET-only, и обычный POST-аплинк.

❌ Минус, о котором надо знать заранее: на Timeweb фиксировались обрывы длинных потоковых сессий. Для мессенджеров и браузинга это незаметно, для больших загрузок уже заметно. Держите Timeweb как резервный фронт, а не как единственный.

Схема проверена на INCY с ядром 26.7.11. Что такое CDN-фронтинг в целом, чем отличаются режимы «через GET» и «через POST» разобрано в обзорной статье «CDN-фронтинг: спрятать ноду за CDN».

Шаг 1. Домен, Caddy и заглушка

Нужен домен, уже направленный A-записью на IP ноды. Дальше серверная часть ставится одним скриптом: он поднимает Caddy, собирает сайт-заглушку для «лишних» посетителей и сам генерирует путь туннеля.

⬇️ Скачать install-caddy-node.sh

chmod +x install-caddy-node.sh
./install-caddy-node.sh

Скрипт спросит почту (для Let's Encrypt) и домен ноды. В конце он выведет сгенерированный путь.

🔑 Сохраните этот путь. Он понадобится дважды: в хосте панели и в JSON инбаунда. Ниже он обозначен как ПУТЬ_ИЗ_СКРИПТА. Если пути не совпадут, клиент получит 404, и искать причину вы будете долго.

Шаг 2. CDN-ресурс в Timeweb

Источник: домен ноды, порт 443. Оставляйте активными только те параметры, что на скриншотах: любая лишняя оптимизация ломает туннель.

Источник и домен раздачи: домен ноды, порт 443

Кэширование: выставляем как на примере

⚠️ Кэш обязательно выключить. CDN, который закэширует ответ туннеля, будет отдавать его повторно другим сессиям, и соединение просто перестанет работать.

Безопасность: редирект и Secure token выключены

Включаем HTTP/3, остальные дополнительные опции по примеру

Шаг 3. Хост в панели

Адрес: домен CDN, порт 443

SNI и Host: домен CDN; путь: из скрипта; ALPN: h3

Коротко о полях:

Поле Значение
Адрес домен CDN, порт 443
SNI домен CDN
Host домен CDN
Path ПУТЬ_ИЗ_СКРИПТА
ALPN h3

ALPN h3 включаем ради скорости. Но он работает только если HTTP/3 включён и в CDN-ресурсе (шаг 2), и здесь. Включите в одном месте, получите обрывы.

Шаг 4. XHTTP-инбаунд

Замените два маркера: ПУТЬ_ИЗ_СКРИПТА и ДОМЕН_НОДЫ. Инбаунд слушает 127.0.0.1:7443, наружу его публикует Caddy, напрямую порт не торчит.

{
  "tag": "TW-Adapted",
  "port": 7443,
  "listen": "127.0.0.1",
  "protocol": "vless",
  "settings": { "clients": [], "decryption": "none" },
  "sniffing": {
    "enabled": true,
    "routeOnly": true,
    "destOverride": ["http", "tls", "quic"]
  },
  "streamSettings": {
    "network": "xhttp",
    "security": "none",
    "xhttpSettings": {
      "mode": "packet-up",
      "path": "ПУТЬ_ИЗ_СКРИПТА",
      "extra": {
        "mode": "packet-up",
        "path": "ПУТЬ_ИЗ_СКРИПТА",
        "xmux": {
          "cMaxReuseTimes": "0",
          "maxConnections": "3",
          "hKeepAlivePeriod": 60,
          "hMaxRequestTimes": "1000",
          "hMaxReusableSecs": "3600"
        },
        "seqKey": "chunk_id",
        "headers": {
          "Accept": "*/*",
          "Cookie": "session_id=66693s41171e7ad909f9d129869361dl",
          "Origin": "https://ДОМЕН_НОДЫ/",
          "Referer": "https://ДОМЕН_НОДЫ/",
          "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0",
          "Sec-Fetch-Dest": "empty",
          "Sec-Fetch-Mode": "cors",
          "Sec-Fetch-Site": "same-origin",
          "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7"
        },
        "sessionKey": "auth",
        "noSSEHeader": true,
        "noGRPCHeader": true,
        "seqPlacement": "query",
        "sessionIDKey": "auth",
        "xPaddingBytes": "50-150",
        "sessionIDTable": "Base62",
        "xPaddingHeader": "X-Api-Key",
        "xPaddingMethod": "tokenish",
        "sessionIDLength": "16-32",
        "sessionPlacement": "query",
        "uplinkHTTPMethod": "GET",
        "xPaddingObfsMode": true,
        "xPaddingPlacement": "header",
        "downloadHTTPMethod": "GET",
        "scMaxBufferedPosts": 100,
        "scMaxEachPostBytes": 3000000,
        "sessionIDPlacement": "query",
        "uplinkDataPlacement": "body",
        "scMinPostsIntervalMs": "5-10",
        "serverMaxHeaderBytes": 32768
      },
      "noSSEHeader": true,
      "noGRPCHeader": true,
      "scMaxBufferedPosts": 100,
      "scMaxEachPostBytes": 3000000,
      "scMaxConcurrentPosts": 10,
      "scMinPostsIntervalMs": 5,
      "serverMaxHeaderBytes": 32768
    }
  }
}

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

🔑 Блок extra на клиенте должен совпадать с серверным 1-в-1. Это самая частая причина «подключилось, но нет интернета»: сервер ждёт одно, клиент присылает другое, и каждый запрос отбивается с 400.

🔁 Если аплинк не идёт, попробуйте POST. На Timeweb доступны все методы кроме PUT, так что "uplinkHTTPMethod": "POST" здесь допустим, в отличие от Yandex CDN, где эдж режет POST и остаётся только GET-only.

Альтернатива: тот же фронт на Beget

Если Timeweb не подошёл, ровно та же схема собирается в Beget. Отличие одно, но принципиальное: там нужно явно добавить заголовок запроса Host со значением домена ноды, иначе origin не поймёт, кому адресован запрос.

Базовые настройки и источник контента

Настройки кэширования

Безопасность и включение HTTP/3

Заголовок запроса Host с доменом ноды обязателен

Финальная проверка

Что проверить Как понять, что верно
DNS готов домен ноды резолвится на её IP
Путь совпадает ПУТЬ_ИЗ_СКРИПТА одинаковый в хосте и в инбаунде
HTTP/3 включён и в CDN-ресурсе, и в ALPN хоста
Домен заменён в Origin и Referer стоит реальный домен ноды, а не маркер
Кэш выключен на пути туннеля кэширование отключено

Быстрая проверка с любой машины: CDN-домен должен резолвиться в адреса CDN, а не в IP вашей ноды:

# должен вернуть IP Timeweb/Beget, НЕ адрес вашего сервера
dig +short cdn.ваш-домен.ru

# заглушка отвечает 200 — значит Caddy на месте
curl -s -o /dev/null -w "%{http_code}\n" https://cdn.ваш-домен.ru/

Грабли

Симптом Причина
Клиент ловит 400 на каждый запрос блок extra на клиенте не совпадает с серверным
404 на пути туннеля путь в хосте и в инбаунде разный
Подключилось, скорость 0 не выключен кэш на пути туннеля
Рвётся на больших загрузках известный минус Timeweb: обрывы потоковых сессий
Работает по HTTP, не работает по TLS HTTP/3 включён только в одном месте из двух

Связано: «CDN-фронтинг» (общая база), «Yandex CDN» (там GET-only обязателен), «Beeline CDN», «Заблокировали IP?».