Zapret Wiki

Недавно обновлено

время чтения ~19 мин.

.md

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

О чём заметка

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

Статус данных: смесь официальной документации, чтения исходников и наблюдений

Лимиты, флаги и порты ниже взяты из документации 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), поэтому часть корпоративных сетей и средств защиты режет его целиком — ссылка может просто не открыться у получателя.
  • Это инструмент «показать своё наружу», а не средство обхода блокировок для собственного браузинга: направление трафика ровно противоположное тому, ради которого ставят 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. Во втором:

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

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

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

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 превращает это из хрупкого трюка в предсказуемый шаг: агенту не нужно вылавливать адрес из нарисованной псевдографикой рамки, чей вид авторы вправе поменять в любой версии. Он читает поле из структурированной строки лога.

Потоковые ответы через быстрый туннель не поедут

Документация 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-атаке: там наружу утекало то, что слушало петлю, а здесь вы сами открываете её всему интернету.

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

Минимальная гигиена перед тем, как дать ссылку

Поставьте перед сервисом хотя бы простейшую проверку — пароль по базовой 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 (об этом — заметка про отключение QUIC в браузере), первое, что стоит попробовать при вечных переподключениях, — это --protocol http2. Проверить доступность точки входа можно вручную: curl -v https://region1.v2.argotunnel.com:7844.

Второй: откроется ли выданный адрес у посетителя. Тут всё упирается в судьбу самой сети Cloudflare в российских сетях, а она отдельная и давняя тема: подсети компании попадали под ковровые блокировки, а списки исключений к ним пересобирались — см. разбор блокировки подсетей Cloudflare и Amazon по белому списку и хронику инцидента 23 июня 2026. Отдельных подтверждённых сообщений именно про trycloudflare.com нет, и выдавать общую картину по Cloudflare за факт о конкретной зоне было бы неправильно. Практический вывод простой: если ссылку открывают из России, проверяйте её работоспособность на месте, а не полагайтесь на то, что «у меня открылось».

Это не обход блокировок

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

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

Дальше — чтение исходного кода, а не документация

Описанное в этом разделе видно в ветке 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 никуда не делась — см. разбор перехвата DNS-запросов к 8.8.8.8 и 1.1.1.1 и заметку о том, когда DoH помогает, а когда нет. Замена ищется среди отдельных DoH-клиентов, а не внутри cloudflared.

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

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

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

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

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

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

📚 См. также

🤖 Эти статьи открыты — можно обучать на них ИИ

При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: исходник этой заметки · скачать весь репозиторий одним zip-архивом.

Вид графа

Обратные ссылки