Charles cerró, pero tu Mac sigue apuntando a 127.0.0.1

Una aplicación falla y la culpa recae en el VPN, pero la petición nunca llega al túnel. Si macOS sigue diciéndole a esa aplicación que use un proxy local, el primer salto es 127.0.0.1 y no hay nada escuchando en él. Cerrar Charles no siempre borra el ajuste de proxy del sistema que instaló, así que un VPN sano queda detrás de un socket muerto. Este es el orden para confirmarlo y arreglar solo la pieza que está mal.

El primer salto es este Mac, no el servidor

Lee la dirección al pie de la letra: 127.0.0.1 es la máquina que tienes delante, y el puerto es el que la herramienta de proxy tuviera configurado para escuchar. Cuando ese oyente desaparece, la conexión falla de inmediato con una conexión rechazada en lugar de un tiempo de espera, y esa es la pista útil.

Un VPN no crea sus propios ajustes de proxy ni elimina los del sistema. Las dos configuraciones son independientes, por eso el túnel puede ser perfecto y el navegador seguir inservible. Esa independencia también explica por qué el fallo sobrevive a una reconexión del VPN, a un reinicio y a un perfil nuevo. Nada en la ruta del VPN toca jamás el almacén de proxy.

Paso 1: lee el estado actual del proxy

Empieza por la vista de solo lectura, porque dice lo que cree el sistema antes de que lo interprete cualquier aplicación:

scutil --proxy

Mira HTTPEnable, HTTPProxy, HTTPPort, los equivalentes de HTTPS y cualquier ProxyAutoConfigEnable con su URL. Un proxy activado en un puerto donde nada escucha es tu fallo. Una URL PAC es la otra forma: el ajuste puede estar activo sin una dirección manual visible, porque el archivo elige el proxy en el momento de la petición.

Después confirma los mismos valores en Ajustes del Sistema, Red, el servicio que usas de verdad, Detalles, Proxies. La interfaz gráfica y el comando leen el mismo almacén, así que un desacuerdo significa que estás mirando otro servicio.

Paso 2: averigua quién es el dueño del ajuste

Tres dueños producen este estado: una herramienta de proxy que instaló un asistente y no lo limpió, un perfil de configuración gestionado de tu organización y un ajuste manual que alguien añadió mientras depuraba. Cada uno tiene una solución correcta distinta, y solo el primero es tuyo para quitarlo sin más.

Charles documenta su integración con el navegador y el proxy del sistema, incluido el asistente de macOS, así que usa primero sus propios controles y su ruta de apagado. El asistente privilegiado existe para cambiar la configuración; eso no es razón para dar a software no relacionado acceso amplio a la máquina.

Si el ajuste vino de un perfil gestionado, desactivarlo localmente o falla o se restaura en la siguiente comprobación. Trátalo como una cuestión de política para quien posee el perfil, no como un fallo local.

Paso 3: cambia lo más estrecho

Desactiva la entrada concreta no deseada del servicio concreto. No alternes todos los servicios ni borres todo el panel de proxy, porque el servicio del VPN y el servicio de Wi-Fi subyacente guardan ajustes separados y uno de ellos puede ser correcto.

Si el proxy es necesario a propósito, arranca su oyente aprobado en lugar de borrar la política. Esa distinción importa en organizaciones donde el proxy es la única ruta a internet y el VPN es un segundo camino, más estrecho.

Reintenta una petición nueva desde la aplicación afectada. Algunas aplicaciones leen el proxy una vez al arrancar, así que cerrarla y volver a abrirla es parte de la prueba y no una superstición.

Paso 4: si el proxy ya no está y sigue fallando

Entonces tienes otro problema, y el nuevo error es la evidencia útil. La resolución de nombres, el enrutamiento del VPN, la confianza TLS y la autorización de aplicaciones son cuatro comprobaciones separadas, y cada una produce un fallo distinguible.

Mantén la confianza en los certificados fuera de esta reparación. Quitar una raíz de confianza o debilitar la validación del servidor no arregla un socket de proxy muerto y te deja con dos cambios y un fallo original. Si un proxy corporativo inspecciona TLS, eso es un diseño deliberado con su propio requisito de confianza, no un efecto secundario que deshacer. Pregunta al equipo dueño del proxy antes de tocar un certificado, porque su respuesta será sobre política y la tuya sobre una petición fallida.

Escribe la reversión antes de empezar: anota los valores exactos de proxy que encontraste, para que restaurar sea copiar y no un ejercicio de memoria. La documentación de configuración del proxy Charles describe la integración y su comportamiento al apagarse para la versión que ejecutas.

La próxima vez que una aplicación falle con un VPN, comprueba el primer salto antes del túnel. Cuesta un comando y descarta toda una categoría de diagnóstico erróneo.