IP hash for session persistence in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does IP hash maintain session persistence in NGINX?

Which statement best describes how the ip_hash directive in NGINX helps maintain session persistence?

A It uses the client's IP address to consistently route requests to the same backend server.

B It stores session data on the NGINX server to track user sessions.

C It randomly distributes requests to backend servers to balance load evenly.

D It uses cookies to identify and route users to backend servers.

💡 Hint

Think about what information NGINX can use without storing session data.

The ip_hash directive uses the client's IP address to ensure requests from the same client go to the same backend server, maintaining session persistence without storing session data.

💻 Command Output

intermediate

NGINX configuration with ip_hash output

Given this NGINX upstream configuration, what will be the output of nginx -t?

Nginx

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

A nginx: [emerg] unknown directive "ip_hash" in /etc/nginx/nginx.conf:2

B nginx: [warn] server backend1.example.com is down

C

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

D nginx: [error] duplicate upstream name "backend" in /etc/nginx/nginx.conf:1

💡 Hint

Check if the ip_hash directive is valid in upstream context.

The ip_hash directive is valid in the upstream block. The configuration syntax is correct, so nginx -t reports success.

❓ Troubleshoot

advanced

Why does session persistence fail with ip_hash in this setup?

After enabling ip_hash in NGINX, users report sessions are not sticky and requests go to different backend servers. What is the most likely cause?

A The client IP is hidden behind a proxy or load balancer, so NGINX sees the same IP for all clients.

B The <code>proxy_pass</code> directive is missing in the server block.

C The <code>ip_hash</code> directive requires a cookie to work properly.

D The backend servers have different IP addresses, causing inconsistent hashing.

💡 Hint

Consider how NGINX sees client IPs when behind another proxy.

If clients connect through a proxy or load balancer, NGINX may see the proxy's IP instead of the real client IP, causing all requests to hash to the same backend server or fail to maintain session persistence.

🔀 Workflow

advanced

Order the steps to enable IP hash session persistence in NGINX

Arrange the steps in the correct order to enable IP hash session persistence for a backend in NGINX.

A 3,1,2,4

B 2,1,3,4

C 1,3,2,4

D 1,2,3,4

💡 Hint

Think about defining backend servers before applying ip_hash and proxying.

First define the upstream block with servers, then add ip_hash inside it, configure the server block to use the upstream, and finally test and reload NGINX.

✅ Best Practice

expert

Best practice to handle client IPs behind proxies for ip_hash

When using ip_hash in NGINX behind a reverse proxy or load balancer, what is the best practice to ensure session persistence works correctly?

A Set the <code>proxy_pass</code> directive to use the proxy's IP address.

B Configure NGINX to use the <code>X-Forwarded-For</code> header with the <code>real_ip_module</code> to get the actual client IP.

C Disable <code>ip_hash</code> and use random load balancing instead.

D Use sticky cookies instead of <code>ip_hash</code> without any additional configuration.

💡 Hint

How can NGINX know the real client IP when behind another proxy?

Behind proxies, NGINX sees the proxy IP by default. Using the real_ip_module to extract the real client IP from headers like X-Forwarded-For allows ip_hash to work properly.