Troubleshooting VPS Connectivity Issues

If your server feels slow, keeps dropping, or you cannot connect at all, this guide walks you through diagnosing the problem yourself. The large majority of connectivity issues are resolvable at the customer level, and working through these steps will either fix the problem or give us the exact evidence we need to help you quickly.

Please work through this guide before opening a ticket. Connectivity problems have many possible causes, and most of them sit inside the server, your firewall, your local network, or your ISP's path to us. When you open a ticket we will ask for the diagnostic output described here anyway, so gathering it up front saves a round trip. Tickets that arrive with an MTR, ping logs, timestamps, and a clear description of what you have already tried get resolved far faster than "my server is down, please fix."

If, after exhausting these steps, you believe the issue is on our network or hardware, skip to the What to Send Us section. We will need proof.

Before you start: gather your details

Have these ready. You will need them for every test below and for your ticket.

• Your server's primary IPv4 address, and IPv6 address if assigned
• Your hostname, if you set one
• Your RackGenius service ID or the email your service is registered under
• The operating system on the VPS (Ubuntu 22.04, Debian 12, Windows Server 2022, and so on)
• The date and time the problem started, including your timezone
• The public IP address you are connecting from
• The ISP you are connecting through
• Your general location (state/region/province/etc)

Step 1: Confirm the scope of the problem

Narrow down what is actually broken before testing anything. Answer these for yourself:

• Is the server fully unreachable, or just slow and unstable? A total outage and intermittent packet loss are different problems with different causes.
• Is it constant or intermittent? If intermittent, how often does it drop, and for how long each time?
• Which services are affected? Can you reach SSH but not your website? Game server but not RDP or SSH? A single-service failure usually points to the server, not the network.
• What error do you actually see? "Connection timed out", "connection refused", "host unreachable", high latency, sessions dropping mid-connection, or a specific application error. Note the exact wording.
• Does it happen from more than one location? Try a phone on cellular data, a different network, or a friend's connection. If it works from one place and not another, the problem is very likely path or ISP related, not the server.
• Did anything change recently? A reboot, a firewall rule, a package update, a new service, a config edit, or a kernel change right before the problem started is the number one cause of "it suddenly stopped working." If the answer is yes, start by reverting that change.

Step 2: Rule out your own network and ISP

Saying "I checked my local network" is not enough for us to act on. Please actually verify the following:

• Test from a completely different network. Tether to your phone's mobile data or connect from another building. This is the fastest way to prove whether the problem follows you (your side) or stays with the server (our side).
• Reboot your own router and modem. Home gateways drop and mangle long-lived connections more often than people expect.
• Check whether other sites and services are stable from the same connection at the same time. If everything is flaky, the problem is your connection, not your VPS.
• Disable any local VPN, proxy, or security software temporarily and test again. These frequently interfere with SSH, RDP, and game traffic.
• Try a wired connection instead of Wi-Fi. Wireless packet loss looks exactly like server packet loss to most people.
• Confirm your ISP is not the bottleneck. Some residential ISPs deprioritize certain ports and destinations, and some have poor peering to specific networks at certain times of day. The MTR below will expose this.

If the problem disappears on another network, the issue is on your side or your ISP's, and we will not be able to fix it from our end.

Step 3: Test the path to your server

This is the most important section. These outputs are the evidence we need. Run these tests while the problem is happening, not after it clears up. A clean test taken during a good moment tells us nothing. Replace YOUR.SERVER.IP with your actual server IP in every command.

Continuous ping

A ping test shows packet loss and latency spikes over time.

Windows:

ping -t YOUR.SERVER.IP

Let it run for several minutes during the issue, then press Ctrl+C. Screenshot or copy the full output including the summary line showing packets sent, received, and lost.

Linux / macOS:

ping YOUR.SERVER.IP

Let it run, then press Ctrl+C for the loss summary. To capture with timestamps on Linux:

ping YOUR.SERVER.IP | while read line; do echo "$(date): $line"; done | tee ping-log.txt

Consistent latency with 0 percent loss is healthy. Latency spikes, gaps, or a nonzero loss percentage point to a real problem, and the traceroute or MTR will show where.

Traceroute

A traceroute shows every network hop between you and the server.

Windows:

tracert YOUR.SERVER.IP

Linux (install with sudo apt install traceroute if missing):

traceroute YOUR.SERVER.IP

macOS:

traceroute YOUR.SERVER.IP

MTR (strongly preferred)

MTR combines ping and traceroute and runs continuously, which makes intermittent loss easy to spot. If you can only provide one thing, provide this.

Windows: download and run WinMTR (a free graphical tool). Enter your server IP as the host, let it run for at least 100 packets during the issue, then export or screenshot the result.

Linux:

sudo apt install mtr
sudo mtr -rwzbc 100 YOUR.SERVER.IP

macOS:

brew install mtr
sudo mtr -rwzbc 100 YOUR.SERVER.IP

The -rwzbc 100 flags produce a clean report of 100 cycles with AS numbers and both hostnames and IPs, which is exactly the format we want.

Test in both directions

Path problems are often one-directional. If you can get into the server at all, even briefly or through the console, please also run an MTR from the server back to your IP:

sudo mtr -rwzbc 100 YOUR.PUBLIC.IP

Providing both directions helps us tell the difference between an inbound issue, an outbound issue, and your ISP's return path.

Reading an MTR: loss that appears at one middle hop but then clears on the following hops is usually a router deprioritizing ping replies, and is normal. Loss that starts at a hop and continues to every hop after it, all the way to the destination, is real loss at that point in the path. Note which network (AS number) that hop belongs to. If it is your ISP or a transit provider between you and us, we cannot fix it directly, though we can sometimes adjust routing. If the loss begins inside our network, that is exactly what we want to see and act on.

Step 4: Check the server itself via the console

If you cannot reach your server over the network, that does not always mean the network is down. The server may be up but unreachable because of a firewall lockout, a crashed service, or an overloaded system. Do not assume it is our network until you have looked at the server through the out-of-band console.

Every RackGenius VPS has console (VNC) access in the control panel that does not depend on the server's own network stack:

1. Log in to your VPS control panel.
2. Open your server and launch the console / VNC view.
3. See if the server responds. Can you log in directly at the console?

What this tells you:

• Console works, network does not: the server is running fine. The problem is almost certainly the server's firewall, a stopped SSH/RDP service, or the server's own network configuration. This is not a network outage on our side. See the common causes below.
• Console shows the server hung, panicked, or stuck at boot: the operating system has a problem. Check for a full disk, a bad recent change, or a failed update. A reboot from the panel is a reasonable first move.
• Console is completely dead and the server will not power on or boot at all: this is worth a ticket, but please include what the console shows (a screenshot of the panic, the boot screen, or the blank output).

Also check the power state and graphs in the panel:

• Is the VPS actually powered on?
• Do the CPU, memory, disk, and bandwidth graphs show anything unusual around the time of the problem? A pegged CPU, exhausted RAM, or a bandwidth spike changes the diagnosis entirely.

Step 5: Investigate the server's operating system

Once you are in over SSH, RDP, or the console, check the server's own health. A server that looks "down" from outside is very often a healthy server that has locked itself out or run out of a resource.

Resource usage

Linux:

uptime          # load average
free -h         # memory, check available and swap
df -h           # disk space, a full disk breaks almost everything
top   or   htop # live CPU and memory by process

Windows: open Task Manager and check CPU, Memory, and Disk. Open Resource Monitor for network activity per process.

A load average far above your CPU core count, memory at zero available with swap thrashing, or a disk at 100 percent full will all cause exactly the symptoms of unstable connectivity.

Networking on the server

Linux:

ip a              # confirm the interface is up with the right IP
ip route          # confirm the default gateway is present
ping -c4 1.1.1.1  # can the server reach the internet by IP?
ping -c4 google.com  # is DNS resolving?
ss -tulpn         # what is listening, and on which ports?

Windows:

ipconfig /all
ping 1.1.1.1
nslookup google.com
netstat -ano

If the server cannot ping 1.1.1.1 from its own shell but otherwise runs, that points to the server's network config or firewall, not a dead uplink.

Firewall and access control

This is the most common cause of "I can't connect but the server is clearly up." Check, in order:

Linux:

sudo iptables -L -n -v            # or: sudo nft list ruleset
sudo ufw status                   # if you use UFW
sudo fail2ban-client status       # list active jails
sudo fail2ban-client status sshd  # is YOUR IP banned?

If fail2ban or your firewall has banned your own IP after failed logins, unban it:

sudo fail2ban-client set sshd unbanip YOUR.PUBLIC.IP

Windows: check Windows Defender Firewall with Advanced Security for rules blocking RDP (3389) or your application ports, and confirm the source IP is not being blocked.

Service and system logs

Linux:

sudo systemctl status ssh   # or sshd, nginx, your game server, etc.
sudo journalctl -xe --no-pager | tail -n 100
sudo dmesg | tail -n 50     # kernel messages, look for OOM kills and NIC errors

Look specifically for "Out of memory: Killed process" in dmesg, which means the server ran out of RAM and the kernel killed something important.

Windows: open Event Viewer and review the System and Application logs around the time of the problem.

Common causes and how to fix them

Before escalating, check whether your issue matches one of these. Most tickets we receive turn out to be one of them.

• You locked yourself out with fail2ban or a firewall rule. Failed logins, a new firewall rule, or a security tool banned your own IP. Fix it from the VNC console using the commands above.
• The server ran out of memory. An OOM event killed SSHd, your web server, or your game server. Check dmesg, add swap, or size up your plan. The server stays up but the service you rely on is dead.
• The disk is full. A full disk stops logging, breaks databases, and prevents new connections. Run df -h, clear space, and rotate logs.
• A service crashed or was never restarted after a reboot. The OS is up, but SSH, RDP, or your application is not running. Start it and enable it to start on boot.
• A recent change broke networking. A netplan, /etc/network/interfaces, resolv.conf, or firewall edit took the interface or DNS down. Revert it from the console.
• DNS is failing, not connectivity. The server can reach IPs but not names. Fix your resolver config. Your site "being down" is sometimes just DNS.
• Your ISP has a bad path to us at certain times. An MTR shows loss beginning at an intermediate provider, not our network. This is real, but not something we can fix from our side, though we can sometimes adjust routing to help.
• Wi-Fi or local network packet loss. Looks identical to server loss until you test from another network. Always test from mobile data.
• You are hitting a rate or connection limit you configured (SSHGuard, connection throttling, application-level limits).
• You are the target of a DoS or DDoS. If your bandwidth graph is pegged and the server is drowning in traffic to one port, tell us. We handle this, but we need to see it. Do not just say "unstable", show us the traffic.
• The application, not the server, is the problem. A game server that crashes, a web app leaking memory, or a stopped database will all present as "the server is down" when the server itself is perfectly reachable.

What counts as proof

If you have found something and believe it is on our end, we need evidence, not a description. Please attach the actual output. Specifically:

• MTR reports from your side to the server, and from the server back to you, captured during the problem, showing where loss or latency begins. This is the most valuable single item.
• Continuous ping logs with the loss summary and, ideally, timestamps.
• Traceroute output if you cannot run MTR.
• Exact timestamps with timezone for each failure, so we can line them up against our upstream, switch, and router logs.
• The IP you are connecting from, so we can trace the same path.
• Console screenshots if the server is hung, panicked, or stuck at boot.
• Relevant log excerpts (dmesg, journalctl, service status, Event Viewer) if the failure is on the server.
• Bandwidth or resource graphs from the panel if the issue correlates with a spike.
• A clear statement of what you already tested and ruled out (other networks, reboots, firewall, disk, memory).

"It's slow" or "it keeps disconnecting" with nothing attached will unfortunately be sent back to this guide, because we genuinely cannot act on it. Help us help you by bringing the data.

What to send us when you open a ticket

Include the following in your ticket, filling in each field:

1. Service ID or server IP:
2. Operating system:
3. Connecting from (your public IP):
4. Your ISP:
5. When it started (date, time, timezone):
6. Constant or intermittent (and how often):
7. Exact error message you see:
8. Affected services (SSH / RDP / web / all):
9. Does it happen from another network (mobile data, etc.)?
10. Recent changes before it started (reboot, firewall, update, config):
11. Console / VNC access working? (yes / no / server hung):
12. Server resource state (CPU / RAM / disk from console or panel):
13. Troubleshooting already completed:
14. Attached evidence (MTR to server, MTR from server, ping log, timestamps, screenshots, logs):

The more of this you provide, the faster we can resolve it. A complete ticket with an MTR often gets a real answer on the first reply.

What we will do on our side

Once we have your evidence, here is what we check so you know it is being taken seriously:

• We correlate your timestamps against our upstream transit and peering status and our switch and router logs.
• We review the path your traffic takes into and out of our network, and look at where your MTR shows loss.
• We check the host node your VPS lives on for saturation, errors, or hardware issues.
• We look for network events (upstream flaps, congestion, maintenance) that line up with your timestamps.
• If the problem is on our network or hardware, we fix it and update you. If the evidence points to your ISP's path, a change on your server, or your local network, we tell you exactly what we see and, where possible, help you interpret it or adjust routing.

We would much rather receive a well-documented ticket and dig into a real problem than send you back to square one. Working through this guide first is what makes that possible. Thank you for helping us get to the root cause quickly.