---
title: "Via header"
url: https://proxy.wiki/glossary/via-header/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-09-06
updated: 2026-09-06
site: proxy.wiki
topics: ["Proxy fundamentals"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# 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.

**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](/glossary/proxy-server/) 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](/glossary/http-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](/glossary/x-forwarded-for/) carries client addresses and is not standardised. `Via` carries intermediary names and protocol versions and is. A [transparent proxy](/glossary/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.

## Frequently asked questions

### Does the presence of a Via header mean my traffic is proxied?

It means at least one intermediary added an entry. Its absence means nothing, because any intermediary can be configured not to add the header, and a CONNECT tunnel gives it nothing to annotate in the first place. Treat presence as evidence and absence as no information.

### Can Via reveal my internal hostnames?

It can, which is why RFC 9110 permits pseudonyms in place of a sensitive host and says a proxy acting as a portal through a firewall should not forward the names of hosts behind it unless explicitly enabled. Check the configuration rather than assuming the safe default applies.

### What is the difference between Via and X-Forwarded-For?

Via is standardised and describes the path: which intermediaries handled the message, and on which protocol version. X-Forwarded-For is a convention with no defining RFC and describes origin: the client addresses each hop observed. They answer different questions and neither implies the other.

## Sources

1. [RFC 9110: HTTP Semantics, section 7.6.3, the Via header field](https://www.rfc-editor.org/rfc/rfc9110.html)