--- title: "How to test VPS latency from Brazil | StreetHosting" description: "Measure VPS latency with ping, MTR and TCP tests, compare cities in Brazil using probes and looking glasses, and learn to read average, jitter and loss." url: "https://streethosting.com.br/en/guides/vps/test-vps-latency" type: "page" language: "en-US" --- VPS · 9 min · Beginner Published on Sep 28, 2026 · Updated on Sep 28, 2026 # Testing VPS latency: ping, MTR and measurements from multiple cities Good latency is the latency your users measure, not what you see from your own computer. Learn how to test with ping, TCP and MTR, how to measure from other cities without owning a machine there, and how to compare the numbers fairly. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Latency and ping](https://streethosting.com.br/en/guides/topics/latency) [Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=How%20to%20test%20VPS%20latency%20from%20Brazil&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency "Share on LinkedIn") [](https://wa.me/?text=How%20to%20test%20VPS%20latency%20from%20Brazil%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ftest-vps-latency "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/test-vps-latency.md) In this guide 8 sections * [What to measure and from where](https://streethosting.com.br/en/guides/vps/test-vps-latency#o-que-medir) * [Ping: the basic test](https://streethosting.com.br/en/guides/vps/test-vps-latency#ping) * [When ping gets no reply](https://streethosting.com.br/en/guides/vps/test-vps-latency#tcp) * [MTR to see the path](https://streethosting.com.br/en/guides/vps/test-vps-latency#mtr) * [Measuring from multiple cities](https://streethosting.com.br/en/guides/vps/test-vps-latency#varias-cidades) * [To São Paulo and between regions](https://streethosting.com.br/en/guides/vps/test-vps-latency#regioes) * [A checklist for comparing](https://streethosting.com.br/en/guides/vps/test-vps-latency#roteiro) * [VPS in São Paulo](https://streethosting.com.br/en/guides/vps/test-vps-latency#onde-rodar) Quick answer To **test VPS latency**, run `ping -c 100 IP_DA_VPS` and read the average, the variation and the loss. If ICMP is blocked, measure the TCP connection time with `curl` or with MTR in TCP mode. The test is only meaningful if you run it from where your users are: ask for measurements from other cities, use probe platforms and looking glasses, and repeat it during peak hours. ## What to measure and from where[](https://streethosting.com.br/en/guides/vps/test-vps-latency#o-que-medir) Three numbers sum up the quality of the connection to the VPS: the average round-trip latency, the variation in that latency, and packet loss. Each one points to a different cause, and the guide on [ping, jitter and packet loss](https://streethosting.com.br/en/guides/infrastructure/ping-vs-jitter-vs-packet-loss) explains what is good and what is a problem for each. If latency is still a new concept, the introduction is in [what latency and ping are](https://streethosting.com.br/en/guides/infrastructure/what-is-latency-and-ping). The most common mistake is testing only from your own computer. Latency depends on the distance and the route between two points, so the number you see at home is valid for you and for people in the same city on the same carrier. A game server with players in the South, the Northeast and the North of Brazil has to be measured from those places, and an API called by another server has to be measured from that other server. | Tool | What it measures | When to use it | | ------------------------------- | -------------------------------------------------- | -------------------------------------------------- | | ping | Round trip over ICMP, loss and variation | Quick test from any computer | | curl with timings | TCP handshake time and HTTP response time | When ICMP is blocked or to measure the application | | MTR | Latency and loss at each hop of the route | Finding where the delay starts | | StreetHosting connectivity test | Round trip from the browser to the São Paulo nodes | Before you buy, no terminal needed | | Looking glass | Ping and traceroute from a carrier's network | Seeing how another network sees the destination | | Probe platforms | Ping and traceroute from many cities and networks | Measuring from where your users are | ## Ping: the basic test[](https://streethosting.com.br/en/guides/vps/test-vps-latency#ping) Send at least 100 packets. With four, the Windows default, one random spike skews the average and the loss figure means nothing. `# Linux and Mac: 100 packets, summary at the end ping -c 100 IP_DA_VPS # Windows (Command Prompt or PowerShell) ping -n 100 IP_DA_VPS` * **Average (avg):** the main number. Compare it with the physical minimum for the distance, which appears further down. * **Minimum and maximum:** a large gap between the two means spikes. On Linux, the `mdev` value sums up this variation; Windows does not calculate it. * **Loss:** any value above zero on a healthy route deserves an MTR to see where it starts. Test over a cable. On Wi-Fi, the variation of the radio itself shows up in the result and hides what comes from the network up to the VPS. If the results with and without a cable are very different, the problem is local. ## When ping gets no reply[](https://streethosting.com.br/en/guides/vps/test-vps-latency#tcp) Many servers drop ICMP at the firewall, and some routers give ICMP lower priority than real traffic. Measuring over TCP solves both cases, because the handshake takes exactly one round trip. For an HTTP or HTTPS service, curl breaks down each stage of the connection. The timings are cumulative from the start, so the TCP handshake is `tcp` minus `dns`: `curl -o /dev/null -s -w 'dns: %{time_namelookup}s\ntcp: %{time_connect}s\ntls: %{time_appconnect}s\nfirst byte: %{time_starttransfer}s\n' https://seu-dominio.com.br` The difference between `first byte` and `tls` is the time the application took to respond, which separates a slow network from a slow server. Run on the VPS against an external API, such as a payment gateway or the Discord API, the same command shows how long your application waits on each call. For other ports, such as a game server's, use MTR in TCP mode: `sudo mtr -rwc 100 -T -P 25565 IP_DA_VPS`. On Windows, psping, from Microsoft's Sysinternals tools, does the same with `psping -n 50 IP_DA_VPS:25565`. ## MTR to see the path[](https://streethosting.com.br/en/guides/vps/test-vps-latency#mtr) Ping tells you how much; MTR tells you where. It continuously measures every router along the path and shows at which hop latency rises and whether loss starts on your network, at the carrier or near the destination: `mtr -rwzbc 100 IP_DA_VPS` The golden rule is to read from the bottom up: if the last hop is clean, loss on the middle hops is just a router rationing its replies. The complete walkthrough, with examples and the test in the opposite direction, is in [how to use MTR to diagnose the network](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr). If you have access to the VPS, also run it from the VPS to the IP of whoever is complaining, because the return route can be different. ## Measuring from multiple cities[](https://streethosting.com.br/en/guides/vps/test-vps-latency#varias-cidades) You don't need a machine in every state to know how the VPS behaves there. Four options, from the simplest to the most complete: * **Browser test:** the [StreetHosting connectivity test](https://streethosting.com.br/en/tools/connectivity) measures the round-trip time from the browser to the nodes in São Paulo and runs an MTR from the SP node to the public IP of whoever is testing. The measurement is over HTTP, not ICMP, so treat it as an estimate. Send the link to users in other cities and ask for the result. * **Real users:** ask people in other states to run a 100-packet ping to the VPS IP and send you the summary. It is the most faithful test, because it uses the carrier and the home of the person who will use the service. * **Looking glass:**many carriers and internet exchange points publish a page that runs ping and traceroute from their routers. It shows how a specific carrier's network reaches the VPS. * **Probe platforms:** services such as RIPE Atlas and Globalping keep probes in thousands of networks around the world, including in Brazil, and run ping and traceroute from cities you choose. Coverage varies by city, and RIPE Atlas requires registration. ## To São Paulo and between regions[](https://streethosting.com.br/en/guides/vps/test-vps-latency#regioes) Two different questions tend to get mixed up. The first is how long the user takes to reach the data center. The second is how long traffic takes between regions, for example between your VPS in São Paulo and an API in the United States. Both have the same physical limit: light in fiber takes about 1 ms per 100 km of round trip. The table shows the theoretical minimum in a straight line from São Paulo. The real route is always longer, because cables don't run in straight lines and each network picks its own path. A result close to these values is excellent; a result many times higher points to a bad route. | From São Paulo to | Straight-line distance | Theoretical minimum round trip | | ----------------- | ---------------------- | ------------------------------ | | Rio de Janeiro | About 360 km | Around 4 ms | | Porto Alegre | About 850 km | Around 9 ms | | Brasília | About 870 km | Around 9 ms | | Fortaleza | About 2,400 km | Around 24 ms | | Manaus | About 2,700 km | Around 27 ms | | Miami | About 6,600 km | Around 66 ms | In practice, people in the South and Southeast tend to see the lowest numbers to the data center, and people in the North and Northeast see higher values, which depend heavily on how each person's carrier routes the traffic. When your audience is Brazilian, a server abroad adds the submarine leg for everyone. The full comparison is in [VPS in Brazil or in the United States](https://streethosting.com.br/en/guides/vps/vps-brazil-vs-usa). ## A checklist for comparing[](https://streethosting.com.br/en/guides/vps/test-vps-latency#roteiro) To compare two VPSs, two providers, or before and after a change, the tests have to be run under the same conditions. Follow this checklist and write everything down: * Same origin, same carrier and a wired connection * At least 100 packets per test, noting average, variation and loss * One test off-peak and another between 8 PM and 11 PM * Measurements from at least three cities where your users are * An MTR to the destination whenever loss or a spike shows up * A TCP test on the service port when ICMP is blocked * Date, time and command of each measurement recorded Latency is only half of the network experience. To find out how much data the VPS delivers in both directions, complete the diagnosis with [iperf3 for testing network speed](https://streethosting.com.br/en/guides/vps/test-vps-network-speed). ## VPS in São Paulo[](https://streethosting.com.br/en/guides/vps/test-vps-latency#onde-rodar) For a Brazilian audience, location is the factor that weighs most on latency, and no configuration makes up for a server far from your users. The [StreetHosting VPS](https://streethosting.com.br/en/vps) plans sit in a data center in São Paulo, with a 1 Gbps uplink, Anti-DDoS included and root access so you can run ping, MTR and curl from the server. * **Xeon VPS:** advertised with 20 ms average latency in Brazil, it runs from R$ 26.00 (2 vCPU, 2 GB, 20 GB NVMe) to R$ 553.00 (24 vCPU, 64 GB, 640 GB NVMe). Good for APIs, bots and sites with many connections. * **Ryzen 9 9950X VPS:** clock speeds up to 5.7 GHz and DDR5, from R$ 40.00 (1 vCPU, 2 GB) to R$ 846.00 (14 vCPU, 64 GB). It is the one recommended for game servers, where the CPU also contributes to the feeling of lag. The tiers are on the [Ryzen VPS page](https://streethosting.com.br/en/vps/ryzen). The VPS is activated within 60 seconds after payment by Pix, boleto or card, so you can sign up, run the checklist above from the cities of your audience and decide with numbers in hand. In this guide * [What to measure and from where](https://streethosting.com.br/en/guides/vps/test-vps-latency#o-que-medir) * [Ping: the basic test](https://streethosting.com.br/en/guides/vps/test-vps-latency#ping) * [When ping gets no reply](https://streethosting.com.br/en/guides/vps/test-vps-latency#tcp) * [MTR to see the path](https://streethosting.com.br/en/guides/vps/test-vps-latency#mtr) * [Measuring from multiple cities](https://streethosting.com.br/en/guides/vps/test-vps-latency#varias-cidades) * [To São Paulo and between regions](https://streethosting.com.br/en/guides/vps/test-vps-latency#regioes) * [A checklist for comparing](https://streethosting.com.br/en/guides/vps/test-vps-latency#roteiro) * [VPS in São Paulo](https://streethosting.com.br/en/guides/vps/test-vps-latency#onde-rodar) ## Frequently asked questions How do I test the latency of a VPS? Run ping -c 100 IP\_DA\_VPS on Linux or ping -n 100 IP\_DA\_VPS on Windows and look at the average, the variation and the loss. If ping is blocked, measure the TCP connection time with curl or with MTR in TCP mode. Repeat the test from the cities where your users are, and during peak hours. What is good latency for a VPS in Brazil? It depends on where your users are. People close to the data center see a few milliseconds; people thousands of kilometers away see more, because light in fiber takes about 1 ms per 100 km of round trip. Compare your result with the physical minimum for that distance and with other destinations in the same city. Why doesn't my VPS answer ping? Usually because the VPS firewall drops ICMP, which is a configuration choice and not a defect. In that case, measure latency through the TCP connection time on an open port, using curl, psping on Windows, or mtr with -T and -P. How do I measure latency from other cities without a server there? Use distributed probe platforms such as RIPE Atlas and Globalping, which run ping and traceroute from points in many cities. Carrier looking glasses show how their network sees the destination. And asking real users in other states to run a ping is still the most faithful test. Does VPS latency change with the time of day? It can, mostly on the user side. In the evening home networks get busier and the queues on routers grow, which raises the average and the variation. That is why a single test at three in the afternoon does not represent what a player will see at nine at night. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) [See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS.](https://streethosting.com.br/en/vps/ryzen) [See Xeon VPS Xeon VPS for steady workloads, automation and long-running projects.](https://streethosting.com.br/en/vps/xeon) ## Related guides [Infrastructure Beginner Ping, jitter and packet loss: the difference in practice Ping measures how long the network takes, jitter measures how much that time varies and packet loss measures what never arrives. Each one ruins the experience in a different way, and knowing which one is bad is what decides the fix. 9 min Read guide](https://streethosting.com.br/en/guides/infrastructure/ping-vs-jitter-vs-packet-loss) [Infrastructure Intermediate How to use MTR to diagnose network problems MTR combines traceroute and ping and shows, hop by hop, where latency climbs and where packets get lost. The trick is knowing which loss is real and which is just a router rationing its replies. 8 min Read guide](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr) [Infrastructure Intermediate How to use traceroute to find routing problems Traceroute lists every router between you and the server and how long each one takes to answer. Read the right way, it shows whether the delay starts at your home, at your ISP, between networks or at the destination. 8 min Read guide](https://streethosting.com.br/en/guides/infrastructure/how-to-use-traceroute) [← Back to the Guide Center](https://streethosting.com.br/en/guides)