摘要

  • HTTP 511 表示客户端必须先满足接入网络的条件；它应由控制网络访问的拦截代理发出，而不是由请求所指向的源站发出。
  • 511 页面应链接到另一个登录资源，而不应在源站 URL 的语境里直接索取凭据。它能减少身份混淆，却不能让拦截变得可信，也不能绕过 TLS 的证书边界。

一次请求里出现了两个说话者

新接入一张网络时，应用仍会照常向熟悉的服务发送请求。问题在于，链路上的接入设备可能把这个请求截住，用自己的登录页替换源站响应。对人眼来说，这或许只是“先登录 Wi-Fi”；对同步程序、软件更新器或 API 客户端来说，收到的却是一段冒充业务结果的陌生内容。

真正的矛盾不在于页面是否好看，而在于谁有权回答。URL 指向一个源站，字节却来自接入网络。浏览器尚且可以把异常交给用户判断，无人值守的客户端则可能把 HTML 当成清单解析、缓存错误结果、反复重试，甚至跟随重定向继续执行原来的工作流。

2012 年发布的 RFC 6585 新增 511 Network Authentication Required，目的就是把这种中途干预说得更准确。它告诉客户端：当前缺少的是网络访问条件，不是目的应用返回了一个普通错误。规范同时限定了发言者——511 面向控制接入的拦截代理，不属于请求中的源站。

准入与源站认证是两套关系

“需要认证”很容易让人误以为密码总是交给正在访问的网站。实际上，源站可以要求用户登录某项应用；接入网络也可以要求付费、接受条款或完成登记。两者掌握的控制面不同，因而不能共享身份。

RFC 6585 明确说，源站不应生成 511。应用自身的身份验证和授权有既有的 HTTP 语义；511 表达的是路径施加的前置条件。它让客户端知道，修复网站账户大概率无济于事，也让网络不能因为拥有丢包能力就自动取得源站的名义。

这个状态码能作出的证明十分有限。它可以报告“此接入路径要求交互”，不能证明场所条款合理、门户运营者可信，更不能证明设备背后是哪一个自然人。把这些推论附加到 511 上，会重新扩大它本想收窄的权限。

为什么只能给链接，不能把登录框塞进响应

RFC 6585 建议 511 的表示内容给出一个链接，引导用户前往提交凭据或完成交互的资源；同时建议不要直接放置认证挑战或登录界面。

原因是浏览器会在用户原本请求的 URL 语境中展示响应。若酒店把密码框直接嵌进天气站的页面位置，普通读者很难分辨究竟是谁在索取秘密。认证挑战同样可能被理解为目的站发出的要求。

链接至少把下一步移到另一个明确命名的资源。它不是安全保证：客户端仍需展示实际主机名、验证 TLS 证书，门户也只能索取其有权处理的凭据。511 表达的是一次交接，而不是成功登录。原请求并未完成；用户处理接入条件后，还应重新向真正的源站发起请求。

非浏览器客户端让拦截的代价暴露出来

RFC 6585 把 511 称为对强制门户所造成损害的缓解措施，尤其考虑了非浏览器软件；它并未因此认可拦截。

软件更新程序期待清单由指定服务器控制，协作客户端期待 WebDAV 响应来自账户所属服务。用门户 HTML 替代这些内容，可能被解释成文件损坏、协议错误或业务状态。即便返回重定向，自动化程序也可能继续跟随，并把门户输出带入原有处理链。

HTTP 越多地成为其他协议的承载层，环境式替换的外部成本就越大。一条接入策略会穿过运营者并不了解的多个应用边界。独立状态码至少给健壮客户端一个暂停源站操作的理由，而不是盲目缓存、修改状态或持续重试。

缓存不能把短暂受限写成源站事实

511 响应不得被缓存。受限状态属于某一接入网络、某一设备会话和某一时刻。若缓存保存了它，用户通过认证后仍可能看见旧状态；设备换到另一张网络后，错误也可能继续存在。更糟的是，缓存会把接入网络的声明重新包装成源站内容。

只有当前执行准入的系统有资格给出新鲜判断。缓存并不拥有延续拦截的授权。

TLS 显示了状态码无法修补的身份替换

在明文 HTTP 上，中间设备可以替换响应并附上 511。HTTPS 则要求客户端先通过 TLS 验证服务器名。强制门户没有目的站的证书，因此无法诚实地完成握手；RFC 6585 指出，拦截 HTTPS 会导致证书错误。

这意味着 511 无法出现在一个门户本来就不能完成的可信 TLS 会话之后。若为了展示门户而压制证书警告，相当于把源站身份授予网络，正好违背了 511 要限制的混淆。

风险也不限于证书。中间设备可能看到明文认证材料，或干扰属于源站命名空间的 Cookie。规范强调，无论是否采用 511，强制门户都可能带来这些问题。更清楚的错误信息不能净化一条不安全的路径。

后来的设计把状态放回网络自己的名字下

RFC 8952 描述的强制门户架构把系统拆成若干角色：配置机制向用户设备提供 Captive Portal API 的地址，API 报告状态，用户门户负责交互，执行设备决定放行或阻断。RFC 8908 定义了基于 HTTPS 的接口交换。

发现方式因此改变。客户端不再必须向无关源站发送明文探针，再通过响应被篡改来猜测受限状态；它可以在加入网络时取得 API URI，验证 API 服务器证书，然后查询属于本设备的状态。接口返回必需的 captive 布尔值，并可在需要交互时提供 HTTPS 门户地址。

用户完成操作后，客户端再次查询，确认限制确实解除。一次表单提交或重定向成功不再自动等于网络已经放行。API 与执行系统还必须对同一台用户设备有一致的身份判断，否则“已登录”与“仍被阻断”会成为两个互不相干的事实。

这种架构没有让旧式门户瞬间消失，设备身份绑定也仍需谨慎。但网络的声明终于可以落在它有权运营的名称与信道上，天气站不必继续充当偶然的发现界面。

511 能承载的是一条很窄的真相

511 不能认证门户，不能赋予拦截合法性，不能击穿 TLS，也不能证明某个人同意了条款。它不是源站对 401 或 403 的替代。它的价值更克制：把准入要求的来源指向接入网络，并阻止这项要求被当作可复用的源站内容。

后来的 API 架构延续了同一个原则：权力应使用自己的身份说话。网络有权控制是否转发流量，却不应借目的站的声音来解释这种控制。

来源