Basic Auth请求头未被后端识别，主因是中间件/网关（如API Gateway、Nginx、CloudFront）过滤、改名或剥离该头；Postman中手动添加与自动填充Authorization头冲突也会导致失效；Spring Security下POST持续401实为CSRF拦截而非认证失败；关键应查Postman Console与服务端日志比对headers，验证WWW-Authenticate响应头以确认真实认证方式。
Basic Auth 请求头没被后端识别到
Postman 选了 Basic Auth 类型、填了用户名密码，但服务端日志里压根没收到 Authorization 头——这通常不是 Postman 没发，而是中间件/网关/反向代理把它过滤或改名了。
常见原因包括：
- API Gateway（如 AWS API Gateway、Cloudflare）默认不透传
Authorization头，需显式配置允许转发； - Nginx 配置中用了
underscores_in_headers on;或大小写重写规则，导致Authorization被转成authorization或丢弃； - Spring Security + CloudFront 场景下，Lambda 接收的事件里
headers.Authorization实际是headers.authorization（小写），而鉴权中间件硬编码读headers.authorization就会失败； - 某些内网代理强制剥离认证头，尤其在企业办公网络中很常见。
验证方法：打开 Postman Console（View → Show Postman Console），发一次请求，看「Request Headers」区域是否真实存在 Authorization: Basic xxx；再对比服务端 access log 或调试日志里收到的 headers 字段，确认字段名和值是否一致。
Basic Auth 的 Base64 编码被手动干扰
别手动生成 Base64 字符串填进 Header——这是最常踩的坑。Postman 的 Basic Auth 类型会自动把 username:password 拼接后做 Base64 编码，并塞进 Authorization 头。如果你手动在 Headers 标签页加了一行 Authorization: Basic xxx，又同时在 Authorization 标签页也选了 Basic Auth，Postman 会发两个冲突的 Authorization 头（部分 HTTP 客户端只取第一个，部分直接拒收）。
正确做法只有这一种：
- 删掉 Headers 标签页里所有手动写的
Authorization行； - 只在 Authorization 标签页选
Basic Auth，填username和password； - 点「Preview Request」，确认生成的值形如
Basic dXNlcjpwYXNzd29yZA==，且没有多余空格或换行。
注意：password 中含冒号 :、@、/ 等特殊字符时，Postman 会自动 URL encode，但 Base64 编码本身不处理这些——所以只要别手动生成，就不用管编码细节。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
Spring Security 下 POST 请求 401 不是认证问题，是 CSRF 拦截
GET 请求能过 Basic Auth，POST 却持续 401？这不是认证失败，而是 Spring Security 默认开启 CSRF 防护，对非 GET/HEAD/OPTIONS/TRACE 请求要求携带有效 X-CSRF-TOKEN。Basic Auth 只解决身份识别，不提供 CSRF Token。
临时验证方式：
- 在 Postman 的 Authorization 标签页设好 Basic Auth；
- 再切到 Headers 标签页，手动加一行：
X-CSRF-TOKEN→ 值填dummy（随便一个字符串）； - 如果此时 POST 成功，说明就是 CSRF 拦截；
- 若仍失败，再回头查 Basic Auth 配置。
正式环境不要关 CSRF（.csrf().disable()），应走标准流程：先用登录接口获取 XSRF-TOKEN（从响应 Cookie 中提取），再在后续请求 Header 中带上它。
服务端实际期望的是其他认证方式，而非 Basic Auth
你以为对方要 Basic Auth，其实接口文档写的是 X-Api-Key，或 Swagger 示例里用的是 Bearer token，甚至后端代码里硬编码校验的是 X-Auth-Token。401 错误本身不承诺“你填错了”，只表示“我认不出你给的东西”。
关键线索藏在响应头里：
- 看返回的
WWW-Authenticate头，例如WWW-Authenticate: Bearer realm="api.example.com"，说明后端明确要求 Bearer 方案； - 检查接口文档中「Authentication」章节，确认是否写了 “Use
X-API-Keyheader” 或类似说明； - 用 curl 对比测试：
curl -H "X-API-Key: abc123" https://api.example.com/xxx，如果成功，那 Postman 就不该用 Basic Auth 标签页。
别依赖“别人说用 Basic Auth”这种二手信息——直接抓包看服务端真正认什么头、什么值格式。很多团队把 Basic Auth 当占位符写进文档，实际早切到 JWT 或 API Key 了。
