How to enable Nginx stub_status page

An internal stub_status endpoint exposes a fast, low-overhead snapshot of Nginx activity that helps confirm whether the web tier is constrained by connections or request volume during incidents and load tests.

The stub_status directive (from the ngx_http_stub_status_module) returns a small plaintext payload with connection counts and cumulative request counters. When configured inside a dedicated location, it becomes a simple diagnostics surface that can be queried with curl or polled by monitoring collectors.

The output is operationally useful but also operationally chatty: leaving it reachable from untrusted networks leaks service metadata and makes reconnaissance easier. Keep the location locked down (localhost or an admin subnet), reload safely after testing the config, and verify both the expected status output and the expected access restrictions.

1. Add a protected status location to a server block.

   location = /nginx_status {
       stub_status;
       access_log off;
       allow 127.0.0.1;
       allow ::1;
       deny all;
   }

   Using location = /nginx_status avoids matching unintended subpaths like /nginx_status/foo.

2. Test the configuration for syntax errors.

   $ sudo nginx -t
   nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
   nginx: configuration file /etc/nginx/nginx.conf test is successful

3. Reload Nginx to apply the change.

   $ sudo systemctl reload nginx

   On non-systemd systems, sudo nginx -s reload is a common equivalent.

4. Verify status output locally.

   $ curl -s http://127.0.0.1/nginx_status
   Active connections: 1
   server accepts handled requests
     42 42 123
   Reading: 0 Writing: 1 Waiting: 0

5. Verify the access rules deny non-local requests.

   $ curl -s -o /dev/null -w "%{http_code}\n" http://<server-ip>/nginx_status
   403

   A 200 response from an untrusted network means the endpoint is exposed and should be restricted immediately.