问题背景：

当我本地运行服务时莫名其妙报了cors错误

• 首先，我检查了响应标头是明确存在cors消息的
• 然后检查了请求端是否包含了额外头部，没有
• 然后对比了响应字段，都能对上

此时发现了一个神奇字段，请求表头中含有Access-Control-Request-Private-Network

Access-Control-Request-Private-Network: true

初步断定与该字段有关

问题解决：

资料参考：

• https://stackoverflow.com/questions/72385682/access-control-request-private-network-header-issues
• https://stackoverflow.com/questions/70292687/cors-for-private-networks-rfc1918-warning-on-call-to-local-service

参看stackof上的同类问题，我测试发现该问题确实目前只在chrome上出现。但是答案中加请求头的方案没有解决我的问题，我的请求依然不能正常发出

此时我找到了w3c关于该字段的描述：https://wicg.github.io/private-network-access/

本文档指定了对 Fetch 和 HTML 的修改，这些修改旨在减轻与客户端内部网络上的设备和服务器无意暴露给整个 Web 相关的风险。

根据这个描述，我猜测如果我的请求地址是以localhost开始的则不会发起预检请求，事实也确实如此。至此这个神奇的跨域消失了。变成了一个没有预检请求的普通请求。

内网请求时：

换成localhost后，预检请求消失：

问题总结：

目前看到产生该问题的场景都是内网之间测试时产生的
该字段用于防止用户代理无意中对运行在用户本地 Intranet 上的设备或直接在用户机器上运行的服务进行攻击。因此：

当其客户端是安全上下文并且对目标源的CORS 预检请求成功时，才允许私有网络请求。

可以解决的方案有：

• 更改chrome相关配置
• 不使用chrome
• 更改请求地址，使其避开这个问题

可参考：

• https://stackoverflow.com/questions/72385682/access-control-request-private-network-header-issues