heroku 中 websocket 连接正常关闭时触发的 h15（idle connection）日志仅为路由层“伪告警”，并非真实错误；其本质是 router 对长期挂起连接的超时统计机制所致，不影响功能，但需正确认知以避免误判。
heroku 中 websocket 连接正常关闭时触发的 h15（idle connection）日志仅为路由层“伪告警”，并非真实错误；其本质是 router 对长期挂起连接的超时统计机制所致，不影响功能，但需正确认知以避免误判。
在 Heroku 上部署 Go（或其他语言）编写的 WebSocket 服务时，开发者常在日志中观察到类似以下的 H15 报错：
heroku[router]: at=error code=H15 desc="Idle connection" method=GET path="/ws" host=your-app.herokuapp.com request_id=abc123 dyno=web.1 connect=1ms service=300000ms status=503 bytes=147
乍看之下，service=300000ms（即 5 分钟）和 status=503 容易被误解为服务响应超时或崩溃。但事实恰恰相反：该连接极大概率是健康运行了 5 分钟后由客户端主动、优雅关闭的——H15 日志在此场景下是 Heroku Router 的固有行为，而非应用缺陷。
? 根本原因：Router 的连接状态建模局限
Heroku Router 本质上是一个 HTTP 反向代理，它不理解 WebSocket 协议语义，仅将整个升级后的连接视为一个“长生命周期的 HTTP 请求”。其超时逻辑严格遵循 55 秒空闲检测机制：
- 当客户端通过 Upgrade: websocket 完成协议切换后，Router 将该 TCP 连接标记为“挂起（pending）”；
- 此后，只要客户端或服务端持续发送心跳帧（如 ping/pong），Router 每次收到数据包便会重置内部空闲计时器；
- 但当连接最终关闭时，Router 并不会区分“主动断开”与“真正卡死”——它仅回溯从初始 CONNECT 到最终 FIN 的总耗时，并以该值填充 service= 字段，同时标记为 H15。
✅ 简言之：H15 + high service time ≈ “一个成功存活 N 秒后被干净关闭的 WebSocket”，而非故障信号。
? 验证方法：用 Chrome DevTools 观察真实行为
- 打开浏览器开发者工具 → Network 标签页；
- 过滤 WS（WebSocket）类型请求，观察连接建立过程；
- 注意两个关键阶段：
- 协议升级阶段：可见 GET /ws HTTP/1.1 + 101 Switching Protocols（此阶段计入 Router 日志）；
- 心跳维持阶段：连接建立后无新 Network 条目——因为 ping/pong 帧不产生独立 HTTP 请求，Router 日志中“静默”；
- 手动关闭标签页或调用 socket.close()，此时 Router 立即记录 H15，service= 值即为本次连接总时长。
?️ 最佳实践建议
- 无需修复，但需监控过滤：在日志分析系统（如 Papertrail、Datadog）中对 code=H15 且 status=101 或 status=503 但 bytes > 0 的条目添加白名单规则，避免告警噪声；
- 确保心跳合规：Go 服务端应启用标准 WebSocket 心跳（如 gorilla/websocket 的 SetPingHandler + SetPongHandler），并设置 < 55s 的 WriteDeadline，保障 Router 计时器持续重置；
- 客户端健壮性增强：在页面卸载前显式关闭连接（beforeunload 事件中调用 socket.close()），减少因强制终止导致的异常日志；
- 避免误判指标：切勿将 H15 出现频率作为服务可用性（Uptime）或延迟（Latency）指标——它反映的是用户会话生命周期，而非服务性能。
✅ 总结
Heroku 的 H15 日志在 WebSocket 场景下是一种设计使然的诊断副产品，其存在本身即证明连接曾长期稳定运行。只要你的服务正确处理 ping/pong、客户端能正常收发帧、且无实际连接中断投诉，便可安心忽略此类日志。把精力聚焦于真正的错误码（如 H13、H14、5xx 应用级错误），才能高效保障实时通信质量。
