When you send a request through a proxy, the request that reaches the target server is no longer the one you sent. The proxy steps in, alters some headers and often adds new headers. These added headers clearly give away that you are using a proxy — and sometimes your real IP address.
This is precisely the technical basis of the anonymity level concept. In this article we cover which headers are added, what they mean and how to verify your own connection.
Three Main Headers
If this header is present and contains your real IP, the proxy falls into the "transparent" class and provides no anonymity.
| Header | Standard? | What it carries | Effect on anonymity |
|---|---|---|---|
X-Forwarded-For | De facto standard | Client IP chain | Can expose the real IP |
Forwarded | RFC 7239 | for, by, proto, host | Carries the same information in structured form |
Via | RFC 9110 | Name and version of intermediaries | Does not give the IP but reveals the presence of a proxy |
X-Real-IP | Common usage | A single client IP | Can expose the real IP |
X-Proxy-ID / Proxy-Connection | Non-standard | Traces of the proxy software | Reveals the presence of a proxy |
Anonymity Levels Arise From These Headers
The three levels used in the industry are defined directly by the presence of these headers:
Elite level does not mean "undetectable"; it only means that no trace is left at the header level . Other signals such as IP reputation and TLS fingerprint are still present.
Our article covering the levels in a broader frame, proxy anonymity levels explains which level suits which job. To test the level of your own connection our anonymity test tool you can use.
Where Do the Headers Come From?
The one adding these headers is not always the proxy you are using. There can be multiple intermediaries in the chain:
Every intermediary can add its own trace. The list of headers reaching the target's application layer is the sum of this entire chain.
Especially if you are working on a corporate network, an intermediary outside your control X-Forwarded-For may be adding it. In that case, even if the proxy you bought is elite, the intermediary at the start of the chain exposes your identity.
How Do You Verify Your Own Connection?
The way to verify is to use an endpoint that reflects exactly how your request looks on the other side. In the industry, such endpoints are called proxy judge ; they echo back every header they receive as plain text.
Put the two outputs side by side. Every extra header that appears in the request going through the proxy is the trace you leave behind.
If you do not want to deal with it manually our anonymity test page does this comparison for you and reports the level. To see only your exit IP and its location My IP Address is enough.
The Situation Changes With HTTPS
An important detail: on HTTPS traffic, the proxy cannot touch the body or the headers. In the tunnel established with the CONNECT method, the proxy only carries encrypted bytes; X-Forwarded-For cannot be added — it cannot even see the request.
For this reason, the concern "will a transparent proxy leak my IP" is largely invalid on HTTPS sites — but entirely valid on plain HTTP sites.
Even though the proxy cannot touch the headers, it sees the domain name in the CONNECT line and the SNI field in the TLS handshake. In other words, which site you visit is known by the proxy on HTTPS too. What is encrypted is what you do, not where you go .
Reading It Correctly on the Server Side
The other side of the coin: if you are trying to read the real visitor IP on your own server, these headers are vitally important — but unreliable. X-Forwarded-For can be fabricated by the client.
- Only trust the value coming from an intermediary you trust. If your reverse proxy writes it itself, the rightmost value is reliable.
- Read the chain from the right. The rightmost one is the intermediary closest to you and the most trustworthy.
- Define a list of trusted proxies. In Nginx,
set_real_ip_from, and the "trusted proxies" setting in application frameworks, exist for this. - Do not base rate limiting and blocking decisions on the raw header; an attacker can write the header however they like.
Header Hygiene and Fingerprinting
Getting rid of proxy headers is not enough on its own. Target sites look at other signals too when classifying requests:
| Signal | What gives it away | How to manage it |
|---|---|---|
| Header order | Library signature (requests, curl) | Mimic the browser's header order |
| User-Agent inconsistency | Old version or fake value | Use a real and up-to-date value |
| Accept-Language | Mismatch with the IP's country | Send a language matching the exit country |
| TLS fingerprint (JA3) | Client library | A browser engine or a compatible client |
| IP reputation / ASN | Datacenter origin | Residential or ISP pool |
In other words, even an elite proxy is still easily classified if it exits from a datacenter ASN. On this subject our residential proxy and ISP proxy pages explain why the source ASN is decisive.
Summary
X-Forwarded-For, Via and similar headers are the most visible traces a proxy leaves behind, and they form the technical definition of the anonymity level. On plain HTTP traffic they can expose your real IP; on HTTPS the proxy cannot touch these headers. To see your own situation The anonymity test run it, verify your exit IP with My IP Address and check whether you leave traces on the DNS side DNS leak test to check the anonymity level.