Wi-Fi dice conectado, nada carga: resolutores del Mac obsoletos

Haga ping a una dirección literal y responde. Abra un sitio por su nombre y no pasa nada, mientras el icono de red insiste en que la conexión está bien. En un Mac que acaba de unirse a una VPN, esa combinación casi siempre significa que las consultas apuntan a un servidor que ya no es accesible, no que la red esté caída. Las direcciones se fijaron al servicio Wi-Fi en algún momento anterior y nada las ha quitado desde entonces. Diagnostique por eliminación y luego borre las entradas fijadas.

La reparación es un borrado y no un vaciado, y la diferencia importa porque los comandos que la mayoría prueba primero hacen algo completamente distinto.

Conectado es una afirmación sobre el enlace

macOS mantiene una configuración de resolutor por cada servicio de red. Los valores del DHCP son una fuente, los escritos a mano otra, y los que empuja un perfil o escribe un cliente son una tercera. Los fijados tienen más peso que lo que ofrece la red, y nada en la pila los vuelve a validar. Por eso un servidor que se ha ido se queda en la lista hasta que una persona lo quita o el servicio se reconstruye desde cero.

Por eso un túnel que completa su saludo no cambia nada en una consulta que ya iba mal dirigida. La VPN añadió un resolutor; no auditó el que estaba fallando.

Separe los nombres de los paquetes

Primero llegue a un host por la dirección literal. Cuando carga, los paquetes están bien y el resolutor tiene la culpa. Cuando no carga, deténgase ahí y trate el problema como de enrutamiento, porque los cambios de DNS solo añadirán una variable a un panorama ya confuso.

Un nombre que falla mientras la dirección correspondiente funciona es la huella. Fíjese también en el alcance: si falla todo, apunta a una entrada global rota, mientras que si solo fallan los hosts dentro del túnel, apunta a otro propietario y a una solución más estrecha.

Borre los servidores fijados

En Ajustes de Red, abra los detalles del servicio Wi-Fi y pase a la pestaña DNS. Quite cada fila de servidor, confirme el cambio y luego revise los dominios de búsqueda por si hay valores que nunca añadió. Deje la lista vacía, vuelva a conectar el servicio y confirme que la dirección que entrega el DHCP reaparece por sí sola. Una lista vacía es el estado temporal que demuestra que los valores fijados eran el problema.

Las versiones antiguas esconden el mismo panel un nivel más abajo, tras un botón Avanzado, con un comportamiento idéntico y el mismo resultado.

Lea el estado, no el panel

scutil --dns | head -40 imprime los resolutores que macOS usa de verdad, agrupados por alcance, y un nslookup rápido de un nombre interno conocido muestra si llega alguna respuesta. Compare las dos salidas: un panel limpio con un servidor obsoleto todavía listado significa que otro escritor es dueño de ese ajuste. Ese es otro fallo con otra solución.

Cuando ambos parecen limpios y los nombres siguen fallando, el fallo se ha mudado a otro sitio y ya no está depurando la configuración de DNS.

Quién vuelve a poner las entradas

Los servidores que regresan tras borrarlos tienen un origen. Revise Gestión de dispositivos por si hay un perfil de configuración, porque los perfiles pueden llevar DNS y se reevalúan según su propio calendario. Revise las preferencias del cliente por si hay una opción de establecer DNS al conectar, y decida si aún merece su sitio en esta máquina. Si la VPN necesita de verdad un resolutor privado, limítelo a los dominios que posee en lugar de escribir en la lista global que hereda toda red futura.

Anote el resolutor previsto y los dominios que debe responder. Tras la siguiente actualización del cliente, verifique un nombre público y uno privado, lo que es más rápido que repetir el recorrido por los ajustes y atrapa la regresión mientras la máquina sigue en sus manos.

Todo lo demás es teatro de mantenimiento: comandos que parecen deliberados, no cambian nada medible y dejan la misma consulta rota para la siguiente persona.