"Works for me, doesn't work for my users in Russia" is one of the most common network puzzles we see. You can't fix what you can't see, so the first job is to look at your server from inside those countries. Two free services make that a two-minute check.
The examples below use 203.0.113.10 as the server address. Replace it with yours.
1. Quick check in the browser: check-host.net
Open check-host.net, enter your server's IP, and run Ping first, then TCP port with the port your service listens on (for example 203.0.113.10:443). The results list every probe; look at the ones in Russia and Iran. check-host.net has probes in Moscow and in several Iranian cities.
The same checks work from a terminal. Start a ping test from one Russian and one Iranian probe:
curl -s -H 'Accept: application/json' \
'https://check-host.net/check-ping?host=203.0.113.10&node=ru1.node.check-host.net&node=ir5.node.check-host.net'
It answers with a request_id. Wait a few seconds, then fetch the result:
curl -s -H 'Accept: application/json' 'https://check-host.net/check-result/REQUEST_ID'
For a TCP test, swap check-ping for check-tcp and add the port to the host: host=203.0.113.10:443. Probe names change from time to time; the current list is at https://check-host.net/nodes/hosts.
2. Second opinion: Globalping
Globalping runs tests from volunteer probes all over the world, including Russia and Iran. In the browser, pick the test type, enter your IP and type the country as the location. From a terminal:
curl -s -X POST https://api.globalping.io/v1/measurements \
-H 'content-type: application/json' \
-d '{"type":"ping","target":"203.0.113.10","locations":[{"country":"RU"},{"country":"IR"}],"limit":2}'
The reply contains an id. After a few seconds:
curl -s https://api.globalping.io/v1/measurements/MEASUREMENT_ID
Each result shows the probe's country and city and whether the target answered.
3. Reading the results
| What you see | What it usually means |
|---|---|
| Ping fails, TCP to your port connects | ICMP is filtered somewhere. Your server is reachable; nothing to fix. |
| Ping and TCP fail from several probes in one country, work everywhere else | The address is most likely filtered in that country. |
| TCP connects from inside the country, but your VPN won't connect | The protocol is being blocked, not your IP. Changing the address won't help. |
| Fails everywhere, including Europe | It's your server, not the country: the service is down or a firewall blocks the port. |
One probe failing proves little; home and mobile networks have their own problems. Trust a pattern across several probes in the same country.
4. What to do about it
If the IP is filtered. A different address is the fix. On a dedicated-IP plan you can add a second IPv4, or move to a new server and get a new one. Both options and their prices are in Changing your IP address. Check a new address the same way before you move your users onto it.
If the protocol is blocked. Handshakes of WireGuard and OpenVPN are easy for deep packet inspection to recognise. VLESS + Reality looks like ordinary HTTPS and holds up much better where VPN protocols get filtered.
If it fails from everywhere. Start with the server: is the service running, is it listening on the port, does the firewall allow it? The VPN troubleshooting checklist walks through it step by step.
On a NAT plan, test your personal port (the one shown in the dashboard, like 20xxx). It's the only port that reaches the server from outside; to receive connections on 443 or a VPN port you need a plan with your own IPv4.
Comments
No comments yet. Be the first.