Block Specific IP Addresses Across WordPress
There are situations where blocking an address only from the WordPress login form is not enough. You may want a known abusive source to stop reaching the frontend, API endpoints, wp-admin, AJAX handlers, and XML-RPC altogether.
Blacklist mode is designed for that situation.
Add an individual IPv4 or IPv6 address, or specify an entire CIDR range, and requests originating from a matching address are denied with an HTTP 403 response. Everyone outside the list continues accessing WordPress normally.
For example, you could block one address:
<203.0.113.25><192.168.1.0/24>Because the restriction is site-wide, it is considerably broader than Limit Login Attempts, which temporarily restricts authentication after repeated failures. IP Allow & Block List is appropriate when you already know that a particular address or network should not be allowed to access WordPress at all.
Create a Private WordPress Site With Whitelist Mode
Blacklist mode answers the question "Who should be denied?" Whitelist mode reverses that model and asks "Who should be allowed?"
When Whitelist mode is active, only IP addresses and networks appearing on your list can access the protected WordPress installation. Requests from everyone else are denied.
This can be useful for internal company sites, private administration environments, staging installations, development websites, restricted client portals, or other WordPress projects that should only be reachable from known networks.
The restriction applies to the frontend as well as administrative and API areas. Being logged into WordPress does not automatically override it, and administrators are not silently exempt. If an administrator's IP does not match the whitelist, that administrator is blocked just like any other visitor.
That makes Whitelist mode a powerful control, but it also means it should be used carefully on networks where public IP addresses change frequently.
Protect More Than the WordPress Login Page
IP Allow & Block List is designed as a site-wide WordPress access control, not merely a login restriction.
Rules apply to normal frontend requests as well as wp-login.php and wp-admin. They also extend to WordPress AJAX, REST API requests, and XML-RPC so a blocked address cannot simply move from the visible website to another WordPress interface.
The response is appropriate to the type of request. Normal HTML visitors receive the configured blocked page with an HTTP 403 status, while REST requests receive a structured 403 error and AJAX requests receive a JSON error. Administrative and XML-RPC access is denied as well.
This makes the module useful when your policy concerns the source IP itself rather than one particular WordPress feature.
If you only want to control an individual interface, more focused WP PowerSuite modules may be preferable. Disable REST API, for example, controls WordPress REST access, while Disable XML-RPC specifically closes XML-RPC when that functionality is not required.
Use Individual IP Addresses or CIDR Networks
Manually listing every address becomes impractical when an entire trusted or unwanted network needs the same rule.
IP Allow & Block List therefore supports CIDR notation for both IPv4 and IPv6.
A blacklist can block a network range instead of maintaining dozens of individual entries. A whitelist can similarly allow a known office, VPN, infrastructure, or other controlled network using an appropriate CIDR rule.
IPv4 masks from /1 through /32 and IPv6 masks from /1 through /128 are supported.
Entries are validated when settings are saved, and invalid addresses or malformed ranges are discarded rather than becoming ambiguous firewall rules.
Because a CIDR entry can cover a large number of addresses, ranges should be chosen carefully—especially in Whitelist mode. An overly broad rule can provide access to far more systems than intended.
Detect the Real Visitor IP Behind Cloudflare and Proxies
IP restrictions are only useful when WordPress is evaluating the correct client address.
On a direct connection, that will usually come from the server's remote address. Websites behind Cloudflare, reverse proxies, load balancers, or other network infrastructure can be more complicated because WordPress may otherwise see the proxy address rather than the original visitor.
WP PowerSuite uses shared client-IP detection that can recognize Cloudflare's CF-Connecting-IP and explicitly configured real-IP headers when the request comes through a trusted proxy.
It deliberately avoids blindly trusting common spoofable headers such as X-Forwarded-For, Forwarded, or Client-IP. Accepting arbitrary forwarding headers from any request would allow a visitor to potentially claim a different source address and undermine IP-based restrictions.
The settings interface shows the detected client IP and its source, and Add My IP to List uses the same resolver as actual enforcement. This makes it easier to verify which address WP PowerSuite will use before creating access rules.
Customize the Access Denied Page
Blocked visitors using ordinary HTML requests do not need to see a generic WordPress error screen.
The built-in blocked page can display a custom title, headline, message, and logo, along with configurable background and text colors. This allows businesses and agencies to provide a more intentional response explaining that access to the website is restricted.
For more customized layouts, you can select an HTML file from the WordPress Media Library. WP PowerSuite sanitizes that HTML before output and wraps it in a minimal page document.
This is deliberately not an unrestricted arbitrary-code template. Scripts, styles, event handlers, and document wrappers are removed during sanitization, reducing the risk of turning an access-denied page into another place for executable code.
API and administrative requests continue receiving appropriate structured or standard 403 responses rather than the frontend design.
