Elite proxies are the highest anonymity level: they do not expose proxy-identifying headers and make traffic appear to come from the proxy IP itself. Today, almost all commercial proxy services ship their endpoints configured to this elite level by default. If a target flags you, it is usually due to IP reputation or fingerprinting, not easy header tells. See the full model in Proxy Anonymity Levels.
What is an elite proxy?
Elite proxies remove proxy-identifying headers and show the proxy’s IP as the source.
They make requests look like a normal client from that IP, so detection shifts to reputation and fingerprints rather than headers.
Elite is commonly called “high anonymity.” Unlike lower levels, it aims to be header-clean in all paths. In practice, that means no X-Forwarded-For, no Via, and no Forwarded getting to the destination.
How elite differs from transparent, distorting, and anonymous
Elite hides both your real IP and the fact that a proxy is in use.
Transparent passes the client IP, distorting forges an IP, and anonymous hides the client IP but still leaks that a proxy is present.
Because elite strips headers, simple WAF rules that key on proxy headers do not work. Sites must rely on IP reputation, TLS and TCP fingerprints, and traffic behavior to tell.
Header behavior matrix
Elite removes proxy headers and shows only the proxy IP to the target.
Lower levels either pass your IP or announce themselves through headers.
| Header or Signal | Transparent | Distorting | Anonymous | Elite |
| X-Forwarded-For | Real client IP | Fake IP | Usually absent | Absent |
| Forwarded | Often present | Often present | Often present | Absent |
| Via | Often present | Often present | Present | Absent |
| IP seen by target | Client IP | Fake IP | Proxy IP | Proxy IP |
| “Proxy in use” header | Yes | Yes | Likely | No |
Elite over HTTP vs HTTPS CONNECT
HTTPS CONNECT avoids HTTP proxy headers by tunneling TLS end to end.
Plain HTTP requires strict header scrubbing to stay elite.
In HTTP mode, the proxy must not forward or append any proxy headers. In HTTPS CONNECT mode, the origin never sees HTTP proxy headers from your hop, but any upstream terminator can still add them. See background in the HTTP and HTTPS proxy guide.
SOCKS and “headerless” transport
SOCKS4/5 forwards TCP or UDP and does not add HTTP headers.
That makes elite behavior simpler to achieve, though reputation and fingerprints still apply.
If your tool supports SOCKS5 with hostname resolution, you avoid HTTP-layer header pitfalls entirely. See SOCKS details.
Where elite still gets detected
Elite removes header tells, not deeper network signals.
Common flags are IP reputation, TLS fingerprints, TCP quirks, and traffic patterns.
Typical signals include ASN and range history, JA3 or JA4 style TLS hashes, initial TCP parameters, synchronized request bursts, identical client stacks, and known automation fingerprints. Good IP pools and realistic client behavior still matter.
“False elite” pitfalls
If headers reappear, something upstream is re-inserting them.
CDNs, reverse proxies, or chained gateways can add Via or Forwarded back in.
Periodic verification against echo endpoints is essential. Always test both HTTP and HTTPS CONNECT paths, and repeat through any load balancers you control.
Quick tests you can run
Echo checks must show no proxy headers and the visible IP must be the proxy’s.
Run both HTTP and HTTPS CONNECT to cover header and tunnel paths.
# HTTP path
curl -s https://httpbin.org/anything -x http://PROXY:PORT | jq '.headers'
# HTTPS CONNECT path
curl -s https://httpbin.org/anything -x http://PROXY:PORT --proxytunnel | jq '.headers'
# SOCKS5 path
curl -s https://httpbin.org/anything --socks5-hostname PROXY:PORT | jq '.headers'
You should not see X-Forwarded-For, Forwarded, or Via in any output.
Minimal configs to keep headers clean
These snippets show how to avoid proxy-identifying headers in HTTP mode.
Treat them as starting points and adapt to your stack.
Squid 6.x
via off
forwarded_for off
request_header_access X-Forwarded-For deny all
request_header_access Forwarded deny all
request_header_access Via deny all
reply_header_access Via deny all
Nginx (HTTP forward proxy)
proxy_set_header X-Forwarded-For "";
proxy_set_header Forwarded "";
proxy_set_header Via "";
more_clear_headers 'X-Forwarded-For' 'Forwarded' 'Via';
HAProxy 2.8
option http-buffer-request
http-request del-header X-Forwarded-For
http-request del-header Forwarded
http-request del-header Via
mitmproxy 10+ addon
from mitmproxy import http
def request(flow: http.HTTPFlow):
for h in ["x-forwarded-for", "forwarded", "via"]:
flow.request.headers.pop(h, None)
Troubleshooting
Headers are clean but the site still says “proxy detected.”
That is likely reputation or fingerprint based, not a header leak.
My real IP shows at the target.
Either you are not going through the proxy or the proxy is transparent or distorting on that path.
Headers are clean on CONNECT but not on HTTP.
Migrate to CONNECT or SOCKS, or fix the HTTP proxy’s header policy and any upstreams that re-add headers.
When to choose elite
Use elite whenever a target blocks based on proxy headers.
Elite does not overrule IP-based limits or behavioral scoring, so pair it with clean ranges, sensible pacing, and realistic client stacks.
In day-to-day practice, elite is the default choice and, again, it is what almost all providers sell by default today.
FAQs
Are elite proxies undetectable?
No. They block simple header checks, but IP reputation and fingerprints can still flag traffic.
Does HTTPS CONNECT make any proxy elite automatically?
No. CONNECT hides HTTP proxy headers, but later hops can still add them. Reputation and fingerprints still apply.
Is SOCKS always better for elite behavior?
SOCKS avoids HTTP headers, which helps, but you still need quality IPs and realistic clients.
How do I verify an elite claim quickly?
Run echo tests over HTTP, HTTPS CONNECT, and SOCKS. None should show Via, Forwarded, or X-Forwarded-For.
Why would headers appear intermittently?
Multi-hop paths, CDNs, or configuration drift can re-insert headers on some requests. Re-test after any routing or config changes.