WebSocket Ping vs. TCP Keepalive Through a Proxy
Choose a liveness check for the WebSocket peer rather than treating a live TCP socket as proof that the application path is responding.
A live TCP socket, a responsive WebSocket peer, and useful application progress are different observations:
| Evidence | What it establishes |
|---|---|
| TCP-level liveness | The checked transport path responds at that level |
| A matching WebSocket Pong | The peer answered that control frame |
| An application acknowledgement | The application confirmed an operation under its own protocol |
A forward proxy commonly maintains separate client- and destination-facing connections. The client's TCP peer is the proxy, while a Ping inside an established tunnel travels to the WebSocket endpoint.
A matching Pong
The protocol requires a responding Pong to carry the Ping's application data. Use that correspondence to identify an outstanding probe. An unsolicited Pong is allowed but does not request an acknowledgement; sending one after each data message supplies different evidence.
Prefer the library's supported heartbeat mechanism. Browser JavaScript needs an application heartbeat contract instead. Choose intervals and failure thresholds for the workload and network policy. Scheduling pauses or an overloaded event loop can miss an aggressive threshold without establishing a failed network.
Keep the receiver running
The client needs ongoing I/O to receive and process control frames. Blocking that machinery can make local starvation appear to be an outage.
Ping creates tunnel traffic, but each intermediary decides what satisfies its idle policy. No heartbeat guarantees protection from an absolute connection-lifetime limit.
A peer can answer Ping while its application stops producing updates, and a quiet subscription can be healthy. Track the last valid Pong and meaningful application event separately when both matter. On failure, retain the route, elapsed times, and outstanding probe, then close or recover through the supported lifecycle.