Wireshark показывает сетевые пакеты и помогает исследовать проблемы ниже уровня пользовательского HTTP-ответа. Когда запрос не доходит, соединение разрывается или задержка возникает до ответа приложения, packet capture позволяет увидеть дополнительный слой фактов. Это измерительный инструмент, а не автоматический объяснитель причины любого сетевого сбоя.
В отличие от HTTP-прокси Wireshark обычно наблюдает обмен на выбранном интерфейсе, не подменяя ответы приложения. Для QA это полезно при расследовании DNS, TCP, TLS и других протоколов. Но полезность зависит от точки наблюдения: на одном компьютере не видно все события, происходящие между клиентом и сервером.
Сначала сформулируйте вопрос
Примеры хороших вопросов: отправился ли DNS-запрос, установилось ли TCP-соединение, начался ли TLS-handshake, кто закрыл соединение? Вопрос «почему сайт медленный» слишком широк для первого захвата. Сначала отделите сеть от ожидания сервера и обработки интерфейса.
Определите клиент, сервер, примерное время действия и известный адрес. Согласуйте наблюдение собственного тестового трафика. Запись всего корпоративного интерфейса ради одного дефекта обычно создаёт много лишних данных и мешает анализу. Небольшое воспроизведение с известной последовательностью даёт более понятный результат.
Как выбрать интерфейс
Нужный трафик может идти через Wi-Fi, Ethernet, VPN или loopback. Отсутствие пакетов на одном интерфейсе ещё не подтверждает отсутствие запроса. Проверьте маршрут и активность интерфейса на контрольном обращении, затем начинайте основной эксперимент.
Точка захвата влияет на видимые адреса, инкапсуляцию и направление потока. NAT, VPN и балансировщик могут изменить представление соединения. Зафиксируйте, где сделана запись, иначе коллега не сможет объяснить, почему ожидаемый адрес сервера в ней отсутствует или выглядит иначе.
Capture filter и display filter
Capture filter ограничивает, какие пакеты сохраняются при захвате. Для него используется синтаксис libpcap. Пример для собственного тестового сервера по TCP на 443:
host 192.0.2.10 and tcp port 443Display filter применяется к уже имеющимся данным и управляет отображением, не возвращая пакеты, исключённые при захвате. Он имеет другой синтаксис. Для той же выборки в сохранённой записи:
ip.addr == 192.0.2.10 && tcp.port == 443Адрес 192.0.2.10 здесь иллюстративный. Фильтр TCP/443 не охватывает весь возможный HTTPS-трафик: например, другой транспорт или порт требуют другого условия. Слишком узкий capture filter способен исключить DNS и другие события, необходимые для расследования.
DNS и начало соединения
Посмотрите, потребовалось ли разрешение имени и какой ответ получил клиент. Отсутствие обычного DNS-пакета не доказывает отсутствие разрешения: возможен кэш, зашифрованный DNS или другая точка маршрута. Это ограничение нужно учитывать перед выводом о неисправности.
Для TCP проверьте попытку установления соединения и ответы сторон. Повторяющиеся SYN без ответа с точки захвата указывают, что завершение handshake не наблюдалось. Это ещё не определяет место потери: причина может находиться на маршруте, фильтрации, сервере или в особенностях самой записи.
Что видно в TLS
TLS защищает содержимое обмена. Без подходящих секретов Wireshark не превращает HTTPS в читаемый JSON просто потому, что пакеты записаны. Можно анализировать доступные признаки handshake, размеры, тайминги и закрытие соединения; конкретная видимость зависит от протокола и конфигурации.
Для собственного тестового клиента иногда используют поддерживаемый механизм key log и соответствующие настройки Wireshark. Это отдельный контролируемый процесс: секреты сессии и запись хранят ограниченно. Корневой сертификат прокси не заменяет такие секреты, а закрытый ключ сервера не расшифровывает автоматически современные сеансы с прямой секретностью.
Повторы, потери и ограничения наблюдения
Фильтр tcp.analysis.retransmission помогает найти пакеты, которые анализатор классифицирует как повторные передачи. Это подсказка для расследования, а не безусловное доказательство плохой сети. Неполная запись, потеря пакетов самим захватом и особенности аппаратной обработки могут влиять на интерпретацию.
Смотрите последовательность, подтверждения и временные интервалы в контексте потока. Ошибка checksum в локальном захвате тоже не всегда означает отправку повреждённых данных: вычисление могло быть передано сетевой карте. Сопоставляйте наблюдение с логами и, при необходимости, другой согласованной точкой измерения.
Практический пример: загрузка не начинается
Собственное приложение должно скачать тестовый документ, но после нажатия кнопки долго ждёт и показывает timeout. В DevTools нет полноценного HTTP-ответа. Подготовьте один небольшой файл и одинаковые действия для успешной и неуспешной попытки.
- 1.Зафиксируйте время нажатия и начните ограниченный захват на нужном интерфейсе до действия. Ожидается возможность связать сетевой поток с конкретной попыткой.
- 2.Проверьте разрешение имени и попытку соединения. Если соединение не установилось, исследуйте этот слой, не описывая проблему как «API вернул ошибку».
- 3.Если TCP установлен, изучите TLS и закрытие потока. Зафиксируйте наблюдаемое событие и сторону, отправившую доступный сигнал отказа.
- 4.Сравните успешную попытку с той же сборкой и файлом. Ожидается выявление первого различающегося этапа, а не только разницы общего времени.
Пользовательское ожидание проверяют отдельно: после timeout интерфейс должен объяснить ситуацию и позволить допустимый повтор. Сам анализ пакетов не подтверждает корректность этого поведения.
Как оформить доказательство
В отчёте укажите интерфейс, точку записи, время, фильтр, адреса и номер значимого потока. Приложите минимальный фрагмент с объяснением: что наблюдалось, чего запись не подтверждает и какое дополнительное наблюдение требуется. Это полезнее неподписанного скриншота красных строк.
PCAP может содержать чувствительные данные даже без читаемого HTTP: адреса, имена и метаданные соединений. Передавайте его по согласованному каналу с ограниченным доступом. Добавление TLS-секретов существенно расширяет содержимое, которое сможет прочитать получатель.
Ошибки и полезные выводы
Частые ошибки — путать два языка фильтров, записывать неправильный интерфейс, ожидать plaintext из любого TLS и объявлять повторную передачу окончательной причиной. Ещё одна ошибка — считать отсутствие пакета доказательством отсутствия события, не проверив качество и границы захвата.
Полезный результат Wireshark — локализованный сетевой этап и воспроизводимые факты с понятными ограничениями. Они помогают выбрать следующий шаг: настройка клиента, маршрут, TLS, серверные логи или исследование самого приложения.