Postman中确认Authorization头是否发出，最可靠方法是点击Code按钮查看生成的cURL/HTTP原始请求，或开启Console并勾选“Show sensitive headers in console”；需注意Auth Tab配置优先级高于Headers Tab，且Inherit auth from parent要求父级（collection）已设认证。
Postman怎么确认Authorization头真的发出去了
Postman不会自动帮你发送Authorization头，除非你明确配置了——哪怕你在Headers Tab里手动写了Authorization，如果同时在Auth Tab里选了“无认证”，它就会忽略你手写的那一行。最稳妥的验证方式是看请求发出前的原始快照。
操作步骤：
- 打开请求，切到
Authorization选项卡，确认类型已选（如Bearer Token），且Token值非空 - 点击右上角
Code按钮（图标为{}），选择cURL (bash)或HTTP格式，直接查看生成的请求头是否含Authorization: Bearer ... - 若需更底层验证，开启Postman Console（
View → Show Postman Console），发送请求后筛选Request Headers部分，找authorization（注意小写）字段
Headers Tab里手动填Authorization和Auth Tab选Bearer的区别
两者不兼容，Postman会以Auth Tab为准，Headers Tab里同名项会被覆盖或静默丢弃。这是最容易踩的坑：你明明在Headers里写了Authorization，但Auth Tab选了No Auth，结果发出去根本没这个头。
关键差异：
-
Auth Tab：自动拼接、自动编码（如Basic认证会做Base64）、支持变量注入（如{{api_token}}），且能继承到子请求 -
Headers Tab：纯静态字符串，不处理编码，不参与认证流程管理，仅当Auth Tab设为No Auth时才生效 - JWT过期调试时，建议用Auth Tab + 环境变量，避免每次手动改Headers里的长token串
为什么Console里看不到Authorization头
Postman Console默认隐藏敏感头，包括Authorization、Cookie、X-Api-Key等。这不是没发，而是被刻意掩码了。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
解决办法：
- 在Console窗口右上角点齿轮图标 → 勾选
Show sensitive headers in console - 或者换用
Code生成器，它不做过滤，能100%反映实际发出的内容 - 如果仍为空，检查Auth Tab是否误选
Inherit auth from parent但父级没设认证
Auth Tab选Bearer但服务端收不到Authorization头
常见原因不是Postman没发，而是请求被中间层（如Nginx、API网关）剥离了。尤其当服务部署在反向代理后，某些配置会默认过滤掉Authorization头。
排查顺序：
- 先用
Code → cURL复制命令，在终端执行，确认服务端日志是否收到——排除Postman本身问题 - 检查代理配置：Nginx需显式添加
proxy_pass_request_headers on;和proxy_set_header Authorization $http_authorization; - 如果是Kubernetes Ingress，确认annotation是否含
nginx.ingress.kubernetes.io/configuration-snippet透传头
真正难定位的，往往不是Postman怎么配，而是那个没写进文档的代理规则。
