The next time the connection drops, do not open any settings screen. Pick up a second device and a third one, and look at them while the drop is still happening. That observation decides everything that follows, and it cannot be reconstructed afterwards.
If the other devices kept working, the fault lives on the one device that dropped, and no router setting will fix it. If every device lost the network in the same second, the fault lives in the access point or the line behind it, and no client setting will fix it. These two situations produce an identical complaint and share almost no repair steps. Working through a generic checklist without splitting them first is how a Wi-Fi problem survives a weekend of effort.
Everything below is taken from published documentation: Microsoft support articles for Windows, Apple support articles for iOS and macOS and for router configuration, and the Federal Communications Commission rules in 47 CFR Part 15 for the radio behaviour. Where a widely repeated explanation has no first-party source behind it, it is left out, and it is named as left out near the end.
Split the Fault Before Changing Anything
The count of affected devices is the only diagnostic that costs nothing and rules out half the work. It has to be taken during a drop, because a device that reconnects in fifteen seconds leaves no trace a person can see later.
One qualifier matters more than it looks. Simultaneous means the same second, not the same evening. Two laptops that each drop a few times an hour, on their own schedules, are two instances of the left column, not one instance of the middle column.
When Only One Device Drops
On Windows there is a way to stop guessing about the frequency and the timing. At a command prompt, run:
netsh wlan show wlanreport
Microsoft documents that this builds a wireless network report "saved as an HTML file, which you can open in your favorite web browser," and that it "shows all the Wi-Fi events from the last three days." The report's Summary contains sections for Session Success/Failures, Disconnect Reasons, Session Durations and Wireless Sessions. Three days of session durations and disconnect reasons is a far better starting point than a recollection that it happens "a lot."
The Power Management Checkbox
Microsoft's own Wi-Fi troubleshooting article for Windows lists a per-adapter power setting. The path is Device Manager > Network adapters > the wireless adapter > Properties > Power Management tab, and the checkbox is worded "Allow the computer to turn off this device to save power." Clearing it removes one documented mechanism by which the operating system may power down the radio. This is a single-device setting; it has no bearing on any other device on the network.
The Saved Profile and the Reset Ladder
Microsoft documents three escalating steps, and the order matters because each one discards more state than the last.
- Forget the one network. "In the Settings app on your Windows device, select Network & internet > Wi-Fi, then select Manage known networks. Select your Wi-Fi network and click Forget." Then reconnect and re-enter the password.
- Reset the stack. The documented commands are
netsh winsock reset,netsh int ip reset,ipconfig /release,ipconfig /renewandipconfig /flushdns. - Network reset. In Windows 11 this is Settings > Network & internet > Advanced network settings > Network reset; in Windows 10 it is Settings > Network & Internet > Status > Network reset. Microsoft's description is explicit about the cost: "Network reset removes any network adapters you have installed and the settings for them. After your PC restarts, any network adapters are reinstalled, and the settings for them are set to the defaults." Every saved network and every VPN profile goes with it, so this belongs last, not first.
A Randomised Address Against a Fixed Reservation
This is the failure that most reliably produces a one-device drop while the household stays online, because two features that are individually sensible cancel each other out.
Microsoft's setting is called Random hardware addresses and sits under Settings > Network & internet > Wi-Fi, with a per-network copy under Manage known networks. Microsoft's stated purpose is to "make it harder for people to track you when your device scans for networks and connects," because the probe signal a device sends while looking for networks "contains the unique physical hardware (MAC) address for your device."
Apple's equivalent is Private Wi-Fi Address, present from iOS 14, iPadOS 14 and watchOS 7, and on the Mac from macOS Sequoia 15. From iOS 18, iPadOS 18, macOS Sequoia 15, watchOS 11 and visionOS 2 onward, the setting takes three values: Off, where "your device uses its hardware MAC address"; Fixed, where the "private address doesn't rotate, regardless of the network's security"; and Rotating, which "rotates to a different private address every 2 weeks." Apple also notes that "Businesses and other organizations might need to update their Wi-Fi network security to work with private addresses."
A rotation interval measured in weeks matters for diagnosis. If a device worked for a month and then began losing its place on the network, the interval fits, and Fixed is usually the setting to move to rather than Off, because it keeps one stable address per network without exposing the hardware address. Apple's own router guidance points the same way from the other end: it recommends setting MAC address filtering to Disabled, on the grounds that hardware addresses "can easily be copied, spoofed (impersonated), or changed."
Two Interfaces Competing on the Same Machine
A machine with more than one live network interface can behave as though Wi-Fi is dropping when it is simply not the interface being used. On macOS the ordering is explicit and editable: Apple menu > System Settings > Network, then the Action pop-up menu > Set Service Order, then "Drag services into the order you want" and click OK. Apple documents one exception worth knowing before hunting for it: "you can't change the order of virtual private network (VPN) connections because they already take priority over non-VPN connections." Apple lists this path for macOS versions from High Sierra through Tahoe 26.
When Every Device Drops at the Same Moment
Simultaneous loss across unrelated devices means the access point stopped serving, and one legally mandated behaviour explains a large share of these events without any fault existing at all.
Dynamic Frequency Selection is required for unlicensed devices operating in the 5.25-5.35 GHz and 5.47-5.725 GHz bands. The rule text is unambiguous about what happens on a detection: "After a radar's presence is detected, all transmissions shall cease on the operating channel within 10 seconds. Transmissions during this period shall consist of normal traffic for a maximum of 200 ms after detection of the radar signal." The channel is then flagged and "is subject to a non-occupancy period of at least 30 minutes," counted from the moment of detection. Before the device can start using any DFS channel, it must first listen: it "may start using the channel if no radar signal with a power level greater than the interference threshold values" is detected "within 60 seconds." Those thresholds are -64 dBm for devices between 200 mW and 1 W EIRP, and -62 dBm for lower-power devices.
The practical consequence is a drop that is longer than the ten-second move suggests, because the access point may have to spend another sixty seconds listening before it can transmit again. It is also recurring: a rotating radar comes back around. Homes near an airport, a coastal weather radar or a military installation see this pattern most, and no amount of client-side repair touches it. The fix is to move the access point off DFS channels, or to accept the behaviour and stop investigating it.
Router Settings Worth Checking Against a Published Baseline
Apple publishes recommended settings for Wi-Fi routers and access points, which is one of the few vendor-neutral baselines a home network can be measured against. The relevant entries for a repeating-disconnection problem:
| SSID name across bands | "Make sure that all routers on your network use the same name for every band they support." |
| Hidden network | "Set to Disabled." Hiding the name "doesn't conceal the network from detection or secure it." |
| MAC address filtering | "Set to Disabled." |
| DHCP lease time | "Set to 8 hours for home or office networks. Set to 1 hour for hotspots or guest networks." |
| Channel selection | "Set to Auto." |
| Channel width | "Set to 20 MHz for the 2.4 GHz band. Set to Auto or all widths for the 5 GHz and 6 GHz bands." |
| Security | "Set to WPA3 Personal for better security, or set to WPA2/WPA3 Transitional for compatibility with older devices." |
| Automatic firmware updates | "Set to Enabled." |
Firmware belongs on this list rather than at the end of it. Apple's stated reason for enabling automatic updates is that they "deliver other important improvements to the stability, performance, and security of your router" — stability being the word that matters for a router that drops all clients on a schedule.
When Some Devices Drop and Others Do Not
The third column of the first diagram is the one that rewards patience. The task is to find the attribute the affected devices share and the unaffected ones do not, and the most common shared attribute is the frequency band.
Three bands are in play in the United States. The 2.4 GHz range under 47 CFR 15.247 is 2400-2483.5 MHz. The 5 GHz U-NII ranges include the two DFS bands above, plus 5.15-5.25 GHz and 5.725-5.850 GHz, which are not subject to DFS. The 6 GHz range is 5.925-7.125 GHz, where low-power access points and their client devices are limited to indoor locations, and standard-power access points in 5.925-6.425 GHz and 6.525-6.875 GHz operate under an Automated Frequency Coordination system.
What follows from this is a rule about how to check, not a claim about any device. Whether a given phone, laptop, thermostat or camera can use 5 GHz or 6 GHz depends on the radio in that specific model, and that is a question for that manufacturer's specification sheet, not for a general article. Assuming a band is exactly the error that sends people to reconfigure a router that was never at fault. Read the connected-device list on the router, note which band each affected device is actually associated with, and compare that against the devices that stayed up. If every affected device is on 5 GHz and the survivors are all on 2.4 GHz, the DFS timeline above is the first thing to test — by moving the access point to a non-DFS channel and watching whether the pattern stops.
What Is Deliberately Left Out
Three explanations that appear constantly in Wi-Fi troubleshooting are absent above because no first-party source was confirmed for them here.
- Named devices that "only support 2.4 GHz." Band support is a per-model hardware fact. It is checked on the manufacturer's specification page for that exact model, and it is not asserted here for any device.
- DHCP renewal fractions. The figures usually quoted for when a client starts renewing a lease, and when it begins broadcasting for any server, were not confirmed from the protocol specification for this article. What is used instead is the observable behaviour and Apple's published lease-duration recommendation.
- Named sources of 2.4 GHz interference. Specific household appliances are routinely blamed. The band edges and Apple's 20 MHz channel-width recommendation are cited above instead, because those are documented; the appliance list is not.
When This Doesn't Apply
This frame assumes a repeating drop that recovers on its own. It does not fit several nearby situations.
- The Wi-Fi holds but the internet does not. If the device stays associated with the network and only web traffic fails, the fault is past the access point, in DNS or upstream. The device count says nothing useful, because every device will fail together regardless of cause.
- A single continuous outage rather than repeated drops. One long failure that ends when the router is restarted is a different investigation, closer to a hardware or line fault than to the settings above.
- Managed or corporate networks. On a network with enterprise authentication, network access control or a captive portal, client-side changes may be blocked by policy, and a changed hardware address may cause an authentication failure rather than an address problem. The private-address advice above is written for home networks.
- Mesh systems. If the affected devices are all served by one node, the question becomes why that node loses its backhaul, which is a different chain from a single access point vacating a channel.
- Regions outside the United States. The DFS timings, thresholds and band edges above are from the FCC rules. Other regulators impose their own values, and the numbers are not interchangeable.
- Older operating systems. The Apple paths above assume iOS 14 or later and macOS Sequoia 15 or later for the private-address setting, and the three-value Off/Fixed/Rotating menu requires iOS 18, iPadOS 18, macOS Sequoia 15, watchOS 11 or visionOS 2 onward. The Windows paths are as documented for Windows 11 and Windows 10.
Comments
Post a Comment