Web server detector. 15+ servers + CDN edges.
Paste the Server header (or full response headers). We classify the origin server, the CDN / edge, and any exposed version info — plus a security verdict on whether the server fingerprint is leaking too much.
Paste the Server header value or full HTTP response headers from curl -I or DevTools. We identify the origin server, the CDN / edge layer in front, and any exposed version info — plus a security verdict on whether the fingerprint is leaking too much.
How do I get response headers?
- curl:
curl -I https://example.com— fetches headers only. - DevTools: F12 → Network → click the document request → Response Headers panel.
- Just the Server line: paste
Server: nginx/1.20.1on its own — the parser handles single-line input too.
Privacy: detection happens in your browser. Nothing is sent or logged.
CDN → WAF → origin → app. Each leaves headers.
CDN / edge. The first layer — the request from the user hits the closest edge POP. Cloudflare leaves cf-ray; Vercel leaves x-vercel-id; Netlify leaves x-nf-request-id; AWS CloudFront leaves x-amz-cf-id; Fastly leaves x-served-by: cache-*. These platform-specific headers are the most reliable CDN identifier — far more so than Server, which is often stripped.
WAF / security. Web Application Firewall sits between CDN and origin (or is bundled with the CDN). Cloudflare's WAF runs on the same edge as the CDN. Imperva and Sucuri commonly run as separate WAF-only proxies in front of customer origins. The WAF often rewrites the Server header to its own brand, hiding the actual origin from attackers — useful security but obscures the stack from you too.
Origin server. The actual app server hosting the code. nginx and Apache HTTPD dominate the open-source web (~70% of public web origins between them per W3Techs). Microsoft IIS holds enterprise Windows hosting. Caddy is a modern auto-HTTPS server gaining share. Custom Node.js / gunicorn / uvicorn often hide behind nginx as a reverse proxy.
App stack. What runs the application code, exposed via the X-Powered-By header (when not stripped). PHP, ASP.NET, Express, Next.js, Rails, Django all leak their identity by default. Modern best practice: strip X-Powered-By at the framework or CDN layer. Knowing the app stack tells you what runtime vulnerabilities apply (PHP version-specific CVEs, Express middleware issues) and what kind of framework patches need monitoring.
Four jobs this tool covers.
Job 1: Pre-launch fingerprint audit. Before going live, run curl -I https://staging.example.com, paste the headers here. If the verdict is "version exposed," strip those headers in your CDN / nginx / Apache config before the launch. The fix is a one-line config change; the cost of skipping it is real exploit-targeting risk.
Job 2: Vendor / partner stack assessment. Knowing a vendor's stack tells you about their operational profile. A vendor on Cloudflare + nginx + Express has good defaults; one with Apache 2.2 + PHP 5.6 exposed in headers is operating very legacy infrastructure. Useful filter for SaaS / API / partner due diligence. Pair with our HTTP Headers Checker for the security-headers side.
Job 3: CDN migration verification. After moving from one CDN to another, paste headers from the new endpoint to confirm the migration landed. The CDN-specific headers (cf-ray, x-vercel-id, x-served-by) are the canonical "we're now on this CDN" signal. Pair with our DNS Lookup to verify the DNS side of the cutover landed too.
Job 4: Incident-response forensics. When investigating a security incident, the response headers are part of the evidence trail. Snapshot the full Server / WAF / CDN stack at the time of incident; the diff with current headers can tell you whether the WAF / firewall config has changed since. Combine with our SSL Cert Inspector for the cert side of the security stack.
Six questions users ask.
Should I expose the Server header version?
No, ideally. Server headers like 'nginx/1.18.0' tell attackers exactly which version-specific exploits to try. The fix is to suppress or generic-ize the version: in nginx, server_tokens off; in Apache, ServerTokens Prod ServerSignature Off; in IIS, the URLScan tool or HTTP response rewrite rules. Modern CDN-fronted sites often have the origin server header stripped automatically (Cloudflare, Vercel, Netlify all strip or rewrite). The X-Powered-By header is even worse — it leaks the application stack (PHP, ASP.NET, Express). Strip it always.
What's the difference between origin server and CDN?
Origin server is the actual application server hosting your code (nginx, Apache, IIS, Caddy, custom Node.js, etc.). CDN / edge is the global cache layer in front (Cloudflare, Vercel, Netlify, AWS CloudFront, Fastly, Akamai). Modern sites are usually CDN + origin pairs. The headers tell you both — Server may say 'nginx' (origin) while cf-ray indicates Cloudflare (CDN). The detector classifies them separately so you see the full stack, not just the closest layer.
Why do some servers report fake Server values?
Three reasons. (1) Security hardening — admins replace the real Server with a fake value (e.g. 'Apache/9.99' to throw off attackers). Common but provides only weak protection because the actual server fingerprint is detectable through other signals (TCP/HTTP behavior, error pages, default ports). (2) Reverse proxy in front — the Server you see is the proxy's, not the origin's. (3) WAF in front — Cloudflare, Imperva, Akamai often rewrite the Server header. The detector flags this when it spots the WAF / CDN signature elsewhere in the headers.
Which servers does it identify?
Origin: nginx, Apache HTTPD, Microsoft IIS, Caddy, LiteSpeed, OpenLiteSpeed, Tomcat, Jetty, Lighttpd, gunicorn, uvicorn, Tengine, Express. CDN / edge: Cloudflare, Vercel, Netlify, AWS CloudFront, Fastly, Akamai, KeyCDN, BunnyCDN, jsDelivr, Google Frontend (gws), GitHub Pages. Security / WAF: Sucuri Firewall, Imperva (Incapsula), Cloudflare WAF. Application stacks (from X-Powered-By): PHP, ASP.NET, Express, Sinatra, Rails, Django.
What if the response has no Server header at all?
Good security hygiene. Cloud-managed platforms (Vercel, Netlify, Cloudflare Pages) often strip Server entirely from public responses. Indistinguishable-from-X is a strong defensive posture — attackers have to spend time fingerprinting via other signals. The detector flags 'no Server header — well-configured' as a positive signal in those cases. If you're seeing other headers (cf-ray, x-vercel-id, x-served-by) the platform-specific headers tell you the stack even when Server is hidden.
Is the data I paste sent anywhere?
No. Detection happens entirely in your browser. The page is static HTML; the only network request is the initial page load. Safe for headers from internal apps, staging environments, or any source you don't want to share. We never see your input.
Three mistakes we see most.
Server-stack fingerprinting via the Server header has been an exercise in self-deception since roughly 2015. MDN's Server header reference notes the value is informational and may be spoofed, stripped, or replaced by an upstream proxy. Roughly 80% of the production sites we audit report a Server value that has nothing to do with the actual origin software running the application.
Mistake 1, trusting the Server header at face value: "Server: cloudflare" tells you the request hit Cloudflare, nothing about origin. "Server: nginx/1.18" may be the truth, may be a stale Apache config that someone set to "nginx" for security obscurity, or may be a custom proxy advertising itself as nginx. The detector on this page cross-references the Server header with X-Powered-By, X-Backend, cookie names, and TLS fingerprints to triangulate the truth. Treat the Server header as a starting hypothesis, not a fact.
Mistake 2, ignoring the CDN layer: in 2026, roughly 70% of production traffic terminates at a CDN edge (Cloudflare, Vercel, Fastly, Akamai, CloudFront) before reaching the origin. The CDN often rewrites Server, strips X-Powered-By, and adds its own cache headers. Per Cloudflare's HTTP-request-headers reference, CF-RAY, CF-Cache-Status, and Server: cloudflare confirm the edge layer; the origin sits behind it and may be entirely different software. Map the layers, not just the visible response.
Mistake 3, testing only the root path: modern stacks route different paths through different servers. /api/* may hit Node.js on Railway, /shop/* may hit Shopify, /blog/* may hit WordPress on Cloudways, all under the same domain. Hitting only example.com gives you the framework that handles the marketing page, missing the rest. The detector accepts arbitrary paths; run it against five representative routes per domain to build the real stack map.
When to actually use this: competitive analysis (knowing a competitor runs Shopify Plus vs. custom Next.js changes your pitch entirely), pre-acquisition due diligence (legacy stacks are liabilities), debugging customer-side issues (a 502 from "nginx" is different from a 502 from Cloudflare), and tooling decisions for a rebuild. Our Web development engagements use stack-detection as a day-zero discovery step on every inherited codebase.
Related Digital Heroes services + reading: See our Web development service for production-grade stack architecture and our SaaS development service for greenfield product builds. Sibling tools: CDN Detector and Tech Stack Detector.
Published · Last updated .