Wireshark displays network packets and helps investigate problems below the level of a user-facing HTTP response. When a request does not arrive, a connection drops, or a delay occurs before the application responds, packet capture provides another layer of evidence. It is a measurement tool, rather than an automatic explanation for every network failure.
Unlike an HTTP proxy, Wireshark typically observes exchanges on a selected interface without replacing application responses. This helps QA investigate DNS, TCP, TLS, and other protocols. Its usefulness depends on the observation point: one computer cannot see every event between client and server.
Formulate a question first
Useful questions include: Was a DNS query sent? Was a TCP connection established? Did the TLS handshake begin? Who closed the connection? “Why is the site slow?” is too broad for an initial capture. First distinguish networking from server wait time and interface processing.
Identify the client, server, approximate action time, and known address. Agree on observing your own test traffic. Capturing an entire corporate interface for one defect usually creates excessive data and obstructs analysis. A small reproduction with a known sequence produces clearer results.
Choosing an interface
Relevant traffic may use Wi-Fi, Ethernet, a VPN, or loopback. Seeing no packets on one interface does not confirm that no request occurred. Check routing and interface activity with a control request before starting the main experiment.
The capture point affects visible addresses, encapsulation, and flow direction. NAT, VPNs, and load balancers may alter how a connection appears. Record where the capture was made; otherwise, a colleague cannot explain why the expected server address is absent or different.
Capture filters and display filters
A capture filter limits which packets are saved during capture and uses libpcap syntax. Here is an example for your own test server using TCP on port 443:
host 192.0.2.10 and tcp port 443A display filter applies to existing data and controls what is shown. It cannot recover packets excluded during capture, and it uses different syntax. For the same selection in a saved capture:
ip.addr == 192.0.2.10 && tcp.port == 443192.0.2.10 is an illustrative address. A TCP/443 filter does not cover every possible form of HTTPS traffic: another transport or port needs a different condition. An overly narrow capture filter can exclude DNS and other events needed for investigation.
DNS and connection establishment
Check whether name resolution was needed and which response the client received. Absence of a conventional DNS packet does not prove that resolution did not occur: caching, encrypted DNS, or another routing point may be involved. Consider this limitation before concluding that something failed.
For TCP, inspect the connection attempt and both sides' responses. Repeated SYN packets without a response at the capture point indicate that handshake completion was not observed. They do not locate the loss: the cause may involve routing, filtering, the server, or the capture itself.
What TLS reveals
TLS protects exchange content. Without suitable secrets, recording packets does not let Wireshark turn HTTPS into readable JSON. You can analyze available handshake details, sizes, timing, and connection closure; exact visibility depends on the protocol and configuration.
For your own test client, a supported key log mechanism and appropriate Wireshark settings may be available. This is a separate, controlled process, with restricted storage of session secrets and captures. A proxy root certificate does not replace those secrets, and a server private key does not automatically decrypt modern sessions using forward secrecy.
Retransmissions, loss, and observation limits
The tcp.analysis.retransmission filter helps find packets the analyzer classifies as retransmissions. This is an investigative clue rather than definitive proof of a poor network. Incomplete recording, packet loss during capture, and hardware processing can affect interpretation.
Inspect sequence, acknowledgments, and timing intervals in the context of the flow. A checksum error in a local capture does not always mean corrupted data was transmitted: checksum calculation may have been offloaded to the network adapter. Correlate observations with logs and, if needed, another agreed measurement point.
Practical example: a download never starts
Your application should download a test document, but clicking the button produces a long wait followed by a timeout. DevTools shows no complete HTTP response. Prepare one small file and identical actions for successful and unsuccessful attempts.
- 1.Record the click time and start a limited capture on the appropriate interface before the action. The network flow should be traceable to the specific attempt.
- 2.Check name resolution and the connection attempt. If the connection was not established, investigate that layer rather than describing the problem as “the API returned an error.”
- 3.If TCP was established, examine TLS and flow closure. Record the observed event and which side sent any visible failure signal.
- 4.Compare a successful attempt using the same build and file. Identify the first stage that differs, beyond the difference in total duration.
Test the user experience separately: after a timeout, the interface should explain the situation and permit an appropriate retry. Packet analysis alone does not confirm that behavior.
Presenting evidence
Include the interface, capture point, time, filter, addresses, and relevant stream number in the report. Attach a minimal excerpt explaining what was observed, what the capture does not establish, and what additional observation is needed. This is more useful than an unlabeled screenshot of red rows.
A PCAP can contain sensitive data even without readable HTTP: addresses, names, and connection metadata. Share it through an agreed channel with restricted access. Adding TLS secrets substantially expands what the recipient can read.
Mistakes and useful conclusions
Common mistakes include confusing the two filter languages, capturing the wrong interface, expecting plaintext from any TLS connection, and declaring a retransmission the definitive cause. Another is treating an absent packet as proof that an event never happened without checking capture quality and scope.
Wireshark's useful outcome is an isolated network stage and reproducible facts with clear limitations. These guide the next step: client configuration, routing, TLS, server logs, or investigation of the application itself.