“The router keeps disconnecting” can describe several different failures. Your device may lose the Wi-Fi signal, stay connected to Wi-Fi but lose internet access, or only one application may stop working. The fix depends on which layer is actually failing.

Watch the Wi-Fi icon and local connectivity

If the Wi-Fi network disappears or the signal drops, focus on wireless coverage, interference, access-point stability, or the client device. If Wi-Fi remains connected but the internet fails on every device, focus on the WAN/ISP side.

Compare wired and wireless devices

If Ethernet remains stable while Wi-Fi drops, the ISP connection is probably not the cause. Check channel congestion, router placement, firmware, overheating, and band-steering behavior.

Check the physical environment

Keep the router in open air, away from enclosed cabinets and heat sources. Large metal objects, reinforced walls, aquariums, and neighboring access points can reduce signal quality. A mesh node placed at the edge of usable coverage has little good signal to repeat.

Review firmware and power

Use the manufacturer’s supported firmware for the exact model and hardware revision. An unstable power adapter can cause reboots that look like network drops. Check the system uptime/log if the interface provides one.

Test the modem or ONT side

When every device loses internet at the same time, record the modem/ONT indicators and router WAN state before rebooting. That evidence helps distinguish a local router reboot from an ISP signal or authentication problem.

Watch what disappears

If the SSID vanishes or the client drops association, investigate radio/router stability. If Wi-Fi stays connected and the gateway remains reachable but internet stops, investigate WAN/ISP/DNS. If the router itself becomes unreachable, power/firmware/hardware or a reboot loop is possible.

Collect timestamps

Write down when drops occur, whether wired clients fail too, which band/node the client used and what router/modem logs show. Patterns reveal interference, DHCP lease events, WAN renewals or hardware resets better than repeated speed tests.

Mesh-specific checks

A client can appear connected while a satellite loses backhaul. Test near the main node and compare wired backhaul where possible.

Diagnostic rule: prove the failing layer before changing settings

Start with physical/link state, then local IP/gateway, then router/WAN status, then DNS/application behavior. This order prevents destructive resets and random configuration changes from hiding the original problem. Write down what works and what fails after each step.

When to stop and contact the provider/vendor

Escalate when the fault is upstream of equipment you control, when provider provisioning is involved, when hardware is under warranty, or when the next step would erase settings you cannot reconstruct. Capture model, firmware, timestamps and test results first.

A four-layer field test you can use before changing configuration

1. Link and association

Verify that Ethernet shows a physical link or that Wi-Fi is connected to the intended SSID. A device connected to a similarly named guest, extender or neighbor network can make every later test misleading. On a phone, temporarily disable cellular data if you need to prove the browser is using the local LAN.

2. Local addressing

Read the client IPv4/IPv6 address, subnet/prefix, default gateway and DNS servers. A self-assigned 169.254.x.x IPv4 address usually means DHCP failed. A normal private address without a reachable gateway points to a different failure than a working gateway with no internet.

3. Gateway and WAN

Open or ping/test the gateway using a method appropriate to the device. If local management works, inspect router WAN status rather than resetting Wi-Fi. Look for WAN address, link state, lease/session status and provider alarms on modem/ONT equipment.

4. Name resolution and application

Separate DNS from connectivity. If an IP destination works but names fail, investigate resolver settings/cache. If DNS and routing work but one site/app fails, the problem may be remote, TLS-related, filtered or application-specific.

Document before escalating

Record exact error messages, timestamps, model/firmware, wired versus wireless result and whether multiple devices are affected. This turns “internet broken” into evidence an ISP or vendor can act on.

Wi-Fi-specific evidence to collect

Record band, channel/channel width, RSSI/signal level if available, negotiated link rate, node/access point association and whether the same symptom occurs over Ethernet. A wired control test is especially valuable: if Ethernet is stable while Wi-Fi fails, focus on radio/interference/roaming rather than WAN or DNS.

Client compatibility matters

Old drivers, power-saving behavior, unsupported WPA modes and device-specific roaming decisions can make one client fail while every other device works. Update the client and test another device before changing the whole network around a single endpoint.

What not to do while diagnosing the problem

Do not factory-reset the router merely because a familiar address does not open. Do not change DNS, Wi-Fi channels, DHCP and firewall rules simultaneously. Do not download “router unlock” utilities or enter administrator credentials into a public website. Those actions add risk without proving the failing layer.

A good stopping point

Stop local troubleshooting when the evidence clearly shows a provider outage/provisioning issue, failing hardware, or a model-specific recovery process you cannot safely complete. Preserve logs/screenshots and the exact tests that isolated the fault, then escalate with those facts.

After the fault is fixed

Remove temporary test settings, reconnect any VPN/security tools you disabled, verify several devices, and document the final LAN/gateway/DNS configuration. If a reset was required, restore security settings intentionally rather than assuming every factory option is appropriate.