办公网内仅现CORS报错：未知地址空间权限被拒（疑Chrome PNA拦截）

环境配置 #

• 前端：公网域名（HTTPS协议）
• 后端API #1：公网API域名→反向代理至内部服务器
• 后端API #2：另一公网API域名→反向代理至FastAPI后端

两个API在外部网络均返回正确CORS响应头：

Access-Control-Allow-Origin: *

正常场景 #

• 家庭/移动热点/外部网络：所有API调用均成功
• 所有CORS响应头配置符合要求

办公网内异常场景 #

前端在办公网内调用任一API时，Chrome浏览器报错：

Access to XMLHttpRequest has been blocked by CORS policy:
Permission was denied for this request to access the `unknown` address space.

所有API端点均出现该问题。

排查发现 #

办公网内DNS将API域名解析为内部私有IP，但前端仍从公网域名加载，形成：

Public-origin → Private-IP request

该模式触发了Chrome的Private Network Access (PNA) 限制。

浏览器差异表现 #

• Chrome：预检请求前直接拦截（PNA限制），抛出上述报错
• Firefox：不拦截PNA，请求正常发送，但后端返回：

CORS header missing (Status code: 413)

此为预期情况，因后端在添加CORS头前已拒绝大载荷请求。

核心疑问与解答 #

1. Chrome是否因Private Network Access (PNA)限制拦截请求？ #

是。Chrome从版本94开始严格执行PNA规则，禁止公网源（HTTPS公网域名）直接请求私有IP地址的资源，这是为了防范跨源请求伪造到内部网络的风险，你的场景完全符合触发条件。

2. 是否存在服务端配置允许该访问模式？ #

有两种服务端配置方式可以适配：

• 添加PNA响应头：在API服务端返回Access-Control-Allow-Private-Network: true头，同时需要配合Access-Control-Allow-Origin指定具体的前端公网域名（不能用*），因为PNA规则要求Allow-Origin不能是通配符。
• 启用PNA预检请求支持：如果是复杂请求（如带自定义头、POST非表单格式），服务端需要正确响应OPTIONS预检请求，返回上述PNA相关头。

但注意：这种配置会降低内部网络的安全性，仅建议在办公网可信环境下使用。

3. 移除内网DNS解析覆盖是否为唯一可靠修复方案？ #

不是唯一方案，但是最安全、最无副作用的方案。移除内网DNS对API域名的私有IP解析，让办公网内也通过公网IP访问API，完全规避PNA限制，同时保持内外网访问逻辑一致。

4. 将所有API调用通过反向代理内网路由（使浏览器始终访问公网端点）能否规避PNA问题？ #

可以。如果办公网内搭建反向代理，让前端请求的公网API域名被代理到内部私有IP，但浏览器看到的始终是公网域名（而非私有IP），就不会触发PNA限制。本质是让浏览器端的请求目标始终是公网域名，内部路由由代理完成。

5. 针对公网域名仅在特定网络解析为内网IP的场景，有何推荐方案？ #

推荐按优先级选择：

1. 保留公网解析（优先）：移除办公网DNS对API域名的私有IP解析，统一走公网路由，内外网访问逻辑一致，无额外配置成本。
2. 内网反向代理：在办公网内部署反向代理，将公网API域名的请求转发到内部私有IP，浏览器端始终请求公网域名，规避PNA。
3. 适配PNA规则：修改API服务端配置，添加Access-Control-Allow-Private-Network: true，同时将Access-Control-Allow-Origin设为前端公网域名（而非*），适合无法修改DNS或路由的场景，但需评估安全风险。
4. Split DNS优化：调整办公网Split DNS规则，仅让内部服务（而非前端浏览器）解析API域名为私有IP，前端仍解析为公网IP，实现内外网路由分离。

总结 #

• 外部网络下API调用全部正常
• 仅在办公网内（API域名被解析为私有IP）出现API调用失败
• Chrome因PNA限制抛出“未知地址空间”拦截报错

内容的提问来源于stack exchange，提问作者harsha datta