Not every part of a website is meant for public eyes. Admin panels, staging environments, internal dashboards — I lock these down to specific IP addresses or ranges as a matter of routine, and it’s one of the simplest security controls available in Apache. Here’s exactly how I set it up.
Why Restrict Access by IP
- Protects sensitive areas like admin panels, phpMyAdmin, or internal tools from public exposure
- Adds a layer of defense even before authentication — if you’re not on the allowed list, you never even see a login form
- Useful for staging/development environments you don’t want indexed or discovered by the public
- Simple to implement without needing additional software
Prerequisites
- Root or sudo access, or
.htaccessaccess withAllowOverrideenabled on shared hosting - Apache 2.4+ (this guide uses the modern
Requiresyntax) - Knowledge of the specific IP address(es) or CIDR range you want to allow
Step 1: Find the IP Address You Want to Allow
If you’re restricting access to yourself or your team, first confirm the public IP:
curl ifconfig.me
I always double-check this with each team member, since restricting access to the wrong IP locks everyone out, including you.
Step 2: Restrict Access to a Single IP Address
Using the Apache 2.4 Require syntax, here’s how I lock down a directory to one specific IP:
<Directory /var/www/example.com/admin>
Require ip 203.0.113.100
</Directory>
Anyone whose request doesn’t originate from 203.0.113.100 will receive a 403 Forbidden response.
Step 3: Allow Multiple IP Addresses
For a small team, I list each trusted IP:
<Directory /var/www/example.com/admin>
<RequireAny>
Require ip 203.0.113.100
Require ip 198.51.100.50
Require ip 192.0.2.25
</RequireAny>
</Directory>
RequireAny means access is granted if the request matches any one of the listed conditions.
Step 4: Allow an Entire IP Range (CIDR Notation)
If your team works from an office with a consistent IP range, I use CIDR notation instead of listing every possible IP:
<Directory /var/www/example.com/admin>
Require ip 203.0.113.0/24
</Directory>
This allows the entire 203.0.113.0–203.0.113.255 range.
Step 5: Combine IP Restriction With Authentication
For genuinely sensitive areas, I never rely on IP restriction alone — I stack it with HTTP authentication for defense in depth:
<Directory /var/www/example.com/admin>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
<RequireAll>
Require valid-user
Require ip 203.0.113.0/24
</RequireAll>
</Directory>
RequireAll here means both conditions must be true — the visitor needs to be on the allowed IP range AND provide valid credentials.
I generate the password file with:
sudo htpasswd -c /etc/apache2/.htpasswd adminuser
Step 6: Restrict Access for an Entire Virtual Host (Staging Environments)
For an entire staging site I don’t want publicly discoverable, I apply the restriction at the virtual host level:
<VirtualHost *:80>
ServerName staging.example.com
DocumentRoot /var/www/staging
<Directory /var/www/staging>
Require ip 203.0.113.0/24
</Directory>
</VirtualHost>
Step 7: Using .htaccess for IP Restriction
On shared hosting without access to the main config, the same rules work inside a .htaccess file placed in the target directory:
Require ip 203.0.113.100
Keep in mind this requires AllowOverride AuthConfig or AllowOverride All to be set for that directory in the main config.
Step 8: Test Your Configuration
After saving changes:
sudo apachectl configtest
sudo systemctl restart apache2
I always test from both an allowed IP (should work normally) and a non-allowed IP or VPN (should get a 403) before considering the job done.
Real-World Use Case
For a client’s staging environment that had accidentally been indexed by Google (a genuinely common and embarrassing issue), I restricted the entire virtual host to their office IP range and their remote team’s VPN exit IP. Combined with a noindex meta tag as a backup, this fully resolved the exposure issue within minutes.
Common Mistakes to Avoid
- Restricting access without accounting for remote/VPN workers, locking out legitimate team members who don’t work from a fixed office IP.
- Forgetting that home internet IPs are often dynamic, meaning a restriction that works today might block that same person tomorrow.
- Relying on IP restriction alone for highly sensitive data — always combine it with authentication for anything genuinely critical.
- Not testing the restriction from an actual disallowed IP, which is the only way to confirm it’s working correctly.
Troubleshooting Tips
If your restriction isn’t working as expected, check whether there’s a conflicting rule elsewhere — a broader <Directory> block, a .htaccess file, or a caching layer (like a CDN) sitting in front of Apache that’s serving cached content without ever reaching the origin server’s access check. If legitimate users get blocked unexpectedly, verify their actual outbound IP with a tool like whatismyip.com, since corporate networks sometimes route through IPs different from what you’d expect.
Security and Performance Best Practices
- Always combine IP restriction with authentication for genuinely sensitive resources — IP addresses can be spoofed or the restriction bypassed if a device changes networks.
- Keep a documented, up-to-date list of allowed IPs and the reason each one is there, since these lists tend to become stale and confusing over time.
- Consider a VPN for remote teams instead of maintaining an ever-growing list of individual home IPs.
- Review IP restrictions periodically — former employees’ IPs or old office locations often get forgotten in these lists.
Frequently Asked Questions
Can IP restriction be bypassed? Yes, technically — IP spoofing and compromised networks are possible, which is why I never rely on it as the sole layer of protection for genuinely sensitive data.
What happens if my IP address changes? You’ll be locked out until you update the configuration with your new IP. This is a common issue with residential ISPs that assign dynamic IPs, so I recommend a static IP or VPN for reliable long-term access.
Is IP restriction better than password protection? They serve different purposes and work best combined — IP restriction limits who can even attempt access, while authentication verifies who they are. Using both together is significantly stronger than either alone.
Can I restrict access by country instead of specific IPs? Yes, using mod_geoip2, though this requires installing and maintaining a GeoIP database and isn’t as precise as specific IP or range restriction.
Summary and Key Takeaways
Restricting access to specific IP addresses or ranges in Apache is a fast, effective way to lock down admin panels, staging environments, and internal tools. Use the modern Require ip syntax, combine it with authentication for sensitive areas, and always test from both allowed and disallowed IPs before considering the configuration complete.