Visual traceroute

How this tool finds the problem

Every connection from your computer to a server crosses several separately run networks: your own home network and router, your internet provider, usually one or more large “transit” networks that carry traffic between providers, and finally the network the server lives in. When a stream buffers or a site won't load, the useful question is not “is the internet broken?” but “which of those networks is the problem in?” — because that decides who can fix it.

This page answers it from two directions. First, IPFerret's own server (in a data center in St. Louis, USA) looks the destination up, tries to open the exact port your app uses, and traces the path to it. That tells you whether the server is up and reachable from the internet at all. Second, you run a trace from the computer that has the problem and paste the result. The page labels every router on the way with the network it belongs to, groups them into home, your ISP, transit and destination, and points at the hop where delay or packet loss really begins.

Reading the result

Home

The first hop is your own router, with a private address such as 192.168.1.1. A wired computer usually gets an answer in under 2 ms and a computer on good Wi-Fi in under 10 ms. If the very first hop is slow or jumpy, nothing further down the line can be better: move closer to the router, use a cable, or restart the router before blaming anyone else. Some homes show two private hops in a row — that is a second router or a mesh system, also inside your home.

Your ISP

Everything from the first hop outside your home until traffic leaves your provider's network belongs to the ISP. Do not be surprised by private-looking addresses here: mobile and fixed-wireless providers in particular route through internal 10.x.x.x addresses, carrier-grade NAT addresses (100.64.0.0/10) and translation addresses such as 192.0.0.1. Because they come after your router, the tool counts them as your ISP, not your home. Problems that start here — loss that begins at one of these hops and carries on to the destination — are for your provider to fix, and the output on this page is exactly what their support team will ask for.

Transit

Between your ISP and the server there are often one or two backbone networks. A large jump in delay where traffic enters one of them is frequently just distance: crossing an ocean adds 70–150 ms that no one can remove. When the registry country changes at that hop, the verdict says so. A jump with no change of country, or sustained loss inside a transit network, is a congested link — usually evening peak-hour congestion between your ISP and that network.

Destination

The last segment is the network that hosts the server. If loss or delay only appears here, or if the port test fails from our server as well as from yours, the problem sits with the service provider — the server is overloaded, down, or listening on a different port.

Things that look alarming but aren't

• Rows of stars (* * *). The router at that hop did not answer probes. Most backbone routers limit how many probe replies they send. If later hops answer, the silent ones forwarded your traffic fine.
• One slow hop in the middle. Answering a probe is low-priority work for a router. If the hops after it are fast again, it is not slowing you down. The tool compares every hop with the fastest time seen at or after it, so a slow-answering router is marked “slow to answer — OK” rather than blamed.
• Several addresses on one hop. Large networks spread traffic over parallel links. Each probe can take a different one, so one hop lists two or three routers. That is load balancing, not a fault.
• The trace never reaches the destination. Many servers drop probe packets. The port test settles it: if the port answers, the server is reachable.

IPTV and streaming: buffering versus not connecting

Streaming problems come in two kinds, and the tests above separate them. If the channel list or the stream never loads, look at the port results. When our server connects to the port but your computer cannot, something between you and the provider blocks it: a parental-control or security setting on your router, your ISP filtering that port or that provider, or the provider refusing connections from your network or country. Testing the same link over a mobile hotspot is a quick way to confirm it is your connection rather than the service. If neither our server nor your computer can connect, the provider's server is down or the port in your link is wrong.

If the stream loads but buffers or freezes, the cause is almost always packet loss or Wi-Fi, not raw speed. Run the longer loss test from step 3 (mtr on Mac or Linux, pathping on Windows) ideally at the time of day the buffering happens — many problems only appear in the evening peak. Sustained loss of even 1–2% is enough to stall a live stream. If loss starts at your first hop, fix the Wi-Fi. If it starts inside your ISP, send them the result. If it starts at the destination, it's the provider's problem.

One more check that solves a surprising number of “it just stopped working” reports: compare the address our server resolved for the host with the one in the first line of your own trace. If they are different and yours doesn't answer, your ISP's DNS may be redirecting or blocking that name. Our DNS lookup shows what public DNS returns, and the guide to flushing your DNS cache covers clearing a stale answer on your device.

What to send your ISP or provider

Support teams act on evidence. Send the full output of the loss test (not a screenshot of part of it), the date and time you ran it, the destination you tested, and one sentence from the verdict above — for example “loss starts at hop 4 inside your network and continues to the destination”. Run it twice, once when things are fine and once when they are not; the difference is the most convincing thing you can show them.

New to traceroute? How traceroute works explains the mechanism, and What is latency? covers what the milliseconds mean. To test a single port on your own connection, use the port checker.

Frequently asked questions