WebSocket proxying in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

WebSocket connection upgrade headers

You have an Nginx configuration proxying WebSocket traffic. What is the output of the following curl command headers when connecting to the WebSocket endpoint?

curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" http://localhost/ws

A HTTP/1.1 200 OK\nContent-Type: text/html

B HTTP/1.1 400 Bad Request\nContent-Type: text/plain

C HTTP/1.1 101 Switching Protocols\nUpgrade: websocket\nConnection: Upgrade

D HTTP/1.1 404 Not Found\nContent-Type: text/html

💡 Hint

WebSocket connections require HTTP 101 status with upgrade headers.

When Nginx proxies WebSocket correctly, it responds with HTTP 101 Switching Protocols and includes Upgrade and Connection headers to establish the WebSocket connection.

❓ Configuration

intermediate

Correct Nginx config for WebSocket proxy

Which Nginx configuration snippet correctly enables WebSocket proxying to backend at ws://backend:8080/ws?

A proxy_set_header Upgrade $http_upgrade;\nproxy_set_header Connection "upgrade";\nproxy_pass http://backend:8080/ws;

B proxy_set_header Upgrade websocket;\nproxy_set_header Connection keep-alive;\nproxy_pass http://backend:8080/ws;

C proxy_set_header Upgrade $http_upgrade;\nproxy_set_header Connection "close";\nproxy_pass http://backend:8080/ws;

D proxy_set_header Upgrade $connection_upgrade;\nproxy_set_header Connection "close";\nproxy_pass http://backend:8080/ws;

💡 Hint

The Upgrade header must use the client header variable, and Connection must be 'upgrade'.

To proxy WebSocket, Nginx must forward the client's Upgrade header using $http_upgrade and set Connection to 'upgrade'. Other values break the WebSocket handshake.

❓ Troubleshoot

advanced

WebSocket connection fails with 400 Bad Request

You configured Nginx to proxy WebSocket but clients get HTTP 400 Bad Request errors. Which is the most likely cause?

A Client is using HTTP/2 instead of HTTP/1.1

B Backend server is down and not responding

C Nginx is missing SSL certificate configuration

D Missing or incorrect Upgrade and Connection headers in proxy_set_header directives

💡 Hint

WebSocket handshake requires specific headers to upgrade the connection.

If Nginx does not forward the Upgrade and Connection headers correctly, the backend rejects the handshake causing 400 errors.

🔀 Workflow

advanced

Steps to enable WebSocket proxying in Nginx

What is the correct order of steps to enable WebSocket proxying in Nginx?

A 2,3,1,4

B 1,3,2,4

C 2,1,3,4

D 1,2,3,4

💡 Hint

Headers must be set before proxy_pass, then reload Nginx.

First set the headers to handle WebSocket upgrade, then proxy_pass to backend, finally reload Nginx to apply changes.

✅ Best Practice

expert

Best practice for WebSocket timeout settings in Nginx

Which Nginx configuration snippet follows best practices to avoid WebSocket connection drops due to timeouts?

A proxy_read_timeout 30s;\nproxy_send_timeout 30s;

B proxy_read_timeout 3600s;\nproxy_send_timeout 3600s;

C proxy_connect_timeout 5s;\nproxy_send_timeout 10s;

D proxy_connect_timeout 60s;\nproxy_read_timeout 10s;

💡 Hint

WebSocket connections are long-lived and need longer timeouts.

Setting long proxy_read_timeout and proxy_send_timeout prevents Nginx from closing idle WebSocket connections prematurely.

Practice

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

1. Step 1: Understand the Upgrade header role

   The Upgrade header tells the server to switch from HTTP to another protocol, here WebSocket.

2. 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.

3. Final Answer:

   To tell nginx to allow the connection to switch protocols to WebSocket -> Option A

4. Quick Check:

   Upgrade header enables protocol switch = A [OK]

Hint: Upgrade header signals WebSocket protocol switch [OK]

Common Mistakes:

• Confusing Upgrade with client IP headers
• Thinking it enables compression
• Assuming it disables caching

2. Which of the following nginx configuration snippets correctly enables WebSocket proxying?

easy

A. proxy_http_version 1.0; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

B. proxy_http_version 1.1; proxy_set_header Upgrade "websocket"; proxy_set_header Connection "close";

C. proxy_http_version 2.0; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "keep-alive";

D. proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

Solution

1. Step 1: Identify required HTTP version for WebSocket

   WebSocket proxying requires HTTP/1.1 because HTTP/1.0 does not support the Upgrade header properly.

2. Step 2: Check correct headers for WebSocket

   The Upgrade header must be passed as $http_upgrade and Connection header must be "upgrade" to maintain the protocol switch.

3. Final Answer:

   proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; -> Option D

4. Quick Check:

   HTTP/1.1 + Upgrade + Connection upgrade = B [OK]

Hint: Use HTTP/1.1 and set Upgrade and Connection headers correctly [OK]

Common Mistakes:

• Using HTTP/1.0 instead of 1.1
• Setting Connection to keep-alive or close
• Hardcoding Upgrade header instead of using $http_upgrade

3. Given this nginx config snippet inside a location block:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://backend_server;

What will happen if a client tries to establish a WebSocket connection through nginx?

medium

A. The connection will be cached by nginx, causing stale data.

B. The WebSocket connection will be successfully proxied to the backend server.

C. The connection will be proxied but without protocol upgrade, causing failure.

D. The connection will fail because HTTP/2 is required for WebSocket.

Solution

1. Step 1: Analyze HTTP version and headers

   The config uses HTTP/1.1 and sets Upgrade and Connection headers correctly for WebSocket proxying.

2. Step 2: Understand nginx behavior with this config

   nginx will forward the WebSocket upgrade request to the backend, enabling a successful WebSocket connection.

3. Final Answer:

   The WebSocket connection will be successfully proxied to the backend server. -> Option B

4. Quick Check:

   Correct HTTP version and headers = successful proxy [OK]

Hint: HTTP/1.1 + Upgrade + Connection upgrade = success [OK]

Common Mistakes:

• Thinking HTTP/2 is required for WebSocket
• Assuming protocol upgrade is automatic without headers
• Believing nginx caches WebSocket connections

4. You have this nginx config for WebSocket proxying:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "keep-alive";
proxy_pass http://backend;

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

1. Step 1: Check Connection header value

   For WebSocket proxying, Connection header must be "upgrade" to signal protocol switch.

2. Step 2: Identify impact of incorrect Connection header

   Using "keep-alive" prevents the protocol upgrade, causing WebSocket connection failure.

3. Final Answer:

   Because Connection header should be "upgrade" not "keep-alive" for WebSocket -> Option A

4. 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

1. 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.

2. 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.

3. 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

4. Quick Check:

   HTTP/1.1 + Upgrade + Connection upgrade + upstream = A [OK]

Hint: Use HTTP/1.1, Upgrade and Connection headers plus upstream for load balancing [OK]

Common Mistakes:

• Using HTTP/1.0 or 2.0 instead of 1.1
• Setting Connection to keep-alive or close
• Hardcoding Upgrade header instead of using $http_upgrade