Network problems on a dedicated server are uniquely frustrating because the cause can live anywhere: your application, the kernel, the NIC, the datacenter switch, an upstream carrier, or the user side. The cure is a layered method — work from the physical link upward, with one reliable tool per layer, and you can localize almost any issue in fifteen minutes.

Layer 1–2: Is the Link Itself Healthy?

Start at the bottom with ethtool eth0: confirm the negotiated speed matches what you pay for (a 10Gbps port linked at 1Gbps happens more often than you would think) and check ethtool -S for incrementing error, drop or CRC counters — those indicate a bad cable, transceiver or switch port, which is a provider ticket, not a software fix. ip -s link gives a quick view of interface-level drops.

Layer 3: Localize Loss and Latency With mtr

mtr --report -c 100 <target> combines ping and traceroute, showing loss and latency per hop over 100 probes. Reading it correctly matters: loss that appears at one middle hop but not at later hops is just a router deprioritizing ICMP — harmless. Loss that starts at a hop and persists to the destination is real. Always run mtr in both directions when possible, because return paths differ and asymmetric routing hides half the story.

Layer 4: Sockets and Connections With ss

The modern replacement for netstat answers most connection questions:

  • ss -s — summary: how many sockets in which states; thousands of TIME-WAIT or a growing SYN-RECV count each tell a specific story.
  • ss -tlnp — what is actually listening where, and which process owns it.
  • ss -ti — per-connection TCP internals including retransmits and congestion window; heavy retransmissions confirm path loss.

Also check nstat for system-wide TCP retransmit counters and listen-queue overflows — the kernel counts every drop it makes.

When You Must See the Packets: tcpdump

For the stubborn cases, capture traffic: tcpdump -i eth0 -w capture.pcap host 203.0.113.5 and port 443, then analyze in Wireshark. Filter tightly on busy servers — capturing everything on a 10Gbps interface fills disks fast. Packet captures settle arguments definitively: you can see retransmissions, resets, MTU-related fragmentation failures and TLS handshake problems rather than inferring them.

The Frequent Culprits Checklist

  1. DNS — slow resolution masquerades as a slow server; test with dig and check resolver latency.
  2. MTU mismatches — connections that hang after the handshake, especially over VPNs or tunnels.
  3. Conntrack table full — on busy NAT/firewall setups; check kernel logs for table-full messages.
  4. Saturated uplink — verify with your bandwidth graphs before debugging anything subtle.
  5. DDoS or scraping traffic — a sudden connection-count spike from diverse sources.

Frequently Asked Questions

What belongs in a provider ticket?

Interface error counters, bidirectional mtr reports with timestamps, and iperf3 results. Evidence at those layers lets the network team act immediately instead of asking you to reboot.

Why is only one region slow?

Almost always routing: a congested carrier on that specific path. mtr from an affected user localizes the hop; providers can sometimes shift traffic to another transit provider.

Any always-on precautions?

Graph interface errors and retransmit rates in your monitoring, and keep a known-good iperf3 baseline. Deviations then page you before users complain.

Our network engineers watch these layers around the clock — see dedicated servers with premium bandwidth, add a dedicated IP, or escalate a network question.