2026-06-02

Анализ PCAP тайм-аута HTTP-шлюзов 502 и 504: прокси-сервер, балансировщик нагрузки, восходящий поток или сеть?

Как диагностировать плохой шлюз HTTP 502 и тайм-аут шлюза 504 с помощью перехвата пакетов, включая TCP от прокси-сервера к восходящему потоку, TLS, время запроса, сброс серверной части и задержку ответов.

Ошибки HTTP «502 Bad Gateway» и «504 Gateway Timeout» являются симптомами прокси-уровня. Браузер или API-клиент видит ответ прокси-сервера, но реальная проблема может заключаться между прокси-сервером и вышестоящим сервером, внутри вышестоящего приложения, в согласовании TLS, в доступности TCP или в политике тайм-аута. Когда журналов недостаточно, пользователи ищут «анализ 502 pcap», «захват пакетов по тайм-ауту шлюза 504», «сброс исходящего прокси-сервера», «тайм-аут балансировщика нагрузки Wireshark» и «устранение неполадок сети с плохим шлюзом».

PCAP Surgery полезен, поскольку при сбоях прокси-сервера, если возможно, требуется история пакетов с обеих сторон: от клиента к прокси и от прокси к восходящему потоку.

Что обычно означает 502

«502 Bad Gateway» обычно означает, что прокси-сервер получил неверный, неполный или неудачный ответ от восходящего сервера. Причины включают в себя:

Сброс восходящего TCP.
Ошибка подтверждения TLS восходящего потока.
Восходящее соединение закрыто раньше времени.
Прокси-сервер подключен к неправильному порту.
Серверная часть вернула неверный HTTP-код.
Балансировщик нагрузки не имел исправного восходящего потока.
Несоответствие протокола, например ожидается HTTPS, но HTTP отправлен.

Клиент видит только 502 прокси-сервера. Трассировка пакетов может показать, что произошло в восходящем направлении.

Что обычно означает 504

«504 Gateway Timeout» обычно означает, что прокси-сервер переслал запрос, но не получил полного ответа восходящего потока до истечения его истечения.

Причины включают в себя:

Вышестоящее приложение работает медленно.
TCP-соединение с восходящими стойлами.
Сервер принимает соединение, но никогда не отвечает.
Большой ответ заблокирован из-за MTU или потери пакетов.
Задержка базы данных или зависимости позади восходящего потока.
Тайм-аут прокси-сервера слишком мал.
Тайм-аут простоя брандмауэра или NAT.

Ключевым доказательством является время: когда прокси-сервер отправил восходящий запрос и когда он отказался.

Захват размещения

Лучшие доказательства получены из:

Клиентская сторона: видит финальные 502/504.
Клиентский интерфейс на стороне прокси.
Восходящий интерфейс на стороне прокси.
Вышестоящая серверная часть.

Если вы захватываете только на клиенте, вы можете доказать, что прокси вернул 502/504, но не почему. Если вы захватываете прокси-сервер, вы можете проверить поведение восходящего потока.

TCP и TLS перед HTTP

Перед диагностикой HTTP проверьте:

Прокси-сервер установил TCP для восходящего потока?
Завершено ли установление связи TLS?
Соответствовал ли SNI ожиданиям восходящего потока?
Выполнен ли сброс восходящего потока?
Пакеты пересылались повторно?

В случае сбоя TCP или TLS статус HTTP может быть только трансляцией прокси-сервером сбоя нижнего уровня.

Запрос отправлен, ответа нет.

Для 504 ищите:

Proxy -> Upstream: HTTP request
No upstream response for timeout interval
Proxy -> Client: HTTP/1.1 504 Gateway Timeout

Checklist

Use this workflow:

Final diagnosis

Пакетный ответ для «Анализ PCAP тайм-аута HTTP-шлюзов 502 и 504: прокси-сервер, балансировщик нагрузки, восходящий поток или сеть?»

Краткий ответ: label анализатора или сообщение приложения не определяет причину. Начните с точки захвата и направления, докажите последнюю успешную protocol boundary и первую неудачную. Для «Анализ PCAP тайм-аута HTTP-шлюзов 502 и 504: прокси-сервер, балансировщик нагрузки, восходящий поток или сеть?» другой reviewer должен найти packet, gap или interval, поддерживающий каждую фразу, и понять, какой факт её опровергнет.

Разместите capture на карте пути

Запишите client, server и все proxy, load balancer, NAT или firewall. Укажите interface, место, clock, OS и видимые направления. Capture у client доказывает приход туда, но не отсутствие отправки server. Capture у server доказывает выход в этой точке, но не весь путь. Перед сравнением двух точек исправьте clock offset и сопоставьте flow tuple, TCP sequence или transaction ID.

Проверьте snap length, dropped packets, offload, capture filter, ring buffer и время старта. Bad checksum на host может быть offload artifact. Большой segment может быть результатом GRO/TSO и не существовать так на проводе. Отсутствие packet в ограниченном файле не является network loss, пока не доказано, что точка обязана была его видеть.

Читайте границы по порядку

Граница	Успешный признак	Полезный признак отказа
Link/IP	direction, addresses и route согласованы	нет ARP/NDP, ICMP, MTU, asymmetry
TCP	SYN, SYN-ACK, ACK и sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello и прогресс	alert или SNI/ALPN/certificate boundary
Application	полный request и связанный response	status, gap или ранний close
User	response time или failure window	stall на доказанной границе

Остановитесь на первой границе без успеха. Если TCP не завершён, не начинайте с HTTP. Если request пришёл на proxy, но отсутствует на upstream, граница внутри proxy или его пути. Если upstream получил запрос без response до timeout, ACK и продвижение bytes отделяют application delay от network loss.

Отделите observation от hypothesis

Observation можно указать: «Client отправил до определённой sequence, sender повторил segment трижды, а в этой точке не появилось продвигающего ACK». Hypothesis: «путь потерял segment». Другая точка или dropped records могут её опровергнуть. Для каждой гипотезы запишите подтверждающий и опровергающий факт.

Retransmission и duplicate ACK не назначают виновного. Reordering, loss, capture artifact и receiver delay дают похожие labels. Свяжите direction, sequence, ACK, SACK, RTT, window и application timing. Для DNS/DHCP сопоставляйте transaction ID и attempts; для HTTP request/response; для TLS направление handshake.

Сохраните original

Рассчитайте checksum и не изменяйте оригинал. Filter, trim и redaction выполняются над working copy. Запишите input, operation, время, packet count до/после, output checksum и причину. После timestamp rewrite или удаления packets копия не поддерживает часть выводов о timing и sequence.

Addresses и identifiers заменяйте устойчивыми aliases. Не удаляйте port, direction и length, если они нужны выводу. Secret mapping держите отдельно. Проверьте границы capture и export и обзор PCAP Surgery.

QA перед публикацией

Title и answer относятся к одному flow? Каждая duration называет clock и точки? Первая failure boundary определена? Есть alternative explanation? Повтор меняет одну переменную? Original сохранён? Ограничьте итог: «Файл доказывает поведение около client в этом interval, но не внутреннее выполнение server».

Проверенный Semrush-термин PCAP analyzer принадлежит только странице продукта. Техническая статья не получает выдуманный volume или KD.

Flow ledger и исключающий тест

Для «Анализ PCAP тайм-аута HTTP-шлюзов 502 и 504: прокси-сервер, балансировщик нагрузки, восходящий поток или сеть?» создайте строку по каждому направлению: endpoint aliases, первый/последний packet, отправленные и подтверждённые bytes, resets, retransmissions, requests и responses. Одинаковый hostname не объединяет соединения; source port, время старта и TCP initial sequence разделяют sessions. Для NAT/proxy запишите связь flows, не ожидая одинаковых sequence и ports.

Считайте TCP, а не labels

Следите за next expected sequence receiver. Payload сдвигает sequence на длину; SYN и FIN также занимают номер. Стабильный Duplicate ACK после более высоких segments поддерживает loss или reordering. SACK blocks показывают пришедшие ranges, но не место потери. Retransmission у sender без появления у receiver требует проверки пути; отсутствие original уже в sender capture требует проверки capture loss или offload.

Отделяйте fast retransmit после duplicate ACKs от RTO после тишины. Сравните предыдущий RTT, advertised window, zero-window probes, burst и размер transfer. Overlap, spurious retransmission и capture с середины flow меняют label, поэтому число labels не равно числу потерь.

Измеряйте время по границам

Используйте request first byte, request complete, response first byte и response complete. TTFB не равен server time автоматически. Retransmission до response может добавить network delay; полностью подтверждённый request и долгая тишина поддерживают application wait. Укажите значение, unit, clock и point.

Для двух точек совместите характерный packet в обоих направлениях, оцените offset и используйте intervals внутри файлов. При неизвестном clock дайте range. Сравнивайте успешные и неудачные windows одинаковой длительности и нагрузки.

Вопросы протокола

DNS: совпадают ID, name и type, меняет ли retry resolver/source port? DHCP: относятся ли Discover/Offer/Request/ACK к одному client identifier? TLS: последнее handshake message каждого направления и alert. HTTP: кто создал 4xx/5xx и есть ли upstream flow? TCP close: кто отправил FIN/RST и какие bytes не подтверждены?

Решающий тест и передача

Выберите две гипотезы и один разделяющий тест. Capture у другого конца разделяет network loss и measurement loss; выключение offload в тесте проверяет artifact; одинаковый request на фиксированном path — intermittency; upstream log против packet boundary — application delay. Запишите ожидания заранее.

Reviewer должен повторить расчёт по metadata, найти ту же границу и назвать ограничение. Передайте original/derived checksums, filter, packet ranges и операции trim/redaction. Закончите owner, действием и измеримым условием закрытия.

Проверка воспроизводимости

Откройте новую connection и повторите сценарий трижды с одинаковыми inputs и filters. Ports и initial sequence могут меняться, но boundary, direction и response pattern должны повторяться. Запишите успехи и отказы. Исправление меняет одну переменную; после него должно измениться ожидаемое packet behavior, а не только исчезнуть сообщение.

Откройте derived copy на другом компьютере. Reviewer находит flow aliases, clock, capture point, последний успех, первый отказ и alternative. После redaction снова ищите hostname, query, header и чувствительный payload, сохраняя нужные length и direction. Перечислите непроверенное: обратное направление, IPv6, reconnect, другая load.

Итог: доказано в указанном объёме, всё ещё воспроизводится или открыто из-за конкретного capture. Не пишите «сеть исправлена», если проверен один flow.

Противоположный контроль и доверие

До закрытия «{{TITLE}}» запишите противоположный прогноз. Если причина в network path, какой pattern должен быть виден в двух точках после переноса capture? Если это server delay, останутся ли request bytes подтверждёнными при отсутствии response? Ожидания до теста предотвращают подгонку объяснения после результата.

Свяжите confidence с доказательствами. High требует повторения и двух точек либо независимого подтверждения; medium — полного capture с непроверенной alternative; low — только label или примерного timing. Confidence не превращает hypothesis в fact, но задаёт next action.

Для медленного или intermittent failure измеряйте дольше обычного интервала. Сравнивайте rates: retransmissions на мегабайт, failures на connection и latency percentiles при сходной load. Запишите idle, reconnect, DNS cache и TLS session reuse, так как они меняют второй запуск.

Передайте flow table, timeline из пяти событий, first difference, exclusion test, fix result и untested scope. Packet numbers относятся к derived copy, а time map возвращает к original. Получатель должен повторить verdict без secrets и без session автора.