Reverse Proxy Detection: a beginner's guide
Identify reverse proxy presence
Reverse proxies: the front door of every modern website
A reverse proxy is a server that sits in front of one or more backend servers and forwards client requests to them, then sends the responses back. Where a regular ("forward") proxy works on behalf of clients (hiding the client's identity from the destination), a reverse proxy works on behalf of servers (hiding the server's identity, IP address, and architecture from the client). The reverse proxy is the public face of the website; the actual application servers sit behind it on a private network and never speak directly to the public internet. The most common reverse proxies in use today are nginx, HAProxy, Caddy, Traefik, Envoy, and the proxy layers built into Cloudflare, Fastly, AWS CloudFront, and similar CDN/edge platforms.
You should care because a reverse proxy is one of the cheapest, highest-leverage pieces of infrastructure any non-trivial website can add. It centralizes TLS termination (so you only have to manage certificates in one place), it handles request routing (URL paths to specific backends), it provides a single chokepoint for rate limiting and security rules, it absorbs traffic spikes, and it lets you scale, upgrade, and replace backend servers without the public ever knowing. The famous "reverse-proxy pattern" is the foundation of essentially every modern web architecture — even small sites benefit from it, and big sites cannot exist without it.
The four things every reverse-proxy detection check looks at:
The `Via` header. Reverse proxies often add a `Via` header listing the proxy software and version.
The `Server` header. Often shows the proxy software (nginx, Caddy) rather than the underlying application server.
The presence of a CDN or edge service. Cloudflare, Fastly, and AWS CloudFront are all reverse proxies in addition to being CDNs.
The IP address. Compared against the known IP ranges of major reverse-proxy providers.
Three questions a reverse-proxy detection check answers:
Does this website have a reverse proxy in front of its origin servers?
Which proxy product or service is providing the public face?
For a security review, does the reverse-proxy layer hide the backend infrastructure from public scans?
The cost of not understanding the reverse-proxy layer is misreading the security and operational posture of a website. The fix is the same set of header inspections that a CDN detection uses — and in fact, the line between "reverse proxy" and "CDN" is largely a marketing distinction. The famous answer to "what does Cloudflare actually do?" starts with "it's a globally distributed reverse proxy."
The Reverse Proxy Detection endpoint, in plain language
In one sentence: Identify reverse proxy presence
Detects if a domain is served through a reverse proxy. Identifies common proxies like nginx, HAProxy, Varnish, and cloud-based proxies.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Analyzes HTTP (HyperText Transfer Protocol) headers (Via, X-Forwarded-For, X-Proxy-ID), server signatures, and response patterns to identify reverse proxy presence. Distinguishes between CDN (Content Delivery Network), load balancer, and standalone reverse proxy configurations.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Reverse Proxy Detection tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Reverse proxy detection reveals the true infrastructure stack behind a website. It's useful for security assessments, understanding architecture, and identifying potential misconfigurations.
Picture this in real life. Imagine a security researcher. Here's the situation they're walking into: Map the complete infrastructure stack including proxy layers. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Reverse Proxy Detection tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Reverse Proxy Detection tool is built for you:
What is this website actually built with, layer by layer?
Who hosts it, who runs analytics on it, who delivers the assets?
Is the company on a stack that fits my product, my pitch, or my integration?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Sales teams qualifying leads, marketers researching competitors, partnership managers scoping integrations, and security teams looking for known-vulnerable software in the wild. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and you're guessing at how a website is built — which kills sales calls, integration scoping, and competitive research. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the developer plan. The technical details: `GET /v1/domain/reverse-proxy`.
When would I actually use this?
If you're still on the fence about whether the Reverse Proxy Detection tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security researcher, a security engineer, and a solutions architect — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Infrastructure Mapping
Imagine you're a security researcher. Map the complete infrastructure stack including proxy layers.
Why it matters: Understand full request path for security analysis.
Story 2: Misconfiguration Detection
Imagine you're a security engineer. Identify proxy headers that leak internal infrastructure information.
Why it matters: Find and fix information disclosure via proxy headers.
Story 3: Architecture Analysis
Imagine you're a solutions architect. Understand competitor proxy architecture for benchmarking.
Why it matters: Learn from industry proxy deployment patterns.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Reverse Proxy Detection tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
During sales prospecting, to qualify a lead by what they are running.
During competitive research, to understand what a rival is built with.
When scoping an integration or partnership.
When you suspect a target is using a known-vulnerable version of something.
If you can see yourself in even one of those bullets, the Reverse Proxy Detection tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Reverse Proxy Detection tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the Reverse Proxy Detection tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/reverse-proxy?domain=example.com"What you need to provide
There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to detect reverse proxy for | example.com |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
detected | boolean | Whether a reverse proxy was detected |
primaryProxy | string | Primary proxy type identified (null if none detected) |
providers | array | Detected proxy providers with name, vendor, and evidence |
providerCount | number | Number of proxy providers detected |
forwardedHeaders | array | Proxy forwarding headers present (e.g., x-forwarded-for, x-forwarded-proto) |
viaHeader | string | Via header content if present (null if absent) |
recommendations | array | Infrastructure improvement suggestions |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
CDN (Content Delivery Network) — A worldwide network of servers that store copies of your website close to your visitors so pages load fast.
HTTP (HyperText Transfer Protocol) — The language web browsers and websites use to talk to each other.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.