Judged by ping, the best VPS location for Iran is Germany: it is the closest Hetzner location. In an evening measurement on September 29, 2026, taken from a server in an Iranian datacenter, average ping to Falkenstein and Nuremberg was 77 to 82 ms, to Helsinki in Finland about 102 ms, to Ashburn on the US East Coast 167 to 174 ms, and to both Hillsboro, Oregon, and Singapore about 260 ms. This article gives the full table with packet loss, jitter and time to first byte, uses traceroute to show why Singapore is as far from Iran as the US West Coast, explains what each number means in practice for a website, SSH and APIs, and gives you the commands to repeat the test from your own connection.
Ping from Iran to Germany, Finland, the US and Singapore: the measured numbers
The ping of a VPS outside Iran depends above all on where its datacenter is and on the path packets take from Iran’s international gateway to reach it. For each of Hetzner’s six locations — the same ones offered in Mehran Host’s international server order form — we ran two rounds (at 21:39 and 21:52 Tehran time), each sending 100 ping packets and making ten TCP connections and HTTP requests. Each cell of the table shows the range across those two rounds:
| Location | Country | Average ping (ms) | Minimum (ms) | Jitter, mdev (ms) | Packet loss | HTTP first byte (s) |
|---|---|---|---|---|---|---|
| Falkenstein (fsn1) | Germany | 77–80 | 72 | 4–5 | 2–3% | 0.17–0.19 |
| Nuremberg (nbg1) | Germany | 80–82 | 77 | 4 | 0–2% | 0.15–0.17 |
| Helsinki (hel1) | Finland | 101–102 | 99 | 2–3 | 0–2% | 0.20 |
| Ashburn, Virginia (ash) | US, East Coast | 167–174 | 165 | 2–9 | 0–1% | 0.35 |
| Hillsboro, Oregon (hil) | US, West Coast | 259–262 | 255 | 4–5 | 0–2% | 0.50 |
| Singapore (sin) | Singapore | 256–263 | 254 | 3–11 | 1–7% | 0.51 |
Four conclusions come straight out of this table. First, the two German locations are effectively equivalent: the few milliseconds between them swapped sides between the two rounds and sit within the noise, so choose between Falkenstein and Nuremberg on plan availability, not ping. Second, Helsinki is about 22 ms further away — the route section explains why. Third, Ashburn is roughly twice as far as Germany, and Oregon and Singapore more than three times as far. Fourth, in the second round all six destinations showed at least 1–2% packet loss at the same time; loss that hits every destination at once comes from the shared path on the Iranian side, not from the destination datacenter. Singapore, though, with 7% loss and 11 ms of jitter in that same round, was the least stable route.
The last column is the time until the first byte of the response to a simple HTTP request on a fresh connection arrives — one round trip for the TCP handshake and one for the request itself. That’s why it is roughly twice the ping; we come back to it in the section on what the difference means in practice.
Where and how we measured these numbers
The test ran from one of the servers on Mehran Host’s network in an Iranian datacenter, on Tuesday, September 29, 2026, between 21:38 and 21:55 Tehran time. The destinations were Hetzner’s official speed-test hosts, each of which sits inside the datacenter of its location and follows a fixed naming pattern: fsn1-speed.hetzner.com, nbg1-speed.hetzner.com, hel1-speed.hetzner.com, ash-speed.hetzner.com, hil-speed.hetzner.com and sin-speed.hetzner.com. Each round, for each destination, looked like this:
# 100 ICMP echo, one every 0.2 s
ping -c 100 -i 0.2 -q fsn1-speed.hetzner.com
# TCP handshake and first byte, by IP (so DNS lookup time is excluded)
curl -s -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' \
-H 'Host: fsn1-speed.hetzner.com' http://78.46.170.2/
# the path, one probe per hop
traceroute -n -q 1 -w 2 78.46.170.2Because some routers give ping low priority, we also timed the TCP handshake separately; at all six locations it came out within a few milliseconds of the ping figure, so ICMP isn’t misleading here. Two limitations, stated honestly. This is one datacenter’s view, not a home or mobile connection: on your own line, the “last mile” latency and your ISP’s route are added on top. And these are evening-peak numbers; international routes shift with the time of day and from one operator to another. So treat the table as a starting point and repeat it on your own line with the commands in the last section.
Why is Singapore as far from Iran as the US West Coast? The real route, by traceroute
In a straight line, Singapore is about 6,600 km from Tehran and Hillsboro, Oregon, about 11,000 km; yet both ping at around 260 ms. Traceroute shows why: packets bound for Singapore head west first.
- The European route (Germany and Finland): after a few domestic hops, the first router outside Iran, at about 68 ms, is Hetzner’s port on the
NL-IXinternet exchange in theInterxiondatacenter in Frankfurt (its reverse DNS name ishetzner.interxionfra11.nl-ix.net). In other words, traffic from Iran enters Hetzner’s own network directly in Frankfurt; Falkenstein and Nuremberg are a few milliseconds beyond it, and Helsinki about 22 ms further, over Hetzner’s own backbone to Finland. - The US and Singapore route: at about 88 ms, packets surface at the Baku internet exchange (
AZ-IX, on Azerbaijan’sDelta Telecomnetwork), pass to theOrange OpenTransitnetwork and then to a router of Japan’sNTTin Frankfurt, and from there ride NTT’s backbone to Ashburn or Singapore. The last hop before Singapore has the reverse nameae-0.hetzner.sngpsi07.sg.bb.gin.ntt.net: NTT handing the traffic over to Hetzner, inside Singapore.
So the real route from Tehran to Singapore runs through Baku and Frankfurt and is about 14,000 km long — more than twice the straight-line distance. Light in optical fiber covers roughly 200 km per millisecond, and no hardware can make up for a round trip that long. Keep two caveats in mind: this was the route on that night from that origin, and operators change routes; and your own ISP’s traffic may leave Iran through a different gateway — via Turkey, for example. You can look up the owner of every intermediate IP in RIPEstat.
80 ms or 260 ms: what difference does it make in practice?
Ping is a single round trip, but almost nothing you do needs only one. Opening a fresh HTTPS connection with TLS 1.3 takes three round trips before the first byte of the response arrives: one for the TCP handshake, one for TLS and one for the request itself (four with TLS 1.2). In SSH, every key you press takes a round trip to appear on screen. These multipliers are what magnify the gap between locations:
| Location | One round trip | HTTPS first byte on a fresh connection (3 round trips) | Delay before each SSH keystroke appears |
|---|---|---|---|
| Germany | about 80 ms | about 240 ms | practically instant |
| Finland | about 102 ms | about 310 ms | practically instant |
| US East Coast | about 170 ms | about 510 ms | noticeable |
| US West Coast and Singapore | about 260 ms | about 780 ms | annoying when you type at length |
These figures come before any processing time on the server itself. Delays up to about 100 ms feel practically instant to a user; above that, anything made of back-to-back requests — a page with several chained API calls, a git push, or editing a file with nano over SSH — exposes the slowness.
Packet loss hurts more than high ping. If the packet that opens a connection (the SYN) is lost, Linux waits one second and sends it again; in the first round of our test, two of the twenty connections we made to Falkenstein and Helsinki took exactly that long, 1.1 seconds, while the rest finished in under 0.13 seconds. That’s why a service called from Iran should keep its connections open (keep-alive); and for SSH, the ServerAliveInterval setting and working inside tmux, both covered in the SSH connection guide, make short drops bearable.
One important exception: for a bot, a cron job or a service that itself talks to a foreign API, what matters is the distance from the server to that API, not the distance from you to the server. For example, the Telegram Bot API was about 15 ms from our server in Falkenstein; a bot running there responds quickly, and your own ping to Germany only matters when you SSH into the server.
Which location for which job? The best VPS location for Iran, by use case
The general rule is the one from our guide to buying a VPS outside Iran: put the server close to whoever makes the most round trips with it. With the numbers above, the choice for common uses works out like this:
| Use case | Recommended location | Why |
|---|---|---|
| A work server you manage from Iran, a bot, an API or development tools that need direct access to the international internet | Germany: Falkenstein or Nuremberg | Lowest ping from Iran, the cheapest plans and about 20 TB of monthly traffic |
| A site or service with users in Europe | Germany or Finland | Both sit at the heart of Europe’s network; Helsinki is only 22 ms further away, and only for users in Iran |
| A second copy or backup of a European service | Helsinki alongside one of the German locations | Two datacenters in two countries, without paying for the expensive US and Asian traffic |
| Users in North America | Ashburn for the East, Hillsboro for the West | Ping from Iran is high, but it is the shortest path for American users |
| Users in East and Southeast Asia | Singapore | Only when your audience really is in Asia; from Iran it was the least stable route in our test |
| A site, online store or service whose users are in Iran | An Iran server | No foreign location comes close to the few milliseconds of the domestic path; see the section on users in Iran below |
| Trading bots and MetaTrader | Whichever location is closest to the broker’s server | What counts is the distance to the trading server; details in the trading VPS guide |
Traffic and price: why a VPS in Germany or Finland is better value than in the US or Singapore
Distance doesn’t only change the ping; Hetzner’s pricing also differs between Europe and everywhere else. Mehran Host’s panel reads the plan list and prices live from Hetzner itself, and at the time of writing the picture looked like this:
- Included traffic: plans in Germany and Finland include at least about 20 TB of monthly traffic, and larger plans more. In the US, small plans include about 1 TB, and in Singapore the smallest plan about half a terabyte.
- Overage traffic: each extra terabyte costs about seven times as much in Singapore as in Europe or the US.
- Base price: the cheapest plan available to order in the US cost more than three times the cheapest plan in Germany — with half the RAM.
According to its own billing documentation, Hetzner counts only the server’s outgoing traffic; incoming traffic is free. In the order form for a server outside Iran, each plan’s free monthly traffic and the price per extra gigabyte in Toman are shown before you create it, and not every plan is available in every location — the form lists only what’s in stock. You pay by the hour from the same prepaid wallet, kept in Toman (Iran’s everyday currency unit; 1 Toman = 10 rials), so no international card is needed. As long as the server exists — on or off — the meter keeps running, and only deleting it stops the charges. We explain the logic of this model in hourly vs monthly server rental.
The practical conclusion: unless you have a specific reason for the US or Asia, Germany is both closer and cheaper. You can create an international server in Germany, measure its ping and speed from your own line for a few hours, and delete it if you’re not satisfied; you pay only for those hours.
Three things about connecting from Iran to a server abroad that the ping table doesn’t show
1. Use HTTPS with a domain name, not an IP address
On the night of the test, from inside Iran, a curl https://IP request to three different servers of ours in Germany and Finland — without a domain name — was cut off with Connection reset by peer every time. The same servers, addressed by domain name (curl --resolve), completed the TLS handshake in 0.2 to 0.3 seconds and returned 200, and from inside Germany the TLS handshake completed both ways. The only difference between the two requests is that without a domain name, the client doesn’t send the SNI field during the TLS handshake. Browsers always send SNI, so ordinary users notice nothing, but a webhook, app or script that calls HTTPS directly on an IP address fails from Iran. So give every service on a server abroad a domain name with a valid certificate; a free Let’s Encrypt certificate is all you need.
2. Keep your service on TCP
The QUIC handshake — HTTP/3 over UDP — is dropped in Iran’s international transit; the details and the test output are in the test of an Iran server’s international internet access. Browsers fall back to HTTP/2 over TCP on their own, but a service that works only over UDP can’t be reached from Iran.
3. If the server won’t open from Iran, first find out which layer is blocked
A server that is reachable from abroad but not from Iran isn’t necessarily “filtered”, the Iranian term for blocked by the state’s censorship: it may be just one protocol or one domain name that’s blocked. How to tell these cases apart with simultaneous tests from inside and outside Iran, and how to change an international server’s IP from inside the panel, is covered in the guide to checking whether a server IP is blocked in Iran.
Are your users in Iran? You may not need a server abroad at all
The best number in the table above, 77 ms, is still about twenty times a domestic path for an Iranian audience: in the route test from an Iran server, five domestic hops took under 4 ms and the latency jump came exactly at the international gateway. An Iran server also stays reachable for users inside the country during an international internet shutdown — something no foreign location can promise.
A common and sensible combination: the site and database on an Iran server, and the jobs that need direct access to the international internet — a Telegram bot, fetching packages from foreign repositories, talking to international APIs — on a small server in Germany. You create both from one panel and one Toman wallet, and keep the DNS for both domains in the same panel. See the criteria for this choice in Iran or foreign hosting, and how to cut your site’s latency in the guide to reducing ping.
How to test the ping to each location from your own connection
Hetzner’s test hosts are open to anyone. On Windows, open Command Prompt:
ping -n 50 fsn1-speed.hetzner.com
ping -n 50 hel1-speed.hetzner.com
tracert -d sin-speed.hetzner.com
:: TCP handshake time in seconds (curl ships with Windows 10 and 11)
curl.exe -s -o NUL -w "%{time_connect}\n" http://nbg1-speed.hetzner.com/On Linux and macOS, this loop measures all six locations one after another, and mtr shows at which hop packet loss begins:
for h in fsn1 nbg1 hel1 ash hil sin; do
printf '%-5s ' "$h"; ping -c 50 -q "$h-speed.hetzner.com" | tail -1
done
mtr -rwc 50 hel1-speed.hetzner.comLook at three numbers in the output, not just the average: the packet-loss percentage, the mdev value (stddev on macOS), which shows the jitter, and the maximum time. Run the test at the hours when you actually work with the server — international routes are busier in the evening — and on mobile internet, avoid these sites’ large speed-test files, because they eat into your data allowance. Once you have an international server, these same tests plus disk and CPU benchmarks are in the server quality test guide.
Frequently asked questions
What is the ping from Iran to a server in Germany?
In our September 29, 2026 measurement from a server in an Iranian datacenter, average ping to Hetzner’s datacenters in Germany was 77 to 82 ms: Falkenstein 77 to 80 and Nuremberg 80 to 82, with a minimum of 72 ms. On a home or mobile connection, your line’s latency and your ISP’s route are added on top, so your number will be somewhat higher. To measure it on your own line, run ping -n 50 fsn1-speed.hetzner.com on Windows.
Is a VPS in Germany or Finland better for users in Iran?
For users in Iran, Germany is better: Helsinki, Finland, pinged about 102 ms in our test, roughly 22 ms more than Germany, because Iranian traffic enters Hetzner’s network in Frankfurt and only then travels on to Finland. Monthly traffic and plan prices are the same in both countries. Finland makes sense when the plan you want isn’t available in Germany, or when you want a second copy of your service in another country.
Why is ping from Iran to Singapore so high when Singapore is closer than the US?
Because the packets don’t go straight east. In our test’s traceroute, traffic for Singapore went from Baku to Frankfurt and from there over NTT’s network to Singapore, a route more than twice the straight-line distance. The result was a ping of about 260 ms, the same as the US West Coast, and with 7% packet loss in the second round it was the least stable route we tested. Choose Singapore only for an Asian audience.
Which location is best for a Telegram bot or a foreign API?
Germany, unless you have a specific reason to go elsewhere. For bots and services that talk to a foreign API, what matters is the distance from the server to that API, and Germany’s datacenters sit at the heart of Europe’s network; the lowest ping from Iran also makes day-to-day SSH management comfortable. A server inside Iran is not suitable for a Telegram bot, because the Telegram API doesn’t respond from inside Iran. The full setup is in our guide to running a Telegram bot on a VPS.
Can I get a server outside Iran billed hourly and paid in Toman?
Yes. At Mehran Host, servers outside Iran are built on Hetzner’s infrastructure in these same six locations, but you order and pay from your prepaid Toman wallet in the panel, with no international card needed, and billing is hourly. Each plan’s free traffic and its overage rate in Toman are shown in the order form before you create the server. As long as the server exists, on or off, its hourly cost is deducted; only deleting the server stops the charges.