Stub status module in Nginx - Step-by-Step Execution

Process Flow - Stub status module

Enable stub_status in nginx.conf

↓

Reload nginx to apply config

↓

Send HTTP request to /nginx_status

↓

nginx returns status info

↓

Parse output for metrics

The stub status module is enabled in nginx config, nginx is reloaded, then a request to the status URL returns server metrics.

Execution Sample

Nginx

location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

# Then reload nginx

This config block enables the stub status page at /nginx_status, allowing only local access.

Process Table

Step	Action	Input/Request	Output/Result
1	Add stub_status block to nginx.conf	N/A	Config updated with /nginx_status location
2	Reload nginx	nginx -s reload	nginx applies new config without downtime
3	Send HTTP GET to http://127.0.0.1/nginx_status	GET /nginx_status	200 OK with status text
4	Receive stub_status output	N/A	Active connections: 1 server accepts handled requests 10 10 20 Reading: 0 Writing: 1 Waiting: 0
5	Parse output for metrics	Status text	Metrics extracted: active connections=1, accepts=10, handled=10, requests=20, reading=0, writing=1, waiting=0
6	End	N/A	Status info ready for monitoring

💡 Stub status output retrieved and parsed successfully

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
nginx.conf	Original config	Config with stub_status block	Config with stub_status block	Config with stub_status block	Config with stub_status block	Config with stub_status block
nginx process	Running old config	Running old config	Running new config	Running new config	Running new config	Running new config
HTTP response	None	None	None	200 OK with status text	200 OK with status text	200 OK with status text
Parsed metrics	None	None	None	None	Extracted metrics object	Extracted metrics object

Key Moments - 3 Insights

Why do we need to reload nginx after adding the stub_status block?

Because nginx reads its configuration only at startup or reload. The execution_table step 2 shows reload applies the new config without downtime.

Why does the stub_status location allow only 127.0.0.1?

To restrict access to local machine for security. Step 3 shows the request is sent to 127.0.0.1, matching the allow rule.

What does the stub_status output tell us?

It shows live server metrics like active connections and requests handled, as seen in step 4 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution table, what is the HTTP response status code at step 3?

A 404 Not Found

B 200 OK

C 500 Internal Server Error

D 403 Forbidden

💡 Hint

Check the 'Output/Result' column at step 3 in the execution_table.

At which step does nginx apply the new configuration?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look for the action 'Reload nginx' in the execution_table.

If we remove the 'allow 127.0.0.1;' line, what will likely happen when requesting /nginx_status from localhost?

A nginx will fail to reload

B Access will be allowed

C Access will be denied (403 Forbidden)

D The stub_status output will be empty

💡 Hint

Consider the default deny all rule and the allow line in the config from execution_sample.

Concept Snapshot

Stub status module in nginx:
- Enable with 'stub_status;' inside a location block
- Restrict access with 'allow' and 'deny'
- Reload nginx to apply config
- Access /nginx_status URL to get live server metrics
- Output shows active connections, accepts, handled, requests, reading, writing, waiting

Full Transcript

The stub status module in nginx provides a simple way to get live server metrics. First, you add a location block with 'stub_status;' in the nginx configuration file. You usually restrict access to localhost using 'allow 127.0.0.1;' and 'deny all;'. After saving the config, you reload nginx to apply the changes without downtime. Then, when you send an HTTP GET request to the /nginx_status URL on localhost, nginx returns a plain text status page showing active connections, accepted connections, handled connections, total requests, and current reading, writing, and waiting connections. This output can be parsed by monitoring tools to track nginx performance.