How much of the public internet runs on Caddy? A ZoomEye measurement of 1.7 million assets

What the number is for

Caddy is a web server written in Go, and its distinguishing feature is automatic HTTPS: it obtains and renews TLS certificates without a configuration file entry, which removed one of the most tedious parts of running a web server and made the project a default choice for self-hosted services, internal tools and small production deployments. That property also makes it interesting to measure, because Caddy installations are usually personal or departmental rather than part of a large managed fleet, and a fleet-scale view of them is hard to assemble from purchase records.
ZoomEye reports 1,698,802 assets matching the Caddy product fingerprint, and 82,859 of those also match a query for port 443.

Context and method

The measurement comes from a product fingerprint query rather than from a bare string match, which matters for interpretation. A fingerprint match means the scan response contained evidence the platform associates with Caddy, not that the operator confirmed the software by hand. The second query narrows the population to assets where the fingerprint match and an open 443 coincide.
Two limits apply to both figures. The index is a snapshot of what a scanner observed and recorded, and it changes continuously as hosts appear, disappear and rotate addresses. More importantly, the numbers describe exposure, not vulnerability: an asset that matches the Caddy fingerprint is a candidate for an inventory, and nothing about the measurement says whether it is patched, misconfigured or running something the owner intended.

Reading the gap between the two counts

The distance between 1,698,802 and 82,859 is the useful part of the measurement. Automatic HTTPS means Caddy is expected to be serving TLS, so a population five percent the size of the fingerprint match is a signal worth explaining rather than a coincidence. Some of the gap is measurement artefact: the scanner's port probe and its fingerprint probe do not always agree, and an asset can be fingerprinted through a service that is not reachable on 443 from the probe's vantage point.
The parts of the gap that are not artefact are the interesting cases. Caddy is frequently deployed as a reverse proxy in front of one or more backend applications, and the operator often puts a different TLS terminator in front of it, or runs it behind a load balancer that owns the certificate. In that arrangement the Caddy instance is plaintext on a high port with the proxy doing the encryption, and it is reachable on the internal network rather than from a scanner. The same shape appears in container platforms, where Caddy listens on an internal service address inside a cluster and only the ingress controller is published.
For an owner, that distinction has an operational consequence. A Caddy instance whose TLS is terminated elsewhere depends on the fronting component for its security controls, and the configuration that people review is often the one they wrote rather than the one that is actually terminating traffic.

The two administrative surfaces worth checking

Two features of Caddy deserve attention in any inventory, and neither is a vulnerability in the software.
The admin endpoint is the first. Caddy exposes a configuration API for live changes, and it is bound to the loopback interface by default, which is a sensible choice that is easy to override for the convenience of managing a remote instance. An admin endpoint reachable from a wider network is remote configuration control for a process that is usually running as a service account, and the mitigation is an SSH tunnel or a local socket rather than a bind address change.
The second is the automatic certificate issuance. It is what makes Caddy pleasant to run and it means a deployment depends on outbound access to a certificate authority, on the reachability of a challenge endpoint, and on the persistent state of the certificate store. A misconfigured or throttled issuance path produces a certificate error rather than an outage, which is the good case; a stale or duplicated certificate store produces the confusing case where the effective certificate is not the one in the file a reviewer is reading.

What to do with the measurement

Treat the figure as a scope estimate, not a finding. If the organisation's external address space is small, the national or organisational filter matters more than the global total, and repeating the query scoped to those addresses produces a list that can be reconciled against the service register.
Then check the bind address question directly. On any Caddy instance, the useful facts are which listeners exist, which are intended to be reachable from outside the host and which are not, and whether the TLS terminator is the process being reviewed. Every one of those questions is answerable from the running configuration, which makes this a short piece of work when someone owns it and an indefinitely deferred one when nobody does.
Finally, record the answer where the next review will find it. The reason a reverse proxy ends up in an unexpected state is rarely neglect; it is that the person who understood the layout left, and the configuration survived as a file that works.