284 Million Server Headers Against 313 Million Fingerprints: Two Ways to Count the Same Web Server

The same software can be counted in more than one way, and the two counts will disagree. That disagreement is not a defect; it is a property of the measurement, and understanding it prevents a category of analytic mistake.

The measurements

On 20 October 2026, between 22:33 and 22:37 UTC, queries with sub_type="all" and a page size of one record returned:

Query	Matched assets
`http.header.server="nginx"`	284,114,163
`app="nginx"`	313,028,543
`app="Apache httpd"`	599,482,423
`app="OpenSSH"`	137,173,523

The gap between the two nginx figures is about 29 million, roughly ten percent. Both numbers are large enough that the difference is not statistical noise; it reflects what each query asks.

What each query actually asks

The header query asks: does this asset return an HTTP response whose Server header contains the string nginx?

That is a behavioural question with a simple answer. It fails whenever the header is removed, rewritten or replaced — which is common practice. Reverse proxies frequently normalize or strip the server header. Security guidance has recommended removing it for years.

The fingerprint query asks: does the scanning engine's product-detection logic classify this asset as nginx?

That question can be answered from body markers, default error pages, characteristic responses to malformed requests, or header patterns. It can succeed where the header has been stripped, and it can produce false positives where a proxy serves nginx-generated content on behalf of a different origin.

So the fingerprint count is higher because it can see evidence the header query cannot, and the header count is more precise because it reflects a single observable fact.

Why this matters for inventory

Neither number tells an organization how many nginx instances it operates. Both are populations of assets matching a definition.

The practical consequence is that trend analysis must fix the definition. Comparing this quarter's app="nginx" count to last quarter's header count produces a meaningless change. This sounds elementary and is a frequent error in exposure dashboards, where a query is edited and the resulting series is presented as a trend.

The same discipline applies to the large Apache httpd figure. At 599 million, app="Apache httpd" is about twice the nginx fingerprint count. Whether that reflects a larger installed base, a broader detection signature, or different classification rules for embedded deployments is not determinable from the counts alone.

The reverse proxy blindness

An important consequence of proxy-mediated web serving is that the observed product is often not the application. An nginx front end terminating TLS for a Java application will present nginx headers and may be classified as nginx, while the vulnerable component is behind it.

This is a systemic limitation of external counting for web applications, and it is not fixable by better fingerprinting. The observation happens at the network edge; the application lives behind it.

For defenders, that means an inventory based on external observation will systematically undercount application servers and overcount their front ends. Internal discovery remains necessary.

OpenSSH as a comparison

app="OpenSSH" at 137 million is the SSH protocol's recognizable implementation. SSH services were measured at 166,939,313 in the same session, so OpenSSH accounts for the large majority of SSH endpoints but not all of them.

The residual is attributable to other implementations, embedded SSH servers in appliances and network devices, and services that respond on port 22 without identifying as OpenSSH. That is a sensible result and shows what a well-covered fingerprint looks like: a product count close to, but below, the protocol count.

Using that as a reference, the nginx gap of ten percent looks like reasonable detection coverage rather than a problem. A product count within ten percent of the corresponding behavioural count, in an area where header stripping is standard practice, is a sign the fingerprint is doing real work.

Choosing a query for a purpose

For a point-in-time statement about a product class, use the fingerprint and state the definition. For a verifiable claim about observable behaviour, use the header. For a trend, keep whichever you chose for every measurement in the series.

What none of them support is a claim about how much software is installed in the world. They describe what a particular scanner saw when it asked a particular question, and that is a narrower and more defensible thing.