Bird
Raised Fist0
Nginxdevops~5 mins

IP hash for session persistence in Nginx - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What is the purpose of using ip_hash in nginx?
The ip_hash directive in nginx ensures that requests from the same client IP address are always sent to the same backend server. This helps keep user sessions consistent.
Click to reveal answer
intermediate
How does ip_hash differ from round-robin load balancing?
Round-robin sends requests to backend servers in order, cycling through them. ip_hash sends requests from the same IP to the same server, maintaining session persistence.
Click to reveal answer
beginner
Show a simple nginx configuration snippet using ip_hash.
upstream backend { ip_hash; server backend1.example.com; server backend2.example.com; } server { location / { proxy_pass http://backend; } }
Click to reveal answer
intermediate
What happens if a client IP changes when using ip_hash?
If the client IP changes, nginx may route the request to a different backend server, potentially breaking session persistence.
Click to reveal answer
intermediate
Can ip_hash be used with SSL termination in nginx?
Yes, ip_hash works with SSL termination. The load balancer handles SSL and then uses ip_hash to route requests to backend servers.
Click to reveal answer
What does the ip_hash directive do in nginx?
AEncrypts client IP addresses
BDistributes requests randomly to backend servers
CBlocks requests from unknown IPs
DRoutes requests from the same IP to the same backend server
Which load balancing method does ip_hash replace or complement?
ARound-robin
BLeast connections
CRandom
DWeighted
What is a limitation of using ip_hash for session persistence?
AIt requires sticky cookies
BIt only works with HTTP/2
CIt depends on client IP, which can change
DIt disables SSL
How do you enable ip_hash in an nginx upstream block?
AAdd <code>ip_hash;</code> inside the upstream block
BAdd <code>ip_hash on;</code> in the server block
CSet <code>proxy_pass ip_hash;</code>
DUse <code>sticky_ip;</code> directive
If a user behind a proxy shares the same IP with others, what is a possible effect when using ip_hash?
AUsers get distributed evenly
BAll users share the same backend server
CSessions are encrypted
DRequests are blocked
Explain how ip_hash helps maintain session persistence in nginx load balancing.
Think about how nginx decides where to send requests from the same user.
You got /4 concepts.
    Describe a scenario where using ip_hash might cause problems and why.
    Consider what happens if the IP address is not stable or shared by many users.
    You got /4 concepts.

      Practice

      (1/5)
      1. What is the main purpose of using ip_hash in an Nginx upstream block?
      easy
      A. To ensure requests from the same client IP go to the same backend server
      B. To encrypt traffic between Nginx and backend servers
      C. To balance load evenly regardless of client IP
      D. To cache static files on the client side

      Solution

      1. Step 1: Understand the role of ip_hash

        The ip_hash directive in Nginx is used to route requests from the same client IP address to the same backend server.
      2. Step 2: Identify the purpose in session persistence

        This helps keep user sessions sticky, meaning the user stays connected to the same server, which is important for apps storing session data locally.
      3. Final Answer:

        To ensure requests from the same client IP go to the same backend server -> Option A
      4. Quick Check:

        IP hash = session stickiness [OK]
      Hint: ip_hash keeps same IP on same server for session stickiness [OK]
      Common Mistakes:
      • Confusing ip_hash with encryption
      • Thinking ip_hash balances load evenly
      • Assuming ip_hash caches files
      2. Which of the following is the correct way to enable IP hash in an Nginx configuration for upstream servers?
      easy
      A. upstream backend { hash_ip; server 192.168.1.10; server 192.168.1.11; }
      B. upstream backend { iphash; server 192.168.1.10; server 192.168.1.11; }
      C. upstream backend { ip_hash; server 192.168.1.10; server 192.168.1.11; }
      D. upstream backend { ip_hash = on; server 192.168.1.10; server 192.168.1.11; }

      Solution

      1. Step 1: Recall the exact directive syntax

        The correct directive to enable IP hash in Nginx is ip_hash; placed inside the upstream block without any assignment or spelling changes.
      2. Step 2: Check each option for syntax correctness

        upstream backend { ip_hash; server 192.168.1.10; server 192.168.1.11; } uses ip_hash; correctly. Options A and C have wrong directive names. upstream backend { ip_hash = on; server 192.168.1.10; server 192.168.1.11; } uses an invalid assignment syntax.
      3. Final Answer:

        upstream backend { ip_hash; server 192.168.1.10; server 192.168.1.11; } -> Option C
      4. Quick Check:

        Correct directive is ip_hash; [OK]
      Hint: Use exact directive 'ip_hash;' inside upstream block [OK]
      Common Mistakes:
      • Misspelling ip_hash as iphash or hash_ip
      • Adding = on which is invalid
      • Placing ip_hash outside upstream block
      3. Given this Nginx upstream configuration with ip_hash; enabled, what will happen if two requests come from the same client IP?
      medium
      A. Both requests will be sent to different backend servers randomly
      B. Both requests will be sent to the same backend server
      C. Requests will be load balanced based on server load
      D. Requests will be rejected due to IP conflict

      Solution

      1. Step 1: Understand ip_hash behavior on requests

        With ip_hash; enabled, Nginx uses the client's IP address to decide which backend server to send the request to, ensuring the same IP always maps to the same server.
      2. Step 2: Apply this to two requests from the same IP

        Since both requests come from the same IP, they will be routed to the same backend server for session persistence.
      3. Final Answer:

        Both requests will be sent to the same backend server -> Option B
      4. Quick Check:

        Same IP = same server [OK]
      Hint: Same IP means same backend server with ip_hash [OK]
      Common Mistakes:
      • Assuming random distribution despite ip_hash
      • Thinking load balancing ignores ip_hash
      • Believing requests get rejected on IP reuse
      4. You added ip_hash; inside your upstream block, but session stickiness is not working. Which of these is the most likely cause?
      medium
      A. You placed ip_hash; inside the server block instead of upstream
      B. You forgot to restart Nginx after adding ip_hash;
      C. Your backend servers do not support IP hashing
      D. You used ip_hash on; instead of ip_hash;

      Solution

      1. Step 1: Verify correct placement of ip_hash;

        The ip_hash; directive must be inside the upstream block, not inside individual server blocks.
      2. Step 2: Analyze other options

        Restarting Nginx is necessary but usually not the main cause. Backend servers don't affect ip_hash behavior. Using ip_hash on; is invalid syntax.
      3. Final Answer:

        You placed ip_hash; inside the server block instead of upstream -> Option A
      4. Quick Check:

        ip_hash must be inside upstream block [OK]
      Hint: ip_hash belongs inside upstream, not server block [OK]
      Common Mistakes:
      • Putting ip_hash in server block
      • Using wrong syntax like ip_hash on;
      • Blaming backend servers for ip_hash issues
      5. You have three backend servers and want to use IP hash for session persistence. However, one server is down. What will Nginx do with requests from an IP previously mapped to the down server?
      hard
      A. Nginx will randomly distribute requests ignoring IP hash
      B. Nginx will keep sending requests to the down server causing errors
      C. Nginx will reject the requests with a 503 error
      D. Nginx will send requests to a different available backend server

      Solution

      1. Step 1: Understand ip_hash behavior with unavailable servers

        When a backend server is down, Nginx detects it as unavailable and will not send requests to it, even if IP hash maps to it.
      2. Step 2: Determine fallback behavior

        Nginx will route requests to another available backend server to keep service running, though session stickiness is temporarily lost for that IP.
      3. Final Answer:

        Nginx will send requests to a different available backend server -> Option D
      4. Quick Check:

        Down server skipped, requests go to available servers [OK]
      Hint: Down servers skipped; requests go to other servers [OK]
      Common Mistakes:
      • Assuming Nginx keeps sending to down server
      • Thinking requests get rejected automatically
      • Believing ip_hash ignores server health
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard