VPN·HUB·CRACK
Timeweb CDN · VPN HUB CRACK
Timeweb CDN
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. Оставляйте активными только те параметры, что на скриншотах: любая лишняя оптимизация ломает туннель.


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


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


Коротко о полях:
| Поле | Значение |
|---|---|
| Адрес | домен 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 не поймёт, кому адресован запрос.




Финальная проверка
| Что проверить | Как понять, что верно |
|---|---|
| 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?».