如果浏览器开发者工具的网络面板能看到某个自定义响应头，而页面脚本用 fetch 或 XHR 读取却得到 null 或读不到，先不要认定这个头没有发送，也不要直接归因于网卡故障。适用条件是：请求属于浏览器跨源访问，响应本身可按 CORS 读取，脚本又试图读取响应头。此时浏览器默认只向脚本暴露 CORS 安全响应头；不在安全列表里的普通自定义响应头，需要服务端在 Access-Control-Expose-Headers 中明确列出头名。网络面板展示的是浏览器接收和解析到的响应信息，脚本能否读取还受响应头暴露规则限制，两者不是同一件事。同源请求属于另一种情况，应另行核对，不能把跨源结论直接套用。
观察时，先把请求 URL、页面来源、请求方法、是否携带凭据、响应状态、Access-Control-Allow-Origin、Access-Control-Expose-Headers 的实际值，以及脚本读取响应头的代码位置记录下来。判断可以分叉：如果跨源且响应可读，而 Expose-Headers 没有列出目标头名，脚本读不到属于预期结果；如果已经列出，仍要核对列名是否与实际响应头一致、响应是否真的可按 CORS 读取，以及读取代码是否在正确的响应对象上执行。带凭据时尤其要注意，Access-Control-Expose-Headers 里的星号只是字面头名，不是通配符，不表示允许脚本读取所有敏感头或禁止暴露的头；需要读取哪个普通自定义头，就按实际名称明确列出，不能把星号当成泛允许。
风险在于，把脚本读到 null 直接当成“头没发送”或“网卡故障”，容易误导排查方向：有人可能去改共享网关、关闭浏览器安全设置，甚至跨源发送口令来“验证”，这些做法会扩大暴露面，也不能证明问题已经解决。面板可见只说明浏览器侧能看到该响应头，不说明页面脚本有权限读取。下一步应保留去敏后的请求响应与 fetch 上下文，交给能同时查看前端读取代码和服务端响应头配置的人员核对；提交前去掉 cookie、token、口令和用户数据，只保留判断所需的头名、来源、凭据使用情况和状态信息。
涪城区台式电脑用户可拨400-877-9605，先整理去敏来源、凭据使用情况、目标响应头和fetch上下文。电脑快修网提供信息展示与第三方维修对接，具体地址、电脑侧检查是否支持及安排需当次核实，启用范围不代表即时履约。