What is X-Forwarded-For?

X-Forwarded-For (XFF) is a de facto HTTP request header that preserves the original client IP when a connection passes through a reverse proxy, load balancer, or CDN. Without it, the application only sees the last hop’s address, which hides the visitor behind shared infrastructure.

Table of Contents

  1. How does X-Forwarded-For work?
  2. Why does this matter for click fraud and ad fraud?

How does X-Forwarded-For work?

Each trusted proxy appends the IP it observed on the inbound connection to the header, forming a comma-separated list. The leftmost entry is conventionally the first client seen by the chain, but that position is forgeable if a client sends a fake XFF before reaching your controlled edge.

Secure parsing uses a trust list: only accept XFF from known proxies, then walk the list from the right until you reach the first IP that is not your infrastructure. That value is treated as the client for rate limits, geo hints, and logs. The standardized Forwarded header (RFC 7239) expresses similar data with richer syntax; many stacks still rely on XFF in practice.

Related variants include X-Real-IP (single client IP from some proxies) and vendor-specific headers from large CDNs. Applications must be configured to read the right field for their topology.

Why does this matter for click fraud and ad fraud?

Accurate client IP underpins geolocation, velocity rules, and overlap checks against known abusive ranges. If your app logs only the balancer IP, every user looks like one source and real abuse hides in plain sight. Correct XFF handling restores diversity in the data that feeds fraud detection and helps separate suspicious clicks from a busy office NAT.

Fraud operators may chain proxies or VPN exits; XFF still clarifies what your edge saw versus what the ad network attributes. Combine IP context with ASN and ISP-style classification, device signals, and conversion quality when evaluating click fraud and ad fraud. Bot traffic often clusters on hosting IPs even when XFF is present.

Frequently Asked Questions

  • Is the leftmost XFF IP always the user?

    No. A client can prepend a fake value. Parse only from trusted proxies and validate against your network map.

  • Does HTTPS hide X-Forwarded-For?

    TLS encrypts the HTTP layer between client and first terminator. Your origin still receives headers the proxy adds after termination. End-to-end encryption to the app does not remove the need for careful trust configuration.

  • Should I log the full XFF string?

    Storing the raw header alongside the chosen client IP helps forensics when chains change. Apply retention and privacy rules appropriate to your jurisdiction and contracts.

Abisola

Abisola

Meet Abisola! As the content manager at ClickPatrol, she’s the go-to expert on all things fake traffic. From bot clicks to ad fraud, Abisola knows how to spot, stop, and educate others about the sneaky tactics that inflate numbers but don’t bring real results.