Router versus public internet
Ping the router and a nearby public endpoint at the same time to see whether delay begins inside or beyond the home.
Find where the delay starts by comparing Wi-Fi, Ethernet, the router gateway, public internet, loaded latency and packet loss.
Latency troubleshooting guide
Separate Wi-Fi delay, loaded queues, packet loss, server distance, VPN routing, CGNAT, line profiles and provider congestion using a repeatable fault boundary.
Start here
Constantly high ping needs a different path from brief lag spikes. Use these comparisons before changing DNS, buying a router or switching provider.
Instant fault isolator
This routes you to the most useful next test or guide without assuming the broadband provider is at fault.
Likely fault boundary
Open the next stepPing the router and a nearby public endpoint at the same time to see whether delay begins inside or beyond the home.
If wired latency is stable, the broadband line is not the first suspect. Fix signal, interference or roaming.
If ping rises only under download or upload load, use the bufferbloat fix guide instead of treating it as a constant routing fault.
Quick reference
These combined symptom-and-cause cards replace separate issue, cause and validation blocks.
Wireless airtime, weak signal, interference, mesh backhaul or device drivers are adding delay locally.
Next: keep Ethernet as the control and work through the unstable-Wi-Fi guide.Router or access-link queues are filling behind downloads, uploads, cloud backup or CCTV traffic.
Next: use the bufferbloat fix guide and compare both loaded directions.The delay may come from the access line, DLM profile, provider routing, congestion, modem processing or a VPN path.
Next: compare the router gateway with a public endpoint and test without VPN.The destination server, region selection, peering route or service load is more likely than a general broadband fault.
Next: select a nearer region and compare another real-time service.Household traffic, shared local capacity or an external peering route may be busy.
Next: repeat the same quiet and peak test with household traffic paused.Delayed delivery is being compounded by unstable or failed packets from Wi-Fi, cabling, hardware or the external line.
Next: run the packet-loss test over Ethernet and Wi-Fi.Practical reference
Use a nearby UK endpoint and a wired connection for comparison. Distance changes normal ping, so your own repeatable baseline matters more than one universal number.
| Pattern | Ping | Jitter | Packet loss | Meaning |
|---|---|---|---|---|
| Very stable | Often below 30 ms to a nearby server with small variation. | Below 5 ms. | 0%. | Suitable baseline for responsive gaming and calls. |
| Needs investigation | 30–80 ms may be usable, but repeated jumps of 30–100 ms above baseline are noticeable. | 5–15 ms. | Any repeatable loss deserves investigation. | Compare Wi-Fi, load and destination. |
| Severe instability | Repeated rises above 100 ms from baseline or peaks around 150 ms and above. | Above 15 ms. | 1% or more, or bursts of consecutive loss. | Real-time apps are likely to stutter or disconnect. |
Average ping can hide the fault. Record idle, average and maximum ping together. A 20 ms average can still conceal repeated 200 ms peaks.
Test in order
Keep the same endpoint and change one variable at a time.
Run the LinkSpeed Ping Test with VPNs, downloads, uploads and streaming paused. Save idle, average and maximum latency plus jitter.
If the wired result is stable, focus on router position, channels, mesh placement, device drivers or the affected room.
If the router ping spikes, the fault is inside the home. If the gateway stays stable but the public ping rises, the delay begins beyond the LAN.
Run the bufferbloat test. A quiet baseline that collapses under upload or download load confirms queueing rather than constant path delay.
Run the packet-loss test over both connection types. Persistent wired loss across services is stronger provider evidence than one isolated timeout.
Test another nearby server or app and repeat off peak and during the problem. This separates one service from a wider provider path.
ipconfig
ping -t YOUR_ROUTER_IP
ping -t 1.1.1.1Press Ctrl+C to stop and compare minimum, average, maximum and loss. Replace YOUR_ROUTER_IP with the default gateway shown by ipconfig.
ip route
ping YOUR_ROUTER_IP
ping 1.1.1.1Run the router and public tests in separate terminal windows while the issue is happening.
tracert 1.1.1.1 # Windows
traceroute 1.1.1.1 # macOS or LinuxOne slow intermediate hop or an asterisk does not prove a fault because routers can deprioritise diagnostic replies. Stronger evidence is delay or loss that begins at one point and continues through later hops and the destination.
Advanced checks
These subjects are kept in expandable panels so the main diagnostic route stays compact.
On VDSL2, classical interleaving can add constant delay while protecting a noisy line. G.INP physical-layer retransmission is different and can provide impulse-noise protection with less constant latency. The exact result depends on the cabinet, modem and active DLM profile.
Check sync rate, error counters, retrains, attainable rate and the active retransmission or interleaving status. Avoid repeated router reboots because DLM can interpret frequent retrains as instability.
CGNAT allows providers to share public IPv4 addresses. It can complicate inbound connections and NAT type, but it does not automatically explain high ping. Test several nearby services first, then ask whether a public or static IPv4 option is available if multiplayer NAT or route problems remain.
If periodic wired spikes remain while the line is quiet, check firmware, heat, CPU load and modem mode. Some older gateway or cable-chipset designs can produce short processing stalls that a download-only test misses.
Use the provider guide and compare idle, loaded and packet-loss results before replacing hardware.
On G.fast and high-speed FTTP, CAKE or FQ-CoDel can become CPU-bound before the line reaches full rate. A wired throughput plateau while loaded latency improves points toward router processing limits rather than a general high-ping fault.
Keep this page focused on finding the latency boundary. For queue statistics, CPU checks, offloading and firmware-specific settings, use the OpenWrt section of the bufferbloat fix guide.
A large download does create return ACK traffic, but on a healthy 80/20 FTTC line it normally uses only a small part of the upstream capacity. Severe spikes are more often caused by deep queues, another upload source or incorrect shaping than ACK packets alone.
Advertisement · Affiliate
After Ethernet, packet-loss and loaded-latency checks are clean, a different VPN route can sometimes improve an inefficient path to one destination. It can also make ping worse, so compare the same game region with the VPN off and on.
Apply the result
Do not change the broadband package until the fault layer is clear.
Do: improve router position, channel use, mesh backhaul or device Wi-Fi. Keep latency-sensitive devices wired where practical.
Retest: same endpoint and time over Wi-Fi and Ethernet.
Do: identify the upload or download trigger, schedule bulk transfers and limit upload-heavy devices.
Retest: restart one activity at a time.
Do: enable SQM with CAKE or FQ-CoDel where supported and shape below stable wired throughput.
Retest: both loaded directions after every change.
Do: select a nearer region, check service status and test without VPN.
Retest: another server and another real-time app.
Do: replace the test cable, bypass powerline adapters and extra switches, then test directly at the router.
Retest: gateway and public endpoints over Ethernet.
Do: collect comparable quiet and peak results on at least two days with local traffic paused.
Retest: same endpoint, device and cable.
Escalate with evidence
Escalate when the problem remains on Ethernet, affects several nearby services, continues with household traffic paused and repeats at comparable times.
Date and time, Ethernet or Wi-Fi, router ping, public ping, idle/average/maximum latency, jitter, packet loss, VPN state and affected services.
State whether the router remained stable while external latency rose, whether the issue is peak-time only and whether more than one service was affected.
Focused answers
These answers match the FAQ structured data in the page head.
Download speed measures capacity, while ping measures delay. High ping with good speed usually points to Wi-Fi retransmissions, a distant server, VPN routing, bufferbloat, packet loss, line-profile delay or provider routing.
A wired ping below about 30 ms to a nearby server is usually responsive, but the important comparison is your own stable baseline. A distant game server can be higher without indicating a broadband fault.
That pattern normally indicates bufferbloat or queue saturation. Bulk traffic fills the router or access-link queue, so gaming, voice and acknowledgement packets wait behind it.
CGNAT can add a provider-side translation layer or an awkward route, but it is not automatically the cause of high ping. Compare several nearby services and ask the provider whether a public IPv4 option is available if NAT or routing problems persist.
Classical interleaving can add constant latency to protect a noisy VDSL2 line. G.INP retransmission is different and can provide protection with less constant delay. The exact effect depends on the active DLM profile.
Contact the provider when high ping remains on Ethernet across several nearby services at different times, with VPNs and household traffic disabled. Include timestamps, gateway and public ping, jitter and packet-loss evidence.