A practical checklist for slow or unstable internet
Slow internet reports are easier to solve when you isolate where the slowdown starts. The same symptom can come from a broadband fault, weak Wi-Fi, router load, a single busy device, or congestion at a specific time of day.
Choose the next test from the symptom
Start by deciding whether the problem affects one device, one room, one service, or the whole connection. The table below is a triage method, not a diagnosis. Record what changes and what stays the same after each check so the next person does not need to repeat the entire process.
| Pattern | Next comparison | What that comparison can tell you |
|---|---|---|
| Only one device is slow | Another device in the same room at the same time | A difference points toward the device, browser, VPN, or its Wi-Fi connection |
| Only one room is slow | The same device next to the router | An improvement points toward coverage, interference, or mesh backhaul |
| All devices slow during uploads | Pause the upload, then repeat under the same conditions | An improvement suggests shared upload capacity or queueing is involved |
| Only one website is slow | Other websites on the same device and connection | The affected service, DNS, or its route may be involved; a general speed test cannot isolate it |
| Ethernet and Wi-Fi are both slow | A quiet-network test and the provider's service-status check | This reduces the chance that room-specific Wi-Fi coverage is the sole cause |
Start with a clean baseline
Run a test when the network is quiet. Pause cloud backups, game updates, streaming boxes, file transfers, and operating system updates before measuring.
Record the result before restarting equipment. The original public IP, provider path, and performance numbers can help explain whether a later reboot changed anything.
Compare wired and wireless results
If possible, test with Ethernet from a laptop connected directly to the router. A strong wired result and poor Wi-Fi result points toward wireless coverage, interference, mesh backhaul, or device placement.
If wired and wireless tests are both poor, check router load, broadband service status, modem signal levels where available, and whether the slowdown happens at predictable times.
Test more than one device
A single slow phone or laptop may have its own issue: poor signal, old Wi-Fi standard, VPN software, low power mode, browser extensions, or security scanning.
If every device is affected in the same location, the room or access point is more likely to be the problem. If every device is affected everywhere, the router or broadband path is more likely.
Look for upload saturation
Many connections have much less upload than download. One cloud backup or video upload can make calls and browsing feel broken even while download tests look acceptable.
Run a test during a video call problem and check upload, latency, and jitter together. High latency under load can point to router queueing or a saturated uplink.
Worked example: an office at the far end of the house
In this invented example, one laptop measures 18 Mbps in the office and 95 Mbps beside the router. An Ethernet run on the same laptop measures 110 Mbps. These are comparison numbers, not promised speeds. The improvement when the local connection changes makes the office wireless path the first thing to investigate.
Move a mesh node closer to its upstream node, away from obstructions, and repeat from the original desk. A node placed in an existing dead spot may have a weak connection back to the router even if the laptop sees strong signal bars. Record whether the node uses wired or wireless backhaul.
If moving the node makes no consistent difference, compare another device at the desk and check which access point each device joins. Do not assume a Wi-Fi extender or a faster broadband package will solve the issue before establishing which link is limiting it.
Avoid changes that erase the evidence
Do not factory-reset a working router as an initial test. A reset may erase provider settings, Wi-Fi names, and any business configuration. If a restart is necessary, save the original results and arrange a suitable interruption for anyone using calls or remote access.
Keep workplace security controls in place unless your IT team authorises a comparison. Stop speed tests during a critical call or when mobile data costs matter. Port233's short test still transfers real data and competes with other traffic.
A DNS change is worth investigating when names fail to resolve, but it does not add capacity to the broadband line. Save existing settings and follow the resolver provider's instructions if you have evidence of a DNS problem. If just one site fails, check its status before changing the whole network.
Collect evidence for support
Useful support notes include the date and time, wired versus Wi-Fi method, room or access point, public IP, ISP/ASN, speed result, latency, jitter, and what else was using the connection.
Repeatable evidence saves time. A single result can show a symptom, but a short pattern usually shows where to investigate next.
Download the free troubleshooting worksheet (.txt)
Sources and tool notes
The examples above are illustrative. The references below describe the tools and methods used. Read more about Port233-specific behaviour in our methodology and limitations.
- Cloudflare: what speed-test measurements describe
- Google Public DNS: configuration and connection troubleshooting
Found a mistake? Send a correction with the page address and the result you expected. See our editorial approach.