How to Read Wireshark Captures: 10 Filters Every Engineer Needs

By Stackvora Team · 2026-08-12 · 9 min read

Wireshark is the most powerful troubleshooting tool most engineers barely use, because a raw capture is overwhelming. The fix is method: capture narrowly, then apply a fixed sequence of display filters that answer specific questions.

Capture narrowly, filter widely

Capture filters (BPF syntax) reduce what is written to disk; display filters reduce what you see. Use a capture filter to keep files manageable:

host 10.0.5.20 and not port 22
tcp port 443 and host 10.0.5.20
vlan and not broadcast

Then work in display filters, which are far more expressive and can be changed without recapturing.

The ten filters

1. Everything wrong, at a glance

tcp.analysis.flags

Retransmissions, duplicate ACKs, zero windows and out-of-order segments in one view. Start here.

2. Retransmissions only

tcp.analysis.retransmission || tcp.analysis.fast_retransmission

A few are normal. Sustained retransmissions on one path point at packet loss; on one host, at a NIC, driver or offload problem.

3. Connection resets

tcp.flags.reset == 1

Who sends the RST tells you who refused: a firewall in the middle, the server application, or the client giving up. Check the TTL of the RST — a TTL that differs from the server's other packets means a middlebox forged it.

4. Failed handshakes

tcp.flags.syn == 1 && tcp.flags.ack == 0

Repeated SYNs with no SYN/ACK means the port is filtered or the service is down — not a slow application.

5. Zero window

tcp.analysis.zero_window

The receiver's buffer is full. This is an application or host resource problem, never a network problem, and it is often misdiagnosed for weeks.

6. DNS failures

dns.flags.rcode != 0

NXDOMAIN and SERVFAIL responses surface instantly. Add dns.time > 0.5 to find slow resolvers.

7. TLS handshake problems

tls.handshake.type == 1 || tls.alert_message

Client Hellos without a Server Hello mean the server rejected the connection; alert messages carry the actual reason, including certificate and version failures.

8. HTTP errors

http.response.code >= 400

Useful on internal, unencrypted services and API gateways.

9. Slow responses

http.time > 1 || dns.time > 1

Turns "the app feels slow" into a measured list of the slowest transactions.

10. One conversation, cleanly

ip.addr == 10.0.5.20 && tcp.port == 443

Right-click any packet → Follow → TCP Stream to isolate a single session and read it in order.

A repeatable method

1. Establish the timeline. Note the exact timestamp of the reported failure and use View → Time Display Format → Seconds Since Beginning of Capture.
2. Check Statistics → Conversations. Sort by bytes and duration; the anomaly is usually visible before any filter.
3. Run tcp.analysis.flags. If it is empty, the network is likely healthy and the problem is the application.
4. Isolate one failing conversation and follow the stream.
5. Compare against a working session of the same type. Differences jump out far faster than absolute analysis.

Interpretation table

Practical tips

• Capture on both ends when possible; the difference between the two captures locates the loss point exactly.
• Disable NIC offloads on the capture host, or you will see impossible 30 KB "packets".
• Use tshark -r file.pcap -q -z conv,tcp for fast triage on large files.
• Always record what "normal" looks like before an incident — a baseline capture is worth hours later.

Capturing in the right place

Filter skill matters less than capture location. A capture taken on the client shows what the client sent and received; a capture on the server shows what actually arrived. If the two disagree, the loss is between them and you have narrowed a whole network path to a segment in one step. Use a SPAN or mirror port on the switch when you cannot install anything on either endpoint, and confirm the mirror is configured for both directions — a one-way mirror produces captures full of unanswered packets and hours of false conclusions.

Working with very large captures

Multi-gigabyte files make the Wireshark GUI unusable. Split and pre-filter on the command line first:

editcap -c 200000 big.pcap split.pcap
tshark -r big.pcap -Y "tcp.analysis.retransmission" -w retrans.pcap
tshark -r big.pcap -q -z io,stat,1

Ring buffers are the right way to capture long-running intermittent problems: dumpcap -i eth0 -b filesize:100000 -b files:20 -w cap.pcap keeps a rolling window without filling the disk, so when the fault finally reproduces the evidence is already on disk.

With these ten filters and a fixed method, most captures resolve in minutes rather than hours. Paste a filtered summary into Stackvora AI for a second opinion, and browse the knowledge base for protocol-specific analysis guides.