WebSocket disconnects after ~60 seconds of silence
Default `proxy_read_timeout` kills idle sockets.
Fix: Bump 'Idle timeout' in this generator (e.g. 3600s) and consider keep-alive pings from the client.
Search tools and pages.
Generate an nginx config for proxying WebSocket connections with Upgrade and Connection headers and long read timeouts
sidebar • 160x600
Written by Giorgos Kostas. Last reviewed:
Nginx WebSocket Proxy Generator emits the canonical websocket-aware proxy block — including the `map $http_upgrade $connection_upgrade` directive that Nginx's docs require.
It tunes the parts that trip up websocket setups: `proxy_http_version 1.1`, `proxy_buffering off`, and a configurable `proxy_read_timeout` for long-idle sockets.
path = /ws upstream = http://127.0.0.1:8080 idle = 3600s
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80;
server_name app.example.com;
location /ws {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_buffering off;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
}Default `proxy_read_timeout` kills idle sockets.
Fix: Bump 'Idle timeout' in this generator (e.g. 3600s) and consider keep-alive pings from the client.
Nginx is buffering responses before forwarding to the client.
Fix: Generator emits `proxy_buffering off;` — keep it on. Don't override it elsewhere.
The `Upgrade`/`Connection` headers aren't being forwarded.
Fix: Confirm the generated `map` block is included and that nothing rewrites those headers downstream.
Nginx forwards `Connection` literally by default. WebSockets need `Connection: upgrade`, but only when the client requested an upgrade. The `map` translates `$http_upgrade` to either `upgrade` or `close`, which the proxy block then forwards.
At the http {} level. The generator emits it at the top of the snippet — paste it into a file under `/etc/nginx/conf.d/` so it loads inside the http context.
The websocket location works the same on HTTPS — paste the location block into the HTTPS server generated by the SSL Config Generator. Clients connect with `wss://`.
Yes — set the optional fallback `proxy_pass` and the generator emits a `location /` block alongside the websocket location.
Just here. `proxy_buffering off` is appropriate for streaming/long-poll/websocket responses; keep it on for normal REST traffic.
1 hour (3600s) is a reasonable upper bound for chat/realtime apps. If you go higher, also configure TCP keep-alive on the upstream so dead connections are reaped.
WebSocket-stack neighbours. You can also browse the full DevOps & Infra category for more options.
Generate a production-ready nginx.conf for reverse proxying with proxy_pass, headers, timeouts, and gzip from a focused form
Generate an HTTPS-ready nginx.conf with SSL certificate paths, modern protocols, ciphers, HSTS, and HTTP-to-HTTPS redirect
Generate an nginx upstream + load balancer config with round-robin, least_conn, ip_hash, weights, health checks, and keepalive
Send a real OPTIONS preflight and the actual request from a server proxy and inspect the per-rule CORS verdict for any origin
Paste response headers to audit HSTS, CSP, CORS, X-Powered-By disclosure, and Set-Cookie flags
Generate an nginx.conf for serving a static site with try_files, SPA fallback, gzip, brotli, and aggressive cache headers
Validate docker-compose.yml against the Compose Spec schema with hand-written lints (port collisions, undefined networks, depends_on cycles)
Edit .env files in a key/value table with type detection, masked secrets, duplicate-key warnings, and export to JSON, YAML, shell, or docker-compose
Explore multi-document Kubernetes manifests grouped by kind with a cross-reference graph (Service to Deployment, ConfigMap mounts, Ingress backends)
sudo nginx -t && sudo systemctl reload nginxcontent bottom • up to 300x250