Recommended Free Tools
To block an IP address in WordPress, use Wordfence for a quick plugin-level block, an Apache .htaccess rule for server-level control, or a Cloudflare firewall rule when your site is proxied through Cloudflare. Choose one enforcement point, confirm the address you intend to block, and keep a recovery path so you do not lock out legitimate visitors or yourself.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Which WordPress IP-blocking method should you use?
The right method depends on where you want the request rejected and what infrastructure your site uses. Wordfence is the least technical option. An Apache rule acts before WordPress loads and is useful for a small list or a range of addresses. Cloudflare can reject traffic at its edge, before it reaches your hosting server, but only when the domain is proxied through Cloudflare.
As an Amazon Associate I earn from qualifying purchases.
| Method | Where the block happens | Best use | Main risk or limitation |
|---|---|---|---|
| Wordfence Blocking | Inside the WordPress security plugin | One or a few abusive addresses; temporary blocks; sites already running Wordfence | WordPress and the plugin still receive the request, so it consumes some server resources |
.htaccess |
Apache web server, before WordPress | Server-wide blocks and CIDR ranges on Apache hosting | A syntax error can produce a 500 error; rules can match the wrong address behind a proxy |
| Cloudflare firewall | Cloudflare’s edge, before the origin server | Proxied sites receiving repeated unwanted traffic or broad attacks | It does nothing for DNS-only traffic, and dashboard labels can change |
Do not combine methods automatically. A single, correctly placed rule is easier to test and remove. Layering can make sense for a persistent attack, but document each block so a future administrator knows where to undo it.
Before you block an IP address
Confirm that the address is genuinely abusive
Look for repeated failed logins, aggressive crawling, comment spam, exploit attempts, or a volume of requests that is clearly inconsistent with normal use. A single suspicious request is not always enough: shared offices, schools, mobile carriers, and virtual private networks can put many unrelated people behind one public address.
#1 Best Overall
Use Wordfence’s live traffic log, your hosting access log, or Cloudflare’s request analytics to identify the address and the pattern associated with it. Check the timestamp, requested URL, response code, and user agent where available. Block the address only after you have ruled out a misconfigured plugin, a search crawler you need, or your own monitoring service.
Record your own access addresses
Write down the public IP address you use to administer the site, plus the address used by a trusted colleague or office. If your internet provider changes your address regularly, do not rely on a permanent allowlist entry as your only protection. Keep a second administrator account and an out-of-band way to reach the hosting file manager or control panel.
Decide whether you need a single address or a range
- Single address: use the exact IPv4 or IPv6 address when the abuse is isolated.
- Range: use a CIDR range only when you have evidence that multiple addresses in the same allocation are involved. A broad range can block legitimate users.
- Temporary block: prefer this when the source may be a compromised device, a short-lived bot, or an address shared by many people.
Back up before editing server configuration
For a server-level rule, download a copy of the existing .htaccess file before changing it. Save the file with its original name and keep the backup outside the public web directory. If the site becomes inaccessible, you can restore the original through the hosting file manager, FTP, or another server access method.
How to block an IP with Wordfence
Wordfence is usually the safest starting point when the site already has the plugin installed and you need to block a small number of addresses. The block is managed from WordPress rather than from the hosting server.
Block one address temporarily or permanently
- Sign in to the WordPress administrator dashboard.
- Open Wordfence > Firewall > Blocking.
- Find Manually Block IPs.
- Enter the complete IP address. Check every character before submitting; an extra digit can block a different address or fail to match.
- Choose Permanent or select a temporary duration, such as one hour or one day.
- Apply the block and confirm that it appears in the active-block list.
A temporary block is appropriate when you are testing a rule or dealing with an incident that may stop on its own. A permanent entry should be reserved for an address you have a continuing reason to deny, because public addresses can later be reassigned.
Block a range in Wordfence
- Remain on Wordfence > Firewall > Blocking.
- Open Block by IP Address Range.
- Enter the range in the notation the screen accepts, then review the first and last addresses represented by that range.
- Submit the rule and check the resulting entry in the list of blocks.
Range blocking is more powerful than blocking one address, but it also increases the chance of denying legitimate visitors. Start with the narrowest range that explains the observed traffic.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchFind the address from live traffic
When you do not know which address to block, open the Wordfence live traffic view and filter the recent requests. Use the request details to distinguish repeated malicious activity from a normal user who simply triggered an error. Copy the address directly from the log instead of retyping it.
Remove or change a Wordfence block
Return to the Blocking screen, locate the active entry, and use its remove or unblock control. If a temporary block was selected, it should disappear when its duration expires. After removing a rule, watch the live traffic log to confirm whether the underlying activity has stopped; deleting the block does not fix a compromised account or vulnerable endpoint.
How to block an IP with WordPress .htaccess
This method applies to sites served by Apache. The .htaccess file is commonly in the site’s public_html directory or the document root that contains wp-admin, wp-content, and wp-includes. If your server runs Nginx, an .htaccess file is not the place to configure access rules; ask the host for the equivalent server configuration instead.
Use Apache 2.4 syntax for a single IPv4 address
- Open the hosting file manager or connect with FTP/SFTP.
- Enable the option to show hidden files, because filenames beginning with a period may be hidden.
- Download a backup of
.htaccess. - Edit the existing file without deleting WordPress’s rewrite rules.
- Add the deny rule in the access-control section, replacing the example address with the one you verified.
Require not ip 203.0.113.42Apache 2.4 uses the Require syntax. The example address belongs to a documentation-only range; substitute the real address you intend to block. Keep the rule syntactically separate from WordPress’s RewriteEngine and RewriteRule lines.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Understand the older Deny from form
Older Apache configurations commonly use a Deny from directive. It may continue to work through Apache’s compatibility module, but it is legacy syntax rather than the preferred Apache 2.4 form. If your host supplies a generated access-control template, follow that environment’s documented syntax instead of mixing directive styles at random.
Block a CIDR range
CIDR notation expresses a network prefix and its size. A /32 IPv4 range contains one address. A /24 contains 256 IPv4 addresses, so a rule for a /24 can affect many unrelated visitors. Use the smallest prefix that covers the confirmed abusive allocation.
Require not ip 203.0.113.0/24Do not assume that adjacent addresses belong to the same attacker. Check the log pattern and the address allocation information available from your host or network operator before choosing a broad range.
Save and test the change
- Save the file and preserve its permissions and encoding.
- Open the site in a normal browser from an address that should remain allowed.
- Test the login page, a representative front-end page, and an administrator page.
- Review the server error log if any page returns a 500 status.
If the site immediately returns a 500 error or becomes unreachable, restore the backup first. A malformed directive, unsupported module, or misplaced rule can break the entire virtual host. Do not keep editing a broken file through the browser-based WordPress editor.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →How to block an IP with Cloudflare
Cloudflare can reject a request at its edge, so the origin server never handles the blocked request. This is useful when unwanted traffic is consuming bandwidth or connection capacity, not merely WordPress CPU time. The domain must be proxied through Cloudflare; a DNS-only record sends traffic directly to the origin and cannot apply an edge firewall block.
Create an IP firewall rule
Guides commonly describe this dashboard path: Firewall > Firewall Rules > Create a Firewall Rule. Cloudflare changes product names and navigation periodically, so confirm the current labels in your account before publishing a rule.
- Sign in to the Cloudflare dashboard and select the correct zone.
- Open the firewall or security rules area.
- Create a rule that matches the visitor IP address you confirmed in your logs.
- Set the action to block, review the scope, and give the rule a descriptive name such as the incident date and reason.
- Deploy the rule and monitor security events to verify that matching requests are being stopped.
Use a separate rule for each unrelated address when clarity matters. If several addresses are part of one confirmed network range, use the narrowest range that explains the attack. Avoid copying a range from an unverified list: an edge block affects every visitor whose request matches it.
Check whether Cloudflare is actually in the request path
The block is effective only for hostnames whose DNS records are proxied. If visitors can reach the origin through an unproxied hostname or a disclosed origin address, they may bypass the edge rule. Protecting the origin requires separate network or server controls, and those controls must account for the proxy arrangement.
The Cloudflare and .htaccess trap
When a site is behind Cloudflare, the origin web server can see Cloudflare’s connecting addresses rather than the visitor’s original address. A server-level rule that was written for the visitor’s IP can therefore match the wrong value. In the worst case, it can block Cloudflare itself, stop Wordfence from receiving useful visitor information, or deny your own requests.
Do not paste Cloudflare’s published network ranges into .htaccess as a substitute for restoring the visitor address. A WordPress.org support discussion describes a case in which allowlisting a home address and Cloudflare ranges in .htaccess was followed by a Wordfence interface that stopped updating. Treat that symptom as a sign to review the proxy and real-client-IP configuration rather than adding more addresses blindly.
- For a proxied site, prefer the Cloudflare edge rule for visitor-IP blocking.
- Use
.htaccessfor rules based on information the origin can reliably see, and verify the logged address first. - If Wordfence logs show proxy addresses instead of visitors, pause the block and have the hosting or proxy administrator correct the trusted-proxy configuration.
Verify that the block works without locking yourself out
Check the expected result
- The blocked address should receive the action selected by the enforcement layer: a Wordfence block response, an Apache denial, or a Cloudflare block page.
- An allowed address should still load the home page, login page, and a normal content URL.
- The relevant log should show the request and the rule that handled it.
Use a controlled test
Do not test a permanent rule while connected through the only administrator connection you have. Schedule the change, keep the hosting file manager open in a separate session, and use a second trusted connection for verification. If your public IP changes during testing, update your notes before interpreting the result.
Remove the rule if legitimate traffic is affected
For Wordfence, remove the entry from the Blocking screen. For Cloudflare, disable or delete the matching firewall rule. For Apache, restore the backed-up file or remove only the new directive, then retest. Record what was changed and why so the same address is not accidentally reblocked by another layer.
Free tools Windows power users keep installed
One-click scans. No signup required.
Troubleshooting common failures
The block does nothing
- Confirm that the address in the rule is the address recorded at the same enforcement layer.
- Check whether the visitor is rotating addresses through a mobile connection, proxy, or botnet.
- Verify that Cloudflare is proxied for the hostname receiving the traffic.
- Look for another hostname, direct origin address, or API endpoint that bypasses the rule.
The site returns “500 Internal Server Error” after an .htaccess edit
Restore the backup immediately through the hosting file manager or FTP/SFTP. Then inspect the server error log and confirm whether the host supports Apache 2.4 Require directives and the module needed for legacy syntax. Reapply one rule at a time only after the site is stable.
Legitimate visitors are blocked
Remove the broad range and replace it with the specific address or a shorter-lived block. Shared networks make permanent IP denial especially risky. If the traffic is an authentication attack, protect the login endpoint rather than denying an entire organization or country based on one address.
Wordfence traffic information suddenly looks wrong
Review recent proxy, DNS, and .htaccess changes. A server that records Cloudflare addresses instead of client addresses cannot reliably support visitor-IP rules at the origin. Temporarily disable the suspect rule, restore the last known-good configuration, and involve the host or proxy administrator before creating another allowlist.
Why IP blocking is not a complete security strategy
An IP address identifies a network endpoint at a moment in time, not a person. Attackers can rotate addresses, use residential proxies, compromise new devices, or move to a different network. A block can reduce noise from a known source, but it does not repair a vulnerable plugin, stolen password, exposed XML-RPC endpoint, or weak login policy.
Pair an IP block with controls appropriate to the behavior you observed:
- Use login-rate limiting and multi-factor authentication for administrator and editorial accounts.
- Keep WordPress core, themes, and plugins updated and remove software you no longer use.
- Use strong, unique passwords and review administrator accounts for unexpected changes.
- Rate-limit comment, registration, search, and API endpoints that attract automated abuse.
- Monitor logs after the block to determine whether the same behavior moves to new addresses.
- Maintain tested backups so a bad rule or a compromise does not become a permanent outage.
Use the narrowest, shortest-lived block that solves the immediate problem, then address the control that allowed the abuse to reach the site.
A practical decision checklist
| Your situation | Recommended first action | What to verify |
|---|---|---|
| One known address is repeatedly probing a WordPress site | Wordfence temporary or permanent block | The live traffic entry and the resulting block record |
| Several addresses in a confirmed network are attacking an Apache origin | A narrow Apache CIDR rule after backing up .htaccess |
Apache version, syntax support, and a clean response from an allowed connection |
| Traffic is overwhelming a site already proxied through Cloudflare | Cloudflare firewall rule at the edge | That the hostname is proxied and security events show the rule firing |
| The site is behind Cloudflare and origin logs show proxy addresses | Do not add visitor-IP rules to .htaccess yet; correct address handling first |
That logs and Wordfence identify the real client address consistently |
| Abuse continues from changing addresses | Keep a narrow temporary block, then add rate limits, login protections, and updates | Whether the behavior stops rather than merely moving to another IP |
Final recommendation
Start with Wordfence when you need a reversible block and already use the plugin. Choose .htaccess when Apache must reject a verified address or range before WordPress runs, and always keep a backup. Choose Cloudflare when the site is proxied and the traffic should be stopped at the edge. The most important operational rule is to match the blocking layer to the address it can actually see; behind a proxy, a technically correct-looking IP rule can otherwise block the wrong system.
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.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
