微信网页版的兴衰对逆向的启示
微信网页版（wx.qq.com）曾是协议逆向的"黄埔军校"——完整的 web 协议、清晰的同步机制、相对宽松的风控。2017 年后逐步关闭（新号无法登录），但它的协议设计思想至今影响着 IM 逆向的方法论。本文回顾其协议架构，重点讲可迁移的通用知识。
网页版协议架构回顾
登录流程：
1. GET jslogin → 拿 uuid
2. 生成二维码（内容: https://login.weixin.qq.com/l/uuid）
3. GET login?uuid=xxx 轮询 → 200=确认，201=已扫码
4. 确认后跳转 webwxinit → 初始化，拿 SyncKey消息同步（长轮询设计）：
GET webwxsync?sid=xxx&synckey=xxx → 拉取消息
GET synccheck?synckey=xxx → 长轮询等待新消息（30秒超时）synccheck 是精髓：长轮询——请求挂起 30 秒，有新消息立即返回，没有则超时重发。用 HTTP 实现了接近长连接的实时性。
SyncKey 状态机：每次同步返回新的 SyncKey，下次请求带上——服务端据此判断"哪些消息你还没收"。这是增量同步的经典实现。
uos 头：最后的口子
网页版关闭后，社区发现 wx2.qq.com 配合特定 ua（uos 标识）一度还能登录：
User-Agent: Mozilla/5.0 (...) uos ← 在 ua 里加 uos 标识这个口子也已基本关闭。但它的启示价值在于：大厂的多端协议常有"遗留通道"——为了兼容老版本/小众平台（Linux web 端、车载端），会保留一些风控较松的入口。逆向时多试几个端（web/小程序/车机/手表），经常有惊喜。
可迁移的协议设计知识
1. 长轮询 vs WebSocket 的选型
微信网页版用长轮询而非 WS，原因：穿透性好（任何代理/防火墙都放行 HTTP）、实现简单、服务端无状态化容易。你的协议模拟如果对实时性要求不极致，长轮询比 WS 好维护得多。
2. SyncKey 增量同步模式
"客户端带状态标识，服务端返回增量"是消息类协议的通用模式。逆向任何 IM 协议时，先找它的"SyncKey 等价物"（offset、seq、cursor、since_id），搞清更新规则，消息拉取就通了。
3. 扫码登录的状态机
微信网页版把"等待扫码/已扫码/已确认/已过期"的状态机设计成了行业标准——现在各家的扫码登录（前文抖音/B站/快手/小红书）全是这个范式的变体。
微信逆向的现实路径
网页版关闭后，微信协议的现实路径：
- iPad/Mac 协议：社区有基于 iPad 协议的框架（需自行评估合规风险）
- hook 方案：PC 微信 hook（DLL 注入）或手机端 Xposed/Frida——合规边界内做自动化
- 企业微信 API：官方开放的合规通道，能走官方就别走逆向
总结
- 微信网页版虽已关闭，其协议设计（长轮询、SyncKey、扫码状态机）是行业标准范式
- uos 头的启示：大厂多端协议常有风控宽松的遗留通道
- 逆向 IM 先找 SyncKey 等价物，增量同步规则是钥匙
- 微信场景优先考虑官方通道（企业微信），逆向是最后手段
交流微信：run1255