如何验证 WebSocket 代理连接中的消息顺序和完整性

验证 WebSocket 代理链路时，要分别检查消息顺序和内容完整性：用序号发现缺失、重复或乱序，再对还原后的完整消息比较长度和哈希。测试应使用合成消息，并先排除并发写入、多连接合并和重连重放等应用侧原因，再判断问题是否出在链路。

用消息序号和哈希验证 WebSocket 顺序与完整性

每条测试消息固定带五个字段：seq（连接内递增）、len（规范化后的字节数）、hash（sha256 前 16 位，属截断摘要）、conn_id、ts。接收端按 conn_id 分组还原序列；没有这五个字段，只能看到“收到/没收到”，判不出缺口、重复还是乱序。注意 seq 只在单条连接内单调，conn_id 也只标识连接生命周期，跨连接比较时不能直接拿两者的组合当全局顺序——重连补发场景需要额外的业务游标或服务端事件 ID。

seq： 用于判断缺口、重复、倒序；缺少该字段时，分不清丢消息与乱序。

len： 用于判断截断与合并；缺少该字段时，长消息被截断时看不出来。

hash： 用于判断内容被改写；缺少该字段时，长度相同、内容不同会漏判。

conn_id： 用于区分连接；缺少该字段时，多连接序号跳变被误判为丢包。

ts： 用于关联时间线；缺少该字段时，无法判断延迟与重放。

判断消息乱序是否由应用并发处理造成

单条 TCP 连接提供有序字节流，但 WebSocket 消息顺序仍取决于同一连接上的发送顺序；多连接聚合、并发写和重连补发，需要应用层序号才能验证。代理是否解析帧取决于实现，不能概括为所有代理都不拆帧。真正常见的是三种应用侧问题：并发写没有串行化，两个协程同时写导致帧交错；应用开了多条连接，却按全局顺序期待消息；断线重连后服务端补发与本地缓存叠加，旧消息晚到。

还有一个边界：如果启用了 permessage-deflate，压缩发生在帧层，解压后顺序才可比较，不要在压缩字节上算哈希。

确认 WebSocket 使用的代理协议及认证设置时，可参考代理设置帮助。

通过消息序号检查缺失、重复和顺序颠倒

先保留接收端的原始到达顺序和接收时刻，用到达索引判断倒序；再另建一份排序副本或集合，核对缺口与重复。排序会抹平乱序证据，不能一边排序一边检查。比如发送顺序是 1、2、3，接收顺序是 1、3、2：按到达序列能看出 3 早于 2（乱序），按排序副本看序号又齐全（无缺口），说明乱序不等于缺失，两者要分开记。

seq 跳号且无重复： 这通常表示消息丢失或未发出；下一步核对发送端日志与连接关闭时间。

同一 seq 出现两次： 这通常表示重投或补发重叠；下一步查重连补发区间与去重键。

seq 小的后到： 这通常表示乱序；下一步查并发写与多连接聚合顺序。

len 变短： 这通常表示截断；下一步查帧边界、压缩与缓冲区大小。

hash 不符但 len 相同： 这通常表示内容被改写或编码不一致；下一步比对规范化字节与字符编码。

按完整消息校验长度和哈希

一条消息可能拆成多个帧，也可能被压缩扩展合并传输；按帧比长度和哈希，会把正常分帧判成损坏。正确做法是在接收端先聚合完整消息，再算 len 和 hash，与发送端的值比对。

文本帧按 UTF-8 字节算，二进制帧按原始字节算，两边必须约定同一种。哈希范围要写清楚：只排除承载哈希本身的字段，两端对同一 message ID 的同一段字节做校验；时间戳、ID 这类需要完整性保护的内容要保留，否则“哈希一致”并不能证明内容没被改。跨样本比较时才需要语义规范化（例如去掉与业务无关的生成时间），那属于另一个测试，不能和校验混在一起说明。另外，16 位十六进制只是截断摘要，判重足够，不能称它是完整 SHA-256 校验。

验证 WebSocket 重连后的消息补发和完整性

检查补发消息是否连续、完整且没有重复

重连后服务端通常按 last_seq 补发，要验三件事：补发是否从断点开始、有没有补多、补发消息是否被去重。seq 连续说明没有漏，重复计数说明补多了，业务键说明去重是否生效。服务端不做补发时，客户端必须自己标记缺口，“顺序正确”只对重连后的新消息成立。判断“有没有补多”时，协议允许的重放要和去重后的副作用分开统计：原始重放出现重复是正常的，重复的业务效果才是不变量要盯的。为了让断开前后的消息能对齐，补发区间应带跨连接稳定的业务游标或服务端事件 ID，conn_id 单独用不足以跨连接做比较。

记录消息序号、哈希和补发结果

记录测试 ID 和时间窗、应用与客户端版本、连接标识和消息总数，以及缺口、重复、乱序数量与哈希一致率；测试数据使用合成消息。
验收按测试约定执行：在 N 条合成消息、指定重连窗口且无业务丢弃策略的前提下，预期缺口和重复为 0、哈希全匹配；报告里写明样本量、重连窗口和超时约定，不把它当作通用阈值。出现真实凭据、影响非测试用户或消息量超出预算时立即停止并恢复配置。

若连接问题需要进一步确认产品接入步骤，可从全球代理帮助中心查找对应文档。

消息帧与关闭码的一手定义见：

• RFC 6455《The WebSocket Protocol》

常见问题

测试时为什么必须固定请求与客户端版本？

序列化和压缩策略随版本变化，客户端一升级，字节和哈希就变了，基线和变更组不再可比。

什么时候应停止测试并回滚？

出现真实凭据、影响到非测试用户，或消息量、费用超过预设上限时立即停止，恢复配置后再排查。