Go 内网管理接口为什么在 Chrome 142 打不开：Local Network Access、HTTPS 与 CORS 排查

设备控制台部署在 https://console.example.com，页面需要拉取局域网内某台设备的 http://192.168.10.7:8787/status。之前不少团队碰到这类问题，第一反应都是给Go服务补全CORS配置，结果升到Chrome 142之后，接口还是拿不到数据。打开浏览器网络面板看不到任何指向服务端的报错，页面反而反复提示用户确认本地网络访问权限。

碰到这类问题别死盯着Go接口找问题，实际排查的时候要把三个环节拆开捋：浏览器当前能不能发起指向本地网络的请求、当前页面是不是合法的安全上下文、Go服务有没有正确放行对应来源的跨域调用，三层里任意一层校验不通过，最终的表现都是内网管理接口打不开，拿不到返回数据。

Chrome 142 对本地网络访问的权限校验规则做了变更，公网页面访问内网IP、回环地址的请求不再只靠CORS规则放行，必须先经过用户手动授权本地网络访问权限，同时页面本身要处于HTTPS安全上下文状态，三层校验全部通过后Go服务配置的跨域规则才会生效。

先别加旧 PNA 响应头：现场究竟被哪一层挡住

打开浏览器开发者工具看到 OPTIONS，很容易联想到旧版的Private Network Access预检逻辑，直接就尝试添加 Access-Control-Allow-Private-Network。现在这个思路已经不能当成优先的修复方案：Chrome官方已经说明PNA的预检相关实验已经搁置，Local Network Access能力现在完全由用户手动授权的权限提示来控制。

先核对两边的地址关系。公网页面访问 192.168.x.x、10.x.x.x、172.16.x.x 这类本地地址，或者访问 localhost / 127.0.0.1，都会落到本地网络访问的覆盖范围内。Chrome 142的更新说明里已经明确这类能力需要走用户授权流程，同时要求发起请求的页面必须处于安全上下文状态。

所以排查的第一步不该上来就问“是不是CORS少配了头”，而是先确认三个点：页面是不是用HTTPS访问的，浏览器有没有弹出本地网络访问的授权提示，用户是不是已经同意了授权。如果页面本身跑在HTTP协议下，后面Go服务写的头部配置再完整，也绕不开安全上下文的硬性限制。

从前端做一次最小验证：把权限和接口错误分开看

先用手动触发的按钮发起请求，不要在页面刚加载的时候就静默调用接口。这样用户能把“需要访问本地设备”的授权提示和自己的操作对应上，也方便在控制台直接观察当前权限状态。针对明确的局域网IP地址，用下面的最小请求逻辑就可以完成验证：

async function readDeviceStatus() {
  const permission = await navigator.permissions.query({
    name: "local-network",
  });

  if (permission.state === "denied") {
    throw new Error("浏览器已拒绝本地网络访问");
  }

  const response = await fetch(
    "http://192.168.10.7:8787/status",
    { method: "GET", mode: "cors" },
  );

  return response.json();
}

如果浏览器本身不支持这项权限查询能力，不要直接把异常判定为服务端故障，可以提示用户升级到目标浏览器版本之后再检查页面的访问协议。针对那种“看起来是公网域名，解析之后实际指向本地地址”的特殊部署，支持该能力的浏览器还要求请求里明确配置 targetAddressSpace: "local"；不然HTTPS页面发起的HTTP资源请求会先被混合内容校验直接拦截。

这里拿到的结果分两种情况处理：权限被拒绝的场景，优先引导用户在浏览器的站点权限设置里重新开启本地网络访问；权限已经通过但 fetch() 依然报错，才进入Go服务的跨域规则和路由逻辑排查。给两类不同故障配不同的前端提示文案，客服和后续运维就不会再把两种完全不同的问题当成同一个故障处理。

Go 服务只做它该做的事：精确响应 CORS

Local Network Access权限校验通过之后，https://console.example.com 和 http://192.168.10.7:8787 依然是两个完全不同的跨域来源。这时候Go服务要正确处理 OPTIONS 和后续正式请求，允许的来源必须走白名单校验，不能为了省事直接返回 *。

package main

import (
  "encoding/json"
  "net/http"
)

const consoleOrigin = "https://console.example.com"

func statusHandler(w http.ResponseWriter, r *http.Request) {
  if r.Header.Get("Origin") != consoleOrigin {
    http.Error(w, "origin not allowed", http.StatusForbidden)
    return
  }

  h := w.Header()
  h.Set("Access-Control-Allow-Origin", consoleOrigin)
  h.Set("Access-Control-Allow-Methods", "GET, OPTIONS")
  h.Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
  h.Set("Vary", "Origin")

  if r.Method == http.MethodOptions {
    w.WriteHeader(http.StatusNoContent)
    return
  }

  if r.Method != http.MethodGet {
    http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
    return
  }

  w.Header().Set("Content-Type", "application/json")
  json.NewEncoder(w).Encode(map[string]string{
    "state": "ready",
  })
}

这段代码没有、也不应该尝试在服务端替用户点击浏览器的授权提示。它的职责很明确：校验请求的来源合法性，给预检请求和实际请求返回统一的CORS响应头，同时限制接口允许的请求方法。如果设备状态接口还附带控制操作能力，要额外叠加接口身份校验和设备侧的授权逻辑，不能把浏览器已经授予本地网络访问权限当成已经允许所有管理操作的依据。

有 iframe 时，再多检查一层 Permissions-Policy

设备控制台页面如果嵌套在其他站点的iframe里，顶层文档还可以通过 Permissions-Policy 限制子框架的本地网络访问能力。默认策略下不是所有第三方iframe都能直接使用这项能力。需要把权限委托给指定页面的时候，顶层页面可以显式声明允许的来源，同时iframe标签本身也要配置对应的 allow 属性：

Permissions-Policy: local-network=(self "https://console.example.com")

这时候别急着配置通配的允许来源，实际需要嵌入该页面的站点数量很少，明确写清允许的来源比直接把本地网络能力开放给所有iframe要稳妥很多。如果页面不需要嵌套在iframe里运行，没必要为了兜底在Go接口上额外加这类策略头，它属于页面文档层的配置，不是设备API的通用开关。

把排查顺序固定下来，避免来回改两端

最终留在服务端日志里的信息不用太复杂，记录请求来源、请求方法、访问路由、响应状态这几项就足够了。浏览器侧的权限授权结果还是交给前端记录和展示更合理。把“用户拒绝授权”“服务端拒绝请求来源”“接口本身不可用”三种状态明确区分开，排查问题的效率比盲目追加响应头要高很多。

延伸问答

给 Go 接口加 CORS 头后，为什么还是没有响应？

CORS规则只负责处理跨来源读取的逻辑。如果当前页面不是合法的安全上下文，或者用户直接拒绝了本地网络访问授权，请求甚至还没到达Go服务就已经被浏览器直接拦截了。

可以用 Access-Control-Allow-Origin: * 快速验证吗？

不建议在设备管理类接口上这么做。先固定好控制台的访问来源，遇到来源不匹配的请求直接打日志记录，后续再根据实际业务需求增加明确的允许来源；直接用通配符会大幅扩大本地设备接口被任意站点读取的风险范围。

旧的 Private Network Access 预检头还要保留吗？

新的修复方案不需要依赖它。Chrome已经把PNA预检相关的实验搁置，全面转向Local Network Access权限控制逻辑，以当前浏览器官方文档和目标浏览器的实际运行行为为准就可以，不要把早年的迁移文档当成永久生效的配置。

内网页面访问 localhost 也会受影响吗？

本地站点访问回环地址也属于本地网络访问的典型覆盖场景。按照浏览器的授权提示、页面访问协议和地址空间分类逐一测试就好，不要直接凭“都在公司内网里”的直觉直接判定不会受影响。

相关阅读

• Go errgroup 怎么收口并发错误：取消时机、结果保留和服务层取舍
• Go WaitGroup 为什么会卡住：Add、Done、Wait 的顺序与一次并发事故
• MCP 工具调用为什么返回 401 或 403：用 metadata、scope 和 audience 快速定位

核对资料

• Chrome 142 发布说明：本地网络请求的权限提示与安全上下文要求。
• MDN：Local network access：本地/回环地址、targetAddressSpace、权限查询和 Permissions-Policy 的边界。
• Chrome：Local Network Access 说明：PNA 预检实验搁置与 Local Network Access 的迁移背景。
• Go 官方 net/http 文档：Go 服务端路由与 HTTP 响应头处理接口。