How to Restrict Access to Directories by IP Address

Restricting a directory to a short list of trusted IP addresses is one of the simplest and most effective ways to keep attackers away from a sensitive area of your website, such as a WordPress admin login (/wp-admin/), a staging folder, or any private tool. Even if someone knows your password, they cannot reach the login page unless they are connecting from an approved address.

This guide shows you how to lock a directory to your own IP address using an .htaccess file on Noiz hosting. It applies to any directory, not just WordPress. It is the mirror image of shutting out a single nuisance visitor: if that is what you need, see How to Block Any IP Address via an htaccess Rule instead.

Last reviewed: 27 July 2026, against Apache HTTP Server 2.4 (latest stable). This guide is written for Noiz hosting and is kept current against Apache. It complements, and does not replace, the official Apache documentation linked below.

Official Documentation Reference

• mod_authz_host: the Require ip and Require host directives.
• mod_authz_core: the <RequireAll>, <RequireAny> and Require all containers.
• .htaccess files: how per-directory configuration works.
• Upgrading to 2.4 from 2.2: why the older Order, Deny and Allow syntax is deprecated.
• WordPress: brute force attack hardening: where an IP restriction fits alongside the other defences.

Prerequisites

• Access to your website files, either through your control panel File Manager or over SFTP.
• The public IP address you connect from (covered in the first step). A fixed or static IP is strongly recommended, because a changing address will lock you out.
• A site served by Apache. On Nginx and some other servers .htaccess files are ignored entirely, so these rules have no effect there.

Decide Whether an IP Restriction Suits Your Connection

Most home and mobile internet connections hand out a dynamic IP address that changes when the router reboots, when the line reconnects, or simply overnight. An allow list built on a dynamic address will eventually lock you out of your own admin area, usually at the worst possible moment.

Use this method when you connect from a fixed business line, a static IP, or a VPN with a known exit address. If your address moves around, password protection on the directory is the safer control, and it is available as a built-in feature in every mainstream control panel. The two also combine well: allow your office range by IP, and keep a password prompt for everywhere else.

Find Your Public IP Address

Before you lock anything down, confirm the address you are currently connecting from. Open a search engine and search for what is my IP, or visit any IP-checking service. Note the value it returns, for example 203.0.113.5. The address your computer reports on your local network, typically one beginning 192.168. or 10., is not the address Apache sees, so do not use it.

If your internet connection uses IPv6, the service may show an address such as 2001:db8::a00:20ff:fea7:ccea. Use whichever address your browser actually connects with, because Apache matches on the exact protocol you arrive over. If in doubt, add both your IPv4 and IPv6 addresses. This catches out a lot of people: a rule listing only an IPv4 address will refuse you the moment your browser prefers the IPv6 route.

Create the .htaccess File

Create a file named .htaccess (note the leading dot, and no file extension) inside the directory you want to protect. For a WordPress admin area that is /wp-admin/.htaccess. The rule applies to that directory and everything beneath it. If a .htaccess file already exists in that directory, add the lines to it rather than overwriting it.

The leading dot makes the file hidden by default, so switch on Show hidden files (dotfiles) in File Manager if you cannot see it. Take a copy of any existing file before you edit it, because a single typo in .htaccess can take the directory, or the whole site, offline with a 500 Internal Server Error.

Restrict the Directory (Apache 2.4)

Add the following, replacing the example address with your own:

Require ip 203.0.113.5

That single line tells Apache to allow the directory only for that address and to return a 403 Forbidden to everyone else. No matching deny line is needed, because anything the Require rules do not match is refused automatically. The 203.0.113.5 value is an example from the documentation range only. Replace it with your real IP address.

Allowing Several Addresses or a Range

To permit more than one address, list them on the same line separated by spaces:

Require ip 203.0.113.5 198.51.100.10

Separate Require ip lines work equally well, and Apache treats a plain list of them as "any one of these may pass":

Require ip 203.0.113.5
Require ip 198.51.100.10
Require ip 2001:db8::a00:20ff:fea7:ccea

To permit a whole block, use CIDR notation. This is useful if your connection hands out an address that changes within a known range, or if you want to admit a whole office:

Require ip 203.0.113.0/24

That example covers every address from 203.0.113.0 to 203.0.113.255. A partial address such as Require ip 203.0.113 behaves the same way and matches everything beginning with those numbers. If you prefer to be explicit about the "any one of these" behaviour, or you are nesting rules inside a larger configuration, wrap the list in a <RequireAny> block, which behaves identically:

<RequireAny>
  Require ip 203.0.113.5
  Require ip 198.51.100.0/24
</RequireAny>

Keep admin-ajax.php Working (WordPress)

If you restrict /wp-admin/ on a WordPress site, be aware that many front-end features, such as contact forms, "load more" buttons, cart updates and some page builders, call /wp-admin/admin-ajax.php from your visitors' browsers rather than yours. Blocking that one file breaks those features for everyone, and it usually fails silently: the form simply never submits, with no error message to point you at the cause.

To keep it reachable while still protecting the rest of the admin area, add an exception below your Require ip line:

Require ip 203.0.113.5

<Files admin-ajax.php>
  Require all granted
</Files>

Do Not Forget wp-login.php

The WordPress login form itself is wp-login.php, and it sits in the site root, not inside /wp-admin/. Locking the admin directory therefore does nothing to slow the automated login attempts hitting that one file. To cover it as well, add the following to the .htaccess file in your document root, usually public_html:

<Files wp-login.php>
  Require ip 203.0.113.5
</Files>

Place this block outside and above the # BEGIN WordPress section of the root file. WordPress rewrites everything between its own # BEGIN and # END markers whenever you save permalink settings, so anything added inside them will eventually disappear.

Why Not "Order deny,allow"?

Older tutorials, and earlier versions of this guide, told you to use this:

Order deny,allow
Deny from all
Allow from 203.0.113.5

That syntax belongs to Apache 2.2, which reached end of life years ago. On Apache 2.4, which current Noiz hosting servers run, those directives are deprecated and only work through the legacy mod_access_compat module, which is not guaranteed to be loaded. Mixing the old Order, Deny and Allow style with the new Require style in the same file can also produce results you do not expect. There is one more trap worth knowing: Order takes its two arguments with no space after the comma (Order deny,allow), so a stray space, as in order deny, allow, is read as two separate arguments and returns a 500 Internal Server Error on every page in that directory. Use Require ip and you avoid the whole problem.

Test Your Restriction

Save the file, then confirm it works from an address that is not on your allow list. The easiest way is your mobile phone with Wi-Fi turned off, so it uses mobile data. You should receive a 403 Forbidden response. From your own approved connection, the directory should load normally.

A private or incognito browser window is not a valid test. It changes your cookies, not your IP address, so the rule will still let you straight in.

Troubleshooting

• You locked yourself out: your public IP has probably changed, as most home and mobile connections use dynamic addresses. Edit or rename the .htaccess file through your control panel File Manager or over SFTP, both of which bypass the browser rule, then update it with your new IP or a CIDR range.
• The rule has no effect and everyone still gets in: confirm the file is named exactly .htaccess, with the leading dot and no hidden .txt extension, and that it sits in the directory you intend to protect rather than the parent. Check too that the site really is served by Apache and that AllowOverride permits these directives for that directory.
• Everyone is blocked, including you: the address you allowed is probably not the one your connection presents. Re-check it, and add your IPv6 address alongside your IPv4 address if your connection has both.
• You see a 500 Internal Server Error: there is a syntax error in the file. Check for a stray space, a typo in Require ip, or an unclosed <Files> or <RequireAny> block.
• WordPress front-end features stopped working: add the admin-ajax.php exception shown above.
• Blocked visitors still get through, or everyone appears to share one address: your site may sit behind a content delivery network or reverse proxy, in which case Apache sees the proxy's address rather than the visitor's. When traffic is proxied, apply the restriction at the proxy or CDN level instead.
• The directory is locked but the attacks continue: automated login traffic that never reaches the directory still consumes resources. Treat the IP restriction as one layer, alongside strong passwords, two-factor authentication and a login rate limit, rather than as your only defence.

If you are on a Noiz managed plan and would like help locking down an admin area, or you have locked yourself out and cannot regain access, open a ticket from your Noiz client area and the support team will assist.