Server pings but website won't load from Russia: how to check your IP

A familiar situation: the server is purchased, the site is up, everything loads in milliseconds from Europe. Then a user in Russia writes that the page won't open. You check the ping — it responds. You check the port — it's open. Support replies that everything is fine on their end, and technically they're right. Meanwhile, half your visitors genuinely cannot access the site.

This is what a block on a specific IP address by Russian ISPs looks like. It's invisible to standard tools, which is exactly why disputes about it drag on for days. Let's break down how to check an address properly, how to interpret the results, and what to do next.

Why standard checks show a green light

Most online availability checkers place their probes in data centers. It's convenient and cheap: a server in a rack runs around the clock and has a wide channel. But traffic filtering by ISPs is configured not for data centers, but for residential and mobile networks — where real people are.

This creates a trap. You run a check, see "Moscow — 20 ms, port open," show the screenshot to your hosting provider, and hear that the problem is on your end. Meanwhile, a home user on MTS or Rostelecom can't open the site at all.

We ran into this in support: a client insisted the server was unreachable, while our measurements from Moscow showed stable 17–24 ms across three consecutive runs. Both sides were right. The address responded from data centers and went silent on residential networks.

How to check an address from residential networks

You need a service that has probes specifically on user networks. Globalping works well — its probes are tagged, and among them is the eyeball-network tag, meaning end-user networks. You can check directly in the browser at globalping.io by selecting country RU and that tag, or via a terminal request.

# ping from ten Russian residential networks
curl -s -X POST https://api.globalping.io/v1/measurements \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "ping",
    "target": "YOUR_IP",
    "measurementOptions": { "packets": 4 },
    "locations": [{ "country": "RU", "tags": ["eyeball-network"], "limit": 10 }]
  }'

The response will contain a measurement ID; the result is retrieved with a second request a few seconds later. It's useful to run two checks: a ping and a connection to the working port — 443 for the website or 22 for SSH.

# check port 443 from the same networks
curl -s -X POST https://api.globalping.io/v1/measurements \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "http",
    "target": "YOUR_IP",
    "measurementOptions": {
      "port": 443,
      "protocol": "HTTPS",
      "request": { "method": "HEAD" }
    },
    "locations": [{ "country": "RU", "tags": ["eyeball-network"], "limit": 12 }]
  }'

How to interpret the results

Three typical patterns, each with its own cause.

First: ping fails everywhere, port does too. This is a block on the address itself. Most often it was restricted not because of you, but because of whoever used it before: addresses are reused, and their history follows them.

Second: ping succeeds from all probes, but the connection on port 443 drops at the TLS handshake stage. This is protocol filtering along the route. The address is alive, the network is there, but the encrypted connection is being cut. This is what blocking of VPN protocols and non-standard traffic often looks like.

Third: one or two out of ten probes don't respond, the rest work fine. This is not a block, but a quirk of a specific ISP or route. Repeat the test in half an hour: if the pattern repeats exactly, the issue is with the ISP; if it fluctuates, it's a routing issue.

What to do if the address is blocked

Change the address. This is the fastest and often the only thing that helps. But there is a nuance that saves time and money: addresses within the same subnet are often blocked in entire ranges. If the new address differs from the old one only in the last number, there is a good chance it will be blocked as well.

So check the new address immediately, using the same residential networks, and don't accept it silently. A decent hosting provider will do this for you before handing over the machine.

If changing the address doesn't help and you keep getting addresses from the same range, the solution is a different location. For example, when addresses in one country are blocked, a neighboring country may work perfectly — sometimes with even lower latency to Russia, since routes don't always follow geography.

When only the encrypted connection drops while ping succeeds, changing the port and protocol helps: moving the service from port 443 to a non-standard port, using a different transport, or obfuscating traffic. For SSH, simply moving it off port 22 is enough.

What not to do

Reinstall the OS. The block lives outside your machine, and a clean install changes nothing. We've seen more than once how someone lost data trying to fix with a reinstall what could be solved by changing the address in two minutes.

Argue without measurements. The phrase "it doesn't work for me" doesn't move things forward: the other side sees green graphs. But a report from ten residential networks where nine out of ten are silent closes the argument instantly — we've confirmed this firsthand: that's exactly how a data center acknowledged the problem and removed the addresses from their pool.

Pay for an address change if the one you were given was already broken. That's a delivery defect, not a personal request.

In short

Check the address from residential networks, not from data centers — they are different worlds. Distinguish between an address block and protocol filtering: they require different fixes. Demand that a new address be verified before it's assigned to you. And remember that a clean address is as much a part of the service as the CPU and disk: a server that's invisible to your users is useless, no matter how powerful it is.