Who’s Really Connecting? Handling IP Headers in CDN Networks

📑 Introduction

When a request passes through a Content Delivery Network (CDN), the client's original IP address is often replaced with the CDN server's IP. This can create challenges for the origin server in identifying the true source of the request. In this post, we will explore how extra HTTP headers like X-Forwarded-For and True-Client-IP help pass the client’s real IP address back to the origin server, ensuring accurate request processing.

🚨 The Problem: IP Address Masking by CDNs

CDNs act as intermediaries, often replacing the client’s IP with their own. This poses challenges such as:

• Difficulty in identifying the real client IP.
• Ineffectiveness of IP-based security measures (e.g., access control lists, rate limiting).

Since IP filtering at the network level (Layer 3 of the OSI model) is unreliable in a CDN environment, extra HTTP headers are used to convey the original client IP.

🛠️ The Solution: Using Extra HTTP Headers

To solve this, CDNs use HTTP headers like X-Forwarded-For and True-Client-IP to relay the real client IP to the origin server.

🏷️ X-Forwarded-For

• Used by proxies and CDNs to forward the client’s IP address.
• If a request passes through multiple proxies, the header contains multiple IPs, separated by commas.

Example:

X-Forwarded-For: client_IP, proxy1_IP, proxy2_IP

🏷️ True-Client-IP

• Provides only the original client IP, simplifying processing at the origin server.
• Equivalent to the first IP address in X-Forwarded-For.

Key Difference:

• X-Forwarded-For is useful in multi-tier architectures where tracking intermediate proxies is necessary.
• True-Client-IP offers a simpler way to retrieve the real client IP.

---

⚠️ Common Issue: Login Failure Due to X-Forwarded-For Handling

🚨 The Problem

After implementing a CDN, I encountered a login issue when multiple IP addresses appeared in the X-Forwarded-For header:

X-Forwarded-For: 59.10.176.51  ✅ Login Success
X-Forwarded-For: 59.10.176.51, 8.8.8.8  ❌ Login Error

The web server only trusted the first IP address and ignored the rest. When the CDN or proxy added additional IPs, the server misinterpreted the header and rejected the request.

🛠️ Solutions

Solution 1: Trust Only the First IP

• Modify the application or configuration to extract only the first IP from X-Forwarded-For.
• Ensures consistency, but may not work in all environments.

Solution 2: Configuring Nginx

If using Nginx, configure it to trust only the real client IP:

Option 1: Override X-Forwarded-For

proxy_set_header X-Forwarded-For $remote_addr;

• Replaces the X-Forwarded-For header with the real client IP.

Option 2: Preserve Existing Header and Append Real Client IP

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

• Maintains the list of IPs but requires additional processing to extract the trusted IP.

---

✅ Conclusion

By properly configuring X-Forwarded-For and True-Client-IP, CDNs enable origin servers to correctly identify client IPs, even in complex proxy environments. Ensuring correct header parsing prevents login failures and enhances security by allowing accurate IP-based filtering and logging.