Need help: websocket proxy stops working after a while

Server NGINX
#1

I got nginx websocket proxy working but the socket would close
in a minute or so. So I add
proxy_read_timeout 180s;
and it works within 3 minutes but closed the websocket after 3
minutes, but it works OK before that. Why is that?
BTW, I am using Nginx 1.4 now.
Thanks,

  • Alder
#2

Hello!

On Mon, Jun 03, 2013 at 03:24:52PM -0700, Alder N. wrote:

I got nginx websocket proxy working but the socket would close
in a minute or so. So I add
proxy_read_timeout 180s;
and it works within 3 minutes but closed the websocket after 3
minutes, but it works OK before that. Why is that?
BTW, I am using Nginx 1.4 now.

Much like with normal http, nginx will time out connection to the
upstream server if it doesn’t see any data from it. If with a
backend you use there are no data expected from the backend to a
client, there are two possible solutions:

  1. Send periodic ping frames from the backend.

  2. Configure higher proxy_read_timeout in a location where
    websocket connections are handled.

–
Maxim D.
http://nginx.org/en/donation.html

#3

Thanks for the info.

For 2) , it would be nice to accept value of -1 ( or 0 ) for
proxy_read_timeout as indefinite, namely no timeout checking
at proxy.

#4

Hello!

On Fri, Apr 04, 2014 at 04:20:04AM -0400, phil3361 wrote:

This is ennoying: such application work has a quite heavy resource cost,
especially on the server side. This looses some of the most valuable
benefits of a WebSocket connection: maintaining an active asynchronous
notification channel from the server to the client, just in case…

You are understanding it wrong.

Any ping/pong frame, as well as any other frame in a proxied
websocket connection, will reset nginx timeouts. Note that first
my response suggests “periodic ping frames from the backend” as
one of the possible solutions.

–
Maxim D.
http://nginx.org/

#5

Hi all,

The WebSocket protocol specification (RFC 6455) defines a
protocol_level
keep alive fonctionnality (the protocol defines both a ‘ping’ and a
‘pong’
frame).

Unfortunately, it seems that nginx doesn’t take these frames into
account to
reset its timeout watchdog timer so far… so that you have to implement
some application_level heartbeat mecanism if you don’t want your
WebSocket
connection be broken by an intermediate nginx on low activity periods…

This is ennoying: such application work has a quite heavy resource cost,
especially on the server side. This looses some of the most valuable
benefits of a WebSocket connection: maintaining an active asynchronous
notification channel from the server to the client, just in case…

Hope this helps,
Philippe.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,239809,248984#msg-248984