Server not opening from your network: how to check and what we can do

It happens: the server shows “Running” in the panel (that means the virtual machine is started, but it does not guarantee there is a path to it from your network), while SSH is silent, the site does not open and the bot does not reply. The first thought is usually: “the server is broken, let them change the IP or refund me”. Before doing that, it is worth spending five minutes to find out one thing: is the server not working at all, or is it not working only for you? Everything else depends on the answer. Below is how to check it yourself, how to read the result and what position HIP support takes in such cases.

In short. We are responsible for the server and for making it reachable from the internet. The path from your device to us goes through your provider and other networks, and there may be restrictions there that we cannot influence. So if the server opens from other networks, the problem is not the server: in that case we do not change the IP address and do not issue a refund. How to make sure in five minutes that this is the case is below.

What we are responsible for and what we are not

The path from your computer to the server consists of several segments: your router, your internet provider, the backbone networks between countries and, finally, our data centre. We are responsible for the last segment: the server is on, the network up to it works, the address is routed to the world.

We cannot influence the other segments. That includes restrictions introduced by internet providers and traffic filtering systems at country level. Such restrictions have unpleasant properties:

• They depend on location. In one country or at one provider an address opens, at another it does not. Sometimes there is a difference even between mobile and home internet at the same operator.
• They are irregular. It worked yesterday, not today, and again in a week. Neither we nor anyone else can predict this in advance.
• They do not depend on server settings. Rebooting, reinstalling the system and editing the firewall do not help here: the server was healthy and stays healthy.

We try to make our addresses reachable from as many networks as possible. But nobody can guarantee reachability from a particular network of a particular provider, and we will not promise what we do not control.

A 5-minute check: is the server down or does it just not let you in

The idea is simple: look at the server from several sides. If it answers from everywhere except your network, the problem is on your side of the path. If it answers nowhere, the problem is the server or us.

Step 1. Check from another network

The fastest test, no tools needed. Turn on mobile data on your phone, turn off Wi-Fi and open the site on the server or connect over SSH from a terminal on your phone. You can also share your phone’s internet with your computer and repeat what did not work.

• Works from mobile, not from home - the restriction is on your home provider’s side.
• Does not work anywhere - go to step 2.

Step 2. Check from outside nodes with ping.pe

1. Open ping.pe. In the box at the top enter the server address and the port separated by a colon: for example, 203.0.113.10:22 for SSH or 203.0.113.10:443 for a website.
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 you should not rely on ping: some servers and networks deliberately do not answer it even though SSH and the site work. So look first at the port check.
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 our server in Helsinki, taken on 1 October 2026. The original has about 170 rows; nodes from different countries are picked here:

What you can see here:

• Almost everywhere successful, and the time grows with distance: Helsinki answers in 1.59 ms, Stockholm in 6.81 ms, Warsaw in 19 ms, Frankfurt in 31.76 ms, New York in 91.57 ms, Sydney in 305.58 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 or its provider can have their 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.

This is what a healthy server looks like: answers from almost everywhere, with time growing with distance. If you see the same picture and the server does not open from your device, the server is healthy and the restriction is on your part of the path.

If almost all rows are red (for both the port and ping), check whether the server is switched off and whether a firewall closed the needed port. That is a check inside the server: see the next steps and the web console guide.

Step 3. See where the route breaks

The mtr command (tracert on Windows) shows the chain of intermediate nodes from you to the server and at which of them answers disappear. It is useful, for example, to show your provider exactly where the answers disappear.

On Windows open PowerShell and run (use your own IP):

On macOS and Linux, if mtr is installed (it is usually absent on macOS, then use traceroute -n YOUR_IP):

The option -r prints a final report instead of a live table, -w does not truncate long addresses, -n does not waste time on names, -c 10 makes 10 probes per node.

Read the result by the last row and by how the rows after it behave. An example of a normal route (from our server to a node in Moscow: the direction is reverse, and the return path may even go differently, but the result is read the same way):

Note the second row: ??? and 100% loss. It looks like a failure, but it is not. Many routers on the way simply do not answer service requests while passing your traffic through. You can see it from the following rows: there is no loss, and the last node (the sixth row) answers with 0% loss. The rule is: look at the last row. If the final node answers without loss, the route works, whatever “???” stand in the middle.

A bad sign is when loss starts at some node and stays on all the following ones up to the last one, and the final address does not answer at all. That picture says the problem is not only yours: the server answers no one. Then look for the cause on the server itself, as described in the next steps.

Step 4. Check a specific port

Sometimes ping works but SSH or the site does not. That means the address is alive but the needed port is closed: on the server, in a firewall or by someone on the way. A check from your computer (if you changed the SSH port, use your own instead of 22):

Windows (PowerShell):

In the answer look for the line TcpTestSucceeded: True means the port is open, False means it is not.

macOS and Linux:

The phrase succeeded means the port is open. If you see refused, you reached the server but nothing listens on this port (the service is not running). If timed out, packets are lost on the way: a firewall or filtering. For a website replace 22 with 80 or 443.

If you open a site by domain, note one more cause. A domain can have both an IPv4 address (A record) and an IPv6 address (AAAA record). If your IPv6 is broken, the site may not open even though IPv4 is fine. Check the server by the plain IPv4 address, as in the examples above.

If the port opens on ping.pe (an address:port query) but not for you, the restriction is on your side of the path. If it opens nowhere, check the firewall on the server itself (ufw status), as shown in the guide Securing a fresh VPS.

Step 5. Look at the server through the web console

In the panel open the server page, the tab Console. This is a direct connection to the server screen through the panel, bypassing the network and SSH. If the console opens and you can log in, the server works. If the server is off, switch it on in the panel, wait a minute and refresh the console. More details are in the guide HIP web console: how to get onto the server.

The console may not open the first time, especially for a switched-off server: wait a minute and refresh the page.

How to read the result: what you see and what it means

What we can do and what we cannot

We understand how upsetting it is when a server is paid for and works properly but does not open for you. But we have a line of responsibility: 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 opens from other networks, we consider the service to be working as it should. In that case:

• We do not change the IP address. A new address from our own range may be just as unreachable at your provider: such restrictions are not tied to a particular server and cannot be predicted in advance. We cannot promise that a replacement will 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. The settings of services on your server are your area. They may affect how visible traffic is to filtering systems, but there are no guarantees here and we cannot support such settings.

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 server does not answer from everywhere, the problem is not your network. Check that the server is on and the port is not closed by a firewall (steps 4 and 5 above).

What to do if the server is unreachable only for you

1. Work from a network where the server answers. For administration this can be mobile internet or another provider.
2. Ask your provider. Most often the cause is with them or an upstream operator, and they can find out why traffic to this address does not pass and, if they wish, lift the restriction. Give them the address and the check results: that it opens from other networks.
3. Wait. Such restrictions can be temporary and change without our involvement.
4. Do not reinstall the system or recreate the server. It will change nothing: the problem is not the server, and you will lose data.

What to keep from the check

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

• The address and port you checked.
• The link to the ping.pe result. Under the table there is a button Save snapshot: it gives a permanent link, copy it. With it the provider will see the same thing you see.
• The result of mtr or tracert as text. Not as a screenshot if possible: text is easier to read and to search for addresses in.
• When it started and what you did by that moment: changed settings, rebooted a computer or a router.
• Which network you checked from: which provider and country, and what you saw from mobile internet.

FAQ

Why does everything work on a friend’s identical server?

Restrictions depend on the provider, the region and even the specific address. The same server can open for one person and not for another. That does not mean something is wrong with yours.

Can I change the IP address?

If the server is reachable from outside networks, no. A new address does not guarantee the restriction will disappear, and we cannot guarantee it. If the server does not answer from anywhere, that is a different case: then look for the cause on the server itself.

Will you refund me if it does not open for me?

If the server works and is reachable from outside networks, no: the service has been delivered. If the server does not answer from anywhere, we consider that something is wrong with it, and the cause should be looked for on the server itself.

Ping works but SSH does not. Is this blocking?

Not necessarily. Most often the port itself is closed: a firewall on the server, the ssh service is not running or a wrong setting. Compare the result with ping.pe (an address:22 query) and check the server through the web console.

It worked yesterday, not today. What changed?

First check the server with ping.pe and the web console. If it answers from outside, the path to it in your network or restrictions at your provider have changed. If it does not answer, see the table above: perhaps something changed inside the server.

ping.pe shows green but it does not open for me. What next?

This is exactly the situation “the server is healthy, the restriction is on your side”. Check from another network, ask your provider. We cannot help further, but it is better to keep the check results: they will be useful in a conversation with the provider.

Summary

Before looking for the cause in the server, spend five minutes: check it from another network, run ping.pe and look at the route. If the server answers from outside, the cause is on your part of the path, and there is nothing to change the address or refund for. If it answers nowhere, go to steps 4 and 5: most likely the problem is on the server itself (firewall, service).