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

Ella @ellapark

About: Securing networks and writing code—making tech safer, faster, and smarter!

Location:
Seoul, South Korea
Joined:
Mar 5, 2025

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

Publish Date: Mar 5
5 0

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode
  • 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;
Enter fullscreen mode Exit fullscreen mode
  • 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.

Comments 0 total

    Add comment