US VPS Hosting: What Matters, Which City

US VPS hosting: the short answer

US VPS hosting starts from one honest fact: any location in the country serves a US audience within one coast-to-coast round trip. That round trip has a hard floor of about 39 ms between New York and Los Angeles, set by the speed of light in glass, and every real path lands somewhere above it. For a website or an API with users spread across the country, the city you choose moves a ping by tens of milliseconds and moves almost nothing a visitor can feel.

The city does matter in three situations. Your users sit on one coast. Your application talks to a database or an API in a fixed place on every request. Or your users are not in the United States at all, and the US server is the landing point for traffic from Latin America, Asia-Pacific or Europe. Each case is covered below, with the physics to reason about any pair of places and a way to measure a real path from your own machine before you pay for anything. If you are still choosing between countries rather than cities, start with whether a Canadian or a US VPS fits your users and come back here for the city.

The US cities, coast by coast

As of September 2026, SSD Nodes offers US locations on both coasts and in the middle of the country. On the West Coast: Seattle and Los Angeles. In the centre: Dallas and Chicago. On the East Coast: Atlanta and New York. The only question on this page is the place on the map, and the geography around each place is what makes it useful.

• Seattle and Los Angeles face the Pacific. The submarine cables from Asia and Australia come ashore in California and the Pacific Northwest, so traffic from Japan, Korea, Singapore and Australia reaches these cities first.
• Dallas and Chicago sit near the middle. Their longest domestic path, to the far corner of the opposite coast, is well short of the New York to Los Angeles line, which makes them the safe pick for a national audience. Dallas also has short overland paths into Mexico.
• Atlanta and New York face the Atlantic. The trans-Atlantic cables land around New York and New Jersey, so Europe reaches New York first. Atlanta is the nearest of these cities to Miami, where most cables from Latin America and the Caribbean come ashore.

The physics floor: why the city rarely matters inside the US

Light in optical fibre travels at about 200,000 km per second, roughly two thirds of its speed in a vacuum, because glass slows it. A round trip covers the path twice, so every 100 km of cable costs about 1 ms of round-trip time (RTT). New York to Los Angeles is about 3,900 km on a great-circle line, which gives a floor of 39 ms. No router and no provider can bring a packet back faster than that.

Real paths run longer. Fibre follows railways and highways rather than the straight line, and traffic often detours through an exchange point in another city before it turns toward the destination. Each router on the way adds a small delay, and a busy one adds queueing on top. So the floor is a lower bound, not a prediction. A measured number close to the floor means a direct path. A number at double the floor or more means a detour worth looking into.

The chart below gives the floor for the pairs that come up in the sections that follow. The values are computed from rounded great-circle distances, not measured, so treat each one as the number your own measurement cannot beat.

[
  {
    "label": "New York to Los Angeles, 3,900 km",
    "floor_ms": 39
  },
  {
    "label": "Dallas to Seattle, 2,700 km",
    "floor_ms": 27
  },
  {
    "label": "Chicago to San Francisco, 3,000 km",
    "floor_ms": 30
  },
  {
    "label": "Dallas to Chicago, 1,300 km",
    "floor_ms": 13
  },
  {
    "label": "New York to Atlanta, 1,200 km",
    "floor_ms": 12
  },
  {
    "label": "Seattle to Los Angeles, 1,550 km",
    "floor_ms": 15.5
  },
  {
    "label": "Mexico City to Dallas, 1,500 km",
    "floor_ms": 15
  },
  {
    "label": "S\u00e3o Paulo to Atlanta, 7,500 km",
    "floor_ms": 75
  },
  {
    "label": "London to New York, 5,600 km",
    "floor_ms": 56
  },
  {
    "label": "Tokyo to Seattle, 7,700 km",
    "floor_ms": 77
  },
  {
    "label": "Tokyo to Los Angeles, 8,800 km",
    "floor_ms": 88
  }
]

Two things turn a small RTT into a delay a person notices. The first is the number of round trips a new connection needs before any content moves: one for the TCP handshake, one for the TLS 1.3 (transport layer security) handshake, then one for the request itself. A first visit pays three round trips before the first byte arrives, and older TLS versions pay four. The second is repetition. A page that loads dozens of objects, or an API client that opens a fresh connection per call, pays that price over and over. This is why the city matters far more for chatty traffic than for one large download.

When the US city does matter

Your users are concentrated on one coast

If your traffic comes from California and the Pacific Northwest, a server in Seattle or Los Angeles keeps the floor near 15.5 ms across that whole region, instead of paying the coast-to-coast 39 ms to New York on every round trip. The same logic puts a Northeast or Southeast audience on New York or Atlanta, which sit 12 ms apart at the floor. A national audience with no strong centre is better served from the middle: from Dallas the worst case to the far coast is about 27 ms at the floor, and from Chicago about 30 ms, against 39 ms from New York to Los Angeles.

This is the case that decides a game server. Players feel the difference between 20 ms and 60 ms in a way that readers of a blog never will, so a VPS for a game server belongs in the city closest to the players, and a player base split across both coasts usually means two servers rather than one compromise city in the middle.

Your app talks to a database somewhere else on every request

Latency between the user and the server is paid once per request. Latency between the server and its database is paid once per query, and a single page often runs many queries in sequence. Each query waits for the previous result before it can start, so the round trips add up instead of overlapping. At the Dallas to Chicago floor of 13 ms, ten sequential queries add 130 ms before the page starts to render, and the real path is longer than the floor. Put the same database in the same building and those ten queries cost well under a millisecond of network time.

So if the database or the payment API you depend on lives in a fixed place, pick the city nearest to it and let your users take the longer hop once. The big cloud regions map onto these cities cleanly. Northern Virginia (AWS us-east-1) is closest to New York, then Atlanta. Oregon (us-west-2) is closest to Seattle, and Northern California (us-west-1) to Los Angeles. The Iowa and Ohio regions are closest to Chicago, and Azure's South Central US region in San Antonio is closest to Dallas. If the other half of your stack is a second VPS, linking two VPS across providers with an encrypted tunnel keeps that traffic private, but a tunnel does nothing about distance, so choose the cities first.

Your users are outside the United States

Many people who search for a VPS in America are not in America. A developer in São Paulo or Manila wants a US server for the price or for a US audience, and needs to know which coast their traffic reaches first. Submarine cable landings answer that question, and the great-circle map gives the floor.

Latin America comes ashore mostly around Miami, and Mexico connects over land through Texas, so Atlanta and Dallas are the natural picks. São Paulo to Atlanta has a floor of 75 ms, and Mexico City to Dallas only 15 ms. If most of your users are in Brazil and the US is only a convenience, weigh that against a VPS hosted in Brazil first. If Canada was also on your list, the path from Latin America to a Canadian VPS adds most of the length of the United States on top of the Miami landing.

Asia-Pacific reaches the West Coast. Tokyo to Seattle has a floor of 77 ms and Tokyo to Los Angeles 88 ms, and Singapore, Sydney, Manila and Seoul all land on the same coast. Choosing New York for users in Japan adds a full coast-to-coast crossing to every round trip.

Europe reaches New York. London to New York has a floor of 56 ms, and the cables that carry it land in New York and New Jersey. Traffic from Africa and the Middle East mostly crosses Europe first, so the same answer holds there. Readers weighing VPS hosting for users in France usually want a European server first and a US server second, and when the US half is needed it should be New York, unless a database elsewhere overrides it.

Measure it yourself with ping and mtr

Nothing above replaces a measurement from the place your users actually sit. Most providers publish a test IP address or a looking-glass host for each location on their data-centre page. Copy the address for each city you are weighing and run the checks below from your own machine. Then ask one user in your main market to run the same commands, because a ping from your desk in Berlin says nothing about a customer in Bogotá.

Start with ping. Twenty packets are enough to see the shape.

ping -c 20 203.0.113.10   # replace with the test address for the city

The line to read is the last one. The numbers here only show the format; yours will differ.

rtt min/avg/max/mdev = 41.203/41.611/43.980/0.612 ms

min is the closest you will get to the path's floor. avg is what a user feels on a quiet path, and mdev is the jitter, the spread between the fastest and slowest packets. macOS labels the same line round-trip and calls the last field stddev. Compare min against the chart above. A min near the floor for that pair means a direct route. A min at twice the floor means the path detours, and mtr shows you where.

mtr combines traceroute with repeated pings, so it reports the delay at every hop along the path. On Ubuntu and Debian the command-line build is the mtr-tiny package. On macOS, brew install mtr and run it with sudo.

sudo apt install -y mtr-tiny
mtr -rwc 100 203.0.113.10   # same test address as above

-r prints a report instead of a live screen, -w stops long hostnames being cut short, and -c 100 sends 100 probes so the averages settle. Read it from top to bottom. The Avg column should rise in steps as the path crosses the country, and the hostname of each hop where it jumps usually names a city, which tells you where the traffic really goes. Two rules keep you from wrong conclusions. Loss at one hop that vanishes on the hops after it is not real loss: that router answers probes at low priority while forwarding real traffic normally, so only loss that continues to the final hop counts. Likewise, a hop with a high Avg followed by lower ones is a slow control plane on one router, not a slow link. On Windows, tracert <test-ip> gives the same per-hop picture without the repeated sampling.

Once you have a server, measure what users actually do, which is open a TLS connection, rather than ICMP (Internet Control Message Protocol) echo, which some networks slow down on purpose. curl can time each stage of a request:

curl -o /dev/null -s -w 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s\n' https://your-server.example.com/

time_connect is one round trip. time_appconnect adds the TLS handshake on top, and time_starttransfer adds the request and the server's own processing. The gap between the first two is your RTT, measured the way a browser pays it.

What changes when you pick a US server from abroad

Two things change, and neither depends on the city.

Jurisdiction. A server in the United States is under US law whichever city it sits in. That decides what a provider can be compelled to hand over, and to whom. It does not switch off the rules of your own country: the laws that govern your users' data follow the users and your business, and a US address does not replace them. Keep two facts straight. HIPAA (the Health Insurance Portability and Accountability Act) and PCI DSS (the Payment Card Industry Data Security Standard) attach to the data and to the organisation handling it, not to the city the disk is in, so a compliant setup in Dallas is compliant in New York and a non-compliant one is non-compliant everywhere. And there is no general US data-residency statute: no federal law requires data about US residents to stay inside the country, which is why US providers rarely advertise in-country storage the way Canadian and European ones do. If residency is the question you actually have, what matters in VPS hosting in Canada covers a country where it does apply.

Billing in US dollars. The invoice is in USD, so a move in the exchange rate changes what you pay in your own currency even when the price never changed. Cards issued outside the US often add a foreign transaction fee of a few percent. Whether your local sales tax or VAT applies to the invoice is a question for your accountant, not for the provider. Before you decide the US plan is the cheaper one, work out what a VPS really costs in your currency at today's rate, with those fees added.

The one-minute decision rule

Answer these in order and stop at the first one that applies.

1. Do you depend on a database or an API in a fixed place? Pick the city nearest to it. Users take the long hop once per request; queries take it once each.
2. Are most of your users on one coast? West Coast: Los Angeles or Seattle. Northeast: New York. Southeast and Texas: Atlanta or Dallas. Upper Midwest: Chicago.
3. Are most of your users outside the US? Latin America: Atlanta or Dallas. Asia-Pacific: Los Angeles or Seattle. Europe (and the traffic from Africa and the Middle East that crosses it): New York.
4. A US-wide audience with no anchor? Dallas. Its worst case to the far coast is about 27 ms at the floor, the smallest worst case on the list.

Whichever city the rule gives you, run the ping and mtr checks against its test address from where your users are. If the measurement disagrees with the map, believe the measurement, because it includes the detours the map cannot see.

Between them, New York and Dallas settle most decisions. Read the New York VPS page if the rule sent you east or to Europe, and the Dallas VPS page if it sent you to the middle or to Latin America. Each one covers its own city in detail.

FAQ

Which US VPS location is best for users in Europe?

New York. The trans-Atlantic cables that carry European traffic land in New York and New Jersey, so New York is the first US city the packets reach. London to New York has a floor of about 56 ms round trip from distance alone. Choosing a West Coast city would add a coast-to-coast crossing, about 39 ms more at the floor, to every round trip.

Does it matter whether my US VPS is in Dallas or New York?

For a US-wide audience, less than most people expect. Both cities sit within one coast-to-coast round trip of every US user, and a site that reuses connections hides that difference. Dallas has the smaller worst case, about 27 ms at the floor to the far coast against 39 ms from New York to Los Angeles. New York wins when your users are in the Northeast or in Europe, or when your database lives in Northern Virginia.

Is my data more protected in one US city than another?

No. US law applies to a server in Seattle exactly as it applies to one in Atlanta. HIPAA and PCI DSS attach to the data and to how you handle it, not to the city, and there is no general US data-residency statute that treats one state differently from another for hosting. Choosing the city is a latency decision. Choosing the country is the legal one.

How do I measure latency to a US VPS before I buy?

Take the test IP address the provider publishes for each city and run ping -c 20 and mtr -rwc 100 against it from the place your users are, not only from your desk. Compare the min value that ping reports against the physics floor of about 1 ms per 100 km of great-circle distance. A min near the floor means a direct path. A min at double the floor means a detour, and the mtr report shows which hop adds it.

Should I pick a US VPS or a Canadian one?

Pick by users first and by law second. For users in the US, a US city is always at least as close and usually closer. For users in Canada, the distance between Toronto and New York is short enough that latency rarely decides it, so the choice turns on data residency and billing currency instead. Canada vs US VPS: which to pick walks through that comparison.