NAS 内网域名访问为什么需要浏览器授权

在企业内网中，经常会把 NAS 文件服务配置成一个内网域名，例如：

text 复制代码

nas.internal.example → 192.168.x.x

业务系统通过 HTTPS 页面访问这个域名时，新版 Chromium 浏览器可能弹出"允许访问本地网络"的授权提示。这不是 NAS 登录权限，而是浏览器的 Local Network Access（LNA，本地网络访问） 安全机制。

为什么需要授权

公网网页如果可以静默访问用户内网，就可能扫描路由器、打印机或 NAS。浏览器因此会拦截从公网地址空间访问内网地址空间的请求，只有用户明确允许后才放行。

常见现象包括：

text 复制代码

Failed to fetch
ERR_FAILED
ERR_CONNECTION_CLOSED

页面也可能自动回退到服务器中转，而不是使用 NAS 直连。

前端如何触发授权

可以通过一次轻量的 HEAD 请求探测 NAS：

ts 复制代码

await fetch("https://nas.internal.example:18443/healthz", {
  method: "HEAD",
  mode: "no-cors",
  cache: "no-store",
});

建议页面加载时自动探测；失败后保留"重新授权"按钮，让用户通过点击再次发起请求。授权过程不要只设置几秒超时，应给用户留出处理弹窗的时间，例如 30 秒。

对于 HTTPS NAS 地址，不建议强制添加 targetAddressSpace: "local"。部分代理链路会把目标识别为 unknown，从而出现地址空间不匹配。该参数更适合 HTTPS 页面访问 HTTP 内网地址时使用。

NAS 网关需要配合

NAS 前置网关应正确处理 HEAD、OPTIONS 请求，并只允许可信业务域名跨域访问：

nginx 复制代码

add_header Access-Control-Allow-Origin "https://app.example.com" always;
add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS" always;
add_header Access-Control-Allow-Private-Network "true" always;

生产环境建议使用可信 HTTPS 证书，避免证书错误与浏览器授权问题混在一起。

代理软件是高频原因

如果关闭代理后可以正常弹窗并直连，说明代理接管了内网 DNS 或 HTTPS 连接。无需长期关闭代理，只需增加直连规则：

yaml 复制代码

rules:
  - DOMAIN,nas.internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

使用 Fake-IP 或 TUN 模式时，还应将 NAS 域名加入 Fake-IP 排除列表，并确保它通过公司内网 DNS 解析。

排查顺序

nslookup 确认域名解析到正确的内网 IP。
检查 NAS HTTPS 端口是否可达。
直接访问 /healthz，确认返回 200 或 204。
检查浏览器站点权限中的"本地网络访问"。
暂停代理测试；成功后配置域名和内网网段直连。

总结

NAS 直连是否成功，不只取决于前端代码，还取决于浏览器授权、内网 DNS、HTTPS 证书和代理规则。正确做法是：页面主动探测、失败后允许用户重试、NAS 网关正确响应，并让代理绕过内网域名。

本文中的域名、IP、端口和业务名称均为脱敏示例，请按实际环境替换。