Инспектор трафика и кнопка Replay: Реактивный дебаг вебхуков в TunnelHunt

Делать тестовый платеж или отправлять форму заново, чтобы отладить вебхук? Забудьте. Рассказываем, как встроенная функция HTTP Replay в дашборде TunnelHunt ускоряет локальную разработку.

Отладка вебхуков — одна из самых раздражающих задач в современной веб-разработке. Вы настраиваете интеграцию с YooKassa, Stripe, Telegram или GitHub. Сторонняя платформа присылает события (вебхуки) на ваш бэкенд, когда происходит какое-то действие: совершена оплата, создан репозиторий, пришло сообщение.

Обычно отладка выглядит так:

Вы запускаете локальный сервер и туннель.
Инициируете событие (например, делаете тестовую покупку на сайте).
Вебхук прилетает, ваш код падает с ошибкой 500 из-за опечатки.
Вы исправляете ошибку в коде.
А теперь вам нужно повторить всё сначала: заполнить корзину, ввести тестовую карту, пройти 3D-Secure… и надеяться, что на этот раз код отработает.

Если ошибка сложная, этот цикл приходится повторять десятки раз. В этой статье мы расскажем, как TunnelHunt решает эту проблему с помощью встроенного логгера запросов и функции HTTP Replay.

🧐 Как устроен инспектор трафика TunnelHunt?

Каждый раз, когда внешний сервис делает запрос к вашему туннелю (например, https://my-app.tunnelhunt.ru/webhooks/stripe), запрос не просто пересылается на вашу локальную машину, но и фиксируется системой.

В дашборде TunnelHunt в реальном времени (через WebSockets) обновляется лента запросов:

Заголовки (Headers): Все системные заголовки, User-Agent, токены авторизации и специфичные заголовки платформ (например, сигнатуры X-Hub-Signature от GitHub).
Параметры (Query & Path): Все GET-параметры.
Тело запроса (Body): Полный JSON, XML или Form-Data payload, присланный внешним сервисом.
Ответ вашего сервера: Время обработки запроса и HTTP-статус, который вернул ваш локальный localhost (например, 200 OK, 400 Bad Request или 500 Internal Server Error).

Вы видите полную картину того, как ведет себя ваше приложение при получении внешних данных.

⚡ Киллер-фича: Что такое HTTP Replay?

Вместо того чтобы вручную симулировать новое событие во внешней системе, вы можете просто повторить уже полученный запрос.

В интерфейсе дашборда TunnelHunt рядом с каждым запросом есть кнопка Replay (Повторить). При нажатии на неё:

Панель управления (Next.js Dashboard) берет сохраненную копию оригинального запроса (метод, заголовки, тело).
Отправляет команду на Go-сервер через API.
Сервер дублирует этот запрос и направляет его по открытому SSH-каналу на ваш локальный порт.
Ваш локальный сервер обрабатывает запрос точно так же, как если бы его только что прислал Stripe или YooKassa.

Это сокращает время отладки одной ошибки с 5 минут до 2 секунд. Вы можете изменять код, нажимать одну кнопку в дашборде и сразу видеть, помогла ли правка.

[Внешний Webhook] ──(Один раз)──> [TunnelHunt Сервер] ──> [Логи в БД]
                                         │
                         (Клик Replay в Dashboard)
                                         │
                                         ▼
[Ваш localhost] <────────────────────────┘ (resend raw request)

🛠 Пример использования: Отладка авторизации по вебхуку

Давайте разберем практический кейс. Вы пишете обработчик вебхука для GitHub, который должен реагировать на создание нового Issue.

GitHub подписывает каждый запрос заголовком X-Hub-Signature-256, чтобы ваш сервер мог удостовериться, что запрос пришел именно от GitHub. Для проверки подписи используется HMAC-SHA256 хэш от тела запроса.

Если вы допустили ошибку в проверке подписи (например, забыли перевести секретный ключ в байты), ваш сервер вернет 401 Unauthorized.

Без TunnelHunt: Вам нужно каждый раз заходить на GitHub, создавать тестовое Issue в репозитории (или идти в настройки вебхуков репозитория и нажимать “Redeliver” в интерфейсе GitHub).

С TunnelHunt:

Вы видите первый упавший запрос с кодом 401 в дашборде.
Вносите исправление в функцию верификации подписи на локальном компьютере.
Нажимаете Replay прямо в интерфейсе TunnelHunt.
Запрос мгновенно отправляется повторно. Вы видите статус 200 OK в консоли локального сервера и в логах дашборда. Задача решена!

🏗 Как это устроено под капотом TunnelHunt?

Архитектура фичи состоит из взаимодействия трех компонентов:

Go SSH Server: Принимает HTTP-запрос от Nginx Edge Proxy. Перед отправкой запроса в SSH-канал клиента, Go-сервер сохраняет заголовки и тело запроса в базу данных PostgreSQL, а также отправляет метаданные в Redis для быстрого инкремента лимитов трафика.
Next.js Dashboard: По веб-сокету получает уведомление о новом запросе и отображает его в UI.
Replay Flow: При нажатии кнопки повтора, Dashboard отправляет POST-запрос на API, который инициирует повторную отправку запроса через внутренние сетевые каналы Go-сервера. Поскольку SSH-соединение с вашим локальным компьютером держится открытым, запрос мгновенно попадает на ваш локальный порт.

🎯 Заключение

TunnelHunt — это не просто инструмент для создания ссылок, а полноценная среда отладки (Developer Experience). Возможность инспектировать входящие запросы и повторять их в один клик превращает монотонный процесс интеграции сторонних API в быструю и приятную работу.

Попробуйте отладку вебхуков с помощью HTTP Replay на TunnelHunt.