---
date: 2026-09-20
tags:
  - cloudflare
  - tunnel
  - localhost
  - devtools
  - webhook
  - ai-agents
  - security
  - quic
aliases:
  - Quick Tunnel Cloudflare
  - trycloudflare.com что это
  - Как выставить localhost в интернет без белого IP
  - cloudflared tunnel --url http://localhost:3000
  - Публичная ссылка на локальный сайт для Claude Code
  - Бесплатный туннель без аккаунта Cloudflare
  - Почему не открывается ссылка trycloudflare
  - try.cloudflare.com сентябрь 2026
description: "Публичный HTTPS-адрес для localhost одной командой: как устроены Quick Tunnel и trycloudflare.com, какие у них лимиты, риски и польза для ИИ-агентов."
image: attachments/cloudflare-quick-tunnel-header.webp
link: https://try.cloudflare.com/
---

> [!mirror] Резервное зеркало
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/cloudflare-quick-tunnel](https://wiki.zapret.moe/cloudflare-quick-tunnel)

# 🚇 Quick Tunnel от Cloudflare: публичная ссылка на localhost одной командой (trycloudflare.com)

![[cloudflare-quick-tunnel-header.webp]]

> [!info] О чём заметка
> Команда `cloudflared tunnel --url http://localhost:3000` выдаёт случайный публичный адрес вида `https://три-английских-слова.trycloudflare.com`, который ведёт прямо на сервис, запущенный у вас на компьютере. Не нужен ни «белый» (публичный) IP-адрес, ни проброс портов на роутере, ни свой домен, ни даже аккаунт в Cloudflare: пока команда работает в консоли, ссылка живёт, закрыли процесс — адрес умер. Здесь разобрано, как это устроено внутри, какие у бесплатного режима жёсткие лимиты, что при этом видит Cloudflare, почему ссылку на `trycloudflare.com` откроет не всякая корпоративная сеть и что из этого следует для ИИ-агентов вроде Claude Code и Codex, под которых Cloudflare в сентябре 2026 переписала витрину сервиса.

> [!warning] Статус данных: смесь официальной документации, чтения исходников и наблюдений
> Лимиты, флаги и порты ниже взяты из документации Cloudflare и репозитория `cloudflared` по состоянию на **20 сентября 2026**. Места, где описано поведение, полученное **чтением исходного кода**, помечены отдельно: документация его не фиксирует, и авторы вправе поменять его без предупреждения. Про доступность `trycloudflare.com` из российских сетей никаких системных замеров нет: всё, что об этом написано ниже, — рассуждение о вероятных препятствиях с инструкцией, как проверить свой случай самому, а не измеренный факт.

## TL;DR

- Quick Tunnel («быстрый туннель») — бесплатный режим Cloudflare Tunnel без регистрации: одна команда поднимает обратный прокси от сети Cloudflare к вашему `localhost` и печатает случайный адрес в зоне `trycloudflare.com` с готовым HTTPS.
- Сама возможность не новая: поддержка появилась в `cloudflared` версии **2020.5.1** (по документации Cloudflare). В сентябре 2026 обновились витрина `try.cloudflare.com` и позиционирование — сервис продвигают как инструмент для **кодовых агентов**, которым нужен публичный адрес, а не ноутбук разработчика.
- Машиночитаемый вывод, ради которого агенты это и любят, включается флагом `--output json`: в документации он описан как формат логов консоли, то есть агент читает поле из JSON-строки, а не регулярным выражением из ASCII-рамки.
- Лимиты бесплатного режима жёсткие и официально задокументированы: **200 одновременных запросов** (сверх — ответ HTTP 429), **не поддерживается SSE** (потоковая досылка событий от сервера), одно соединение до сети Cloudflare, никаких гарантий доступности.
- Туннель ставит ваш локальный сервис в открытый интернет **без какой-либо аутентификации**: случайность адреса — не защита. Перед тем как отдать ссылку, стоит понимать, что именно отвечает на этом порту.
- Трафик расшифровывается на стороне Cloudflare: HTTPS-сертификат выписан Cloudflare на её же домен, значит содержимое запросов и ответов проходит через компанию в открытом виде.
- Домен `trycloudflare.com` с 2024 года активно используют рассыльщики вредоносов (наблюдения Proofpoint), поэтому часть корпоративных сетей и средств защиты режет его целиком — ссылка может просто не открыться у получателя.
- Это инструмент «показать своё наружу», а **не** средство обхода блокировок для собственного браузинга: направление трафика ровно противоположное тому, ради которого ставят [[Zapret2/Zapret2|Zapret]] или VPN.

## Что изменилось в сентябре 2026, а что было и раньше

Формулировка «Cloudflare запустила сервис» разошлась по новостным каналам в середине сентября 2026, но технически запускать было нечего: режим быстрых туннелей работает годами. Документация Cloudflare прямо указывает минимальную версию клиента — `cloudflared` **2020.5.1**, то есть механика доступна с 2020 года, а ограничение «один канал до сети Cloudflare вместо четырёх» появилось в версии **2023.3.2** (файл `CHANGES.md` в репозитории проекта).

Что действительно произошло: Cloudflare переписала страницу `try.cloudflare.com` и развернула её к новой аудитории. Прежний посыл был «попробуйте туннель, прежде чем заводить аккаунт»; новый обращается к кодовым агентам напрямую — «вашему агенту нужен URL, а не ноутбук», с перечислением сценариев: тесты, сервисы скриншотов, приёмники webhook, прогонные стенды. Там же названа возможность, которую агенты ценят больше человека: **структурированный вывод** — «hostname, edge и health в JSON на stdout, без регулярных выражений по логам».

Обсуждение попало на Hacker News (по датировке агрегаторов — 18–19 сентября 2026), оттуда разошлось по каналам и блогам. При этом в официальном списке изменений Cloudflare Tunnel за сентябрь 2026 записи про быстрые туннели, JSON-вывод или агентов нет — ближайшие записи касаются массового создания маршрутов и снятия поддержки 32-битных сборок. Так что корректная формулировка новости — **не «появился новый сервис», а «старый режим переупаковали под задачи ИИ-агентов»**.

От этой разницы зависит, чего ждать. Переупакованный режим наследует все ограничения, которые Cloudflare годами вешала на бесплатные туннели: они разобраны ниже, в разделе про лимиты, и знать их полезно до того, как агент построит на такой ссылке рабочий процесс.

## Что вообще решает эта команда

Сервис, запущенный на вашей машине, обычно доступен только ей самой: адрес `localhost` (он же `127.0.0.1`) — это «сам себе сеть», петля внутри операционной системы. Чтобы на такой сервис зашёл кто-то извне, исторически нужно было собрать цепочку: получить у провайдера публичный, он же «белый», IP-адрес; настроить на роутере проброс портов, то есть правило «входящие соединения на такой-то порт отправляй вот этой машине в домашней сети»; завести домен и прописать ему A-запись; выпустить TLS-сертификат, иначе браузер будет ругаться на небезопасное соединение.

Каждый шаг в этой цепочке ломается по-своему. Домашний интернет и мобильные сети часто прячут абонентов за общим шлюзом, который подменяет адреса на границе сети (NAT, Network Address Translation; когда так поступает сам провайдер и один публичный адрес делят сотни абонентов, это называют CGNAT), — пробрасывать порт там попросту некуда. Публичный адрес у многих провайдеров — платная услуга. Динамический адрес меняется, и за ним нужно следить отдельным сервисом. А выставленный наружу порт домашнего компьютера немедленно начинают перебирать сканеры.

Quick Tunnel сносит всю цепочку разом за счёт смены направления: не интернет стучится к вам, а ваша машина сама устанавливает исходящее соединение к сети Cloudflare и держит его открытым. Всё, что приходит на выданный адрес, Cloudflare заворачивает в это уже установленное соединение.

Проще говоря: вместо того чтобы прорубать в своей стене дверь с улицы и потом её сторожить, вы сами звоните наружу и держите линию — а входящие переадресуют вам по этой линии. Ни роутер, ни провайдерский NAT этому не мешают, потому что для них это обычное исходящее соединение, как у браузера.

## Как это выглядит на практике

Понадобится один исполняемый файл — `cloudflared`. Его ставят пакетным менеджером (в macOS — `brew install cloudflared`, в Windows — через `winget`, в Linux есть пакеты `.deb` и `.rpm`) или кладут готовый бинарник из релизов проекта. Аккаунт, ключ и вход в систему на этом этапе не нужны.

Дальше всё сводится к двум окнам консоли. В первом крутится ваш проект — например, `npm run dev` на порту 3000. Во втором:

```bash
cloudflared tunnel --url http://localhost:3000
```

В ответ клиент печатает предупреждение о том, что туннели без аккаунта не имеют гарантий доступности и подпадают под пользовательское соглашение Cloudflare, а затем — рамку с адресом вида `https://arrived-suggests-flesh-liberty.trycloudflare.com`. Этот адрес уже работает по HTTPS: сертификат на `*.trycloudflare.com` принадлежит Cloudflare, ничего выпускать самому не нужно. Закрыли процесс по Ctrl+C — адрес перестал существовать; запустили снова — выдали новый, случайный.

Если ссылку разбирает не человек, а скрипт или агент, добавляется флаг формата вывода:

```bash
cloudflared tunnel --url http://localhost:3000 --output json
```

Теперь каждая строка лога — это отдельный JSON-объект, и адрес достаётся разбором поля, а не вылавливанием текста из рамки. В документации Cloudflare флаг `--output` описан скупо: «задаёт формат логов консоли, доступные значения `default` и `json`». Витрина `try.cloudflare.com` обещает в этом выводе «hostname, edge и health» — то есть имя выданного хоста, точку присутствия, через которую идёт соединение, и состояние туннеля. Отдельного описания этих полей в документации нет, поэтому автоматизацию лучше писать снисходительной: она не должна падать, если поле переименуют или добавят новое.

## Как это устроено внутри

Запущенный `cloudflared` делает две вещи. Сначала он обращается к сервису быстрых туннелей и получает от него служебные данные: идентификатор туннеля, секрет и выданное имя хоста в зоне `trycloudflare.com`. Затем поднимает постоянное соединение до ближайшей точки присутствия Cloudflare — на порт **7844**, по UDP для транспорта QUIC или по TCP для HTTP/2.

Дальше Cloudflare работает как обратный прокси. Посетитель открывает `https://…trycloudflare.com`, его TLS-соединение заканчивается на сервере Cloudflare, там запрос расшифровывается и отправляется в ваше исходящее соединение. Ваш `cloudflared` принимает запрос и стучится на указанный в `--url` локальный адрес, обычным HTTP по петле. Ответ идёт тем же путём назад.

Проще говоря: публичного адреса у вашего компьютера не появляется — его роль играет сеть Cloudflare, а вы остаётесь клиентом, который держит открытую линию. Отсюда все свойства режима: посетитель не видит ваш IP-адрес; защита роутера остаётся нетронутой; но и всё, что проходит по этой линии, проходит через чужую инфраструктуру.

Два следствия выясняются только на практике. Первое: по умолчанию быстрый туннель просит транспорт QUIC — если пользователь сам не задал `--protocol`, клиент подставляет `quic` (это видно в коде запуска быстрых туннелей в репозитории `cloudflared`). В сетях, где исходящий UDP на 7844 режут, соединение будет устанавливаться мучительно: клиент отрабатывает серию повторов с нарастающей паузой и только потом уходит на HTTP/2 поверх TCP. Быстрее не ждать, а сразу написать `--protocol http2`. Второе: если в каталоге `.cloudflared` лежит файл конфигурации `config.yaml` от «настоящего» именованного туннеля, быстрый режим не запустится — документация упоминает это как отдельное ограничение.

## Чем это полезно человеку

Самый частый сценарий — показать работу, которая ещё нигде не развёрнута. Вёрстка, собранная на ноутбуке, открывается на чужом телефоне в другом городе без выкладывания на хостинг. Заодно видно, как страница ведёт себя на реальном мобильном устройстве в реальной сети, — эмулятор мобильного экрана в браузере этого не показывает.

Второй сценарий — **webhook**, то есть входящий вызов от внешнего сервиса. Платёжный шлюз, мессенджер или Git-хостинг устроены так, что сами приходят на ваш адрес с уведомлением о событии: пришла оплата, написали в чат, случился коммит. Отладить такое на `localhost` нельзя в принципе — внешнему сервису некуда постучаться. Публичный адрес закрывает вопрос, и туннель живёт ровно столько, сколько идёт отладка.

Рядом стоят задачи, где сервису нужно, чтобы адрес был не локальным: возврат после входа через чужой аккаунт (OAuth-редирект), песочницы платёжных систем, проверка того, как страницу видят внешние анализаторы — сборщики превью в мессенджерах, измерители скорости, валидаторы разметки. Все они ходят к вам снаружи и на `localhost` не пойдут.

Наконец, туннель годится как временная замена файлообменника: подняли простой сервер каталога, отдали ссылку, забрали — закрыли. Но именно на этом сценарии чаще всего и обжигаются, потому что ссылка ведёт в папку на живой машине; об этом ниже, в разделе про то, что оказывается выставлено наружу.

Для постоянного домашнего сервиса — торрент-клиента, «умного дома», личной вики — быстрый туннель не годится, и это не вкусовщина, а прямая рекомендация документации: адрес меняется при каждом запуске, гарантий доступности нет, лимиты низкие. Постоянному сервису нужен именованный туннель с аккаунтом и своим доменом.

## Зачем это ИИ-агентам

Кодовый агент — Claude Code, Codex и прочие — работает короткими циклами: собрал, запустил, проверил, поправил. Пока проверка сводится к запуску тестов, публичный адрес ни к чему. Он нужен, как только в цикле появляется что-то внешнее по отношению к машине агента.

Таких мест три. Первое — сервисы, которые должны сами прийти на ваш стенд: те самые webhook от платёжек и мессенджеров, обратные вызовы внешних интеграций. Второе — инструменты, работающие «снаружи по ссылке»: сервисы скриншотов, аудиторы доступности и скорости, проверка превью ссылки. Третье — показ результата человеку: агент поднял проект и прислал ссылку, по которой заказчик смотрит страницу со своего телефона, а не собирает проект у себя.

Флаг `--output json` превращает это из хрупкого трюка в предсказуемый шаг: агенту не нужно вылавливать адрес из нарисованной псевдографикой рамки, чей вид авторы вправе поменять в любой версии. Он читает поле из структурированной строки лога.

> [!warning] Потоковые ответы через быстрый туннель не поедут
> Документация Cloudflare прямо отмечает: быстрые туннели **не поддерживают SSE** (Server-Sent Events — способ, при котором сервер держит одно HTTP-соединение открытым и досылает по нему события по мере появления). На SSE работают потоковая выдача ответов языковых моделей и часть серверов **MCP** (Model Context Protocol — протокол, по которому ИИ-агент подключает внешние инструменты). То есть выставить наружу локальный MCP-сервер или стриминговый чат-эндпоинт быстрым туннелем, скорее всего, не выйдет: обычные запросы пройдут, а поток оборвётся. Это случай для именованного туннеля.

И отдельно — вопрос доверия, который в этом сценарии решает не техника. Команда, поднимающая туннель, выглядит невинно, а по факту выносит кусок вашей машины в открытый интернет. Если агенту разрешено выполнять команды без подтверждения, он в состоянии сделать это молча. Разумная привычка — держать `cloudflared` в списке команд, требующих явного согласия, и проверять, какой именно порт агент собрался выставить.

## Лимиты бесплатного режима

| Ограничение | Что это значит на практике |
| --- | --- |
| 200 одновременных запросов | Всё сверх лимита получает ответ **HTTP 429** («слишком много запросов»). Для демонстрации хватит, для нагрузочного теста или публичного анонса — нет. |
| Нет поддержки SSE | Потоковые ответы и часть MCP-серверов работать не будут; обычные запросы пройдут. |
| Одно соединение до сети Cloudflare | С версии 2023.3.2 быстрый туннель держит один канал вместо четырёх: меньше запас на случай обрыва. |
| Нет гарантий доступности | В предупреждении клиента сказано прямо: аптайм не гарантируется, а Cloudflare оставляет за собой право проверять использование туннелей на соответствие своему пользовательскому соглашению. |
| Адрес случайный и не сохраняется | При каждом перезапуске выдаётся новый хост; закрепить имя нельзя. |
| Конфликт с `config.yaml` | Если в каталоге `.cloudflared` лежит конфиг именованного туннеля, быстрый режим не поднимется. |
| Версия клиента | Нужен `cloudflared` не ниже 2020.5.1. |

Отдельный, не технический лимит — назначение. Cloudflare описывает быстрые туннели как режим для разработки и экспериментов и отправляет всех, кому нужна работающая постоянно публикация, к именованным туннелям с аккаунтом. Это не пустая формальность: предупреждение самого клиента прямо оговаривает отсутствие гарантий и право Cloudflare разбираться со злоупотреблениями.

## Что видит Cloudflare и что видит интернет

HTTPS в этой схеме заканчивается на сервере Cloudflare. Сертификат выписан Cloudflare на её собственный домен, ключ — у неё же, значит и расшифровка происходит там. Дальше до вашей машины данные идут по отдельному защищённому соединению, но это уже другой участок: сквозного шифрования от посетителя до вашего приложения здесь нет. Для показа вёрстки это несущественно, для чужих персональных данных, паролей и рабочих документов — решение, которое стоит принимать осознанно.

Второе и более опасное: аутентификации нет вообще. Любой, кто узнал адрес, попадает на ваш сервис с правами обычного посетителя. Случайность имени хоста защитой не является — адрес утекает сам собой: он остаётся в заголовке `Referer` при переходе на внешние ссылки, разворачивается в превью мессенджеров, попадает в историю браузера и в логи всех сервисов, которым вы его дали. Исходить стоит из того, что адрес публичный с первой секунды.

Дальше вопрос в том, **что именно** отвечает на этом порту. Локальные сервисы разработки к встрече с интернетом не готовы: сборщики отдают исходники и карты кода, часть каркасов раскрывает переменные окружения через служебные маршруты, а если туннель направлен на простой файловый сервер каталога — наружу уходит содержимое папки целиком, вместе с `.env`, ключами и `.git`. Отдельная категория риска — панели без пароля, которые принято держать «только для себя»: административные интерфейсы баз данных, локальные блокноты для вычислений, веб-интерфейсы локальных языковых моделей. Сюда же — вопрос выставления локальных портов вообще, разобранный с другой стороны в заметке [[Localhost-tracking-Meta-Yandex-SOCKS5|о localhost-атаке]]: там наружу утекало то, что слушало петлю, а здесь вы сами открываете её всему интернету.

Побочный эффект того же свойства — проверка имени хоста в сервере разработки. Современные версии Vite (популярный сервер разработки и сборщик фронтенда) отвергают запрос с незнакомым заголовком `Host` и отвечают «Blocked request»: так они защищаются от атак с перепривязкой DNS (DNS rebinding — приём, при котором чужая страница заставляет браузер жертвы обратиться на её локальный адрес). Лечится это добавлением домена в `server.allowedHosts`, где допустим суффикс `.trycloudflare.com`. Полезно понимать, что это не поломка туннеля, а сработавшая защита, и снимать её стоит ровно на время демонстрации.

> [!tip] Минимальная гигиена перед тем, как дать ссылку
> Поставьте перед сервисом хотя бы простейшую проверку — пароль по базовой HTTP-аутентификации или секретный токен в адресе. Направляйте туннель строго на нужный порт приложения, а не на файловый сервер с каталогом проекта. Держите туннель открытым столько, сколько идёт показ, и закрывайте сразу после. И помните, что по ссылке к вам может прийти не только тот, кому вы её отправили.

## Почему ссылку могут не открыть: репутация домена

С февраля 2024 года домен `trycloudflare.com` активно используют не только разработчики. Proofpoint описала серию финансово мотивированных рассылок, где письма вели на быстрые туннели, а оттуда жертве отдавали средства удалённого доступа — AsyncRAT, Xworm, Remcos, VenomRAT, GuLoader. Схема удобна для атакующего тем же, чем и для честного пользователя: бесплатно, без аккаунта, поднимается за секунды, а после жалобы адрес просто меняют.

Последствие простое и предсказуемое: многие корпоративные сети, почтовые фильтры и средства защиты рабочих станций режут зону `trycloudflare.com` целиком, не разбирая, что за ней. Поэтому ссылка, которая у вас открывается прекрасно, у заказчика на рабочем ноутбуке может не открыться вовсе или встретить его предупреждением. Для внутренней отладки это не проблема, для показа работы клиенту — проблема ровно в тот момент, когда показать нужно.

Вывод отсюда практический: быстрый туннель хорош как черновик. Как только ссылку начинают пересылать людям, у которых своя корпоративная сеть, стоит потратить полчаса на именованный туннель со своим доменом — у него нет ни этой репутации, ни лимита в 200 запросов.

## Дойдёт ли туннель до Cloudflare из России

Здесь придётся разделить два вопроса, которые легко путаются.

Первый: доберётся ли ваш `cloudflared` до сети Cloudflare. Ему нужно исходящее соединение на порт 7844 — по UDP, если транспорт QUIC, или по TCP, если HTTP/2. Поскольку в быстром режиме клиент по умолчанию выбирает QUIC, а UDP российские системы фильтрации обрабатывают заметно хуже TCP (об этом — заметка [[DPI/tspu-disable-quic-chrome|про отключение QUIC в браузере]]), первое, что стоит попробовать при вечных переподключениях, — это `--protocol http2`. Проверить доступность точки входа можно вручную: `curl -v https://region1.v2.argotunnel.com:7844`.

Второй: откроется ли выданный адрес у посетителя. Тут всё упирается в судьбу самой сети Cloudflare в российских сетях, а она отдельная и давняя тема: подсети компании попадали под ковровые блокировки, а списки исключений к ним пересобирались — см. [[DPI/subnet-whitelist-blocking-2026|разбор блокировки подсетей Cloudflare и Amazon по белому списку]] и [[DPI/tspu-whitelist-cloudflare-june-2026|хронику инцидента 23 июня 2026]]. Отдельных подтверждённых сообщений именно про `trycloudflare.com` нет, и выдавать общую картину по Cloudflare за факт о конкретной зоне было бы неправильно. Практический вывод простой: если ссылку открывают из России, проверяйте её работоспособность на месте, а не полагайтесь на то, что «у меня открылось».

> [!important] Это не обход блокировок
> Быстрый туннель открывает интернету доступ **к вам**, а не вам — к заблокированным ресурсам. Через него не «ходят в YouTube»: направление трафика противоположное. Инструменты для своей стороны — это [[Zapret2/Zapret2|Zapret 2]] и разборы в разделе [[DPI/DPI|про DPI и ТСПУ]], а не `cloudflared`. Путаница возникает из-за слова «туннель», которым называют и обход цензуры, и публикацию своего сервиса наружу.

## Что лежит в исходниках: туннель с проверкой по почте

> [!warning] Дальше — чтение исходного кода, а не документация
> Описанное в этом разделе видно в ветке `master` репозитория `cloudflared` на 20 сентября 2026, в документации отсутствует и пользователю пока недоступно. Планы могут поменяться, код — исчезнуть, поведение — стать другим. Проверяйте по актуальным исходникам, прежде чем на это рассчитывать.

В коде быстрых туннелей заведена «защищённая» разновидность: если передать список разрешённых почтовых адресов или доменов флагом `--allowed-mail`, клиент запрашивает у сервиса туннель с режимом авторизации по одноразовому коду и поднимает у себя обработчик, который этот вход проверяет. То есть быстрый туннель без аккаунта, но с проверкой, что посетитель — тот, кого вы позвали.

Пользоваться этим пока нельзя: в том же файле висит пометка разработчиков о том, что флаг ещё предстоит зарегистрировать в интерфейсе командной строки, и до тех пор ветка кода недостижима. Если возможность доведут до релиза, она закроет главную дыру бесплатного режима — отсутствие какой бы то ни было аутентификации.

## Заодно: в cloudflared больше нет proxy-dns

Тем, кто держит `cloudflared` не ради туннелей, а как DNS-клиент, стоит знать о менее заметном изменении. В версии **2026.2.0** из клиента удалили режим `proxy-dns` — локальный прокси, поднимавший на машине обычный DNS-сервер и отправлявший запросы дальше по **DoH** (DNS over HTTPS — шифрованный DNS поверх HTTPS). Вместе с ним убраны команды `cloudflared proxy-dns`, `cloudflared tunnel proxy-dns`, все флаги `--proxy-dns-*` и секция `resolver` в конфигурации.

Для российского читателя это как раз тот случай, когда обновление способно сломать рабочую схему: `cloudflared proxy-dns` был популярным способом получить шифрованный DNS на машине или роутере, а тема актуальности такого DNS никуда не делась — см. [[DPI/tspu-dns-nsdi-dnat-august-2026|разбор перехвата DNS-запросов к 8.8.8.8 и 1.1.1.1]] и [[Zapret/doh-cherez-zapret|заметку о том, когда DoH помогает, а когда нет]]. Замена ищется среди отдельных DoH-клиентов, а не внутри `cloudflared`.

## Когда пора переходить на именованный туннель

Именованный туннель — это тот же `cloudflared`, но с аккаунтом Cloudflare, постоянным именем и вашим доменом. Настройка занимает больше времени: нужно завести домен в Cloudflare, авторизовать клиент, создать туннель и связать его с именем хоста. Взамен уходят почти все ограничения бесплатного режима — адрес постоянный, лимит в 200 одновременных запросов не действует, SSE работает, репутация домена ваша собственная.

Сигналов к переходу ровно четыре: ссылку нужно давать повторно или надолго; на неё приходят люди из корпоративных сетей; нужен поток событий или ответов; на сервис приходит сколько-нибудь заметная нагрузка. Если ни одного из них нет — быстрый туннель остаётся самым дешёвым способом решить задачу и забыть про неё через десять минут.

Поверх именованного туннеля включается и настоящая авторизация — доступ по правилам с проверкой личности посетителя. Это уже отдельная тема, которая в эту заметку не помещается, но знать про существование такой опции полезно: она решает ту самую проблему «ссылку знает любой», которой страдает бесплатный режим.

## Чек-лист перед тем, как выставить сервис наружу

- [ ] Понятно, **что именно** слушает выставляемый порт, и в этом каталоге нет `.env`, ключей и `.git`.
- [ ] Перед сервисом стоит хотя бы пароль или секретный токен — на случай, если адрес разойдётся.
- [ ] Туннель направлен на конкретное приложение, а не на файловый сервер с каталогом проекта.
- [ ] Если сервер разработки ругается «Blocked request» — домен добавлен в список разрешённых хостов на время показа, а не навсегда.
- [ ] Проверено, что получателю ссылка открывается: корпоративные сети и средства защиты режут `trycloudflare.com` целиком.
- [ ] Для потоковых ответов и MCP-серверов выбран именованный туннель: SSE в быстром режиме не поддерживается.
- [ ] Туннель закрыт сразу после показа, а не оставлен «на всякий случай» до перезагрузки.
- [ ] Если туннель поднимает ИИ-агент — команда `cloudflared` требует подтверждения, и видно, какой порт он выставляет.

## 📚 См. также

- [[Localhost-tracking-Meta-Yandex-SOCKS5|Localhost-атака: как Meta, Яндекс и шпионское ПО эксплуатируют loopback]] — обратная сторона темы: чем опасны сервисы, слушающие локальную петлю
- [[VLESS-localhost-protection-guide|Защита VPN-клиентов от localhost-атаки]] — практика закрытия локальных портов паролем и правилами
- [[DPI/tspu-disable-quic-chrome|Отключение QUIC как обход таймаутов ТСПУ]] — почему UDP-транспорт в российских сетях ведёт себя хуже TCP
- [[DPI/subnet-whitelist-blocking-2026|Блокировка подсетей Cloudflare и Amazon по белому списку]] — что мешает адресам Cloudflare открываться из России
- [[DPI/tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026: слетели исключения Cloudflare]] — как это выглядело на практике
- [[DPI/tspu-dns-nsdi-dnat-august-2026|Перехват DNS-запросов к 8.8.8.8 и 1.1.1.1]] — контекст к удалению proxy-dns из cloudflared
- [[Zapret/doh-cherez-zapret|Поможет ли Zapret при блокировке DoH]] — про шифрованный DNS без cloudflared
- 🔗 [try.cloudflare.com](https://try.cloudflare.com/) — витрина сервиса, та самая, переписанная под агентов
- 🔗 [Документация Cloudflare по быстрым туннелям](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/trycloudflare/) — первоисточник лимитов: 200 запросов, отсутствие SSE, версия клиента
- 🔗 [Параметры запуска cloudflared](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/run-parameters/) — описание флагов `--output`, `--protocol`, `--loglevel`
- 🔗 [Репозиторий cloudflared](https://github.com/cloudflare/cloudflared) — исходники быстрых туннелей и файл CHANGES.md с историей ограничений
- 🔗 [Разбор Proofpoint о злоупотреблении быстрыми туннелями](https://www.proofpoint.com/us/blog/threat-insight/threat-actor-abuses-cloudflare-tunnels-deliver-rats) — откуда у домена trycloudflare.com плохая репутация

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/cloudflare-quick-tunnel.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).