Una VPN no puede desactivar CORS, cambia la respuesta
Una nueva dirección de salida no hace iguales dos orígenes. Captura las cabeceras de respuesta en ambas rutas y compáralas antes de culpar a la aplicación de CORS.
Empieza por separar dos cosas que cambiaron a la vez: la ruta de red y la aplicación del navegador. Una VPN cambia la dirección de salida; no cambia el origen de la página, que se compone de esquema, host y puerto. Si la petición ahora tiene éxito, algo de la respuesta ha cambiado, o la propia petición. Averiguar cuál de las dos es toda la investigación.
CORS es un protocolo de cabeceras que aplica el navegador, así que nada en la ruta de red puede desactivarlo.
El origen no es una dirección IP
Un origen es un esquema, un host y un puerto. No es la dirección desde la que salen los paquetes ni es la IP que ve el servidor. Por eso una VPN puede cambiar cada dirección observable y dejar el origen idéntico. El navegador compara el Access-Control-Allow-Origin de la respuesta con el origen de la página, y la dirección de salida nunca entra en esa comparación.
Así que una extensión o un proxy que parece arreglar un error de CORS hace otra cosa: reescribe cabeceras o enruta la petición para que deje de ser de otro origen. Ninguna de las dos es una propiedad de la VPN.
Lo que el navegador envía en realidad
Para una petición de otro origen que no es simple, el navegador envía primero una precomprobación OPTIONS con el método y las cabeceras previstos. El servidor debe responder con los permisos que permite, y la petición real solo sigue si esa respuesta cumple las reglas. Una VPN cambia la ruta que transporta ambos intercambios y puede cambiar lo que responden los servicios intermedios. No cambia la cadena de origen ni el requisito de precomprobación.
Un cliente de línea de comandos normalmente no muestra nada de eso. Puede no enviar la cabecera Origin, a menudo se salta la precomprobación y puede llevar credenciales distintas. Un cuerpo devuelto a curl demuestra que el servidor respondió a curl.
Encuentra la respuesta que cambió
Compara la respuesta real por cada ruta, no solo el código de estado. Mira las cabeceras que llevan permisos de CORS, el tipo de contenido, cualquier redirección y si una variante de WAF o CDN produjo una página distinta. Un rechazo regional, una redirección de autenticación o una página de error sin la cabecera de permiso fallan en el navegador aunque parezcan un error de CORS. Son diferencias de la ruta de entrega, y son lo que hay que documentar.
Captura las cabeceras de respuesta de ambas rutas y compáralas línea por línea. Si la única diferencia es la falta de Access-Control-Allow-Origin en una página de error, has encontrado la causa.
Arregla el servicio, no la aplicación
Cuando el servicio es tuyo, declara explícitamente los orígenes permitidos y las funciones de la petición, y luego lee los errores que producen su frontend y sus intermediarios. Si no lo haces, envía al propietario del servicio una comparación saneada. Nunca incluyas cookies, cabeceras de autorización ni exportaciones de sesión en ese informe, porque son las credenciales que la política existe para proteger.
Evita las extensiones del navegador que desactivan CORS. Cambian la frontera de seguridad mientras ocultan la diferencia de respuesta que había que explicar, y dejan el mismo fallo para todos los demás usuarios.
Registra ambas respuestas, el origen usado y la ruta seguida. Ese registro convierte un rumor sobre VPN en un error del servicio.