The default proxy_send_timeout is 60s. If you rely on the information about connected clients (chat anyone?), it's way nicer to ping the server every 30s, than to set huge timeouts. If internet connection of the client breaks (mobile anyone?) and the client has no possibility to close the websocket connection, nginx keeps the connection open and you server thinks that there are some clients to talk to. Nice side effect: Your client knows about the disconnect, because the ping fails.
EDIT: the parent originally said "proxy_read_timeout", and this comment was in response to that.
proxy_read_timeout times out reads from the upstream. It will trigger when a backend server goes AWOL, not when a client falls off the net.
If you want to detect client-side disconnection, you want proxy_send_timeout.
You can emulate this by having server sent heartbeats with a proxy_read_timeout with the client required to respond to them before the server will send any more, thus going read-silent whenever the client fails to respond, but why not just have the client do the pinging? Then the server doesn't have to say anything in response most of the time.
Agreed. We have a larger window so that we can adaptively ping (when the client isn't very active, we don't ping as often). We're not making chat though.
If you do want timeouts like this, an alternative is to handle this on the application layer, and not rely on nginx to drop connections.
EDIT: it's the proxy_send_timeout directive.