OpenClaw Linux VPS 2026 | Webhook HTTP 202, Nginx/Caddy и health-пробы

Когда публичный вход к OpenClaw Gateway терминируется на маленьком Linux VPS, типичная цепочка выглядит так: TLS на краю → Nginx или Caddy → loopback-порт процесса шлюза. Со стороны всё «зелёное»: тело JSON доходит, подписи валидны, в логах шлюза событие принято. Но SaaS-платформа или корпоративный коннектор помечает доставку как ошибку, потому что в их спецификации успех — это только 200 OK (иногда ещё 204), а ваш стек честно отвечает 202 Accepted — семантически верно для асинхронного ACK, но несовместимо с жёстким клиентом. Разложите контекст по томам постоянства и health в 2026: OpenClaw — Fly.io против обычного Linux VPS в облаке: постоянные тома, публичный вход HTTPS, webhook каналов и health checks (матрица решений + воспроизводимый FAQ), а для соседней боли с подписью и 403 на callback см. 2026: OpenClaw в Slack на Linux VPS: токены бота, подписки на события, callback URL к шлюзу — воспроизводимая схема и поуровневый FAQ по 403 и повторам.

202

Accepted — корректно для очереди, но не для всех проверяющих SDK

curl -i

Минимальное воспроизведение до правок Nginx/Caddy

/health

Отдельный путь пробы, чтобы не путать с webhook

Почему «правильный» 202 ломает интеграцию

Многие HTTP-клиенты в B2B-коннекторах не читают RFC до конца: они сверяют код с белым списком {200} или ожидают непустое тело challenge. Шлюз же может отвечать 202, чтобы сразу освободить воркер и не держать удалённый таймаут. Вторая ловушка — двойной слой: сам процесс отдаёт 200, а прокси добавляет собственный статус при limit_req, буферизации или неудачном error_page. Сначала изолируйте, кто формирует статус: прямой запрос на loopback, затем тот же payload через публичный хост.

Воспроизведение за три шага

Зафиксируйте эталон без браузера: один и тот же POST должен давать идентичную строку статуса на loopback и снаружи.

Сравнение loopback и публичного края

# 1) Шлюз напрямую (подставьте порт из конфигурации OpenClaw)
curl -sS -o /dev/null -w '%{http_code}\n' -X POST http://127.0.0.1:PORT/webhook/example \
  -H 'Content-Type: application/json' -d '{"ping":true}'

# 2) Через TLS-домен (именно так видит внешняя система)
curl -sS -o /dev/null -w '%{http_code}\n' -X POST https://claw.example.com/webhook/example \
  -H 'Content-Type: application/json' -d '{"ping":true}'

# 3) Полные заголовки ответа (ищите лишний Server/Via)
curl -sS -D- -o /dev/null -X POST https://claw.example.com/webhook/example \
  -H 'Content-Type: application/json' -d '{}'

Если на 127.0.0.1 уже 202, а внешний мир должен видеть 200, меняйте либо политику ответа в приложении, либо край (см. матрицу ниже). Если локально 200, а снаружи 202, ищите второй upstream, кэш CDN или правило на границе.

Матрица решений: upstream, edge или маршрут

Симптом	Предпочтительное действие	Риск
Везде `202`, интегратор принимает только `200`	Согласовать «синхронный ACK» в настройках шлюза или патч upstream	Низкий: одна точка правды, нет магии в прокси
Нельзя трогать версию OpenClaw сейчас	Отдельный `location` / site block: терминировать webhook на лёгком адаптере, который возвращает `200` и асинхронно дергает loopback	Средний: следить за идемпотентностью и повторами доставки
Нужен быстрый hotfix только на краю	Caddy `handle_response` / событийный слой с явным переписыванием статуса для конкретного пути	Средний: обновления Caddy и порядок директив
Только Nginx без Lua/njs	Избегать «невидимых» костылей; вынести адаптер в отдельный процесс или маленький sidecar	Низкий при дисциплине, высокий при попытке «сломать» статус вслепую

Идемпотентность

Если edge начинает отвечать 200 раньше, чем шлюз реально обработал событие, при повторной доставке webhook вы должны корректно дедуплицировать по Idempotency-Key или штатному полю провайдера — иначе «зелёный» HTTP скроет бизнес-дубли.

Nginx и Caddy: где править статус

Caddy удобен тем, что рядом с reverse_proxy можно описать обработку ответа upstream и условно заменить код для одного пути, не трогая остальной трафик. Nginx «из коробки» не предназначен для произвольной подмены статус-кода ответа upstream без расширений; практичнее либо сменить ответ приложения, либо поставить тонкий адаптер перед шлюзом. В обоих случаях держите отдельный access_log с полем $upstream_status / эквивалентом, чтобы не спорить с мониторингом вслепую.

Health-пробы и webhook: не переключайте один URL

Классический сбой: балансировщик или systemd-чек бьёт в /, а единственный публичный маршрут отдаёт редирект на HTTPS или JSON с 401 — инфраструктура объявляет инстанс мёртвым и начинает дренаж, пока webhook ещё жив. Вынесите отдельный лёгкий эндпоинт (например /healthz) с коротким таймаутом и явным 200 без побочных эффектов. Webhook-путь пусть остаётся строгим: авторизация, размер тела, rate limit — всё это не должно выполняться на каждом tick проб health.

Краткий FAQ

Можно ли «просто» заменить 202 на 200 в Nginx одной директивой?

Без Lua/njs или внешнего адаптера — плохая идея: легко получить несогласованность заголовков и тела. Лучше исправить upstream или явный адаптер.

Почему curl показывает 200, а провайдер видит 202?

Разные пути (/hooks vs /hooks/), другой хост (www), промежуточный CDN или старый DNS TTL на второй IP.

Нужно ли менять health после правки webhook?

Да, перепроверьте: если проба случайно попала на тот же location, что и webhook, новый статус-код может сломать LB.

Документируйте контракт

Зафиксируйте в runbook для команды: ожидаемый код ответа webhook, допустимые повторы, таймаут провайдера и отдельный URL health — это снимает половину ночных эскалаций.