Serverless-relay-транспорт
- title
- Serverless-relay-транспорт
- type
- concept
- summary
- Использование бесплатного тарифа serverless-сред (Apps Script, Workers, Cloud Run) как выходного узла для прокси обхода блокировок
- tags
- networking, censorship-circumvention, serverless, google-apps-script, cloudflare-workers
- created
- 2026-04-24
- updated
- 2026-04-24
- lang
- ru
- translation_of
- serverless-relay-transport
- source_updated
- 2026-04-24
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-medium
Схема обхода блокировок, в которой "выходным сервером" пользователя служит не арендованный VPS, а serverless-функция, развёрнутая на бесплатном тарифе крупного облачного провайдера. Клиент выполняет MITM-терминацию собственного HTTPS, переупаковывает каждый запрос в RPC к функции, а функция пересылает его через fetch() (или аналог). Ответ возвращается тем же путём.
Типичные примеры на сегодняшний день - Google Apps Script (см. masterhttprelayvpn, masterhttprelayvpn-rust) и Cloudflare Workers (те же инструменты поддерживают их как альтернативный бэкенд). В прошлом похожим образом использовалась AWS Lambda, а Cloud Run используется до сих пор теми, кто готов платить за исходящий трафик. Схема обобщается на любого провайдера, предоставляющего простой HTTPS-эндпоинт на своих общих edge-IP с бесплатным или почти бесплатным лимитом запросов.
Чем это отличается от VPN или VLESS-туннеля
Туннель на базе VPS (xray-tutorial, WireGuard, OpenVPN) даёт вам L3/L4-канал. Вы отправляете туда пакеты, пакеты выходят с другого конца. Сервер ваш, IP ваш, сертификат ваш, и форма передаваемого трафика полностью под вашим контролем.
Serverless-relay даёт RPC-эндпоинт, а не сетевой канал:
- Провайдер сам определяет имя хоста, IP, TLS-сертификат, разрешённые HTTP-методы, а также зачастую максимальный размер тела и длительность запроса.
- Нельзя гонять произвольные протоколы. UDP исключён. WebSocket исключён (Apps Script не поддерживает upgrade; Workers поддерживают, но большинство relay'ев на бесплатных тарифах этого не делают). Server-sent events и долгоживущие потоки HTTP/2 по большей части не работают.
- Каждый запрос оплачивает накладные расходы: один TLS-handshake (часто переиспользуется), открытие одного HTTP/2-потока, упаковку исходного запроса в JSON, вызов
fetch()провайдером к целевому серверу, декодирование JSON-ответа и возврат результата. Это добавляет сотни миллисекунд задержки на каждый запрос. - Потоковое видео работает плохо: у функции relay обычно есть ограничение по времени на один вызов (Apps Script: 6 минут; Cloudflare Workers: 30 секунд на бесплатном тарифе, 15 минут на платном), после чего соединение обрывается прямо посреди потока.
Отсюда следует, что построить прозрачное туннелирование наподобие WireGuard невозможно. Клиенту приходится локально перехватывать TLS через MITM, разбирать HTTP-запрос, переупаковывать его и преобразовывать ответ. Именно поэтому каждый инструмент в этой категории поставляется с локальным корневым CA, который предлагается установить пользователю.
Почему это работает, когда CDN fronting обычно не работает
Классический domain-fronting практически мёртв, поскольку CDN требуют совпадения SNI и заголовка Host. Serverless-relay продолжает жить, потому что фронт и бэк - это один и тот же провайдер:
- Для Apps Script внешний SNI равен
www.google.com, а внутренний Host -script.google.com. И то, и другое принадлежит Google. Google маршрутизирует запрос между ними по внутреннему заголовку Host, не называя это "fronting", - это просто их собственный HTTP/2-роутер. - Для Cloudflare Workers внешний SNI - это имя хоста вашего Worker'а (или любой хост Cloudflare), а внутренний Host - маршрут вашего Worker'а. И то, и другое - Cloudflare. Та же самая история.
Цензор не может заблокировать внешний SNI, поскольку этот хост необходим половине интернета. Цензор также не может отличить запрос к вашему relay от запроса к легитимным сервисам провайдера: IP, сертификат и TLS-отпечаток принадлежат провайдеру, а не вам. Тот факт, что "domain fronting умер в 2020 году", не похоронил этот подход, потому что это не домен-фронтинг через CDN; это "аренда поддомена на общем edge провайдера".
Подвох в том, что провайдер может прибить ваш relay в любой момент: удалить развёртывание, заблокировать аккаунт или внедрить проверки на стороне сервера, отличающие трафик UrlFetchApp.fetch() от обычного использования. На текущий момент (апрель 2026 года) Google не делает этого для Apps Script. Завтра всё может измениться.
Что вы получаете и от чего отказываетесь
Плюсы:
- Нулевая инфраструктура. Никаких VPS, доменов, TLS-сертификатов, SSH-ключей, юнитов
systemd, правилufwи мониторинга. Нужен только Google-аккаунт и ~5 минут кликов по инструкциям. - Нулевая стоимость (при умеренном использовании). Бесплатный тариф покрывает обычный веб-сёрфинг одного пользователя. Apps Script: 20 000 вызовов скрипта в день. Cloudflare Workers: 100 000 запросов в день на бесплатном тарифе.
- Трудноблокируемый IP. Через edge-IP провайдеров проходит столько легитимного трафика, что их ковровая блокировка обходится цензору слишком дорого политически и технически. Тот же аргумент, что и у CDN-фронтинга, но здесь он по-прежнему работает, поскольку трафик действительно принадлежит провайдеру.
- Нет состояния сервера, которое жалко потерять. В отличие от VPS, где заблокированный IP приходится менять часами, заблокированный Apps Script разворачивается заново с другого аккаунта примерно за 30 секунд.
Минусы:
- Никакого UDP, WebSocket или стриминга. Никакого Hysteria2, QUIC или видеозвонков без протокола, который relay способен проксировать как простые HTTPS-запросы.
- Потолок квот. Пара сессий на YouTube быстро съест дневную квоту Apps Script, если только инструмент не маршрутизирует трафик к сервисам Google напрямую (трюк с гибридной маршрутизацией - см. masterhttprelayvpn-rust).
- Риск нарушения правил провайдера (ToS). Условия использования Apps Script запрещают "работу в качестве прокси или VPN". Контроль за этим непостоянен, но Google может блокировать и блокирует скрипты, похожие на прокси. Инструменты в этой нише собирают меньше звёзд, чем в среднем по рынку, в том числе из-за пользователей, у которых заблокировали relay.
- Штраф по задержке. Каждая загрузка страницы оплачивает накладные расходы relay. Разница заметна по сравнению с прямым VLESS-туннелем: для чтения текста приемлемо, для тяжёлых медиа-сайтов раздражает.
- Подходит только для одного пользователя. Если разделить relay даже между несколькими людьми, квота сгорит за минуты. Это инструмент строго для индивидуального использования.
Место схемы в экосистеме обхода блокировок
Serverless-relay находится на полюсе "одиночный пользователь с нулевым бюджетом". Ступенью выше идёт схема VLESS-over-CDN (платный домен на Cloudflare + Worker + VLESS-конфигурация), затем классический VLESS на VPS (xray-tutorial), затем каскадные многозвенные схемы (russia-vpn-bypass-state-2026-04).
Аудитория играет решающую роль:
- Иран. Serverless-relay используют очень активно, поскольку IP-адреса Google там фактически невозможно заблокировать, а локальный рынок инструментов обхода огромен. Apps Script сейчас является предпочтительным бэкендом. Telegram-канал проекта MasterHttpRelayVPN ведётся на фарси.
- Россия. Распространено меньше. Подход ТСПУ к белым спискам CIDR отличается от иранского подхода со списками SNI: edge-IP Google не попадают в белые списки ТСПУ автоматически, а сам ТСПУ периодически замедляет сервисы Google. Кроме того, российская культура обхода блокировок стандартизировалась вокруг связки VLESS+Reality с выходом через VPS, поэтому ниша serverless-relay здесь скромнее.
- Китай. Исторически было полезно (Apps Script не блокируется активно в том смысле, как основные сервисы Google), но обработка edge-инфраструктуры Google Великим файрволом устроена иначе, поэтому большинство китайских пользователей предпочитают семейство Shadowsocks с локальными мостами.
Шаблон проектирования для реализации
Все инструменты в этой категории приходят к одинаковой архитектуре:
- Локальные слушатели HTTP-proxy + SOCKS5, чтобы пользователь мог направить браузер на 127.0.0.1.
- Локальный корневой CA, генерируемый при первом запуске. Устанавливается в системное хранилище доверенных сертификатов ОС с помощью платформенных утилит.
- Слой переупаковки: парсит HTTPS-запрос браузера, упаковывает его в JSON и отправляет POST-запросом на эндпоинт relay.
- На стороне relay: проверяет общий секрет, делает вызов встроенным HTTP-клиентом провайдера к настоящей цели и передаёт тело ответа обратно потоком.
- Оптимизация гибридной маршрутизации: запросы к собственным ресурсам провайдера (Google, Cloudflare) идут в обход relay и туннелируются напрямую через edge провайдера с подменой SNI. Именно за счёт этого экономится львиная доля квоты на бесплатном тарифе.
Модель аутентификации - это всегда предварительно согласованный секрет (auth_key) между клиентом и relay. Аутентификации на уровне провайдера нет, поскольку смысл как раз в анонимном развёртывании. Эндпоинт relay фактически публичен: если секрет утечёт, любой сможет сжигать вашу квоту, пока вы его не смените.
Связанные страницы
- masterhttprelayvpn - эталонная реализация на Python (бэкенды Apps Script, Cloud Run, Cloudflare Worker)
- masterhttprelayvpn-rust - порт на Rust с десктопным интерфейсом и поддержкой Android
- domain-fronting - трюк с TLS, который serverless-relay использует на внешнем уровне
- xray-tutorial, vless-subscription-format - альтернатива на базе VPS с принципиально другим профилем цены и производительности
- russia-vpn-bypass-state-2026-04 - почему этот паттерн играет меньшую роль в российских реалиях