{{ summaryTitle }}
{{ summaryValue }}
{{ summaryLine }}
{{ badge.label }}{{ badge.value }}
The neutral sample is not requested on page load. Include HTTPS when that is the route you intend to inspect.

{{ runStatus }}

Explore the report
Uses a labeled local fixture and does not contact the sample URL.
The result records the final method and whether a HEAD 405 fallback was used.
Tool default is the safest general probe. Custom values remain out of the share URL.
Example: ExampleAudit/1.0
Use 200–8,000 milliseconds.
ms
Use 0–12. Zero inspects only the first response.
Used only when Request method is HEAD.
{{ params.get_on_405 ? 'On' : 'Off' }}
Use 30–95 points. This does not change provider attribution or candidate scores.
StatusCheckEvidenceNext actionCopy
{{ severityLabel(row.severity) }}{{ row.check }}{{ row.evidence }}{{ row.next_action }}
SignalFamilyHeaderValueHopWeightCopy
{{ row.signal }}{{ row.family }}{{ row.header }}{{ row.value }}{{ row.hop }}{{ row.weight }}
HopURLStatusServerVia / cacheTime (ms)Copy
{{ row.hop }}{{ row.url }}{{ row.status }}{{ row.server }}{{ row.route_hint }}{{ row.time_ms }}
Hypertext Transfer Protocol (HTTP) Header Checker Check a public URL’s HTTP headers across redirects and review security, cache behavior, browser state and cross-origin exposure.
Hypertext Transfer Protocol (HTTP) Redirect Checker Trace a public HTTP redirect chain hop by hop to identify loops and HTTPS downgrades, compare timing and generate a replayable cURL command.
NGINX Proxy Headers Checker Audit an NGINX proxy block for unsafe forwarded headers and trust-boundary gaps with checks for WebSocket, timeout and upstream TLS risks.
Nginx Server Block Generator Generate an NGINX server block for static sites, PHP-FPM apps, or reverse proxies with TLS routing plus safety and activation checks.

A public HTTP response often describes the service at the edge of a request path rather than the machine that generated the application. A CDN, reverse proxy, cache, gateway, or load balancer can replace headers and hide the origin. Seeing Cloudflare when the application runs behind Nginx can therefore be accurate: Cloudflare is the strongest client-visible layer in that observation.

Web server fingerprinting compares response headers with recognizable signatures. The Server field can directly name Nginx, Apache, IIS, Caddy, or another server, while fields such as Via, cache identifiers, edge request IDs, and powered-by hints can point to proxies, CDNs, application servers, or frameworks. Header values are self-reported and can be removed, shortened, spoofed, or changed by an intermediary.

Visible family What the clue may identify What it does not prove
Web serverNginx, Apache, IIS, Caddy, LiteSpeed, or OpenRestyThat no CDN or hidden upstream exists
Edge, proxy, or cacheCloudflare, CloudFront, Fastly, Varnish, Envoy, or another front layerThe software running on the origin
Application serverTomcat, Jetty, Kestrel, Gunicorn, Uvicorn, or WerkzeugThe full request path or deployment topology
Application hintA framework or runtime exposed by a secondary headerThe web server that accepted the connection

Method, client identity, redirects, cache state, DNS answer, location, and timing can all change the visible response. A HEAD request is efficient for metadata, but some servers reject it or return different headers from GET. Bot and browser identities may also reach different routes. Comparisons are meaningful only when those request conditions are kept consistent.

Detection is useful for migration checks, incident triage, monitoring inventories, and authorized security review. It is evidence, not ownership proof. When the hidden origin matters, confirm the result against CDN, load-balancer, reverse-proxy, and server configuration controlled by the infrastructure owner.

How to Use This Tool:

Choose one public route and a repeatable request identity before comparing its visible service clues.

  1. Enter the exact Public URL, including HTTPS when that is the route you intend to inspect. The example evidence is local and is not requested automatically.
  2. Choose HEAD for a header-focused probe or GET when the route handles HEAD differently. Leave Retry GET after HEAD 405 enabled when that fallback should be part of the observation.
  3. Select the client identity. A custom User-Agent must be one line from 1 to 300 characters; keep it stable when comparing runs.
  4. Set a per-hop timeout from 200 to 8,000 milliseconds and a redirect limit from 0 to 12. Zero records only the first response.
  5. Run the check, then compare the winning candidate with its header evidence and redirect hop. Use the Action confidence floor from 30 to 95 only as a local decision threshold; it does not change attribution or confidence scoring.

Interpreting Results:

Action ready means a named candidate reached or exceeded the chosen confidence floor. Provisional means a candidate was found below the floor, and Unknown means no identifying signature won. None of these states proves the hidden origin.

  • Confirm the winning header and hop before recording the name in a runbook.
  • When an edge or proxy wins, treat a separate origin hint as a lead that needs infrastructure-owned evidence.
  • More than two redirects, a reached redirect limit, or a HEAD-to-GET fallback makes request-path context important to the conclusion.
  • Repeat with the same method, client identity, timeout, and redirect policy before treating score changes as service changes.

Technical Details:

The remote check follows the selected HTTP or HTTPS route manually and retains a bounded set of response headers from each hop. It does not fingerprint response bodies. Signature rules assign a family and base weight to recognized values, then combine evidence across the redirect path.

Transformation Core

Stage Exact behavior
Request pathFollow up to the selected redirect limit; a 303 changes the method to GET, while 301, 302, 307, and 308 retain the current method
HEAD recoveryWhen enabled, a 405 response to HEAD is retried once with GET and the final method is recorded
Header matchingRecognized server, edge, cache, proxy, application-server, and application signatures receive configured weights
Hop weightingFinal-hop evidence keeps its full weight; earlier-hop evidence is multiplied by 0.86 and rounded
Candidate rankingWeights are summed per candidate; ties retain the evidence order and no more than six candidates are returned

Formula Core

Confidence depends on the strongest single signal, repeated support for the winning candidate, and its lead over the runner-up. Penalties reduce confidence when the evidence is ambiguous or limited to a narrow family.

C=clamp099(round( Wmax+ min(18,4max(0,H−1))+ min(20,round(D/3))−P ))

Wmax is the winner's strongest matched weight, H its hit count, and D the non-negative difference between the winner's summed weight and the runner-up's. P adds 8 points when more than two candidates exist and the lead is below 10, 7 when no Server header was seen, 10 for application-only evidence, and 8 for edge-only evidence.

Rule Core

Confidence is High at 82 to 99, Medium at 58 to 81, and Low below 58. The separate action floor is inclusive: a score equal to the floor is action ready. Candidate chart scores are each candidate's summed evidence weight rounded and clamped from 0 to 99; those values are not the same calculation as the final confidence score.

The redirect setting allows 0 to 12 followed redirects and therefore at most 13 observed responses. Each hop uses the selected timeout cap, while the remote run has an overall deadline of about 8.9 seconds. A missing candidate returns Unknown with zero confidence rather than guessing from generic headers.

Privacy and Accuracy Notes:

A live run sends the public URL, request method, timeout, redirect policy, and selected or custom User-Agent to a remote checker, which then requests the target. The URL and custom User-Agent are not placed in the share address. Avoid authenticated, signed, private, or sensitive URLs.

  • Headers can be hidden, forged, or rewritten, so attribution is probabilistic evidence.
  • DNS, location, cache state, bot handling, and deployment changes can alter the observed path.
  • The check does not scan ports, authenticate, inspect page content, or prove which software is installed on a hidden origin.

Worked Examples:

CDN winner with an origin hint

A two-hop request may return several Cloudflare signatures on both responses and one lower-weight Nginx hint on the final hop. Cloudflare ranks first because its repeated edge evidence is stronger; Nginx remains an origin hint. Record Cloudflare as the client-visible layer, then verify Nginx against load-balancer or origin configuration before describing the backend.

References: