VPS Looks Healthy but Visitors Can't Connect? Trace the Path With mtr

Monitoring says the VPS is fine. CPU is idle, memory has headroom, the disk isn't full, and Nginx or LiteSpeed is running. Yet visitors from one country, or from one ISP, get connection timeouts while everyone else loads the site normally. When the server looks healthy and only some regions fail, the problem is often somewhere on the network path between them and you. mtr is one of the quickest ways to find out where. This walkthrough goes from the symptom down to a specific network, in the order a support engineer would usually check things. It also covers the readings that look alarming but mean nothing.

First, prove whether packets reach the VPS

Check the server side before you start tracing routes across the internet. Two inside causes produce exactly this regional pattern, and both are easy to miss. The first is the firewall. Geo-blocking rules, a CSF or fail2ban ban, or a rate-limit rule can block one region and leave others alone. Mobile carriers and some home ISPs put many users behind a shared address (CGNAT, carrier-grade NAT). Banning one abusive client on that address can lock out a large group of real visitors who appear to come from the same place. The second is the listener. The service must be listening on the public address and port, not only on localhost or only on IPv4. If affected users resolve your domain to an AAAA record and the site only listens on IPv4, the failure follows whoever has IPv6. To the customer, that looks like a regional problem. The most useful single check is to watch the wire while an affected user retries. Ask them for their public IP, then capture traffic on the VPS:

BASH

# Is anything listening on 443, and on which addresses?
sudo ss -tlnp 'sport = :443'

# Read-only view of the current firewall rules (use whichever your system has)
sudo nft list ruleset
sudo iptables -S

# Watch for the affected client's packets while they reload the page
# Replace 198.51.100.25 with the client's real public IP
sudo tcpdump -ni any 'tcp port 443 and host 198.51.100.25'

The capture gives you one of three results, and each one narrows the search. If no packets arrive at all, the inbound path is broken before your server. That could be upstream, at the provider edge, or a provider-level filter you can't see from inside the VPS. If a SYN arrives and nothing goes back, the drop is local. Look at your firewall or the service again. If a SYN arrives, your server sends a SYN-ACK, and the client never completes the handshake, your server did its job. The reply is getting lost on the way back. This case matters later, because it points at the return path.

Run mtr from the side that is failing

mtr combines traceroute and ping. It discovers each router (hop) between two points, then keeps probing all of them and builds up statistics on loss and latency for each hop. A single traceroute is a snapshot. mtr running for a hundred cycles shows you a pattern. The direction matters. Running mtr from your VPS to some random test site tells you very little about why users in another country can't reach you. The trace has to start in the affected region. You can get one from the affected user, from a small VM you spin up in that region, or from a public looking glass operated by a network in that area. On Windows, users can run WinMTR or the built-in pathping, although both probe with ICMP rather than TCP. When you can, probe with TCP to the port the site actually uses. Some networks treat ICMP differently from real traffic, so a TCP trace to port 443 is closer to what a browser experiences. The second command below is for the reverse direction, which the next sections explain.

BASH

# From the affected region toward the VPS (TCP to port 443; usually needs root)
sudo mtr -rwzn -T -P 443 -c 100 203.0.113.10

# From the VPS back toward the affected client or their ISP
sudo mtr -rwzn -c 100 198.51.100.25

Here is what each flag does:

-r prints a report after the run finishes.
-w keeps hostnames from being cut off.
-z adds the AS number (the identifier of the network that owns each hop's address).
-n skips reverse DNS so the run is faster.
-c 100 sends 100 probes per hop.
-T and -P 443 switch the probes to TCP on port 443.

AS lookup and TCP mode depend on the mtr build, so check man mtr if a flag is rejected.

Reading the report without chasing ghosts

The report is where most people go wrong. Here is a shape you will see often.

TEXT

Illustrative output format (documentation IPs and private AS numbers)
HOST: probe-affected-region       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.1.1          0.0%   100    1.0   1.2   0.8   3.0   0.3
  2. AS64500  198.51.100.1         0.0%   100    8.0   8.5   7.9  12.0   0.6
  3. AS64500  198.51.100.9         0.0%   100   10.0  10.4   9.8  15.0   0.7
  4. AS64501  192.0.2.17          40.0%   100   30.0  31.0  29.5  40.0   1.5
  5. AS64501  192.0.2.33           0.0%   100   31.0  31.5  30.0  38.0   1.1
  6. AS64502  192.0.2.65          30.0%   100   90.0  92.0  88.0 140.0   8.0
  7. AS64502  192.0.2.70          30.0%   100   91.0  93.0  89.0 150.0   9.0
  8. AS64510  203.0.113.1         30.0%   100   95.0  96.0  92.0 155.0   9.5
  9. AS64510  203.0.113.10        30.0%   100   96.0  97.0  93.0 160.0   9.8

Hop 4 shows 40% loss, and it is tempting to send that line to someone. But hop 5 and later show nothing like it. Routers forward traffic in hardware, but they answer probes addressed to themselves with a much slower control processor. Many routers also rate-limit those replies on purpose. A hop can ignore your probes while forwarding everyone's packets perfectly. Loss that appears at one hop and disappears at the next is almost always this kind of reply throttling, not a real problem. Real loss looks different. It starts at one hop and continues through every hop after it, all the way to the destination. That is what hops 6 to 9 show. The loss begins where traffic enters AS64502, and the latency and StDev (jitter) jump at the same point. The fault sits at hop 6 or on the link just before it. The same rule applies to latency. A big jump that persists to the end can simply be distance, like a subsea cable crossing. A spike at one middle hop that does not carry forward is the same reply-throttling effect. Rows showing ??? mean the hop did not answer. They do not mean the hop is down. The last hop is what counts. If the destination shows 0% loss, the path is fine as far as these probes can tell, whatever the middle looks like. Even 30% loss at the destination is enough to cause timeouts, because TCP stalls and retransmits on every dropped handshake or data segment.

Trace back from the VPS too

Internet routing is usually asymmetric. The path from a visitor to you is chosen by their networks' policies, and the path from you back to them is chosen by yours and your upstreams'. The two directions can cross completely different carriers. A clean forward trace does not prove the return trip works. This is where the earlier tcpdump result comes back. If you saw SYNs arrive and SYN-ACKs leave but no handshake completion, the forward path is working and the return path is the suspect. Run the second mtr command from the VPS toward the client's IP. Many home routers and phones do not answer probes, so the last hop or two may stay silent. In that case, trace to the client's ISP gateway or watch where loss begins and persists. The same reading rules apply. For a deeper treatment of telling one-way drops from a fully dead path, see Deciding If Inter-VPC Timeouts Are Asymmetric Drops or a Dead Path. The reasoning carries over to public internet paths.

Deciding where the fault lives

Once you have tcpdump results and mtr reports in both directions, the evidence usually lands in one of three places. Inside the VPS: tcpdump shows packets arriving but nothing useful going back, or the firewall rules match the affected source. The fix is yours. Unban the address, adjust geo-rules, or fix the listen address. At the provider edge: loss starts within the first hops that carry the provider's AS number. It shows up in both directions and affects several unrelated destinations, not just one region. That points at the provider's routers, uplinks, or filtering. Only they can fix it. Upstream: loss starts inside a transit or carrier network between you and the visitor, in the forward path, the return path, or both. Only users whose traffic crosses that network are affected. That explains why some regions work and others don't. Sometimes the path itself looks wrong, and traffic passes through an AS that has no business being there. That pattern fits a BGP route leak, where a network wrongly advertises routes and pulls traffic toward itself. The traffic then gets congested or dropped while every dashboard inside the VPS stays green. Why a BGP Route Leak Looks Like Your Host's Outage But Isn't covers how that plays out. Leaks often clear on their own once the bad routes are withdrawn, although full recovery can lag while routing tables converge. For anything outside your VPS, the useful move is a good report. Send your provider:

The mtr reports for both directions, with timestamps and source IPs.
The tcpdump findings.
Which regions or ISPs fail and which work.

A provider can't repair a third party's network. Depending on how they are connected, they may be able to shift traffic to a different upstream or escalate to the carrier with your data attached. Reports that show where loss begins and persists get acted on much faster than a ticket saying 'site down for some users'. At the support desk, the first questions save the most time: where is the visitor, which ISP are they on, and can they run an mtr. Most 'my VPS is down' reports from a single region are answered by those three facts. When a healthy server times out for only part of the world, start at the wire. Confirm with tcpdump whether packets arrive and replies leave, then trace in both directions from the side that is failing. Ignore loss that doesn't carry forward, follow the loss that persists to the destination, and note the AS number where it starts. That one line in the report tells you whether to fix your own config, open a ticket with your provider, or wait out an upstream problem with evidence in hand.