Learning how to use Wireshark to find slow network problems is one of the most practical skills a network engineer can build. Our team has spent years staring at packet captures, and one scenario keeps coming back to us. A file transfer crawls along at a small fraction of the link speed, ping looks perfectly healthy, and nobody on the floor can explain it. That is usually the moment when knowing how to use Wireshark to find slow network problems stops being a theory exercise and becomes the fastest way forward. Wireshark will show you where the time goes, but only if you know which filters to apply and which TCP signals actually mean something. Below we walk through the sequence we follow on real incidents, from capturing the right traffic to separating packet loss from a receiver that simply cannot keep up.
How to use Wireshark to find slow network problems: the core workflow
Slowness almost never arrives with a clear error message. Instead it leaves a pattern: retransmissions bunching together, zero-window stalls, and gaps between packets that are far longer than they should be. Wireshark makes those patterns visible. The workflow is simple to describe. Capture on the path that feels slow, narrow the view to the affected conversation, then read the TCP behavior and its timing. We follow the steps in the order we use during an incident, because the order itself saves time.
Setting up a capture that shows the real problem
Where you capture matters more than most engineers expect. A capture taken on the wrong side of a switch can make a healthy network look broken, or hide the real bottleneck completely. We usually start at the client or the server, since those are the endpoints where users feel the slowness. If the suspected bottleneck sits in the middle of the path, we place a SPAN or mirror port close to that device.
Full captures grow fast. A busy link can fill a laptop disk within minutes, so we rely on a capture filter such as host 10.20.30.40 and port 443 to record only the conversation under investigation. A ring buffer is also worth enabling so older data rolls off instead of exhausting the drive. When you capture at two points, make sure both clocks are synchronized, normally through NTP. Without that discipline, comparing timestamps between two files tells you very little.
Display filters that isolate the slowness
Capture filters decide what gets recorded, while display filters decide what you examine afterward. Display filters do most of the analytical work. Begin by narrowing the view to one conversation:
ip.addr == 10.20.30.40 && tcp.port == 443
Next, reveal only the trouble indicators Wireshark has already flagged:
tcp.analysis.flags
That single filter brings retransmissions, duplicate ACKs, and zero-window events to the surface. To measure delay directly, use tcp.time_delta, which reports the gap since the previous packet in the same stream, and tcp.time_relative, which reports elapsed time since the stream began. A two-second hole in a transfer that should flow smoothly is exactly the clue you are hunting for.
We keep a small library of saved filters and reuse them across cases. That habit keeps our analysis consistent from one incident to the next.
Retransmissions versus zero window: different culprits
Of all the flags Wireshark raises, retransmissions and zero window cause the most confusion. Both slow a transfer, yet they implicate different culprits, and mixing them up sends people chasing the wrong device for days.
tcp.analysis.retransmission and tcp.analysis.fast_retransmission mean the sender had to resend a segment, which nearly always means a packet was lost along the path. The sender detects this through duplicate ACKs, producing a fast retransmission, or through a timer expiring, producing a retransmission timeout. Timeouts hurt the most, because the sender sits idle until the timer runs out. In that case the network path is the prime suspect.
tcp.analysis.zero_window carries a different meaning. The receiver has advertised a window of zero, telling the sender to pause because its buffer is full. The network delivered the data without trouble; the receiving host is not draining its buffer fast enough. When zero-window events appear, we look at the receiver rather than the switch.
Two more flags deserve attention: tcp.analysis.window_full and tcp.analysis.bytes_in_flight. They show when the sender itself is constrained by the window it was given. Loss stalls a sender through timers, while zero window stalls it through buffers. Keeping those two apart turns a quick diagnosis into a productive one.
Reading I/O graphs for throughput and gaps
A long list of numbers is hard to scan. The I/O graph turns the capture into something you can read at a glance. Open it from the Statistics menu and choose I/O Graphs. Configure one line for bytes per second to show throughput. Add a second line set to COUNT FRAMES with the display filter tcp.analysis.flags, so spikes in problem packets sit directly against the throughput curve.
The shape carries most of the information. A flat line usually means the transfer stopped, often because the sender was waiting on a timer or a full window. A sawtooth is ordinary congestion control at work. When retransmission spikes line up with throughput dips, loss is the likely cause. Overlaying round-trip time helps separate a latency problem from a loss problem.
Measuring RTT per conversation
Round-trip time is how long a packet takes to reach the far side and for its acknowledgement to return. To view it per conversation, go to Statistics, then TCP Stream Graphs, then Round Trip Time. The graph shows how RTT evolves over the life of the transfer.
One technique we find useful is to compare the RTT in the handshake, from SYN to SYN-ACK, with the steady-state RTT later in the session. If the handshake looks quick while the steady-state figure climbs, something on the path changed partway through, such as a route flap or a filling queue. Absolute values depend heavily on distance and path, so always benchmark against a baseline recorded on a healthy path between the same two endpoints.
A worked example from our lab
One case illustrates the method well. A 500 MB file copy between two servers ran at roughly a tenth of link speed, and we worked through it in a fixed order.
First we filtered the stream and counted retransmissions, checking where they clustered. The retransmissions came in short bursts rather than spreading evenly across the transfer. That pattern pointed toward an intermittent fault rather than a consistently bad link.
Next we ruled out the receiver. Filtering for zero-window events returned nothing, so the receiving host was draining its buffers normally, and the path became the likely location of the problem.
We then inspected the I/O graph alongside the RTT trend. Throughput dropped sharply in step with the retransmission bursts, while RTT stayed steady in between. That combination indicated a lossy segment, not a long or congested route.
Only after that correlation did we check interface counters on the switch and firewall along the path. The counters showed CRC errors on one uplink. Replacing the cable and retesting brought the transfer back close to line speed. The takeaway is simple: let the capture point toward a suspect, then confirm with device counters before changing anything.
Common symptoms and what they usually mean
When you are reading a capture under pressure, a quick reference helps. These pairings are a starting point, not a verdict, and each should be checked against the surrounding TCP state.
- Retransmissions with normal RTT: usually loss on the path or a congested link, worth checking against interface error counters.
- Zero window from the receiver: the application or host is not draining its buffer quickly enough, so the investigation moves to the endpoint.
- High RTT without retransmissions: typically a long-distance or queued path rather than packet loss, so focus on routing and queue depth.
Gaps with no TCP flags at all deserve their own look. They often come from upstream delay, slow DNS lookups, or application think time between requests, and no amount of TCP filtering will expose those. Move up the stack and check what the application was waiting on during the silence.
Mistakes that hide the real cause
The first mistake is capturing on one side only and then blaming whichever device happens to be under suspicion. Capture at both ends whenever possible so the two views can be compared directly.
The second mistake is filtering too early. If you narrow the capture before examining the handshake, you lose the initial window size and the first RTT sample, both of which are valuable reference points later. Keep the full conversation until you have looked at its beginning.
The third mistake is reading absolute numbers without a baseline. A 40 millisecond RTT could be excellent on one route and alarming on another. The fourth is assuming a flag always means the same thing. A retransmission in the middle of a long transfer is a different event from one at the start of a connection.
Where slow links tend to appear in Vietnamese enterprises
In the Vietnamese enterprise environments we work with, slowness clusters in a few predictable places. Multi-site organizations often combine leased lines with broadband, and loss concentrates at the edge where those links meet the core. A capture taken at a branch office frequently shows retransmissions that disappear when the same test runs from headquarters, a strong hint that the problem sits on the branch access link.
Cross-border traffic to international SaaS platforms is the other frequent source. RTT is high by nature, and congestion on international routes varies through the day. For teams building a broader toolkit around these checks, resources like The MONA are useful reference points alongside hands-on testing.
Frequently asked questions
Do I need to capture on both ends to diagnose slowness?
Not always, but it helps considerably. A capture on one side shows that retransmissions happened and how the window looked from that host. Capturing both ends lets you check whether a packet left one side and never arrived at the other, which is the clearest evidence of loss between them.
Does Wireshark work on encrypted traffic such as TLS?
Yes, at the TCP layer. Retransmissions, windows, and timing remain visible even when the payload is encrypted. Reading the application data requires session keys, so inspecting TLS content means capturing keys from the endpoint. That decision should be made deliberately and documented.
How large a capture can I analyze on a laptop?
It depends on available memory and filter complexity. In our experience a laptop with 16 GB of RAM handles captures of a few gigabytes comfortably. For anything larger, apply a capture filter first or split the trace with a ring buffer.
Which TCP flags matter most for a first pass?
Start with the analysis flags instead of raw SYN, ACK, and FIN bits. The tcp.analysis.flags field summarizes retransmissions, duplicate ACKs, and zero-window events in one place. Drop to the raw flags only when you need to confirm how a connection started or ended.
When should a capture go to the security team?
When the slowness could be malicious, for example unexpected traffic to unfamiliar destinations, a sudden flood of connections, or patterns resembling scanning or data exfiltration. If the capture shows only loss, delay, or a full receiver buffer, the network or infrastructure team is usually the right owner.
Related reading
If you want to go a level deeper, our piece on kernel-level visibility complements packet captures well. Pairing the two shows both what crossed the wire and what happened inside the host. You can read it at threat hunting with eBPF and kernel observability. For the path-level side of the same problem, our notes on SD-WAN and fiber backbone resilience cover how links are engineered for resilience, and our digital twin integration testing article shows how to rehearse these fixes before they reach production.