Via header

Via is a standard HTTP header in which each intermediary records the protocol version it received the message on, together with a name for itself. It documents the path a message took, and it is defined for both requests and responses.

#What it records

RFC 9110 gives the grammar as a received-protocol, a received-by name and an optional comment. Each intermediary appends its own entry, so the list reads in the order the message travelled.

Via: 1.0 fred, 1.1 p.example.net

That example is from the specification: a request that passed through an HTTP/1.0 user agent’s internal proxy named fred and then a public proxy at p.example.net before reaching the origin.

#Pseudonyms and firewalls

A sender may replace the real host with a pseudonym where the hostname is sensitive, and a proxy acting as a portal through a firewall is told it should not forward the names of hosts behind that firewall unless explicitly configured to. A comment identifying the software is permitted but optional, and any recipient may remove it.

The practical consequence is that Via proves an intermediary existed, while telling you as little about it as its operator chose. Absence proves nothing at all, since the header can simply be stripped.

#Why it matters for proxy work

A proxy that adds Via announces itself to every destination. Whether that matters depends on the target: some sites ignore it and some treat it as a signal. Whether your provider adds it is a property of that deployment, not of the category you bought, so test it.

In a CONNECT tunnel the proxy has no request inside the tunnel to annotate, so the header cannot appear on the tunnelled traffic at all.

#Commonly confused with

X-Forwarded-For carries client addresses and is not standardised. Via carries intermediary names and protocol versions and is. A transparent proxy in the interception sense may add either, both or nothing, which is why neither header can be used as a reliable test for one.