Chrome插件版Postman因安全策略限制无法发送Referer、Cookie等敏感Header，需配合Postman Interceptor扩展才能透传；桌面版无此限制，可自由设置所有标准Header。

Postman自定义Header被浏览器拦截的典型表现

Chrome插件版Postman在2018年后陆续出现Referer、Cookie、User-Agent等Header设置无效的问题，根本原因是Chrome逐步收紧了扩展程序对敏感请求头的修改权限。你填了Referer或Cookie，但服务端日志里收不到，或者响应返回403/400且明确提示“missing referer”或“invalid origin”，大概率就是这个原因。

• 不是Postman没发送，而是Chrome底层直接丢弃了这些字段
• 桌面版App（Electron构建）不受此限制，Header可自由设置
• 插件版即使显示Header已填写，实际发出的HTTP请求中可能根本不存在该字段

如何确认Header是否真的发出去了

不能只看Postman界面里的Headers选项卡——它只是编辑区，不等于实际发出的内容。最可靠的方式是用抓包工具交叉验证：

Postman 12.27.7

Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。

下载

• 启动Postman Console（View → Show Postman Console），发送请求后查看「Request Headers」面板，这里显示的是Postman最终组装并准备发出的头信息（注意：仍可能被Chrome拦截）
• 同时开启Fiddler或Charles，过滤对应域名，检查原始HTTP请求帧中的GET /xxx HTTP/1.1之后的真实Header行
• 如果Fiddler里看不到你填的Content-Type或Authorization，说明Postman根本没传，或被中间层（如Chrome Interceptor未启用）截断

插件版强行生效Header的唯一可行路径

必须配合Postman Interceptor扩展使用，否则纯插件模式下多数自定义Header注定失效。这不是配置问题，是Chrome安全策略的硬性限制。

• 先去Chrome商店安装Postman Interceptor，安装后点击浏览器右上角图标启用
• 在Postman插件界面右上角打开Interceptor开关（不是“Capture requests”那个按钮，是旁边带小盾牌图标的）
• Interceptor启用后，Postman会接管当前Chrome标签页的请求上下文，此时你手动填的Cookie、Referer等才能透传
• 注意：Interceptor只对当前激活的Chrome标签页生效，换标签需重新点一下拦截器开关

桌面版 vs 插件版的Header行为差异

桌面版（macOS/Windows/Linux App）和插件版在Header处理逻辑上本质不同：前者是独立HTTP客户端，后者是Chrome扩展，受制于chrome.webRequest API权限模型。

• 桌面版支持所有标准Header，包括Origin、Sec-Fetch-*系列（虽然后者通常不应手动设）
• 插件版即使开了Interceptor，也无法设置Host、Connection、Upgrade等被Chrome列为“不可覆盖”的请求头
• 如果你需要测试CORS预检（OPTIONS请求）、或调试Origin校验逻辑，必须用桌面版，插件版连发都发不出合法的预检请求

真正容易被忽略的点在于：**Header是否生效，和你是否“看到它被填上”完全无关**。很多用户反复检查拼写、大小写、空格，却没意识到自己正被困在Chrome插件的安全沙箱里——这时候换桌面版不是“升级”，而是绕过一道无法绕过的系统级限制。