Opened 8 years ago
Closed 7 years ago
#1295 closed defect (invalid)
proxy_pass to websocket server
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | other | Version: | 1.12.x |
| Keywords: | Cc: | ||
| uname -a: | Linux 4.11.4-1.el7.elrepo.x86_64 #1 SMP Wed Jun 7 12:18:44 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.12.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' |
||
Description
Hello, I have nginx config as a proxy server to local websocket server.
As the guide was used http://nginx.org/ru/docs/http/websocket.html.
Problem in the current configuration are lines in the error.log (hundreds per second) with number of clients ~5k:
2017/06/10 05:48:37 [error] 1134#0: *28355 recv() failed (104: Connection reset by peer) while proxying upgraded connection, client: 178.62.128.67, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8005/", host: "example.com"
2017/06/10 05:48:37 [error] 1138#0: *27997 recv() failed (104: Connection reset by peer) while proxying upgraded connection, client: 36.234.135.45, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8005/", host: "example.com"
2017/06/10 05:48:37 [error] 1134#0: *27922 recv() failed (104: Connection reset by peer) while proxying upgraded connection, client: 5.18.206.115, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8005/", host: "example.com"
Part of config:
upstream ws_server {
server 127.0.0.1:8005;
}
server {
listen 443 ssl;
ssl keys
server_name example.com;
error_log /var/log/nginx/error.log notice;
location / {
proxy_pass http://ws_server;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_connect_timeout 7d;
proxy_send_timeout 7d;
proxy_read_timeout 7d;
}
}
As a backend websocket server was used "gorilla-weboscket" written in golang and an implementation on node.js with "ws" library. Errors occur in both situations.
Change History (3)
comment:1 by , 8 years ago
comment:2 by , 7 years ago
Sorry for the late reply. You are right, problem was in backend and with the kernel configuration.
comment:3 by , 7 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
The log messages suggest that the connection is reset by your backend for some reason. This may happen either because of how your backend is written, or because of some network problems between nginx and the backend.
Note that in theory, WebSocket's close handshake is expected to prevent connection resets in case of well-behaving clients. They might still appear though if a client misbehaves and tries to send additional data after a Close frame. It would be interesting to look into a tcpdump of traffic between nginx and the backend.