Postman 的 Digest Auth 必须先获取服务端返回的 WWW-Authenticate 头（含 realm、nonce、qop 等），再手动填入高级配置，否则因缺少动态挑战参数而必然 401；它不自动预检，也不缓存 nonce，每次 nonce 失效都需重新提取。
Postman 的 Digest Auth 不是“填完用户名密码就完事”的类型，它依赖服务端返回的挑战（WWW-Authenticate 头）动态生成认证参数；如果手动填错 realm、nonce 或漏掉 qop，请求必然 401 —— 这不是 Postman 的 bug，而是协议本身要求客户端必须响应服务端给出的挑战。
为什么 Digest Auth 在 Postman 里总返回 401？
根本原因：Postman 的 Digest Auth 类型 **不自动发起预检请求获取 WWW-Authenticate 头**。它假设你已从首次 401 响应中手动提取了 realm、nonce、qop、algorithm、opaque 等字段，并准确填入高级配置。常见错误包括：
-
realm值多一个空格或大小写不一致（如服务器发的是"Users"，你填成"users"） -
nonce被复制时带了换行或引号（应为纯字符串，如ni1LiL0O37PRRhofWdCLmwFsnEtH1lew） - 漏填
qop，或填了服务端未声明的值（如服务端只支持auth，你填了auth,auth-int） -
algorithm写成MD5-sess却没同步提供cnonce和nc（Postman 不自动生成这些，需手动补）
Postman 中 Digest Auth 的正确配置步骤
必须分两步走：先触发 401 获取挑战头，再回填参数重发。不能跳过第一步直接填。
- 用
No Auth发一次请求（比如访问https://postman-echo.com/digest-auth），看响应状态码是否为401 - 点开响应的
Headers标签页，找到WWW-Authenticate字段，复制整段值（例如：Digest realm="Users", nonce="ni1LiL0O37PRRhofWdCLmwFsnEtH1lew", algorithm=MD5, qop="auth"） - 切回请求的
Authorization选项卡，Type改为Digest Auth - 在
Username/Password栏填凭证（如postman/password） - 点
Advanced展开，按WWW-Authenticate中的实际值逐项填写：Realm、Nonce、Algorithm、Qop（注意去掉引号）、Opaque（如有） - 点击
Send—— 此时 Postman 才会基于这些值 + 请求方法 + URI 计算response并构造完整Authorization头
什么时候必须手动补充 cnonce 和 nc？
当服务端返回的 WWW-Authenticate 头中包含 qop="auth" 或 qop="auth-int" 时，cnonce 和 nc 就是强制项。Postman 的 UI 默认不暴露这两个字段，但你可以：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 在
Advanced区域勾选Include cnonce and nc（部分 Postman 版本有此开关） - 若无该选项，改用
Bearer Token或API Key类型，手动在Headers里加Authorization: Digest ...全量头（把cnonce设为随机 hex 字符串，nc设为00000001） - 更稳妥的做法：用环境变量存
{{digest_realm}}、{{digest_nonce}}等，避免每次重填
Digest Auth 和 Basic Auth 的关键区别在哪？
不只是“加密 vs 明文”的问题，而是协议交互模型完全不同：
-
Basic Auth：Postman 直接拼base64(username:password)，塞进Authorization: Basic ...头，一发即中 -
Digest Auth：必须先收到服务端的nonce（一次性随机数）才能计算哈希，且每次nonce失效后需重新挑战 —— 这意味着你无法在集合里长期复用同一组 Digest 参数 - Postman 不缓存
nonce，也不自动重试；如果服务端轮换nonce，你得手动抓新头、更新配置，否则持续 401
真正容易被忽略的是：Digest 认证的生命周期绑定服务端状态，不是客户端配对就永久有效。调试时别盯着 Postman 配置找问题，先确认 WWW-Authenticate 头有没有变。
