Online Ping from Multiple Location

Ping any host or IP. Measure latency & check connectivity from multiple locations.

Ping from

Rate this tool

How useful was this tool?

Ping From Multiple Locations

Enter a domain or IP address in Host or IP address, choose how many Packets to send (between 1 and 16, 4 by default), tick the cities under Ping from, and click Measure Ping. You can ping from Frankfurt, Amsterdam, London, New York, San Francisco, Singapore, Sydney and Bengaluru.

The pings run from Globalping measurement probes in those cities, not from our server or your computer. The results show how quickly a host answers from different parts of the world, not how good your own connection is.

Results appear city by city as each probe answers. Stop ends a test that’s still running, and Clear starts over.

How ping works

Ping sends a small ICMP “echo request” packet to the host. If the host is set up to answer, it sends back an “echo reply.” The time between the two is the round-trip time (RTT), measured in milliseconds.

 

What the results show

The summary table has one row per city:

  • Network: the network the probe is in, with its AS number.
  • Target IP: the address that city actually pinged. For a domain, each probe looks it up itself, so sites on a CDN can show a different address in each city.
  • Min, Avg, Max: the fastest, average and slowest reply. The minimum is the best the path can do.
  • Jitter: how much the reply times change from one packet to the next.
  • Loss: the share of packets that got no reply.
  • Result: replied, N% lost when some packets went missing, no reply when none came back, or probe failed when the probe itself couldn’t run the test. That last one says nothing about your host.

Open a city to see one bar per packet, with lost packets marked in red, plus the number of replies, the TTL and the raw ping output. Notes under the results name the fastest and slowest city.

Example: pinging 8.8.8.8

From Network Min Avg Max Jitter TTL
Frankfurt Oracle 0.9 ms 0.9 ms 0.9 ms 0.0 ms 120
London OVH 1.1 ms 1.2 ms 1.2 ms 0.0 ms 112
Sydney Oracle 1.4 ms 1.5 ms 1.5 ms 0.0 ms 121
New York DigitalOcean 1.3 ms 1.6 ms 2.4 ms 0.4 ms 118
Singapore LeaseWeb 1.2 ms 2.8 ms 4.7 ms 1.2 ms 119
San Francisco Paxio 3.9 ms 5.0 ms 5.8 ms 0.6 ms 118
Amsterdam DELUXHOST 7.2 ms 13.8 ms 23.6 ms 13.4 ms 118
Bengaluru RACKVOLT 9.8 ms 26.1 ms 52.1 ms 19.4 ms 118

All four packets came back everywhere (0% loss). Frankfurt was fastest at 0.9 ms on average, and Bengaluru slowest at 26.1 ms.

One IP, many servers

Frankfurt, Sydney and New York all got answers in under 2 ms. That can’t be one server. Light in fiber covers about 200 km per millisecond, so a round trip between Frankfurt and Sydney takes at least 165 ms.

What’s happening is anycast. 8.8.8.8 is Google Public DNS (see IP to Hostname), and Google announces that same address from data centers all over the world. Each probe reached whichever Google server was closest to it.

The same applies to any site behind a CDN like Cloudflare. Ping it and you measure the distance to the nearest CDN server, not to the server where the site actually runs.

Steady vs. jittery paths

Look at the minimum and the jitter together. Frankfurt’s four replies were all 0.9 ms, with jitter of 0.0. Bengaluru’s best reply was 9.8 ms, but its worst was 52.1 ms, with jitter of 19.4 ms, almost as high as the 26.1 ms average.

The minimum shows what the distance allows. The jitter shows how much is added on top of it: busy links, queueing, or a busy probe. When jitter gets close to the average, as in Bengaluru and Amsterdam here, the path is unsteady. A few milliseconds of jitter is normal.

Jitter matters more than the average for video calls and online games, because it makes timing unpredictable. Before blaming the target, run the test again. The probe’s own network can cause it.

Counting routers with TTL

Every reply starts with a TTL value, usually 64, 128 or 255, and each router it passes lowers it by one. Frankfurt’s replies arrived with TTL 120, which means about 8 routers if it started at 128. London’s arrived with 112, about 16.

This counts the routers on the way back, which isn’t always the way there. So it won’t always match the hop count from a Traceroute.

Distance sets the floor

A useful rule of thumb: every 100 km of fiber adds roughly 1 ms of round-trip time, and real cable routes are rarely straight. Typical round trips:

Route Typical round trip
Same city or data center region under 5 ms
Within Europe 10–40 ms
Europe to the US East Coast 70–100 ms
Europe to Southeast Asia 150–200 ms
Europe to Australia 250–300 ms

So 280 ms from Sydney to a server in Frankfurt isn’t a fault; it’s distance. Pinging from eight cities shows you where visitors wait longest. If many of your visitors are on the far side of the world, a CDN or a second server closer to them is the fix.

Latency also adds up faster than people expect. Opening a new HTTPS connection takes a DNS lookup plus about three round trips (TCP connection, TLS handshake, then the request itself) before the first byte arrives. With a 100 ms round trip, that’s already more than 300 ms of waiting.

What can make results misleading

Blocked ping. Many servers and firewalls don’t answer ICMP at all. Cloud servers often block it by default; on AWS, for example, ping fails until you allow ICMP in the security group. A no reply result doesn’t mean the site is down. Check with the Website Status Checker, or check that port 80 or 443 is open with the Open Port Checker.

Too few packets. With 4 packets, a single lost reply shows as 25% loss. For loss and jitter you can rely on, choose 10 or 16 packets. Routers also give ICMP low priority when they’re busy, so an occasional dropped ping isn’t necessarily a real problem.

Different probes each time. Each run uses whichever probe is available in each city, so the network, and the numbers, can change between runs. If one city looks bad, run it again before drawing conclusions.

What it’s useful for

Choosing where to host. Ping a provider’s test IP from all eight cities before you buy. Most hosts publish test IPs or a “looking glass” page for exactly this.

Checking CDN coverage. Low latency everywhere means visitors are being served from nearby. If one region stands out, the CDN isn’t covering it well. The Target IP column shows which server each city reached.

Spotting regional problems. If one city shows high latency, loss or jitter and the others are fine, the problem is on the path from that region. Run Traceroute from the same city to see where it goes wrong.

After a server move. Confirm the new IP answers from everywhere, and that the Target IP column shows the new address in every city.

FAQ

What’s a good ping?

It depends on how far away the server is. For a website, under about 50 ms from the region where most of your visitors live is good. For gaming and video calls, low jitter matters as much as the number itself.

Why does it say “no reply”?

The host may be down or the address may be wrong. Most often, though, the host simply doesn’t answer ping. Check whether the website loads before assuming anything is broken.

Does ping affect SEO?

Not directly. Google doesn’t ping your server, and ping time isn’t a ranking factor. Latency does slow page loads, and page speed feeds into Core Web Vitals such as Largest Contentful Paint. Serving visitors from nearby, usually through a CDN, is the practical fix.

Is ping the same as a speed test?

No. A speed test measures bandwidth: how much data you can move per second. Ping measures latency: how long one round trip takes. A 1 Gbps connection to a server on another continent still has a high ping.

Can I test my own connection with this?

No. The pings run from probes in the eight cities, not from your device. To test from your own computer, open a terminal and run:

  • Windows: ping -n 20 8.8.8.8
  • Mac or Linux: ping -c 20 8.8.8.8

Twenty packets give you a much better picture of loss and jitter than four.

Related Tools

Contact

Missing something?

Feel free to request missing tools or give some feedback using our contact form.

Contact Us