📖 Scenario: You are setting up a web server to forward WebSocket connections from clients to a backend WebSocket server. This is common when you want to use Nginx as a reverse proxy to handle WebSocket traffic securely and efficiently.
🎯 Goal: Configure Nginx to proxy WebSocket connections correctly by setting up the necessary headers and connection upgrade directives.
📋 What You'll Learn
Create a basic Nginx server block listening on port 80
Add a variable for the backend WebSocket server URL
Configure proxy settings to handle WebSocket upgrade headers
Print the final Nginx configuration to verify correctness
💡 Why This Matters
🌍 Real World
WebSocket proxying is used to enable real-time communication in web apps, such as chat apps or live notifications, by forwarding WebSocket traffic through a reverse proxy like Nginx.
💼 Career
Understanding how to configure Nginx for WebSocket proxying is a valuable skill for DevOps engineers and system administrators managing scalable, real-time web services.
Progress0 / 4 steps
1
Create a basic Nginx server block
Write an Nginx server block that listens on port 80 and has a location /ws/ to proxy requests. Use proxy_pass http://backend_ws_server; inside the location block.
Nginx
Hint
Start with a server block, add listen 80;, then add a location /ws/ block with proxy_pass http://backend_ws_server;.
2
Add a variable for the backend WebSocket server URL
Define an upstream block named backend_ws_server with the server address 127.0.0.1:8080 before the server block.
Nginx
Hint
Use upstream backend_ws_server { server 127.0.0.1:8080; } to define the backend server.
3
Configure proxy settings for WebSocket upgrade
Inside the location /ws/ block, add these directives exactly: proxy_http_version 1.1;, proxy_set_header Upgrade $http_upgrade;, proxy_set_header Connection "upgrade";, and proxy_set_header Host $host;.
Nginx
Hint
These headers are needed to tell Nginx to handle WebSocket upgrades properly.
4
Print the final Nginx configuration
Write a command to print the contents of the Nginx configuration file /etc/nginx/nginx.conf to verify your setup.
Nginx
Hint
Use cat /etc/nginx/nginx.conf to display the configuration file contents.
Practice
(1/5)
1. What is the main reason to use proxy_set_header Upgrade $http_upgrade; in nginx when proxying WebSocket connections?
easy
A. To tell nginx to allow the connection to switch protocols to WebSocket
B. To set the client's IP address in the header
C. To enable gzip compression for WebSocket data
D. To disable caching for WebSocket requests
Solution
Step 1: Understand the Upgrade header role
The Upgrade header tells the server to switch from HTTP to another protocol, here WebSocket.
Step 2: Recognize nginx's proxy_set_header usage
Setting proxy_set_header Upgrade $http_upgrade; passes the client's Upgrade header to the backend, enabling protocol switching.
Final Answer:
To tell nginx to allow the connection to switch protocols to WebSocket -> Option A
Why might WebSocket connections fail with this setup?
medium
A. Because Connection header should be "upgrade" not "keep-alive" for WebSocket
B. Because proxy_http_version should be 1.0 for WebSocket
C. Because Upgrade header should be hardcoded to "websocket"
D. Because proxy_pass URL is missing a trailing slash
Solution
Step 1: Check Connection header value
For WebSocket proxying, Connection header must be "upgrade" to signal protocol switch.
Step 2: Identify impact of incorrect Connection header
Using "keep-alive" prevents the protocol upgrade, causing WebSocket connection failure.
Final Answer:
Because Connection header should be "upgrade" not "keep-alive" for WebSocket -> Option A
Quick Check:
Connection header must be upgrade for WebSocket [OK]
Hint: Connection header must be "upgrade" for WebSocket [OK]
Common Mistakes:
Using keep-alive instead of upgrade
Setting HTTP version to 1.0
Hardcoding Upgrade header instead of using $http_upgrade
5. You want to proxy WebSocket connections through nginx to two backend servers for load balancing. Which configuration snippet correctly supports WebSocket proxying with load balancing?
hard
A. upstream ws_backend {
server backend1.example.com;
server backend2.example.com;
}
location /ws/ {
proxy_pass http://ws_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "close";
}
B. upstream ws_backend {
server backend1.example.com;
server backend2.example.com;
}
location /ws/ {
proxy_pass http://ws_backend;
proxy_http_version 1.0;
proxy_set_header Upgrade websocket;
proxy_set_header Connection "keep-alive";
}
C. upstream ws_backend {
server backend1.example.com;
server backend2.example.com;
}
location /ws/ {
proxy_pass http://ws_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
D. upstream ws_backend {
server backend1.example.com;
server backend2.example.com;
}
location /ws/ {
proxy_pass http://ws_backend;
proxy_http_version 2.0;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Solution
Step 1: Confirm HTTP version and headers for WebSocket
HTTP/1.1 is required, and headers Upgrade and Connection must be set to allow protocol upgrade.
Step 2: Check load balancing setup and header correctness
upstream ws_backend {
server backend1.example.com;
server backend2.example.com;
}
location /ws/ {
proxy_pass http://ws_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
} uses correct HTTP version, headers, and defines upstream servers for load balancing properly.
Final Answer:
upstream ws_backend {
server backend1.example.com;
server backend2.example.com;
}
location /ws/ {
proxy_pass http://ws_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
} -> Option C