CIDR Allow/Deny Snippet Generator (nginx)

The CIDR Allow/Deny Snippet Generator for nginx creates ready-to-use nginx configuration blocks with allow and deny directives from lists of IP addresses or CIDR blocks. Enter addresses like 192.168.1.0/24 and 10.0.0.0/8, choose allowlist or blocklist mode, and get correctly formatted directives you can paste directly into your server blocks or save as an include file.

Understanding nginx Access Control

If you run nginx as a web server or reverse proxy, IP-based access control is one of the simplest and most effective ways to protect sensitive resources. The ngx_http_access_module is compiled into nginx by default and requires no additional installation -- you just add allow and deny directives to your configuration. This is the standard approach for restricting admin panels, internal APIs, staging servers, and any endpoint that should not be publicly accessible.

The concept is straightforward: you list the IP addresses or CIDR blocks that should be allowed (or denied), and nginx checks each incoming request against the list. The key detail that trips people up is evaluation order. Nginx processes allow and deny directives from top to bottom and stops at the first match. If deny all appears before your allow lines, every request is denied regardless of the source IP. The generator handles this automatically by always placing the default rule at the end, but understanding the evaluation model is important when you are troubleshooting access issues.

Where nginx access control gets complicated is in multi-level configurations. Directives in a location block override those in the enclosing server block, which override those in the http block. If you set up an allowlist in your server block but forget to apply it to a specific location, that location inherits whatever the parent defines. For complex configurations, the cleanest approach is to put your access rules in a separate file and include it wherever needed, which is exactly the workflow the generator supports.

How to Generate nginx Allow/Deny Directives

1. Enter your IP addresses or CIDR blocks -- one per line or comma-separated.
2. Select the mode: allowlist (allow listed IPs, deny all others) or blocklist (deny listed IPs, allow all others).
3. The generator formats each entry as a proper nginx directive with correct syntax.
4. Copy the output into your nginx server, location, or http block, or save it as an include file.
5. Run nginx -t to test the configuration, then reload with nginx -s reload.

nginx Allow/Deny Output Examples

Allowlist Mode

Input:

192.168.1.0/24
10.0.0.0/8
203.0.113.50

Output:

allow 192.168.1.0/24;
allow 10.0.0.0/8;
allow 203.0.113.50;
deny all;

Blocklist Mode

Input:

198.51.100.0/24
203.0.113.0/24

Output:

deny 198.51.100.0/24;
deny 203.0.113.0/24;
allow all;

Using an Include File

server {
    listen 443 ssl;
    server_name admin.example.com;

    include /etc/nginx/conf.d/admin-allowlist.conf;

    location / {
        proxy_pass http://backend;
    }
}

When to Use the nginx CIDR Snippet Generator

• Admin panel protection -- Restrict /admin or /wp-admin access to office and VPN IP ranges only.
• Staging server access control -- Limit staging environments to developer and QA team IP addresses.
• API rate limiting by IP -- Combined with limit_req_zone, allow higher limits for known partner IPs while restricting unknown sources.
• Geographic blocking -- Block entire country-level CIDR ranges from accessing specific resources.
• Compliance requirements -- Restrict access to sensitive data endpoints to approved corporate network ranges.

How nginx Access Control Directives Work

Rule Processing Order

Nginx evaluates allow and deny directives in order from top to bottom. The first matching rule wins. This means:

# This WORKS -- specific allow before general deny
allow 192.168.1.0/24;
deny all;

# This DOES NOT WORK -- deny all is evaluated first
deny all;
allow 192.168.1.0/24;   # never reached

The generator always places the default rule (deny all or allow all) at the end to ensure correct evaluation.

Directive Scope

Access control directives can be placed at different levels:

• http block -- Applies to all virtual hosts
• server block -- Applies to a specific virtual host
• location block -- Applies to a specific URL path

location /api/internal {
    allow 10.0.0.0/8;
    deny all;

    proxy_pass http://internal-api;
}

IPv6 Support

The generator handles IPv6 addresses and CIDR blocks with the same syntax:

allow 2001:db8::/32;
allow 192.168.1.0/24;
deny all;

Combining with Proxy Headers

When nginx sits behind a load balancer or CDN, the client IP comes from a header like X-Forwarded-For rather than the TCP connection. In this case, use the ngx_http_realip_module to set the real client IP before access control evaluation:

set_real_ip_from 10.0.0.0/8;       # trust your load balancer range
real_ip_header X-Forwarded-For;
real_ip_recursive on;

allow 203.0.113.0/24;              # allow based on real client IP
deny all;

Practical Advice for nginx Access Control

The most common mistake with nginx access control is not testing your configuration before reloading. A missing semicolon, an invalid CIDR block, or even a stray character will cause nginx -t to fail, and if you reload without testing, the old configuration stays active -- but the next time nginx restarts (after a server reboot, for example), it will refuse to start entirely because the invalid configuration is on disk. Always run nginx -t before nginx -s reload, and consider putting this check in your deployment scripts as an automated gate.

When protecting admin panels, do not rely solely on IP-based access control. Use it as one layer in a defense-in-depth approach: IP allowlisting to limit who can even reach the login page, strong authentication behind it, and rate limiting to prevent brute-force attacks from any allowed IP. IP addresses can be spoofed at the application layer (via forged headers), so make sure you configure real_ip_header correctly if you are behind a reverse proxy, and never trust X-Forwarded-For directly without validating the immediate upstream.

For large allowlists (hundreds of entries), consider using the geo module instead of individual allow/deny directives. The geo module uses a binary search tree internally, which is faster than the linear scan of allow/deny for large lists. The trade-off is slightly more complex configuration, but for lists beyond 50-100 entries, the performance difference is measurable on high-traffic servers.

Frequently Asked Questions

Why does nginx fail to start after adding allow/deny rules? The most common cause is a missing semicolon at the end of a directive line. Every allow and deny line must end with ;. The generator handles this automatically. Run nginx -t to check syntax before reloading.

Can I mix allow and deny directives in a single block? Yes, but the order matters. Nginx processes rules top-to-bottom and stops at the first match. Typically you either allow a set of IPs and deny all others, or deny a set and allow all others. Mixing allow and deny for different IP ranges in the same block is valid but harder to maintain.

What is the difference between deny all and return 403? deny all is an access control directive that returns a 403 Forbidden response. return 403 is a content directive that also returns 403 but does not participate in the allow/deny evaluation chain. For IP-based access control, always use allow/deny directives.

How do I include the generated snippet in my nginx config? Save the output to a file like /etc/nginx/conf.d/allowlist.conf and use the include directive in your server or location block: include /etc/nginx/conf.d/allowlist.conf;

What if my nginx is behind a CDN or load balancer? You need to configure the ngx_http_realip_module to extract the real client IP from the appropriate header (usually X-Forwarded-For or X-Real-IP). Without this, nginx sees the CDN or load balancer IP for every request, and your allowlist matches against the wrong address.

Is there a limit to how many allow/deny rules nginx can handle? There is no hard limit, but performance degrades linearly with the number of rules because nginx scans them sequentially. For lists beyond 100 entries, consider using the geo module or the map directive for better performance. For most configurations with under 50 rules, the performance impact is negligible.

Related Tools

• Apache Require ip Snippet Generator - Generate Apache Require ip directives
• Allowlist Builder - Build minimal CIDR allowlist from IP list
• Blocklist Builder - Build minimal CIDR blocklist from IP list
• iptables Rule Generator - Generate iptables rules from CSV
• IP:Port Allowlist Validator - Validate bulk IP:port entries