The internet fuels our work, entertainment, and connection to loved ones. When it sputters, slows, or vanishes entirely, frustration soon follows. Before contemplating drastic measures like throwing your router out the window, let's put on our detective hats and find out which part of the connection needs attention.
A Wi-Fi connection and an internet connection are different things. Your laptop can reach the router while the router cannot reach the outside world. Equally, a single broken website does not mean the whole connection is down. Start with those distinctions and change one setting at a time, so you can tell what helped.
Diagnosing the Culprit: Sherlock Holmes Mode Activated
Before grabbing the proverbial magnifying glass, build a picture of the problem:
- Isolate the issue: Try another device on the same network and two unrelated websites. If only one app fails, check that service's status and the app itself before changing the household network.
- Compare connections: Test near the router, then over Ethernet to a router LAN port if available. Keep the normal router and firewall in place. A better wired result points toward the wireless path; it does not automatically identify which access point, client, or setting is responsible.
- Timeline is key: Note when the issue started and whether it follows a firmware update, new VPN, moved mesh unit, power cut, or scheduled backup. An evening slowdown is useful evidence, but needs repeated measurements before you blame neighbourhood congestion.
- Check the usual suspects: Use your ISP's official status page or support channel. If home internet is unavailable, a phone's mobile connection can help you check. A clear status page does not rule out a fault affecting your individual line.
Write down the router, modem, or fibre ONT indicator lights and any error messages before restarting equipment. Logs and uptime can disappear during a restart. Take care when sharing screenshots: account details, Wi-Fi passwords, and public addresses may need redacting.
Common Culprits and Their Nemesis: Troubleshooting Tips
These checks move from the shared network toward individual devices. Stop when you have enough evidence to investigate a specific cause.
1. The Router: Your Network's Gatekeeper
- Restart deliberately: A normal restart can clear a temporary problem, but briefly disconnects the household. Follow the equipment maker or ISP's sequence and allow the connection to re-establish. A restart is different from a factory reset, which erases configuration.
- Connection check: Check power and Ethernet plugs, including the WAN cable between router and modem or ONT. Try a known-working Ethernet cable and LAN port where practical. Do not unplug or handle a fibre connector casually; ask the provider about optical-link alarms.
- Firmware update: Use the manufacturer's instructions for your exact model and hardware revision. Read the release notes, preserve configuration where supported, and choose a suitable maintenance window. Do not interrupt power during an update.
2. ISP: The Source of the Internet River
- Contact your ISP: Report whether every device is affected, what the equipment lights show, and whether the problem happens on Ethernet as well as Wi-Fi. The provider can check line or service information you cannot see locally.
- Check account and service status: An outage, activation problem, or account restriction can require provider action. Router setting changes will not resolve every upstream fault.
- Avoid repeated resets: If the modem or ONT repeatedly loses its connection, record the times and contact support. Follow their advice before restarting provider-managed equipment or changing WAN authentication settings.
3. Signal Interference: The Invisible Foe
- Check placement: Compare performance near the router with performance in the affected room. Walls, obstructions, and competing radio traffic can affect Wi-Fi. Avoid hiding the router in a cupboard or immediately beside potential interference sources such as a microwave.
- Check the mesh path: A satellite can show a good signal to your phone while having a poor wireless connection back to the main router. Check its backhaul status and test a better position before buying more units.
- Change channels carefully: Follow the router's regional channel options and manual. Automatic selection may already be suitable. Record the old setting and compare repeated results after one change; selecting a channel once does not guarantee lasting improvement.
4. Device-Specific Issues: The Individual Culprits
- Check basic settings: Confirm the device joined the intended network and that Wi-Fi is enabled. Test another browser or app if only one fails. A captive portal on a guest or public network may require sign-in before internet access works.
- Check software changes: Update the operating system and network driver from trusted manufacturer sources. Inspect recently changed VPN, proxy, or security software settings. Do not disable the firewall or ignore certificate warnings as a general fix.
- Check competing traffic: Pause a large download or cloud upload briefly and compare responsiveness. Run a trusted malware scan if there are signs of compromise; poor speed alone is not proof of malware.
- Keep resets for later: Windows network reset removes adapters and their settings and can require VPN or virtual-switch reconfiguration. Microsoft treats it as a last troubleshooting step, so preserve those details first.
Bonus Tip: Invest in a Quality Router
A good-quality router can improve your experience when the existing equipment has poor coverage, unsupported firmware, insufficient ports, or inadequate capacity for the work you need it to do. That remains a useful investment when testing identifies a limitation. Price and Wi-Fi branding alone do not guarantee a better result, though: even an expensive router cannot repair an ISP line fault or a broken website. For a coverage problem, placement or an additional access point with suitable backhaul may be more relevant than replacing the main router.
The 4-Step Command-Line Isolation Test: Where Is the Bottleneck?
These four checks collect clues rather than promising an instant diagnosis. On Windows, open Command Prompt or PowerShell and run ipconfig. Find the active adapter's Default Gateway; it is not necessarily 192.168.1.1. On macOS or Linux, find the router or gateway in the active connection's network settings. VPNs and multiple adapters can complicate which path is in use.
The table uses Windows commands. Replace the example gateway with your actual address. On Linux, ping -c 4 sends four probes; command options differ across operating systems, so check the installed tool's help. traceroute is the corresponding path-tracing tool on macOS/Linux, but may need installing on Linux.
| Test Step | Windows Command | What It Checks | How to Interpret the Result |
|---|---|---|---|
| 1. Local gateway | ping /n 4 192.168.1.1 using your actual gateway | Whether the gateway responds to ICMP echo probes from this device. | Replies show reachability at that moment. Compare Wi-Fi with Ethernet and another device. Repeated delay or missing replies deserves investigation, but some routers restrict or deprioritise these responses. There is no universal pass/fail latency threshold. |
| 2. External address | ping /n 4 1.1.1.1 | Reachability to one external IPv4 address without a hostname lookup. | Replies show a working IP path to that destination, not that every service works. Missing replies can reflect filtering, a VPN, routing, or destination behaviour as well as a WAN problem. Compare other destinations and real applications before concluding the line is down. |
| 3. DNS lookup | nslookup techdecode.online | A name lookup through the tool's selected DNS server. | Record the server shown and the response or error. Test another known domain. A failure may involve the resolver, the domain, or the path to the resolver. A successful lookup does not prove the website or its HTTPS connection is healthy. |
| 4. Path trace | tracert -d 1.1.1.1 | Which responding routers appear along the path; -d skips reverse name lookups. | Asterisks can simply mean a router did not answer probes. Hop 2 is not universally an ISP aggregation node. An isolated slow intermediate response does not prove congestion if later hops and the destination respond normally. |
Repeat a short test when the problem occurs and again when the connection is healthy. Four probes are a quick sample, not a reliable estimate of intermittent loss. End-to-end problems that recur across multiple devices and destinations are stronger evidence than a single alarming line in a trace. Microsoft's TRACERT documentation explains why some routers remain invisible to the tool.
If an IP ping works but the browser fails, do not assume the ISP's DNS server has crashed. The browser may use DNS over HTTPS through a different resolver, and browser, proxy, certificate, clock, or website problems can also interfere. If evidence points to DNS, compare a lookup using a second trusted resolver before making a household-wide change. Public resolvers do not know your private homelab names and may change filtering behaviour. Keep a record of the original settings and restore them if the experiment does not help.
Making Speed Tests Comparable
Run a baseline through Ethernet to the router when practical, with other large transfers paused. Record download speed, upload speed, latency, the test provider or server, time, and connection type. Repeat using the same service and device, then compare Wi-Fi at the location where the problem occurs. A slow result includes the client, browser, local network, and path to the test server; it is not a measurement of the ISP alone.
Compare with the plan's stated rates while allowing for your device and router ports. A fast download number does not tell you whether a video call will remain responsive during an upload. Different tools also use different workloads. Cloudflare explains that its test uses predefined transfer sizes rather than aiming to saturate the connection, so it should not be treated as a definitive maximum-throughput check.
How to Diagnose and Cure "Bufferbloat" (Lag Under Load)
If calls or games become sluggish during a large upload or download, excessive queueing is one possible explanation. Bufferbloat is delay caused by too much data waiting in network buffers. It can occur at different points along a connection; the symptom alone does not identify a particular modem or router. Weak Wi-Fi and other congestion can produce similar frustrations.
Compare latency when idle with latency during transfers. The Waveform Bufferbloat Test and Cloudflare Speed Test are examples of tools that examine responsiveness under load, but their workloads and scoring are different. Compare measurements from the same tool and connection type before and after a change, rather than treating their scores as interchangeable. A repeatable increase over Ethernet helps separate a busy-link problem from a room-specific wireless problem.
On a compatible router, Smart Queue Management (SQM) can combine traffic shaping with queue management. The sqm-scripts project supports either HTB shaping with FQ-CoDel scheduling or CAKE's integrated shaping and scheduling. A generic QoS toggle does not necessarily provide the same functionality.
Measure your connection without shaping, then follow the router's supported SQM setup and tune upload and download rates while checking both throughput and loaded latency. A rate below the actual bottleneck can help your router manage the queue; setting a cap too low unnecessarily sacrifices capacity. There is no percentage that suits every connection, especially when cellular or other link rates vary. Queue management can improve responsiveness, but cannot promise zero latency or remove congestion elsewhere on the internet.
The Bufferbloat project's guidance recommends measuring, enabling supported SQM, and adjusting it based on results. If the router lacks that capability, use the measurements to discuss options with its vendor before buying equipment.
Giving Support Useful Evidence
When the basics do not resolve the issue, send support a short record: when it happens, affected devices, wired versus wireless results, equipment models and firmware, indicator lights, and relevant lookup or trace output. Include whether the issue affects every destination or just one service. Ask what the provider can see on the line and what further comparison they need, rather than asserting a fault from one test.
After a change, repeat the task that originally failed as well as your measurements. Restore unsuccessful experimental settings and keep notes on what helped. With that little bit of detective work, the internet blues become a problem you can describe clearly and tackle methodically.
