--- title: "How to Restrict Access to Directories by IP Address" description: "Lock a directory such as wp-admin to trusted IP addresses with an Apache Require ip rule in .htaccess, covering ranges, IPv6 and the admin-ajax.php exception." url: "https://docs.noiz.ie/security/how-to-restrict-access-to-directories-by-ip-address/" section: "Security" categories: - "Security > Best Practices" last_reviewed: "27 July 2026, against the current Apache HTTP Server release" --- # 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](/security/how-to-block-an-ip-address-using-an-htaccess-rule/) instead. **Last reviewed:** 27 July 2026, against the current Apache HTTP Server release. 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](https://httpd.apache.org/docs/2.4/mod/mod_authz_host.html): the `Require ip` and `Require host` directives. - [mod\_authz\_core](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html): the ``, `` and `Require all` containers. - [.htaccess files](https://httpd.apache.org/docs/2.4/howto/htaccess.html): how per-directory configuration works. - [Upgrading to 2.4 from 2.2](https://httpd.apache.org/docs/2.4/upgrading.html): why the older `Order`, `Deny` and `Allow` syntax is deprecated. - [WordPress: brute force attack hardening](https://developer.wordpress.org/advanced-administration/security/brute-force/): 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: ```apacheconf 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: ```apacheconf 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": ```apacheconf 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: ```apacheconf 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 `` block, which behaves identically: ```apacheconf Require ip 203.0.113.5 Require ip 198.51.100.0/24 ``` ## 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: ```apacheconf Require ip 203.0.113.5 Require all granted ``` ## 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`: ```apacheconf Require ip 203.0.113.5 ``` 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: ```apacheconf 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 `` or `` 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](https://www.noiz.co.za) and the support team will assist. --- Source: https://docs.noiz.ie/security/how-to-restrict-access-to-directories-by-ip-address/