Enter a hostname or IP address to trace the network path to it from three probes in the region you choose. Each hop shows the router name and address and its response time, so you can see where latency starts or where packets stop.
Table of Contents
How traceroute works
Traceroute sends packets with a time-to-live that grows by one each round. Every router that drops a packet because its TTL ran out sends back a message, which reveals the router and the time it took. When the packet reaches the target, the target answers and the trace ends.
ICMP, TCP or UDP
ICMP is the classic Windows-style traceroute. UDP is the default on Linux. TCP to port 443 looks like a normal HTTPS connection, so it passes firewalls that drop ICMP and UDP and is the best choice for testing a web server.
Reading the hops
Rows with * * * are routers that do not answer traceroute packets, which is normal in the middle of the path. If every hop after a certain point is silent and the target never answers, traffic is being dropped there, often by the target’s own firewall. A jump in time that stays high for all later hops shows where the delay is added.
Online Traceroute from Multiple Countries at a glance
How to use this tool
- Enter a hostname such as
example.comor an IPv4 or IPv6 address. A pasted URL is reduced to its hostname. - Choose where to trace from: Worldwide or one region (Europe, North America, South America, Asia, Oceania, Africa, Middle East). A traceroute always uses three probes, whichever you pick.
- Choose the protocol: ICMP (the default, like Windows tracert), TCP port 443 (looks like an HTTPS connection and passes most firewalls) or UDP (like the Linux default).
- Press Trace route. A trace can take up to about 40 seconds. It counts towards the same limit of 10 tests per hour as the ping test, and private or reserved targets are refused.
How to read the results
The summary has one line per probe, for example “7 hops · reached the target” in green, or “no reply from the target (often a firewall dropping traceroute probes)” in amber. “Reached” means the last address that answered is the address the probe resolved for your target. Below the summary there is a hop table for each probe:
| Column | What it shows |
|---|---|
| Hop | The position on the path: 1 is the probe’s own gateway, the last row is the target or the last router that answered. |
| Status | Green when the hop answered, grey when it did not. |
| Router | hostname (IP) when the router has reverse DNS, the bare IP when it has none, and * * * when nothing answered. |
| RTT | Round-trip time of each packet that got an answer, separated by a slash, for example 5 / 4.9 ms. A single value means only one packet was answered. no reply when none were. |
Hop 1 is often called _gateway. That is not a real DNS name: systemd on the probe resolves its default gateway to that name. Router names further on often contain an airport or city code (fra, ams, lhr, iad) and the operator’s domain, which tells you where the packet is and whose network carries it. Private addresses such as 10.x.x.x or 100.64.x.x in the middle of a path are normal inside provider networks.
Common problems and how to fix them
The trace never reaches the target
If the last hops are all * * * and the summary is amber, the target or its firewall drops the probe packets. Run the trace again with TCP port 443: web servers accept that, so a TCP trace that reaches the target proves the path is fine and only ICMP or UDP is filtered. If even TCP stops at the same router, check whether the service itself responds with the website down checker or the open port checker.
Latency jumps at one hop and stays high to the end
That hop is where the delay is added. A jump of 70 ms or more where the router names change from one continent to another is just the ocean crossing. A jump between two routers in the same city, especially at the hand-over between two networks, points to congestion at that interconnect. Run the trace from two or three regions; if all paths into the target network slow down at its edge, the problem is with the hosting network, otherwise with a transit provider.
The same routers repeat until the trace gives up
Hops that bounce between the same two or three addresses are a routing loop, usually after a broken route announcement or a misconfigured static route. Nothing on your server fixes it; send the trace to the network that owns those addresses (the WHOIS lookup shows the abuse or NOC contact).
The trace from here looks fine, but your users still have problems
Internet routing is often asymmetric: replies can take a different path back. Ask an affected user for their IP (they can read it on What is my IP) and trace from your server to them as well.
“traceroute: command not found” on your server
Minimal installs do not include it. Install it, or use tracepath, which is usually present and needs no root:
dnf install traceroute mtr # AlmaLinux / Rocky
apt install traceroute mtr-tiny # Ubuntu / Debian
tracepath example.comA TCP trace from your own server needs root: sudo traceroute -T -p 443 example.com. On Windows use tracert -d example.com (-d skips the slow reverse lookups) or pathping example.com.
Symbols after the times in a Linux traceroute
Local traceroute output can end a line with a marker that explains why the trace stopped:
| Marker | Meaning |
|---|---|
!H, !N, !P | Host, network or protocol unreachable, reported by that router. |
!X | Communication administratively prohibited: a firewall rule rejected the packet. |
!F | Fragmentation needed; often an MTU problem on a tunnel or VPN. |
!S | Source route failed. |
Making a report your provider will act on
A single traceroute is a snapshot. MTR sends packets to every hop continuously and shows loss and latency per hop, which is what network support teams ask for. Run it from the affected side for at least 100 cycles:
mtr -rwzbc 100 example.com-r prints a report, -w keeps full hostnames, -z adds AS numbers, -b shows names and IPs, and -c 100 sets the number of cycles. Add -T -P 443 for TCP. When you read the report, loss that starts at one hop and continues on every hop after it, up to the target, is real. Loss at a single middle hop that disappears on the next one is that router limiting its replies and can be ignored. Send the report together with the time, your source IP and a trace in the opposite direction. For tunnels that slow down at a particular size, see VPN MTU fragmentation.
Official documentation: Globalping network, RFC 792 (ICMP).
Related guides: VPN MTU Fragmentation: Proven Fixes for Slow VPN Throughput · Cloudflare Error 521, 522 and 525 on cPanel: Proven Fixes.
Frequently asked questions
Why does the trace stop before the target?
The target or a firewall in front of it drops the probe packets. Try TCP to port 443, which most web servers accept.
Why are some hops slower than later hops?
Routers answer traceroute at low priority, so one slow hop followed by faster ones is not a problem. Only a delay that continues to the target matters.
Can I trace from my own computer?
Yes: tracert on Windows, traceroute or mtr on Linux and macOS. This tool adds paths from other countries that you cannot test locally.
How many probes run each traceroute?
Three, in the region you choose. Worldwide picks three probes from the whole network rather than one per continent.
Which protocol should I choose?
Start with ICMP. If the trace stops before the target, run it again with TCP port 443, which passes most firewalls in front of web servers. UDP matches the Linux traceroute default.
Why are there private IP addresses in the middle of the trace?
Providers often number their internal links with private or carrier-grade NAT ranges such as 10.0.0.0/8 or 100.64.0.0/10. Those hops are inside the provider network and are normal.
What does _gateway mean at hop 1?
It is the name systemd gives to the probe’s default gateway, not a DNS record. It is the first router the probe sends traffic to.
Why do some hops show two times and others one?
Each time is one answered packet. When a router ignores some of the packets because it limits its replies, fewer times are shown, which is normal.
Does the return traffic follow the same path?
Not necessarily. Routing is often asymmetric, so trace from the other end as well when you troubleshoot a slow connection.