How to Fix Common VPS Connection Problems

Introduction

A VPS connection problem can prevent you from managing your website, application, database or server even when the virtual machine itself is still running.

The cause is not always the VPS provider. A failed connection can result from an incorrect IP address, DNS problems, a blocked firewall port, a stopped SSH or RDP service, incorrect credentials, an overloaded server, network-security rules or a configuration change that prevents remote access.

The troubleshooting process has also changed considerably since older VPS guides were published. Modern cloud VPS environments commonly include multiple layers of network security, including the operating-system firewall, provider-level firewalls, security groups, network ACLs and private networking.

Important: Before changing SSH, firewall or RDP configuration, make sure you have an alternative recovery method such as a provider console, serial console, rescue environment or out-of-band management. A configuration mistake can otherwise lock you out of the server.

Table of Contents

1. What Causes VPS Connection Problems?
2. Start With a Basic VPS Connectivity Check
3. Linux VPS Connection Problems
   • SSH Connection Timed Out
   • SSH Connection Refused
   • SSH Authentication Failed
   • SSH Connection Drops
   • Firewall and Port Problems
4. Windows VPS and RDP Connection Problems
   • RDP Is Not Enabled
   • RDP Port or Firewall Problems
   • DNS and IP Address Problems
   • Remote Desktop Service Problems
   • Performance and Resource Problems
5. How to Troubleshoot VPS Connection Problems Systematically
6. VPS Connection Troubleshooting Checklist
7. Frequently Asked Questions
8. Conclusion

What Causes VPS Connection Problems?

There are several possible causes of VPS connection issues, and identifying the type of failure is the first step toward solving it.

Common causes include:

• Incorrect VPS IP address or hostname
• DNS resolution problems
• Incorrect username or password
• Invalid or unavailable SSH key
• SSH service not running
• RDP service not running
• Firewall blocking the connection
• Cloud security group blocking the port
• Incorrect network configuration
• Wrong SSH or RDP port
• IP address temporarily blocked by security software
• Server resource exhaustion
• Network outage
• Provider-side maintenance
• Incorrect SSH or RDP configuration
• Operating-system updates or configuration changes

The exact error message can provide an important clue.

For example:

Do not immediately change configuration based on the error alone. First determine where the connection is failing.

Start With a Basic VPS Connectivity Check

Before changing server configuration, verify that the VPS is actually running.

Log in to your VPS provider’s control panel and check:

1. Is the VPS powered on?
2. Does it have the expected public IP address?
3. Is there a provider-level outage?
4. Has the public IP changed?
5. Are there firewall or security-group rules blocking access?
6. Is the server reporting high CPU, RAM or disk usage?
7. Is the network interface healthy?

If your provider offers a web-based console or serial console, try it.

This is particularly useful because it separates server-side problems from network-access problems.

If the console works but SSH or RDP does not, the VPS itself may be running correctly while the remote-access service or network path is causing the problem.

Microsoft’s current RDP troubleshooting guidance similarly recommends checking the machine’s state and using console access where available before moving on to listener and network diagnostics.

Linux VPS Connection Problems

Linux VPS instances are commonly managed through SSH (Secure Shell).

OpenSSH provides encrypted remote administration and file-transfer capabilities and is included in the standard Linux server ecosystem. Ubuntu’s current documentation recommends using /etc/ssh/sshd_config and configuration snippets under /etc/ssh/sshd_config.d/ for SSH server configuration.

Let’s look at the most common Linux VPS connection problems.

SSH Connection Timed Out

A message such as:

ssh: connect to host example.com port 22: Connection timed out

usually indicates that your SSH client cannot establish a connection to the server on the specified port.

Possible causes include:

• VPS is offline
• Wrong IP address
• Port 22 is blocked
• Provider firewall is blocking SSH
• VPS operating-system firewall is blocking SSH
• Network routing problem
• SSH is configured on another port
• Server is overloaded or unreachable

Start by checking whether the hostname resolves correctly.

From a local machine, you can test the port with tools appropriate to your operating system. On Windows PowerShell, for example:

Test-NetConnection YOUR_SERVER_IP -Port 22

If the test fails, inspect the provider firewall and the server’s firewall before changing SSH configuration.

If SSH uses a non-standard port, test that port instead:

Test-NetConnection YOUR_SERVER_IP -Port 2222

Replace 2222 with the actual configured port.

SSH Connection Refused

A different error is:

ssh: connect to host example.com port 22: Connection refused

This generally means the host was reachable but nothing accepted the connection on that port.

Possible causes include:

• SSH service is stopped
• SSH is listening on another port
• Firewall is rejecting traffic
• SSH configuration is invalid
• The service failed after a configuration change

If you have console access, check the SSH service.

On a system using systemd:

sudo systemctl status ssh

On some distributions the service may be named sshd:

sudo systemctl status sshd

You can also check whether something is listening on port 22:

sudo ss -lntp | grep :22

If you recently modified SSH configuration, validate it before restarting the service:

sudo sshd -t

Ubuntu’s current OpenSSH documentation specifically recommends testing the configuration with sshd -t before restarting SSH because an invalid configuration can prevent the service from starting and potentially lock you out of the server.

SSH Authentication Failed

If you can reach the server but receive:

Permission denied

the problem is usually authentication rather than network connectivity.

Check:

• Username
• Password, if password authentication is enabled
• SSH private key
• Key file permissions
• authorized_keys
• SSH authentication configuration
• Whether the account is locked
• Whether the account is allowed to log in through SSH

For key-based authentication, make sure the public key is present in the user’s:

~/.ssh/authorized_keys

Ubuntu’s documentation also highlights checking the permissions of authorized_keys when troubleshooting SSH key authentication.

For additional information, inspect SSH logs.

On many systemd-based distributions:

sudo journalctl -u ssh

or:

sudo journalctl -u sshd

The exact service name depends on the Linux distribution.

SSH Connection Drops

A connection that works initially but repeatedly disconnects can have several causes.

Potential causes include:

• Unstable client network
• Unstable server network
• Idle connection timeouts
• Firewall session timeouts
• VPN interference
• Server overload
• SSH configuration
• Provider networking problems

For long-running work, don’t rely on a normal SSH session alone.

Use a terminal multiplexer such as tmux:

tmux

If your SSH connection drops, reconnect and run:

tmux attach

The process can continue running on the server even if your SSH connection disappears.

Ubuntu’s current server documentation specifically recommends terminal multiplexers such as tmux or screen for unstable SSH connections because the session can continue independently of the SSH connection.

Using SSH Keepalive Settings

OpenSSH also provides keepalive mechanisms.

For example, ClientAliveInterval controls how frequently the SSH server sends a message through the encrypted channel when no data has been received from the client.

A configuration might look like:

ClientAliveInterval 60

ClientAliveCountMax 3

However, don’t blindly add keepalive settings to every server. First determine whether an idle timeout is actually causing the disconnection.

Firewall and Port Problems

Firewalls are among the most common causes of VPS connection problems.

There may be more than one firewall between your computer and your VPS:

Your computer → Internet → provider firewall/security group → VPS firewall → SSH/RDP service

Every layer needs to allow the required traffic.

For Linux, check whichever firewall system your distribution uses, such as:

• UFW
• firewalld
• nftables
• iptables

For example, with UFW:

sudo ufw status

If SSH is supposed to use the standard port:

sudo ufw allow 22/tcp

Do not run firewall commands blindly on a production VPS. Verify the actual SSH port and ensure you have another recovery path before changing firewall rules.

Windows VPS and RDP Connection Problems

Windows VPS servers are commonly accessed through Remote Desktop Protocol (RDP).

Microsoft’s current troubleshooting documentation recommends checking the RDP protocol, Remote Desktop Services, the RDP listener, the listening port and network/firewall configuration when an RDP connection fails.

RDP Is Not Enabled

If Remote Desktop is disabled, the client cannot establish a normal RDP session.

Check the server configuration and make sure remote connections are permitted.

If you have console access, verify the Remote Desktop configuration before troubleshooting the network.

Microsoft also identifies machine availability and remote-access configuration as fundamental checks when RDP cannot connect.

RDP Port or Firewall Problems

The standard RDP port is:

3389

Both TCP and UDP 3389 can be used by standard RDP configurations.

You can test connectivity from a Windows client using:

Test-NetConnection SERVER_IP -Port 3389

If:

TcpTestSucceeded : True

the network path to that TCP port is working.

If it returns False, investigate:

• Windows Firewall
• Provider firewall
• Cloud security group
• Network ACL
• NAT rules
• RDP port configuration

Microsoft recommends checking the RDP firewall rules and the RDP listener when troubleshooting connectivity.

Do Not Automatically Change RDP to Another Port

The original version of this article recommended changing RDP back to port 3389.

That is too simplistic for a modern VPS.

RDP can be configured to listen on a different port, so the important question is which port your server is actually configured to use.

Microsoft’s current documentation confirms that 3389 is the default but that administrators can configure another listening port. If you change it, the corresponding firewall rules and client connection settings must also be updated.

Changing the port is not a substitute for proper authentication, firewall restrictions and network security.

DNS and IP Address Problems

Sometimes the VPS is perfectly healthy but the hostname points to the wrong address.

If:

ssh server.example.com

fails, try connecting directly to the VPS IP:

ssh user@203.0.113.10

For RDP, you can similarly test the IP address instead of the hostname.

If the IP works but the hostname does not, investigate:

• DNS records
• DNS propagation
• Local DNS cache
• Incorrect A/AAAA records
• IPv4 versus IPv6 configuration

Microsoft’s RDP guidance also recommends trying the IP address when a hostname cannot be reached because DNS resolution may be the source of the problem.

Remote Desktop Service Problems

If the Windows VPS is running but RDP isn’t responding, check whether the Remote Desktop Services service is functioning.

You can also check whether the RDP listener is active.

Microsoft recommends checking the RDP-TCP listener and verifying that the expected port is listening. It also provides Test-NetConnection as a diagnostic method.

From an elevated PowerShell session, you can test:

Test-NetConnection SERVER_IP -Port 3389 -InformationLevel Detailed

If the connection reaches the machine but RDP still fails, investigate the RDP service, listener, authentication and Windows configuration rather than continuing to change firewall rules.

Performance and Resource Problems

Sometimes what appears to be a VPS connection problem is actually a resource problem.

A severely overloaded VPS may become slow or stop responding to management connections.

Check:

• CPU usage
• RAM usage
• Swap usage
• Disk space
• Disk I/O
• Network bandwidth
• Number of active processes
• System load

On Linux:

uptime

free -h

df -h

top

On Windows, use Task Manager, Resource Monitor or Performance Monitor.

If the VPS repeatedly runs out of memory, for example, SSH may become extremely slow or fail while the underlying server is technically still running.

Also check whether a recent deployment caused the problem.

A new application, database process, backup job, security scanner or container workload can consume substantially more resources than expected.

How to Troubleshoot VPS Connection Problems Systematically

Instead of trying random fixes, follow this sequence.

Step 1: Confirm the VPS is running

Check your hosting provider’s dashboard.

Step 2: Confirm the IP address

Make sure you’re connecting to the current public IP.

Step 3: Test DNS

If you’re using a hostname, verify that it resolves to the correct address.

Step 4: Test the required port

For SSH:

Port 22

For RDP:

Port 3389

Or use the custom port configured on your server.

Step 5: Check provider-level firewall rules

Cloud firewalls and security groups can block traffic before it reaches your VPS.

Step 6: Check the operating-system firewall

Review UFW, firewalld, nftables or Windows Firewall.

Step 7: Check the service

For Linux:

systemctl status ssh

For Windows, check Remote Desktop Services.

Step 8: Check the listener

Verify that SSH or RDP is actually listening on the expected port.

Step 9: Check authentication

If the network connection works but login fails, investigate credentials, keys, permissions and account restrictions.

Step 10: Check server resources

Look for CPU, RAM, disk and network exhaustion.

Step 11: Review logs

Logs can tell you whether the connection is being rejected, authenticated and disconnected, or never reaching the service.

Step 12: Use provider recovery tools

If you have completely lost remote access, use the provider’s web console, rescue mode, serial console or recovery environment.

VPS Connection Troubleshooting Checklist

Frequently Asked Questions

Why can’t I connect to my VPS?

The most common causes include an incorrect IP address, blocked SSH/RDP ports, firewall rules, stopped remote-access services, DNS problems, authentication failures and server resource exhaustion.

Start by determining whether the VPS is running and whether the required port is reachable.

Why does SSH say “Connection timed out”?

An SSH timeout usually means the connection cannot reach the SSH service successfully. Check the VPS status, IP address, provider firewall, operating-system firewall, routing and SSH port.

Why does SSH say “Connection refused”?

A refused SSH connection usually indicates that the server is reachable but the expected port is not accepting connections. Check whether sshd or ssh is running and whether it is listening on the expected port.

Why is my RDP connection not working?

Check whether Windows Remote Desktop is enabled, whether Remote Desktop Services and the RDP listener are functioning, and whether the correct port is allowed through Windows Firewall and any provider-level firewall or security group. Microsoft identifies these as core areas of RDP troubleshooting.

Is port 3389 always required for RDP?

No. Port 3389 is the default RDP port, but Windows Server can be configured to use another port. If a custom port is configured, the firewall and RDP client must use the corresponding port.

How can I prevent SSH sessions from being lost?

For long-running tasks, use tmux or screen so the process continues even if your SSH connection drops. SSH keepalive settings can also help with certain idle or unstable connection scenarios.

What should I do if I accidentally lock myself out of my VPS?

Use your hosting provider’s web console, serial console, rescue environment or another out-of-band management method if available. Avoid repeatedly changing firewall or SSH configuration remotely when you have no recovery path.

Conclusion

Start with the basics: confirm that the VPS is running, verify its IP address, test DNS resolution and check whether the required SSH or RDP port is reachable.

For Linux servers, investigate the SSH service, listening ports, authentication, firewall rules and system logs. For Windows VPS environments, check Remote Desktop configuration, the RDP listener, port 3389 or the configured alternative port, Windows Firewall and provider-level network rules. Microsoft’s current guidance specifically recommends checking the RDP protocol, service, listener and network configuration rather than treating every RDP error as the same problem.

For SSH, be especially careful when editing sshd_config. Validate configuration with sshd -t before restarting the service, and maintain a recovery method in case the configuration prevents SSH from starting.

The most important principle is simple:

Don’t troubleshoot a VPS connection problem by guessing. Test each layer—from the server and DNS to the port, firewall, service and authentication—until you find exactly where the connection is failing.

That approach is safer, faster and much more reliable than repeatedly restarting the VPS or changing random settings.