nginx-prometheus-exporter publishes the proxy state it can see

The nginx-prometheus-exporter converts nginx status data into Prometheus metrics. Its default web port is commonly documented as 9113. The exporter does not read every part of nginx. It reads the status interface or API that its configuration can reach, and that dependency defines the security boundary.

The measurements

The count-only queries completed on November 5, 2026:

The port population and the build-information population are different observations. Neither is a confirmed list of nginx exporters, and the zero application count means the application field did not identify the product in this query.

Two HTTP boundaries

The exporter exposes a metrics endpoint to Prometheus. It also connects to nginx through a scrape URI, often a local status endpoint or the nginx Plus API. Both sides need a policy.

On the exporter side, bind the listener to a private address and restrict the monitoring source. On the nginx side, restrict the status endpoint to the exporter's address. The status endpoint can reveal request counts, connection state, upstream health, and other operational details. It should not be exposed to the public internet.

The nginx status module may require a separate location and access rule. The exporter URI can include a host, port, path, and credentials. Store those values in a protected configuration and avoid printing the full URI in logs.

Metrics are not the same as access

An exposed exporter can disclose nginx version, build information, upstream names, server zones, and traffic patterns. The exposure may help an attacker map which services are active and when they receive traffic. It does not by itself grant access to nginx configuration or client traffic.

Do not extrapolate from a metric count to a compromised reverse proxy. Compare the exporter's /metrics response with the nginx status endpoint and the deployment inventory. Confirm that the exporter's read-only status query is the only capability it has.

If the exporter supports TLS and authentication through the exporter toolkit, enable them where the monitoring path crosses an untrusted network. Validate the certificate from the Prometheus host. A self-signed certificate copied into a trust store needs an owner and a rotation plan.

Test the scrape path

From the monitoring host, request the exporter endpoint and check the expected nginx metric prefixes. From an ordinary user network, confirm the request is denied. Then inspect nginx access logs for the status path: the source should be the exporter, not an arbitrary client.

Keep the exporter and nginx versions in the asset inventory. A change to nginx's status API can break collection, and a change to the exporter's configuration can broaden the URI or credentials it uses. Treat both changes as production changes.

The useful conclusion

The five port matches are a small review set. The one body match is an even smaller signal, not a guarantee. The practical task is to identify the owned nginx instances, find their exporter dependencies, and verify that the status path and metrics path are both restricted. The exporter is useful when it remains a monitoring component, not a public description of the reverse proxy.

References

• nginx-prometheus-exporter
• nginx status module
• Default port allocations
• ZoomEye search platform