How to Diagnose Network Issues on Your VPS

If you are experiencing network problems such as slow connections, packet loss, or your VPS being unreachable, this guide will help you gather the diagnostic information needed to identify and resolve the issue. If you need to contact our support team, the data collected here will significantly speed up the troubleshooting process.

Step 1: Check if Your VPS Is Reachable

Before running any advanced diagnostics, verify basic connectivity from your local machine:

ping -c 10 YOUR_SERVER_IP

If you receive no replies at all, try accessing your VPS through the emergency console / VNC console in your control panel. If you can log in via console but not over the network, the issue is likely network-related. If the console is also unresponsive, the server itself may need a reboot.

Quick Checklist

• Can you reach the server via VNC/emergency console?
• Did you recently change any firewall rules (iptables, firewalld, ufw, CSF)?
• Is the network interface up? Run ip a and check that your primary interface shows your IP and state UP.
• Are there disk or memory issues preventing the server from responding? Check with dmesg | tail -50.

Step 2: Run an MTR Test (Most Important)

MTR combines ping and traceroute into a single tool and is the most useful diagnostic for network issues. It shows every network hop between two points along with latency and packet loss at each hop.

Installing MTR

Running the Test

You need to run MTR in both directions — this is critical because network routes are often asymmetrical (traffic can take a different path going vs. returning).

From your local machine → server:

mtr -s 1000 -r -c 200 YOUR_SERVER_IP

From your server → your local machine:

First, find your local public IP at a site like https://ifconfig.me, then run on the server:

mtr -s 1000 -r -c 200 YOUR_LOCAL_PUBLIC_IP

Each test sends 200 packets and takes about 3–4 minutes. Save the output of both tests — you will need them if you contact support.

Tip: On Windows, open WinMTR, enter the target IP, and click "Start". Let it run for at least 200 cycles, then click "Export TEXT" to save the results.

Step 3: How to Read MTR Results

MTR output shows a numbered list of hops with loss percentage, packet count, and latency statistics. Understanding what the results mean will help you determine where the problem is and who can fix it.

Normal Result (No Issues)

HOST: your-server              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway.local           0.0%   200    0.3   0.4   0.2   1.1   0.2
  2.|-- isp-router.example      0.0%   200    5.2   5.5   4.8   8.3   0.6
  3.|-- core-router.example     0.0%   200   12.1  12.4  11.8  15.2   0.5
  4.|-- datacenter-gw.example   0.0%   200   14.3  14.5  14.0  16.1   0.3
  5.|-- your-server.example     0.0%   200   14.5  14.6  14.1  16.4   0.4

All hops show 0.0% loss and consistent latency — the connection is healthy.

Pattern 1: Loss That Disappears Before the Destination

  1.|-- gateway.local           0.0%   200    0.3   0.4   0.2   1.1   0.2
  2.|-- isp-router.example      0.0%   200    5.2   5.5   4.8   8.3   0.6
  3.|-- core-router.example     8.5%   200   12.1  12.4  11.8  15.2   0.5
  4.|-- datacenter-gw.example   0.0%   200   14.3  14.5  14.0  16.1   0.3
  5.|-- your-server.example     0.0%   200   14.5  14.6  14.1  16.4   0.4

Hop 3 shows loss, but hop 4 and 5 are fine. This is not a real problem. Many routers deprioritise ICMP (ping) traffic to save resources, which makes it look like there is loss even though your actual traffic is unaffected. If the final hop shows 0% loss, your connection is fine.

Pattern 2: Loss Only on the Last Hop

  1.|-- gateway.local           0.0%   200    0.3   0.4   0.2   1.1   0.2
  2.|-- isp-router.example      0.0%   200    5.2   5.5   4.8   8.3   0.6
  3.|-- core-router.example     0.0%   200   12.1  12.4  11.8  15.2   0.5
  4.|-- datacenter-gw.example   0.0%   200   14.3  14.5  14.0  16.1   0.3
  5.|-- your-server.example    35.0%   200   14.5  48.2  14.1 320.4  62.1

All hops are clean except the server itself. The problem is most likely on the server. Common causes include high CPU or memory usage, a misconfigured firewall dropping packets, or a software issue. Check your server's resource usage:

top -bn1 | head -20
free -m
ss -s

Pattern 3: Loss That Starts at a Hop and Continues to the End

  1.|-- gateway.local           0.0%   200    0.3   0.4   0.2   1.1   0.2
  2.|-- isp-router.example      0.0%   200    5.2   5.5   4.8   8.3   0.6
  3.|-- core-router.example    48.0%   200   12.1  85.4  11.8 450.2  95.3
  4.|-- datacenter-gw.example  47.5%   200   14.3  82.1  14.0 440.8  90.1
  5.|-- your-server.example    52.0%   200   14.5  90.2  14.1 460.3  98.4

Loss begins at hop 3 and persists through every subsequent hop. This indicates a real network problem at or near hop 3. The responsible party depends on who owns that hop — it could be your ISP, a transit provider, or the datacenter network. Contact support with both MTR results so the correct provider can be notified.

Step 4: Additional Diagnostics

If MTR results look clean but you are still experiencing issues, these additional tests can help narrow things down.

Check for Firewall Issues

A misconfigured firewall is one of the most common causes of connectivity problems. Check whether your firewall is blocking traffic:

# Check iptables rules
iptables -L -n -v
# Check if CSF is running (common on cPanel servers)
csf -l
# Check UFW status (common on Ubuntu)
ufw status verbose
# Check firewalld (common on CentOS/AlmaLinux)
firewall-cmd --list-all

Check DNS Resolution

Slow or broken DNS can make a server seem unresponsive even when the network is fine:

# Test DNS resolution speed
dig google.com
dig your-domain.com
# Check which nameservers are configured
cat /etc/resolv.conf

Check for Port-Specific Issues

If only certain services are unreachable (e.g. websites load but SSH doesn't connect), test specific ports:

# From your local machine, test if a port is open
nc -zv YOUR_SERVER_IP 80
nc -zv YOUR_SERVER_IP 443
nc -zv YOUR_SERVER_IP 22
# On the server, verify the service is listening
ss -tlnp | grep -E ':(80|443|22)\s'

Check Network Interface and Routing

# View interfaces and IPs
ip a
# View routing table
ip route
# Check for errors on the network interface
ip -s link show eth0

Look for RX errors, TX errors, or dropped counters that are increasing — these can indicate a hardware or virtualisation layer issue.

Check System Logs

# Check for network-related kernel messages
dmesg | grep -i -E 'network|eth0|link|nic|drop'
# Check system log for recent issues
journalctl -u systemd-networkd --since "1 hour ago"

Step 5: What to Include When Contacting Support

If you have completed the steps above and still need assistance, please open a support ticket and include the following:

1. Both MTR results — from your machine to the server AND from the server back to your machine. Attach them as a .txt file for readability.
2. When the problem started — date and time, and whether it is constant or intermittent.
3. What is affected — all traffic, only certain ports, only certain protocols, only from certain locations?
4. What you have already checked — firewall rules, DNS, service status, resource usage.
5. Your public IP address — so we can run tests from our side toward you.

The more information you provide upfront, the faster we can identify and resolve the issue.

Important Notes

• Do not use flood pings (ping -f). Most networks, including ours, will interpret this as an attack and may automatically block your IP or take your server offline.
• ICMP may be blocked on your local router or server. If the last hop in an MTR shows as unreachable but everything before it is fine, this is usually because ICMP is being filtered — not because there is actual packet loss.
• Asymmetrical routing is normal. Traffic from your machine to the server may take a completely different path than traffic going back. This is why testing in both directions is essential.
• Intermittent issues require timing. If the problem comes and goes, try to run MTR during the time when you are experiencing the issue. Results captured when things are working normally won't show the problem.