Проверка чужого API часто начинается с прокси — исходящий маршрут настраивают быстро и без вопросов. Дальше приходит вебхук от того же поставщика — обратный вызов о том, что заказ оплачен, номер получил SMS или задача завершена, — и данные просто не доходят. Разберём, почему прокси тут ни при чём, откуда берётся разрыв и как выстроить приём обратных вызовов так, чтобы он не зависел от исходящего канала.

Прокси меняет исходящий маршрут, а не открывает вход

Прокси-сервер стоит между вашим клиентом и удалённым API только на исходящем плече: вы инициируете соединение, он подменяет обратный адрес и IP, с которого виден запрос. Всё, что происходит дальше, — ответ на уже открытое вами соединение. Вебхук устроен наоборот: инициатором выступает поставщик, а не вы. Он открывает новое соединение к URL, который вы заранее зарегистрировали в кабинете или в параметрах запроса, и это соединение никак не связано с тем каналом, через который вы недавно ходили к его API.

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

Почему обратный вызов не доходит

Причин у пропавшего вебхука немного, и все они на стороне приёмника, а не отправителя. Машина находится за NAT домашнего или офисного роутера без проброшенного порта — снаружи её адреса просто не существует. Локальный адрес разработки не резолвится из интернета в принципе. Зарегистрированный URL указывает на внутренний хост, видимый только из корпоративной сети. Сертификат TLS просрочен или выпущен для другого домена, и рукопожатие обрывается до передачи тела запроса. Сервер отвечает кодом, отличным от 2xx, — большинство поставщиков после нескольких неудачных попыток прекращают повторную доставку.

Отдельная причина — allowlist у самого поставщика: инфраструктура сменилась, запись не обновили, и вызовы глохнут тихо, без ошибки в интерфейсе.

Как правильно принимать обратные вызовы

Приёмник обратных вызовов должен быть публично доступным адресом с открытым портом и действующим TLS-сертификатом — доменом или IP, до которого поставщик может достучаться напрямую, без прокси и туннелей с вашей стороны. Это требование не пересекается с тем, каким каналом вы пользуетесь для исходящих запросов к тому же API.

Правильная архитектура приёма разделяет две задачи: быстро подтвердить получение и не спеша обработать данные. На входе — лёгкий обработчик, который сохраняет сырое тело запроса в очередь и сразу отвечает 200, не дожидаясь бизнес-логики. Обработка идёт асинхронно, из очереди, отдельным процессом. Это защищает от таймаутов на стороне поставщика: если полезная обработка занимает секунды, а лимит ответа — доли секунды, синхронная схема рано или поздно начнёт терять события при любой просадке.

Если публичный адрес завести нельзя — закрытый контур, тестовый стенд, временная среда без домена, — используйте поллинг вместо push: большинство таких API дают параллельный эндпоинт для запроса статуса или списка событий. Опрашивайте его по расписанию. Задержка получения события вырастет с секунд до интервала опроса, зато требование к публичной доступности снимается полностью.

Проверка доставки

Проверку ведут по двум независимым логам, а не по одному. Первый — журнал доставки в кабинете поставщика: там видны попытки, коды ответа и тайминги. Второй — лог собственного приёмника: факт, что запрос физически дошёл до вашего кода, а не был перехвачен балансировщиком или CDN, ответившим 200 самостоятельно, без передачи тела дальше. Статус «доставлено» в чужом интерфейсе без встречной записи в своей очереди — сигнал разрыва где-то посередине, а не повод считать интеграцию рабочей.

Стоит проверить и подпись: если вебхук подписан HMAC-ключом, а секрет устарел после ротации, сервер молча отклонит валидные события как поддельные — снаружи это выглядит как «не приходит».

Где здесь всё же нужен прокси

Он остаётся полезен на исходящем плече этой же связки. Если вы перешли на поллинг вместо push, каждый опрос — исходящий запрос к API, и его можно распределять так же, как любой другой трафик к чужому серверу: по гео, по частоте, с ротацией адреса при рейт-лимите. Ещё один сценарий — сверка того, что видит сама площадка со стороны нужной страны: если обратный вызов зависит от гео-специфичной логики поставщика, проверить её удобнее из подходящего гео, а не из адреса дата-центра по умолчанию.

Частые вопросы

Можно ли принимать вебхуки через прокси-сервер?

Поставщик должен достучаться до вашего приёмника напрямую, и канал, которым вы пользуетесь для исходящих запросов, в этой цепочке не участвует. Если нужно скрыть реальный адрес сервера, перед ним ставят обратный прокси — это другая роль, не путайте её с исходящим прокси для клиентских запросов к чужому API.

Почему в кабинете поставщика написано «доставлено», а данных нет?

Статус «доставлено» означает, что провайдер получил ответ 2xx с вашего адреса — ответить мог балансировщик, CDN или другой сервис на том же домене, не передав тело дальше в очередь. Сверяйте лог поставщика с логом собственного приёмника, а не полагайтесь только на статус в чужом интерфейсе.

Что делать, если публичный адрес завести нельзя?

Переходите на поллинг: опрашивайте эндпоинт статуса по расписанию вместо ожидания push-уведомления. Задержка получения события вырастет, зато требование к публичной доступности машины снимается полностью.

Для исходящей части связки — опроса API поставщика или проверки логики со стороны нужной страны — подходит выделенный или ротируемый канал из каталога прокси. Настройка — в статье ротация IP по API, метрики канала — в материале как проверить качество прокси.