What Is a Looking Glass? How to Test a Hosting Network Before You Buy

What is a looking glass?

A looking glass is a public, read-only web interface to a network operator's routers. You use it to run ping, traceroute and BGP route queries from inside the provider's own network, then read the results in your browser. In short, you see the network from the inside instead of from your own connection.

The name sounds odd, but the idea is simple. In practice, you normally see the internet only from your own line. A looking glass gives you a second vantage point, for example a data center in Frankfurt or New York.

Our team often helps clients weigh hosting decisions alongside their websites and online stores. In this guide we explain how to use the tool before you buy hosting, how to read the output, and where it can mislead you. We keep ping and traceroute details short here, because our sibling guides cover them in depth.

Which commands does a looking glass run?

Most looking glasses offer three kinds of query. For example, Hurricane Electric runs a well known public one. Its page lets you pick a router location around the world and then run BGP Route, BGP Summary, Ping or Traceroute.

• Ping: sends ICMP echo requests from the chosen router to a target IP address and reports the round trip time.
• Traceroute: lists the routers a packet crosses on its way to the target, hop by hop.
• BGP route query: shows the prefix that covers the target and the autonomous systems on the path.
• BGP summary: lists the router's neighbors and their state. Not every provider exposes this command.

The command set differs from provider to provider. Some offer only ping and traceroute, while others open up BGP queries too. The Hurricane Electric page also carries a useful warning: the service and its support run on a best effort basis.

How is a looking glass different from testing on your own computer?

The difference is the point of view. For example, a ping from your laptop measures the path from your internet provider to the target. However, a looking glass shows the path that leaves the hosting provider's network, which is where your server lives.

That distinction matters, because the way there and the way back do not have to match. A visitor's packet may reach your server on one route, while the reply comes back on another. A one way test therefore tells only half of the story.

In short, the tool is a complement, not a verdict. It becomes useful once you combine it with the other methods.

How do you find a looking glass before you buy hosting?

Start by looking for a page called "Looking Glass", "Network" or "Test IP" on the provider's website. Also, providers that run their own network and value transparency often publish one. If you cannot find it, ask the sales or support team.

In general, shared hosting plans rarely come with such a page, while VPS and dedicated server offers more often do. That is a tendency, not a rule, so treat it as a hint. A missing page is also not a red flag on its own.

You can ask the provider for the following:

• The address of the looking glass page.
• A test IP address in the data center you plan to use.
• If possible, a link to a test file download.
• A short list of the locations where they offer routers.

For the other parts of the decision, read our guide on how to choose web hosting. It also covers processor, storage, support and backups.

How do you test with a looking glass step by step?

First decide what you want to measure. For most websites the real question is this: can visitors in my target region reach the server cleanly? Then you answer it by testing in both directions.

1. Pick an IP address on a line in the region where most of your audience lives. You can find your own address with our what is my IP tool.
2. Open the provider's looking glass and select the router in your server's location.
3. Run a ping first and note the latency values.
4. Run a traceroute to the same target and look at the hop count and the route.
5. Now reverse it: run ping and traceroute from your own computer to the server's test IP.
6. Repeat the test several times during the day and write the results into a table.

However, a single measurement can mislead. For that reason, one test in the morning, one in the afternoon and one at evening peak gives a much healthier picture.

How do you read a ping result?

In a ping result you mainly watch three values: average latency, maximum latency and packet loss. Latency arrives in milliseconds. Packet loss should be zero, and constant loss points to a problem with the line or the target.

In network measurements, consistency counts more than the absolute number. For example, ten tries that all return nearly the same value suggest a stable line. However, if one try jumps far above the others, the network may be fluctuating.

Physical distance also affects latency. Light travels at a fixed speed, so a server in Frankfurt will naturally answer more slowly for a visitor in Istanbul than a server in the same city. Therefore judge the number against where your audience actually lives.

Also remember that ping relies on ICMP echo messages, which RFC 792 defines. Also, some servers and firewalls do not answer them. If you get no reply, do not conclude that the site is down.

How do you interpret a looking glass traceroute?

Traceroute prints one hop per line. Each line shows the hop number, the router name or IP address, and usually three timing values. The output below is a made up example. It does not belong to a real network and uses documentation addresses only.

 1  core1.example.net (198.51.100.1)   0.4 ms   0.4 ms   0.5 ms
 2  edge2.example.net (198.51.100.9)   1.1 ms   1.0 ms   1.2 ms
 3  transit.example.org (203.0.113.5)  8.3 ms   8.1 ms   8.4 ms
 4  isp-gw.example.com (203.0.113.77) 24.7 ms  25.2 ms  24.9 ms
 5  203.0.113.10                      25.8 ms  25.6 ms  26.0 ms

In this example the time grows hop by hop and the last line reaches the target. That is the typical picture of a healthy path. Instead, a sudden and lasting jump between two hops deserves a closer look.

Still, a row of asterisks (*) does not mean trouble by itself. Some routers give low priority to answering such probes, or they never answer. What matters is whether the jump continues in the later hops.

The router names also give hints. For example, many networks put a city or company code in the name. That way you can roughly tell which continent the packet crossed.

What does a BGP route query tell you?

BGP is the routing protocol that independent networks use to tell each other which addresses they can reach. The current version, BGP-4, comes from RFC 4271. A looking glass presents this information in readable form.

In a BGP route query you typically see the following:

• The prefix that covers the target IP address.
• The AS path: the order of autonomous systems the packet will cross.
• The neighbor from which the router learned the route.
• Extra attributes such as communities.

A short AS path usually means a more direct route, but a short path is not always a faster one. Also, routing choices depend on commercial agreements and on each provider's policy.

On Cisco style systems the equivalent command is show ip bgp, while web front ends usually hide it behind a "BGP Route" button. This level of detail may be more technical than most site owners need, so skip it if it feels heavy. Still, knowing the terms makes the talk with your provider easier.

Who uses a looking glass, and why is it public?

Network operators, members of internet exchange points (IXPs) and network engineers use it most. According to Philip Smith's peering toolbox page, it is a web front end that gives limited access to a router or route collector. Operators use it to inspect the BGP table, verify outbound policy and check reachability from different points.

So why do providers open it to everyone? Because transparency builds trust and cuts support load. When a customer hits a problem, they can take their own measurement to the support team, and both sides then talk about the same data.

As a site or store owner you are not the main audience, but you can still use the same tool. The key is to remember that the output was built for a network engineer, so do not drown in detail. For most decisions, latency, packet loss and the general shape of the path are enough.

How can you look at your server from outside with a third party looking glass?

A clever use of a looking glass is to view your server from other networks. Find your server's IP address with our DNS lookup tool. Then open a public looking glass, choose a location close to your target region, and enter your server's IP address as the target.

This gives you a view that is closer to the visitor's direction, because the packet travels from that network toward your server. Be careful, though: a single third party network does not represent all of your visitors.

• First, test from several regions and several networks.
• Use the same target and the same command each time, so the results stay comparable.
• Record each result with date and time.
• Do not aim the tool at systems other than your own server.

This test helps most before or after a move to a new server. Putting the new server's network view next to the old one backs your decision with data.

Why does latency come out high?

High latency has a few typical causes. Therefore knowing them helps you interpret the result, and each cause has a different fix.

• Physical distance: signals travel through cables at a limited speed, so a distant location is slower by nature.
• Roundabout routing: a packet can take a path that makes little geographic sense. For example, traffic between two neighboring countries may flow through a third one.
• Congestion: when a link saturates at busy hours, latency climbs.
• Router priority: some devices answer probe packets slowly, which shows up as a high time on an intermediate hop.
• The target itself: if the server is busy, its answer can lag.

Roundabout routing comes from the commercial nature of BGP. Still, the shortest physical path may not be the cheapest or the preferred one. You cannot fix this yourself, because only the provider's network team can change routing preferences.

What should you watch for with IPv4 and IPv6 queries?

Many looking glasses support both IPv4 and IPv6 queries. The Hurricane Electric page, for instance, offers the BGP summary for both versions separately. Today, reachability over both versions is a modern expectation for a website.

Also, the two versions can take different paths. Therefore run separate queries to the same target over IPv4 and over IPv6. If the IPv6 path is clearly slower or drops packets, tell your provider.

You can quickly check whether your site answers over IPv6 with our IPv6 test. If the site has no IPv6 address, the query will not work either, so ask your provider about IPv6 support first. Documentation examples use only the 2001:db8::/32 block for IPv6, and you should never share your real address.

How do you compare two providers with a looking glass?

To keep the comparison fair, use the same target, the same times and the same number of tries with both providers. The table below is a made up example. It is neither a real measurement nor a real provider, and it only shows how to keep records.

In this made up table, Provider A stays steady in the evening, while Provider B's latency nearly doubles. A gap like that can decide the matter when prices are close. Even so, do not choose from this table alone, because support quality, backups and server resources also count.

How do you record your measurements?

Measuring matters, but so does keeping tidy records. Otherwise you will not remember a week later which result came at which hour. A simple spreadsheet is usually enough.

Add these columns: date, time, looking glass location, target IP address, command, average latency, packet loss and notes. Then, in the notes column, write down anything unusual that day. For instance, a maintenance notice or a busy campaign day can affect the result.

That way you also see the trend over time. One bad result and a bad result every evening mean very different things. The second points to a real congestion problem, while the first is most likely a passing fluctuation.

Your records also become a solid basis in contract or service level talks. Going to a provider with dated, repeatable data gets taken far more seriously than a general complaint.

What are the limits of this tool?

A looking glass gives strong visibility, but it has a few limits. Because of that, if you ignore them, you may read too much into a result.

• One vantage point: the query leaves only from the router you chose, and the provider's other routers may behave differently.
• A snapshot: the result shows that second only, and the picture can change at peak hours.
• Network layer only: it does not measure the speed of the web server, PHP or the database.
• One direction: it usually shows the path from the provider to the target, not the return path.
• Limited access: the provider decides which commands stay open.
• Best effort: as the Hurricane Electric example shows, the service itself gives no guarantee.

Some providers also serve the page from a loaded machine or from a separate host. In that case the result can differ slightly from the segment where customer servers sit. So treat every result as a clue, not as a final ruling.

How do network results affect site speed?

Network latency adds directly to the time before the first byte of your page reaches the visitor. web.dev defines Time to First Byte (TTFB) as the time between the start of navigation and the arrival of the first byte of the response. That time includes redirects, the DNS lookup, connection and TLS setup, and the server response.

web.dev treats 0.8 seconds or less as good TTFB and more than 1.8 seconds as poor. Cutting connection setup time and backend time lowers TTFB. Instead, a looking glass helps you see only the network link of that chain.

So if the network results look fine but the site is slow, the problem probably does not sit in the network. The software layer, the database, plugins or image sizes come into play. At that point it pays more to read about how site speed affects SEO and about Core Web Vitals.

For example, store owners feel the picture even more. Page speed affects conversion, and our article does page speed affect e-commerce sales goes into detail.

Which hosting type makes this test most meaningful?

The test helps most where the network path is the deciding factor. On shared hosting, server load and the neighbors on the machine often matter more than the network.

If a CDN sits in front of your site, the answer comes from a point close to the visitor. Therefore the path to the origin server only matters for requests that miss the cache. To learn about caching, read how caching works.

How do you attach the output to a support ticket?

When you report a connection problem to your provider, this output is strong evidence. Instead of writing "I cannot reach my site", a measurement lets the support team narrow the problem down faster.

Add the following to a support ticket:

• The date and time of the test, with the time zone.
• The looking glass location and the command you used.
• The target IP address and the domain where you see the problem.
• A text copy of the ping and traceroute output.
• What you see when you run the same test from your own computer.

Pasting text works better than a screenshot, because the support team can search and compare it. Also take care not to paste your own real IP address into public forums.

If you wonder who owns an IP address, our IP lookup and WHOIS lookup tools can help.

When should you leave it to your hosting provider?

Reading a looking glass is something anyone can do, but interpreting the result and acting on it takes network engineering. In the cases below, leave the job to the provider.

• You see constant packet loss or drops. These usually fall under the provider or an upstream network, because you cannot reach those links.
• You notice an unexpected AS path in the routing table. Therefore only the party that runs the network can fix a route change.
• You would have to change the network configuration (firewall, routes, interfaces) and you are not sure what you are doing.
• You see signs of suspicious heavy traffic or an attack.

To be clear, we are a digital marketing and web team, not a hosting company. This guide rests on official documents and standards, and it claims no network operations experience. So for a firm diagnosis at network level, your provider's network team is the right contact.

Do your own part: take the measurement, collect the evidence and write a clear request. Then leave the fix to the team with the authority to make it.

Which other tests complete the picture?

In practice, no single tool shows the whole picture. A looking glass covers the network path, while other tools cover other layers. When you evaluate hosting, you can add these checks.

• Use the DNS lookup to confirm that your domain resolves to the right IP address.
• Use an SSL check to confirm the certificate is valid. For background, read what an SSL certificate is.
• Use the IPv6 test to see whether your site also answers over IPv6.
• Measure page performance with Google Lighthouse.

The backup routine is also part of the hosting decision. However good the network is, a site without backups carries risk. For that, we recommend our website backup strategy guide.

Which mistakes should you avoid?

The most common mistake is to decide from a single measurement. Also, latency can fluctuate from moment to moment. The average and the spread of several measurements are more reliable.

The second mistake is to treat the result as the speed of the site. However, it shows only the network path. Most of the page load time usually passes in the browser and in the application.

The third mistake is to abuse the tool. Because these pages are public and shared, they are limited resources. Avoid the following behaviors:

• Running the same query hundreds of times in a row.
• Probing third party systems heavily.
• Querying the page constantly with automated scripts.

These behaviors slow the service down for everyone, and the provider may block you. Moreover, heavy tests against systems you do not own can cause legal and ethical trouble.

What is a looking glass checklist before you buy?

The list below is a short guide that helps before you buy hosting or a VPS. You do not have to finish every step, so pick by priority.

1. Find the provider's looking glass or test IP page.
2. Run ping and traceroute from your target region to the server's test IP.
3. Run ping and traceroute from the provider's looking glass to your own IP address.
4. Take at least three measurements at different times.
5. Write packet loss, latency consistency and hop count into a table.
6. Run the DNS, SSL and IPv6 checks.
7. Weigh the results together with price and support quality.

Also, you can use this list like a decision table. If you take the same measurements for every provider, the comparison stays fair.

What do you do if the results look bad?

First, do not panic. Repeat the test at other times and from other locations. If the problem stays, write to the provider and attach the results.

Before you buy, the simplest fix is to try another data center location or another provider. After you buy, wait for the provider's answer first, and then ask for a location change if needed.

On the other hand, if the results are bad only from one region and not on every line, the fix can differ. For example, if your audience lives in that region, consider a CDN or an extra location. If your audience sits elsewhere, the finding matters less.

If you want a broader review of your site's technical performance and visibility, our SEO consulting and web design services support you in that frame.

What should you take away from all this?

A looking glass is the free and fast way to look into a hosting provider's network from the inside. Used well, it therefore gives you hard data before you buy. But read wrongly, it misleads.

To sum up, keep three things in mind: never base a decision on one measurement, never mix up the network layer with the application layer, and leave network level changes to the provider. For ping and traceroute details, turn to our sibling guides.

For more background, read Philip Smith's looking glass page, the Hurricane Electric looking glass, RFC 4271 for BGP-4, RFC 792 for ICMP and the web.dev TTFB guide.