Wi‑Fi 6/6E Slow on Windows 11? Fix the Driver + Power Combo

Fast diagnosis playbook (find the bottleneck in 10 minutes)

This is the sequence I use when someone pings me with “Wi‑Fi 6 is slow” and I can’t afford a week of vibes-based troubleshooting.
You’re going to determine whether the bottleneck is (a) RF/band choice, (b) driver/firmware, (c) power management, (d) router feature interaction,
or (e) the internet connection itself.

First: prove it’s not the WAN

1. Run a speed test from a wired device on the same router (or plug your Windows 11 machine in temporarily).
   If wired is also slow, stop blaming Wi‑Fi. Your bottleneck is WAN, modem, ISP, or upstream routing.
2. If wired is fine, continue. You have a WLAN or client issue, not an internet issue.

Second: check link details and band in 30 seconds

1. Confirm whether you’re on 2.4 GHz, 5 GHz, or 6 GHz, and your receive/transmit rates.
2. If you’re on 2.4 GHz: that’s your answer for “why is it slow” in many homes and a shocking number of offices.

Third: check driver version and capability

1. Identify the Wi‑Fi chipset (Intel/Realtek/Qualcomm/MediaTek) and driver version.
2. If the driver is old, OEM-customized, or suspiciously new: test a known-good version (update or rollback).

Fourth: remove power savings and “smart” adapter settings

1. Disable “Allow the computer to turn off this device to save power.”
2. Confirm the active Windows power plan isn’t quietly throttling the radio.
3. Turn down roaming aggressiveness only if you’re stationary and suffering roam flaps.

Fifth: isolate router feature interactions

1. Test with WPA2 vs WPA3 (temporarily) if you suspect negotiation or CPU bottlenecks.
2. Try disabling 160 MHz channels (yes, disabling a feature can increase throughput).
3. On 6E, confirm 6 GHz is enabled and not running in a weird “legacy compatibility” mode.

Sixth: measure latency and loss, not just throughput

1. Ping the router/gateway and a stable internet target. If gateway latency spikes, you have a local RF/driver/power issue.
2. If gateway is clean but internet target spikes, look upstream (WAN, bufferbloat, ISP, VPN, corporate proxy).

The aim: don’t “fix Wi‑Fi.” Fix the specific bottleneck you can prove with one or two observations.

What “good” looks like on Wi‑Fi 6/6E (and what’s a lie)

Windows reports a “Link speed” that is not your throughput. Link speed is the negotiated PHY rate under current modulation,
channel width, spatial streams, and signal conditions. Your real throughput is lower due to overhead (MAC framing, contention,
encryption, acknowledgements, retries), plus whatever your router and client are doing in the background.

Practical expectation, close range, clean spectrum:

• Wi‑Fi 6 on 5 GHz (80 MHz, 2×2): often 600–900 Mbps real throughput in good conditions.
• Wi‑Fi 6 on 5 GHz (160 MHz, 2×2): can exceed 1 Gbps, but is fragile and more interference-prone.
• Wi‑Fi 6E on 6 GHz (80 MHz, 2×2): tends to be cleaner than 5 GHz; throughput often more consistent.
• 2.4 GHz: don’t expect miracles. It’s for reach, not speed.

The lie: “My link speed says 2402 Mbps, therefore my downloads should be 2.4 Gbps.” No. Think “half to two-thirds on a very good day,”
and that’s before your NAS, VPN, or cloud service becomes the bottleneck.

One operational rule: if latency to your default gateway is spiky while throughput is low, don’t touch DNS, don’t touch Chrome, and don’t touch your ISP.
That’s local Wi‑Fi (RF, driver, power, roaming). Fix local first.

Interesting facts and a little history (because it helps)

• Wi‑Fi 6 is 802.11ax, and it focused as much on efficiency in busy networks as on raw speed.
• Wi‑Fi 6E is basically Wi‑Fi 6 extended into the 6 GHz band; the protocol isn’t “new,” the spectrum is.
• OFDMA (Orthogonal Frequency Division Multiple Access) is the big scheduling change that helps many clients share airtime more efficiently.
• 1024‑QAM can increase peak rates, but it’s picky: it needs good signal quality, so distance and walls matter more than marketing.
• 160 MHz channels are fast on paper but are often a stability tax in real environments due to DFS, interference, and limited clean spectrum.
• 6 GHz has more room for wide channels and fewer legacy devices; that’s why 6E can feel “magically stable” in dense apartments.
• Windows power management decisions date back to the laptop era where saving battery was often prioritized over performance by default.
• Driver quality matters more with 802.11ax because scheduling, roaming, and power states are more complex than older Wi‑Fi generations.
• WPA3 improves security, but certain router/client combinations have had performance quirks during early adoption phases.

The real failure modes: driver, power, band, router features

1) The driver is “correct” but wrong for your reality

Windows Update loves shipping drivers that are stable enough for a broad fleet, not necessarily fast for your specific laptop+router combination.
OEM vendors also ship customized drivers tuned for their antenna designs, thermal constraints, and power profiles.
Then you install a generic driver from the chipset vendor because a forum said so, and roaming becomes a circus.

The pattern I see: one driver version works great at the office but tanks at home (or vice versa). That’s not supernatural.
It’s usually a feature interaction: 160 MHz, WPA3, target wake time, beamforming behavior, or AP steering.

2) Power management quietly kneecaps throughput

“Allow the computer to turn off this device to save power” is the obvious checkbox. The less obvious part: Windows power plans can change how aggressively
the OS and driver enter low-power states. On modern Wi‑Fi chipsets, the transition between power states can add latency, reduce transmit opportunities,
and cause intermittent stalls that look like “slow internet.”

If your symptom is good speed for 10 seconds then a drop, or random periodic stutters, power state oscillation is a prime suspect.
Especially on battery. Especially after sleep/hibernate cycles.

3) You’re on the wrong band (or the AP is steering you badly)

Band steering is great until it isn’t. Some routers would rather keep you on 2.4 GHz because the signal looks “stronger” (RSSI),
even though the airtime is noisy and congested. The OS might also prefer a saved network profile that leads to a suboptimal band.

4) “More features” can mean less speed

OFDMA, MU‑MIMO, beamforming, 160 MHz, WPA3, fast roaming (802.11r), BSS coloring… these are not automatically wins.
They’re tools. Tools interact. Sometimes they fight.

Joke #1: Wi‑Fi is just Ethernet, except it’s haunted and you can’t see the cables.

5) The router isn’t as strong as the sticker implies

Router marketing focuses on aggregate “AX” numbers that assume multiple clients and wide channels. Your real throughput can be limited by:
CPU (encryption/NAT), poor radio design, buggy firmware, thermal throttling, or bad defaults (like forcing 160 MHz in a crowded neighborhood).

Practical tasks (commands, outputs, decisions)

These are real tasks you can run on Windows 11 and on a router or a Linux box on your LAN.
Each task includes: command, sample output, what it means, and what decision you make next.
The goal is to stop guessing.

Task 1: Confirm interface status and current rates

cr0x@server:~$ netsh wlan show interfaces
There is 1 interface on the system:

    Name                   : Wi-Fi
    Description            : Intel(R) Wi-Fi 6E AX210 160MHz
    GUID                   : 8a1d3c1b-2d0d-4d5a-9c6a-9d4c8c8e9c2f
    Physical address       : 3c:52:82:aa:bb:cc
    State                  : connected
    SSID                   : CorpNet
    BSSID                  : 84:16:f9:11:22:33
    Network type           : Infrastructure
    Radio type             : 802.11ax
    Authentication         : WPA2-Personal
    Cipher                 : CCMP
    Connection mode        : Auto Connect
    Channel                : 37
    Receive rate (Mbps)    : 1201.0
    Transmit rate (Mbps)   : 1201.0
    Signal                 : 88%
    Profile                : CorpNet

Meaning: You’re connected, on 802.11ax, and Channel 37 strongly suggests 6 GHz (6E) in many regulatory domains.
Rates around 1201 Mbps often indicate 80 MHz channel width with 2 spatial streams.

Decision: If your receive/transmit rates are low (e.g., 144–433 Mbps) while you expect more, focus on band/channel width/signal first.
If rates are high but throughput is low, focus on driver/power/router CPU and feature interactions.

Task 2: Check driver file, version, and supported radio types

cr0x@server:~$ netsh wlan show drivers
Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6E AX210 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 2024-05-10
    Version                   : 23.50.0.6
    INF file                  : oem42.inf
    Type                      : Native Wi-Fi Driver
    Radio types supported     : 802.11a 802.11b 802.11g 802.11n 802.11ac 802.11ax
    FIPS 140-2 mode supported : Yes
    802.11w Management Frame Protection supported : Yes

Meaning: You have a modern Intel driver, and 802.11ax is supported. The oem42.inf indicates an installed package
(could be OEM or Windows Update).

Decision: If the version is old or if it changed recently and your issues started “after updates,” plan a controlled rollback test.
If 802.11ax is missing from supported radio types, you’re not running the driver you think you are.

Task 3: Verify IP config and confirm the default gateway

cr0x@server:~$ ipconfig /all
Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . . : Intel(R) Wi-Fi 6E AX210 160MHz
   Physical Address. . . . . . . . . : 3C-52-82-AA-BB-CC
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.20.5.114(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, February 6, 2026 9:12:41 AM
   Default Gateway . . . . . . . . . : 10.20.5.1
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Meaning: You have a sane DHCP lease and a gateway. This is setup validation, not performance validation.

Decision: Use the gateway IP for latency tests. If you have multiple gateways or a VPN adapter doing weird things, isolate that next.

Task 4: Ping the gateway to separate Wi‑Fi from WAN

cr0x@server:~$ ping -n 30 10.20.5.1
Pinging 10.20.5.1 with 32 bytes of data:
Reply from 10.20.5.1: bytes=32 time=2ms TTL=64
Reply from 10.20.5.1: bytes=32 time=3ms TTL=64
Reply from 10.20.5.1: bytes=32 time=64ms TTL=64
Reply from 10.20.5.1: bytes=32 time=4ms TTL=64

Ping statistics for 10.20.5.1:
    Packets: Sent = 30, Received = 30, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 64ms, Average = 6ms

Meaning: That 64 ms spike to the gateway is suspicious in a local LAN context. It often means retries, interference, power state transitions,
or the AP is momentarily busy. If you see frequent spikes or loss here, it’s not your ISP.

Decision: If gateway pings are spiky, prioritize driver/power/band/channel changes before touching DNS or modem settings.

Task 5: Ping a stable internet target to detect upstream issues

cr0x@server:~$ ping -n 30 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=18ms TTL=57
Reply from 1.1.1.1: bytes=32 time=19ms TTL=57
Reply from 1.1.1.1: bytes=32 time=85ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 30, Received = 30, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 85ms, Average = 23ms

Meaning: Some jitter to the internet is normal. Compare this with gateway ping. If gateway is clean but internet jitter is bad,
look at WAN congestion, bufferbloat, VPN, or ISP routing.

Decision: If both gateway and internet are bad, fix local Wi‑Fi first. If only internet is bad, stop chasing Wi‑Fi ghosts.

Task 6: Capture a Wi‑Fi report (Windows built-in)

cr0x@server:~$ netsh wlan show wlanreport
WLAN report saved to C:\ProgramData\Microsoft\Windows\WlanReport\wlan-report-latest.html

Meaning: Windows generates a timeline of connectivity events, driver resets, roaming, and errors. It’s not perfect, but it’s evidence.

Decision: If you see frequent disconnect/reconnect cycles, authentication failures, or driver resets, stop optimizing channels and fix the driver/power combo.

Task 7: List saved Wi‑Fi profiles and remove stale ones

cr0x@server:~$ netsh wlan show profiles
Profiles on interface Wi-Fi:

Group policy profiles (read only)
---------------------------------
    <None>

User profiles
-------------
    All User Profile     : CorpNet
    All User Profile     : CorpNet-Guest
    All User Profile     : HomeNet

Meaning: Multiple profiles with similar names can cause Windows to roam or auto-connect in ways you didn’t intend.

Decision: If you have duplicates or old profiles from previous router configs, delete the junk and reconnect cleanly.

cr0x@server:~$ netsh wlan delete profile name="CorpNet-Guest"
Profile "CorpNet-Guest" is deleted from interface "Wi-Fi".

Decision: After cleanup, test again. If performance improves, you had a policy/auto-connect mess, not RF physics.

Task 8: Force a reconnect to test band steering outcomes

cr0x@server:~$ netsh wlan disconnect
Disconnection request was completed successfully.

cr0x@server:~$ netsh wlan connect name="CorpNet"
Connection request was completed successfully.

Meaning: You’re forcing a re-association. This is useful after router changes or when the client is stuck on a bad band.

Decision: Immediately re-run netsh wlan show interfaces and verify channel/band and rates changed the way you wanted.

Task 9: Inspect power plan and active scheme

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Meaning: Balanced is fine until it’s not. Vendors sometimes add hidden tweaks or ship “quiet” modes in their control apps
that alter device power behavior under the hood.

Decision: If your Wi‑Fi issues appear mainly on battery, you’ll likely need to tune adapter power saving and/or choose a more performance-oriented plan for testing.

Task 10: Check if the Wi‑Fi adapter is allowed to be powered down

cr0x@server:~$ powercfg /devicequery wake_armed
HID Keyboard Device
HID-compliant mouse

Meaning: This doesn’t directly list “can be turned off,” but it helps you understand what devices are permitted to wake the system.
Power policy debugging is messy; we triangulate from multiple indicators.

Decision: Use Device Manager for the Wi‑Fi adapter power checkbox, then retest gateway ping stability and throughput.

Task 11: Check advanced TCP settings that affect perceived performance

cr0x@server:~$ netsh int tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : default
ECN Capability                      : disabled
Timestamps                          : disabled

Meaning: Auto-tuning should generally be normal. If it’s disabled, high-bandwidth networks can feel inexplicably slow.

Decision: If auto-tuning is disabled, set it back to normal and retest throughput. If you’re in a corporate environment, policy may revert it.

cr0x@server:~$ netsh int tcp set global autotuninglevel=normal
Ok.

Task 12: Identify which process is actually using the network

cr0x@server:~$ netstat -b -o -n | findstr ":443"
  TCP    10.20.5.114:51542     52.96.34.18:443        ESTABLISHED     10240
 [msedge.exe]
  TCP    10.20.5.114:51556     13.107.42.14:443       ESTABLISHED     14892
 [Teams.exe]

Meaning: If the complaint is “Wi‑Fi is slow” but one process is saturating upstream (cloud sync, backup, game downloads),
you’re debugging the wrong layer.

Decision: If a single app is dominating traffic, pause it and re-test. If everything improves, you had contention, not a radio problem.

Task 13: On the router or a Linux host, verify LAN throughput independent of Wi‑Fi

If you have a Linux box wired to the router (or a small server), use it as a control to separate “Wi‑Fi problem” from “LAN/WAN problem.”

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

Then from the Windows machine (if you have iperf3 installed) or another client. Here’s a sample client run from Linux for illustration:

cr0x@server:~$ iperf3 -c 10.20.5.50 -P 4
Connecting to host 10.20.5.50, port 5201
[SUM]   0.00-10.00  sec  1.02 GBytes   876 Mbits/sec  sender
[SUM]   0.00-10.00  sec  1018 MBytes   854 Mbits/sec  receiver

Meaning: This is solid for a 2×2 Wi‑Fi 6 client on 80 MHz, assuming good RF. If your internet tests are slow but LAN iperf is fast,
your Wi‑Fi is fine and your WAN path is not.

Decision: Fast LAN + slow internet = look at ISP/VPN/DNS/CDN path, not your adapter settings.
Slow LAN iperf = local Wi‑Fi or router CPU issue.

Task 14: Inspect Wi‑Fi event logs for driver resets and roaming churn

cr0x@server:~$ wevtutil qe Microsoft-Windows-WLAN-AutoConfig/Operational /c:8 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 8001
  Level: Information
  Description:
    WLAN AutoConfig service has successfully connected to a wireless network.
Event[1]:
  Provider Name: Microsoft-Windows-WLAN-AutoConfig
  Event ID: 11004
  Level: Warning
  Description:
    WLAN AutoConfig detected limited connectivity, attempting recovery.

Meaning: Warnings around limited connectivity, repeated connects, or authentication timeouts point to driver/power/AP negotiation issues.

Decision: If you see repeated churn, stop chasing channel “optimization” and start by stabilizing the driver and disabling adapter power cutoffs.

Joke #2: The fastest way to improve Wi‑Fi is to stop printing PDFs over it at 4K resolution.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A mid-sized company rolled out new Windows 11 laptops with Wi‑Fi 6E adapters. The helpdesk script said: “If it’s slow, the ISP is congested.”
That script worked last year. This year, it became a liability.

Complaints piled up: video calls freezing, cloud IDE disconnects, “VPN is broken.” The WAN graphs looked fine. The firewall wasn’t melting.
The Wi‑Fi controller showed decent client RSSI. Everyone still blamed the internet because speed tests were inconsistent and emotionally persuasive.

The wrong assumption was simple: high link speed means the Wi‑Fi is fine. On these laptops, link speed stayed high even while the client
experienced microbursts of latency and occasional retransmit storms. Windows would happily display 1201 or 2402 Mbps while the gateway ping hit 200+ ms.

The fix was also simple, once the team stopped treating Wi‑Fi as magic: pin a stable driver version for the chipset, disable the adapter’s ability to be powered down,
and turn off 160 MHz on the problematic SSID. The network didn’t get “faster.” It got consistent, which is what work actually needs.

The operational lesson: never let a single UI number (“Link speed”) act as your SLO. Measure gateway latency and retransmits; they tell the truth.

Mini-story 2: The optimization that backfired

Another org decided to “modernize” their wireless by enabling every shiny feature across the fleet: WPA3-only, 160 MHz everywhere, aggressive band steering,
and fast roaming. It looked fantastic in a conference room demo with one laptop six feet from the AP.

Then reality arrived. In open office areas, 160 MHz collided with RF noise and DFS events. Clients would shift channels, renegotiate, and sometimes land on crowded spectrum.
A subset of Windows 11 clients with a particular driver revision started showing intermittent throughput collapses—fine for minutes, awful for 30 seconds, repeat.
It was perfect: hard to reproduce on demand and easy to misdiagnose.

The “optimization” was intended to increase peak throughput. Instead, it increased variability. And variability is what breaks voice, VDI, and anything interactive.
People don’t complain when they get 700 Mbps instead of 900 Mbps. They complain when their call drops.

The rollback plan was incremental: return to 80 MHz on most SSIDs, keep WPA3 as “transition” rather than hard requirement for a while, and treat band steering
as something you tune per environment. Peak speed went down. Tickets went down more.

The lesson: the best Wi‑Fi is boring Wi‑Fi. Optimize for stability and airtime fairness, not a screenshot you can put in a slide deck.

Mini-story 3: The boring but correct practice that saved the day

A regulated enterprise had a habit that other teams mocked: they maintained a small matrix of “known-good” Wi‑Fi driver versions per chipset and laptop model.
They also tested Windows feature updates with those drivers in a pilot ring before broad rollout.

When a Windows 11 update landed and Wi‑Fi performance degraded for a specific adapter family, they didn’t panic.
They already had baselines: gateway ping distributions, iperf throughput ranges, and roaming behavior under load.
It wasn’t subjective. It was measurable regression.

They held the driver constant, reproduced the issue, then tested two alternate driver versions: one newer, one older.
The older version restored stability. The newer improved throughput but reintroduced roaming churn on certain AP models.
So they picked the boring option: stability first, then a longer vendor engagement for the complex case.

While other orgs spent weeks in “try turning it off and on again,” this one shipped a controlled rollback through endpoint management
and moved on with their lives. Nobody got promoted for it. That’s how you know it was correct.

A paraphrased idea often attributed to engineering reliability thinking (not verbatim): availability comes from controlling change and understanding failure modes, not from heroics.

Common mistakes: symptom → root cause → fix

1) Symptom: “Link speed is huge but downloads are slow”

• Root cause: Throughput limited by retries, interference, or router CPU/NAT/encryption; link speed is just PHY.
• Fix: Ping gateway for jitter/loss; test LAN iperf; try 80 MHz instead of 160; update/rollback driver; confirm you’re on 5/6 GHz.

2) Symptom: “Fast for 30 seconds, then drops, then recovers”

• Root cause: Power management state transitions, Target Wake Time quirks, or driver bugs after sleep.
• Fix: Disable adapter power-off checkbox; test on AC power; set Wireless Adapter Settings to Maximum Performance; consider driver rollback.

3) Symptom: “Only slow on battery”

• Root cause: Aggressive power plan policies for the WLAN adapter.
• Fix: Set Wi‑Fi adapter power saving to Maximum Performance on battery; keep Balanced but tune this one knob if you care about stable conferencing.

4) Symptom: “Slow only in one location (same laptop)”

• Root cause: RF congestion, DFS channel events, or band steering puts you on 2.4 GHz.
• Fix: Verify channel and band; move to 5/6 GHz SSID; avoid forcing 160 MHz in congested environments.

5) Symptom: “Wi‑Fi 6E is slower than Wi‑Fi 6”

• Root cause: 6 GHz signal attenuation through walls, lower effective SNR, or AP placement not designed for 6 GHz.
• Fix: Use 6 GHz close to the AP; otherwise prefer strong 5 GHz; consider adding APs rather than expecting 6 GHz to punch through walls.

6) Symptom: “VPN feels broken on Wi‑Fi but fine on Ethernet”

• Root cause: Wi‑Fi jitter/loss triggers VPN retransmits; MTU/fragmentation can amplify pain.
• Fix: First stabilize gateway ping; then check MTU and VPN client settings if needed. Don’t start with the VPN.

7) Symptom: “After a Windows update, Wi‑Fi throughput tanked”

• Root cause: Driver replaced by Windows Update or new power policy defaults.
• Fix: Identify driver version changes; test rollback; then pin known-good driver through endpoint management.

8) Symptom: “Speed is fine, but latency spikes during uploads”

• Root cause: Bufferbloat on the router/WAN link; upstream saturation; QoS not configured.
• Fix: Cap uploads, enable SQM/Smart Queue Management if available, or configure QoS properly. Wi‑Fi can be innocent here.

Checklists / step-by-step plan

Plan A: Fix the driver + power combo (the usual win)

1. Record baseline: run netsh wlan show interfaces and save channel, radio type, rates, signal.
   Run a 30‑ping gateway test and note max/avg latency.
2. Check driver version: run netsh wlan show drivers. If the version changed recently, plan a rollback test.
3. Update or rollback intentionally:
   • Prefer OEM-supported drivers first for laptops (they often tune power/antennas).
   • If OEM is stale and broken, test chipset-vendor drivers, but treat it like a change with rollback.
4. Disable adapter power cutoffs: in Device Manager → Network adapters → your Wi‑Fi adapter → Power Management:
   uncheck “Allow the computer to turn off this device to save power.”
5. Set wireless adapter power policy: Power Options → Advanced settings → Wireless Adapter Settings:
   set both “On battery” and “Plugged in” to Maximum Performance (at least for testing; keep it if it fixes your life).
6. Retest: gateway ping again; then a LAN iperf test if you can; then internet test.
7. Decide: if latency stability improved materially, keep the settings and stop tinkering.

Plan B: Band and channel sanity (when the PHY is the issue)

1. Confirm you’re on 5 GHz or 6 GHz. If you’re on 2.4 GHz, fix steering or split SSIDs temporarily to prove the point.
2. Avoid 160 MHz until you have evidence it helps. Use 80 MHz for stability in noisy environments.
3. On 6E, place the AP where 6 GHz can actually reach your desk. If it can’t, use 5 GHz and move on.
4. Retest: if rates and gateway ping improve, you had an RF/channel planning problem, not a Windows problem.

Plan C: Router feature interactions (when “new” equals “weird”)

1. Temporarily switch WPA3-only to WPA2/WPA3 transition mode (or WPA2) to test negotiation/perf quirks.
2. Disable advanced roaming features (802.11r) if you see repeated auth/roam churn on Windows clients.
3. Update router firmware. If the firmware is already current, consider that “current” can be “currently buggy.” Test one version back if possible.
4. Keep changes isolated: one change, one test, one decision. Don’t create a mystery stew.

FAQ

1) Why is my Wi‑Fi 6/6E link speed high but real speed low?

Link speed is the negotiated PHY rate. Real throughput is lower due to overhead, contention, retries, and sometimes router CPU limits.
Use gateway ping and LAN iperf to find where the loss/jitter is introduced.

2) Should I always enable 160 MHz channels?

No. Use 160 MHz when you have clean spectrum and short distances. Otherwise it often increases variability (DFS events, interference)
and can reduce actual throughput or stability.

3) Is 6 GHz always faster than 5 GHz?

Not always. 6 GHz is usually cleaner, but it attenuates more through walls. If your 6 GHz signal isn’t strong, 5 GHz can outperform it in practice.

4) Do I want the newest Wi‑Fi driver?

You want the best driver for your adapter + laptop + router combination. “Newest” is sometimes right, sometimes a regression.
If performance broke after an update, a controlled rollback test is sane engineering.

5) What Windows 11 setting most often causes Wi‑Fi stutters?

Power management. Specifically: allowing Windows to power down the adapter and aggressive wireless power saving on battery.
Disable the power-off checkbox and set wireless adapter power to Maximum Performance as a test.

6) My Wi‑Fi is slow only after sleep. Why?

Some drivers don’t resume cleanly, or power state transitions get stuck in suboptimal modes.
A driver update/rollback plus disabling adapter power cutoffs usually fixes it.

7) Will disabling IPv6 speed up Wi‑Fi?

Usually no, and it often creates new problems. If you suspect DNS or path issues, test with gateway ping and LAN iperf first.
Don’t break IPv6 because the internet told you to.

8) How do I know if the router is the bottleneck?

If LAN iperf between your Wi‑Fi client and a wired server is slow, the bottleneck is local (Wi‑Fi or router).
If LAN iperf is fast but internet is slow, the router’s WAN path, ISP, VPN, or upstream congestion is more likely.

9) Why does performance change depending on the office vs home router?

Different channel plans, different feature sets (WPA3/802.11r/OFDMA tuning), and different interference profiles.
Drivers can behave differently depending on AP implementation and band steering behavior.

10) Should I split SSIDs (separate 2.4/5/6 GHz names)?

For troubleshooting, yes—it’s one of the fastest ways to prove band steering is the problem.
Long-term, a single SSID can be fine if your router does steering well. Many do not.

Conclusion: next steps that actually move the needle

If you remember one thing: stop worshipping the link speed number. Measure gateway latency, confirm your band, and treat driver changes like real changes
with rollback. Windows 11 isn’t uniquely bad at Wi‑Fi 6/6E; it’s just very good at hiding the two knobs that matter most: driver behavior and power policy.

Practical next steps:

1. Run netsh wlan show interfaces and confirm band/channel and rates.
2. Ping your default gateway for 30–60 seconds. Spikes or loss mean local Wi‑Fi trouble.
3. Check driver version with netsh wlan show drivers. If issues started after an update, test rollback.
4. Disable adapter power-off and set wireless adapter power saving to Maximum Performance (at least to test).
5. If you’re forcing 160 MHz, try 80 MHz for a day and see if stability improves.

Wi‑Fi is a shared medium with a lot of moving parts. The trick is to be methodical, not mystical.