How to Choose a VPS Location: Latency Math, Tests and the Law

To choose a VPS location, put the server where the network path is shortest to whatever it talks to most: your visitors or players for a website or game server, an exchange or API for a bot, your own desk for a remote dev box. Distance sets a hard floor of about 1 ms of round-trip time for every 100 km, and real Internet paths typically take about twice that floor, so measure from your users’ networks before you commit.

Latency is only half of the decision. The location also sets which country’s law applies to your data, and a second city can keep you online when the first has a bad day. Below: the physics, the tests, the legal basics and a worked comparison of Istanbul, where HourlyVPS deploys today, and New York, which is coming soon.

VPS location latency: how much does distance add?

Light in optical fiber travels at roughly two-thirds of the speed of light in a vacuum, about 204,000 km/s (Bozkurt et al., 2018). A request has to reach the server and the answer has to come back, so every kilometer between the two ends counts twice.

That gives a rule of thumb you can do in your head: every 100 km of distance adds about 1 ms of round-trip time (RTT), at minimum. The exact arithmetic is 2 × 100 km ÷ 204,000 km/s = 0.98 ms.

For any distance: minimum RTT in ms = 2 × distance in km ÷ 204,000 km/s × 1,000, which simplifies to distance in km ÷ 102.

Worked example: Istanbul to Frankfurt

1. Great-circle distance between the two city centers: about 1,867 km.
2. Round trip: 2 × 1,867 km = 3,734 km.
3. Time at fiber speed: 3,734 km ÷ 204,000 km/s = 0.0183 s = 18.3 ms.

18.3 ms is a theoretical lower bound for fiber, not a measurement. No fiber path between the two cities can beat it, and the routes your packets actually take will be slower.

Why real latency is higher than the distance math

The floor assumes one straight fiber from door to door. Real packets follow cables laid along roads, railways and seabeds, cross several networks, and change hands only where those networks have agreed to exchange traffic.

Measurement studies cited by Bozkurt et al. found Internet latencies to be, in the median, 3.1 times the bound set by the speed of light in a vacuum. Fiber is only two-thirds as fast, so that is about 2.1 times the fiber floor, and the authors turn it into a rule of thumb: “multiply the distance by 2.1 and divide by the speed-of-light in fiber”. For Istanbul to Frankfurt that is 18.3 ms × 2.1 ≈ 38 ms: a planning guess, not a promise.

Five things push a real RTT above the floor:

• Cable paths. Fiber follows rights-of-way and coastlines, not great circles.
• Routing and peering. Two networks exchange traffic only where they interconnect. If your users’ provider and the data center’s carriers meet in a distant city, packets travel there and back even when both ends sit in the same country.
• The last mile. Home Wi-Fi, mobile radio and busy access links add delay and jitter before a packet reaches a backbone.
• Asymmetric routes. The return path can differ from the outbound path, so a traceroute from one side shows only half of the story.
• Queues. Busy links at peak hours add waiting time on top of travel time.

This is why two providers in the same city can show different latency to the same user, and why a closer data center sometimes loses to a farther one with better connections. Distance tells you what is possible; only a measurement tells you what you will get.

Run the numbers for your own cities

This short Python script computes the great-circle distance between two coordinates, the fiber floor and the 2.1× planning guess. Replace the coordinates with your server city and your users’ city.

from math import asin, cos, radians, sin, sqrt

FIBER_KM_PER_S = 204_000  # light in fiber, about two-thirds of c
EARTH_RADIUS_KM = 6371.0088  # mean Earth radius
TYPICAL_FACTOR = 2.1  # median Internet path vs the fiber floor


def great_circle_km(lat1, lon1, lat2, lon2):
    """Shortest distance over the Earth's surface (haversine)."""
    p1, p2 = radians(lat1), radians(lat2)
    dp, dl = p2 - p1, radians(lon2 - lon1)
    h = sin(dp / 2) ** 2 + cos(p1) * cos(p2) * sin(dl / 2) ** 2
    return 2 * EARTH_RADIUS_KM * asin(sqrt(h))


def rtt_floor_ms(km):
    """Theoretical minimum round-trip time over fiber, in milliseconds."""
    return 2 * km / FIBER_KM_PER_S * 1000


# Istanbul to Frankfurt (city-center coordinates)
km = great_circle_km(41.0082, 28.9784, 50.1109, 8.6821)
floor = rtt_floor_ms(km)
print(f"{km:,.0f} km | floor {floor:.1f} ms | rough guess {floor * TYPICAL_FACTOR:.0f} ms")

Save it as rtt_floor.py and run python3 rtt_floor.py. It prints 1,867 km | floor 18.3 ms | rough guess 38 ms.

Why a few milliseconds turn into hundreds

Latency hurts more than the RTT figure suggests, because a new connection needs several round trips before the first byte of a response arrives. TCP opens with a three-way handshake, the TLS 1.3 handshake takes one more round trip before the client can send encrypted data (RFC 8446), and then the request itself takes a round trip.

HTTP/3 runs over QUIC, whose handshake “combines negotiation of cryptographic and transport parameters” (RFC 9000), which saves one round trip. A connection that is already open pays one round trip per request.

A page that loads files from several hosts pays this setup cost once per new connection. A backend that makes five calls in sequence to a database 80 ms away waits at least 5 × 80 ms = 400 ms, however fast its CPU is. That is why the right location is the one closest to the chattiest link, which is not always the end user.

How much latency is acceptable?

There is no single “good ping”. The budget depends on who or what is waiting, and three published yardsticks help you set it:

To turn a budget into a distance, reverse the planning guess: distance in km ≈ RTT budget in ms × 102 ÷ 2.1, or about 49 km per millisecond. A 100 ms budget reaches roughly 4,860 km on a median route. Beyond that, only a measurement can show that a location fits.

How to choose a VPS location in 6 steps

1. Find where the traffic comes from. Check the country and city report in your analytics, your server logs or your player list. Weight it by what matters: paying customers and peak-hour users count more than one-off visits.
2. Find what the server talks to most. A web app that queries a hosted database, a bot that calls an exchange API, a CI runner that pulls from a package registry: each has a dependency that may matter more than the user.
3. Set a latency budget. Decide how much RTT the workload tolerates (the yardsticks above help), then drop any location whose theoretical floor already uses up the budget. No provider can beat physics.
4. Check the law. Note where personal data will sit, whose data it is, and which transfer rules apply. The data protection section below covers the basics.
5. Check the network terms. Compare traffic allowances, DDoS protection, IPv6 and whether the provider publishes a looking glass or test IPs. For HourlyVPS, those details are on our network page and each location page.
6. Measure, then decide. Deploy a small test server by the hour in each city on your shortlist, measure from real user networks, and delete the servers when you are done.

Where to place the server, by workload

Istanbul or New York: which location fits your users?

HourlyVPS deploys in Istanbul, Türkiye today; New York, USA is coming soon and cannot be ordered yet. The table below applies the formula above to the great-circle distance from each city to common hubs. Read every number as a floor: real RTTs will be higher, by about 2.1× in the median case.

Between the two cities the distance is about 8,070 km, so the floor RTT from Istanbul to New York is 79.1 ms. An audience split between Europe and North America is at least that far from one of the two cities.

Who Istanbul suits

• Users in Türkiye. The floor to Ankara is 3.4 ms, against 82.3 ms from New York.
• Southeastern Europe, the Caucasus, the Middle East and North Africa. Bucharest, Athens, Cairo, Tbilisi, Baku and Dubai all have floors under 30 ms from Istanbul and of 75 ms or more from New York.
• Central and Western Europe, on paper. Frankfurt’s floor is 18.3 ms from Istanbul against 60.8 ms from New York, and London’s is 24.5 ms against 54.6 ms. Measure this one: the real path depends on where your users’ networks connect to Türkiye.
• Projects that need a Turkish IP address, for example to check how a service looks from inside Türkiye.

Who New York will suit once it opens

• North America. Floors of 5.4 ms to Toronto, 11.2 ms to Chicago and 38.6 ms to Los Angeles.
• Latin America. São Paulo’s floor is 75.3 ms from New York against 103.8 ms from Istanbul.
• Transatlantic audiences that lean North American. From New York, London’s floor is 54.6 ms; from Istanbul, Chicago’s is 86.4 ms.
• Until it opens, New York servers cannot be ordered, and their plans, prices and traffic terms will be published on the New York page. For an audience that is mostly in North America today, a provider with a region there will serve it better.

If your users are everywhere, or far from both cities

One server always leaves someone far away. For a worldwide audience, put the origin near the largest group of paying users, serve static files from a CDN, and add a second city once the other side of the audience is big enough to justify it (see two VPS locations below).

If most of your users are in East Asia or Oceania, neither Istanbul nor New York is close: Singapore, Tokyo and Sydney all have floors of 84.7 ms or more from both, before any routing detour. A provider with a data center in that region will serve those users better. Our Hourly VPS Fine-Print Index compares 20 hourly-billed providers, including the locations each one publishes, with a source for every entry (checked October 2026).

How to measure VPS latency before you commit

The most honest latency figure is the one you measure from your users’ networks. This procedure takes about an hour:

1. Get a target in each candidate city. Use the provider’s looking glass, test IP or download file if it publishes one (for HourlyVPS, check each location page). If there is none, deploy the smallest plan by the hour in each city: on HourlyVPS that is Quartz Q1.
2. Test from where your users are, not only from your office: run ping, mtr and curl (below) from a home connection, a mobile hotspot or a colleague abroad, at peak hours as well as quiet ones.
3. Add more networks with RIPE Atlas when your users are spread across countries.
4. Delete the test servers. Our pre-delete checklist covers what to copy and wipe first.

Ping: the quick check

On Linux or macOS, send 20 echo requests. Replace 203.0.113.10 (a documentation address) with your target’s IP:

ping -c 20 203.0.113.10

On a Windows PC the count flag is /n, as in ping /n 20 203.0.113.10; without it, Windows sends 4 requests (Microsoft Learn). Read the minimum and the average in the summary at the end. Compare the minimum with the floor for that distance: around 2× the floor is a typical route, much more points to a detour.

mtr: ping and traceroute in one

mtr “combines the functionality of the traceroute and ping programs in a single network diagnostic tool”, reporting loss and response time for every router on the path (mtr manual). On Ubuntu 24.04, install the terminal version:

sudo apt install mtr-tiny

Run 100 cycles (one per second) and print a wide report with the network (AS) number of each hop:

mtr --report --report-wide --report-cycles 100 --aslookup 203.0.113.10

Some networks filter ICMP. If ping and mtr time out but the service itself works, trace with TCP SYN packets to the port your service listens on:

mtr --tcp --port 443 --report --report-wide --report-cycles 100 203.0.113.10

Routes can differ in each direction, so also run mtr from the server back to your own public IP address. On a Windows PC, pathping /n 203.0.113.10 is the closest built-in tool: it lists the hops, sends 100 queries to each one by default, and reports loss per router and per link (Microsoft Learn).

curl: time a real HTTPS request

ping measures the network; curl shows what a browser waits for. Its timing variables report, from the start of the request, when name resolution, the TCP connect, the TLS handshake and the first byte completed (curl manual). Point it at a page on your own server:

curl -o /dev/null -s -w 'dns %{time_namelookup}s  tcp %{time_connect}s  tls %{time_appconnect}s  first byte %{time_starttransfer}s\n' https://example.com/

The TCP figure should land about one RTT after the DNS figure, and with TLS 1.3 the TLS figure about one RTT after that. The first byte needs one more RTT plus the server’s own work, so if it arrives much more than one RTT after the TLS figure, the server is slow, not the network.

Measure from many networks with RIPE Atlas

RIPE Atlas is a global network of measurement probes run by the RIPE NCC. With a free account you can schedule ping and traceroute measurements from probes in the countries you care about. New users get a one-time grant of 50,000 credits, and with default settings a ping result costs 3 credits and a traceroute result 30 (RIPE Atlas docs).

Point every test at your own servers or at endpoints a provider publishes for testing. Our acceptable use policy covers what is allowed from HourlyVPS servers.

How to read ping and mtr results

Does server location matter for GDPR and data protection?

The GDPR does not require EU hosting, but it does regulate where personal data goes. It applies to organizations established in the EU “regardless of whether the processing takes place in the Union or not”, and to organizations outside the EU that offer goods or services to people in the EU or monitor their behavior there (GDPR Article 3). Hosting outside the EU doesn’t take you out of scope, and hosting inside it doesn’t make you compliant.

Making personal data available to an organization outside the European Economic Area, such as a hosting provider there, usually counts as a transfer, and Chapter V of the GDPR (Articles 44 to 49) sets the conditions. A transfer to a country with an EU adequacy decision needs no further safeguard. Anywhere else, you need an appropriate safeguard such as the Commission’s standard data protection clauses (Article 46), or one of the narrow exceptions.

What that means for Istanbul and, once it opens, New York:

• New York, USA. The EU adequacy decision for the United States covers only commercial organizations participating in the EU-US Data Privacy Framework (European Commission). Check whether your provider is on the Data Privacy Framework List; if it is not, you need another safeguard.
• Istanbul, Türkiye. Türkiye is not on the Commission’s list of adequate countries (European Commission), so EU personal data stored in Istanbul needs an appropriate safeguard such as standard contractual clauses.
• UK GDPR. The UK runs a parallel system: every “restricted transfer” must be covered by UK adequacy regulations, appropriate safeguards or an exception. If you rely on a safeguard, the ICO’s guide, updated in January 2026, says you must also complete a transfer risk assessment, to make sure protection is “not materially lower” after the transfer (ICO). For the US, UK organizations can use the UK Extension to the Data Privacy Framework, in force since 12 October 2023, but only toward certified US organizations (GOV.UK).
• Türkiye’s own law. If your processing falls under KVKK (Law No. 6698), its Article 9, as amended by Law No. 7499, sets separate rules for transfers abroad, and the Turkish authority publishes standard contract texts (KVKK). Weigh those rules before you move Turkish users’ data to New York.

Two jurisdictions, not one

The country where the hardware sits governs the facility and the data stored in it. The country where the provider is established governs the provider. HourlyVPS is sold by White Label Services, LLC, a Wyoming company, so US law applies to the seller wherever your server runs, and Turkish law also applies to hardware in Istanbul.

Istanbul and New York are both outside the EEA and the UK. If you process EU or UK personal data, plan the transfer mechanism before you deploy, or choose a provider with a European location. The GDPR also requires a contract with every processor you use (Article 28). HourlyVPS business customers can request a data processing agreement at [email protected], as our privacy policy explains.

Does server location affect SEO?

A little, and mostly indirectly. Google lists server location, read from the server’s IP address, among the signals it uses to work out a page’s target audience, next to country-code domains and hreflang (Google Search Central). It also says why the signal is weak:

Some websites use distributed content delivery networks (CDNs) or are hosted in a country with better webserver infrastructure, so it is not a definitive signal.

Google Search Central, Managing multi-regional and multilingual sites

Google describes a country-code domain as a strong signal, so if you target one country, the domain and hreflang do more than the server’s address. The bigger effect of location is speed: everything on a page waits for the first byte, and the first byte waits for the round trips above. Put static files behind a CDN and keep the origin near most of your visitors, because uncached requests still travel to the origin.

When should you use two VPS locations?

One location is one failure domain. A regional fiber cut, a power event or a routing problem can take it offline however well the server itself is run. A second city protects you at three levels of cost and complexity:

• Off-site backups. Copy backups to a small server in another location; until New York opens, that means another provider, or S3-compatible storage with restic. Lowest cost; recovery means deploying a new server and restoring.
• Warm standby. Keep a replica running in the second city and switch DNS when the primary fails. Lower the TTL on the record you plan to switch well before you need it.
• Active-active. Serve users from both cities. Lowest latency for a split audience, hardest for data, because every write must reach both sides.

Distance matters here too. A synchronous database replica in New York for a primary in Istanbul adds at least one round trip, a 79.1 ms floor, to every committed write. Asynchronous replication avoids that wait but can lose the most recent writes that had not been copied when the primary failed. Pick the trade-off deliberately.

A backup target can be much smaller than the primary, and its cost stays predictable while it waits: a small plan left on never costs more than its monthly price in a billing period, which runs one month from your order date (monthly VPS), and a standby you keep for only a few days costs 24 hours of hourly billing per day (daily VPS). You can price both servers on the pricing page.