专题归档 · 2026 年 6 月（编辑分组，非实际写作日期）

Sub-Store 管理后台一直弹登录框：从 Basic Auth 改用 Access 的一轮排查

前端页面通过认证后，API 请求却再次收到 401；从浏览器行为梳理管理面与公开订阅入口的边界。

主页面能过验证，紧接着又要求输密码

历史部署记录里，给自托管 Sub-Store 管理入口加上反向代理的 Basic Auth 后，浏览器开始反复弹出原生登录对话框。看上去像密码输错，但现象更像是：HTML 页面认证通过了，页面脚本随后发起的 API 请求却拿到 401。

仅看页面成功不能判断整个应用的认证都成功。前端和 API 请求的地址、缓存的认证信息以及代理规则，都可能影响浏览器是否按预期带上凭据。

当时记录选择撤掉管理入口上的代理 Basic Auth，改由 Cloudflare Access 管理会话。它使用基于会话的认证机制，减轻了原有全路径 Basic Auth 与动态 API 请求之间的不匹配。

另一个值得留下的设计点是：管理后台入口与客户端稳定读取的分享入口不应共用可轮换的管理路径。否则服务搬迁或调整安全前缀，客户端订阅也会跟着失效。

排查认证循环时，最重要的是区分 Cloudflare Access、反向代理和 Sub-Store 各自的鉴权逻辑，确认到底是哪一层在重复返回认证挑战，而不是一遍遍输入密码。

不同浏览器、域名和凭据缓存条件下，fetch 的请求头可能不同。排查时要直接检查对应请求，不要根据某一次抓包结果推断所有客户端的行为。