When users complain that the network is slow, the worst thing I can do is start guessing. In my environment, I've learned that finding the real cause of network slowness means working through a checklist — not jumping straight to ping and hoping for the best. Most "network is slow" tickets turn out to be DNS, a saturated uplink, a misconfigured duplex setting, or an application problem masquerading as a network issue. Here are seven methods I use to systematically track down the actual bottleneck.
Start With Ping and Traceroute for Latency
This is basic, but it's where I start every time. Run ping against the target the user is complaining about, then compare it to a known-good reference host.
ping -c 10 8.8.8.8
ping -c 10 internal-app.local
mtr -r -c 100 remote-site-gatewayWhat I'm looking for here isn't just whether ping succeeds — it's the pattern. Consistent 2ms latency is fine. Spikes from 2ms to 200ms intermittently tell me there's buffer bloat, congestion, or a flapping link somewhere. mtr is better than plain traceroute for this because it runs continuously and shows packet loss per hop.
Check Bandwidth Saturation With iftop and nload
Latency might be fine, but if your uplink is maxed out, everything crawls. I log into the edge router or firewall and check interface utilization.
iftop -i eth0 -n
nload -u Miftop shows me which connections are eating the bandwidth. If I see one IP pulling 900 Mbps on a 1 Gbps link, I've found my culprit. Sometimes it's a backup job that someone scheduled at noon. Sometimes it's a user downloading a massive file. Either way, I need to see the traffic before I can fix it.
If you have SNMP set up (and you should), vnstat or your monitoring platform like Zabbix or PRTG gives you historical data — which matters a lot when the problem is intermittent.
Investigate DNS Resolution Delays
This one bites me more often than I'd like to admit. A user says "the internet is slow," but actually DNS is slow. The page loads in pieces because each new hostname takes 300ms to resolve instead of 5ms.
dig +trace example.com
dig @8.8.8.8 example.com
time nslookup internal-service.localIf querying an external DNS resolver is fast but your internal resolver is slow, look at your local DNS server. Is it forwarding to a dead upstream? Is it overloaded? I once spent two hours chasing a "network slowness" issue that turned out to be a DNS forwarder pointing at a server that had been decommissioned weeks earlier.
Look for Packet Loss and Interface Errors
Packet loss is a silent killer. Small amounts — even 0.5% — can destroy TCP throughput because of retransmissions. I check interface stats on every device in the path.
ip -s -s link show eth0
show interfaces counters | include errorOn Cisco gear, I'm looking for input errors, output errors, CRC errors, and runts. On Linux, I'm watching for dropped packets, overruns, and frame errors. If I see CRC errors climbing, that's almost always a cabling issue or a duplex mismatch.
Warning: Duplex mismatches are sneaky. A 100 Mbps half-duplex link plugged into a full-duplex port will pass traffic but perform terribly under load. Always check duplex settings on both ends.
Verify MTU and Path MTU Discovery
MTU problems show up as "large transfers are slow but small ones work fine." If a user can ping a server but can't transfer large files without stalling, I suspect MTU.
ping -M do -s 1472 10.0.0.50
ip route get 10.0.0.50If 1472-byte packets get dropped but 1400 works, there's a path MTU issue — probably a VPN tunnel or a tunnel interface with a smaller MTU somewhere in the path. ICMP "fragmentation needed" packets might be getting blocked by a firewall, which breaks Path MTU Discovery entirely.
As I mentioned before in my post about Windows Server performance killers (https://furkanikkan.com/urun/windows-server-performans-katilleri-hemen-duzeltmen-gereken-gizli-ayarlar-44), OS-level settings like TCP autotuning and chimney offload can also create weird throughput issues that look like network problems.
Use tcpdump and Wireshark to Inspect Application Traffic
When everything above checks out and the problem persists, it's time to look at what's actually flowing on the wire. tcpdump on the server side, then pull the pcap into Wireshark.
tcpdump -i eth0 -w /tmp/capture.pcap host 10.0.0.50 and port 443
tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn-ack'Things I look for:
- TCP retransmissions and duplicate ACKs — indicates loss somewhere
- Very small window sizes — receiver can't keep up
- Unusual reset packets — firewall or middleware interfering
- TLS handshake taking too many round trips — certificate chain or SNI issues
This is where network-level diagnosis meets application-level diagnosis. If the network is clean but the application is slow, the problem isn't the network — it's the app, the database, or the server itself.
Correlate With Monitoring and Historical Baselines
The last method is the one that saves me the most time: having monitoring data before the problem happens. You can't diagnose a slowness issue properly if you don't know what "normal" looks like.
My checklist for monitoring before issues happen:
- SNMP-based bandwidth polling on all key links — at least 1-minute granularity
- Latency monitoring from multiple sites to critical services
- DNS response time tracking on internal resolvers
- Interface error counters alerting at thresholds, not just up/down
- NetFlow or sFlow export for traffic analysis on edge devices
- Application response time monitoring — not just availability
- Historical data retained for at least 30 days for pattern comparison
When a user reports slowness, I pull up the monitoring dashboard and compare current metrics to the baseline from last week. If bandwidth is normal, latency is normal, DNS is normal, and errors are zero — I go back to the application team. The network isn't always the villain, and good data proves it.
The key takeaway: don't jump to conclusions. Work the problem top to bottom — latency, bandwidth, DNS, errors, MTU, packet capture, and historical data. Most of the time, the real cause is hiding in one of those layers, and a systematic approach finds it faster than guessing ever will.
Cover image: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/52879212541