A server IP blocked in Iran ("filtered", as Iranians call blocking by the state's internet censorship) is one that answers from outside Iran but not from inside it: no port responds, not even ping. An Iran server that can only be reached from inside the country has the opposite problem: it has lost international access. Every other result — an error on HTTPS only, a domain that resolves to 10.10.34.36, a server that answers from nowhere — is a different problem with a different fix. Using tests we ran on September 29, 2026 from a server in an Iranian datacenter, this guide shows how one test, run from inside and outside Iran at the same time, separates these five cases, why curl https://IP gives the wrong answer from Iran, and, if the IP really is blocked, how to replace it from the panel.
What "server IP blocked in Iran" actually means: five cases that get confused
"My server won't open from Iran" has five different causes, and only one of them is a blocked IP. What sets them apart is which test fails, and from which side:
| Case | From inside Iran | From outside Iran | Deciding sign |
|---|---|---|---|
| 1. The server or the service is down | Fails | Fails | No answer from anywhere; the problem is the server itself, its firewall or the service |
| 2. The international server's IP is blocked for Iran | Fails, on every port and on ping | Works | The only case that really is an "IP block" |
| 3. The domain is filtered, not the IP | Works by IP, fails by domain name | Works | DNS inside Iran returns a 10.10.34.x address, or TLS with that name gets reset |
| 4. Only one protocol or pattern is blocked | Ping and TCP work, one specific thing fails | Works | For example HTTP/3 over UDP, or HTTPS without a domain name |
| 5. The Iran server has no international access | Works | Fails | The mirror image of case 2; users inside Iran see no problem |
Changing the IP only cures cases 2 and 5. In case 3 a new IP is just as blocked, because the problem is the domain name; in cases 1 and 4 the IP is fine. So before you do anything, you need to know which row you are in, and only comparing both sides at the same time tells you that.
Testing from inside Iran: ping, a TCP connection and mtr
From your own connection — home broadband or mobile — measure three things: ping, whether the service port is open, and the route. On Windows, in PowerShell:
ping -n 20 203.0.113.10
Test-NetConnection 203.0.113.10 -Port 22 # TcpTestSucceeded : True / False
tracert -d 203.0.113.10On Linux and macOS:
ping -c 20 203.0.113.10
nc -zvw5 203.0.113.10 22
mtr -rwc 30 203.0.113.10Ping on its own is not a verdict, because the server's own firewall may block ICMP; the real test is a TCP connection to the port the service actually listens on — 22 for SSH, 80 and 443 for the web. And never test HTTPS with a bare IP; two sections down you will see why, with real output. In the mtr output, look at where the replies stop. If the last reply comes from hops inside Iran, the packets never crossed the border; if they reached the destination datacenter's network and only the server itself is silent, the problem is the server or its firewall. If the server won't open on one ISP but opens on another, the problem is that ISP's route, not a nationwide block of the IP.
Testing from outside and inside Iran at once with check-host.net
You don't have to arrange the second side yourself. check-host.net tests an IP or a domain from dozens of locations around the world at once; on September 29, 2026 its node list had 59 nodes, 8 of them inside Iran — four in Tehran and the rest in Isfahan, Shiraz and Qom. To check whether an IP is blocked in Iran:
- On the Ping tab, enter the server's IP and compare the results of the Iranian nodes with those of the nodes in Germany, the Netherlands and elsewhere.
- On the TCP port tab, enter the same IP with the service port (for example 203.0.113.10:22); this test is more reliable than ping.
- If the foreign nodes are fine and every Iranian node fails on both tabs, you are most likely in case 2. If everything fails everywhere, case 1. If only some Iranian nodes fail, the problem is the route through those particular networks.
check-host's Iranian nodes sit in datacenters, and their results do not always match a home connection, so put this site's results next to your own test from the previous section, not in place of it. For an Iran server, read the same comparison the other way round: working from Iran and failing from every foreign node means case 5.
The curl https://IP trap: why "Connection reset" from Iran is misleading
Many people test a foreign server from inside Iran with curl https://IP, get Connection reset by peer, and conclude that the IP is blocked. We tried exactly that on September 29, 2026, from a server in an Iranian datacenter against one of our own servers in Germany — a server with a 78–90 ms ping from Iran and port 443 open:
# 1) HTTPS by bare IP: no SNI in the TLS ClientHello
curl -sk https://SERVER-IP/
curl: (56) Recv failure: Connection reset by peer
# 2) the same IP, with the site's real name as SNI
curl -sk --resolve www.example.com:443:SERVER-IP https://www.example.com/
HTTP 200, TLS handshake 0.16 s
# 3) the same IP, with a filtered name as SNI
curl -sk --resolve twitter.com:443:SERVER-IP https://twitter.com/
curl: (56) Recv failure: Connection reset by peerAll three requests went to the same IP, and that IP is perfectly healthy. The only difference is the SNI field of the message that opens TLS (the ClientHello) — the name the client says it wants to reach. This is SNI filtering at work: with no name, or with a filtered name, the connection is reset on the path at the very start of TLS; with an ordinary name, a 200 comes back. The same two requests that were reset — the one with no name and the one for twitter.com — completed the TLS handshake in under 0.1 seconds when we sent them from one of our servers in Finland to the same server. The reset comes from the path through Iran, not from the server.
Two practical conclusions. Always test HTTPS with the real domain name (the --resolve switch pins that name to any IP you choose without touching DNS), and don't read a reset that arrives right after TLS starts as a sign of an IP block — a blocked IP doesn't even answer the TCP handshake. Browsers always send SNI, so ordinary users never see this reset; but an app, a webhook or a script that calls HTTPS directly on an IP will fail from Iran. We cover this and two other points about connecting from Iran in our ping comparison of international server locations.
Domain blocked or IP blocked? What 10.10.34.36 (10.10.34.x) tells you
When a domain name is filtered in Iran, a DNS lookup made inside the country never returns the real IP; a private address from the 10.10.34.x range comes back instead. In the same experiment, a lookup for twitter.com from inside Iran got the answer 10.10.34.36 both from the ISP's resolver and from OpenDNS, a resolver outside Iran. Getting that answer from a foreign resolver means the reply is replaced on the path, so changing your device's DNS settings doesn't change the result either. For your own domain:
nslookup www.example.com
nslookup www.example.com 208.67.222.222If either answer is 10.10.34.x, or the connection is reset with the domain name while the same IP answers under another name, you are in case 3: the domain name itself is blocked, and moving the site to another server or IP won't help. In that case don't change the IP — it costs money and fixes nothing.
Diagnosis table: what the results say and what to do next
| Result | Diagnosis | Next step |
|---|---|---|
| Ping and TCP both fail, from inside and outside Iran | The server, the service or its firewall | Check the server, the service and the firewall from the panel's web console |
| Fine from outside; from Iran, ping and every port fail, on several ISPs | The international server's IP is blocked for Iran | Change the IP from the panel (next section) |
| From Iran, ping and TCP work; only HTTPS to a bare IP is reset | The IP is fine; the reset is caused by the missing SNI | Test with the domain name and --resolve; nothing needs fixing |
| Fails by domain name; DNS from Iran returns 10.10.34.x | The domain is filtered | Changing the IP or the server won't help |
| Only HTTP/3 or a UDP service doesn't work | A protocol restriction on the international route | Offer the service over TCP |
| Fine from Iran; fails from every foreign node | The Iran server has no international access | A ticket with the IP and your test results (last section) |
| Fails on one ISP only | That ISP's route | Report it to the ISP with an mtr taken on that line |
International server IP blocked in Iran: change the IP from the panel
For servers outside Iran (Hetzner infrastructure), changing the IP is self-service and needs no ticket. On the server's page:
- Power the server off completely from the "Overview" tab; Hetzner only reassigns IPs on a server that is powered off.
- In the "Change IP address (IPv4)" card, check the change fee. It is calculated from Hetzner's IP pricing, shown right there before you confirm, and deducted from your wallet only after a successful change.
- To confirm, type the server's name exactly and click "Get a new IP". The new IP comes at random from Hetzner's pool, and the server powers itself back on.
Three things to know before you press the button. The old IP is released for good and cannot be recovered. DNS and rDNS records do not move to the new IP, so you have to set them up again. And there is no guarantee the new IP will be reachable from Iran either, so repeat the tests above straight away. The number of changes per 24 hours is capped. If the domain uses Mehran Host's nameservers, set the A record's TTL to 60 seconds beforehand so the new IP reaches everyone within a minute; the full steps for changing the record are in our guide to pointing a domain at a VPS.
If what you run on the server is a website, there is another route: the CDN switch next to the same A record in the DNS panel. With it on, visitors connect to the CDN's edge nodes, and the origin server's IP no longer appears in DNS. The default "Automatic" setting checks where the origin is and, for an origin outside Iran, puts only the international nodes in front of it. Leave it that way, because a node inside Iran would have to cross the same blocked route to reach the origin. We explain how a CDN works in What is a CDN?.
Iran server lost international access: the filtering watchdog and IP replacement
For cloud servers inside Iran, Mehran Host runs a system called the "filtering watchdog", which tests the IPs of active, powered-on servers from outside the country every half hour. An IP that gives no response in two consecutive checks is recorded in the list of filtered IPs, and the technical team is alerted. From then on it is not handed to new customers and is re-tested regularly, and it only returns to rotation after three healthy checks in a row. When a powered-on server is deleted, its IP goes through the same test from abroad before it returns to the IP pool.
This automated process does not touch your server. Under clause 10 of the terms of service, disruption caused by regulators' decisions or by filtering is outside the provider's control, and an IP change is made available after review. So if your Iran server can't be reached from abroad, open a ticket and include three things: the server's IP, the destination or service that won't open, and the output of your tests — the check-host result or an mtr. How an Iran server normally behaves with the international internet, and what doesn't work from inside Iran even on ordinary days, is covered in testing an Iran server's access to the international internet.
Test the IP in the first hour after provisioning
The best time to discover a blocked IP is before you install anything or set up DNS. Because servers are billed by the hour, this test costs almost nothing: create the server, run ping and TCP tests from your own line and from check-host within the first ten minutes, and if the IP of a server outside Iran turns out to be blocked, change it from the panel before doing anything else. If you no longer want the server, delete it; deleting stops the hourly charge at that moment. For choosing a location by ping, see our ping comparison of Germany, Finland, the US and Singapore from Iran; and if you need a fresh server, create a server outside Iran and run these same tests on it.
Frequently asked questions
How can I tell if my server's IP is blocked in Iran?
Run the same test from inside and outside Iran at the same time: ping plus a TCP connection to the service port, such as 22 or 443. If both work from outside but neither answers from inside Iran on several ISPs, the IP is blocked for Iran. If nothing answers from anywhere, the problem is the server itself or its firewall. If ping and TCP work from Iran and only HTTPS fails, the IP is not blocked; look at the domain name or the protocol instead.
Can check-host.net show whether an IP is blocked in Iran?
Yes, as long as you compare the two groups of nodes. check-host.net tests an IP from dozens of locations at once, and on September 29, 2026 it had eight nodes inside Iran, in Tehran, Isfahan, Shiraz and Qom. On the Ping and TCP port tabs, if the foreign nodes succeed and all the Iranian nodes fail, a block is likely. The site's Iranian nodes are in datacenters, so confirm the result with a test from your own connection as well.
Why does curl https://IP give "Connection reset by peer" from Iran?
Because an HTTPS request to a bare IP sends no site name in the SNI field of the TLS ClientHello, and connections like that from inside Iran to foreign destinations are reset right at the start. In our test, the same server returned a 200 with its real domain name and the --resolve switch, and from outside Iran both requests worked. So this error is not a sign of an IP block; always test HTTPS with a domain name, and give your services a domain and a valid certificate.
What is the IP 10.10.34.36, and why does my domain resolve to it?
Addresses in the 10.10.34.x range are private IPs that DNS inside Iran returns in place of the real IP of a filtered domain. In our test, even a query to the foreign OpenDNS resolver got the same answer, which means the reply is swapped on the path and changing your device's DNS doesn't help. If your domain resolves to this range from inside Iran, the domain name itself is blocked, and moving the site to another IP or server won't fix it.
My international server's IP is blocked in Iran. How do I change it?
In the Mehran Host panel, power the server off from the Overview tab, then get a new IP in the Change IP address card by typing the server's name. The fee, based on Hetzner's IP pricing, is shown before you confirm and is deducted only after a successful change; the new IP is random, and the server powers back on automatically. The old IP is released for good, you must point your DNS records to the new IP yourself, and changes per 24 hours are capped.