VPS not opening: is the server broken or is your provider in the way? A five-minute check

You open the client area: the service is active and paid. But SSH is silent, Remote Desktop will not connect, the site on the server does not load. The first thought is: “the server is broken, let them replace it or refund me”. Sometimes, though, the server is perfectly fine and it is only the path from you to it that is not working. These are two different situations and they are solved differently. Below is a way to tell them apart and what to do in each case.

In short. Check the server from another network and with the free ping.pe service. If it answers from outside and not from your side, it is healthy and the restriction sits with your provider or further along the route. We cannot influence such restrictions, so in this case we do not change the IP address and do not issue a refund: the service works as it should.

Two different problems with the same symptom

From the outside both look the same: “I cannot connect”. But the causes differ.

• The server really is down. It has hung, something inside has crashed, a port is closed, or there was an incident on the data centre side. It does not answer anyone, from any country.
• The server works, but it cannot be reached from your network. Your provider or an operator further up the chain does not let traffic through to this address. From other networks it opens without problems.

We are responsible for the first case and will help. We cannot influence the second: restrictions are introduced by providers and traffic filtering systems, they depend on the country, the operator and even the connection type, and they can appear and disappear without warning. So the first thing to do is understand which case you have.

Step 1. Open the server from your phone

The quickest check. Turn off Wi-Fi on your phone, keep mobile data on and try to open the site on the server or connect to it. Another option: share your phone’s internet with your computer and repeat what did not work.

• Works from mobile but not from home: the restriction is with your home provider.
• Does not work in either place: move on.

Step 2. Ask a third-party service: ping.pe

ping.pe is a free site that checks your address from many countries at once. No registration needed.

1. Open ping.pe. In the box at the top enter the server IP and the port separated by a colon. For SSH that is port 22, for Windows Remote Desktop 3389, for a website 80 or 443. For example: 203.0.113.10:22.
2. Press Go (or Enter). The service understands you are checking a port and runs a TCP check. If you enter only an address without a port, it checks ping, but do not trust ping blindly: some networks deliberately do not answer ping even though the port is open. That is why the port is more reliable.
3. Wait a few seconds: rows appear as answers come in.

The table has two columns: Location (where the check came from) and the result. A green successful and a time in milliseconds mean the node reached the port. A red failed means there was no answer.

Here is a real result of a port 22 check for one of our servers in the Netherlands, taken on 1 October 2026. The original has about 170 rows; nodes from different countries are picked here:

How to read it:

• Almost everywhere successful, and the time grows with distance: Amsterdam answers in 12.22 ms, Frankfurt in 17.85 ms, London in 21.09 ms, Helsinki in 30.14 ms, New York in 71.76 ms, Sydney in 273.05 ms.
• A few nodes (Chengdu in the screenshot) showed failed although the server is healthy. A couple of red rows among hundreds of green ones prove nothing: the checking node itself can have its own trouble. Look at the overall picture and at the countries closest to you.
• Under the table there is a link Save snapshot: it saves the result and gives you a permanent link to it. It is worth keeping.

Step 3. See where the route breaks

The command shows every node on the way to the server and where answers disappear. Open PowerShell or a terminal and run (replace YOUR_IP with the server address):

Windows:

tracert -d YOUR_IP

macOS and Linux (if mtr is not installed, use traceroute -n YOUR_IP):

sudo mtr -rwn -c 10 YOUR_IP

What the options do: -r prints a final report, -w does not truncate addresses, -n does not resolve names (faster), -c 10 is ten probes per node.

Read the result from the end. Here is an example of a result to our server in the Netherlands (measured on 1 October 2026):

By eye there seem to be two “failures” here: the fourth row loses 40% of packets, the second one loses 100%. But this is a false alarm. Many routers deliberately answer service requests selectively while passing transit traffic normally. The proof is all the rows below: they have no loss, and the last one (that is the server) answers 100%. The rule is simple: if the last node answers without loss, the route works, whatever happens in the middle.

An alarming picture is the opposite: loss starts at some node and holds all the way to the end, and the server does not answer. That picture says the problem is not only yours: the server does not answer anyone.

Step 4. Check the port from your computer

Sometimes the address answers but the service you need does not. Check the port directly.

Windows, PowerShell (port 22 for SSH, 3389 for Remote Desktop; if you changed the port, use your own):

Test-NetConnection YOUR_IP -Port 3389

Look for the line TcpTestSucceeded. True means the port is open, False means it is not.

macOS and Linux:

nc -vz YOUR_IP 22

The word succeeded means the port is open. refused means you reached the server but nothing listens on this port: the service is not running or is closed by its settings. timed out means packets are lost on the way: a firewall or filtering.

If you open a site by domain, the domain can have both an IPv4 address (A record) and an IPv6 address (AAAA record). With broken IPv6 the site may not open for you even though everything works over IPv4. Check using the plain IPv4 address.

What the result showed and what to do

What we can do and what we cannot

We understand how frustrating it is when a server is paid for and running but does not open for you. Our line of responsibility is simple, though: we are responsible for the server and the network up to the exit to the internet, while the path from you to us depends on your provider and the networks along the way.

So when the server answers from outside networks, we consider the service to be working as it should. In that case:

• We do not change the IP. A new address from our own network may be just as unreachable at your provider. Restrictions are not tied to your server and cannot be predicted in advance, so changing the address “just in case” does not help.
• We do not issue a refund. The server works and the network up to it is healthy.
• We do not advise how to bypass restrictions. What runs on your server and how it is configured is your area; we cannot support such settings and guarantee nothing.

We try to make our addresses open from as many networks as possible, but nobody can guarantee access from a particular network of a particular provider.

If the problem is only yours

1. Work from a network where everything opens. For example, mobile internet.
2. Write to your provider. Give them the server IP and say that it opens from other networks. Most often the cause is at the provider or an operator above it, and only they can lift the restriction.
3. Wait. Such restrictions are often temporary.
4. Do not reinstall the system. The server is healthy and you will lose your data.

What to keep from the check

The check results will help make the conversation with your provider concrete. Keep:

• the IP address and port you checked;
• the link to the ping.pe result: the button Save snapshot under the table gives a permanent link, and the provider will see the same thing you do;
• the result of tracert or mtr as text, not a screenshot;
• when it started and what you did before that: changed settings, restarted a computer or a router;
• which network you checked from: provider, country, whether you tried mobile internet.

FAQ

It works on a friend’s identical server. Why not on mine?

Restrictions depend on your provider, region and connection type. The same address can open for one person and not for another.

Can I change the IP address?

If the server is reachable from outside networks, no, it does not guarantee a result. If the server does not answer from anywhere, that is a different case: the cause is no longer your provider’s restrictions.

Will you refund me?

If the server works and is reachable from other networks, the service has been delivered and there is no refund. If the server does not answer from anywhere, the cause is no longer your provider’s restrictions.

Ping works but Remote Desktop or SSH does not. Is this blocking?

Not necessarily. Most often the port itself is closed. Check it with ping.pe (an address:port query) and from your computer, as in step 4.

It worked yesterday, not today. What changed?

Check the server with ping.pe. If it answers from outside, something changed on the path to it in your network. If it answers nowhere, see the table above.

Summary

Before asking for a replacement or a refund, spend five minutes on the check: phone, ping.pe, route. If the server answers from outside, the cause is on your part of the path and there is nothing to change the address for. If it answers nowhere, the cause is no longer your provider’s restrictions: see the table above.

🎁 40% off the first month of a new VPS. Promo code GUIDE40
Need a second server to compare access from different networks? First month at a discount.
Enter GUIDE40 at checkout. One use per customer.
Pick a VPS and claim the discount →