[2026-09-26] eagle: personal/plans/balda-mm-phase4-agents.md personal/projects/balda/balda-mm-delegation-plan.md personal/tech/cloudflare-tunnel-ssh-published-route.md

personal/tech/cloudflare-tunnel-ssh-published-route.md

@@ -52,6 +52,36 @@ Host ssh-kraken.qentra.top
 - Сам ssh к hostname:22 напрямую (без cloudflared в ProxyCommand) к проксированному DNS не работает — hostname за Cloudflare-Anycast, в туннель трафик попадает только через cloudflared-клиент.
 - `network_mode: host` (container cloudflared) — сервис напрямую видит локальные порты (sshd на `0.0.0.0:22`).
 
+## HTTP-сервис через существующий туннель (без рестарта cloudflared)
+
+Туннель на origin — **один процесс на все маршруты**. Добавление нового HTTP-маршрута
+**не требует** ни правки токена, ни рестарта cloudflared: маршруты живут на стороне
+Cloudflare и подхватываются работающим туннелем.
+
+**Схема (Zero Trust):**
+- Networks → Tunnels → туннель → **Routes → Add route → Published application**
+- Service: **HTTP** → `localhost:<порт>` (например `localhost:8790`)
+- hostname — **одиночный** subdomain (`agents-bridge.qentra.top`), см. правило выше
+
+**Обязательно: Access Application** на тот же hostname (Access → Applications →
+Add self-hosted, тип HTTP). Без него сервис получается публичным без авторизации —
+для служебных мостов это недопустимо.
+
+**Живой пример на Mac (проверено 2026-09-26):**
+
+| Факт | Значение |
+|---|---|
+| Бинарь | `/opt/homebrew/bin/cloudflared` (2026.3.0) |
+| Процесс | `cloudflared tunnel --protocol quic run --token …` |
+| Автозапуск | LaunchAgent `com.cloudflare.cloudflared.plist` |
+| Токены | `~/.cloudflared/*-token` (0600), отдельный файл на каждый hostname |
+| Маршрут на Mac | `ssh-kraken.qentra.top` → `ssh://localhost:22` |
+
+Проверка, что туннель поднят: наличие процесса + запись в `~/.cloudflared/`.
+Проверка нового маршрута: `curl` извне на `<hostname>/healthz`.
+
+---
+
 ## Общий паттерн «жив, но шумит» cloudflared на origin без IPv6
 
 Если у origin нет глобального IPv6 (роутер не выдаёт), cloudflared пытается поднять QUIC и по IPv6 → в логах постоянные `ERR ... write udp [::]->198.41.x.x:7844: sendmsg: network is unreachable`, соединения падают/retry. Туннель продолжает работать по IPv4-QUIC. Возможный фикс — заставить cloudflared использовать только IPv4.