---
title: "Transparent vs Anonymous vs Elite Proxies: The Differences"
description: "A transparent proxy forwards your real IP, an anonymous proxy hides it but reveals itself, and an elite proxy adds nothing. Three HTTP headers decide which."
url: https://proxynet.io/blog/anonymous-proxy-levels
date: 2026-09-19
author: "Acar Diveroli"
category: "Proxies"
lang: en
---

# Transparent vs Anonymous vs Elite Proxies: The Differences

Look at a proxy list or a provider's product page and you will see the labels "transparent", "anonymous" and "elite" next to the addresses. The third one also goes by "high anonymity". All three route your request through another server, but the request that reaches the target site is not the same: in one, your real IP address is written out as a line; in another, there is only a note saying "a proxy sits in between"; in the third, neither is present.

This post explains what decides the anonymity level, what the `Via`, `X-Forwarded-For` and `Forwarded` headers carry, and how the same request arrives at the target at each of the three levels. After that we cover why the levels lose their meaning for HTTPS and SOCKS5 traffic, how to see the level of your own proxy, and what the "elite" label does not guarantee. We ran the Python example at the end against a local test proxy at all three levels.

> **Note: Short answer**
>
> The level is assigned by the HTTP headers the proxy adds to your request. A **transparent proxy** passes your real IP address to the target in an `X-Forwarded-For` or `Forwarded` header. An **anonymous proxy** hides your address but gives itself away with a header such as `Via`. An **elite (high anonymity) proxy** adds neither; the target sees only the proxy's IP address. The distinction applies to unencrypted HTTP requests and describes headers only: the reputation, owner and history of the IP address are a separate matter.

## What is a proxy anonymity level?

A proxy is an intermediary server that forwards your request to the target on your behalf. Because the target site receives the connection from the proxy, it sees the proxy's IP address. We covered the general mechanics in [What Is a Proxy Server and How Does It Work?](/blog/what-is-a-proxy-server); the type table there sorts proxies by protocol, IP source and rotation. The anonymity level is a fourth question added to those three axes: **what does the proxy tell the target about you when it forwards the request?**

The answer is not in the IP address but in the header lines of the request. An HTTP proxy can open and read an unencrypted request and add lines to it before passing it on. Depending on what it adds, there are three outcomes:

- The target learns both that a proxy is in use and what your real IP address is (transparent).
- The target learns that a proxy is in use but not your real address (anonymous).
- The target learns nothing from the headers (elite).

That also gives the short answer to "what is an anonymous proxy?": a proxy that does not pass your real IP address to the target. Both the second and the third level fit this definition. In everyday use, "anonymous proxy" is mostly meant in this broad sense; the "anonymous" label on proxy lists has the narrow meaning of the second level, the proxy that hides your address but reveals itself.

This classification is not a standard. No RFC defines a term called "elite proxy"; the names are a habit of proxy list sites. What is standardised are the headers that produce the levels.

## Which HTTP headers decide the level?

### Via

`Via` records which intermediaries a request has passed through. [The Via section of RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-via) compares the header to the `Received` lines of email: each intermediary appends the protocol version it received the request with, and its own name, to the end of the list.

```text
Via: 1.1 proxy-a.example, 1.1 cache-2
```

The standard leaves no room for doubt here: a proxy must add an appropriate `Via` header to every message it forwards. The same section allows a pseudonym to be written instead of the real name when the host name is considered sensitive. So `Via` does not carry your real IP address; it only says "this request went through an intermediary". This is the header that produces the anonymous level. Proxies called elite never add this line, which means they knowingly do not follow that clause of the standard.

### X-Forwarded-For

`X-Forwarded-For` carries the IP address of the client that connected to the proxy. It never became an official standard, but in the words of [MDN's X-Forwarded-For page](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For) it is a de-facto standard. With more than one intermediary, the addresses are listed with commas: the client that started the request sits on the far left, the most recent intermediary on the far right.

```text
X-Forwarded-For: 203.0.113.7, 198.51.100.24
```

The header was born for load balancers and reverse proxies: the application behind them reads the visitor's address from this line. How far the target site can trust that line is covered in the "Can you trust the X-Forwarded-For header?" section of [Forward Proxy vs Reverse Proxy: What's the Difference?](/blog/forward-vs-reverse-proxy). On the forward proxy side the same line works in the opposite direction: if the proxy adds this header, the address you wanted to hide lands in the target's log as plain text. This is the header that produces the transparent level.

### Forwarded

`Forwarded` is the standardised form of the same job. [RFC 7239](https://www.rfc-editor.org/rfc/rfc7239) defines four parameters in a single header: `for` (who sent the request), `by` (the intermediary that received it), `host` and `proto`.

```text
Forwarded: for=203.0.113.7;proto=http;by=198.51.100.24
```

The RFC says that this header is optional and, because of the sensitivity of the information it carries, should be turned off by default. The introduction also contains a plain sentence: when the purpose of the proxy is to provide anonymity for the client, the proxy will not use this feature. Two halfway options are defined: the intermediary can write `for=unknown`, or use a random identifier that starts with an underscore (`for=_hidden`). In both cases the target does not learn your address but does learn that an intermediary is present, which corresponds to the anonymous level.

### Other traces

Tools that test proxy lists also look at a few non-standard lines: `X-Real-IP`, `Client-IP`, and `Proxy-Connection`, which the client sends to the proxy and a careless proxy forwards to the target unchanged. If they reach the target, they say one of the same two things: either your address, or that an intermediary is present.

## How does the same request reach the target at the three levels?

The journey of an unencrypted `http://` request goes like this:

1. The client sends the whole request to the proxy. The target address, the headers and the body, if any, are readable to the proxy.
1. The proxy authenticates you and strips only the lines meant for itself (such as `Proxy-Authorization`).
1. Depending on its configuration, it adds new lines to the request or adds nothing. The level is decided at this step.
1. It opens a new connection to the target from its own IP address and forwards the request.
1. The target sees two pieces of information together: the address the connection came from (the proxy's exit IP) and what the headers say.

We ran our local test proxy with three different configurations and sent the same request to an echo endpoint. An echo endpoint is a server that returns the headers it received as they are. With the client at `127.0.0.1` and the proxy's exit address at `127.0.0.2`, the three results are below; we trimmed unrelated lines such as `Accept`.

Transparent configuration:

```text
Host: 127.0.0.1:8318
User-Agent: python-requests/2.34.2
Via: 1.1 test-proxy
X-Forwarded-For: 127.0.0.1
Forwarded: for=127.0.0.1;proto=http
```

Anonymous configuration:

```text
Host: 127.0.0.1:8318
User-Agent: python-requests/2.34.2
Via: 1.1 test-proxy
```

Elite configuration:

```text
Host: 127.0.0.1:8318
User-Agent: python-requests/2.34.2
```

In all three cases the echo server reported that the connection came from `127.0.0.2`; the only difference was in the headers.

## What are the differences between transparent, anonymous and elite proxies?

| | Transparent | Anonymous | Elite (high anonymity) |
|---|---|---|---|
| IP the target sees | The proxy's address | The proxy's address | The proxy's address |
| Is the real IP in a header? | Yes (`X-Forwarded-For`, `Forwarded: for=`) | No | No |
| Do the headers show it is a proxy? | Yes | Yes (`Via`, `for=unknown`) | No |
| The `Via` rule in RFC 9110 | Followed | Followed | Not followed |
| Where you typically find it | School, office and hotel networks, cache servers | Proxy software whose defaults were partly changed | Commercial proxy services |
| Label on proxy lists | Transparent | Anonymous, "distorting" (the kind that writes a fake address) | Elite, high anonymity |

Because the names change from list to list, it is safer to look at the headers themselves than at the label. The in-between type called "distorting" writes a made-up address into the `X-Forwarded-For` line instead of the real one. From the target's point of view the result is the same as the anonymous level: it does not learn your address, but it learns that an intermediary exists.

## What is a transparent proxy and where do you meet one?

"Transparent proxy" is used in two separate senses, and the two are often mixed up.

The first is the network-level sense. Section 3.7 of RFC 9110, which describes intermediaries, calls a setup that the client did not choose, where the network redirects the traffic on its own, an "interception proxy", and notes that it is also commonly known as a "transparent proxy". According to the same section, it is most often found on public network access points that make you sign in before you get online, and within corporate firewalls that enforce usage policies. You configure nothing in your browser. We explained how these setups relate to firewalls in [Proxy vs Firewall: What's the Difference?](/blog/proxy-vs-firewall).

The second is the proxy-list sense: a proxy that passes your real IP address to the target in a header. The two senses usually meet on the same server, because a proxy on an organisation's network is not there to hide you; it is there for caching, filtering and logging.

A good example is Squid, the widely used open-source proxy software. According to [Squid's `forwarded_for` documentation](https://www.squid-cache.org/Doc/config/forwarded_for/) (the directive exists in v7 and earlier versions), the default value is `on`, in which case the client's IP address is appended to the `X-Forwarded-For` line. Set to `off`, the line goes out as `unknown`; set to `delete`, the header is removed entirely. In the same versions the `Via` header is also on by default. A proxy like this installed with default settings therefore works at the transparent level; whether a proxy is "anonymous" or "elite" does not come from the kind of software but from a few lines of configuration written by whoever runs it.

## What is an elite (high anonymity) proxy?

An elite proxy is one that, even on unencrypted requests, passes neither your address nor any trace of an intermediary to the target. It takes the request, strips the lines meant for itself, and sends the rest untouched from its own IP address.

In paid proxy services this behaviour is not a privilege but the normal state of things: a service that writes its customer's address to the target would make no sense. The word "elite" gets its real meaning on free lists: among those addresses are servers left on default settings, misconfigured or compromised, and nothing but the label tells you which of them adds headers. We covered the security side of those lists in [Are Free Proxies and Web Proxy Sites Safe?](/blog/are-free-proxies-safe).

Elite does not say that the proxy is fast, that the IP address is clean, or that your traffic is not being logged. It only says that two lines are absent from the forwarded request.

## Why do the levels lose their meaning with HTTPS and SOCKS5?

All three levels rest on the assumption that the proxy can read and modify the request. That assumption only holds for unencrypted HTTP.

For an HTTPS request the client tells the proxy, with the `CONNECT` method, "open a tunnel to port 443 of this server". According to RFC 9110, once the tunnel is established the proxy's job is limited to blindly relaying data in both directions. The TLS handshake takes place between the client and the target; the headers are inside the encrypted channel and the proxy cannot add lines to them. We tested this locally as well: the proxy in the transparent configuration added three lines to the `http://` request, and on an `https://` request through the same proxy not a single extra line reached the echo server. The exception is corporate inspection proxies that open the traffic and re-encrypt it; even they cannot do so without having their own root certificate installed on your device.

With SOCKS5 it is like this from the start. A SOCKS proxy does not speak HTTP, it carries bytes; there is no layer where it could add a header. We compared the two protocols in [SOCKS vs. HTTP Proxy: Which One Should You Choose?](/blog/socks-vs-http-proxy). As the web moved to HTTPS, the practical territory of the level distinction shrank to unencrypted pages, old APIs and the plain HTTP calls that devices make. Our [HTTPS Proxy](https://proxynet.io/https-proxy) and [SOCKS5 Proxy](https://proxynet.io/socks5-proxy) pages show which protocol fits which job.

This does not mean the target cannot work anything out over HTTPS. Only the header route is closed; the other signals described below stay in place.

## How do you see the level of your own proxy?

All you need is an echo endpoint. The open-source `httpbin.org` is widely used for this. Two details decide the result:

- **The address must start with `http://`.** On an `https://` address the proxy cannot add headers, so every proxy looks elite.
- **The `show_env=1` parameter must be added.** By default httpbin strips lines such as `Via` and `X-Forwarded-For` from its response. In a request without the parameter we could not see these headers in the response even though we had sent them; once we added the parameter they appeared.

To try it without writing code, set the proxy in your browser and open `http://httpbin.org/get?show_env=1`. In the `headers` section of the page, check whether there is a `Via` line or a line carrying your own address. On the command line the same request looks like this (cURL's proxy options are in [How to Use cURL with Proxy?](/blog/curl-proxy)):

```bash
curl -s -x http://user:pass@pr.proxynet.io:8000 "http://httpbin.org/get?show_env=1"
```

One detail can mislead you when reading the response: httpbin runs behind a load balancer, and that load balancer writes the address that connected to it into the `X-Forwarded-For` line. You will see this line even on a request without a proxy. If the line contains only the proxy's exit address, there is no leak; a leak is when your own address is in the line too.

The script below makes that distinction itself. It first learns your own address with a request that does not use the proxy, then goes to the same endpoint through the proxy and classifies the headers that arrived. Because it tries both addresses, it shows the effect of the tunnel.

```python
import requests

PROXY = "http://user:pass@pr.proxynet.io:8000"
ECHO_URLS = [
    "http://httpbin.org/get?show_env=1",   # plain HTTP: the proxy can read the request and add headers
    "https://httpbin.org/get?show_env=1",  # HTTPS: the request travels inside the CONNECT tunnel
]
# Known headers that intermediary servers add to a request
PROXY_HEADERS = ["via", "forwarded", "x-forwarded-for", "x-real-ip", "client-ip", "proxy-connection"]

def echo(url, proxies=None):
    """Return the address and the headers the echo endpoint saw."""
    data = requests.get(url, proxies=proxies, timeout=20).json()
    headers = {name.lower(): value for name, value in data["headers"].items()}
    return data["origin"], headers

def classify(real_ip, origin, headers):
    exit_ip = origin.split(",")[-1].strip()
    found = {name: headers[name] for name in PROXY_HEADERS if name in headers}
    # The load balancer in front of the echo service writes the exit IP into X-Forwarded-For; that is not a leak
    if found.get("x-forwarded-for", "").strip() == exit_ip:
        del found["x-forwarded-for"]
    if exit_ip == real_ip:
        level = "proxy not in use (the exit IP is your own address)"
    elif real_ip in origin or any(real_ip in value for value in found.values()):
        level = "transparent (the real IP reaches the target)"
    elif found:
        level = "anonymous (IP hidden, proxy visible)"
    else:
        level = "elite (no trace in the headers)"
    return level, exit_ip, found

def main():
    proxies = {"http": PROXY, "https": PROXY}
    for url in ECHO_URLS:
        real_ip = echo(url)[0].split(",")[-1].strip()  # request without the proxy: your own address
        level, exit_ip, found = classify(real_ip, *echo(url, proxies))
        print(f"{url}\n  exit IP: {exit_ip}\n  level  : {level}")
        for name, value in found.items():
            print(f"  {name}: {value}")

main()
```

When we ran the script with the transparent configuration of our local test proxy and a local echo server that answers in the same format, the output was:

```text
http://127.0.0.1:8318/get
  exit IP: 127.0.0.2
  level  : transparent (the real IP reaches the target)
  via: 1.1 test-proxy
  forwarded: for=127.0.0.1;proto=http
  x-forwarded-for: 127.0.0.1
https://127.0.0.1:8319/get
  exit IP: 127.0.0.2
  level  : elite (no trace in the headers)
```

In the anonymous configuration only the `via` line remained in the first block, and in the elite configuration no line was listed. The second block was identical in all three configurations. The other checks, such as speed, location and DNS, are laid out in order in [Is My Proxy Working? How to Test a Proxy](/blog/how-to-test-a-proxy).

## Why is the "elite" label not a guarantee?

Sites rarely need headers when they decide whether a connection comes from a proxy. They hold information that is independent of headers and that the proxy cannot change:

- **The owner of the IP address.** Every address block is registered to an organisation. If the block belongs to a hosting company, the connection counts as "server traffic" no matter how clean the headers are. How that record is read is explained in [ISP vs Residential Proxies: Which One Should You Choose?](/blog/isp-vs-residential-proxy).
- **The reputation of the address.** IP intelligence services score addresses by their past behaviour. How the score is built is in [What Is an IP Fraud Score and How Do You Read It?](/blog/ip-fraud-score).
- **Blacklists.** An address that was abused in the past can stay listed whoever uses it today. Details are in [What Is an IP Blacklist and How Do You Get Delisted?](/blog/ip-blacklist).
- **Consistency.** If the country of the IP address does not match the browser's time zone or language, or if the browser exposes the real address by another route, that is noted. See [WebRTC and DNS Leaks: What They Are and How to Stop Them](/blog/webrtc-dns-leak).

That is why "elite" addresses from free lists give the worst result in practice: their headers are clean, but because the address was published on a list open to everyone, it has most likely entered IP databases as an "open proxy". If you see an "Anonymous proxy detected" warning on screen, this is usually the reason too: the site did not read a header, it looked your address up in a database. If you get this warning without using a proxy at all, the likely causes and what to do are laid out step by step in [VPN or Proxy Detected Error: What It Means and Why](/blog/vpn-or-proxy-detected).

Clean headers are necessary, because a proxy that forwards your address as a line fails its purpose from the outset. They are not sufficient: how a site will judge your connection is decided less by the level than by who the IP address belongs to and what its history is. A platform's terms of use also apply unchanged behind a proxy.

## Which level matters for which job?

- **Threat intelligence and OSINT research:** The organisation address of a security team examining a suspicious server should not land in that server's log. A transparent configuration does exactly the opposite. The setup for this work is on our [data security solution](/data-security) page.
- **Price and stock tracking on public data:** Your own office address should not travel to the target as a line; a [Residential Proxy](https://proxynet.io/residential-proxy) that adds no headers is the usual tool for this job.
- **Logged-in, long-running sessions:** As much as the level, it matters that the address stays the same. [ISP Proxy](https://proxynet.io/static-isp-residential-proxy) gives you a fixed address registered to a service provider.
- **Ad verification and localisation testing:** If you are measuring how a page looks to an ordinary visitor in that country, a request carrying a `Via` line tells the target "I came through an intermediary", and the measurement stops representing that visitor.
- **Restricting access to your own API:** If the allowlist works by IP, the address the connection comes from decides, not the headers; details are in our post on [static IPs for API access](/blog/static-ip-for-api-access).

## Common mistakes

- **Testing the level with an `https://` address.** No header can be added inside the tunnel, so every proxy comes out elite and the test tells you nothing.
- **Forgetting the `show_env=1` parameter on httpbin.** The `Via` and `X-Forwarded-For` lines are stripped from the response and a transparent proxy looks clean.
- **Confusing the "elite" label with IP quality.** The label describes headers; it does not say whether the address is on a blacklist.
- **Leaving a proxy you set up yourself on default settings.** In widely used proxy software, forwarding the client address is the default behaviour.
- **Looking only at headers and forgetting the browser side.** An address exposed through WebRTC or DNS makes the cleanest headers meaningless.

## Decision guide

| Need | Recommendation |
|---|---|
| Content filtering or caching on a school or company network | Transparent proxy; nothing is being hidden from the user |
| Keeping your own address from reaching the target | A service that adds no headers (elite); confirm it with an `http://` echo test |
| Working only with HTTPS sites | No level difference arises; choose by IP type and location |
| Judging an "elite" address found on a list | Do not use it; even with clean headers the address is most likely flagged, and your traffic passes through a stranger's server |
| Understanding an "Anonymous proxy detected" warning | An IP reputation issue, not a header issue; see [our post on it](/blog/vpn-or-proxy-detected) |
| Setting up a proxy on your own server | Choose the client address and `Via` directives in the config file deliberately, then run an echo test |

## Frequently asked questions

### What does anonymous proxy mean?

It means a proxy that does not pass your real IP address to the target site. The site sees the connection coming from the proxy's address. In the narrow sense, that is the "anonymous" label on proxy lists, it describes the second level: a proxy that hides the address but reveals itself with a header like `Via`.

### What is the difference between an elite proxy and an anonymous proxy?

Both hide your real address. The difference is a single line: an anonymous proxy leaves an intermediary trace on the request (`Via`, `Forwarded: for=unknown`), an elite proxy does not. In the first case the target site reads "this request went through a proxy" from the headers; in the second it cannot read that from the headers.

### Does a transparent proxy hide my IP address?

No. The target receives the connection from the proxy's address, but your real address is written in the `X-Forwarded-For` or `Forwarded` line and ends up in the server log.

### If I use an elite proxy, can the site not tell that I am using a proxy?

It cannot tell from the headers, but it can tell in other ways: the IP address being registered to a hosting company, its reputation score, blacklist entries and inconsistent signals from the browser are all independent of headers.

### Does the proxy level matter on HTTPS sites?

In practice, no. An HTTPS request travels inside the `CONNECT` tunnel and the proxy cannot add headers to encrypted traffic. The difference only shows up on unencrypted `http://` requests.

### How do I find out my proxy's level without writing code?

Set the proxy in your browser and open `http://httpbin.org/get?show_env=1`. If the `headers` section of the response contains `Via`, the proxy is revealing itself; if any line contains your own IP address, it is working at the transparent level. If neither is there, it leaves no trace at header level.

## Summary

The transparent, anonymous and elite distinction is three answers to one question: what does the proxy add to an unencrypted request when it forwards it? If it adds your real address it is transparent, if it adds only an intermediary trace it is anonymous, if it adds nothing it is elite. `Via` is defined in RFC 9110 and `Forwarded` in RFC 7239; `X-Forwarded-For` is a de-facto standard. With HTTPS and SOCKS5 the proxy cannot touch the headers, so the distinction disappears by itself. You can verify the level in a few seconds with an echo test on an `http://` address. The result promises nothing on its own: in a site's assessment the real weight lies with the owner and the history of the IP address. You can compare the IP type that suits your work on our [proxy services](/proxy) page.