Анализ HTTP-трафика в DevProxy: запросы, ответы и вебхуки

Вебхук отправлен, но приложение не сработало. Или сайт открывается по внешней ссылке, а API отвечает ошибкой. В локальной панели DevProxy можно найти пришедший HTTP-запрос и посмотреть, что ответило приложение: статус, заголовки, тело и время ответа. Для этого не нужно добавлять журналирование в свой обработчик.

Панель работает на компьютере с клиентом. Откройте адрес из его консоли, обычно http://127.0.0.1:4040, и выберите HTTP traffic. Это отдельная страница от кабинета на сайте. Ниже описан клиент 1.0.11; названия элементов монитора пока на английском.

На снимках ниже настоящая локальная панель клиента 1.0.11. События принимает отдельный локальный тестовый обработчик; аккаунты внешних сервисов для примера не используются.

Подготовьте HTTP-канал

Нужны клиент DevProxy, ключ с вариантом «Сайт или API» и работающий локальный сайт или обработчик вебхуков. Если клиент ещё не настроен, начните с инструкции первого запуска.

Например, приложение открывается по адресу http://127.0.0.1:3000. Для нового отдельного файла настроек подойдёт такой YAML:

server: https://control.devtunnels.ru
token: ВАШ_КЛЮЧ
reconnect: true

tunnels:
  - kind: http
    name: inspect-demo
    local: http://127.0.0.1:3000

Вставьте свой ключ и настоящий адрес приложения. Если в файле уже есть другие каналы, сохраните их и добавьте только нужный HTTP-канал. Не создавайте второй канал, если этот сайт уже подключён.

Для ZIP Windows откройте PowerShell в распакованной папке и выполните .\devproxy.exe start. Для архива Linux/macOS используйте ./devproxy start. После установки в PATH подойдёт devproxy start. Для отдельного файла добавьте --file "полный путь к файлу".

Откройте локальную панель. В клиенте 1.0.11 защита входа включается по желанию в настройках. Если она включена, получите одноразовый код на этом же компьютере от пользователя клиента: .\devproxy.exe panel code, ./devproxy panel code или devproxy panel code, в зависимости от установки. При нескольких клиентах выберите нужный через --instance <PID>. Используйте фактический адрес панели: если порт занят, он может отличаться.

Найдите запрос и ответ

Скопируйте внешний HTTPS-адрес канала из раздела «Туннели» в кабинете и откройте его. Для вебхука отправьте событие из своего тестового сервиса. Прямой запрос к localhost обходит туннель и в этот список не попадёт.

На вкладке HTTP traffic запросы появляются в списке слева. Service показывает канал, Method метод GET или POST, Path путь запроса, Status код ответа. В примере проверка состояния и вебхук получили ответ 200, а обращение по неверному пути вернуло 404.

Выберите канал в списке All services, оставьте нужный метод, например POST, и найдите путь через Search requests. Нажмите строку POST /webhook/preview, чтобы открыть подробности справа:

• Request headers и Request body показывают заголовки и тело входящего запроса.
• Response headers и Response body показывают ответ приложения.
• Статус и длительность помогают отличить отказ обработчика от медленного ответа.

В Request body видно тестовое событие с event_id: demo-001 и сообщением. В Response body обработчик вернул received: true и handled_count: 1. Эти поля принадлежат тестовому приложению; DevProxy показывает его ответ, а не добавляет их сам.

Кнопка Beautify рядом с каждым телом форматирует JSON, как на снимке выше. Для вебхука сравните путь, тип содержимого и поля события с тем, что ожидает обработчик. Ответ 401 или 403 обычно означает отказ в доступе; 404 помогает заметить неверный путь. Ответ 200 подтверждает HTTP-ответ, но сам по себе не доказывает выполнение бизнес-действия: проверьте результат в приложении.

Повторите запрос после исправления

Кнопка Replay отправляет записанный запрос прямо в локальное приложение. Это удобно на тестовом обработчике: исправили код, повторили запрос и прочитали новый ответ рядом с исходным. Повтор не обращается к отправителю вебхука и не проверяет весь путь через внешний адрес.

Новый ответ появляется в блоке Replay response 200 над исходным обменом. Теперь в нём handled_count: 2: обработчик получил то же событие ещё раз. Ответ первого запроса остаётся ниже.

Replay действительно вызывает обработчик ещё раз. Если он создаёт заказ, отправляет письмо или меняет данные, действие может повториться. Используйте тестовые события и учитывайте защиту приложения от повторной обработки. Запрос с обрезанным телом повторить нельзя.

Сохраните историю и учитывайте её пределы

Export HAR сохраняет текущую историю HTTP-обменов в файл. Clear history очищает её. История относится к текущему запуску клиента, поэтому сохраните нужное до его остановки. HAR, заголовки и тела могут содержать cookies, секреты вебхуков и данные пользователей; перед передачей удалите эти значения.

Монитор хранит до 1000 последних записей. Для каждого тела запроса и ответа сохраняется до 256 КиБ; превышение отмечается как обрезка. Запросы к файлам с рядом расширений, например .js, .css и изображениям, пропускаются. Это не полный архив всех обращений к сайту.

Здесь показаны HTTP-обмены через этот клиент. Монитор не расшифровывает произвольный TCP-трафик, RDP и сообщения внутри WebSocket после перехода на этот протокол.

Если записи не появились

• Откройте панель именно того клиента, который обслуживает канал. Панель другого компьютера не покажет его историю.
• Проверьте, что канал запущен, и обратитесь к внешнему адресу, а не напрямую к локальному приложению.
• Сбросьте поиск и фильтры методов, выберите All services. Для проверки используйте страницу или путь API без расширения статического файла.
• При ошибке 502 проверьте, открывается ли адрес из local на компьютере клиента. Отсутствие записи не доказывает, что отправитель ничего не отправлял: запрос мог быть отклонён раньше.

Для конкретной доставки продолжите по инструкциям GitHub, Telegram или n8n. Монитор помогает разобрать HTTP-запрос, а журнал отправителя показывает, когда и с каким результатом тот пытался его доставить.