Measure Round-Trip Latency From Many Countries at Once
A ping from your own computer tells you one thing: how long packets take between your connection and the target. That is useful, but it says nothing about a visitor in Sao Paulo, a gamer in Warsaw or a customer in Singapore. This online ping test sends the same probe from a set of check nodes in different parts of the world, usually between ten and thirty, and lists the results side by side.
Each node sends a short series of ICMP echo requests to the host you enter and records how many replies come back and how long each round trip took. The table shows the node's location, the packet count, the loss percentage and the fastest, average and slowest response in milliseconds.
Typical uses include checking whether a website or game server is reachable worldwide, comparing candidate data centers before ordering a virtual private server, confirming that a new server answers from every region after delivery, and diagnosing complaints that a service is slow only in certain countries.
Because the probes come from outside your network, the test also removes your local Wi-Fi, router and ISP from the picture. If every node reports healthy latency and your own connection does not, the problem is likely on your side, and our internet speed test can help you narrow it down.
What the Worldwide Ping Test Measures
Ping is one of the oldest diagnostic tools on the internet. It sends an ICMP echo request to a host and waits for an echo reply, timing the full journey there and back. That journey is the round-trip time, or RTT, and it is the number most people mean when they talk about ping or latency.
RTT is not the same as bandwidth. A connection can move hundreds of megabits per second and still feel sluggish if every request waits 250 ms for an answer, and a modest link with low latency can feel snappy. Interactive workloads such as gaming, remote desktop, SSH sessions, voice calls, trading terminals and API calls care far more about RTT than raw throughput.
Running the probe from many nodes turns one number into a map. Nodes close to the target should show low single or double-digit milliseconds, while nodes on other continents show higher figures driven mostly by distance. When a nearby node shows unexpectedly high latency or packet loss, that points to a routing or congestion issue worth investigating.
The test measures the network path plus the time the target takes to answer ICMP. That second part is normally tiny, because operating systems answer pings in the kernel, but a heavily loaded host or a router that deprioritizes ICMP can add a few milliseconds.
What ping cannot tell you is how fast a web page loads or how much data a link can carry. For those questions, combine latency data with application timing and a throughput test.
Choosing the Right Host or IP to Ping
You can enter either a hostname, such as a domain name, or a raw IP address. With a hostname, each node resolves it through DNS before pinging, which matters for sites behind a content delivery network or global load balancer: different nodes may reach different servers, and the table will reflect the nearest edge rather than one origin.
If you want to measure a single machine, ping its IP address directly. That is the correct approach for a VPS, a dedicated server, a game server or a VPN endpoint, and it avoids confusion caused by DNS records that point to several addresses.
To compare our data centers, use the test IPs published on the IP and latency test list. Those addresses sit inside the locations they represent, so the results show how each facility performs from the regions you care about, before you commit to a plan.
Avoid pinging private addresses such as 192.168.x.x or 10.x.x.x; check nodes on the public internet cannot reach them. Likewise, the address your own router shows is not reachable from outside unless your ISP gives you a public IP and you allow ICMP.
Finally, be considerate. Ping a host you own, administer or are evaluating as a customer. The tool sends a small number of packets per node, which is harmless, but repeated automated runs against third-party infrastructure are poor etiquette.
Packets Sent, Received and Packet Loss Explained
Each check node sends a fixed handful of echo requests and counts the replies. The packets column shows that ratio, for example 4/4 or 3/4, and the loss column expresses the gap as a percentage. Zero percent loss is what you want to see from every node.
Small, occasional loss on one distant node is not unusual on the public internet, especially across long intercontinental links during peak hours. It becomes significant when the same node shows loss on repeated tests, or when several nodes in one region lose packets together, which suggests a congested link or a faulty route between that region and the target.
Loss affects applications differently. TCP-based services such as websites and file transfers retransmit missing segments, so loss shows up as slower loads rather than errors. Real-time protocols such as voice, video calls and most online games use UDP and cannot wait for retransmission, so even a few percent loss produces choppy audio, rubber-banding or dropped frames.
One hundred percent loss from every node has a different meaning: either the host is down, or it does not answer ICMP at all. Many firewalls and cloud security groups block ping by default. Before concluding that a server is offline, check whether the same host serves a web page or accepts an SSH connection.
If loss appears from only a few nodes while others report 0%, the server itself is almost certainly fine. The issue lies on specific paths, and a traceroute from the affected side is the next diagnostic step.
Min, Avg and Max Milliseconds: Reading Ping Columns
Every node reports three timing values. The minimum is the fastest round trip observed and is the best indicator of the physical path length, because it represents a moment with no queuing delay. If you want to compare two data centers fairly, compare their minimums from the same nodes first.
The average is what users typically feel. When the average sits close to the minimum, the path is calm and predictable. When the average climbs well above the minimum, packets are waiting in buffers somewhere along the way, often because a link is busy.
The maximum shows the worst case in that short sample. A single high maximum with a low average may be a one-off spike, such as a router briefly busy with other work, and is not alarming. A maximum that is consistently double or triple the minimum points to jitter, which hurts voice, video and multiplayer games even when the average looks acceptable.
A rough way to read the spread: if max minus min is only a few milliseconds, the route is stable. If the gap is tens of milliseconds on a nearby node, test again at a different time of day to see whether the variation follows peak traffic hours.
Remember that distance sets a floor. Light in fiber travels at roughly two-thirds of its speed in a vacuum, so a round trip across an ocean always costs tens of milliseconds no matter how good the network is. Low numbers on distant nodes are impossible; high numbers on nearby nodes are worth a question.
Distance, Routing and Other Causes of High Latency
Geography is the biggest single factor. The longer the cable path between a check node and the server, the higher the minimum RTT. Cable paths also rarely follow a straight line; traffic between two neighboring countries can travel through a hub hundreds of kilometers away if their networks do not exchange traffic directly.
Routing policy is the second factor. Networks choose paths based on business agreements as much as distance, so two servers in the same city can show very different results from the same node because their providers connect to the rest of the internet differently. This is exactly why running the test against a real IP in a candidate facility beats guessing from a map.
Congestion adds delay that changes through the day. A link that is quiet at 4 a.m. local time may be saturated at 9 p.m. when residential streaming peaks. Testing at the hours your users are most active gives a more honest picture than a single daytime check.
The target host can contribute too. A server at full CPU, a virtual machine on an overloaded host, or a firewall that rate-limits ICMP can all add milliseconds or drop replies. On your own server, check load averages and firewall rules if ping results drift while network paths look stable.
Finally, the last mile matters for real users even though it is excluded from this test. Wi-Fi interference, mobile networks and busy home routers can add more delay than the entire long-haul path, which is why server-side numbers and user-side experience sometimes differ.
When a Host Fails the Ping Check: ICMP Troubleshooting
If every node shows a timeout, start with the simplest explanation: ICMP may be blocked. Windows Server blocks inbound echo requests in its default firewall profile, and many Linux distributions ship firewall tools that can be configured to drop them. On your own VPS, allow ICMP echo requests in Windows Defender Firewall, or in iptables, nftables, firewalld or ufw, then rerun the test.
If ICMP is allowed but nothing answers, confirm the server is running and its network interface is up. For a VPS, the control panel or a VNC console lets you check the machine even when the network is unreachable. A wrong gateway or netmask after a manual network change is a common cause.
If the hostname fails but the IP works, the problem is DNS. Check that the A record exists, that it points to the right address, and that recent changes have propagated. Some nodes may still hold an old answer in their cache for the duration of the record's TTL.
If only certain regions fail or show high loss, the server is fine and a path between those regions and the server is not. Collect the node names, times and a traceroute or MTR output from an affected location, and send them to your provider. That data is what network engineers need to escalate a routing issue.
If you host with us and see persistent loss or timeouts from multiple nodes, open a support ticket with the target IP and a screenshot of the results so the team can investigate the path.
Latency Targets for Gaming, VoIP, Web and Trading
How much latency is acceptable depends on the workload. There are no universal thresholds, but common rules of thumb help you decide whether a location is close enough for your users.
Competitive online games feel best when players see roughly under 50 ms, remain playable for most genres up to about 100 ms, and start to feel delayed beyond that. Game servers should therefore sit in the region where most players live; a European community is better served from a central location such as the Netherlands VPS than from another continent.
Voice and video calls tolerate a little more delay, but they are sensitive to jitter and packet loss. A steady 120 ms with no loss often sounds better than a jumpy 60 ms with spikes. Use the spread between minimum and maximum, not just the average, when judging a VoIP location.
Websites and APIs are more forgiving because browsers fetch many resources in parallel and caches hide repeat requests. Still, every round trip in a TLS handshake or a chain of API calls multiplies the RTT, so a server 200 ms away from its users adds visible delay to the first page load.
Trading tools, remote desktop sessions and SSH work best with the lowest RTT you can get to the exchange, office or user. For these, compare minimum values across candidate data centers and choose the closest consistent result, even if a more distant location is cheaper.
Comparing Data Center Latency Before Buying a VPS
A ping test is the cheapest way to avoid choosing the wrong server location. Before you order, shortlist two or three data centers near your audience, collect their test IPs from the network page, and run each one through this tool. Take screenshots so you can compare the same nodes side by side.
Focus on the nodes that represent your users. If your audience is in South Asia, the nodes in that region matter far more than results from North America. For an Indian audience you might compare the India VPS location with a regional hub such as Singapore, then pick whichever shows the lower and steadier minimum from your users' side.
Repeat the comparison at a busy time of day. A location that wins at noon can lose in the evening if its upstream links are congested, and a few minutes of testing at peak hours can save a migration later.
When your users are spread across several regions, no single location will win everywhere. In that case, consider placing servers in two locations, or look at our multi-location VPS option, and route users to the nearest one with DNS or application logic.
After delivery, ping your new server's IP from the same nodes. The numbers should match what you saw from the test IP. If they differ significantly, open a ticket with both result sets so we can check the routing.