首页加载成功不代表实时连接可用

页面文件、登录 API 与实时数据可能来自不同地址。WebSocket 在建立连接后交换消息；SSE 通常由服务器持续发送事件，标准 EventSource 有自己的重连行为。网站也可能使用 fetch 流或轮询，因此不要看到“实时”二字就先改 UDP 或节点传输协议。

  1. 记录站点、浏览器版本、时间、网络和代理模式，说明是一直没有更新，还是空闲或切网后停住。先确认账号仍登录，站点本身没有显示维护提示。
  2. 保存未提交内容，选择一个可重复且不会产生重要交易的观察动作，例如等待已有看板下一次正常刷新。不要重复点击付款、发布或发消息来测试。
  3. 本轮保持同一个页面、账号和预期事件，记录观察时间长度。没有新数据产生时，没有新消息可能是正常现象。

在 Network 中找到真正的连接

  1. 通过 Chrome 菜单“更多工具 → 开发者工具”打开 Network（网络），确认正在记录，清空旧记录后刷新页面并复现。需要跨页面保留时才勾选 Preserve log。
  2. 确认限速菜单是 No throttling，未启用 Offline。先看 WS 筛选；有连接时选择对应条目，在 Messages 中查看消息与时间。
  3. 没有 WS 记录时回到 All 或 Fetch/XHR，查看持续请求的 Headers。如果响应是 text/event-stream，或该请求提供 EventStream 标签，在其中查看事件；不要把所有长请求都称为 SSE。

标准 EventSource 默认会在连接断开后重试，但网站主动关闭、认证失败或其他实现可能改变结果。fetch 流并不因为内容类似就自动具备相同重连机制。请求一直处于 Pending 也不必然失败：持续流本来就可能长期不结束，应结合新数据和页面动作判断。

用实际阶段决定下一步

可观察的现象下一步
刷新后没有相关请求先核对筛选、触发动作和页面错误；不能据此判节点故障
连接未建立或出现明确 HTTP / 浏览器错误保留错误原文；区分会话、权限、解析和连接问题
有消息后关闭，随后反复建立连接记录间隔与发生条件，继续对照网络和代理路径
Messages / EventStream 有新数据，页面不更新向网站反馈前端现象，不把收到数据等同业务成功
仅返回页面后停住，刷新恢复记录返回导航触发条件，供网站排查连接生命周期

安全页面应使用安全 WebSocket（wss）。如果浏览器明确提示混合内容或安全限制，交给站点维护者核对，用户不应通过允许不安全内容来修复。开发者工具提供的关闭或错误信息只是线索，不能单凭一次断开认定运营商阻断。

做两轮可以比较的对照

  1. 先固定网络，只切换到已有可用的代理配置，重新加载并观察相同事件。若客户端能显示连接记录，核对实时连接域名是否命中与预期一致的规则，记录实际结果。
  2. 再固定客户端和配置，只换另一张自己可用的网络。保存前后失败阶段和观察时间，不同时修改 DNS、扩展、协议和账号。
  3. 若同一站点开了许多实时页面，先保存工作，只保留一个页面复测。MDN 说明 HTTP/1.x 下 SSE 同域连接数较低，但 HTTP/2 条件不同，不能把多标签一概判为故障原因。

只在一组条件下改善，可以缩小范围；它还不能证明是哪一层超时。跨网络都在相同业务动作后失败，更需要站点检查会话、接口或客户端行为。不要向 Console 粘贴陌生脚本，也不要复制带授权信息的请求去陌生在线测试站。

验收实时功能，并恢复临时设置

  1. 回到日常使用的配置，确认预期的新数据确实显示；在业务允许时观察一次短暂切网后的恢复，并注明有没有依靠手动刷新。
  2. 撤销本轮临时规则，恢复限速、离线模拟和 Preserve log 的原状态，停止无必要的持续记录。
  3. 求助时优先提供请求类型、脱敏域名、时间、错误和对照结果。确需 HAR 时使用清理敏感信息的导出选项，再人工检查 URL、正文和响应内容；不要公开完整聊天或账户数据。

最终记录应写清“连接已建立”“持续收到数据”“界面更新正常”分别是否验证。只能靠刷新临时恢复时就写临时恢复，保留原故障条件交给站点或客户端支持人员继续排查。