Invita a un amigo: ganas el 15% de cada pedido y él un 10% de descuento
InicioGlosarioX-Forwarded-For
Glosario

X-Forwarded-For

A header that records the chain of addresses a request passed through. When a proxy adds your own address to it, the proxy has announced you.

X-Forwarded-For exists for infrastructure that sits in front of a server on purpose: load balancers and reverse proxies add the client address so the application behind them knows who called. In that direction it is useful and expected.

In the other direction it is a leak. A forward proxy that adds your real address to the header hands the destination exactly what you were paying not to hand over. This is the mechanism behind the old distinction between transparent, anonymous and elite proxies: what they write into the headers on the way out.

The header is also trivially forgeable, which is why servers that care do not trust it blindly. A site behind its own load balancer reads only the entry its own infrastructure appended and ignores whatever arrived from outside.

For anyone buying proxies the practical content of the term is one check: send a request through the exit to something that echoes headers, and look at what arrived. If your own address is in there, nothing else about the setup matters.

Who writes it and who reads it

The header carries a comma-separated list, appended to by each hop that chooses to participate. Reading it left to right gives the original client first and the most recent hop last, which is only true if every hop was honest.

Because any client can send the header itself, its contents are untrusted input. Applications that use it correctly count hops from their own edge inward and discard the rest.

Related headers behave the same way: Forwarded, X-Real-IP, Via and Client-IP all carry the same risk when a forward proxy fills them in.

Checking your exit in one request

Any endpoint that echoes headers will do. What matters is what is not there:

What your exit sends

# ask an echo service what it received
curl -s -x login_c_US:password@proxy.sotaproxy.com:10000 https://httpbin.org/headers

# and the same through a static address
curl -s -x login:password@YOUR-ISP-IP:50100 https://httpbin.org/headers

# your own address, for comparison
curl -s https://api.ipify.org
  • Your own address should appear nowhere in the echoed headers. If it does, the exit is transparent and the geography you bought is decoration.
  • Via and X-Real-IP are worth checking in the same request; a proxy can be clean on one header and not on another.
  • The check takes seconds and is worth repeating after any change to your client, because libraries sometimes add these headers themselves.

What the header does and does not prove

Its absence does not prove anonymity

It proves this one leak is closed. Fingerprints, cookies and behaviour are separate questions.

Its presence is not always a proxy leak

A site behind a load balancer appends its own entry. What matters is whether your address is in the list.

It is not authentication

Anyone can send any value. A site that trusts it for access control has a bug rather than a feature.

It is not the only leak

DNS resolution outside the tunnel exposes the same information by another route.

¿Listo para usar x-forwarded-for?

SotaProxy te da acceso a proxies residenciales rotativos, móviles, de centro de datos e ISP. Sin compromiso mínimo.

Empezar