Diagnose slow Linux networking with tcpdump
Troubleshooting slow network performance with tcpdump becomes practical when capture is tied to a reproducible test. A packet capture shows what crosses one Linux interface, helping separate DNS delay, TCP stalls, loss and application wait from a vague report that the network is “playing up.”
Australian paths add context: NBN FTTP, FTTN and fixed-wireless services behave differently, while routes between Sydney, Melbourne, Brisbane and Perth may be longer than the straight-line distance suggests. Record whether the endpoint is a home gateway, Australian VPS or cloud region.
Establish a reproducible baseline
Begin with route and timing data. On RHEL, CentOS or Fedora, run ip -br addr, ip route and ping -c 20 1.1.1.1. Record the interface, gateway, loss and minimum, average and maximum round-trip time.
Use mtr -r -w -c 20 1.1.1.1 to expose intermediate loss and latency variation. For HTTP, run curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' "$URL"; unusually large gaps identify the stage to investigate.
Capture on the correct interface
Choose the interface that carries the failing traffic, not merely the one with the most packets. Use eth0 for a public NIC, tun0 or wg0 for VPN traffic, and br0 for a Linux bridge. A useful capture is sudo tcpdump -ni eth0 -s 0 -w /var/tmp/slow-network.pcap 'tcp port 443'.
Keep the duration and filter narrow, then stop it cleanly. Read the file with sudo tcpdump -nn -tttt -r /var/tmp/slow-network.pcap | less; full timestamps make it easier to match responses to requests. Treat the pcap as sensitive because its payload may contain credentials or personal data.
Read handshake and retransmission evidence
Start with the TCP handshake. Repeated SYNs without SYN-ACKs narrow the problem to routing, a firewall, an overloaded listener or packet loss. A completed handshake followed by a long data gap can instead point to server processing, a slow dependency or receiver-side queuing.
Inspect sequence numbers, acknowledgements, window sizes and timing around the slow transaction. Duplicate data or repeated acknowledgements can indicate retransmission; a zero-window advertisement means the receiver temporarily advertised no buffer space. Confirm suspected retransmissions in Wireshark, since raw tcpdump output can resemble them during normal sequence changes.
Correlate clocks before comparing hosts. tcpdump normally prints local timestamps, so daylight-saving changes around Sydney or Melbourne can differ from Brisbane or UTC. Check timedatectl and NTP status on every participating system.
Distinguish latency from packet loss
A pcap should be read beside active measurements. A route hop with persistent high RTT may indicate path delay; rising RTT plus retransmissions more strongly suggests congestion or loss. ICMP can be rate-limited, so one blocked mtr hop is not conclusive.
| Signal | Likely interpretation | Best next check |
|---|---|---|
| RTT rises without retransmissions | Path delay or queueing | Compare mtr across repeated runs |
| Retransmissions accompany RTT spikes | Loss or congestion | Inspect interface counters and route changes |
| SYN arrives, but no SYN-ACK leaves | Listener, firewall or routing problem | Check ss, nftables and packet filters |
| Frequent zero-window packets | Receiver cannot accept data quickly | Inspect application reads and socket buffers |
Repeat the test during the reported period and sample enough packets to distinguish a brief queue from a persistent fault. Compare the same destination, protocol and time of day; otherwise, changing internet paths or Australian ISP routing can make the evidence misleading.
Check listeners, firewalls and Nginx
If packets arrive but no service response appears, inspect the application before changing firewall rules. Use ss -lntp to confirm the listener, ss -s to review socket pressure, and nft list ruleset or firewall-cmd --list-all on the relevant host. For proxied traffic, the Nginx server guides provide practical checks for virtual hosts and upstreams.
Nginx access logs can separate total request time from upstream_response_time; multiple upstream values may reflect retries. Validate configuration with nginx -t, compare CPU, memory and queue pressure, then reload only after a valid change. A capture taken only at the proxy ingress will not reveal delays inside its upstream.
Reproduce the affected user workflow
Browser requests combine DNS, TCP, TLS, caching and application calls. Compare a timed curl request with a repeatable browser workflow test so a slow button, redirect or third-party dependency is visible under the same narrow capture.
Australian NBN providers and local routers create separate support boundaries: Telstra, Optus, Aussie Broadband or another ISP may own the line, while the firewall, Wi-Fi and server belong to the customer. Note the access technology, modem and whether VPN split tunnelling changes the route before assigning blame.
Apply findings and confirm recovery
Use the pcap to support one change at a time rather than stacking tuning guesses. The Linuxtpoint tutorials are useful for checking the surrounding Linux administration workflow once the faulty layer is known.
Apply this evidence checklist:
- Capture on the true path interface with a narrow filter and fixed duration.
- Record the command, destination, route, timestamp and expected response time.
- Pair tcpdump with mtr, curl timing, socket state and server logs.
- Examine handshake completion, retransmissions, window limits and latency separately.
- Change one network, service or application variable, then rerun the identical workflow.
- Store pcap files securely and remove unneeded payload or test credentials.
Replay one affected transaction while running sudo timeout 30 tcpdump -ni eth0 -s 0 -w /var/tmp/retest.pcap 'tcp port 443', replacing eth0 with the baseline interface, then save its exact start time.