HTTP Headers

HTTP proxy headers, such as X-Forwarded-For and Via, are used by proxy servers to convey information about the original client, the request path, and other contextual data to the upstream server, which would otherwise be obscured by the proxy's presence.

When an HTTP request passes through one or more proxy servers, the immediate upstream server typically sees the IP address of the last proxy, not the original client. Proxy headers address this by adding or modifying specific HTTP headers, allowing the original client's IP, protocol, host, and the sequence of proxies to be communicated to the final destination server.

X-Forwarded-For

The X-Forwarded-For (XFF) header is a de-facto standard header used to identify the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.

Purpose

Its primary purpose is to allow the web server to access the original client's IP address for logging, analytics, security, and application-specific logic (e.g., IP-based access control, geo-location). Without XFF, all requests would appear to originate from the proxy server's IP address.

Format and Examples

The XFF header can contain a comma-separated list of IP addresses. When a request passes through multiple proxies, each proxy appends the IP address of the client that connected to it to the XFF header.

• X-Forwarded-For: <client>, <proxy1>, <proxy2>

Example 1: Single Proxy
A client (192.0.2.1) connects to a proxy (198.51.100.1), which then connects to the origin server.
The proxy adds:

X-Forwarded-For: 192.0.2.1

The origin server sees the request coming from 198.51.100.1 and X-Forwarded-For: 192.0.2.1.

Example 2: Multiple Proxies
A client (192.0.2.1) connects to Proxy A (198.51.100.1), which connects to Proxy B (203.0.113.1), which then connects to the origin server.
1. Client to Proxy A: Proxy A adds X-Forwarded-For: 192.0.2.1.
2. Proxy A to Proxy B: Proxy B receives X-Forwarded-For: 192.0.2.1. Proxy B appends 198.51.100.1 to it.
The header becomes: X-Forwarded-For: 192.0.2.1, 198.51.100.1.
3. Proxy B to Origin Server: The origin server receives X-Forwarded-For: 192.0.2.1, 198.51.100.1.

In a chain of proxies, the leftmost IP address is typically the original client. The rightmost IP address is the IP of the immediate upstream proxy (the client that connected to the current proxy).

Security Considerations for X-Forwarded-For

The X-Forwarded-For header can be easily spoofed by a malicious client. A client can send a request with a fabricated X-Forwarded-For header.

GET / HTTP/1.1
Host: example.com
X-Forwarded-For: 10.0.0.1, 1.1.1.1

If a proxy blindly appends to this, the header received by the origin server might look like X-Forwarded-For: 10.0.0.1, 1.1.1.1, <proxy_ip>.
Therefore, downstream applications should not trust the entire X-Forwarded-For header value directly. The generally accepted practice is to trust only the rightmost untrusted IP address in the list as the actual client IP, after removing any entries that belong to known trusted proxies. Many web servers and application frameworks provide mechanisms to specify a list of trusted proxies.

Via

The Via header is a standard HTTP header that indicates the intermediate proxies and gateways through which a request (or response) has passed.

Purpose

The Via header serves several purposes:
* Traceability: It provides a trace of the proxy chain, useful for debugging network paths.
* Loop Detection: It can help detect request loops in proxy chains.
* Protocol Compatibility: It signals the protocol versions used by each intermediate proxy, which can be relevant for protocol conversions.

Format and Examples

Each proxy adds its own Via entry to the header. The format for each entry is protocol-name/protocol-version host:port (comment). The comment field is optional and can contain arbitrary information.

Via: <protocol-name>/<protocol-version> <host>:<port> (comment)

Example:
A client sends a request that passes through Proxy A (hostname proxy-a.example.com, port 8080) and Proxy B (hostname proxy-b.example.com, port 80).

1. Client to Proxy A: Proxy A adds Via: HTTP/1.1 proxy-a.example.com:8080.
2. Proxy A to Proxy B: Proxy B receives Via: HTTP/1.1 proxy-a.example.com:8080. Proxy B prepends its own entry.
   The header becomes: Via: 1.1 proxy-b.example.com, 1.1 proxy-a.example.com:8080.
   (Note: HTTP/ is often omitted if it's HTTP, and port 80/443 might be omitted.)
3. Proxy B to Origin Server: The origin server receives the full Via header.

Privacy and Operational Considerations

The Via header exposes internal network topology and hostnames, which might be a security or privacy concern in some deployments. Organizations might choose to strip or modify this header for external-facing proxies to prevent internal network disclosure.

Forwarded

The Forwarded header is a standardized header defined in RFC 7239, intended to replace the de-facto X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto headers.

Purpose

It provides a more structured and extensible way to convey information about the original client, the proxy itself, and the original request context (host, protocol) to the upstream server.

Format and Examples

The Forwarded header can contain one or more sets of parameters, separated by commas, representing each proxy in the chain. Each set of parameters uses key-value pairs. Common parameters include:
* for: The IP address (or obfuscated identifier) of the original client.
* by: The IP address (or obfuscated identifier) of the proxy that forwarded the request.
* host: The original Host header requested by the client.
* proto: The original protocol (e.g., http or https) used by the client.

Forwarded: for=<client_ip>; proto=<protocol>; host=<original_host>
Forwarded: for=<client_ip>, for=<proxy_ip>; proto=<protocol>

Example 1: Single Proxy
A client (192.0.2.1) connects via HTTPS to a proxy (198.51.100.1) requesting example.com.
The proxy adds:

Forwarded: for=192.0.2.1; proto=https; host=example.com

Example 2: Multiple Proxies
Client (192.0.2.1) -> Proxy A (198.51.100.1) -> Proxy B (203.0.113.1) -> Origin Server.
1. Client to Proxy A: Proxy A adds Forwarded: for=192.0.2.1; proto=https; host=example.com.
2. Proxy A to Proxy B: Proxy B receives the header. Proxy B appends its own entry, including by to identify itself.
The header becomes:
Forwarded: for=192.0.2.1; proto=https; host=example.com, for=198.51.100.1; by=203.0.113.1
(Note: The host and proto parameters are typically only included in the first entry for the original client, unless a proxy performs a protocol or host rewrite.)

Comparison: X-Forwarded-For vs. Forwarded

Feature	X-Forwarded-For	Forwarded
Standard Status	De-facto standard (non-standard X- header)	RFC 7239 Standard
Information	Only client IP addresses	Client IP, proxy IP (by), original host, original protocol (proto)
Structure	Comma-separated list of IP addresses	Comma-separated list of structured key-value parameter sets
Extensibility	Limited to IP addresses	Highly extensible with additional parameters
Adoption	Widely supported by existing software and infrastructure	Growing adoption, but less ubiquitous than XFF currently
Security	Vulnerable to spoofing; requires careful parsing	Still vulnerable to spoofing; structured parsing aids robustness

Other Proxy Headers

X-Forwarded-Host

This de-facto header identifies the original Host requested by the client in the Host HTTP request header. It is useful when a proxy or load balancer modifies the Host header (e.g., for internal routing) before forwarding the request to the upstream server, but the application needs to know the original host requested by the client for tasks like generating absolute URLs or handling virtual hosts.

Example:
Client requests example.com. Proxy forwards to internal host app-server-1.

Host: app-server-1
X-Forwarded-Host: example.com

X-Forwarded-Proto

This de-facto header identifies the protocol (HTTP or HTTPS) that the client used to connect to the proxy or load balancer. This is crucial when the proxy performs SSL/TLS termination, meaning the client connects via HTTPS, but the proxy communicates with the backend server over plain HTTP. The application needs to know the original protocol to generate correct links (e.g., https:// instead of http://).

Example:
Client connects via HTTPS to a load balancer. Load balancer connects via HTTP to the backend.

X-Forwarded-Proto: https

X-Real-IP

This is another de-facto header, commonly used by NGINX, to convey the original client's IP address. Unlike X-Forwarded-For, it typically contains only a single IP address—that of the original client or the immediate upstream trusted proxy. It's often set by the first proxy in a chain after validating the X-Forwarded-For header.

Example:

X-Real-IP: 192.0.2.1

Practical Implications and Use Cases

Proxy headers are fundamental for proper operation and security in modern web architectures involving proxies, load balancers, and CDNs.

• Logging and Analytics: Accurate client IP addresses are essential for web server access logs, traffic analysis, and user behavior tracking.
• Security:
  • IP-based Access Control: Restricting access to certain resources based on client IP addresses.
  • Rate Limiting: Preventing abuse or DDoS attacks by limiting requests per client IP.
  • Web Application Firewalls (WAFs): Applying security rules based on the original client's identity.
  • Geolocation: Determining a user's geographical location for content customization or compliance.
• Application Logic:
  • URL Generation: Applications need X-Forwarded-Host and X-Forwarded-Proto to construct correct absolute URLs (e.g., for redirects or links within the application) that match the client's original request.
  • Session Management: Some session mechanisms might be tied to IP addresses.
  • Multi-tenant Applications: Distinguishing tenants based on the original Host header.
• Debugging and Troubleshooting: The Via header and the full X-Forwarded-For chain can help diagnose network path issues and identify problematic proxies.

Proxy Configuration and Security Best Practices

Configuring proxies to correctly handle these headers is crucial.

• Trust Boundaries: Only trust X-Forwarded-For (or Forwarded) entries from known and trusted upstream proxies. Implement logic to parse the header, identify trusted proxy IPs, and derive the true client IP from the rightmost untrusted entry.
• Header Stripping/Sanitization: For external-facing proxies, consider stripping or sanitizing Via headers and any internal custom X- headers to prevent information disclosure about internal network topology.
• Consistency: Ensure all proxies and load balancers in a chain are configured consistently to append or set these headers correctly.
• Standard vs. Custom: While Forwarded is the standard, X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto remain widely used. Implementations often support both or prioritize the Forwarded header if present.