Understanding and troubleshooting network problems

What this is#

Your VPS feels slow, laggy, or drops packets, and the honest first question is where the problem lives: your network, our network, or one of the carriers in between. This page gives you the mental model and the tools to answer that in about ten minutes, which is also exactly the evidence that lets us act on a ticket immediately instead of asking you for it.

How your packets actually get here#

The internet is a chain of routers. A packet from your laptop to your VPS passes through hops: your device → your home router → your ISP's routers → one or more transit carriers (the long-haul networks that connect ISPs together) → our network's edge → your VPS. Three things about that chain explain most confusion:

• Every hop is owned by someone different. Your ISP owns the first few, carriers own the middle, we own the last ones. A fault at any hop affects everything after it, which is exactly what lets you locate it.
• The path back can be different. Routing is chosen independently in each direction (asymmetric routing), so "there" can be clean while "back" is broken. That's why we test both directions.
• Distance is physics. Packets travel at a large fraction of the speed of light and still need time: same-city pings run a few ms, cross-continent 60 to 90 ms, transatlantic 70 to 100 ms, US to Asia 150 ms or more. High latency to a server far away isn't a fault, it's geography.

First, scope the problem#

Two minutes of scoping saves an hour of tracing:

• Is it just this VPS, or everything you browse? If other sites feel bad too, look at your own connection first.
• Is it just your location? Try your phone on mobile data (not Wi-Fi), and above all run your VPS IP through ping.pe: it pings (and can mtr) your IP from dozens of locations worldwide at once, and the pattern is an instant verdict:
  • Green from every probe: the VPS and our network are fine, the problem is your connection or your ISP's path to us.
  • Red from every probe: something is genuinely down, the VPS itself or a real problem on our side. Check the status page, run My VPS is Down, and ticket us.
  • Bad from some regions, fine from others: a mid-path or regional routing problem, exactly what the mtr section below pins down.
• Is the VPS itself up and healthy? Check the panel and the Console. A box that's swapping, pinned on CPU, or out of traffic feels exactly like a network problem.
• Anything on our side? Check the service status page, and remember a VPS under DDoS gets null-routed, which looks like total unreachability.

One more scoping distinction: this page is about lag, jitter, loss, and unreachability. If your complaint is transfer speed (slow downloads/uploads, "I'm not getting the bandwidth"), that's a throughput question, see Testing your VPS network speed for speedtest CLI, our test files, and iperf3.

ping: the quick health check#

ping YOUR.VPS.IP

Three numbers matter: latency (judge it against the geography above, not against zero), jitter (latency bouncing around, bad for games and calls even when the average looks fine), and packet loss (any sustained loss is worth investigating). Ping tells you whether something is wrong; it can't tell you where. For that:

mtr: the tool that settles it#

mtr is traceroute and ping combined: it pings every hop on the path continuously, so you can see where trouble starts.

• Linux/macOS: install it (apt install mtr / brew install mtr), then run a proper sample: mtr -rwbzc 100 YOUR.VPS.IP (100 rounds, report form, with hostnames and AS numbers).
• Windows: use WinMTR, enter the IP, let it run to at least 100 sent, then Export TEXT.

How to read it (this is the part everyone gets wrong)#

1. Loss only counts if it continues to the final hop. Routers deprioritize replying to pings when busy, so a middle hop showing 20% loss while the destination shows 0% means that router is lazy about ICMP, not that your traffic is being dropped. Real loss starts at some hop and persists on every hop after it, including the last.
2. A latency spike at a single hop means nothing unless the hops after it inherit it. Same reason: the router answered your probe slowly but forwards real traffic at full speed.
3. ??? hops are normal. Some routers never answer probes. If later hops respond, the path is fine.
4. Watch where the handoffs happen. The hostnames/AS numbers show the chain: your ISP's names first, then carrier names (Cogent, Lumen, Telia, and so on), then ours. Where the problem starts tells you whose network it starts in.

Test both directions#

Because return routing can differ, one mtr is half a diagnosis:

• Forward: mtr from your machine to the VPS IP (above).
• Reverse: mtr from the VPS back to your IP, install mtr on the VPS and run mtr -rwbzc 100 YOUR.HOME.IP (find your IP on any "what is my IP" site). If the VPS is unreachable, use our Looking Glass instead, it runs ping and mtr from our network toward any IP, giving you the from-our-side view without touching the VPS.

Reading the verdict#

• Trouble starts in the first hops (your router, your ISP's early hops) and appears toward every destination you test: it's local, your Wi-Fi, router, or ISP. Test on a wire, reboot the router, then take the evidence to your ISP.
• Trouble starts mid-path at a carrier and persists to the end: a transit issue between your ISP and us. Send us both MTRs, sometimes we can adjust routing with our carriers, though mid-path issues are often outside anyone's direct control and get fixed by the carrier itself.
• Trouble starts in the final hops, inside our network: that's ours. Send the MTRs and we'll get on it.
• Everything is clean but the VPS still feels slow: the network isn't the problem, look at the VPS itself (memory, CPU, disk, the app).

What to put in the ticket#

• Both MTRs, at least 100 cycles each, pasted as text (not screenshots),
• the timestamps of when you ran them and when the problem happens (constant, or specific hours?),
• your source IP and the VPS involved.

With that, we can identify the faulty hop on the first read. If the VPS is fully down rather than slow, run My VPS is Down instead, it checks the VPS and walks you through attaching a trace when escalating.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP and the IP you're testing from,
• both MTRs (at least 100 cycles each, pasted as text),
• when it happens (constant, or specific hours).

Related questions#

• "How do I tell if lag is my ISP's fault or the VPS's?"
• "How do I run and read an mtr report?"
• "Why does one hop show packet loss but my connection works?"
• "What is a hop, and why do middle hops time out?"
• "Is 100 ms ping to my VPS normal?"
• "How do I test the network path from your side?"
• "What network evidence should I include in a ticket?"