IP-based access control (allow/deny) in Nginx - Step-by-Step Execution

Process Flow - IP-based access control (allow/deny)

Request arrives

↓

Check client IP

↓

Is IP allowed?

No→Is IP denied?

↓

Allow request

The server checks the client's IP against allow and deny rules to decide if the request is allowed or blocked.

Execution Sample

Nginx

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

This config allows requests from 192.168.1.0/24 and denies all others.

Process Table

Step	Client IP	Check allow	Check deny	Decision
1	192.168.1.10	Matches allow 192.168.1.0/24	Not checked (allowed)	Allow request
2	10.0.0.5	No match	Matches deny all	Block request
3	192.168.2.1	No match	Matches deny all	Block request
4	192.168.1.255	Matches allow 192.168.1.0/24	Not checked (allowed)	Allow request
5	127.0.0.1	No match	Matches deny all	Block request
6	End of requests	-	-	Stop checking

💡 Requests are allowed if IP matches allow rules; otherwise denied if matching deny rules or denied by default.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	Final
client_ip	-	192.168.1.10	10.0.0.5	192.168.2.1	192.168.1.255	127.0.0.1	-
allow_check	-	true	false	false	true	false	-
deny_check	-	false	true	true	false	true	-
decision	-	allow	deny	deny	allow	deny	-

Key Moments - 3 Insights

Why does the server allow 192.168.1.10 but deny 192.168.2.1 even though both are private IPs?

Because 192.168.1.10 matches the allow rule (192.168.1.0/24), so it is allowed immediately. 192.168.2.1 does not match allow, so it falls through to deny all and is blocked (see execution_table rows 1 and 3).

What happens if an IP matches both allow and deny rules?

Nginx processes allow rules first. If an IP matches allow, it is allowed immediately without checking deny rules (see execution_table row 1 and 4). Deny rules are only checked if allow rules do not match.

Why is 'deny all;' needed after 'allow 192.168.1.0/24;'?

Because without 'deny all;', requests from IPs not in the allowed range would be allowed by default. 'deny all;' blocks all other IPs not explicitly allowed (see execution_table rows 2, 3, 5).

Visual Quiz - 3 Questions

Look at the execution table. What is the decision for client IP 10.0.0.5 at step 2?

A Allow request

B Check next rule

C Block request

D No decision yet

💡 Hint

Refer to execution_table row 2 under 'Decision' column.

At which step does the client IP match the allow rule?

A Step 3

B Step 1

C Step 2

D Step 5

💡 Hint

Check 'Check allow' column in execution_table for 'Matches allow' text.

If we remove 'deny all;', what would happen to client IP 127.0.0.1 at step 5?

A It would be allowed

B It would be blocked

C It would cause an error

D It would be logged but no decision

💡 Hint

Look at execution_table row 5 and consider the effect of removing 'deny all;'.

Concept Snapshot

IP-based access control in nginx:
- Use 'allow <IP or CIDR>;' to permit IPs
- Use 'deny <IP or all>;' to block IPs
- Nginx checks allow rules first, then deny rules
- If no allow matches, deny rules apply
- 'deny all;' blocks all IPs not allowed
- Order matters: allow then deny

Full Transcript

This visual execution shows how nginx uses IP-based access control with allow and deny directives. When a request arrives, nginx checks the client's IP against allow rules first. If the IP matches an allow rule, the request is allowed immediately. If not, nginx checks deny rules. If the IP matches a deny rule, the request is blocked. If no rules match, the default is to allow unless 'deny all;' is specified. The example config allows IPs in 192.168.1.0/24 and denies all others. The execution table traces five example IPs through these checks, showing which are allowed or blocked. Key moments clarify why some IPs are allowed or denied and the importance of rule order. The quiz tests understanding of decisions at specific steps and the effect of removing deny rules.