Free tools Windows power users keep installed
One-click scans. No signup required.
The safest way to restrict wp-login.php is to enforce an allowlist before WordPress runs. On Apache, use a <Files> rule with Require ip; on Nginx, use an exact location = /wp-login.php block with allow and deny all. A WAF or CDN can apply the same policy at the edge. Use a plugin only when you cannot change the web server, and keep an out-of-band recovery route before enabling any restrictive rule.
Choose the layer that should enforce the restriction
| Option | Where it runs | Strength | Main limitation |
|---|---|---|---|
Apache Require ip |
Web server | Rejects requests before PHP and supports IPv4 and IPv6 entries | Requires Apache access and a configuration context that permits the rule |
Nginx allow/deny |
Web server | Rejects requests before PHP and is efficient under scanning | Requires Nginx configuration access and a reload |
| WAF or CDN rule | Edge or reverse proxy | Filters traffic before it reaches the origin | Requires correct client-IP handling and a vendor feature that supports path rules |
| WordPress plugin | PHP application layer | Possible on managed hosting without server access | Consumes application resources and may require Apache-specific features |
| Basic Authentication plus an IP rule | Web server or proxy | Adds a second credential barrier | Introduces another password and still requires HTTPS |
An allowlist is appropriate when administrators use fixed office, VPN, or hosting-console egress addresses. It is inconvenient for administrators on changing mobile, residential, or travel connections. In that case, a VPN with a stable egress address or an edge identity-control policy is usually easier to operate.
Before you enable an IP allowlist
- Record every administrator’s current public IPv4 and IPv6 address, plus each office or VPN egress address that must reach the login page.
- Identify whether a CDN, reverse proxy, load balancer, or hosting firewall sits in front of WordPress. Configure trusted-proxy handling so the rule evaluates the real client address. Never trust arbitrary forwarding headers from untrusted clients.
- Back up the server configuration or
.htaccessfile. Arrange SSH, a hosting-panel terminal, file-manager, FTP, or provider-console access that does not depend onwp-login.php. - Apply and test the change in staging first. Server and proxy syntax varies by environment.
Keep one tested recovery path outside the restricted login page. A typo, changed VPN address, or proxy misconfiguration can otherwise lock out every administrator.
Apache 2.4: restrict wp-login.php
Place this rule in a context where Apache permits authorization directives, commonly the virtual-host configuration or a supported .htaccess location:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →<Files "wp-login.php">
Require ip 203.0.113.15 203.0.113.16
</Files>Replace the documentation-only addresses with the public addresses that should be allowed. To make separate IPv4 and IPv6 entries explicit, use:
<Files "wp-login.php">
<RequireAny>
Require ip 192.0.2.123
Require ip 2001:0DB8:1111:2222:3333:4444:5555:6666
</RequireAny>
</Files>Use the syntax supported by the installed Apache version and by your hosting configuration. Validate the configuration before reloading Apache, then test an allowed and a disallowed address. A rejected request should receive an authorization error, while an allowed request should continue to the normal WordPress login flow.
Nginx: use an exact-match location
Add a dedicated exact-match location in the server block that handles the site:
location = /wp-login.php {
allow 203.0.113.15;
allow 203.0.113.16;
deny all;
# preserve the site's existing PHP-FPM or upstream directives
}The = exact match limits the policy to /wp-login.php instead of accidentally covering other paths. Preserve the existing fastcgi_pass, include files, headers, and other upstream directives required by your installation. Add IPv6 addresses when administrators use IPv6, validate the Nginx configuration, reload it, and test both GET and POST requests.
WAF or CDN: enforce the rule at the edge
If the origin is managed and you cannot edit Apache or Nginx, create a WAF or CDN access rule matching the path /wp-login.php and allow only the approved office or VPN egress addresses. Deny all other addresses, and decide explicitly whether the rule should cover both HTTP methods and IPv4/IPv6.
Verify how the provider identifies the client address. A reverse proxy can make the origin see only the proxy’s address unless trusted-proxy settings are correct. Conversely, trusting an unvalidated forwarding header can let a client spoof an allowed address. Test through the CDN, directly against the origin if that route is exposed, and from a deliberately disallowed network.
Plugin-based restriction when server access is unavailable
A plugin can implement an allowlist from the WordPress administration interface, but it runs in the application layer. The WordPress.org listing for Block wp-login states that blocked requests are rejected before WordPress loads, which can reduce PHP work from repeated probes. The listing also requires Apache mod_rewrite and a writable .htaccess file; it warns not to activate the plugin on Nginx or another server that does not process Apache .htaccess.
Confirm those prerequisites with your host before activation. Keep file-manager or FTP access available so you can disable or rename the plugin directory if its allowlist locks you out.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesSafe rollout and verification checklist
- From an approved network, open
https://example.com/wp-login.phpand confirm the login form loads. - Submit a login attempt and verify that the normal authentication and administrator redirect still work.
- From an unapproved network, test both a GET and a POST request and confirm the request is denied before the login form can be used.
- Repeat the tests over IPv4 and IPv6 wherever both are enabled.
- Check the site’s normal redirects, cookies, HTTPS behavior, and any CDN cache bypass for the login endpoint.
- Monitor 401/403 responses and authentication availability during deployment.
- Update the allowlist whenever an office ISP, VPN egress point, or administrator network changes.
Why IP restrictions lock administrators out
The public address changed
Residential, mobile, and some VPN connections change their egress address. Add the new address through the out-of-band recovery path, or route administration through a VPN with a stable egress.
The proxy address is being evaluated
With a CDN or load balancer, the origin may see the intermediary rather than the administrator. Correct trusted-proxy configuration is required before applying an origin allowlist.
IPv6 was omitted
A device may prefer IPv6 even when its IPv4 address is on the list. Add the actual IPv6 range or ensure administration uses the approved VPN path.
The rule was placed in the wrong context
Apache directives may be disallowed in .htaccess, or an Nginx location may replace required PHP-FPM directives. Restore the backup and validate the server configuration before trying again.
Another login component is failing
SSL, DNS proxying, caching, Nginx, Apache, and security-plugin settings can conflict with login access. Exclude wp-login.php and cookie-based sessions from page caching and inspect each layer separately.
Recovery after a lockout
- Plugin: use the hosting file manager or FTP to disable or rename the responsible plugin directory.
- Apache: revert the rule through SSH, the hosting control panel, or the provider console, then reload Apache.
- Nginx: restore the previous server block, validate the configuration, and reload Nginx.
- WAF/CDN: remove or pause the edge rule from the provider dashboard or API, then retest the origin path.
Do not depend on the restricted login page itself as your only recovery method.
Quick Recap
Security controls that should accompany IP restriction
- Use HTTPS consistently; IP filtering does not protect credentials sent over an insecure connection.
- Enable two-factor authentication for administrator accounts. WordPress core does not include 2FA, so use a suitable plugin or identity provider.
- Prefer edge or server-level login throttling. If that is unavailable, a security plugin can throttle attempts, although application-layer throttling still consumes PHP resources during heavy attacks.
- Review
xmlrpc.php. Disable it when unused, or restrict and rate-limit it when Jetpack, mobile apps, or another integration requires it. - Keep login pages and cookie-based sessions out of full-page caches.
- Consider Basic Authentication as an additional layer with an IP rule, never as a replacement for HTTPS or WordPress account security.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
