NGINX: Allow or Deny Access by IP Address — ngx_http_access_module Guide Print

This guide explains how to allow or deny access to your website or server by IP address using NGINX and the built-in ngx_http_access_module. This is one of the most effective ways to restrict access to admin panels, APIs, staging environments, and sensitive directories on a Linux VPS or dedicated server without installing any additional software.

Running this on a VPS or dedicated server? If you need a clean Linux server to test or deploy your NGINX configuration, see our KVM VPS plans in New York and other US and EU locations.

How ngx_http_access_module Works

The ngx_http_access_module is built into NGINX by default — no additional installation is required. It processes allow and deny directives in the order they appear, top to bottom, and stops at the first match. This means rule order matters significantly.

Basic syntax:

In this example, the subnet 192.168.1.0/24 is allowed with the exception of 192.168.1.1. The subnet 10.1.1.0/16 is also allowed. The IPv6 range 2001:0db8::/32 is allowed. All other addresses are denied. Rules are evaluated top to bottom — the first match wins.

Before You Start

• You must have sudo or root access on the server
• NGINX must already be installed and running — confirm with sudo systemctl status nginx
• Know the IP address or CIDR range you want to allow or block before editing any config files
• Always test your configuration with sudo nginx -t before reloading — a syntax error will take your site down
• Have a backup access method (console or out-of-band access) in case you accidentally lock yourself out

Method 1: Inline Rules in the Server or Location Block

The simplest approach is to add allow and deny rules directly inside a location block in your site configuration file. Configuration files are typically located in /etc/nginx/sites-available/ on Debian/Ubuntu, or /etc/nginx/conf.d/ on RHEL, AlmaLinux, and Rocky Linux.

Open your site configuration file:

Add the access rules inside the relevant location block. To restrict access to an admin panel to a single IP:

To restrict access to a subnet while blocking a specific address within it:

Method 2: External Include File (Recommended for Large Lists)

For larger IP lists or rules shared across multiple server blocks, use an external file and include it in your configuration. This allows you to update the IP list without touching the main NGINX configuration files, and without needing to be root to edit the list itself.

Create the IP access file in a proper system location:

To block specific IPs while allowing everyone else:

To allow only specific IPs and block everyone else:

Now include this file inside the appropriate server or location block in your site configuration — not in the http block, as allow and deny directives are only valid in server, location, and limit_except contexts:

Test and Reload NGINX

Always test your configuration for syntax errors before reloading. A broken configuration will prevent NGINX from reloading and could take your site offline if the service is restarted.

Test the configuration:

If the output shows syntax is ok and test is successful, reload NGINX to apply the changes:

If the test returns an error, fix the issue before reloading. Do not use systemctl restart nginx for configuration changes — reload applies changes gracefully without dropping active connections.

Customize the HTTP 403 Forbidden Error Page

The default NGINX 403 page is minimal. To display a custom page when a blocked IP attempts access, create an HTML file in your web root:

Paste your custom error content:

Then add the following inside your server block to point NGINX at the custom file. The allow all exemption is required — without it, blocked clients would also be denied access to the error page itself and see a generic 403 instead:

Test and reload after making this change:

Common Use Cases

• Restrict admin panels: Block public access to /wp-admin, /phpmyadmin, or custom admin paths to specific office or home IPs only
• Staging environment lockdown: Allow only your team's IPs on a staging subdomain while keeping production open
• API endpoint protection: Limit access to internal APIs to known server or application IPs
• Block abusive IPs: Quickly deny specific IPs or ranges that are generating bad traffic or scraping your site
• Internal tool access: Serve monitoring dashboards, metrics endpoints, or status pages only to trusted subnets

Related Solution

Frequently Asked Questions

Does ngx_http_access_module need to be installed separately?

No. The ngx_http_access_module is compiled into NGINX by default on all major Linux distributions. No additional packages or modules are required to use allow and deny directives.

What is the correct order for allow and deny rules in NGINX?

Rules are evaluated top to bottom and the first match wins. Always place more specific rules before broader ones. For example, if you want to deny a single IP within an allowed subnet, the deny for that IP must appear before the allow for the subnet.

Where should I put allow and deny directives in nginx.conf?

allow and deny are valid inside server, location, and limit_except blocks. They are not valid in the top-level http block. The most common and precise placement is inside a specific location block targeting the path you want to protect.

How do I reload NGINX after changing IP rules?

Use sudo nginx -t to test for syntax errors, then sudo systemctl reload nginx to apply the changes. Using reload instead of restart applies the new configuration without dropping active connections.

Can I use this to block access by country?

The ngx_http_access_module works with individual IPs and CIDR ranges only. For country-level blocking, you would need the ngx_http_geoip_module or ngx_http_geoip2_module, which map IP addresses to geographic regions using a database like MaxMind GeoIP2.

Can I test this on a VPS before applying it to production?

Yes, and it is strongly recommended. Misconfigured IP rules can lock you out of your own server. Testing on a separate KVM VPS first lets you validate the allow/deny logic and confirm the 403 behavior before applying changes to a live environment.