Stub status module in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Nginx stub_status basic output

You have enabled the stub_status module in Nginx and accessed the status URL. What is the typical output format you will see?

A

Server status: OK
Connections: 5
Requests: 20
CPU usage: 10%

B

Status: Active
Connections: 5
Requests handled: 20
Errors: 0

C

Active connections: 5 
server accepts handled requests
 10 10 20 
Reading: 0 Writing: 1 Waiting: 4

D

Nginx running
Connections: 5
Requests: 20
Memory usage: 50MB

💡 Hint

Look for the exact format with 'Active connections' and the three numbers line.

The stub_status module outputs a fixed format showing active connections, accepts, handled, requests, and the states Reading, Writing, Waiting.

❓ Configuration

intermediate

Enable stub_status in Nginx config

Which configuration snippet correctly enables the stub_status module on the /nginx_status URL in Nginx?

A

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

B

location /nginx_status {
    status_stub on;
    allow 127.0.0.1;
    deny all;
}

C

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

D

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

💡 Hint

The directive to enable stub_status is exactly 'stub_status;' inside the location block.

The stub_status module is enabled by the directive 'stub_status;' without 'on' or other keywords.

❓ Troubleshoot

advanced

Stub_status returns 404 error

You configured stub_status on /status but when accessing http://localhost/status you get a 404 error. What is the most likely cause?

A The stub_status module is not compiled into Nginx.

B The Nginx service is not running.

C The firewall is blocking port 80.

D The stub_status directive is missing inside the location block for /status.

💡 Hint

Stub_status must be compiled into Nginx or it won't recognize the directive.

If stub_status is not compiled in, Nginx will not recognize the location and return 404.

🔀 Workflow

advanced

Secure stub_status access workflow

You want to allow stub_status access only from your local machine and deny all others. Which workflow correctly achieves this?

A Configure location with stub_status; allow all; then reload Nginx.

B Configure location with stub_status; allow 0.0.0.0/0; then reload Nginx.

C Configure location with stub_status; deny all; then reload Nginx.

D Configure location with stub_status; allow 127.0.0.1; deny all; then reload Nginx.

💡 Hint

Allow only localhost IP and deny all others is the secure approach.

Allow 127.0.0.1; deny all; restricts access to local machine only.

✅ Best Practice

expert

Best practice for monitoring with stub_status

Which practice is best when using stub_status for production monitoring?

A Disable stub_status completely to avoid any information leaks.

B Enable stub_status only on localhost and use a secure proxy for remote access.

C Expose stub_status publicly without restrictions for easy access.

D Use stub_status with default settings and no IP restrictions.

💡 Hint

Consider security and controlled access for production environments.

Limiting stub_status to localhost and accessing it securely via proxy prevents unauthorized access.

Practice

1. What is the main purpose of the stub_status module in nginx?

easy

A. To provide basic server statistics like active connections and requests

B. To enable SSL encryption for secure connections

C. To serve static files faster

D. To balance load between multiple servers

Solution

1. Step 1: Understand the stub status module role

   The stub status module is designed to show simple server stats such as active connections and request counts.

2. Step 2: Compare with other options

   SSL encryption, static file serving, and load balancing are handled by other nginx modules, not stub status.

3. Final Answer:

   To provide basic server statistics like active connections and requests -> Option A

4. Quick Check:

   Stub status = server stats [OK]

Hint: Stub status shows server stats, not security or file serving [OK]

Common Mistakes:

• Confusing stub_status with SSL or load balancing modules
• Thinking stub_status serves files
• Assuming stub_status handles security

2. Which of the following is the correct way to enable the stub status module inside an nginx configuration location block?

easy

A. location /status { stub_status; }

B. location /status { stub_status on; }

C. location /status { status_stub; }

D. location /status { enable_stub_status; }

Solution

1. Step 1: Recall stub status syntax

   The stub status module is enabled simply by adding stub_status; inside a location block without extra keywords.

2. Step 2: Check each option

   location /status { stub_status on; } uses incorrect syntax with stub_status on;. Options C and D use invalid directives.

3. Final Answer:

   location /status { stub_status; } -> Option A

4. Quick Check:

   Enable stub_status with just 'stub_status;' [OK]

Hint: Use exactly 'stub_status;' inside location block [OK]

Common Mistakes:

• Adding 'on' or other keywords after stub_status
• Using wrong directive names
• Placing stub_status outside location block

3. Given this nginx configuration snippet:

location /nginx_status {
    stub_status;
    allow 192.168.1.0/24;
    deny all;
}

What will happen if a client from IP 192.168.1.15 accesses /nginx_status?

medium

A. The client will download the nginx configuration file

B. The client will see nginx server statistics

C. The client will be redirected to the homepage

D. The client will get a 403 Forbidden error

Solution

1. Step 1: Analyze IP access rules

   The configuration allows IPs in 192.168.1.0/24 and denies all others. IP 192.168.1.15 is inside this range, so access is allowed.

2. Step 2: Understand stub_status output

   With access allowed, the client will see the nginx server statistics page generated by stub_status.

3. Final Answer:

   The client will see nginx server statistics -> Option B

4. Quick Check:

   Allowed IP + stub_status = stats page [OK]

Hint: Allowed IPs see stats; others get denied [OK]

Common Mistakes:

• Ignoring IP allow/deny order
• Assuming all IPs can access stub_status
• Thinking stub_status redirects or downloads files

4. You configured nginx with:

location /status {
    stub_status;
}

But when you visit /status, you get a 403 Forbidden error. What is the most likely cause?

medium

A. The stub_status directive is misspelled

B. Nginx does not support stub_status on this version

C. The location block is missing a root directive

D. Access is not restricted by allow/deny rules, so default deny applies

Solution

1. Step 1: Understand default access behavior

   By default, nginx denies access if no allow/deny rules are set and the stub_status is enabled, causing 403 errors.

2. Step 2: Check other options

   The stub_status directive is correct, root is not required for stub_status, and most nginx versions support stub_status.

3. Final Answer:

   Access is not restricted by allow/deny rules, so default deny applies -> Option D

4. Quick Check:

   No allow/deny means deny by default [OK]

Hint: Always add allow/deny rules to permit stub_status access [OK]

Common Mistakes:

• Forgetting to add allow rules for trusted IPs
• Assuming stub_status needs root directive
• Blaming nginx version without checking

5. You want to monitor nginx server stats securely using stub status. Which configuration snippet correctly enables stub status at /status and restricts access only to localhost?

hard

A. location /status {
stub_status;
deny 127.0.0.1;
allow all;
}

B. location /status {
stub_status on;
allow all;
}

C. location /status {
stub_status;
allow 127.0.0.1;
deny all;
}

D. location /status {
stub_status;
allow 0.0.0.0/0;
}

Solution

1. Step 1: Enable stub_status correctly

   Use stub_status; inside the location block without extra keywords.

2. Step 2: Restrict access to localhost

   Allow only 127.0.0.1 and deny all others to secure access.

3. Step 3: Evaluate options

   location /status { stub_status; allow 127.0.0.1; deny all; } correctly enables stub_status and restricts access. location /status { stub_status on; allow all; } wrongly uses 'stub_status on;' and allows all. location /status { stub_status; deny 127.0.0.1; allow all; } denies localhost but allows all others, which is insecure. location /status { stub_status; allow 0.0.0.0/0; } allows all IPs.

4. Final Answer:

   location /status { stub_status; allow 127.0.0.1; deny all; } -> Option C

5. Quick Check:

   Stub_status + allow localhost + deny others = secure [OK]

Hint: Allow localhost and deny all others for secure stub_status [OK]

Common Mistakes:

• Using 'stub_status on;' instead of 'stub_status;'
• Allowing all IPs instead of restricting
• Denying localhost but allowing others