逆向分析JavaScript浏览器聊天客户端：事件推送连接排查求助

1. 优先排查Server-Sent Events（SSE） #

• 打开浏览器DevTools的Network面板，切换到All或XHR/fetch分类，找类型为EventStream的请求——这类请求是HTTP长连接，会保持pending状态，服务端有事件时会持续推送数据，完全符合非轮询、非WebSocket的特征。
• 如果找到这类请求，查看请求头（比如Accept: text/event-stream）和响应内容，即可确认是SSE。

2. 检查是否使用隐藏iframe的Comet推送 #

• 打开DevTools的Elements面板，搜索iframe标签，重点看样式为display: none、visibility: hidden或者位置偏移到可视区域外的iframe。
• 查看这类iframe的src属性，再到Network面板找对应的请求——这类请求通常是长连接，服务端会通过往iframe写入HTML/JS内容的方式推送事件，客户端则监听iframe的onload或内容变化事件。

3. 用浏览器调试工具定位关键代码（无需全读混淆代码） #

• 启用XHR/Event断点：在DevTools的Sources面板左侧，找到XHR/fetch Breakpoints，勾选Any XHR或EventStream相关选项，当推送事件触发时，会自动断到对应的JS代码，查看调用栈就能找到处理推送的逻辑（哪怕代码混淆，也能通过调用栈逆向追踪）。
• 格式化混淆代码：在Sources面板中选中混淆的JS文件，点击右上角的{}按钮格式化代码，然后搜索EventSource、onmessage、addEventListener、iframe这些关键词，快速定位和推送相关的代码片段。
• 控制台全局搜索：直接在Console面板输入window.EventSource，如果返回构造函数，说明用了SSE；输入document.querySelectorAll('iframe')，查看是否有可疑的隐藏iframe。

4. 从浏览器存储找线索 #

• 打开DevTools的Application面板，检查Local Storage、Session Storage、IndexedDB中的数据，找和推送连接相关的token、会话ID或配置参数，这些信息可能会帮你直接定位推送请求的URL或验证逻辑。

5. 简单API禁用验证 #

• 在Console面板执行window.EventSource = null;，刷新页面后如果无法接收新消息，说明是SSE机制。
• 找到可疑的隐藏iframe后，直接在Elements面板删除它，或者在Network面板拦截它的请求，若推送失效，就能确认是iframe长连接方式。

内容的提问来源于stack exchange，提问作者Alvein