¿Wi‑Fi 6/6E lento en Windows 11? Corrige controlador y gestión de energía

Guía de diagnóstico rápido (encuentra el cuello de botella en 10 minutos)

Esta es la secuencia que uso cuando alguien me escribe “Wi‑Fi 6 va lento” y no puedo permitirme una semana de solución basada en intuiciones.
Vas a determinar si el cuello de botella es (a) RF/elección de banda, (b) controlador/firmware, (c) gestión de energía, (d) interacción de funciones del router,
o (e) la propia conexión a Internet.

Primero: demuestra que no es el WAN

1. Ejecuta una prueba de velocidad desde un dispositivo cableado en el mismo router (o conecta temporalmente tu equipo Windows 11 por cable).
   Si por cable también va lento, deja de culpar al Wi‑Fi. Tu cuello de botella es WAN, módem, ISP o el enrutamiento upstream.
2. Si el cableado va bien, continúa. Tienes un problema de WLAN o cliente, no de internet.

Segundo: comprueba detalles de enlace y banda en 30 segundos

1. Confirma si estás en 2.4 GHz, 5 GHz o 6 GHz, y tus tasas de recepción/transmisión.
2. Si estás en 2.4 GHz: esa suele ser la respuesta a “por qué va lento” en muchas casas y en un número sorprendente de oficinas.

Tercero: revisa la versión y capacidad del controlador

1. Identifica el chipset Wi‑Fi (Intel/Realtek/Qualcomm/MediaTek) y la versión del controlador.
2. Si el controlador es viejo, personalizado por el OEM o sospechosamente nuevo: prueba una versión conocida como buena (actualiza o haz rollback).

Cuarto: elimina ahorros de energía y configuraciones “inteligentes” del adaptador

1. Desactiva “Permitir que el equipo apague este dispositivo para ahorrar energía”.
2. Confirma que el plan de energía activo de Windows no esté limitando silenciosamente la radio.
3. Reduce la agresividad de roaming solo si estás estacionario y sufres oscilaciones por cambios de AP.

Quinto: aisla interacciones con funciones del router

1. Prueba con WPA2 frente a WPA3 (temporalmente) si sospechas problemas de negociación o cuello de botella por CPU.
2. Intenta desactivar canales de 160 MHz (sí, desactivar una función puede aumentar el rendimiento).
3. En 6E, confirma que 6 GHz esté habilitado y no funcione en un extraño modo de “compatibilidad legacy”.

Sexto: mide latencia y pérdida, no solo rendimiento

1. Haz ping al router/puerta de enlace y a un objetivo estable en internet. Si la latencia hacia la puerta de enlace es inestable, tienes un problema local RF/controlador/energía.
2. Si la puerta de enlace está limpia pero el objetivo de internet tiene picos, mira hacia arriba (WAN, bufferbloat, ISP, VPN, proxy corporativo).

El objetivo: no “arreglar el Wi‑Fi”. Arregla el cuello de botella específico que puedas demostrar con una o dos observaciones.

Cómo se ve “bien” en Wi‑Fi 6/6E (y qué es mentira)

Windows informa una “Velocidad de enlace” que no es tu rendimiento. La velocidad de enlace es la tasa PHY negociada según la modulación,
el ancho de canal, los flujos espaciales y las condiciones de señal. Tu rendimiento real es menor por la sobrecarga (tramas MAC, contención,
cifrado, reconocimientos, reintentos), además de lo que el router y el cliente hagan en segundo plano.

Expectativa práctica, a corta distancia, espectro limpio:

• Wi‑Fi 6 en 5 GHz (80 MHz, 2×2): frecuentemente 600–900 Mbps de rendimiento real en buenas condiciones.
• Wi‑Fi 6 en 5 GHz (160 MHz, 2×2): puede superar 1 Gbps, pero es frágil y más propenso a interferencias.
• Wi‑Fi 6E en 6 GHz (80 MHz, 2×2): tiende a ser más limpio que 5 GHz; el rendimiento suele ser más consistente.
• 2.4 GHz: no esperes milagros. Es para alcance, no para velocidad.

La mentira: “Mi velocidad de enlace dice 2402 Mbps, por lo tanto mis descargas deberían ser 2.4 Gbps.” No. Piensa “la mitad a dos tercios en un muy buen día”,
y eso antes de que tu NAS, VPN o servicio en la nube se convierta en el cuello de botella.

Una regla operativa: si la latencia hacia tu puerta de enlace predeterminada es inestable mientras el rendimiento es bajo, no toques DNS, no toques Chrome y no culpes al ISP.
Eso es Wi‑Fi local (RF, controlador, energía, roaming). Arregla lo local primero.

Datos interesantes y un poco de historia (porque ayuda)

• Wi‑Fi 6 es 802.11ax, y se centró tanto en la eficiencia en redes concurridas como en la velocidad bruta.
• Wi‑Fi 6E es básicamente Wi‑Fi 6 extendido al banda de 6 GHz; el protocolo no es “nuevo”, es el espectro.
• OFDMA (Acceso Múltiple por División de Frecuencia Ortogonal) es el gran cambio de programación que ayuda a muchos clientes a compartir el aire de manera más eficiente.
• 1024‑QAM puede aumentar las tasas máximas, pero es exigente: necesita buena calidad de señal, por lo que la distancia y las paredes importan más que el marketing.
• Canales de 160 MHz son rápidos en papel pero a menudo suponen un impuesto de estabilidad en entornos reales debido a DFS, interferencias y espectro limpio limitado.
• 6 GHz tiene más espacio para canales amplios y menos dispositivos heredados; por eso 6E puede sentirse “mágicamente estable” en apartamentos densos.
• La gestión de energía de Windows tiene decisiones que vienen de la era de los portátiles, donde ahorrar batería a menudo se priorizaba sobre el rendimiento por defecto.
• La calidad del controlador importa más con 802.11ax porque la programación, el roaming y los estados de energía son más complejos que en generaciones anteriores de Wi‑Fi.
• WPA3 mejora la seguridad, pero ciertas combinaciones router/cliente han tenido peculiaridades de rendimiento durante las fases iniciales de adopción.

Los modos reales de fallo: controlador, energía, banda, funciones del router

1) El controlador es “correcto” pero inapropiado para tu realidad

Windows Update le encanta distribuir controladores que son lo bastante estables para una flota amplia, no necesariamente rápidos para tu combinación específica de portátil+router.
Los fabricantes OEM también envían controladores personalizados ajustados a sus diseños de antena, restricciones térmicas y perfiles de energía.
Luego instalas un controlador genérico del proveedor del chipset porque un foro lo recomendó, y el roaming se convierte en un circo.

El patrón que veo: una versión de controlador funciona genial en la oficina pero falla en casa (o viceversa). Eso no es sobrenatural.
Normalmente es una interacción de funciones: 160 MHz, WPA3, target wake time, comportamiento de beamforming o AP steering.

2) La gestión de energía socava silenciosamente el rendimiento

“Permitir que el equipo apague este dispositivo para ahorrar energía” es la casilla obvia. La parte menos obvia: los planes de energía de Windows pueden cambiar cuán agresivamente
el SO y el controlador entran en estados de baja potencia. En los chipsets Wi‑Fi modernos, la transición entre estados de energía puede añadir latencia, reducir oportunidades de transmisión
y causar bloqueos intermitentes que parecen “internet lento”.

Si tu síntoma es buena velocidad durante 10 segundos y luego caída, o tartamudeos periódicos aleatorios, la oscilación de estados de energía es una sospecha principal.
Especialmente con batería. Especialmente después de ciclos de suspensión/hibernación.

3) Estás en la banda equivocada (o el AP te está dirigiendo mal)

El band steering es genial hasta que no lo es. Algunos routers preferirán mantenerte en 2.4 GHz porque la señal parece “más fuerte” (RSSI),
aunque el airtime esté ruidoso y congestionado. El SO también puede preferir un perfil de red guardado que lleve a una banda subóptima.

4) “Más funciones” puede significar menos velocidad

OFDMA, MU‑MIMO, beamforming, 160 MHz, WPA3, roaming rápido (802.11r), BSS coloring… no son victorias automáticas.
Son herramientas. Las herramientas interactúan. A veces se pelean.

Broma #1: Wi‑Fi es solo Ethernet, excepto que está embrujado y no puedes ver los cables.

5) El router no es tan potente como indica la pegatina

El marketing del router se centra en números agregados “AX” que asumen múltiples clientes y canales amplios. Tu rendimiento real puede estar limitado por:
CPU (cifrado/NAT), diseño de radio pobre, firmware con bugs, limitación térmica o malos valores por defecto (como forzar 160 MHz en un vecindario congestionado).

Tareas prácticas (comandos, salidas, decisiones)

Estas son tareas reales que puedes ejecutar en Windows 11 y en un router o una máquina Linux en tu LAN.
Cada tarea incluye: comando, salida de muestra, qué significa y qué decisión tomar después.
La meta es dejar de adivinar.

Task 1: Confirmar estado de la interfaz y tasas actuales

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

Significado: Estás conectado, en 802.11ax, y el Canal 37 sugiere fuertemente 6 GHz (6E) en muchos dominios regulatorios.
Tasas alrededor de 1201 Mbps suelen indicar ancho de canal de 80 MHz con 2 flujos espaciales.

Decisión: Si tus tasas de recepción/transmisión son bajas (ej., 144–433 Mbps) mientras esperas más, enfócate primero en banda/ancho de canal/señal.
Si las tasas son altas pero el rendimiento es bajo, enfócate en controlador/energía/CPU del router e interacciones de funciones.

Task 2: Comprobar archivo del controlador, versión y radios soportados

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

Significado: Tienes un controlador Intel moderno, y 802.11ax está soportado. El oem42.inf indica un paquete instalado
(podría ser OEM o Windows Update).

Decisión: Si la versión es vieja o cambió recientemente y tus problemas empezaron “después de actualizaciones”, planifica una prueba controlada de rollback.
Si falta 802.11ax en tipos de radio soportados, no estás ejecutando el controlador que crees.

Task 3: Verificar configuración IP y confirmar la puerta de enlace predeterminada

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

Significado: Tienes un lease DHCP razonable y una puerta de enlace. Esto es validación de configuración, no de rendimiento.

Decisión: Usa la IP de la puerta de enlace para pruebas de latencia. Si tienes múltiples puertas de enlace o un adaptador VPN que hace cosas raras, aíslalo a continuación.

Task 4: Hacer ping a la puerta de enlace para separar Wi‑Fi de 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

Significado: Ese pico de 64 ms a la puerta de enlace es sospechoso en un contexto LAN local. A menudo significa reintentos, interferencia, transiciones de estado de energía,
o que el AP está momentáneamente ocupado. Si ves picos o pérdida frecuente aquí, no es tu ISP.

Decisión: Si los pings a la puerta de enlace son inestables, prioriza cambios en controlador/energía/banda/canal antes de tocar DNS o ajustes del módem.

Task 5: Hacer ping a un objetivo estable en internet para detectar problemas upstream

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

Significado: Algo de jitter hacia internet es normal. Compara esto con el ping a la puerta de enlace. Si la puerta de enlace está limpia pero el jitter a internet es malo,
observa congestión WAN, bufferbloat, VPN o enrutamiento del ISP.

Decisión: Si tanto la puerta de enlace como internet presentan problemas, arregla primero el Wi‑Fi local. Si solo internet está mal, deja de perseguir fantasmas del Wi‑Fi.

Task 6: Capturar un informe Wi‑Fi (integrado en Windows)

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

Significado: Windows genera una línea de tiempo de eventos de conectividad, reinicios de controlador, roaming y errores. No es perfecto, pero es evidencia.

Decisión: Si ves ciclos frecuentes de desconexión/conexión, fallos de autenticación o reinicios de controlador, deja de optimizar canales y arregla primero el combo controlador/energía.

Task 7: Listar perfiles Wi‑Fi guardados y eliminar los obsoletos

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

Significado: Múltiples perfiles con nombres similares pueden hacer que Windows haga roaming o se conecte automáticamente de maneras que no deseabas.

Decisión: Si tienes duplicados o perfiles viejos de configuraciones de router anteriores, borra la basura y reconecta limpiamente.

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

Decisión: Tras la limpieza, prueba de nuevo. Si el rendimiento mejora, tenías un lío de políticas/conexiones automáticas, no física RF.

Task 8: Forzar una reconexión para probar resultados del band steering

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

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

Significado: Estás forzando una re-asociación. Esto es útil después de cambios en el router o cuando el cliente está atrapado en una banda mala.

Decisión: Ejecuta inmediatamente netsh wlan show interfaces de nuevo y verifica que el canal/banda y las tasas cambiaron como querías.

Task 9: Inspeccionar plan de energía y esquema activo

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

Significado: Balanced está bien hasta que no lo está. Los vendedores a veces añaden ajustes ocultos o envían modos “silenciosos” en sus apps de control
que alteran el comportamiento de energía de los dispositivos por debajo.

Decisión: Si tus problemas Wi‑Fi aparecen principalmente con batería, probablemente necesitarás ajustar el ahorro de energía del adaptador y/o elegir un plan más orientado al rendimiento para pruebas.

Task 10: Comprobar si el adaptador Wi‑Fi puede ser apagado

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

Significado: Esto no lista directamente “puede ser apagado”, pero te ayuda a entender qué dispositivos pueden despertar el sistema.
La depuración de políticas de energía es compleja; triangulamos desde múltiples indicadores.

Decisión: Usa el Administrador de dispositivos para la casilla de energía del adaptador Wi‑Fi, y luego vuelve a probar la estabilidad del ping a la puerta de enlace y el rendimiento.

Task 11: Comprobar ajustes avanzados TCP que afectan el rendimiento percibido

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

Significado: Auto-tuning debería ser generalmente normal. Si está deshabilitado, las redes de alto ancho de banda pueden sentirse inexplicablemente lentas.

Decisión: Si el auto-tuning está deshabilitado, restablécelo a normal y vuelve a probar el rendimiento. Si estás en un entorno corporativo, la política puede revertirlo.

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

Task 12: Identificar qué proceso está usando realmente la red

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]

Significado: Si la queja es “Wi‑Fi va lento” pero un proceso está saturando el upstream (sincronización en la nube, backups, descargas de juegos),
estás depurando la capa equivocada.

Decisión: Si una sola app domina el tráfico, ponla en pausa y vuelve a probar. Si todo mejora, tenías contención, no un problema de radio.

Task 13: En el router o un host Linux, verifica el rendimiento LAN independiente del Wi‑Fi

Si tienes una máquina Linux conectada por cable al router (o un pequeño servidor), úsala como control para separar “problema Wi‑Fi” de “problema LAN/WAN”.

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

Luego desde la máquina Windows (si tienes iperf3 instalado) u otro cliente. Aquí hay una ejecución de cliente de ejemplo desde Linux para ilustrar:

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

Significado: Esto es sólido para un cliente Wi‑Fi 6 2×2 en 80 MHz, suponiendo buen RF. Si tus pruebas de internet son lentas pero el iperf LAN es rápido,
tu Wi‑Fi está bien y tu ruta WAN no.

Decisión: LAN rápido + internet lento = mira ISP/VPN/DNS/CDN, no los ajustes del adaptador.
iperf LAN lento = Wi‑Fi local o CPU del router.

Task 14: Inspeccionar logs de evento Wi‑Fi por reinicios de controlador y churn de roaming

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.

Significado: Advertencias sobre conectividad limitada, reconexiones repetidas o timeouts de autenticación apuntan a problemas de controlador/energía/negociación con el AP.

Decisión: Si ves churn repetido, deja de perseguir la “optimización” de canales y empieza por estabilizar el controlador y desactivar los cortes de energía del adaptador.

Broma #2: La manera más rápida de mejorar el Wi‑Fi es dejar de imprimir PDFs por la red a resolución 4K.

Tres microhistorias corporativas desde la trinchera

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó nuevos portátiles con Windows 11 y adaptadores Wi‑Fi 6E. El guion del helpdesk decía: “Si va lento, el ISP está congestionado.”
Ese guion funcionó el año pasado. Este año, se volvió una responsabilidad.

Se acumularon las quejas: llamadas de video congeladas, IDEs en la nube desconectándose, “VPN rota”. Los gráficos WAN se veían bien. El firewall no se estaba sobrecargando.
El controlador Wi‑Fi mostraba RSSI decente. Aún así, todos culpaban a internet porque las pruebas de velocidad eran inconsistentes y emocionalmente persuasivas.

La suposición equivocada fue simple: alta velocidad de enlace significa que el Wi‑Fi está bien. En esos portátiles, la velocidad de enlace se mantenía alta incluso mientras el cliente
experimentaba micropicos de latencia y ocasionales tormentas de retransmisión. Windows mostraba feliz 1201 o 2402 Mbps mientras el ping a la puerta de enlace subía a 200+ ms.

La solución también fue simple, una vez que el equipo dejó de tratar al Wi‑Fi como magia: fijar una versión estable del controlador para el chipset, deshabilitar la capacidad del adaptador para apagarse,
y desactivar 160 MHz en el SSID problemático. La red no se volvió “más rápida.” Se volvió consistente, que es lo que el trabajo realmente necesita.

La lección operativa: nunca dejes que un único número de la UI (“Velocidad de enlace”) actúe como tu SLO. Mide la latencia a la puerta de enlace y las retransmisiones; ellas dicen la verdad.

Microhistoria 2: La optimización que salió mal

Otra organización decidió “modernizar” su inalámbrico habilitando todas las funciones brillantes en la flota: solo WPA3, 160 MHz en todas partes, band steering agresivo
y roaming rápido. Parecía fantástico en una demo en sala de conferencias con un portátil a dos metros del AP.

Luego llegó la realidad. En zonas de oficinas abiertas, 160 MHz chocaba con ruido RF y eventos DFS. Los clientes cambiaban de canal, renegociaban y a veces caían en espectro congestionado.
Un subconjunto de clientes Windows 11 con una revisión de controlador particular empezó a mostrar colapsos intermitentes de rendimiento—bien durante minutos, mal durante 30 segundos, repetir.
Fue perfecto: difícil de reproducir bajo demanda y fácil de maldiagnosticar.

La “optimización” pretendía aumentar el rendimiento pico. En cambio, aumentó la variabilidad. Y la variabilidad es lo que rompe voz, VDI y cualquier cosa interactiva.
La gente no se queja cuando obtiene 700 Mbps en lugar de 900 Mbps. Se quejan cuando su llamada se corta.

El plan de reversión fue incremental: volver a 80 MHz en la mayoría de SSID, mantener WPA3 como “transición” en lugar de requisito estricto por un tiempo, y tratar el band steering
como algo que se ajusta por entorno. La velocidad pico bajó. Los tickets bajaron más.

La lección: el mejor Wi‑Fi es el Wi‑Fi aburrido. Optimiza para estabilidad y equidad de airtime, no para una captura de pantalla que puedas poner en una presentación.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada tenía la costumbre que otros equipos se burlaban: mantenían una pequeña matriz de “versiones de controlador conocidas como buenas” por chipset y modelo de portátil.
También probaban las actualizaciones de características de Windows con esos controladores en un anillo piloto antes del despliegue amplio.

Cuando llegó una actualización de Windows 11 y el rendimiento Wi‑Fi se degradó para una familia de adaptadores específica, no entraron en pánico.
Ya tenían líneas base: distribuciones de ping a la puerta de enlace, rangos de rendimiento iperf y comportamiento de roaming bajo carga.
No fue subjetivo. Fue una regresión medible.

Mantuvieron el controlador constante, reprodujeron el problema y luego probaron dos versiones alternas: una más nueva, una más antigua.
La versión antigua restauró la estabilidad. La más nueva mejoró el rendimiento pero reintrodujo churn de roaming en ciertos modelos de AP.
Así que eligieron la opción aburrida: estabilidad primero, luego una gestión de proveedor más prolongada para el caso complejo.

Mientras otras organizaciones pasaron semanas en “intenta apagar y encender de nuevo,” esta envió una reversión controlada mediante gestión de endpoints
y siguió con su trabajo. Nadie recibió un ascenso por ello. Ahí sabes que fue correcto.

Una idea parafraseada a menudo atribuida al pensamiento de confiabilidad en ingeniería (no literal): la disponibilidad viene de controlar el cambio y entender los modos de fallo, no de heroísmos.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “La velocidad de enlace es enorme pero las descargas son lentas”

• Causa raíz: Rendimiento limitado por reintentos, interferencia o CPU/NAT/cifrado del router; la velocidad de enlace es solo PHY.
• Solución: Haz ping a la puerta de enlace por jitter/pérdida; prueba iperf LAN; intenta 80 MHz en vez de 160; actualiza/retrocede el controlador; confirma que estás en 5/6 GHz.

2) Síntoma: “Rápido durante 30 segundos, luego cae, luego se recupera”

• Causa raíz: Transiciones de estados de gestión de energía, peculiaridades de Target Wake Time o bugs del controlador después de suspensión.
• Solución: Desactiva la casilla de apagado del adaptador; prueba con corriente alterna; establece Wireless Adapter Settings a Maximum Performance; considera rollback del controlador.

3) Síntoma: “Solo va lento con batería”

• Causa raíz: Políticas de energía agresivas para el adaptador WLAN.
• Solución: Establece el ahorro de energía del adaptador Wi‑Fi en Maximum Performance con batería; mantén Balanced pero ajusta este parámetro si te importa la estabilidad en conferencias.

4) Síntoma: “Solo va lento en un lugar (mismo portátil)”

• Causa raíz: Congestión RF, eventos DFS o el band steering te pone en 2.4 GHz.
• Solución: Verifica canal y banda; conéctate al SSID 5/6 GHz; evita forzar 160 MHz en entornos congestionados.

5) Síntoma: “Wi‑Fi 6E es más lento que Wi‑Fi 6”

• Causa raíz: Atenuación de la señal de 6 GHz a través de paredes, SNR efectivo más bajo o colocación de AP no diseñada para 6 GHz.
• Solución: Usa 6 GHz cerca del AP; de lo contrario prefiera 5 GHz fuerte; considera añadir APs en lugar de esperar que 6 GHz atraviese paredes.

6) Síntoma: “La VPN se siente rota en Wi‑Fi pero bien por Ethernet”

• Causa raíz: Jitter/pérdida en Wi‑Fi que provoca retransmisiones de la VPN; MTU/fragmentación puede amplificar el problema.
• Solución: Primero estabiliza el ping a la puerta de enlace; luego revisa MTU y ajustes del cliente VPN si hace falta. No empieces por la VPN.

7) Síntoma: “Después de una actualización de Windows, el rendimiento Wi‑Fi cayó”

• Causa raíz: Controlador reemplazado por Windows Update o nuevos valores por defecto de políticas de energía.
• Solución: Identifica cambios de versión del controlador; prueba rollback; luego fija la versión conocida como buena mediante gestión de endpoints.

8) Síntoma: “La velocidad está bien, pero la latencia sube durante subidas”

• Causa raíz: Bufferbloat en el router/enlace WAN; saturación upstream; QoS no configurado.
• Solución: Limita las subidas, habilita SQM/Smart Queue Management si está disponible, o configura QoS adecuadamente. Aquí el Wi‑Fi puede ser inocente.

Listas de verificación / plan paso a paso

Plan A: Arreglar el combo controlador + energía (la victoria habitual)

1. Registrar línea base: ejecuta netsh wlan show interfaces y guarda canal, tipo de radio, tasas y señal.
   Ejecuta una prueba de ping de 30 segundos a la puerta de enlace y anota latencia máxima/media.
2. Comprobar versión del controlador: ejecuta netsh wlan show drivers. Si la versión cambió recientemente, planifica una prueba de rollback.
3. Actualizar o retroceder intencionalmente:
   • Prefiere controladores soportados por el OEM primero para portátiles (a menudo ajustan energía/antenas).
   • Si el OEM está anticuado o roto, prueba controladores del proveedor del chipset, pero trátalo como un cambio con posibilidad de rollback.
4. Desactivar apagado del adaptador: en Administrador de dispositivos → Adaptadores de red → tu adaptador Wi‑Fi → Administración de energía:
   desmarca “Permitir que el equipo apague este dispositivo para ahorrar energía.”
5. Configurar política de energía del adaptador inalámbrico: Opciones de energía → Configuración avanzada → Wireless Adapter Settings:
   establece tanto “Con batería” como “Con corriente” en Maximum Performance (al menos para pruebas; mantenlo si mejora tu vida).
6. Volver a probar: ping a la puerta de enlace otra vez; luego una prueba iperf LAN si puedes; luego prueba de internet.
7. Decidir: si la estabilidad de la latencia mejoró de forma significativa, conserva la configuración y deja de tocarlo.

Plan B: Saneamiento de banda y canal (cuando el PHY es el problema)

1. Confirma que estás en 5 GHz o 6 GHz. Si estás en 2.4 GHz, corrige el steering o separa SSID temporalmente para demostrar el punto.
2. Evita 160 MHz hasta que tengas evidencia de que ayuda. Usa 80 MHz para estabilidad en entornos ruidosos.
3. En 6E, coloca el AP donde 6 GHz realmente pueda alcanzar tu escritorio. Si no puede, usa 5 GHz y sigue adelante.
4. Vuelve a probar: si las tasas y el ping a la puerta de enlace mejoran, tenías un problema de planificación RF/canal, no un problema de Windows.

Plan C: Interacciones de funciones del router (cuando “nuevo” equivale a “raro”)

1. Cambia temporalmente WPA3-only a modo de transición WPA2/WPA3 (o WPA2) para probar peculiaridades de negociación/rendimiento.
2. Desactiva funciones avanzadas de roaming (802.11r) si ves churn repetido de auth/roam en clientes Windows.
3. Actualiza el firmware del router. Si el firmware ya está al día, considera que “actual” puede ser “actualmente defectuoso.” Prueba una versión anterior si es posible.
4. Mantén los cambios aislados: un cambio, una prueba, una decisión. No crees un guiso misterioso.

Preguntas frecuentes

1) ¿Por qué mi velocidad de enlace Wi‑Fi 6/6E es alta pero la velocidad real es baja?

La velocidad de enlace es la tasa PHY negociada. El rendimiento real es menor por sobrecarga, contención, reintentos y, a veces, límites de CPU del router.
Usa ping a la puerta de enlace e iperf LAN para encontrar dónde se introduce la pérdida/jitter.

2) ¿Debo activar siempre los canales de 160 MHz?

No. Usa 160 MHz cuando tengas espectro limpio y distancias cortas. De lo contrario suele aumentar la variabilidad (eventos DFS, interferencias)
y puede reducir el rendimiento real o la estabilidad.

3) ¿6 GHz siempre es más rápido que 5 GHz?

No siempre. 6 GHz suele ser más limpio, pero se atenúa más a través de paredes. Si tu señal de 6 GHz no es fuerte, 5 GHz puede rendir mejor en la práctica.

4) ¿Quiero siempre el controlador Wi‑Fi más nuevo?

Quieres el mejor controlador para tu combinación adaptador + portátil + router. “Más nuevo” a veces es correcto, a veces una regresión.
Si el rendimiento empeoró tras una actualización, una prueba controlada de rollback es una ingeniería sensata.

5) ¿Qué ajuste de Windows 11 provoca más a menudo tartamudeos en Wi‑Fi?

La gestión de energía. Específicamente: permitir que Windows apague el adaptador y el ahorro de energía inalámbrico agresivo con batería.
Desactiva la casilla de apagado del adaptador y establece el ahorro del adaptador inalámbrico en Maximum Performance como prueba.

6) Mi Wi‑Fi va lento solo después de la suspensión. ¿Por qué?

Algunos controladores no reanudan correctamente, o las transiciones de estado de energía quedan atascadas en modos subóptimos.
Una actualización/rollback del controlador más desactivar los cortes de energía del adaptador suele solucionarlo.

7) ¿Desactivar IPv6 acelerará mi Wi‑Fi?

Usualmente no, y a menudo crea nuevos problemas. Si sospechas DNS o problemas de ruta, prueba con ping a la puerta de enlace e iperf LAN primero.
No rompas IPv6 porque internet te lo dijo.

8) ¿Cómo sé si el router es el cuello de botella?

Si iperf LAN entre tu cliente Wi‑Fi y un servidor cableado es lento, el cuello de botella es local (Wi‑Fi o router).
Si iperf LAN es rápido pero internet es lento, lo más probable es la ruta WAN del router, ISP, VPN o congestión upstream.

9) ¿Por qué el rendimiento cambia según el router de oficina vs casa?

Diferentes planes de canal, diferentes conjuntos de funciones (WPA3/802.11r/OFDMA tuning) y diferentes perfiles de interferencia.
Los controladores pueden comportarse distinto según la implementación del AP y el comportamiento del band steering.

10) ¿Debería separar SSID (nombres separados para 2.4/5/6 GHz)?

Para la resolución de problemas, sí—es una de las maneras más rápidas de demostrar que el band steering es el problema.
A largo plazo, un solo SSID puede estar bien si tu router hace buen steering. Muchos no lo hacen.

Conclusión: próximos pasos que realmente mueven la aguja

Si recuerdas una cosa: deja de adorar el número de velocidad de enlace. Mide la latencia a la puerta de enlace, confirma tu banda y trata los cambios de controlador como cambios reales
con posibilidad de rollback. Windows 11 no es extraordinariamente malo con Wi‑Fi 6/6E; solo es muy bueno ocultando los dos controles que más importan: el comportamiento del controlador y la política de energía.

Pasos prácticos siguientes:

1. Ejecuta netsh wlan show interfaces y confirma banda/canal y tasas.
2. Haz ping a tu puerta de enlace predeterminada durante 30–60 segundos. Picos o pérdida significan problemas Wi‑Fi locales.
3. Comprueba la versión del controlador con netsh wlan show drivers. Si los problemas empezaron después de una actualización, prueba rollback.
4. Desactiva el apagado del adaptador y establece el ahorro de energía del adaptador inalámbrico en Maximum Performance (al menos para pruebas).
5. Si estás forzando 160 MHz, prueba 80 MHz por un día y ve si la estabilidad mejora.

El Wi‑Fi es un medio compartido con muchas piezas en movimiento. El truco es ser metódico, no místico.