mod_proxy_wstunnel不处理Ping/Pong，仅透传帧；连接中断主因是后端未响应ping，需后端显式注册PongHandler并持续读取消息，Apache端应调大ProxyTimeout、禁用健康检查干扰。

mod_proxy_wstunnel 本身不处理 Ping/Pong，只透传

Apache 的 mod_proxy_wstunnel 是个「隧道式代理」，它不解析 WebSocket 帧，也不主动响应 ping 帧 —— 它只负责把原始 TCP 流（含 ping/pong 帧）原样转发给后端。所以如果你看到连接被断开、浏览器报 WebSocket is closed before the connection is established 或日志里有 connection reset by peer，大概率不是 Apache 配置错，而是后端没回 pong。

后端必须显式注册 PongHandler（以常见语言为例）

只要后端没正确响应 ping，mod_proxy_wstunnel 就会在超时后静默关闭 socket，浏览器感知不到原因，只显示连接中断。

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• Node.js（ws 库）：默认已内置 ping/pong 处理，但若你用了 noServer: true 或自定义 handleUpgrade，就得手动调用 socket.ping() 和监听 pong 事件
• Java Spring Boot（spring-websocket）：@MessageMapping 不管底层帧；必须在 WebSocketConfigurer 中注册 WebSocketHandlerRegistry，并启用心跳：registry.addEndpoint("/ws").setAllowedOrigins("*").withSockJS().setHeartbeatTime(30000)
• Go（gorilla/websocket）：必须调用 conn.SetPingHandler(func(appData string) error { return conn.WriteMessage(websocket.PongMessage, nil) })，且要确保 conn.ReadMessage() 或 conn.NextReader() 持续被调用，否则 ping 帧堆积不触发 handler

Apache 端需避免干扰心跳周期

mod_proxy_wstunnel 默认每 60 秒发一次 ping（由底层 apr_socket_timeout_set 控制），但它不暴露该间隔的配置项。你不能调小这个值，但可以防止它被提前掐断：

• 设 ProxyTimeout 300 或更高（单位秒），否则 Apache 可能在收到 pong 前就因空闲超时关掉连接
• 禁用所有对 /ws/ 路径的健康检查（比如 balancer-manager 的 ping 请求），否则会混入非 WebSocket 流量，触发协议错误
• 不要在 Location 块里加 SetEnv nokeepalive 或 Header unset Connection，这些会破坏 upgrade 过程，导致后续 ping 根本发不出去

怎么确认 ping/pong 真正在走通

别只信浏览器 Network 面板里状态码是 101 Switching Protocols —— 那只代表握手成功。真正通路是否稳定，得看帧级行为：

• 在后端加日志：收到 ping 时打一行 "got ping"，发出 pong 时打 "sent pong"
• 用 tcpdump -i lo -A port 8080 | grep -i "ping\|pong" 抓包（假设后端跑在本地 8080），确认帧进出成对
• Apache 错误日志里搜 wstunnel 和 timeout，如果频繁出现 proxy: error reading status line from remote server，基本就是后端没回 pong 导致连接被重置

关键点其实就一个：Apache 不参与心跳逻辑，它只是管道。管道两端——前端浏览器和后端服务——必须各自守好自己的 ping/pong 职责，中间这段不能加任何“智能”干预。