Troubleshooting network issues and sending support a useful MTR report

Network faults are usually specific to one route between two points. A ticket that says "the server is unreachable" tells us something is wrong, but not where. A pair of MTR reports tells us exactly which hop, which carrier and which direction. This guide shows how to narrow the problem down yourself and, if it is on the network, how to send us the data that gets it fixed fastest.

Step 1: is it the network at all?

Start with a simple ping from your machine:

ping -c 4 203.0.113.10

If ping succeeds but your website or app does not respond, the network is fine and the problem is the service. Check that it is running and that the server's own firewall allows the port:

systemctl status nginxss -tlnp | grep ':443'ufw status

Then test the specific port from outside:

nc -vz 203.0.113.10 443

Step 2: rule out the two most common causes

• Your own IP is blocked. Try from a different connection, such as mobile data. If that works, something is filtering your normal IP: often a rule in the server's own firewall or a tool like fail2ban.
• The server's firewall is blocking you. Use Open Console on the server page in the console. The browser console does not depend on the network, so you can inspect ufw status or iptables -L -n even when SSH is unreachable.

If fail2ban is installed, check whether it banned you:

fail2ban-client status sshdfail2ban-client set sshd unbanip 198.51.100.7

Step 3: run MTR

MTR combines traceroute and ping. It maps the route to a destination and then keeps testing every hop, so it shows sustained loss and latency rather than a single snapshot. That is what makes it useful: a plain traceroute cannot tell a momentary blip from a persistent fault.

Install it

# Debian / Ubuntusudo apt install mtr-tiny # macOSbrew install mtr

On Windows, use WinMTR, which gives the same sustained view. If you only have built-in tools, tracert plus a long ping is better than nothing:

tracert 203.0.113.10ping -n 100 203.0.113.10

Run a report

mtr --report --report-cycles 100 203.0.113.10

That runs 100 cycles, about a minute and a half, and prints a text report. Fewer cycles produce noise that is easy to misread. If large transfers stall but small requests work, add a path MTU check:

tracepath 203.0.113.10

Step 4: run it in both directions

This is the part most reports are missing, and often the part that matters. Internet routing is asymmetric: the path from you to the server can be fine while the path back is broken. A report in one direction frequently shows nothing wrong.

From the server, find your own public IP:

curl -s https://ifconfig.me

If SSH is down, run this from the browser console instead. Then run MTR from the server back to that address:

mtr --report --report-cycles 100 198.51.100.7

Reading the report yourself

• Loss at one middle hop but not after it is usually harmless. Many routers deprioritize replying to pings while forwarding real traffic normally.
• Loss that starts at one hop and continues to the end is real. The first affected hop is where the problem begins.
• Loss only at the final hop points at the destination itself: the server, or its firewall rate-limiting ICMP.
• A sudden, sustained jump in latency that persists to the end points to congestion or a long detour at that hop.

What to put in the ticket

Open a ticket from Support in the console, or email [email protected], and include:

• Both MTR reports as text, each labeled with its direction. A screenshot cannot be searched or compared against routing data.
• Your public IP address and the server's IP address.
• When it started, and whether it is constant or intermittent.
• Your ISP and rough location, since faults are often carrier-specific.

With that, we can usually identify the problem route on the first reply.

Next steps

• See how traffic reaches your server on our Networking page.
• Under attack rather than misrouted? Read about DDoS protection.
• Check which region is closest to your users.