Via Inspect
Parse and diagnose HTTP headers and routing signals in your browser. No input is sent to a server. Use it for first-pass observation-gap troubleshooting.
Status
Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.
How to use
Paste Via and click “Parse”. It splits and lists entries (accepts Via: lines, multi-line paste, or full response headers).
Notes (this tool)
- Comments are free-form and should not be used to identify vendors definitively; treat them as hints.
About this page
What does this tool do?
Split the Via header into hop entries (protocol, received-by, comments) and display them as a list.
Useful for path diagnostics like “Am I behind a CDN?” or “Where are headers being rewritten?”
Via basics
- Via is used by intermediaries (proxies/gateways) to indicate that a message passed through them.
- With multiple hops, it becomes a comma-separated list of entries.
- Some systems omit or hide Via depending on configuration.
Syntax (how to read)
Via is a comma-separated list of entries like “protocol received-by (comment)”. The protocol part may be omitted.
- Via: 1.1 vegur
- Via: 1.0 fred, 1.1 p.example.net
- Via: 1.1 proxy (cache)
Glossary (terms used on this page)
- Intermediary: a proxy/CDN/gateway between client and origin.
- Hop: one intermediate step; multiple Via entries usually indicate multiple hops.
- Rewrite: intermediaries adding/removing/modifying headers.
Why it helps (path visibility)
Header/caching behavior depends heavily on which layers you traverse. Via provides hints that speed up root-cause analysis.
- Even if origin headers look correct, intermediaries may rewrite them
- CORS or cookie attributes can be modified/stripped by intermediaries
Headers to check together (path clues)
Via alone may not be enough to identify your path. Combining multiple headers improves confidence.
- Age: seconds in shared cache (strong CDN/proxy hint)
- Forwarded / X-Forwarded-For / X-Real-IP: forwarding chain / client info hints
- Server / Via comments: treat as hints due to variability
- Vary: useful when suspecting cache key differences/fragmentation
Common pitfalls
- No Via ≠ no intermediaries (it can be hidden or signaled via other headers)
- Do not identify vendors solely from Via (comments are optional and free-form)
- Multiple entries often mean a longer path; you need comparisons to find where behavior changes
How to test (compare to find where it changes)
The key is comparing headers between path A and path B—e.g., CDN vs origin-bypass (or different domains/paths).
- curl -I https://example.com/ (normal path)
- curl -I https://origin.example.com/ (origin-bypass path)
- Compare Via/Age/Cache-Control/ETag/Expires to infer which layer is responsible
Debugging workflow (recommended)
- Paste response headers into Response Headers Parser and extract Via
- Split Via here to see hop count and comments
- Combine with Cache-Control/Expires/Age/ETag/Last-Modified to infer which layer is responsible
Troubleshooting checklist by symptom
- Headers unexpected: check Via (path) and Age (shared cache) and suspect which layer rewrites them
- Prod-only issues: prod has multiple Via entries while staging has none/fewer → path difference likely
- Caching issues: check Cache-Control/Expires/Age alongside Via
Related tools
- Response Headers Parser
- Request Headers Parser
- Cache-Control Inspect / Expires Inspect / Age Inspect
- ETag Inspect / Last-Modified Inspect
- Vary Inspect
What this tool does
- Split Via entries by commas
- Extract protocol / received-by / comments and list them
- Extract Via lines from full response headers
Operational notes
- Intermediaries may rewrite headers. Compare captures from equivalent points.
- Confirm final decisions with server logs and configuration such as trusted proxy and routing.
Referenced specs
- RFC 9110 (HTTP Semantics)
- MDN: Via
FAQ
Is Via a security problem?
It can hint at internal topology. If that’s a concern, control whether it’s added/exposed as a policy.
I see CDN-like behavior but no Via
Some CDNs don’t expose Via. Use Age, vendor-specific headers, DNS/cert clues, and origin vs edge comparisons.
References
Next to view (diagnostic order)
These links are generated from site_map rules in recommended diagnostic order.
- Forwarded Inspect — Parse Forwarded to inspect forwarding path data
- X-Forwarded-For Inspect — Parse X-Forwarded-For/X-Real-IP to inspect client chain
- X-Forwarded-Proto Inspect — Parse X-Forwarded-Proto/Host to verify external URL inference