Postman重定向时丢弃Authorization头是出于安全的默认行为；可关闭自动跳转手动处理，或用Pre-request Script补头，但需确认服务端是否真需重定向后认证。

Postman自动跳转时Authorization头被丢弃是默认行为

Postman 默认不会在重定向（301/302）后保留原始请求头，包括 Authorization、Cookie 等敏感字段。这是出于安全考虑的硬编码限制，不是配置错误或 Bug。

关闭“Automatically follow redirects”手动处理跳转

这是最直接可控的解决方式。重定向逻辑交给你自己判断，避免工具自动丢头：

• 进入 Settings → General，取消勾选 Automatically follow redirects
• 发送请求后，若响应状态码是 302 或 301，查看响应头中的 Location 字段
• 新建一个请求，方法设为重定向目标要求的类型（通常是 GET），URL 填 Location 值，并**手动复制原请求的所有必要 Header**（尤其是 Authorization）
• 某些 OAuth2 流程中，重定向后的 GET 请求仍需携带 Authorization: Bearer xxx，必须手动补上

用 Pre-request Script 在跳转后自动补 Authorization

如果你无法关闭自动跳转（比如集成测试流程强依赖），可用脚本在每次重定向发起前注入头：

Postman 12.27.7

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

下载

• 在集合（Collection）级别添加 Pre-request Script
• 写入以下逻辑（适用于 Bearer Token 场景）：

  if (pm.request.headers.has('Authorization') === false) {
    const token = pm.environment.get('jwt_token');
    if (token) {
      pm.request.headers.add({key: 'Authorization', value: 'Bearer ' + token});
    }
  }

• 注意：该脚本只对当前请求生效，且无法恢复已被丢弃的原始头；它是在重定向新请求发出前“重新加一次”，依赖环境变量存在
• 不适用于 Basic Auth 等需动态计算的认证方式，因为重定向请求无法读取上一跳的原始凭据

检查服务端是否真需要重定向后带认证头

很多开发者默认认为“跳转后也要鉴权”，但实际协议和业务逻辑未必如此：

• 标准 OAuth2 授权码流程中，/authorize 重定向到 /callback 是**无认证的 GET 请求**，靠的是 code 换 token，而非携带原 token
• 某些 SSO 登录跳转链中，认证态通过 Set-Cookie 维持，Header 中的 Authorization 本就不该出现
• 用 Chrome DevTools 的 Network 面板对比真实浏览器行为：看浏览器跳转后是否真的发了带 Authorization 的请求——如果浏览器也没发，那 Postman 不发就是对的

真正容易被忽略的是：重定向目标 URL 是否本身就需要独立认证（比如跳转到另一个 API 域），而不是“继承”上一跳的头。这种情况下，应该单独配置目标请求的认证，而非试图恢复丢失的头。