Web Server Detector

Current detection

{{ confidenceBadgeText }} Status {{ result.final_code || '-' }} {{ result.detected_family || 'unknown' }} {{ result.redirects || 0 }} redirect(s) {{ result.total_ms || 0 }} ms {{ evidenceRows.length }} signal(s)

Ignored {{ extra_lines_ignored }} extra line(s). This detector checks one public URL per run.

Website URL:

Enter one public HTTP/HTTPS target, such as https://example.com.

Method preference:

Start with HEAD for header checks; use GET when HEAD returns sparse or blocked evidence.

Preset target:

Select a generic public URL or choose Custom to keep the current website field.

Timeout in milliseconds:

Range: 200-8000 ms per hop; 2500 ms suits most public sites.

Max redirects:

Accepted values: 0-12 hops; use 0 to inspect only the first response.

Fallback GET:

When on, a 405 HEAD response is retried once with GET for that hop.

User-Agent:

Optional string sent as User-Agent, for example Mozilla/5.0 during parity checks.

Confidence floor:

Accepted score: 30-95; raise it for change-control evidence.

Field	Value	Copy
{{ row.label }}	{{ row.value }}

Signal	Header	Value	Hop	Weight	Copy
{{ row.signal }}	{{ row.header }}	{{ row.value }}	{{ row.hop }}	{{ row.weight }}
No identifying headers were exposed.

Rank	Signal	Family	Score	Hits	Max Weight	Copy
{{ row.rank }}	{{ row.signal }}	{{ row.family }}	{{ row.score }}	{{ row.hits }}	{{ row.max_weight }}
No ranked candidates available.

Hop	URL	Status	Server	Via	X-Powered-By	X-Cache	Edge ID	Time (ms)	Copy
{{ row.hop }}	{{ row.url }}	{{ row.status }}	{{ row.server \|\| '-' }}	{{ row.via \|\| '-' }}	{{ row.powered_by \|\| '-' }}	{{ row.x_cache \|\| '-' }}	{{ row.edge_id \|\| '-' }}	{{ row.time_ms }}
No hop data available.

Priority	Action	Why now	Runbook trigger	Owner	Copy
{{ row.priority }}	{{ row.action }}	{{ row.reason }}	{{ row.trigger }}	{{ row.owner }}
No response recommendations available.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Public web requests rarely travel straight from a browser to one plain origin server. A request may pass through a CDN, reverse proxy, cache, load balancer, application gateway, and finally an origin that generates the response. The headers returned to the client describe the visible path, not necessarily every machine or service behind it.

Web server detection uses those visible HTTP clues to identify the software or service that most likely handled the request. The clearest clue is often the Server response header, but modern sites often shorten, remove, or replace that value. Other headers can be just as important because they point to edge networks, cache layers, application frameworks, or proxy software that sits in front of the origin.

Origin server: The backend service intended to produce the site or application response.
Edge or CDN: A delivery service close to the visitor that may cache, route, or shield the origin.
Reverse proxy: A front service that forwards traffic to another server while adding its own headers or behavior.
Application hint: A framework or runtime clue, such as a powered-by header, that does not fully identify the web server.

These distinctions matter during migrations, outage reviews, penetration-test scoping, compliance evidence collection, and routine operations. If a site was expected to move from Apache to Nginx but the visible answer is Cloudflare, the result may still be correct because Cloudflare is what visitors reach first. If an internal runbook expects a CDN in front of an application server and the CDN signature disappears, that can point to a routing or DNS change before users notice a larger problem.

Header-based fingerprinting follows the public HTTP path. A CDN or proxy can be the correct visible result even when another origin is hidden behind it.

The main mistake is treating a header fingerprint as a complete infrastructure inventory. It is better understood as evidence from one vantage point at one time. A high-confidence edge result can be very useful for confirming what users reach, while still saying little about the backend server protected by that edge. A low-confidence result can also be useful when it tells you the target is intentionally hiding details or handling metadata requests differently from normal page requests.

Reliable interpretation comes from reading the top candidate, the evidence behind it, the redirect path, and any competing candidates together. The server name alone is only a starting clue; the surrounding headers explain whether that clue is direct, masked, weak, or mixed with another layer.

How to Use This Tool:

Use the checker for one public HTTP or HTTPS target at a time. Keep the request settings consistent when you compare runs before and after a migration, DNS change, or edge-policy update.

Enter the target in Website URL. If you paste several lines, the checker keeps the first non-empty URL and warns that the extra lines were ignored.
Choose Method preference. Start with HEAD for a lightweight metadata check, or choose GET when the site blocks HEAD or sends different headers to normal page requests.
Open Advanced when the first result needs tuning. Timeout in milliseconds accepts 200 to 8000 per hop, Max redirects accepts 0 to 12, and Fallback GET retries a 405 response from a HEAD request with GET.
Set User-Agent only when you need parity with another monitoring profile. Leave it blank for the default probe identity, and keep it unchanged when comparing multiple runs.
Adjust Confidence floor if the result will feed a runbook decision. Higher floors make the Response Playbook more conservative.
Run the check and read Detection Metrics first. Confirm Final URL, Final Status, Detected Server, Detection Family, Confidence, Redirects Followed, and Fallback GET Used.
Use Header Evidence, Server Candidates, Hop Details, and Server Confidence Chart to verify the result before acting on the playbook recommendations.

Interpreting Results:

Detected Server is the strongest visible candidate from the observed HTTP path. Detection Family explains what kind of candidate won, such as edge-cdn, proxy, proxy-cache, web-server, app-server, application, or unknown.

High confidence means the captured headers strongly support one visible candidate. It does not prove that the origin server is exposed. A high-confidence Cloudflare, CloudFront, Vercel, or Envoy result can be accurate about the front service while the origin remains masked.

Header Evidence shows the exact header name, value, hop, weight, and signal that contributed to attribution.
Server Candidates shows whether the winner is far ahead or whether another candidate is close enough to deserve review.
Hop Details shows whether redirects changed the URL, status, visible server header, cache clue, or edge request ID along the way.
Possible Origin Hint is a clue for follow-up investigation, not a second confirmed server detection.
Response Playbook turns low confidence, long redirect chains, origin-hint divergence, and close candidate races into practical follow-up actions.

Technical Details:

HTTP fingerprinting relies on response metadata. The Server header can describe the software that handled a response, but many production paths deliberately reduce that detail or replace it with an edge service value. Secondary headers such as Via, x-cache, x-served-by, cf-ray, x-amz-cf-id, x-vercel-id, x-nf-request-id, x-envoy-upstream-service-time, and x-powered-by help separate server, proxy, cache, CDN, and application signals.

The request method affects what evidence is visible. A HEAD request asks for the headers that a GET response would send without transferring the body, but real sites do not always treat HEAD and GET identically. Redirects matter too because an early hop can expose one service while the final hop exposes another.

Rule Core:

Each matched header contributes a weighted signal to a server candidate. Evidence from the final response keeps full weight, while evidence from earlier redirect hops is discounted because the final response is what users actually receive.

S_{candidate} = \sum_{i = 1}^{n} w_{i} h_{i}

Candidate score variables for web server detection
Symbol	Meaning	Boundary
`S`	Total candidate score before the displayed candidate row is rounded and capped.	Higher score ranks ahead of lower score.
`w`	Base weight for the matched header pattern, such as a strong server token or a weaker application hint.	Strong server and edge request-ID clues carry more weight than generic framework clues.
`h`	Hop factor for where the evidence appeared.	`1.00` on the final hop and `0.86` on earlier redirect hops.

Confidence is a second score that describes how action-ready the top attribution is. It starts with the strongest clue for the winning candidate, adds points for repeated agreement, adds points when the winner is well ahead of the runner-up, and subtracts penalties when the evidence is thin or masked.

C = clamp (W_{\max} + \min (18, 4 (H - 1)) + \min (20, round (\frac{D}{3})) - P, 0, 99)

Confidence score terms for web server detection
Term	Meaning	Effect on confidence
`Wmax`	Highest single evidence weight supporting the top candidate.	Sets the starting confidence.
`H`	Number of evidence rows supporting the top candidate.	Adds up to 18 points for repeated agreement.
`D`	Score gap between the top candidate and the runner-up.	Adds up to 20 points when the winner is clearly ahead.
`P`	Penalties for no `Server` header, application-only evidence, edge-only evidence, or a crowded close race.	Reduces confidence when attribution may be masked or ambiguous.

Signal Families:

Signal families used in web server detection
Family	Typical clues	How to read it
Edge CDN	`cf-ray`, `x-amz-cf-id`, `x-vercel-id`, `x-nf-request-id`, or edge-branded `Server` values.	The client-facing delivery layer is visible, and the origin may be intentionally hidden.
Proxy or cache	`Via`, `x-cache`, `x-served-by`, `x-varnish`, HAProxy, Traefik, Envoy, Kong, or Heroku router clues.	An intermediary is forwarding, caching, routing, or shaping traffic.
Web or application server	Nginx, Apache HTTP Server, IIS, Caddy, LiteSpeed, Tomcat, Jetty, Kestrel, Gunicorn, Uvicorn, or Werkzeug tokens.	The visible response is closer to the serving tier, though a proxy can still exist in front of or behind it.
Application	`x-powered-by`, `x-aspnet-version`, or `x-generator`.	The application stack leaked a clue, but the web server or edge layer may remain unknown.

Confidence Bands:

Confidence bands for web server detection
Band	Score range	Practical reading
High	`82-99`	One visible candidate is strongly supported, but hidden origin services can still exist.
Medium	`58-81`	The result is useful for triage, but evidence rows and alternatives should be reviewed before change-control action.
Low	`0-57`	The headers are too sparse, weak, or mixed for confident attribution.

Request and Validation Boundaries:

Only HTTP and HTTPS URLs are accepted. A bare host is normalized to an HTTP URL, so include https:// when the secure route is the route you intend to check.
Redirect following is bounded by Max redirects. A 303 redirect switches the next hop to GET; common 301, 302, 307, and 308 redirects keep the current method.
When no identifying headers match, the detected server is Unknown, confidence is Low (0), and the evidence and candidate tables are empty.
Comparable runs should keep URL, method, timeout, redirect limit, fallback behavior, and user agent consistent.

Privacy Notes:

The entered URL and request options are sent to a server-side probe so the checker can observe public response headers and redirect hops that a normal browser page cannot read across origins.

Check only public URLs you are allowed to test.
Do not include passwords, private tokens, session IDs, or sensitive query strings in the URL.
The result reflects the probe's network vantage point, request method, user agent, and timing. Another location or client profile may see different headers.
The checker does not scan ports, inspect response bodies for framework signatures, bypass access controls, or prove what software runs behind a CDN or proxy.

Worked Examples:

A CDN is the visible server

A production route such as https://store.example.com returns Final Status 200, Detected Server Cloudflare, Detection Family edge-cdn, and Confidence High (98). Header Evidence includes a cf-ray value and a Cloudflare server clue. The right reading is that Cloudflare is the client-facing service; the origin still needs separate evidence.

A redirect changes the final attribution

A legacy URL such as http://www.example.org redirects to https://www.example.org/. Hop Details shows one early cache response and a final Nginx response, while Server Candidates ranks Nginx first with Confidence Medium (76). Because final-hop evidence is weighted more heavily, the result describes the response users receive after the redirect.

HEAD is too sparse

A status route such as https://api.example.net/health returns no useful Server header on HEAD, leaving Detected Server Unknown and Confidence Low (0). Switching Method preference to GET, or keeping Fallback GET on when the response is 405, can reveal headers that the metadata-only request did not expose.

Two candidates are close

A platform route reports Envoy in Server and a weaker Nginx clue in another header. Server Candidates shows a small score gap, so Response Playbook recommends tracking both candidates until repeated checks show a stable winner. Treat that as a runbook cue, not as proof that both services are equally exposed.

FAQ:

Is the detected server always the origin server?

No. It is the strongest visible candidate from the observed public HTTP path. A CDN, proxy, or cache can be the correct detected server while still hiding the origin.

Why do I see Cloudflare or CloudFront instead of Nginx or Apache?

Those edge services can rewrite or add response headers before the visitor sees them. Check Detection Family, Header Evidence, and Possible Origin Hint before assuming the origin server was identified.

Should I use HEAD or GET?

Start with HEAD because it asks for response metadata without the body. Use GET when the target blocks HEAD, returns weak evidence, or behaves differently for metadata-only requests.

Why did extra pasted URLs get ignored?

The checker runs one public URL per check. If several lines are pasted into Website URL, it keeps the first non-empty target and shows a warning for the ignored lines.

Does hiding the Server header make a site secure?

No. Removing banner detail can reduce simple disclosure, but patching, configuration review, access control, and monitoring matter more than hiding a header alone.

Glossary:

Server header: An HTTP response header that can name the software or product that handled a request.
Origin server: The backend server or service intended to generate the site or application response.
Edge CDN: A delivery network that can answer requests before traffic reaches the origin.
Reverse proxy: A front service that accepts client requests and forwards them to another server.
Redirect hop: One response in a 3xx chain that points the next request to another URL.
User-Agent: The client identity string sent with the request, which some servers use to vary response behavior.
Confidence floor: The score threshold used by the playbook to decide whether a detection should be treated as action-ready.

References:

RFC 9110: HTTP Semantics, Internet Engineering Task Force, June 2022.
Server header, MDN Web Docs, 21 November 2025.
HEAD request method, MDN Web Docs, 4 July 2025.
Fingerprint Web Server, OWASP Foundation.
Cloudflare HTTP headers, Cloudflare Docs.
Understand response headers policies, Amazon CloudFront Documentation.