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,
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:
-
Send periodic ping frames from the backend.
-
Configure higher proxy_read_timeout in a location where
websocket connections are handled.
–
Maxim D.
http://nginx.org/en/donation.html
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.
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/
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