London
United Kingdom · Europe
NETWORK TEST DIRECTORY
Open a published looking glass to inspect connectivity from your own network. Use the result to compare likely routes before choosing a city and configuring the server.
View available tests ↓01 / WHAT IT SHOWS
A looking glass is a network test service associated with a deployment location. Depending on the service, it can help you inspect latency, packet paths or transfers from the network you are currently using. It does not promise future performance, but it provides more relevant evidence than a generic speed claim.
Run tests from representative connections: a customer broadband network, an office, a monitoring point or another server that will exchange traffic with the VPS. If the audience is distributed, test several locations and several networks before selecting the final city.
02 / PUBLISHED TESTS
Each link opens the external test service in a separate tab. Network services can change, so confirm important results again before moving production traffic.
United Kingdom · Europe
France · Europe
Germany · Europe
Finland · Europe
Canada · North America
United States · North America
United States · North America
Singapore · Asia Pacific
Australia · Asia Pacific
03 / READ THE RESULT
Round-trip time helps compare how quickly a small exchange travels between your current connection and the test location. Interactive applications often care about repeated round trips, not only bulk throughput.
A traceroute can show the networks and intermediate hops involved. A geographically close city can still take an indirect path, which is why route evidence matters alongside the map.
One result is a snapshot. Repeat tests at different times and from more than one representative network when routing quality is important to the workload.
04 / UNLISTED TESTS
Limburg, Warsaw and Mumbai do not currently have a published looking glass link in this directory. You can still compare their regional position, review the relevant location page and configure the product. For migrations or latency-sensitive systems, confirm route requirements before committing production traffic.
Do not substitute a test from another city as if it were the same facility. Adjacent looking glasses provide regional context only. The exact path to the selected VPS may differ.
05 / FROM TEST TO DEPLOYMENT
Run equivalent checks against two or three plausible locations. A small difference may be less important than data-location policy, operational access or proximity to the systems the VPS exchanges data with.
After choosing a city, compare the four starting plans and inspect the live CPU, RAM, NVMe disk, network, address and recovery options. Network position and server capacity solve different parts of the problem.
Repeat important network tests before a production migration and monitor the deployed service from the users' regions. Routes can change, and a pre-sale snapshot should not be treated as a permanent performance guarantee.
06 / TESTING LIMITS
A network test does not benchmark the CPU, memory or NVMe storage inside a future VPS. It also does not reproduce every customer's access provider, Wi-Fi connection or application behaviour. Use it to examine the network path and compare plausible locations, not as a guarantee of a particular application response time or transfer rate.
For a production service, combine pre-deployment tests with application monitoring after launch. Measure from the regions that matter, observe database and external-service timings, and keep enough server capacity for the real workload. If the audience changes, revisit both the chosen location and the server specification.
TEST / COMPARE / CONFIGURE