| 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. | |||||
Web server fingerprinting is the practice of inferring what sits behind a URL from the headers and redirect behavior it exposes. The tricky part is that the first name you see is often the edge layer, not the origin, so a CDN, proxy, or managed platform can make a stack look simpler than it really is.
This detector turns that ambiguity into a structured result. It probes one HTTP or HTTPS URL, follows redirect hops, inspects a fixed set of response headers, and reports a detected server, layer family, confidence score, possible origin hint, evidence table, candidate ranking, hop log, response playbook, confidence chart, and JSON export.
That makes it useful before a platform cutover, during a vendor audit, or when a site suddenly behaves differently and you want a quick attribution snapshot that is more disciplined than reading raw headers by hand. It is especially helpful when the visible edge and the likely origin do not appear to agree.
The package is strongest when multiple independent headers point in the same direction. It knows common edge CDN, proxy, web-server, app-server, and application clues, but it does not inspect open ports, TLS fingerprints, HTML markup, or service banners outside the HTTP response path.
Treat every result as a weighted best match, not a legal identification. HTTP explicitly allows intermediaries to add their own metadata, and many stacks suppress or rewrite identifying headers. A high-confidence edge result can still mean the origin remains hidden behind that edge.
Use one public URL per run. If you paste multiple lines, the interface keeps the first nonblank line and warns that the extras were ignored, so the page behaves as a single-target checker even though the helper can accept arrays behind the scenes.
Start with the default HEAD preference and leave Fallback GET on 405 enabled. That keeps the first probe light while still recovering when a site refuses HEAD but responds normally to GET.
The preset targets are best treated as quick demonstrations of how different platforms expose different clues. For actual operations work, replace them with the exact hostname or final application URL you need to document.
The page normalizes the first input line into a full URL. If no scheme is present, it assumes http://. Only HTTP and HTTPS inputs are accepted. Advanced settings let you change the preferred method, per-hop timeout from 200 to 8000 ms, redirect limit from 0 to 12, optional custom user-agent, and the action threshold for confidence from 30 to 95.
The browser does not fingerprint the target directly. It sends the normalized URL and selected options to a helper service, and that helper performs the live requests one hop at a time with manual redirect handling. A 303 switches subsequent probing to GET, while 301, 302, 307, and 308 keep the current method. If a HEAD request returns 405 and fallback is enabled, the same hop is retried as GET.
Each hop records status code, elapsed time, and a fixed set of headers that are commonly useful for attribution, including server, via, x-powered-by, x-generator, server-timing, x-served-by, x-cache, cf-ray, x-amz-cf-id, x-vercel-id, x-nf-request-id, and x-envoy-upstream-service-time. Header values are trimmed before export so the evidence tables stay readable.
| Family | Examples recognized | Interpretation |
|---|---|---|
| Edge CDN | Cloudflare, Amazon CloudFront, Fastly, Akamai, Vercel Edge, Netlify Edge, Fly.io, BunnyCDN | Usually identifies the delivery edge seen by the client, not necessarily the origin. |
| Proxy or cache | Varnish, HAProxy, Traefik, Kong, Envoy, Heroku Router | Often means the request path is being mediated before it reaches an origin server. |
| Web or app server | Nginx, OpenResty, Apache HTTP Server, Microsoft IIS, Caddy, LiteSpeed, Tomcat, Jetty, Kestrel, Gunicorn, Uvicorn, Werkzeug | Closer to the serving stack itself, though still not guaranteed to be the innermost origin layer. |
| Application clue | Express, ASP.NET, PHP, WordPress, Drupal | Helpful for hints, but weaker than a direct server or proxy signal when used alone. |
The candidate ranking is score-based rather than rule-finalized. Every recognized header pattern contributes a weighted signal to one candidate. The helper then compares the top candidate with the runner-up, adds credit for repeated hits on the same candidate, and subtracts confidence when the evidence is weaker or more ambiguous.
| Factor | Effect in the package |
|---|---|
| Top candidate's strongest signal | Sets the baseline for the confidence score. |
| Repeated hits for the same candidate | Adds points when several headers agree on the same platform. |
| Dominance over the runner-up | Raises confidence when the top match clearly leads the next candidate. |
No Server header |
Reduces confidence because attribution must rely on secondary headers. |
| Only application-layer clues | Reduces confidence because upstream web or proxy layers may be masked. |
| Only edge-layer clues | Reduces confidence because the visible edge may obscure the origin. |
Confidence labels are then bucketed into high at 82 and above, medium from 58 to 81, and low below that. The Possible Origin Hint field prefers the first non-edge candidate if one exists. If no non-edge candidate is ranked, it may still normalize the final Server header when that header is not itself an edge family.
The result views are intentionally operational. Detection Metrics summarizes the run. Header Evidence lists weighted signals. Candidates ranks the best matches. Hop Details shows status, URL, and selected headers for each redirect step. Response Playbook turns notable conditions into prioritized follow-up actions. Confidence Chart visualizes the top candidates. Each table can be copied or exported as CSV or DOCX, the chart can be downloaded as PNG, WebP, JPEG, or CSV, and the full structured payload is available in JSON.
Because the helper performs live HTTP requests, the checked URL and request options leave the page during analysis. Use it only for destinations you are allowed to probe. The strongest interpretation practice is to treat the result as an attribution aid: useful for triage, documentation, and drift detection, but not a substitute for deeper network discovery when the stakes are high.
The Detected Server field is simply the top-ranked candidate from the observed evidence. The Detection Family tells you what layer that candidate belongs to, which is often more actionable than the specific brand name on its own.
The Response Playbook is built from the result itself. It raises priority when the confidence score falls below your floor, the redirect chain is long, the origin hint differs from the detected server, no identifying headers were exposed, the top two candidates are close together, or the probe had to fall back from HEAD to GET. If none of those conditions appear, the playbook drops back to a steady-state reminder to keep drift checks in place.
The most reliable reading comes from using the views together. A confident top match, clean evidence rows, and a short redirect chain point to a stable answer. A polished summary paired with weak evidence or a crowded candidate table is a signal to slow down and investigate further.
Suppose the final hop exposes server: cloudflare together with a cf-ray header. In the current package, those are both strong Cloudflare signals, so the candidate table is likely to put Cloudflare first with a high confidence label and the family set to edge-cdn.
The correct interpretation is not "the whole stack is Cloudflare." It is "the client-visible edge is strongly consistent with Cloudflare." If you are trying to document the origin, the next thing to inspect is whether an origin hint or secondary candidate appears.
Imagine the visible response looks like Envoy, but secondary headers or lower-ranked evidence also point toward Nginx. The detector can keep Envoy as the top server while surfacing Nginx as a possible origin hint.
That is the kind of run where the Response Playbook becomes more useful than the badge alone. The package explicitly raises a divergence action when the likely origin hint differs from the top detected layer.
If the site hides the Server header and only exposes something like x-powered-by: PHP or a CMS generator header, the page can still rank candidates. The result, however, will usually be weaker because the package penalizes runs that rely only on application-layer clues.
That is a useful outcome in its own right. A low-confidence application hint tells you the site is not revealing enough HTTP metadata for strong server attribution, which is very different from a clear web-server or edge match.
No. The current interface keeps only the first nonblank input line and warns when extra lines were ignored.
Not necessarily. It reveals the strongest match from the observed HTTP response path. A CDN or proxy can still hide the origin behind it.
The helper switches to GET after a 303 redirect, and it can retry a HEAD request as GET when the target replies with 405 and fallback is enabled.
Yes. The helper makes live HTTP requests to the target URL and returns the observed hop, timing, and header data to the page.
That usually means the target exposed too little identifying header data, the redirect path ended ambiguously, or the request failed before strong evidence could be collected.