Reading a Traceroute to Diagnose Slow Sites

2 Sep 2026

A website can feel painfully slow even when your broadband speed test looks normal.

Pages may take several seconds to begin loading, a cloud application may disconnect intermittently or one service may perform badly while everything else works. In these situations, the problem may not be your overall internet speed. It could be the route that traffic takes between your device and the destination.

A traceroute can help reveal that path.

It shows the network devices—known as hops—that traffic passes through on its way to a website, server or online service. It can also show how long each hop takes to respond.

Traceroute is useful, but it is easy to misread. A single high number or a row of asterisks does not automatically prove that a router is faulty. The results must be interpreted as a complete path.

What a Traceroute Does

When you connect to a website, your data may pass through:

Your home or business router
Your internet provider’s network
Regional aggregation equipment
Internet exchanges
Transit providers
Content-delivery networks
The destination’s hosting network

Traceroute sends a sequence of specially constructed packets with progressively increasing Time to Live, or TTL, values.

The first packet is allowed to travel only one hop. The first router reduces its TTL to zero and returns a response.

The next packet is allowed to travel two hops, revealing the second router. The process continues until the traffic reaches the destination or the tool reaches its maximum number of hops.

The result is a rough map of the route.

Traceroute Measures Responses, Not the Complete User Experience

Traceroute can help identify:

Where latency begins increasing
Whether traffic follows an unexpected route
Whether a destination is reached
Whether a problem appears inside your network, your ISP or farther away
Differences between working and failing routes
Possible packet loss or instability

It does not directly measure:

Website processing time
Database performance
Browser rendering
DNS lookup speed
Application errors
Server capacity
File-download throughput
Every packet’s real route

It is one diagnostic tool, not a complete verdict.

How to Run Traceroute on Windows

Open Command Prompt and enter:

tracert example.com

You can also test an IP address:

tracert 1.1.1.1

Windows uses the command tracert, without the final “oute”.

A typical result may look like this:

Tracing route to example.com [93.184.216.34]

over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.1.1

2 8 ms 7 ms 8 ms 10.20.0.1

3 11 ms 10 ms 12 ms isp-router.example

4 16 ms 15 ms 17 ms regional-core.example

5 24 ms 23 ms 25 ms transit.example

6 27 ms 26 ms 28 ms 93.184.216.34

How to Run Traceroute on macOS

Open Terminal and enter:

traceroute example.com

To test an IP address:

traceroute 1.1.1.1

macOS also includes a graphical version within certain network-diagnostic tools, although the Terminal command is normally more useful for recording results.

How to Run Traceroute on Linux

Open a terminal and enter:

traceroute example.com

When the command is unavailable, it may need to be installed through the distribution’s package manager.

Some Linux systems also include:

tracepath example.com

tracepath can provide similar route information without requiring the same permissions as some traceroute modes.

How to Run a Route Test on Android

Android does not normally include an obvious traceroute interface in standard Settings.

Options include:

A reputable network-diagnostic app
A terminal environment
The router’s built-in diagnostic page
Running the test from a computer on the same connection

Be cautious with unknown network-tool apps. They may request broad permissions or contain intrusive advertising.

For meaningful troubleshooting, a wired computer is normally preferable because it removes mobile-device and Wi-Fi variables.

How to Run a Route Test on iPhone or iPad

iOS does not provide a built-in traceroute command through the ordinary interface.

You can use:

A trusted network-utility app
A Mac or PC on the same network
A router or firewall’s diagnostic tool

Again, testing from a wired computer normally gives the cleanest baseline.

Understanding the Columns

A Windows traceroute typically displays:

4 16 ms 15 ms 17 ms regional-core.example

This contains:

4: the hop number
16 ms, 15 ms, 17 ms: three round-trip response times
regional-core.example: the router’s hostname
An IP address may appear instead of or alongside the hostname

Each row represents a device or response point along the route.

What Is a Hop?

A hop is normally a router or Layer 3 network device that forwards traffic between networks.

Your first hop is often your local router.

Later hops may belong to:

Your broadband provider
A mobile operator
A carrier or transit network
A cloud provider
A content-delivery network
The destination organisation

Not every network device appears in the trace. Some equipment does not decrement TTL in the same way, and some routers do not return the expected response.

Reading the First Hop

The first hop is usually your local default gateway, such as:

192.168.1.1

or:

192.168.0.1

On a healthy wired local network, response times are often around or below a few milliseconds.

A first hop showing high or inconsistent times may indicate:

Weak Wi-Fi
Local interference
An overloaded router
A busy mesh connection
A failing Ethernet cable
Powerline instability
A computer or router under heavy load

Example:

1 3 ms 85 ms 140 ms 192.168.1.1

That amount of variation at the first hop deserves investigation.

However, run a normal ping to the router as well. Some routers respond to traceroute slowly while forwarding ordinary traffic normally.

Reading the Second Hop

The second hop is often the first device inside the internet provider’s network.

It may use:

A private address such as 10.x.x.x
A carrier-grade NAT address
A public provider address
A hostname identifying an exchange, region or access network

A private second-hop address does not automatically mean anything is wrong. Providers commonly use private addressing internally.

When the second hop has consistently high latency that continues through every later hop, the problem may be near the broadband access network.

The Most Important Rule: Look at What Happens Afterwards

Suppose a trace shows:

4 20 ms 19 ms 21 ms

5 180 ms 190 ms 175 ms

6 24 ms 25 ms 23 ms

7 28 ms 27 ms 29 ms

Hop 5 responds slowly, but later hops return to normal.

That usually means hop 5 gives low priority to traceroute responses. It does not prove that hop 5 is delaying forwarded traffic.

If the router were genuinely adding 160 milliseconds to every packet, the later hops would normally remain at roughly that higher latency.

The more concerning pattern is:

4 20 ms 19 ms 21 ms

5 180 ms 190 ms 175 ms

6 185 ms 192 ms 181 ms

7 188 ms 195 ms 186 ms

Here the delay begins at hop 5 and continues to the destination.

That suggests the route after or around hop 5 is adding latency.

What Do Asterisks Mean?

You may see:

6 * * * Request timed out.

An asterisk means traceroute did not receive a response within the expected period.

This does not necessarily mean traffic stops there.

Routers may:

Block traceroute traffic
Rate-limit diagnostic responses
Give ICMP messages a low priority
Hide internal infrastructure
Respond only to certain protocols
Be configured not to reveal themselves

When later hops still appear, the timed-out router is clearly forwarding traffic.

Example:

5 22 ms 21 ms 23 ms

6 * * *

7 28 ms 27 ms 29 ms

8 31 ms 30 ms 32 ms

Hop 6 is not replying, but it is not blocking the route.

When Asterisks Are More Significant

Asterisks matter more when:

Every remaining hop times out
The destination never appears
The trace consistently stops at the same place
The service also cannot be reached
Other destinations complete normally
The same point fails from several networks

Example:

8 34 ms 35 ms 33 ms

9 * * *

10 * * *

11 * * *

This could mean:

The route is blocked beyond hop 8
The destination drops traceroute responses
A firewall blocks the chosen probe type
The service is unreachable
The maximum path is hidden

Test the actual service before concluding that the route has failed.

Why the Final Destination May Not Reply

Some websites work normally while traceroute never displays the final server.

The destination may block or ignore:

ICMP echo
UDP traceroute packets
TTL-expired responses
Unsolicited diagnostic traffic

The site can still accept normal HTTPS connections on TCP port 443.

A traceroute timeout at the destination is not proof that the website is offline.

High Latency at One Hop

A single high-latency response is commonly caused by control-plane rate limiting.

Routers are designed primarily to forward traffic. Responding to diagnostic probes is a secondary task.

A router may forward packets quickly while taking longer to generate its own traceroute reply.

Treat one slow hop cautiously unless the increased latency continues through the rest of the path.

Gradually Increasing Latency

Some increase in latency is normal as the route travels farther.

Example:

1 1 ms

2 8 ms

3 12 ms

4 18 ms

5 27 ms

6 35 ms

The traffic may be travelling through several cities or networks.

Physical distance, fibre routes and network processing all add delay.

A gradual rise is usually less concerning than a sudden jump that remains for every later hop.

A Sudden Permanent Jump

Consider:

4 14 ms

5 16 ms

6 78 ms

7 81 ms

8 84 ms

The 60-millisecond increase begins at hop 6 and continues.

Possible explanations include:

A long-distance link
International routing
A congested interconnection
A VPN gateway
Traffic being sent through a distant region
Poor ISP peering
An inefficient route

The hostnames may offer geographical clues, but do not rely on them completely. Router names can be outdated or misleading.

International Routes

Traffic may cross national or continental boundaries.

A site hosted in North America, Asia or Australia will normally have higher latency from the UK than a server in London or Manchester.

A trace may show a significant jump at the international section.

This is not necessarily a fault. It may be unavoidable physical distance.

The more useful question is whether the route is sensible.

A UK user accessing a UK service should not normally need to travel through another continent, although network design and cloud hosting can produce surprising paths.

Hostnames Can Provide Clues

A hop may display a name such as:

lon-core1.example.net

or:

man-edge2.example.net

These may suggest London or Manchester.

Other common abbreviations may refer to:

Airport codes
Cities
Data centres
Router roles
Network providers
Interface numbers

Do not treat these names as definitive proof of location. They are assigned by network operators and may not be updated when equipment moves or changes role.

Comparing a Fast Site With a Slow Site

Run traceroutes to:

The slow destination
A similar site that works well
A general public destination
A nearby speed-test server

Compare:

The first few hops
Where the routes diverge
The point at which latency increases
Whether loss continues to the destination
Whether one route becomes international
Whether one path uses a different transit provider

When both traces are identical until they leave your ISP, your local network is less likely to be the cause of the difference.

Compare Wired and Wi-Fi Results

Run the same trace over:

Ethernet
Wi-Fi in the affected room

When the wired trace is stable but the Wi-Fi trace shows first-hop spikes, the problem is local wireless performance.

Possible fixes include:

Moving closer to the access point
Improving router placement
Using Ethernet
Adding a wired access point
Changing congested Wi-Fi channels
Correcting poor mesh placement

There is little value in investigating distant internet hops while the first hop is unstable.

Compare With and Without a VPN

A VPN changes the route by sending traffic through the VPN provider first.

Run a trace:

Without the VPN
Through a nearby VPN server
Through another VPN location where appropriate

When the site is slow without the VPN but fast through it, possible causes include:

Poor ISP routing
Congested peering
A problematic transit provider
Different DNS or content-delivery selection
Application-specific traffic management

This does not prove deliberate ISP throttling. The VPN changes several variables at once.

Compare Good and Bad Times

When a site slows only in the evening, record traceroutes during:

A period when it works well
A period when it performs badly

Look for:

New routes
Higher latency beginning at a consistent hop
Increased packet loss
A different content-delivery network
Congestion near your ISP’s edge
Problems closer to the destination

Repeat the test over several days. One route snapshot is not enough to prove a recurring pattern.

Use Ping Alongside Traceroute

Traceroute reveals the path. Ping measures repeated round-trip responses.

Test:

Your router
The first ISP hop where possible
The destination
Another stable public destination

Example:

ping 192.168.1.1

ping 1.1.1.1

ping example.com

On Windows, use:

ping -t example.com

for continuous testing.

On macOS or Linux, ping continues until stopped.

Look for:

Average latency
Maximum latency
Packet loss
Large spikes
Differences between local and internet destinations

Use Pathping on Windows

Windows includes pathping, which combines features of traceroute and ping.

Run:

pathping example.com

It first discovers the route and then sends probes over a longer period to estimate loss at each hop.

The test can take several minutes.

Pathping can be helpful, but the same interpretation rule applies: loss reported at one intermediate hop is not automatically meaningful when later hops do not show corresponding loss.

Use MTR on macOS or Linux

MTR combines continuous traceroute and ping-style statistics.

It can show:

Current latency
Average latency
Best and worst response
Packet-loss percentage
Changes over time

A command may look like:

mtr example.com

For a report that finishes automatically:

mtr -rw example.com

MTR is extremely useful for intermittent problems because it samples the path repeatedly.

It may need to be installed separately.

How to Read MTR Loss Correctly

Suppose MTR reports:

Hop 4: 60% loss

Hop 5: 0% loss

Hop 6: 0% loss

Destination: 0% loss

Hop 4 is likely rate-limiting its diagnostic responses. It cannot be losing 60% of forwarded traffic while all later hops and the destination receive everything.

More meaningful loss looks like:

Hop 4: 0% loss

Hop 5: 8% loss

Hop 6: 8% loss

Destination: 8% loss

Here the loss begins at hop 5 and persists.

Packet Loss at the First Hop

Persistent first-hop loss may indicate:

Wi-Fi interference
Weak signal
A failing access point
Router overload
A faulty cable
An unstable powerline link
A damaged network adapter

Confirm with a direct ping to the router.

Test over Ethernet before contacting the ISP.

Packet Loss Beginning Inside the ISP

When local testing is clean but loss begins at an ISP hop and continues to the destination, possible causes include:

Access-network faults
Congestion
Provider equipment problems
Line-quality problems
Routing faults
Overloaded interconnections

Collect tests to several destinations.

If the loss begins at the same ISP point across multiple routes, that is useful evidence for the provider.

Packet Loss Near the Destination

When loss begins only in the destination’s network, the issue may belong to:

The website host
A cloud provider
A content-delivery network
The service’s firewall
An overloaded server network

Contacting your broadband provider may not resolve a fault controlled by the destination organisation.

Provide the trace to the website or service operator.

Private Addresses in the Route

You may see addresses from private ranges:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

The first private address is often your router.

Additional private addresses may belong to:

Your ISP
A mobile provider
A business network
A second router
Carrier infrastructure
A VPN

Private hops are not automatically evidence of double NAT or a fault.

Compare your router’s WAN address and network design before drawing conclusions.

Detecting Double NAT With Traceroute

A route beginning like this may indicate two routers:

1 192.168.1.1

2 192.168.0.1

3 public-provider-address

This commonly occurs when:

A personal router is connected behind the provider router
A mesh system is in router mode
A travel router creates another network

Double NAT can affect gaming, remote access and port forwarding, but it does not normally make one ordinary website slow by itself.

Carrier-Grade NAT in a Trace

Mobile and some fixed providers use Carrier-Grade NAT, or CGNAT.

You may see addresses within:

100.64.0.0/10

CGNAT allows many customers to share public IPv4 addresses.

It can affect inbound connectivity, but it does not automatically cause slow website performance.

Different Traceroute Protocols Give Different Results

Traceroute implementations may use:

ICMP
UDP
TCP

Windows tracert normally uses ICMP echo requests.

Traditional Unix traceroute commonly uses UDP probes, though options can change this.

Firewalls may treat these protocols differently. A route that times out with one method may complete with another.

Advanced users can test TCP traceroute to the service’s real port, such as HTTPS on port 443. This can sometimes pass through firewalls that block ordinary traceroute probes.

Why Load Balancing Can Make Routes Look Strange

Modern networks may distribute traffic across several equal-cost paths.

The three probes for one hop can receive replies from different routers.

You might see:

5 18 ms router-a.example

19 ms router-b.example

17 ms router-c.example

This does not necessarily indicate instability.

It may be normal load balancing.

Successive traceroutes can also show different paths while the service continues working properly.

Asymmetric Routing

The route to a destination may differ from the route back.

Traceroute normally reveals only the forward path as inferred from returned responses. The response packet may use a completely different return route.

This means high traceroute latency can sometimes be caused by the return path rather than the forward hop shown.

Diagnosing asymmetric routing usually requires tests from both ends or assistance from network operators.

MPLS and Hidden Hops

Provider networks may use technologies that hide internal routing details.

Several physical or logical devices can appear as one hop, or labels may add unusual responses.

A short traceroute does not necessarily mean the path contains only a few pieces of equipment.

Content-Delivery Networks Can Change the Destination

Large websites often use content-delivery networks, or CDNs.

DNS may send different users to different servers based on:

Location
Internet provider
Network load
IPv4 or IPv6
Resolver location
Service availability

Two computers may trace different destinations for the same website.

A slow site may therefore be caused by selection of a poor CDN node rather than the origin server.

Try:

Flushing DNS
Testing another DNS resolver
Comparing another network
Checking the resolved IP address
Testing IPv4 and IPv6 separately

Change DNS settings only after recording the originals.

IPv4 and IPv6 Routes Can Differ

A website may be reachable over both IPv4 and IPv6.

The IPv6 route may be faster, slower or broken independently of IPv4.

Advanced tests include:

traceroute -4 example.com

traceroute -6 example.com

Windows tools and options vary, but IPv4 and IPv6 can also be tested by resolving or targeting the relevant address directly.

When one protocol works and the other does not, investigate:

Router IPv6 support
ISP routing
Firewall rules
DNS records
Destination configuration

Do not disable IPv6 permanently merely because one site has a routing fault.

DNS Delay Is Not Shown by Traceroute

A site may feel slow before the browser begins connecting because DNS resolution takes too long.

Traceroute begins after the destination has been resolved, unless you supply an IP address directly.

To test DNS separately, use tools such as:

nslookup example.com

or:

dig example.com

When traceroute looks normal but the browser pauses before connecting, DNS is worth checking.

A Fast Trace Does Not Prove the Website Is Fast

A site may have:

A slow database
Overloaded application servers
Large images
Excessive scripts
Poor third-party advertising
Slow authentication
Broken caching
A distant API
Browser compatibility problems

Traceroute measures network responses, not page-generation time.

Use browser developer tools or service-specific monitoring to examine application performance.

A Slow Trace Does Not Always Mean Slow Downloads

ICMP and traceroute responses can be deprioritised while TCP downloads are forwarded normally.

Test actual throughput using:

A file download
A speed test
An application diagnostic
curl
iperf where you control both ends

Do not judge service speed entirely from one diagnostic protocol.

Tracing a Specific Hostname Matters

Do not trace only the company’s main website when the slow service uses another hostname.

A cloud application may load content from:

Login servers
API endpoints
Static-content domains
File-storage services
Video platforms
Third-party scripts

Identify the actual failing hostname where possible.

Browser developer tools, application logs or vendor documentation may help.

Avoid Tracing Sensitive Internal Systems Publicly

Traceroute results may reveal:

Public IP addresses
Provider names
Internal hostnames
Network structure
Business locations
VPN endpoints

Review the output before posting it publicly.

Share diagnostic details only with trusted support personnel when they contain sensitive information.

How to Record Useful Evidence

When investigating an intermittent slow site, record:

Date and time
Destination hostname
Source connection
Ethernet or Wi-Fi
VPN status
IPv4 or IPv6
Traceroute output
Ping statistics
Download or page-load behaviour
Another comparison destination
Whether colleagues are affected

Run the test during both good and bad periods.

A Practical Example

Suppose a company cloud portal is slow.

Traceroute during a good period:

1 1 ms 1 ms 1 ms 192.168.1.1

2 8 ms 8 ms 9 ms isp-access

3 13 ms 12 ms 14 ms isp-core

4 20 ms 21 ms 20 ms transit

5 24 ms 23 ms 25 ms cloud-edge

During the fault:

1 1 ms 1 ms 1 ms 192.168.1.1

2 8 ms 9 ms 8 ms isp-access

3 14 ms 13 ms 14 ms isp-core

4 145 ms 160 ms 151 ms transit

5 150 ms 165 ms 158 ms cloud-edge

The local network and ISP access section remain normal. The delay begins at the transit link and continues to the destination.

That does not prove exactly which company is responsible, but it narrows the fault to the route beyond the ISP core.

Another Example: Misleading Intermediate Loss

1 1 ms 1 ms 1 ms router

2 9 ms 8 ms 9 ms isp

3 200 ms * 190 ms core-router

4 15 ms 16 ms 15 ms edge-router

5 20 ms 19 ms 21 ms destination

Hop 3 looks terrible, but later hops are fast.

Hop 3 is probably deprioritising or rate-limiting diagnostic responses. It is not adding 180 milliseconds to forwarded traffic.

Another Example: Local Wi-Fi Problem

1 12 ms 140 ms 35 ms 192.168.1.1

2 20 ms 155 ms 48 ms isp-access

3 25 ms 160 ms 53 ms isp-core

4 30 ms 166 ms 60 ms destination

The instability begins at the first hop and continues.

Test with Ethernet.

When Ethernet produces stable first-hop results, the problem is the local Wi-Fi connection rather than the remote site.

Another Example: Destination Blocks Traceroute

1 1 ms 1 ms 1 ms router

2 8 ms 8 ms 9 ms isp

3 14 ms 13 ms 14 ms transit

4 22 ms 21 ms 23 ms hosting-edge

5 * * *

6 * * *

The website still loads normally.

The destination or hosting firewall may simply block traceroute responses.

There may be no fault at all.

Common Traceroute Mistakes

Avoid these conclusions:

“Asterisks mean the internet is broken.”
“The first slow-looking router is responsible.”
“Packet loss at one hop proves packet loss for users.”
“A private address means someone is intercepting traffic.”
“Thirty hops always means a bad route.”
“A short route must be faster.”
“A foreign-looking hostname proves the traffic is abroad.”
“Traceroute proves the website server is slow.”
“One trace is enough evidence.”

Interpret the end-to-end pattern.

A Sensible Diagnostic Order

When one site is slow:

Confirm that other sites work.
Test the affected service on another device.
Test over Ethernet.
Check DNS resolution.
Ping the local router.
Ping a public destination.
Run traceroute to the affected hostname.
Run traceroute to a working comparison site.
Repeat during good and bad periods.
Compare with and without the VPN.
Test IPv4 and IPv6 where relevant.
Use MTR or pathping for intermittent loss.
Record the complete results.
Contact the organisation responsible for the section where the fault appears.

When to Contact Your ISP

Contact your provider when:

The first hop is stable.
Several destinations are affected.
Loss or delay begins inside the ISP network.
The pattern persists over Ethernet.
It occurs repeatedly at the same times.
The broadband connection itself drops.
Wired speeds fall below the expected range.
Multiple customers report the same issue.

Provide dates, times, traceroutes and ping results.

Do not send only a screenshot of one high intermediate hop.

When to Contact the Website or Cloud Provider

Contact the service operator when:

Only its service is affected.
Other destinations use the same ISP connection normally.
The problem begins near the destination network.
The application reports server errors.
Colleagues on other providers experience the same fault.
The route reaches the destination but the application remains slow.
The service status page reports an incident.

Provide the hostname, resolved IP address, approximate time and route evidence.

When to Contact Business IT

Speak to your IT team when:

The issue occurs only through the company VPN.
A firewall or secure web gateway changes the route.
The site works on personal devices but not managed computers.
DNS filtering is involved.
A proxy is configured.
The application uses private cloud connectivity.
Several offices are affected differently.
Internal routing or VLANs may be involved.

Do not bypass company security controls to improve performance without authorisation.

Traceroute Is About Patterns, Not Individual Rows

A useful traceroute interpretation asks:

Where does latency first increase?
Does it remain high afterwards?
Does loss continue to the destination?
Is the first hop stable?
Does another destination show the same pattern?
Does Ethernet change the result?
Does the route change during the fault?
Does a VPN or alternative network use a better path?

The most common mistake is blaming the first router that displays a high number.

Intermediate devices often respond slowly to diagnostic traffic while forwarding real traffic correctly. What matters is whether the problem persists to subsequent hops and the final destination.

Used alongside ping, MTR, DNS tests and controlled comparisons, traceroute can help determine whether a slow site is caused by your local network, your ISP, an internet route or the destination service.

Hamilton Group can diagnose slow websites, routing problems, packet loss, VPN performance and unreliable business connectivity.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our experts.