Via general both

What it does

Via records the intermediate proxies and gateways a message passed through on its way from client to server (or server to client). Each proxy that forwards the message appends its own entry. By the time the request reaches the origin server, Via tells the complete story of the request's routing path.

It serves two purposes: loop detection (a proxy can see if a request has already passed through itself) and protocol tracing (debugging what path a request took through your infrastructure).

Syntax

Via: <protocol-name>/<protocol-version> <pseudonym>[, ...]
Via: <protocol-version> <pseudonym>[, ...]

Examples:

Via: 1.1 proxy1.example.com
Via: HTTP/1.1 cache.example.com, 1.1 gateway.example.com
Via: 1.1 vegur
Via: 1.1 varnish
Via: 2 googlezip (Google Frontend)

Each entry has:

• Protocol: HTTP/1.1, HTTP/2, 1.1 (protocol name optional), 2
• Pseudonym: hostname, IP, or an alias — whatever identifies this proxy

How proxies append to Via

Each intermediate adds its own entry, building a comma-separated list:

Client → Proxy A → Proxy B → Proxy C → Origin

Origin sees:
Via: 1.1 proxy-a.example.com, 1.1 proxy-b.example.com, 1.1 proxy-c.example.com

The leftmost entry is the first proxy the client hit; the rightmost is the last proxy before the origin.

On the response path, proxies can also append to Via as the response travels back — though this is less common.

Reading Via in the wild

Real-world Via values you'll encounter:

Loop detection

When a proxy receives a request, it checks Via for its own hostname or identifier. If it finds itself, the request is in a loop — the proxy should return a 508 Loop Detected or drop the request. This is how proxy chains avoid infinite loops when misconfigured.

Via and Max-Forwards

Max-Forwards works with Via on TRACE and OPTIONS requests to limit how far a request travels through proxies. Each proxy decrements Max-Forwards; when it hits 0, the proxy stops forwarding and responds directly. Via on the response shows exactly how far the request got before being stopped.

Privacy considerations

Via can expose internal infrastructure details — proxy hostnames, IP addresses, internal domain names. For public-facing services, many organisations strip or replace Via entries to avoid leaking topology:

# nginx — replace Via header
proxy_set_header Via "";
add_header Via "1.1 proxy.example.com";

Common mistakes and gotchas

Stripping Via entirely. Some proxies strip Via for privacy but then lose loop detection capability. Consider replacing values rather than stripping.

Confusing Via with Forwarded/X-Forwarded-For. Via tracks which proxies forwarded the message (for loop detection and tracing). Forwarded/X-Forwarded-For tracks the original client IP (for identifying the end user). They serve different purposes and are both often present simultaneously.

Real-world examples

Request via Heroku routing:

GET /api/data HTTP/1.1
Host: api.example.com
Via: 1.1 vegur

Multi-CDN chain:

HTTP/1.1 200 OK
Via: 1.1 varnish, 1.1 proxy.example.com
Age: 120
Cache-Control: public, max-age=300

TRACE response showing proxy path:

HTTP/1.1 200 OK
Via: 1.1 proxy-a, 1.1 proxy-b, 1.1 origin-lb
Content-Type: message/http

FAQ

Is Via required on all proxied requests?

Yes — HTTP/1.1 requires proxies to add a Via entry when forwarding messages. Omitting it is technically non-compliant. In practice, some proxies (especially CDNs that want to hide their infrastructure) don't include it or use opaque identifiers.

What's the difference between Via and X-Forwarded-For?

Via identifies the proxies themselves — who forwarded the message. X-Forwarded-For identifies the original client IP — who initiated the request. A Via: 1.1 proxy.example.com entry tells you the proxy's identity; X-Forwarded-For: 203.0.113.5 tells you the client's IP that proxy received from.

Can I use Via to determine if a CDN is involved?

Yes. If you see Via: 1.1 varnish, Fastly is in the chain. Via: 1.1 vegur means Heroku. CDN-specific Via values are a useful signal when debugging caching behaviour.

Fun fact

Via is one of the original HTTP/1.1 headers from RFC 2068 (1997), designed to solve the proxy loop problem that became apparent as web caching infrastructure proliferated in the mid-1990s. Enterprise intranets with multiple Squid proxies could get into forwarding loops — Via gave proxies a way to recognise their own previous entries and break the cycle. Today, most loop detection happens at the CDN/infrastructure layer rather than via Via inspection, but the header persists as useful debugging information in complex routing architectures.