В контейнере Gateway выглядит здоровым, а за Nginx/Caddy появляются 502, срывы WebSocket-рукопожатия или бесконечные редиректы? Статья фокусируется на слое периметровый reverse proxy + завершение TLS + upgrade WebSocket. Она дополняет разбор сети Docker: там — кто какие пакеты видит, здесь — корректны ли цепочка HTTP/1.1 upgrade и пути от браузера до Gateway. Вы получите шесть частых ловушек, две таблицы топология/симптомы, копируемые фрагменты, шестишаговый продакшен-runbook и три жёсткие метрики для дежурств. После прочтения ясно, править ли заголовки Upgrade или возвращаться к апстриму 127.0.0.1:18789.
proxy_pass без HTTP/1.1 и Upgrade: WebSocket в браузере даёт 400/502 на периметре, а логи похожи на падение Gateway./openclaw, а приложение всё ещё отдаёт абсолютные URL с корня — статика и WS расходятся.proxy_read_timeout: длинные выводы модели или всплески канала тихо рвутся на периметре, вызывая шторм переподключений на апстрим.Таблица топологий сводит прокси на одном хосте, отдельный хост прокси, поддомен и подпуть; далее — заголовки и матрица симптомов.
Reverse proxy на том же хосте, что и Gateway (Nginx/Caddy рядом), даёт кратчайший путь: curl -v http://127.0.0.1:18789 проверяет апстрим локально. Отдельный хост прокси добавляет прыжки — перепроверьте security groups, внутренний DNS и TLS SNI. Поддомены обычно обходят снятие пути и войны за Cookie Path; подпуть подходит для одного брендового входа, но требует снять префикс только один раз на базовом URL OpenClaw и на прокси, плюс в devtools убедиться, что WS URL всё ещё указывают на ожидаемый wss:// путь.
В заявках на изменения прикладывайте два скриншота: финальный URL в адресной строке и Request URL рукопожатия WebSocket во вкладке Network. Без них ревью часто ошибочно классифицирует проблему как таймаут модели или OAuth каналов. Если есть корпоративный HTTPS-прокси, разделяйте путь офисного браузера (PAC) и дата-центрового прокси (часто прямой) — расхождение симптомов нормально.
В 2026 году HTTP/2 на периметре с HTTP/1.1 WebSocket на апстриме всё ещё норма: выясните, на каком прыжке разрешён upgrade. Не включайте одновременно принудительный H2 и кастомные переписывания WS без захвата пакетов — иначе разбор превращается в гадание.
| Топология | Когда уместна | Плюс для эксплуатации | Типичные ямы |
|---|---|---|---|
| Один хост + loopback-апстрим | Один VPS / постоянно включённый удалённый Mac | Локальный curl для разбора; TLS и процесс в одних логах | Привязка к 0.0.0.0 расширяет поверхность — нужен фаервол |
| Отдельный хост прокси | Много бэкендов, blue/green, WAF спереди | Периметр отделён от вычислений; централизованные продления сертификатов | Внутренние маршруты, SNI, дрейф целей health-check |
| Поддомен | WS отделён от основного сайта | Ясная семантика путей; проще правила CDN | Несколько сертификатов; отдельная политика HSTS |
| Подпуть | Один брендовый входной домен | Ниже когнитивная нагрузка на пользователя | Снятие префикса, циклы редиректов, неверный корень статики |
На периметре нужен upgrade до HTTP/1.1, пропуск или сборка Connection: upgrade и Upgrade: websocket, и таймауты чтения выше самого медленного перцентиля модели. Таблица — чеклист для ревью кода.
Часто упускают буферизацию прокси. proxy_buffering может помочь обычным API, но стриминг или долгоживущие соединения добавляют задержку или ощущение обрезки; при потоковых каналах или поведении вроде SSE прогоните staging под нагрузкой до включения буфера по умолчанию.
| Проверка | Nginx | Caddy |
|---|---|---|
| Версия протокола | proxy_http_version 1.1; | reverse_proxy по умолчанию HTTP/1.1; следите за явными transport |
| Цепочка Upgrade | Upgrade $http_upgrade; Connection "upgrade"; | Чаще автоматически; кастом через header_up |
| Host и IP клиента | proxy_set_header Host $host;, X-Forwarded-* | header_up Host {host}; доверие к числу хопов прокси |
| Долгие соединения | proxy_read_timeout / send_timeout | transport http { read_timeout ... } (синтаксис по версии) |
| Большие тела | client_max_body_size | Директивы лимита тела (документация Caddy) |
# Фрагмент: reverse proxy на локальный Gateway (порт по развёртыванию; пример 18789)
location / {
proxy_pass http://127.0.0.1:18789;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
# Фрагмент: авто TLS + WebSocket-апстрим
openclaw.example.com {
reverse_proxy 127.0.0.1:18789 {
header_up Host {host}
header_up X-Forwarded-For {remote_host}
header_up X-Forwarded-Proto {scheme}
}
}
Совет: после правок сначала на апстриме проверьте семантику рукопожатия командой curl -v -H "Connection: Upgrade" -H "Upgrade: websocket" http://127.0.0.1:18789/, затем публичный wss://; иначе TLS и прокси будут перекладывать вину.
Сопоставляйте симптомы с периметром, апстримом или конфигурацией приложения до пересборки контейнеров. Если таблица указывает на сеть контейнеров, вернитесь к разбору сети Docker; если каналы подключены, но Slack/Telegram молчат — разбор каналов.
Только прод, стейдж чист: сравните цепочку сертификатов (тот же УЦ?), версию правил CDN/WAF и ветвления map/if прокси по User-Agent. Многие 502 — ложные срабатывания на периметре, не версия OpenClaw.
| Симптом | Сначала подозревать | Проверить |
|---|---|---|
| 502 Bad Gateway | Апстрим не слушает, фаервол, неверное семейство сокетов | curl с прокси к апстриму; error.log upstream timed out / refused |
| 413 Request Entity Too Large | Маленький client_max_body_size на периметре | Увеличить и reload; синхронизировать лимиты CDN/WAF |
| WS не 101 | Нет Upgrade, переписан путь, http→https ломает рукопожатие | Статус в Network браузера; порядок location и return 301 |
| Циклы редиректа | Принудительный HTTPS без X-Forwarded-Proto | Временно ослабить HSTS на периметре; добавить forwarded-заголовки |
| Предупреждения сертификата / частичные сбои клиентов | Неполная цепь, неверный SNI, смешение IP-сертификатов | openssl s_client -servername для цепи; NTP |
https://, подпуть да/нет, делит ли WS хост с HTTP.18789).127.0.0.1:18789 или внутреннего VIP — без публичной задержки, чтобы отделить медленный периметр от медленного Gateway.При централизованных логах совместите долю 5xx в access прокси и ошибки приложения Gateway на двух осях — когда растёт только одна сторона, зона ответственности очевидна для разборов.
Ноутбучные прокси быстро проверяют фрагменты, но сон, переключения VPN и нестабильный домашний uplink делают TLS и продления ручной работой; SLO по 502 сложно закрепить в договоре. Reverse proxy + постоянный Gateway на выделенных хостах 24/7 (например арендованные облачные Mac на Apple Silicon или контролируемые VPS) превращают лимиты скорости, сертификаты и хранение логов в стандартные изменения. Стабильный вход нужен, чтобы связка OpenClaw с CI и конвейерами подписи была проверяема и передаваема.
Самостоятельный стек прокси тянет за собой CVE OpenSSL, Nginx и ОС; команды, долго связывающие OpenClaw с CI, подписью и мульти-канальными ботами, часто экономят суммарно за счёт предсказуемой выделенной мощности и ясных регионов/сроков аренды, а не домашних экспериментов. Облачные Mac MACCOME дают несколько регионов и понятные уровни аренды как чистую постоянную машину за завершением TLS: сначала закрепите каталоги и границы прав из гайда по установке на три платформы, затем разместите исполнение контрактно через цены аренды Mac mini и региональные страницы — Сингапур, Токио, Сеул, Гонконг, Вирджиния, Кремниевая долина — пока периметровый прокси несёт только политику и наблюдаемость.
Вопросы соединений, сессий и каналов ищите по ключевым словам в центре помощи; для визуального разбора сочетайте с материалами об удалённом рабочем столе и SSH/VNC.
Частые вопросы
502: сначала прокси или Docker?
curl loopback-апстрима с хоста прокси; если нет — к разбору Docker. Тарифы: цены аренды Mac mini.
Подпуть или поддомен?
Поддомены реже страдают от снятия префикса; подпуть требует одинаковых базовых URL. Установку сверяйте с гайдом по установке на три платформы.
WS рвётся за CDN?
Отключите кеш, удлините idle-таймаут или обходите CDN поддоменом управления. Каналы — разбор Slack/Discord/Telegram.
Логи и тикеты куда?
Корпоративные изменения — тикеты центра помощи, половину конфига Nginx не теряйте в прод-чате.