Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteUse Nginx to put an access gate in front of both /wp-admin/ and the exact /wp-login.php endpoint. An IP allowlist, HTTP Basic Authentication, or both can stop requests before WordPress or PHP handles them. Protecting only /wp-admin/ is incomplete because logged-out requests are redirected to wp-login.php.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The safest rollout is staged: identify the real client IPs Nginx receives, back up the active server block, add narrowly scoped rules, validate with nginx -t, reload, and test login, password recovery, AJAX, REST, XML-RPC, cron, mobile-app, and monitoring workflows.
As an Amazon Associate I earn from qualifying purchases.
What “hiding wp-admin” actually does
WordPress does not have a single switch that makes its administration area disappear. Nginx can, however, enforce access rules before a request reaches WordPress. That reduces opportunistic scanning and prevents unauthorized clients from receiving the normal login or administration responses.
The two paths have different jobs:
/wp-admin/serves the administration interface and many administrative handlers./wp-login.phphandles login, logout, password reset, and related authentication requests.
When a visitor is logged out and requests /wp-admin/, WordPress redirects the request to wp-login.php. Consequently, a rule on the directory alone leaves the login surface exposed. A complete Nginx policy covers the directory and the exact login script.
#1 Best Overall
This is access reduction, not invisibility. Anyone who discovers the login URL, obtains an allowed network address, or passes the additional credential layer can still reach WordPress. Continue to patch WordPress, plugins, themes, and Nginx; use strong passwords and two-factor authentication; and apply rate limiting or other controls for abusive login attempts.
Choose the gate that fits your administrators
| Control | How it works | Best fit | Main trade-off |
|---|---|---|---|
| IP allowlist | Nginx permits listed addresses and denies every other client. | Teams with stable office, VPN, or other known public egress addresses. | Administrators on changing residential or mobile addresses can lock themselves out. |
| HTTP Basic Authentication | Nginx requests a username and password before WordPress authentication. | Administrators who need to work from varying networks. | It adds another credential prompt and must be protected with HTTPS. |
| IP allowlist plus Basic Authentication | A request must satisfy the network rule and the extra credential prompt. | Small teams with known networks that want defense in depth. | Two independent controls must be maintained and tested. |
| Application-level URL change | A WordPress plugin changes or redirects the apparent login path. | Installations that cannot change the web-server configuration. | It is maintained by the plugin and does not replace authentication or rate limiting. |
IP allowlisting
An allowlist is simple and strong when every administrator exits through a predictable address. List each individual address or CIDR network, then finish with deny all;. Use your real public addresses, not the documentation-only ranges in the example below. If your team connects through a VPN, allow the VPN’s public egress address rather than each employee’s home address.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Keep the list as narrow as practical. A single fixed address is easier to audit than a broad range, while a VPN network can be useful when several administrators need access. Review the list whenever an office connection, VPN provider, or hosting arrangement changes. An outdated entry is not merely untidy; it can either block legitimate work or leave a wider network exposed than intended.
Basic Authentication
Basic Authentication creates a gate in front of WordPress’s own login. Nginx reads usernames and password hashes from a file such as /etc/nginx/.htpasswd. Use HTTPS so credentials are not exposed in transit, restrict permissions on the password file, and remove accounts when administrators leave.
This prompt is separate from WordPress credentials. A user who passes Basic Authentication must still authenticate to WordPress unless an existing WordPress session is valid. Keep the two passwords distinct, document who administers the password file, and test account removal so a former administrator cannot continue through the outer gate.
Combining both controls
Using an allowlist and Basic Authentication together limits the attack surface to known networks and still requires a separate credential. Nginx evaluates access directives in the order defined by its access module, so keep the rule order explicit and verify the behavior from both an allowed and a denied network.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Apply the same combination to both protected locations. If only the dashboard has both controls while wp-login.php has one, a visitor may receive a different challenge depending on the URL used. Consistent policy is easier to explain, monitor, and recover when an administrator changes networks.
Prepare before editing Nginx
- Back up the active server block. Save the configuration that actually serves the WordPress hostname, including any included files. Editing an unused template will have no effect.
- Determine the deployment layout. Single-site and multisite installations can use different Nginx patterns. In multisite, identify the network administration paths and the server block handling the site before applying a directory rule.
- Find the client address Nginx sees. A CDN or reverse proxy may connect to Nginx on behalf of the visitor. If Nginx sees only the proxy’s address, an allowlist for your office IP will deny you. Configure trusted proxy address handling according to your hosting design, and do not trust arbitrary forwarded headers.
- Inventory dependent services. Note plugins and external systems that use
admin-ajax.php, the REST API, XML-RPC, scheduled tasks, mobile apps, or uptime monitoring. These requests may not behave like an interactive browser login. - Have a recovery route. Keep console, out-of-band, or hosting-panel access available so you can restore the previous server block if a rule blocks every administrator.
Make the change during a period when someone can test immediately. Keep one existing administrator session open, but do not assume that session proves the new policy works: an already authenticated browser may not exercise the same redirect and challenge sequence as a new visitor. Use a fresh private window or a separate device for independent tests.
Implement an IP allowlist
Place the following locations inside the relevant server block. The example addresses are documentation placeholders and must be replaced.
location ^~ /wp-admin/ {
allow 203.0.113.10;
allow 198.51.100.0/24;
deny all;
}
location = /wp-login.php {
allow 203.0.113.10;
allow 198.51.100.0/24;
deny all;
}^~ /wp-admin/ applies the rule to the administration directory, while = /wp-login.php matches that file exactly. Keeping the login rule exact avoids unintentionally applying the policy to unrelated paths. The final deny all; is essential: without it, clients not listed by an allow directive are not blocked.
Recommended Free Tools
After replacing the sample networks, have one administrator keep an existing session open while another tests from an allowed address. Do not remove the old configuration until the new rule has been verified.
Remember that the documentation networks 203.0.113.0/24 and 198.51.100.0/24 are examples, not addresses you should copy into production. Record the real networks in your change notes so another operator can understand why each entry exists and who must approve its removal.
Add HTTP Basic Authentication
Create a password file with your system’s approved password-file utility, store it outside the public web root, and reference it from both protected locations. A representative configuration is:
location ^~ /wp-admin/ {
auth_basic "WordPress admin";
auth_basic_user_file /etc/nginx/.htpasswd;
}
location = /wp-login.php {
auth_basic "WordPress admin";
auth_basic_user_file /etc/nginx/.htpasswd;
}The browser should display a credential prompt before WordPress renders its login form. A failed or cancelled prompt must not fall through to an unprotected WordPress login. Use a unique password for this gate, rotate it when an administrator’s access changes, and keep the site on HTTPS.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchCheck that the Nginx worker can read the password file while ordinary web requests cannot download it. A syntactically valid path with incorrect permissions can cause the challenge to fail or produce an error after reload. Include the password file in your access-control and backup procedures, but do not place a plaintext copy in the public document root.
Use both controls for a layered gate
To require a known network and an additional credential, combine the directives in each location:
location ^~ /wp-admin/ {
allow 203.0.113.10;
allow 198.51.100.0/24;
deny all;
auth_basic "WordPress admin";
auth_basic_user_file /etc/nginx/.htpasswd;
}
location = /wp-login.php {
allow 203.0.113.10;
allow 198.51.100.0/24;
deny all;
auth_basic "WordPress admin";
auth_basic_user_file /etc/nginx/.htpasswd;
}Keep the same network and authentication policy on both locations. A mismatch can produce confusing behavior, such as a protected dashboard that redirects to an unprotected login form.
Test the intended sequence explicitly: a denied network should be rejected by the address rule; an allowed network should receive the Basic Auth challenge when enabled; and only after that challenge succeeds should WordPress display its own login flow. If the sequence differs between the two paths, inspect location selection and the active server block rather than weakening both rules.
Validate and reload without locking yourself out
- Check syntax and referenced files with
nginx -t. Do not reload if the test reports an error. - Reload Nginx using the normal service procedure for your host. A reload applies the new configuration without terminating existing worker processes.
- From an allowed administrator network, request
/wp-admin/and/wp-login.php. Confirm the expected Basic Auth prompt, if enabled, followed by the normal WordPress authentication flow. - From a denied external network, confirm that both paths are rejected before the WordPress login page is served.
- Test logout and password-reset links. Password recovery still depends on the login endpoint and on your mail configuration.
- Exercise every plugin feature that uses
wp-admin/admin-ajax.php, including front-end forms and logged-out actions where applicable. - Check REST requests, XML-RPC clients, mobile applications, scheduled jobs, and monitoring probes. Record any failures before tightening more paths.
Capture the result of each test, including the network used, the requested path, and whether the response came from Nginx or WordPress. This makes it easier to distinguish an access-rule problem from a plugin, mail, or application problem. Repeat the tests after a later Nginx, CDN, or WordPress change because location precedence and proxy behavior can change during deployment.
Why a blanket wp-admin block can break AJAX
Not every request under /wp-admin/ is an interactive administrator page. WordPress specifically warns that simply securing the directory can break functionality such as wp-admin/admin-ajax.php. Plugins may call that handler from the front end, and those calls can require different authentication or may be intentionally available to logged-out visitors.
When AJAX stops working after the change:
- Inspect the browser’s failed request and confirm whether the status is an Nginx denial or an application response.
- Check Nginx access and error logs for the exact URI and client address.
- Identify whether the request is expected to be public, logged-in only, or limited to a known service.
- Create only a narrowly scoped exception that matches the plugin’s documented behavior, or use an authentication design that preserves the endpoint. Do not broadly allow the entire administration directory just to restore one handler.
- Retest both authenticated and unauthenticated flows after every exception.
Because plugin behavior varies, there is no universal safe exemption for admin-ajax.php. Treat each exception as an explicit part of your threat model. A front-end form that works for logged-out visitors may need a different rule from a dashboard action, even though both use the same PHP handler.
Account for proxies and CDNs
Nginx’s allow and deny directives operate on the client address Nginx believes made the connection. With a reverse proxy or CDN, that may be the proxy rather than the visitor. An allowlist can therefore deny every real administrator, or—if proxy identity is trusted incorrectly—allow unintended traffic.
Free tools Windows power users keep installed
One-click scans. No signup required.
Document which proxy networks are trusted, configure address restoration only for those networks, and verify the result in logs. Test from an allowed office or VPN address and from a genuinely external connection after the proxy configuration is in place. Never solve an address problem by allowing every source.
Do not treat a forwarded client-IP header as authoritative merely because it is present. The proxy arrangement must establish which upstream addresses are trusted to set it. If that relationship changes, revisit the allowlist before the next administrator login attempt.
Single-site and multisite considerations
WordPress publishes separate Nginx patterns for single-site and multisite deployments because rewrite and administration paths can differ. Apply the access locations to the server block that handles the relevant site, then verify the network administration interface and each mapped domain. A rule copied from a single-site example may protect the wrong host or omit a multisite path.
On multisite, test a normal site administrator, a network administrator, and a user accessing a mapped domain. Keep the exact wp-login.php protection on every hostname that can authenticate users, not only on the primary network domain.
List every hostname before rollout. A mapped domain that reaches a different server block can bypass a policy that is correct on the primary domain. Confirm the policy separately on each hostname and test both a site-level dashboard and the network administration area.
Troubleshoot common failure modes
Everyone receives 403 Forbidden
- The allowlist contains private or outdated addresses instead of the public egress address.
- A proxy is hiding the administrator’s real address.
- The location is in a server block that does not serve the requested hostname.
- An address range was entered with the wrong CIDR notation.
Confirm the source address in Nginx logs, correct the trusted-proxy arrangement if necessary, and add the smallest verified address range.
The dashboard is blocked but the login page still appears
The rule covers /wp-admin/ but not the exact /wp-login.php location, or another server block handles the login request. Add and test the exact-file location in the active block.
Basic Authentication never appears
- The request is reaching a different server block or location than the one containing
auth_basic. - The password-file path is wrong or unreadable by the Nginx worker.
- A proxy or cached response is masking the test.
Run nginx -t, inspect the active configuration, check file permissions, and retest with a fresh private browser window.
AJAX or a plugin feature fails
Check whether the failing request targets admin-ajax.php. If so, review the plugin’s required authentication and create a minimal, documented exception rather than removing protection from all of /wp-admin/.
Password reset, mobile, or scheduled tasks stop working
These clients may not be able to answer an interactive Basic Auth challenge or may originate outside the allowlist. Verify each integration’s documented endpoint and source network before deciding whether it needs a narrowly scoped rule, a VPN route, or a different authentication arrangement.
A monitoring probe that only checks the homepage will not reveal a broken administrative workflow. Add checks that reflect the services you actually depend on, while ensuring that monitoring credentials and source addresses are handled as carefully as administrator credentials.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Do not rely on URL secrecy alone
Changing the apparent login URL with a plugin can reduce automated scanning noise, but it is not a substitute for authentication controls. WordPress’s security guidance makes the same distinction: obscuring the login URL should not be your only defense. Continue to use updates, strong unique passwords, two-factor authentication, and protections against repeated login attempts.
If you use a URL-changing plugin, document the new path, test upgrades and recovery procedures, and ensure Nginx rules still protect the actual endpoints used by the installation. A redirect or renamed path does not remove the need to understand how WordPress handles /wp-admin/ and wp-login.php.
Production rollout checklist
- Back up the active Nginx server block.
- Confirm whether a CDN or reverse proxy changes the source address.
- Choose an IP allowlist, Basic Authentication, or both.
- Replace documentation addresses with the administrators’ real public networks.
- Protect both
/wp-admin/and the exact/wp-login.phpendpoint. - Keep rule order explicit: allowed addresses first, then
deny all;. - Create and secure the Basic Auth password file if that control is enabled.
- Run
nginx -tand reload through the host’s normal service process. - Test allowed and denied requests, login, logout, password reset, and Basic Auth behavior.
- Test
admin-ajax.php, REST, XML-RPC, mobile apps, cron, and monitoring before expanding restrictions. - Keep WordPress core, plugins, themes, and Nginx updated, and retain layered authentication and abuse-rate controls.
Recommended decision
For a small team with a stable office or VPN address, start with an allowlist on both paths. Add Basic Authentication when administrators work from changing networks or when you want a second barrier. Whichever design you choose, stage it, verify the client IP Nginx sees, and test dependent WordPress endpoints—especially admin-ajax.php—before treating the configuration as finished.
Frequently Asked Questions
Can I protect only /wp-admin/?
You can, but it does not protect the complete login surface. Logged-out requests to /wp-admin/ are redirected to /wp-login.php, so add an exact location = /wp-login.php rule as well.
How do I block WordPress admin access by IP?
Inside the active Nginx server block, add allow entries for the administrators’ real public addresses or VPN egress network, followed by deny all;, in both the /wp-admin/ and /wp-login.php locations.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Can Basic Authentication be used with an IP allowlist?
Yes. Put auth_basic and auth_basic_user_file in the same two locations as the allowlist. The administrator must come from an allowed network and pass the additional credential prompt.
Why did restricting wp-admin break admin-ajax.php?
admin-ajax.php is inside the /wp-admin/ path, but plugins may call it from front-end pages or for logged-out actions. Inspect logs and plugin requirements, then create only a narrowly scoped, documented exception if necessary.
What if Nginx sees my CDN’s IP instead of mine?
Configure trusted proxy address handling for the CDN or reverse proxy networks and verify the resulting client address in logs. Do not trust arbitrary forwarded headers or solve the problem by allowing every source.
Will this work on WordPress multisite?
It can, but multisite and single-site installations may use different Nginx patterns. Apply the locations to the correct server block, test network and site administrators, and protect every hostname that can authenticate users.
Is changing the login URL enough security?
No. A renamed or redirected login path may reduce scanning noise, but it does not replace updates, strong unique passwords, two-factor authentication, and controls against repeated login attempts.
What should I test after reloading Nginx?
Test allowed and denied networks, both protected paths, Basic Auth if enabled, login, logout, password reset, plugin AJAX actions, REST, XML-RPC, mobile apps, scheduled jobs, and monitoring probes.
The Bottom Line
Protect both /wp-admin/ and /wp-login.php at Nginx, using a real IP allowlist, Basic Authentication, or both. Validate the configuration, account for proxies and multisite hosts, and test admin-ajax.php and every dependent integration before considering the rollout complete.
Quick Recap
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.
Recommended Free Tools
