Try 500 MB of US mobile proxy data free for 30 days.Start free trial
October 27, 202614 min read

HTTP Proxy Headers: What They Do and How to Handle Them

Geometric illustration of a proxy boundary

HTTP proxy headers are the request and response fields that tell a proxy, or the server behind it, how a message got where it is. Some are meant only for the proxy (Proxy-Authorization). Some are added by the proxy for the destination (X-Forwarded-For, Forwarded, Via). Others pass through untouched. Knowing which is which explains most 407 errors, most "why does the site see my real IP" bugs, and most scraper fingerprint problems.

This guide covers the headers you will actually meet, what a proxy does to each one, how to see what the destination receives, and where the security traps are. We build mobile proxy infrastructure at Masklabs, so the examples lean toward scraping and automation, but the header rules apply to any HTTP proxy.

TL;DR

  • Proxy-Authorization is for the proxy only. It carries your credentials and should never reach the destination server.
  • X-Forwarded-For, Forwarded and Via are added by proxies to describe the path. A well-configured outbound proxy used for scraping should not leak your origin through them.
  • Hop-by-hop headers (Connection, Keep-Alive, Proxy-Authorization, Transfer-Encoding) apply to one connection, not the whole route.
  • Trust forwarded headers only from proxies you control. Anyone can spoof X-Forwarded-For.
  • Test with a header-echo endpoint and compare what you sent with what arrived.

Table of Contents

What proxy headers are

Every HTTP message carries headers: name and value pairs that describe the message. MDN groups them by function, and for proxies the useful split is by how far a header travels.

  • End-to-end headers are meant for the final recipient and must be passed on unmodified. Accept, User-Agent, Cookie and Authorization are typical examples.
  • Hop-by-hop headers are meaningful only for a single transport-level connection. A proxy consumes them and does not pass them on.
  • Proxy-added headers such as Forwarded and Via exist so intermediaries can describe the request path to the server.

The client-to-proxy connection and the proxy-to-server connection are separate. The proxy can use a different protocol version, different TLS settings and even different header values on each side. Microsoft's YARP guidance states this plainly: the two connections are independent, and the proxy filters headers that could affect forwarding or transport.

That independence is the whole reason "proxy headers" is a distinct topic. A header you set in your code may be consumed, replaced or supplemented before it reaches the website.

HTTP and HTTPS: where headers are visible

Whether the proxy can read and change headers depends on how you reach the destination.

Plain HTTP through a proxy. The client sends the full request to the proxy, using an absolute URL in the request line. The proxy sees every header and can add, drop or rewrite any of them.

HTTPS through a proxy. The client sends a CONNECT request to the proxy, naming the destination host and port. The proxy sees that CONNECT request, including Proxy-Authorization, then opens a tunnel. The encrypted traffic inside the tunnel, with its own headers, is not readable by the proxy unless it does TLS interception. So headers like User-Agent and Cookie go to the destination exactly as your client set them, and the proxy cannot append X-Forwarded-For to them.

Header visibility in HTTP and HTTPS proxy routes

This matters for scraping. With a CONNECT tunnel, the destination sees only the proxy's exit IP as the connection source, and the headers are fully under your control. If you want a deeper comparison of the two proxy types, our guide to HTTP vs HTTPS proxy decision rules walks through it.

The Proxy-Authorization header

When a proxy requires credentials, it answers with status 407 Proxy Authentication Required and a Proxy-Authenticate header naming the accepted scheme. The client then retries with a Proxy-Authorization header. MDN describes it as the request header that carries the client's credentials to the proxy, usually after that 407 challenge. It can hold credentials for schemes such as Basic, Digest or Bearer, depending on what the proxy demands.

An example from MDN:

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

The value after "Basic" is the base64 encoding of username:password. Base64 is an encoding, not encryption. Anyone who can read the request can decode it in one line.

Who sees it, and who should not

RFC 7235 defines Proxy-Authorization as applying to the next inbound proxy that demanded authentication, and it is consumed by the first inbound proxy expecting credentials. Proxies may relay credentials only when they cooperatively authenticate a request. In practice, the destination website should never see this header. If it does, something in your chain is misconfigured, and your proxy credentials may be exposed.

The same RFC warns that the HTTP authentication framework does not itself keep credentials confidential. The underlying connection has to be secured, for example with TLS. With a Basic scheme over a plain-HTTP proxy connection, your username and password cross the network in readable form. For the mechanics of the challenge-response exchange and the schemes involved, this overview of proxy authentication schemes is a handy companion.

Sending it with curl and code

Most clients build the header for you when you put credentials in the proxy URL:

curl -x http://USER:[email protected]:8080 https://example.com

If you need to send a custom header to the proxy rather than the destination, curl has a separate --proxy-header option, because plain --header goes to the remote server. This distinction is easy to miss, and it is the cause of many "my header never reached the proxy" reports.

When you get a 407 even though the credentials look right, check these in order:

  1. The proxy URL scheme matches what the proxy speaks (http:// for an HTTP proxy, even when you request https:// sites).
  2. Special characters in the password are percent-encoded in the URL.
  3. Your HTTP library actually sends credentials on the CONNECT request, not only on the tunneled request.
  4. The scheme the proxy challenged with is one your client supports.

We cover the full debugging flow in Fix 407s: HTTP proxy authentication with curl and RFCs, and for specific stacks in the guides for C# HttpClient and Java and Apache HttpClient.

X-Forwarded-For, Forwarded and Via

These three headers describe the path a request took. They are the ones that decide whether a destination can tell you are behind a proxy, and what it can learn about your origin.

X-Forwarded-For

X-Forwarded-For (XFF) is a de facto standard for identifying the originating IP address of a client connecting to a web server through a proxy. It was never an official standard, but nearly every load balancer, CDN and reverse proxy supports it.

The value is a comma-separated list. Assuming well-behaved clients and proxies, the client IP comes first, followed by each proxy IP the request passed through:

X-Forwarded-For: 203.0.113.50, 198.51.100.17

Here 203.0.113.50 is the original client, and 198.51.100.17 is an intermediary. The IP of the last proxy is usually not in the header at all. The server sees it as the TCP connection's remote address.

So X-Forwarded-For is often a list, not a single IP. Code that reads the whole header as one address breaks the moment a second proxy joins the chain.

Forwarded

Forwarded is the standardized replacement. It carries information that may be altered or lost when proxies are involved: the original client IP, host and protocol. It uses semicolon-separated key-value pairs with the parameters by, for, host and proto:

Forwarded: for=203.0.113.50;proto=https;by=198.51.100.17

The two headers carry similar data. Forwarded is cleaner to parse, but X-Forwarded-For remains far more common in the wild.

Via

Via records the protocol version and name of each intermediary the message passed through. It is mostly diagnostic, and it also helps spot proxy loops.

Quick reference

HeaderAdded byTravels toContainsMain risk
Proxy-AuthorizationClientProxy onlyCredentialsExposure if sent over plain HTTP or forwarded on
X-Forwarded-ForProxy or load balancerDestinationClient IP, then proxy IPsSpoofing, origin leak
ForwardedProxyDestinationfor, by, host, protoPrivacy leak of client IP
ViaProxyDestinationProtocol and proxy namesReveals that a proxy exists
Proxy-AuthenticateProxyClientAccepted auth schemeNone, informational

What a proxy does to your headers

Proxy behavior falls into four patterns. Which one you get depends on the proxy type and its configuration.

1. Strip hop-by-hop headers. A compliant proxy removes headers that apply only to one connection. MDN's header reference lists these as hop-by-hop; typical members are Connection, Keep-Alive, Proxy-Authorization and Transfer-Encoding. Passing them along can confuse message framing and cause interoperability and security problems.

2. Add forwarding headers. Reverse proxies and load balancers usually append the client's IP to X-Forwarded-For or add a Forwarded entry. They do this so that the application behind them can see the real client and respond correctly.

3. Replace instead of append. YARP, for example, by default removes existing forwarded headers and replaces them with its own. That is a deliberate defense: a client-supplied X-Forwarded-For value is not carried forward as if it were true.

4. Pass through untouched. A CONNECT tunnel never edits the inner request. An anonymizing forward proxy, which is what you use for scraping, should neither add your origin IP nor tell the destination that a proxy is in use.

The practical point from Microsoft's guidance: forwarding the original request information through standardized headers lets the destination app generate correct response headers, such as Set-Cookie or Location. That is useful for reverse proxies in front of your own apps. For outbound scraping it is the opposite of what you want.

Headers that matter for scraping and data collection

If you collect data through proxies, three things matter: not leaking your origin, looking consistent, and not breaking the session.

Do not leak your origin

A proxy that adds X-Forwarded-For with your real IP defeats the purpose of using it. This is the difference between a transparent proxy, an anonymous one and a high-anonymity one. Before running a job at scale, send a test request and inspect what arrives. The checks below show how.

Keep the headers consistent

A real mobile browser sends a coherent set: a matching User-Agent, Accept-Language, Accept-Encoding and, on modern browsers, client hint headers. Setting only User-Agent and leaving the rest at library defaults is a common reason requests get flagged. The IP type matters too. Requests from real carrier IPs paired with a plausible mobile header set look like ordinary mobile traffic, whereas datacenter IPs with a bare library User-Agent are easy to classify.

Do not mix up sticky sessions with header state

Cookies and tokens are end-to-end headers. If your rotating proxy changes the exit IP between requests but your cookie jar expects one identity, the site sees a session that teleports. Use sticky sessions for multi-step flows (login, cart, pagination) and rotating sessions for independent page fetches. Our session management tips cover how long to pin an IP and when to rotate.

How to see what the server receives

You cannot reason about proxy headers without looking at them. Three approaches work well.

  1. Verbose client output. curl -v -x http://USER:[email protected]:8080 https://example.com prints the CONNECT request, the proxy's response (watch for 407) and the request headers sent inside the tunnel.
  2. A header-echo endpoint. Send a request through the proxy to a service that returns the headers it received. Compare against what your client sent. Anything extra, such as Via or X-Forwarded-For, was added in the middle.
  3. Browser developer tools. The Network tab shows request and response headers for browser sessions. When you drive Chrome through a proxy, the Chrome proxy flags determine which connections go through it.

Then run this checklist on the echoed output:

  • Is your real IP present anywhere (X-Forwarded-For, Forwarded, custom headers)?
  • Is Proxy-Authorization absent? It should be.
  • Is there a Via header? If so, the proxy announces itself.
  • Do Accept-Language and the User-Agent match the geography and device you intend?

When something fails and you do not know where, the layered approach in proxy error troubleshooting helps separate DNS, TCP, TLS, proxy auth and target-site problems.

Security and privacy precautions

Headers that describe the path are also headers that can be forged or that expose data.

Spoofing. The destination app should be careful about how much trust it places in forwarded headers; YARP's guidance flags them as subject to spoofing attacks. MDN adds a concrete consequence: untrusted X-Forwarded-For values can be spoofed to avoid rate limits or bypass access controls. If you run a service behind a proxy, take the client IP only from entries added by proxies you operate, counting from the right-hand end of the list, never from the leftmost value alone.

Privacy. RFC 7239 notes that Forwarded exposes privacy-sensitive data such as the client IP, which may uniquely identify a client or its network operator. It also says Forwarded should never be copied into response messages, and that obfuscated identifiers can help conceal internal network structure.

Credentials. Use TLS to the proxy where available, keep credentials out of logs and shared repositories, and issue per-team or per-project credentials so you can revoke one without breaking everyone else.

Security and privacy precautions — overview diagram

Our perspective

We see header problems from both sides: customers debugging 407s, and customers whose scrapers get blocked despite a clean IP. Three patterns repeat.

First, most "proxy not working" tickets are authentication or protocol mismatches, not network failures. A wrong scheme in the proxy URL or an unencoded character in the password accounts for a large share of them, and a verbose curl call finds either in seconds.

Second, the IP is only half of looking authentic. Real US carrier IPs get you the right network identity, but the headers on top need to match. We built Masklabs around real mobile carrier IPs, city-level targeting, sticky or rotating sessions and HTTP, HTTPS and SOCKS5 support, so the network side is handled. Your client still has to send a coherent header set.

Third, test before scale. A ten-request test through the proxy to an echo endpoint costs almost nothing in metered data. Finding a leaked header after a million requests costs a lot more.

— Jon

Using headers cleanly with Masklabs

With Masklabs you get self-serve credentials, a usage dashboard and HTTP, HTTPS and SOCKS5 endpoints that work from Python, Node.js, Java, C#, Rust and browser automation tools. You can pick sticky or rotating sessions and target one of 46 US cities, with billing metered per byte, so a header test run uses very little of your data pool.

Plans are published at Masklabs pricing: Starter is $30 per month, Basic is $100 per month, Advanced is $500 per month and Scale is $1,000 per month, with a free trial that includes limited data. If you are comparing tools first, the 8 proxy API features post lists what to check. You can also see the full product on the US mobile proxies page.

What port 8080 means for an HTTP proxy

Port 8080 is not required and not special to proxies. It is registered with IANA as an alternate HTTP port, commonly called http-alt, and it is widely used for web proxies, caching servers such as Squid, and development or admin interfaces. One practical reason: ports above 1024 can be bound without elevated privileges, and port 80 is often taken already.

A proxy can listen on any port its operator chooses. Always use the host and port your provider gives you, and do not assume 8080 works. Note also that 8080 itself carries cleartext HTTP, so encryption comes from TLS on the tunnel or the proxy connection, not from the port number.

FAQ

What are proxy headers?

They are HTTP header fields that deal with intermediaries: ones addressed to the proxy (Proxy-Authorization, Proxy-Authenticate) and ones the proxy adds for the destination (X-Forwarded-For, Forwarded, Via). Each describes who the client is, which route the request took or how to authenticate.

Does the destination website see my Proxy-Authorization header?

It should not. Proxy-Authorization is a hop-by-hop header that the first proxy expecting credentials consumes. If a destination echoes it back, your chain is misconfigured and you should rotate the credentials.

Why is X-Forwarded-For a list of IPs?

Each proxy in the chain appends the address it received the request from. The leftmost entry is the claimed client and the rest are intermediaries. For security decisions, trust only entries added by proxies you control, because a client can send a fake header.

How can I view my HTTP headers?

Use curl -v for command-line requests, the Network tab in browser developer tools for browsers, or a header-echo endpoint to see what the server received through your proxy. Compare the three views to find headers that were added or removed along the way.

Is Forwarded better than X-Forwarded-For?

Forwarded is the standardized version, with a structured syntax using for, by, host and proto. X-Forwarded-For is still more widely supported, so many stacks read both. Use whichever your infrastructure supports, and apply the same trust rules to each.

Sources

Recommended