Digest认证在现代Apache上大概率不生效，因HTTP/2下浏览器强制忽略WWW-Authenticate: Digest（RFC 7540规定），且AuthDigestDomain配置错误会导致401循环、nonce劫持等安全风险；真正可行的是改用HTTPS+bcrypt密码+JWT或会话式认证。
不能直接用 mod_auth_digest 替换 mod_auth_basic 就变安全了——它在 HTTP/2 下会被浏览器静默禁用，且配置稍有偏差（比如 AuthDigestDomain 写错）就会反复弹窗、认证失败。
为什么 Digest 认证在现代 Apache 上大概率不生效
Chrome、Firefox、Safari 在收到 HTTP/2 连接的 WWW-Authenticate: Digest 响应头时，会直接忽略并 fallback 到未授权状态，不触发任何客户端计算。这不是 bug，是 RFC 7540 的强制规定。哪怕你看到 401 响应头里确实写了 Digest，只要走的是 HTTP/2，整个流程就卡死。
- 检查是否真在用 HTTP/1.1：用
curl -v https://yoursite.com/protected/看响应头第一行是否为HTTP/1.1 401 - 临时降级测试：在虚拟主机配置中加
Protocols http/1.1，重启 Apache 后再试 - 生产环境别长期禁用 HTTP/2——性能代价太大；这说明
mod_auth_digest已不适合做主力认证方案
AuthDigestDomain 配置错误是最常见的 401 循环原因
AuthDigestDomain 不是“保护路径”，而是告诉浏览器：“这个 realm 下的所有请求，都允许复用同一个 nonce”。如果它和实际请求的 Host 或 URI 不严格匹配，浏览器就会拒绝重用 digest，导致每次请求都重新挑战。
- 若站点访问地址是
https://admin.example.com/settings/，AuthDigestDomain必须写成https://admin.example.com/或/settings/，不能只写/或example.com - 多个子路径需分别保护？不要用
AuthDigestDomain "/"覆盖全站——这是高危操作，攻击者可诱导用户访问/api/.well-known/xxx劫持 nonce 并重放到/admin/ - 正确做法：对每个敏感路径单独写
AuthDigestDomain "/admin/"和AuthDigestNonceLifetime 300
密码文件生成和 realm 名必须一字不差
htdigest 生成的 .htdigest 文件里，每行格式是 username:realm:hashed_password。Apache 校验时，会把请求头里的 realm 字符串原样比对——多一个空格、大小写不一致、引号没去掉，全失败。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 生成命令必须用：
htdigest -c /path/to/.htdigest "Restricted Area" username，注意双引号包裹 realm - 配置中
AuthName "Restricted Area"的字符串必须和上面完全一致，包括空格和标点 - 不要混用
AuthUserFile（Basic 用）和AuthUserFile（Digest 用）——Digest 只认.htdigest，且必须由htdigest工具生成，htpasswd生成的无效
真正能落地的替代方案不是调参数，而是绕开 Digest
与其花时间调试 mod_auth_digest 兼容性问题，不如直接切换到更可控、更现代的组合：
- 管理后台：用
mod_authn_core+AuthUserFile（配合htpasswd -B生成 bcrypt 密码）+ 强制 HTTPS，比 MD5 digest 抗爆破能力强得多 - API 接口：彻底弃用浏览器原生认证，改用 JWT 或短期 bearer token，由前端在
Authorization: Bearer xxx中携带，后端用mod_lua或 Nginx 校验 - 表单登录：用
mod_session+mod_auth_form实现带 CSRF Token 的会话，而不是依赖客户端算 digest
最常被忽略的一点：即使你把所有配置都写对了，只要客户端走的是 HTTP/2，mod_auth_digest 就只是个摆设——它不是配置问题，是协议层的硬性限制。
