Begin with a specific symptom

Write down which task is affected, on which device, at what time, and whether other devices or services show it too. A slow browser test alone does not separate the router, provider, remote endpoint, or device. This checklist narrows possibilities; it does not issue an automated fault verdict.

Record the setup before changing it

Keep the device, browser, task, destination, VPN state, and other traffic in the log. Note the active interface and local link speed. Save settings before making changes. Do not bypass a provider device, disconnect shared equipment, or reset a router without understanding authentication, phone service, and recovery requirements.

Compare one condition at a time

If available, use the same device on Ethernet to the router and Wi-Fi, disabling the unused interface. Repeat near the access point and at the usual location. Compare quiet and normal busy periods separately. Try a second application or destination to see whether the symptom is service-specific. Alternate run order and keep failed attempts and validity warnings.

A controlled sequence you can actually follow

This is a troubleshooting sequence, not proof that a particular component is faulty. Use the same device and test service where possible, and note when the selected endpoint changes. Tests transfer data: stop after you have a useful comparison if your connection is metered. Do not run repeated large tests during an important call or a shared household task.

  1. Record the starting condition. Note the device, operating system, browser, room, active interface, affected task, time and timezone. Keep a required managed VPN or security control enabled and record it. Pause only discretionary traffic that you are allowed to pause.
  2. Establish a wired observation if practical. Connect that same device to a normal router LAN port using Ethernet and a supported adapter. Select that connection without changing the router's WAN configuration. If you cannot safely confirm the active interface, record the uncertainty. Do not bypass the router, reset it, or unplug shared phone equipment for this comparison.
  3. Compare nearby Wi-Fi. Use the same device near the access point, select Wi-Fi rather than the cable connection, and repeat the same task and test. Record changes in endpoint or household traffic. A local negotiated link speed is a device-to-router link rate, not the internet throughput you should expect.
  4. Check the problem location. Repeat on that device in the usual room. Then revisit the earlier condition in reverse order where practical. A one-off change may be timing or background activity, not location.
  5. Try a second device as a separate check. Use the same location and affected task. Record that the device changed: this is useful evidence, not a perfectly controlled repeat of the first device's result.

If Ethernet is unavailable, compare nearby Wi-Fi with the problem location and record that limitation. Do not describe the result as a wired baseline or claim it separates the access line from all local wireless effects.

Choose the next check from the pattern

Nearby Wi-Fi works, but the same device struggles in the usual room
Investigate coverage, placement and obstructions first. Repeat after one reversible placement change; do not buy a faster plan solely from this pattern.
One device struggles while a second works in the same location
Inspect that device's active adapter, supported driver updates and background activity. Different radios and software still make this a clue, not a definitive device diagnosis.
Wired and nearby Wi-Fi both struggle on more than one device
Collect the observations and ask support about provisioning, faults and supplied equipment. The router, upstream service and remote destination remain candidates; the pattern does not select one automatically.
Only one application or destination struggles
Record its region or endpoint, time and error. Follow that service's status and troubleshooting guidance; a normal browser test does not validate the application's path.
A required managed VPN is present
Keep it in the record and involve the administrator. Do not disable a mandatory control to manufacture a cleaner comparison.

Microsoft's Windows Wi-Fi troubleshooting guide includes connection-status and device checks. Its reset, driver-removal and restart procedures are not prerequisites for this low-disruption sequence; read their consequences before using them.

Keep a private record with the copyable support template. Change one reversible setting at a time and restore it if connectivity or another user's service worsens.

Interpret patterns as clues, not proof

An improvement on Ethernet suggests investigating wireless conditions, but does not prove the provider is healthy. Problems on both interfaces leave the device, router, upstream path, and destination in scope. An evening pattern does not establish deliberate throttling. A VPN changes the route and is not a controlled proof of provider intent.

Change cautiously and escalate with records

Follow device documentation, check supported updates and cables, and try one reversible adjustment. Restore it if service worsens. Avoid unsupported universal router replacement or plan-upgrade recommendations. Send support dated observations, affected applications, active interfaces, local link details, and warnings. For multi-node home networks, see our dedicated guides on Mesh Wi-Fi vs Traditional Router and investigating mesh slowdowns after Ethernet backhaul. Ask what further checks are needed rather than presenting this checklist as a component test.