一次代理 VIP 故障切换后还剩什么？
把代理入口的恢复与既有 CONNECT 隧道的存活、以及面向站点的出口地址区分开来。
浮动地址让代理设置保持稳定：活动机器故障后，客户端仍使用同一个主机名或 IP。这是有用的可用性。但已经在进行的下载仍可能中断。
设想一个已经进入 CONNECT 的 HTTPS 请求。活动代理持有面向客户端的 TCP 连接，以及通往站点的另一条连接。它还持有把这两条流拼接起来的应用状态。
把地址迁到备用机器，本身并不会搬走任何一个 TCP 控制块，也不会搬走那份中继状态。新的持有者可以接受新连接，却无法延续旧持有者建立起来的字节流。
| 期望 | 普通地址故障切换能满足吗？ |
|---|---|
| 保留一个已配置的入口 | 这正是它预期的收益 |
| 延续已建立的 CONNECT 流 | 需要额外的有状态机制 |
| 保持同一个对外公网 IP | 取决于出口路由与 NAT |
| 安全地重试被打断的应用操作 | 取决于该操作与客户端 |
VRRP 定义选举与地址归属，它并不是代理进程的复制协议。使用其他高可用软件的部署也需要同样的区分，除非它明确提供了更多能力。
审视健康检查究竟观察到什么。机器可能在代理服务、DNS 或上游路由已经故障时仍能应答通告。反过来，过于灵敏的检查会导致不必要的切换。
客户端侧的恢复同样重要。新的浏览器请求也许很容易重连；带已被消费的请求体的上传或非幂等的 API 操作，则可能需要应用层专门处理。不要仅因为新请求经备用机成功，就承诺不可见的故障切换。