VPN 无法关闭 CORS，它改变的是响应

先分清同时变化的两样东西：网络路径和浏览器的执行。VPN 会改变出口地址，却不改变页面的源；源由协议、主机和端口构成。如果请求现在成功了，那么响应里有东西变了，或者请求本身变了。弄清究竟是哪一种，就是全部调查工作。

CORS 是由浏览器执行的响应头协议，因此网络路径上没有任何东西能关掉它。

源不是 IP 地址

一个源由协议、主机和端口组成。它不是数据包发出的地址，也不是服务器看到的 IP。正因如此，VPN 可以改变每一个可观测的地址，而源保持不变。浏览器把响应中的Access-Control-Allow-Origin与页面的源做比较，出口地址从不进入这项比较。

所以，一个看似修复 CORS 错误的扩展或代理其实做了别的事：重写响应头，或者把请求改道，使它不再是跨源请求。这两者都不是 VPN 的属性。

浏览器实际发送的内容

对于非简单跨源请求，浏览器会先发送一个预检 OPTIONS，携带预期的方法和头。服务器必须以它允许的权限作答，只有该答复满足规则，真正的请求才会继续。VPN 改变承载这两次交互的路径，也可能改变中间服务的应答。它不改变源字符串，也不改变预检要求。

命令行客户端通常什么都不显示。它可能不发送 Origin 头，常常跳过预检，也可能携带不同的凭据。返回给 curl 的响应体只能证明服务器答复了 curl。

找出发生变化的那个响应

逐条路径比较真实响应，而不只是状态码。查看携带 CORS 权限的头、内容类型、任何重定向，以及 WAF 或 CDN 变体是否生成了不同的页面。区域拒绝、认证重定向或缺少权限头的错误页在浏览器里都表现为失败，看起来却像 CORS 缺陷。这些是分发路径的差异，正是需要记录的东西。

抓取两条路径的响应头，逐行比较。如果唯一的差别是某个错误页缺少Access-Control-Allow-Origin，你就找到了原因。

修服务，而不是修执行

服务属于你时，明确声明允许的源和请求特性，然后读它前端与中间层产生的错误。若不属于你，给服务方发一份脱敏的对比。报告里绝不要包含 Cookie、认证头或会话导出，因为政策存在的意义正是保护这些凭据。

避免使用禁用 CORS 的浏览器扩展。它们改变安全边界，同时掩盖了本应解释的响应差异，并让其他所有用户继续面对同样的失败。

记录两份响应、所用的源和走过的路径。这份记录能把关于 VPN 的传言变成服务缺陷。