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.

The VPS can't reach one specific remote service#

A special case worth settling early: the VPS's internet works fine, but one particular destination won't connect, an API, a mail server, a payment gateway, a site. Know this first: we don't filter or block any outbound connectivity at the network level, none, on any product. So an outbound connection that fails is one of three things:

1. The remote side is blocking it. By far the most common. Many services rate-limit or refuse datacenter IP ranges wholesale (streaming platforms, some banks and APIs), or blocklist IPs on reputation. The signature: the same request works from your home connection but not from the VPS. The fix lives with the remote service (their support, or an allowlist request), there's no setting on our side that causes or cures it.
2. A firewall inside your own VPS. ufw, iptables, or a security tool you installed can block outbound; iptables -L OUTPUT -n shows if so.
3. DNS, if the failure is "could not resolve host" rather than a refused or timed-out connection, that's its own guide.

Two commands settle where it fails: nc -vz remote.host 443 (does TCP connect?) and curl -v https://remote.host/ (what happens above TCP?). A timeout to one host while others connect fine, from a VPS that's otherwise healthy, points at the remote side, test the same destination from another network to confirm.

No outbound connection timeouts imposed by VPSDime#

Related reassurance, stated plainly because the question comes up with long-running work: we impose no time limits on outbound connections from your VPS. A long API call, a streaming response, a websocket held open for hours, none of it is intercepted, proxied, or terminated by our network; there's no middlebox between your VPS and the internet cutting flows at some duration.

So when a long-running request dies with an error like ERR_STREAM_PREMATURE_CLOSE (or ECONNRESET, a broken pipe mid-stream), the cause is one of the parties actually on the connection: the remote server (idle and duration limits on their load balancers and proxies are common, and much shorter than people expect), your own application (its HTTP client's timeout, a worker recycled mid-request), or a fault somewhere on the network path, the thing the rest of this page diagnoses. It is not a VPSDime policy, there isn't one to tune, whitelist, or lift.

One practical tip for connections that sit idle for long stretches: enable keepalives in the client (TCP keepalive, or protocol-level pings on websockets), since remote-side equipment routinely drops flows that go quiet, and a keepalive is what marks the connection as alive.

Corporate and ISP firewall block pages#

The mirror image of the case above: you (or your users) try to open a service hosted on your VPS and get a branded block page, FortiGuard, Cisco Umbrella, Sophos, or similar, instead of your site. That page is the confession: a security appliance on the network path between the visitor and your VPS intercepted the request, typically an office or school network's firewall, or an ISP running content filtering. Neither your VPS nor our network produces pages like that.

The usual trigger is the domain being new: these filters categorize the web, and a freshly registered or "newly observed" domain sits in a suspicious-by-default category for days until the vendor classifies it, which is why a brand-new site works everywhere except from the office.

• Confirm in one move: open the same URL from a different connection, a phone on mobile data is perfect. Loads fine there? The VPS is reachable and the block lives in the filtering network.
• Fix it at the filter: every major vendor has a public recategorization/review form (searching "FortiGuard recategorize" or the equivalent finds it), submissions on a legitimate site are usually processed within days. On a corporate network, the local IT admin can also whitelist the domain immediately.
• Nothing on the VPS or in our network can cure this, the block sits in front of the visitor, not in front of the server.

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?"
• "Why can't my VPS connect to one specific site or API?"
• "Do you block outgoing connections from my VPS?"
• "Why do I see a FortiGuard or Cisco Umbrella block page instead of my site?"
• "My new domain is blocked on my office network but works on mobile data."
• "Do you terminate long-running or idle connections from my VPS?"
• "What causes ERR_STREAM_PREMATURE_CLOSE on my VPS?"