Локальный webhook-debug без боли: что ставить вместо «почему не приходит»

Локальный webhook-debug без боли: что ставить вместо «почему не приходит»

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

ngrok удобен как быстрый прокси: поднял туннель, получил внешний адрес, смотрим в тело запроса. Но у него есть слабые места: нестабильный URL, ручной перезапуск, слабый контроль над буферизацией и ретраями. Для разовой проверки ок, для нормального пайплайна — уже хрупко.

Hookdeck и аналоги полезны там, где нужен буфер, повторная доставка, фильтрация и сохранение событий. Это уже не «проброс порта», а маленькая шина: принял POST, записал сырой payload, дал повторно отправить в локалку, пометил delivery status. Когда внешний сервис шлёт мусор или 5xx на ровном месте, такой слой спасает часы дебага 🔧

Если совсем без внешних SaaS: Tailscale, Cloudflare Tunnel, localtunnel, frp, ssh -R. Но правило одно — не гоняйте вебхук прямо в бизнес-логику. Сначала приёмник с ответом 200, потом очередь, потом воркер. Логи храните целиком: headers, body, signature, request_id.

Проверяйте сигнатуру, режьте таймауты, фиксируйте payload до парсинга. Тогда локальная отладка перестаёт быть шаманством, а превращается в повторяемый сценарий.