Quick fix: Open Command Prompt or Terminal. Run: pathping google.com. After 25 seconds of analysis, output shows each network hop with packet loss percentage. The hop with the highest loss is the bottleneck. If loss starts at your ISP’s router (hop 2-3), the problem is upstream. If loss is in the middle, it’s an Internet routing issue. End-to-end loss without per-hop is local.

pathping combines ping and tracert. It sends test packets to each hop and measures packet loss + latency. Useful for diagnosing whether slow Internet is due to your ISP, peering, or destination server.

Symptom: Internet is slow on Windows 11; want to identify where the bottleneck is via pathping.
Affects: Windows 11 (and Windows 10).
Fix time: ~5 minutes per test.

What causes Internet slowness

Symptoms (slow speeds, lag, dropped connections) can come from many places: your PC’s network stack, your router, your ISP’s links, peering between ISPs, the destination server. pathping helps narrow down which hop is the problem.

Method 1: Basic pathping diagnosis

The standard route.

Open Command Prompt (no admin needed).
Run:
```
pathping google.com
```
Or to a known reliable destination: pathping 8.8.8.8 (Google DNS).
Pathping takes ~25 seconds:
- First, traces the route (like tracert).
- Then sends 100 pings to each hop over 25 seconds.
- Reports per-hop stats: lost/sent, lost %.

Output looks like:

Hop  RTT    Lost/Sent = Pct   Address
0                                YourPC
1    1ms    0/100 = 0%          router.lan
2    8ms    1/100 = 1%          isp-gateway.example.com
3    15ms   2/100 = 2%          isp-core.example.com
4    22ms   85/100 = 85%        peering.upstream.com
5    25ms   3/100 = 3%          google.com

Hop 4 with 85% loss is the problem. Packets going through that peering point are mostly dropped.
This hop is between ISPs. Issue likely outside your control — report to ISP for awareness.

This is the standard diagnosis.

Method 2: Interpret pathping results

For knowing what each pattern means.

Loss starts at your router (hop 1): local issue. Restart router. Test with cable instead of Wi-Fi.
Loss starts at your ISP gateway (hop 2-3): ISP problem. Contact ISP to report.
Loss only in the middle: third-party peering or transit issue. Usually transient. Wait for ISP routing to update.
Loss only at destination (last hop): destination server is overloaded or rate-limiting. Test with different destination.
Loss across all hops uniformly: usually your local network being congested. Test when no one else is using the network.
High latency, no loss: route is long or congested but stable. Not a critical issue.
0% loss everywhere: pathping doesn’t show a problem. Check application-level issues: bandwidth caps, app firewall, server-side delay.
For comparing routes: run pathping to multiple destinations. Pattern of loss tells you the affected segment.

This is the interpretation.

Method 3: Advanced pathping options

For deeper diagnosis.

For more queries per hop:
```
pathping -q 250 google.com
```
250 pings per hop (more data, takes longer).
For more accurate latency on slow routes:
```
pathping -p 100 google.com
```
Wait 100ms between pings (default 250ms). More aggressive.
For specifying number of hops to trace:
```
pathping -h 15 google.com
```
Trace up to 15 hops (default 30).
For IPv6 specifically: pathping -6 google.com.
For IPv4 only: pathping -4 google.com.

For comparing across days: log output to file:

pathping google.com > C:\Diag\pathping-$(Get-Date -Format yyyyMMdd-HHmm).txt

For continuous monitoring: combine with PowerShell scheduled task to run periodically.

This is for deeper analysis.

How to verify the fix worked

pathping completes without errors.
Output shows per-hop loss data.
Bottleneck hop is identifiable.
If actionable: contact ISP with the hop info, or switch DNS / VPN to bypass the problem hop.

If none of these work

If pathping shows nothing useful: ICMP blocked: some networks block ICMP echo. Use tcping or WinMTR instead. For Wi-Fi issues: pathping may show local Wi-Fi router as problem. Run wired test to isolate. For VPN active: pathping traces through VPN. Disconnect VPN for honest test of real ISP. For corporate network: pathping may be blocked by network policies. Run from home or use WinMTR. For consistent global slowness: not a routing issue. Check bandwidth (speedtest.net) and DNS (try 1.1.1.1 or 8.8.8.8). For one specific site slow: that site’s server or CDN issue. For DNS-related slowness: nslookup site.com 8.8.8.8 compares; nslookup site.com uses your DNS. Compare response times.

Bottom line: pathping google.com in Command Prompt. Wait 25 seconds. Find the hop with highest loss percentage. That’s where the bottleneck is. Use -q 250 for more queries or run repeatedly for variance.