101 表示协议已切换
101 Switching Protocols 是对 Upgrade 请求的确认：客户端在请求里声明希望换成某个新协议，服务端同意后返回 101，从这一刻起这条 TCP 连接上的通信就按新协议进行，HTTP 不再解析内容。WebSocket 握手是它最典型的应用。切换完成后，双方都不再按 HTTP 的报文格式收发数据，这也是抓包分析时容易看错的地方。
基本信息
| 名称 | 101 Switching Protocols |
|---|---|
| 作用 | 确认协议升级，之后的连接按新协议通信 |
| 规范 | RFC 9110 第 15.2.2 节 |
| 请求侧要求 | 带 Upgrade 与 Connection 头声明目标协议 |
| 响应侧要求 | 回 101 并带上同名的 Upgrade 与 Connection 头 |
| 版本差异 | HTTP/1.1 用 101 升级；HTTP/2 通过扩展 CONNECT 实现，TLS 上的 h2 直接用 ALPN 协商 |
WebSocket 升级握手
WebSocket 升级握手
GET /chat HTTP/1.1 # 客户端发起升级请求
Host: wss.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols # 服务端同意升级
Upgrade: websocket
Connection: Upgrade
# 之后连接上传输的是 WebSocket 帧，不再是 HTTP 报文观察项与排障
| 观察项 | 含义 | 异常表现 |
|---|---|---|
| Upgrade 请求头 | 客户端要求的协议 | 缺失时服务端不会升级，按普通请求处理 |
| Connection 头 | 必须包含 Upgrade 标记 | 被代理剥离时升级失败，可能回落为普通响应 |
| 101 状态码 | 升级成功 | 返回 400 或 426 说明代理或服务端不支持升级 |
| Sec-WebSocket-Key | 握手校验用的随机值 | 服务端用它计算响应值，不匹配会被客户端断开 |
| 后续帧结构 | 不再符合 HTTP 报文格式 | 抓包工具若仍按 HTTP 解析会显示乱码 |
典型使用场景
- 实时通信：聊天、通知推送、行情与协作类应用建立长连接
- 反向代理配置验证：确认升级相关请求头是否被正确透传
- 排查重连风暴：连接被中间设备重置后客户端反复重连，需要看掉在哪一步
- 灰度发布验证：确认新版本网关对升级请求的处理是否一致
- 抓包分析：区分哪一段是 HTTP 握手、哪一段已经是新协议数据
Nginx 反向代理 WebSocket 时必须显式配置升级相关请求头，否则升级请求会被当作普通请求转发，表现为连接建立后立刻断开，或长时间等待后失败。
HTTP/2 不使用 101：明文场景靠升级或直接使用 h2c，加密场景通过 ALPN 在握手阶段直接协商出 h2，抓包看到的形态与 HTTP/1.1 的升级流程完全不同。