Cuando la red de Windows falla, rara vez lo hace con dignidad. Un minuto estás en la VPN, al siguiente aparece “Conectado, sin internet”, las llamadas de Teams suenan como un submarino, y tu panel de monitorización educadamente finge que no pasa nada porque el host aún puede hacerse ping a sí mismo.
La tentación es pulsar el gran botón rojo: “Restablecer red”, invocaciones aleatorias de netsh, reiniciar y esperar. A veces funciona. A veces convierte un problema localizado en una interrupción total, especialmente en máquinas con clientes VPN, conmutadores virtuales, Hyper‑V, WSL2 o hooks de seguridad endpoint. Esta guía es la forma sensata: restablece la pila de red con PowerShell de manera limpia, deliberada y reversible.
Qué significa realmente “restablecer la pila de red”
La gente dice “restablecer la red” como se dice “reiniciar el servidor”. No es una única acción. En Windows, la “pila de red” es un montón de capas que interactúan con estado en varios sitios:
- Configuración de la interfaz: direcciones IP, rutas, servidores DNS, MTU, estado DHCP.
- Parámetros TCP/IP: ajustes globales como auto-tuning, ECN, RSS, offloads. Algunos son por interfaz.
- Catálogo Winsock: donde los Layered Service Providers (LSPs) solían enganchar llamadas de socket; hoy muchos productos usan WFP (Windows Filtering Platform), pero los resets de Winsock siguen apareciendo en los playbooks.
- Cache del cliente DNS y NRPT: la resolución de nombres es tanto cache del cliente como políticas (especialmente con VPN).
- Configuración de proxy: WinINET/WinHTTP y ajustes PAC; pueden romper el “internet” mientras los sockets crudos siguen funcionando.
- Perfiles y reglas de firewall: no es estrictamente “pila de red”, pero lo bastante cercano como para que los restablecimientos choquen con ello.
- Conmutadores y adaptadores virtuales: vSwitch de Hyper‑V, vEthernet de WSL2, adaptadores VPN, drivers de filtro de agentes endpoint.
Un “restablecimiento” puede significar:
- Restablecimiento suave: limpiar caches, renovar leases, reiniciar adaptadores, restablecer proxy. Bajo riesgo, alto retorno.
- Restablecimiento medio: resetear Winsock y parámetros TCP/IP a valores por defecto, reconstruir partes de la pila, reiniciar servicios. A veces requiere reinicio. Puede interrumpir integraciones VPN/EDR.
- Restablecimiento duro: eliminar y reinstalar adaptadores, borrar perfiles, eliminar rutas persistentes, resetear políticas de firewall, opción “Restablecer red” de la interfaz. Eficaz, pero acabas de borrar evidencias y posiblemente configuraciones críticas para el negocio.
La mentalidad de producción es simple: empieza con movimientos reversibles y observables. Escala solo cuando no puedas probar el modo de fallo o hayas llegado a un estado conocido como malo. Y siempre deja migas de pan para la siguiente persona—a menudo también tú, pero de peor humor.
Antes de tocar nada: límites, respaldos y radio de impacto
Resetear la red en una máquina Windows es como cambiar neumáticos en un coche en movimiento—salvo que el coche está en una llamada y los pasajeros son tus ejecutivos. No lo toques a ciegas.
Decide el alcance: ¿máquina, usuario, aplicación o ruta?
Si solo una aplicación está rota, no “restestees la pila” primero. Demuestra que no es a nivel de app (ajustes de proxy, almacén de certificados, VPN por aplicación, DNS interno obsoleto). Si solo un usuario falla en un sistema compartido, sospecha proxy por usuario/WPAD, credenciales o herramientas VPN específicas del perfil.
Saber qué significa “reversible” en redes Windows
Reversible no significa “botón deshacer”. Significa que tienes suficiente estado capturado para reconstruir:
- Configuración IP/DNS de las interfaces (DHCP vs estático)
- Rutas (especialmente las rutas persistentes)
- Sufijo DNS/lista de búsqueda
- Ajustes de proxy (WinINET y WinHTTP)
- Políticas relacionadas con VPN (NRPT) y nombres de adaptadores
- Propiedades avanzadas del adaptador que hayas ajustado intencionalmente
La mayoría de los scripts de “reset de red” omiten esto y luego recibes el ticket de seguimiento: “Todo funciona excepto la app crítica que necesita una ruta estática a una subred rara”. Esa subred siempre será rara. Aun así tienes que enrutar hacia ella.
Realidad administrativa
Muchas operaciones requieren elevación. Si estás en un endpoint corporativo gestionado, algunas acciones estarán bloqueadas por políticas o serán revertidas por agentes de gestión después. Haz las paces con eso. Tu trabajo es diagnosticar y aplicar el cambio mínimo que permanezca.
Una cita, porque es cierta
“La esperanza no es una estrategia.” — General Gordon R. Sullivan
Los “resets” de red impulsados por la esperanza son cómo acabas reiniciando cinco veces y aún llamándolo “intermitente”.
Guion de diagnóstico rápido (encuentra el cuello de botella en minutos)
Este es el orden que gana en producción: identifica rápidamente si tratas con enlace, IP, resolución de nombres, ruteo, proxy o filtrado. No estás aquí para “probar cosas”. Estás aquí para responsabilizar a una capa.
Primero: ¿la interfaz está realmente arriba y en estado sano?
- Comprueba el estado del adaptador, la velocidad y si se está usando la NIC correcta.
- Confirma que tienes una IP (IPv4 y/o IPv6) y una puerta de enlace por defecto donde esperas una.
Segundo: ¿puedes alcanzar la puerta de enlace y algo más allá?
- Haz ping a la puerta de enlace (alcance L2/L3 local).
- Haz ping a una IP externa (ruteo/NAT/upstream).
- Haz traceroute si el ping engaña (los firewalls hacen del ping un test poco fiable).
Tercero: ¿es DNS el problema (a menudo lo es)?
- Resuelve un nombre conocido a través del servidor DNS configurado.
- Compara resolución de nombres frente a conectividad por IP crudo.
- Vacía la cache DNS solo después de haber capturado evidencia.
Cuarto: ¿un proxy o una política VPN está secuestrando el tráfico?
- Comprueba el proxy WinHTTP y el proxy de usuario.
- Revisa las rutas VPN y las reglas NRPT (tunel dividido vs tunel completo).
Quinto: ¿hay filtrado (firewall, EDR, WFP callout, driver)?
- Busca caídas súbitas después de una actualización específica.
- Verifica el perfil del firewall y reglas básicas de salida.
- Si todo “parece bien” pero nada funciona, sospecha de un driver de filtro o de un orden de enlaces roto.
Si sigues ese orden, normalmente evitarás el peor comportamiento: resetear cinco subsistemas cuando un PAC de proxy obsoleto era el verdadero culpable.
Datos interesantes y contexto histórico
Seis a diez datos pequeños para ayudarte a razonar por qué la red en Windows se comporta como lo hace:
- Los resets de Winsock son una reliquia que aún importa. Los Layered Service Providers (LSPs) fueron una forma común de que el software interceptara sockets; las herramientas de seguridad modernas a menudo usan WFP, pero el catálogo Winsock aún puede corromperse o quedar en un orden incorrecto.
netshes anterior a PowerShell por años. La automatización de redes en Windows vivió ennetshmucho antes de que PowerShell se convirtiera en la interfaz estándar. Muchas soluciones “PowerShell” todavía llaman anetshporque está probada en batalla.- Windows prefiere IPv6 cuando puede. Los sistemas dual-stack a menudo intentan registros AAAA primero. “IPv6 está roto” puede manifestarse como “internet lento”, no como “IPv6 caído”.
- DNS en Windows no es solo DNS. El resolutor mezcla cache, listas de sufijos, LLMNR, mDNS (más nuevo) y reglas basadas en políticas (NRPT). Una política errónea puede hacer que nombres internos fallen mientras los públicos funcionan.
- La función UI “Restablecer red” es relativamente nueva. Es una conveniencia de la era Windows 10+ que efectivamente elimina y reinstala adaptadores y resetea componentes. También es una excelente forma de perder enrutamiento personalizado y enlaces VPN.
- El auto-tuning de TCP fue controversial. Cuando Windows introdujo el auto-tuning de la ventana de recepción ampliamente, mejoró el rendimiento para muchos enlaces pero causó rarezas con algunos middleboxes. Desactivarlo se volvió medicina popular; a veces ayudó, a menudo solo redujo el rendimiento.
- Las configuraciones de proxy viven en dos mundos. El proxy WinINET es en contexto de usuario y lo usan los navegadores; el proxy WinHTTP es en contexto de máquina y lo usan los servicios. Resetear uno y no el otro produce la comedia “funciona en el navegador, falla en el servicio”.
- El ruteo basado en métricas suele tener razón… hasta que no. Windows elige rutas según la longitud del prefijo y métricas. Añade un adaptador VPN y de repente tu ruta por defecto cambia. La gente lo llama “aleatorio”. No lo es. Es determinista e inconveniente.
- La seguridad endpoint adora la pila de red. Muchos EDRs instalan drivers de filtro y WFP callouts. Un “reset” que reordena enlaces o resetea catálogos puede romper esas integraciones—temporalmente o hasta que el agente se repare.
Tareas prácticas (comandos, salidas, decisiones)
A continuación hay tareas prácticas que puedes ejecutar desde un PowerShell elevado. Los bloques de código muestran comandos realistas y salidas plausibles. Después de cada tarea: qué significa la salida y qué decisión debes tomar.
Tarea 1: Confirma que tienes elevación (no lo supongas)
cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal]::new([Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)"
True
Qué significa: True indica contexto de Administrador. Muchas acciones de restablecimiento fallarán silenciosamente o se aplicarán parcialmente sin él.
Decisión: Si es False, vuelve a abrir PowerShell “Ejecutar como administrador”. No sigas. Los restablecimientos parciales son la forma de crear fallos únicos e irreproducibles.
Tarea 2: Captura la configuración actual de la interfaz (tu semilla de rollback)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,InterfaceIndex,IPv4Address,IPv6Address,DNSServer,IPv4DefaultGateway,NetProfile.Name"
InterfaceAlias : Ethernet0
InterfaceIndex : 12
IPv4Address : 10.20.14.55
IPv6Address : fe80::b9f1:7c2a:7c2d:aa11
DNSServer : {10.20.0.10, 10.20.0.11}
IPv4DefaultGateway : 10.20.14.1
NetProfile.Name : CorpLAN
Qué significa: Esto te dice cómo era “lo bueno” antes de tocar nada: IP, gateway, servidores DNS y en qué perfil Windows cree que está.
Decisión: Guárdalo (copia/pega en el ticket, o exporta a un archivo). Si no ves gateway por defecto, aún no es un problema de “reset”—arregla DHCP/configuración estática primero.
Tarea 3: Identifica la elección de ruta activa (la ruta por defecto cuenta historias)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric,InterfaceMetric | Format-Table ifIndex,InterfaceAlias,NextHop,RouteMetric,InterfaceMetric -Auto"
ifIndex InterfaceAlias NextHop RouteMetric InterfaceMetric
------ -------------- ------- ----------- --------------
12 Ethernet0 10.20.14.1 0 25
28 VPN-Corp 0.0.0.0 10 5
Qué significa: Tienes rutas por defecto en competencia. Aquí, el adaptador VPN tiene una métrica total menor y puede robar tráfico. Eso puede ser deseado (túnel completo) o un desastre (se esperaba túnel dividido).
Decisión: Si los síntomas empezaron “tras conectar la VPN”, no restestees la pila—arregla la intención de ruteo/métrica. Si la VPN debería ser túnel dividido, revisa la configuración de la VPN y empuja rutas correctamente.
Tarea 4: Conectividad básica: puerta de enlace y luego IP externa
cr0x@server:~$ powershell -NoProfile -Command "Test-Connection -Count 2 10.20.14.1"
Source Destination IPV4Address IPV6Address Bytes Time(ms)
------ ----------- ----------- ----------- ----- --------
WIN-CLIENT01 10.20.14.1 10.20.14.1 32 2
WIN-CLIENT01 10.20.14.1 10.20.14.1 32 2
cr0x@server:~$ powershell -NoProfile -Command "Test-Connection -Count 2 1.1.1.1"
Source Destination IPV4Address IPV6Address Bytes Time(ms)
------ ----------- ----------- ----------- ----- --------
WIN-CLIENT01 1.1.1.1 1.1.1.1 32 16
WIN-CLIENT01 1.1.1.1 1.1.1.1 32 15
Qué significa: El ruteo L3 hacia internet está bien (al menos ICMP funciona). Si las aplicaciones aún fallan, sospecha DNS/proxy/filtros.
Decisión: Si la puerta de enlace falla, no toques Winsock—tu problema es enlace local/VLAN/DHCP/configuración estática. Si la puerta de enlace funciona pero la IP externa falla, sospecha ruteo upstream, firewall o captura de rutas por VPN.
Tarea 5: Prueba de resolución DNS que realmente te diga algo
cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName -Name example.com -Server 10.20.0.10 | Select-Object -First 2"
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
example.com A 60 Answer 93.184.216.34
example.com A 60 Answer 93.184.216.34
Qué significa: El servidor DNS responde y devuelve registros. Si puedes hacer ping a 1.1.1.1 pero DNS falla, tu problema es la accesibilidad al DNS, la política DNS o el estado del cliente DNS.
Decisión: Si esto falla con timeout, verifica si el servidor DNS es accesible y si la VPN o el firewall están bloqueando UDP/TCP 53. Si falla con “NXDOMAIN” para nombres internos, revisa la lista de sufijos y NRPT.
Tarea 6: Revisa la caché del cliente DNS (y no la vacíes a ciegas)
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientCache | Select-Object -First 5"
Entry RecordName RecordType TimeToLive Data
----- ---------- ---------- ---------- ----
example.com example.com A 00:00:41 93.184.216.34
wpad wpad A 00:05:00 10.20.0.50
intranet intranet A 00:00:12 10.20.8.20
Qué significa: Puedes ver entradas en caché como wpad. WPAD es una fuente frecuente de “solo las apps web están rotas”.
Decisión: Si ves entradas sospechosas (IP incorrecta para intranet, wpad obsoleto), vacía la caché después de capturarla y vuelve a probar la resolución. Si el resultado erróneo vuelve inmediatamente, el problema está aguas arriba o es policy, no caché local.
Tarea 7: Inspecciona el estado del proxy (WinINET vs WinHTTP)
cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:
Proxy Server(s) : 10.20.0.60:8080
Bypass List : (none)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable,ProxyServer,AutoConfigURL"
ProxyEnable ProxyServer AutoConfigURL
----------- ----------- -------------
1 10.20.0.60:8080 http://wpad/wpad.dat
Qué significa: Tanto el contexto máquina como el de usuario apuntan a un proxy/PAC. Si ese proxy no es accesible, los navegadores y muchas apps fallarán mientras el ping funcione bien.
Decisión: Si el proxy no es necesario en esta red, restablécelo (con cuidado). Si es obligatorio, prueba la accesibilidad al proxy y valida la resolución del PAC.
Tarea 8: Comprueba si el servicio cliente DNS está sano
cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache | Format-Table Status,StartType,Name -Auto"
Status StartType Name
------ --------- ----
Running Automatic Dnscache
Qué significa: Si Dnscache está detenido/deshabilitado, la resolución de nombres se vuelve inconsistente y más lenta; algunas APIs se comportan distinto.
Decisión: Si no está en ejecución, inícialo e investiga por qué estaba deshabilitado (¿política de hardening? ¿herramienta “optimizadora”?). No restestees TCP/IP para arreglar un servicio detenido.
Tarea 9: Observa ajustes TCP globales antes de “tunear” nada
cr0x@server:~$ powershell -NoProfile -Command "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
RFC 1323 Timestamps : disabled
Qué significa: Estos son comportamientos globales de TCP. “Resetear TCP/IP” puede revertir algunos ítems; los “optimizadores” a menudo los cambian.
Decisión: Si alguien previamente puso auto-tuning en disabled o cambió el proveedor de congestión “por rendimiento”, trátalo como sospechoso. Pero no lo cambies solo porque “Internet” lo recomienda.
Tarea 10: Identifica drivers de adaptador y cambios recientes
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,LinkSpeed,DriverInformation | Format-List"
Name : Ethernet0
Status : Up
LinkSpeed : 1 Gbps
DriverInformation : Intel(R) Ethernet Connection (11) I219-LM #4
Name : VPN-Corp
Status : Up
LinkSpeed : 100 Mbps
DriverInformation : WAN Miniport (IKEv2)
Qué significa: “Up” no significa “saludable”, pero es un comienzo. La identidad del driver importa: los proveedores NIC incluyen offloads avanzados que pueden fallar tras actualizaciones.
Decisión: Si el problema comenzó tras una actualización de driver, concéntrate ahí. Los resets de pila no arreglarán un driver defectuoso o un binding de filtro roto.
Tarea 11: Reinicia un único adaptador (bajo riesgo, sorprendentemente efectivo)
cr0x@server:~$ powershell -NoProfile -Command "Restart-NetAdapter -Name 'Ethernet0' -Confirm:\$false"
Qué significa: Esto rebota la interfaz, renegocia el enlace, renueva DHCP en muchos casos y vuelve a ligar protocolos.
Decisión: Haz esto antes de destruir Winsock. Si rebotar el adaptador lo arregla, aprendiste que el problema era estado a nivel de interfaz (lease DHCP, fallo del driver, rareza de puerto de switch).
Tarea 12: Forzar renovación DHCP (cuando sospechas un lease obsoleto)
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /release"
Windows IP Configuration
No operation can be performed on Ethernet0 while it has its media disconnected.
Ethernet0 has been released.
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /renew"
Windows IP Configuration
Ethernet0 has renewed its lease.
IPv4 Address. . . . . . . . . . . : 10.20.14.55
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.20.14.1
Qué significa: Release/renew es contundente pero reversible. Si la renovación falla, la ruta DHCP está rota (o 802.1X/VLAN está mal).
Decisión: Si renew falla, detente. Arregla la autenticación L2/VLAN/alcance DHCP. No procedas a resets de pila; solo te quedarás sin red de forma más complicada.
Tarea 13: Vacía DNS y vuelve a probar (solo después de tener evidencia)
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /displaydns | Select-Object -First 12"
Windows IP Configuration
example.com
----------------------------------------
Record Name . . . . . : example.com
Record Type . . . . . : 1
Time To Live . . . . : 41
Data Length . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 93.184.216.34
cr0x@server:~$ powershell -NoProfile -Command "ipconfig /flushdns"
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Qué significa: La caché se borra. Si la resolución vuelve a dar el resultado equivocado de inmediato, el envenenamiento está aguas arriba o es por políticas, no por caché local.
Decisión: Si vaciarla lo arregla y se mantiene, tenías caché obsoleta. Si vuelve, persigue respuestas del servidor DNS, sufijos, NRPT o ajustes DNS de la VPN.
Tarea 14: Resetear Winsock (impacto medio, a menudo requiere reinicio)
cr0x@server:~$ powershell -NoProfile -Command "netsh winsock show catalog | Select-String -Pattern 'Catalog5' -Context 0,2 | Select-Object -First 6"
Catalog5 01
--------
Packed Catalog Item
Description: MSAFD Tcpip [TCP/IP]
cr0x@server:~$ powershell -NoProfile -Command "netsh winsock reset"
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
Qué significa: El catálogo Winsock se reconstruye a valores por defecto. Esto puede romper o arreglar software que engancha sockets. El requisito de reinicio es real.
Decisión: Haz esto solo después de descartar issues simples de proxy/DNS/interfaz. Si la máquina es crítica, programa el reinicio. No lo hagas en medio de un incidente en el portátil del CEO a menos que disfrutes la adrenalina.
Tarea 15: Resetear parámetros de la pila TCP/IP (martillo más grande)
cr0x@server:~$ powershell -NoProfile -Command "netsh int ip reset"
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.
Qué significa: Esto resetea muchas configuraciones del registro de TCP/IP. Puede arreglar corrupción y tweaks malos. También puede eliminar afinaciones deliberadas y algunos patrones de configuración estática.
Decisión: Hazlo solo cuando hayas documentado el estado actual y estés preparado para restaurar configuraciones estáticas y rutas después.
Tarea 16: Resetear proxy WinHTTP (arreglo común de “internet roto”)
cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp reset proxy"
Current WinHTTP proxy settings:
Direct access (no proxy server).
Qué significa: El proxy en contexto máquina se borra. Los servicios que dependen de WinHTTP pueden empezar a funcionar de inmediato.
Decisión: Si estás en un entorno corporativo que exige un proxy, no lo borres permanentemente—configúralo correctamente. Pero resetear es un buen paso diagnóstico: si los servicios empiezan a funcionar, la ruta del proxy es el incidente real.
Tarea 17: Capturar y restaurar rutas persistentes (la interrupción fácil de olvidar)
cr0x@server:~$ powershell -NoProfile -Command "route print -4 | Select-String -Pattern 'Persistent Routes' -Context 0,8"
Persistent Routes:
Network Address Netmask Gateway Address Metric
10.50.0.0 255.255.0.0 10.20.14.254 1
cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -PolicyStore PersistentStore | Format-Table DestinationPrefix,NextHop,RouteMetric,InterfaceAlias -Auto"
DestinationPrefix NextHop RouteMetric InterfaceAlias
----------------- ------- ----------- --------------
10.50.0.0/16 10.20.14.254 1 Ethernet0
Qué significa: Existen rutas persistentes y importan. Un “reset duro” o la reinstalación del adaptador puede eliminarlas, y la app de negocio detrás de 10.50.0.0/16 morirá silenciosamente.
Decisión: Exporta estas antes de resets. Después de los resets, reaplícalas con New-NetRoute -PolicyStore PersistentStore si es necesario.
Tarea 18: Prueba rápida de puerto/ruta (demuestra que no es solo ICMP)
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.0.10 -Port 53"
ComputerName : 10.20.0.10
RemoteAddress : 10.20.0.10
RemotePort : 53
InterfaceAlias : Ethernet0
SourceAddress : 10.20.14.55
TcpTestSucceeded : True
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.0.60 -Port 8080"
ComputerName : 10.20.0.60
RemoteAddress : 10.20.0.60
RemotePort : 8080
InterfaceAlias : Ethernet0
SourceAddress : 10.20.14.55
TcpTestSucceeded : False
Qué significa: El servidor DNS es accesible por TCP 53; el puerto 8080 del proxy no lo es. Eso explica “apps web muertas” sin tocar resets de la pila IP.
Decisión: Arregla la accesibilidad al proxy o las reglas de bypass. No restestees Winsock porque el servidor proxy está caído.
Son muchos comandos, y sí, es intencional. Resetear la pila debería ser el final de una cadena de diagnóstico corta, no el primer paso de un script de apoyo emocional.
Listas de verificación / plan paso a paso: restablecimiento limpio y reversible
Este es el playbook de producción. No es la forma más rápida de “hacer algo”. Es la forma más rápida de dejar de hacer lo incorrecto.
Checklist A: Capturar estado (haz esto siempre)
- Captura configuración de interfaces: IP, DNS, gateway, perfil.
- Captura rutas, incluidas las persistentes.
- Captura ajustes del cliente DNS (lista de sufijos, servidores).
- Captura el estado del proxy (WinINET + WinHTTP).
- Registra el estado de la VPN y la lista de adaptadores.
cr0x@server:~$ powershell -NoProfile -Command "New-Item -ItemType Directory -Force C:\Temp\net-reset | Out-Null; Get-Date | Out-File C:\Temp\net-reset\timestamp.txt; Get-NetIPConfiguration | Out-File C:\Temp\net-reset\netipconfig.txt; Get-NetRoute | Out-File C:\Temp\net-reset\netroutes.txt; Get-DnsClientServerAddress | Out-File C:\Temp\net-reset\dns-servers.txt; netsh winhttp show proxy | Out-File C:\Temp\net-reset\winhttp-proxy.txt; Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Out-File C:\Temp\net-reset\wininet-proxy.txt; Get-NetAdapter | Out-File C:\Temp\net-reset\netadapters.txt"
Qué significa: Ahora tienes una instantánea que puedes comparar después del cambio. Si tu cambio empeora las cosas, puedes restaurar de forma inteligente en lugar de “deshacer” al azar.
Checklist B: Restablecimiento suave (primeras acciones seguras)
- Reinicia el adaptador afectado.
- Renueva lease DHCP (solo si usas DHCP).
- Vacía la caché DNS (después de capturar evidencia).
- Resetear proxy WinHTTP (diagnóstico).
- Reinicia el servicio cliente DNS si está atascado.
cr0x@server:~$ powershell -NoProfile -Command "Restart-NetAdapter -Name 'Ethernet0' -Confirm:\$false; ipconfig /renew; ipconfig /flushdns; netsh winhttp reset proxy; Restart-Service Dnscache -Force"
Windows IP Configuration
Ethernet0 has renewed its lease.
Successfully flushed the DNS Resolver Cache.
Current WinHTTP proxy settings:
Direct access (no proxy server).
Puerta de decisión: Si esto arregla el problema, detente. Documenta qué cambió y por qué funcionó. Tu yo futuro te lo agradecerá.
Checklist C: Restablecimiento medio (cuando falla el suave)
Haz esto cuando hayas demostrado que el host tiene enlace, tiene IP, puede alcanzar la puerta de enlace, pero la red de nivel superior está corrupta o secuestrada.
- Resetear catálogo Winsock.
- Resetear parámetros TCP/IP.
- Reiniciar (sí, realmente reiniciar).
cr0x@server:~$ powershell -NoProfile -Command "netsh winsock reset; netsh int ip reset"
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.
Puerta de decisión: Si no puedes reiniciar, no finjas que restableciste. Programa una ventana de reinicio. La pila está llena de estado; no la engañarás con buenas intenciones.
Checklist D: Restablecimiento duro (último recurso, alto radio de impacto)
Los restablecimientos duros son para máquinas con bindings de adaptador corruptos sin remedio, adaptadores virtuales rotos o “todo está arriba pero nada funciona” tras intentos razonables. Espera reconfigurar clientes VPN, vSwitches y rutas estáticas.
En lugar del “Restablecer red” de Configuración de Windows, prefiero acciones dirigidas primero: eliminar adaptadores obsoletos, deshabilitar/re-habilitar bindings específicos y solo entonces considerar un reset completo. Si debes usar la opción nuclear, asegúrate de tener la instantánea de la Checklist A.
Chiste #1: Un restablecimiento completo de red es como “apágalo y enciéndelo otra vez”, excepto que también borra tu tarea y luego pregunta por qué pareces estresado.
Tres micro-historias del mundo corporativo (cómo falla y cómo sale bien)
Micro-historia 1: El incidente causado por una suposición equivocada
Comenzó como una queja de “la VPN está lenta” desde un equipo remoto del área financiera. El portátil podía hacer ping al gateway VPN, resolvía DNS interno, pero el cliente ERP hacía timeout. Alguien vio “Conectado, sin internet” en el icono Wi‑Fi y concluyó que la pila TCP/IP estaba corrupta.
El intento de arreglo fue entusiasta: reset de Winsock, reset de TCP/IP, “Restablecer red” desde Configuración, reinicio dos veces. Reinstalaron el cliente VPN. Seguía roto. Ahora era peor: la máquina perdió una ruta persistente que había estado silenciosamente enviando el tráfico ERP a través de un appliance proxy interno usado solo por ese departamento.
Nos llamaron después del tercer reinicio, porque a esa altura “debe ser Windows”. La pista estaba en la tabla de ruteo: la VPN había instalado una ruta por defecto con métrica baja, pero la subred del ERP no estaba incluida en las rutas de túnel dividido empujadas por la VPN. Antes del reset, la ruta persistente lo parchaba. Tras el reset, desapareció, así que el tráfico ERP fue al lugar equivocado y murió.
La solución real fue corregir las rutas empujadas por la VPN y volver a añadir la ruta persistente temporalmente. El reset no solo no ayudó—eliminó la solución alternativa que compensaba una mala configuración upstream. La suposición equivocada fue pensar que el icono “sin internet” significaba “TCP/IP corrupto”. En realidad significaba que Windows no podía alcanzar un endpoint de sondeo NCSI específico, que no es lo mismo que “tu red está caída”.
Lección: siempre lee las rutas antes de resetear. Las rutas explican la mayoría de los “apagones misteriosos”, y también son lo primero que borras por accidente.
Micro-historia 2: La optimización que salió mal
Un equipo de ingeniería de escritorio desplegó un script de “optimización de latencia” en una flota de endpoints del piso de trading. Desactivó el auto-tuning de TCP, modificó offloads y aplicó algunos valores de registro copiados de un post de foro de la era Windows Vista. El script hizo que su autor se sintiera poderoso, lo cual rara vez es señal de fiabilidad.
Durante unos días nadie lo notó. Luego empezaron las quejas: apps web internas fallaban intermitentemente, transferencias de archivos lentas y VPNs inestables bajo carga. Los pings estaban bien. Las pruebas de velocidad “parecían aceptables”. Las cargas reales no lo eran.
Comparamos una máquina afectada con una conocida buena. El estado global de TCP fue la pistola humeante: auto-tuning deshabilitado, proveedor de congestión cambiado y una mezcla de offloads de adaptador volteados sin considerar versiones de drivers. Algún middlebox en el camino no toleró el comportamiento resultante y empezó a dropear o reordenar tráfico bajo cargas bursty.
La “solución” terminó siendo un reset—pero un reset controlado. Capturamos el estado, revertimos los globals TCP a valores por defecto y solo aplicamos un cambio estrecho y medible donde era justificable. La mayor parte de la “optimización” se eliminó. El rendimiento mejoró, los errores disminuyeron y lo único que quedó más lento fue la tasa de tickets nuevos.
Lección: las afinaciones de rendimiento sin medición son simplemente incidentes con mejor marketing. Resetear a valores por defecto suele ser la ruta más rápida de regreso a lo aburrido—y lo aburrido es bueno.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Un servidor Windows en una sucursal empezó a fallar al resolver nombres internos. El equipo local hizo lo de siempre: vaciar DNS, reiniciar, regañar al ISP. A veces funcionaba una hora, a veces no. Mientras tanto, el servidor resolvía nombres públicos bien porque podía alcanzar DNS públicos por una ruta alternativa.
Cuando intervenimos, ya había presión para “simplemente restablecer todo”. En su lugar, pedimos una captura base: configuración de interfaces, rutas, servidores DNS y el error exacto de Resolve-DnsName contra cada servidor DNS configurado. Fue lento, metódico y profundamente poco glamuroso.
Los datos mostraron que el servidor estaba configurado con dos servidores DNS: uno interno y uno público. El servidor interno fallaba de forma intermitente por un flap de ruteo entre la sucursal y la sede. Windows entonces “útilmente” usaba el resolutor público, que naturalmente no conocía las zonas internas. Así que las búsquedas internas fallaban según a qué servidor preguntara Windows en ese momento.
La solución fue aburrida: quitar el servidor DNS público, añadir un segundo servidor DNS interno accesible por una ruta estable y corregir la ruta de la sucursal. No fue necesario resetear la pila. La captura base nos impidió destruir la evidencia y nos permitió probar la causalidad al equipo de red.
Lección: captura primero, cambia segundo. No es glamuroso, pero marca la diferencia entre hacer troubleshooting y seguir un ritual.
Errores comunes: síntomas → causa raíz → solución
Esta sección es donde los tickets dejan de ser vagos.
1) “Conectado, sin internet” pero los recursos internos funcionan
Síntoma: Windows muestra “Sin internet”, pero puedes acceder a intranet o hacer ping a IPs internas.
Causa raíz: NCSI (Network Connectivity Status Indicator) no puede alcanzar su endpoint de sondeo, a menudo por proxy, firewall o política DNS. No es necesariamente una caída real.
Solución: Valida el estado real del camino con Test-NetConnection a objetivos conocidos. Revisa proxy y DNS. No restestees TCP/IP porque un icono esté triste.
2) El ping funciona, la navegación web falla
Síntoma: Test-Connection 1.1.1.1 funciona. El navegador no carga nada.
Causa raíz: Mala configuración de proxy (PAC/WPAD), puerto de proxy bloqueado o proxy WinINET mal configurado.
Solución: Inspecciona WinINET y WinHTTP; prueba la conectividad al puerto del proxy; resetea el proxy para diagnóstico.
3) DNS funciona para nombres públicos, falla para nombres internos
Síntoma: Resolve-DnsName example.com funciona; Resolve-DnsName intranet.corp devuelve NXDOMAIN.
Causa raíz: Servidores DNS incorrectos, falta de lista de sufijos DNS o reglas NRPT de la VPN no aplicadas.
Solución: Asegura que los servidores DNS internos estén configurados y sean accesibles; verifica la lista de sufijos; revisa DNS/política de la VPN. Vaciar caché no inventará zonas DNS faltantes.
4) Todo falla tras conectar la VPN
Síntoma: El internet local muere al conectar VPN, o las rutas internas no funcionan.
Causa raíz: Ruta por defecto secuestrada (túnel completo vs túnel dividido), problemas de métricas o rutas empujadas faltantes.
Solución: Inspecciona rutas por defecto y métricas; valida la política de rutas de la VPN. No restestees la pila; arregla la intención de ruteo.
5) “El reset lo arregló una vez, ahora vuelve cada mañana”
Síntoma: Repetición diaria; un reset rápido “ayuda” temporalmente.
Causa raíz: Política/agent subyacente re-aplicando ajustes malos (proxy, DNS, firewall), o un driver inestable que se resetea en suspensión/reanudación.
Solución: Identifica la configuración que deriva comparando snapshots. Arregla la fuente (GPO/MDM/cliente VPN/driver). Resets repetidos son solo hacer el mismo incidente con horario programado.
6) Tras “restablecer red”, una app crítica no alcanza una subred
Síntoma: La mayoría funciona; una subred interna está muerta.
Causa raíz: Rutas persistentes o configuración IP estática perdidas.
Solución: Reaplica rutas persistentes y confirma con Get-NetRoute -PolicyStore PersistentStore. Por eso capturamos el estado.
7) DNS lento, timeouts intermitentes
Síntoma: La resolución de nombres tarda segundos; a veces falla.
Causa raíz: Primer servidor DNS inaccesible, Windows hace fallback lentamente; o un servidor DNS de VPN está sobrecargado.
Solución: Prueba cada servidor DNS directamente con Resolve-DnsName -Server. Elimina servidores DNS muertos; no te limites a vaciar caché y decir “resuelto”.
8) “El reset de Winsock rompió mi cliente de seguridad/VPN”
Síntoma: Tras el reset, el cliente VPN o el agente de seguridad no se conecta, el filtrado de red se comporta de forma extraña.
Causa raíz: El software depende de entradas específicas del catálogo o bindings de filtro; el reset cambió el orden/los valores por defecto.
Solución: Reinstala/repara el agente afectado o restaura desde el estado capturado cuando sea posible. Y la próxima vez, no saltes a un reset de Winsock antes de revisar proxy/DNS/rutas.
Chiste #2: Los resets de Winsock son la cinta adhesiva de las redes Windows—a veces sellan la fuga, a veces se convierten en parte de la plomería.
Preguntas frecuentes
1) ¿“Restablecer la red de este PC” (Configuración) es lo mismo que netsh winsock reset?
No. El “Restablecer red” de la Configuración es más amplio y destructivo: elimina y reinstala adaptadores y resetea múltiples componentes. netsh winsock reset apunta específicamente al catálogo Winsock. Usa la opción de UI solo cuando los restablecimientos dirigidos fallen y hayas capturado el estado.
2) ¿Puedo hacer un restablecimiento limpio solo con PowerShell, sin netsh?
Algunas partes, sí (reinicio de adaptador, inspección de IP, gestión de rutas). Pero Winsock/TCP/IP aún se restablecen de forma más fiable con netsh en muchas versiones de Windows. Ser dogmático sobre la pureza de la herramienta es cómo pierdes tiempo.
3) ¿Cuándo debo reiniciar?
Cuando la herramienta te lo indique y cuando hayas hecho cambios que modifican el estado de bajo nivel de la pila. Los resets de Winsock y TCP/IP suelen requerir reinicio para aplicarse completamente. Si no puedes reiniciar, consíderalo un intento de diagnóstico, no un restablecimiento.
4) ¿El restablecimiento romperá mi VPN?
Puede. Los clientes VPN suelen instalar adaptadores virtuales, rutas, políticas DNS y a veces componentes de filtrado. Los restablecimientos suaves normalmente no dañan. Los restablecimientos medios/duros pueden forzar al cliente a repararse o a reinstalarse. Captura primero rutas y estado DNS para poder decir si la VPN cambió algo.
5) Puedo alcanzar IPs pero no nombres. ¿Debo resetear TCP/IP?
Normalmente no. Eso suele ser accesibilidad a servidores DNS, lista de sufijos, NRPT o proxy/PAC. Empieza con Resolve-DnsName -Server y revisa servidores DNS y rutas. Resetear TCP/IP es un martillo más grande del que pide el problema.
6) ¿Cuál es el comando de “primer restablecimiento” más seguro?
Restart-NetAdapter para el adaptador afectado, seguido de un vaciado de DNS dirigido si tienes evidencia de resolución obsoleta. Tiene bajo radio de impacto y a menudo limpia rarezas transitorias de driver/DHCP.
7) ¿Vaciar la caché DNS afecta a otros usuarios o servicios?
Afecta la caché del resolutor local. Puede causar un breve pico de consultas DNS al resolverse los nombres nuevamente. Generalmente es seguro, pero si estás depurando, captura la caché primero para ver qué estaba mal.
8) ¿Por qué fallan algunos servicios mientras los navegadores funcionan (o al revés)?
Contexto de proxy. Los navegadores suelen usar WinINET (proxy de usuario). Los servicios y componentes en segundo plano usan WinHTTP (proxy máquina). Si no coinciden, obtendrás conectividad con “cerebro dividido”.
9) ¿Debo deshabilitar IPv6 para “arreglar” las cosas?
Casi nunca como primera respuesta. Deshabilitar IPv6 puede ocultar problemas reales de DNS/ruta y romper funciones modernas de Windows y algún comportamiento VPN. Si sospechas problemas en la ruta IPv6, prueba explícitamente (resolución AAAA, ping/traceroute IPv6) en lugar de eliminarlo.
10) ¿Cómo hago que el restablecimiento sea reversible en la práctica?
Exportando estado antes de los cambios: configuración de interfaces, rutas (incluidas las persistentes), direcciones de servidores DNS y ajustes de proxy. Si la máquina usa direccionamiento estático o rutas especiales, apúntalas como si importaran—porque importan.
Conclusión: próximos pasos que no generan nuevos tickets
Si recuerdas una cosa: restablecer la pila de red no es troubleshooting; es un paso de remediación. Úsalo cuando hayas acotado el problema a corrupción local o mal estado—no cuando estés aburrido.
Haz esto a continuación, en orden:
- Ejecuta el guion de diagnóstico rápido: interfaz → gateway → IP externa → DNS → proxy/VPN → filtrado.
- Captura el estado en
C:\Temp\net-reset(o donde tu organización espere). Trátalo como evidencia de incidente. - Intenta primero restablecimientos suaves: reinicio de adaptador, renovación DHCP, vaciado DNS, reset de proxy (diagnóstico), reinicio de Dnscache.
- Si sigue roto y tienes ventana de reinicio: Winsock reset + TCP/IP reset, luego reinicia una vez—limpio.
- Después de cualquier reset: verifica rutas y rutas persistentes, confirma servidores DNS, confirma la intención del proxy y vuelve a probar la aplicación originalmente fallida.
Lo más importante: si la solución es “reset”, escribe por qué ayudó. Si no puedes explicarlo, no has arreglado el sistema—solo has negociado con él.