A VPN Cannot Disable CORS, It Changes the Response

Start by separating two things that changed at once: the network path and the browser's enforcement. A VPN changes the exit address; it does not change the page's origin, which is built from scheme, host and port. If the request now succeeds, something in the response changed, or the request itself did. Working out which is the whole investigation.

CORS is a header protocol enforced by the browser, so nothing on the network path can switch it off.

Origin Is Not an IP Address

An origin is a scheme, a host and a port. It is not the address packets leave from, and it is not the IP the server sees. That is why a VPN can change every observable address and leave the origin identical. The browser compares the response's Access-Control-Allow-Origin against the page's origin, and the exit address never enters that comparison.

So an extension or a proxy that appears to fix a CORS error is doing something else: rewriting headers, or routing the request so it is no longer cross-origin. Neither is a property of the VPN.

What the Browser Actually Sends

For a cross-origin request that is not a simple one, the browser sends a preflight OPTIONS first, carrying the intended method and headers. The server must answer with the permissions it allows, and the real request follows only if that answer satisfies the rules. A VPN changes the path that carries both exchanges and can change what intermediate services answer. It does not change the origin string or the preflight requirement.

A command-line client usually shows none of that. It may not send an Origin header, it often skips the preflight, and it may carry different credentials. A body returned to curl proves that the server answered curl.

Find the Response That Changed

Compare the actual response through each path, not just the status code. Look at the headers carrying CORS permissions, the content type, any redirect, and whether a WAF or CDN variant produced a different page. A regional refusal, an authentication redirect or an error page lacking the permission header all fail in the browser while looking like a CORS bug. Those are delivery-path differences, and they are the thing to document.

Capture the response headers from both paths and compare them line by line. If the only difference is the missing Access-Control-Allow-Origin on one error page, you have found the cause.

Fix the Service, Not the Enforcement

When the service is yours, state the allowed origins and request features explicitly, then read the errors its frontend and intermediaries produce. If you do not, send the service owner a sanitised comparison. Never include cookies, authorization headers or session exports in that report, because those are the credentials the policy exists to protect.

Avoid browser extensions that disable CORS. They change the security boundary while hiding the response difference that needed explaining, and they leave the same failure in place for every other user.

Record both responses, the origin used and the path taken. That record turns a VPN rumour into a service bug.