401响应必须由服务端返回标准HTTP 401状态码及WWW-Authenticate头才能触发浏览器原生认证弹窗；返回HTML页面（如200+401.html）无效且导致状态错乱、SEO污染等问题。
401 响应不该由前端 HTML 页面“实现”
浏览器收到
响应时，会自动触发 HTTP 认证流程（如弹出 Basic Auth 对话框），此时返回 HTML 页面不仅无效，还会被忽略或导致行为异常。所谓“401 认证挑战页面”，实际是服务端未正确返回标准
状态码和
头，而是返回了
+ 自定义登录页——这根本不是 HTTP 认证，只是前端路由拦截或表单登录。
真正触发浏览器认证对话框的必要条件
必须同时满足以下三点，浏览器才会弹出原生认证框：
服务端返回 HTTP 状态码
（不能是
或
）
响应头中包含合法的
，例如：
请求是通过浏览器原生方式发起的（如直接访问 URL、
不带
时可能被 CORS 阻断）
用
可验证是否返回了正确的状态码和头；若看到
或缺失
，那所谓“401 页面”只是个假象。
为什么用 HTML 模拟 401 页面容易出问题
常见错误做法：Nginx 或后端返回
+ 一个叫
的静态页，并配
。这会导致：
立即学习
“
前端免费学习笔记（深入）
”；
使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
下载
浏览器收不到
状态码，不会触发任何认证逻辑
前端 JS 无法区分“真未授权”和“页面加载失败”，
捕获不到
如果用户已登录但 token 过期，服务端本应回
，却返回了登录页，造成状态错乱
搜索引擎可能将该页误判为有效内容，影响 SEO
该怎么做：按场景分清楚责任边界
如果你控制服务端：
需要标准 HTTP Basic/Digest 认证 → 服务端返回
+
，不返回 HTML
使用 JWT 或 Session 登录 → 服务端对未认证请求返回
，前端捕获后跳转到
（这是应用层逻辑，与 HTTP 认证无关）
想自定义未授权提示 → 返回
状态码 + JSON：
，前端渲染友好提示，而非塞 HTML
如果你只写前端：别试图“实现 401 页面”，重点检查
或
是否能正确收到
响应，并处理重定向或 token 刷新逻辑。
真正的难点从来不在 HTML 写得有多漂亮，而在于状态码、响应头、CORS 配置、credentials 模式这几处是否严丝合缝——漏掉任意一环，所谓的“认证挑战”就只是个静态摆设。
401 Unauthorized401WWW-Authenticate200 OK401200302WWW-AuthenticateWWW-Authenticate: Basic realm="Restricted"fetch()credentials: 'include'curl -I https://example.com/protected200WWW-Authenticate200401.htmlerror_page 401 /401.html401fetch().catch()401401401WWW-Authenticate401/login401{"error": "Unauthorized"}fetchaxios401