Introduction
Your site loads, but the logo is missing and a few images show up as broken boxes. You refresh, and everything appears. If that sounds familiar, you may be dealing with a mod_evasive false positive. This Apache module can mistake a normal page load for an attack and block the visitor for a few seconds.
This guide is for server administrators, hosting providers and web developers who run Apache servers. You will learn why it happens, how to confirm it in your logs, and how to fix it without leaving the server exposed. Once you know what to look for, the fix is usually quick.
What mod_evasive Does and How It Decides to Block a Visitor
mod_evasive is an Apache module built to slow down HTTP flood attacks and brute-force attempts. It keeps a table of client IP addresses and the URLs they request. When one address asks for too much, too quickly, the module answers with 403 Forbidden and blocks that address for a short time. The upstream documentation sets that block at 10 seconds by default.
The Checks and Default Limits
Every request is checked against the blocklist, then against two limits. The upstream README lists the defaults below. Your server may use different values, so check your own configuration. Each Apache child process keeps its own counters, so the same page load can be counted differently depending on which process serves it.
Figure 1. The checks mod_evasive runs on every request, with the default limits.
Setting | What it limits | Default |
DOSPageCount | Requests for the same URL per interval | 2 |
DOSSiteCount | Requests for any file from one IP per interval | 50 |
DOSPageInterval / DOSSiteInterval | Length of each counting window | 1 second |
DOSBlockingPeriod | How long a blocked IP stays blocked | 10 seconds |
What Causes a mod_evasive False Positive on Image-Heavy Pages?
A modern page is never one request. The browser fetches the HTML, then every stylesheet, script, font and image the page needs, in parallel. All of those requests come from one IP address, so mod_evasive counts them together. Only files served by your own server count, but a page with a visual page builder, a slider and a few dozen images can still send more than 50 of them in a single second.
Why the First Load Fails and a Refresh Works
On a first visit the browser cache is empty, so it asks for everything at once. If that burst crosses the site limit, mod_evasive blocks the visitor and every file requested afterwards is refused. Each blocked request also resets the timer, so the block lasts as long as the browser keeps asking. The logo, icons and images that arrive late are the ones that go missing.
On a refresh, the browser already holds the files that loaded. It only requests the missing ones, the count stays low, and the page finishes loading. That is why the problem looks random and disappears on the second try.
Figure 2. A cold load can cross the limit; a refresh usually does not.
Why HTTP/2 Makes It Easier to Trigger
HTTP/2 lets a browser request many files at once over a single connection. A connection is served by a single Apache child process, so the whole burst lands in the same counters. Browsers using HTTP/1.1 open several connections, which can spread the requests across more processes.
How Likely Is This on Your Server?
More likely than the module's design suggests. The README carries a 2005 date (version 1.10), long before HTTP/2 and page builders. In the 2025 Web Almanac from HTTP Archive, the median desktop page made 77 requests and the 90th percentile made 185. Not every request goes to one server, and not all arrive in the same second, but a heavy page can pass a limit of 50 without any attack involved.
Spotting a mod_evasive 403 Forbidden or 404 Error in Your Logs
Start in the browser. Open developer tools, go to the Network tab, tick Preserve log and Disable cache, then reload. Look for failed requests for files you know exist, and for repeated 403 or 404 errors in the Console. The upstream module returns 403, but a custom error page, a different build or a rewrite rule in front of the file can change the status the browser reports. Judge by the pattern instead: the file exists on disk and fails only during a burst of requests. Some genuine 404s for missing files may remain after a refresh. Those are a separate problem, so check them against the files on disk.
Then check the server. Confirm the module is loaded and search the system log:
httpd -M 2>/dev/null | grep -i evasive
grep -i evasive /var/log/messages | tail -50On Debian and Ubuntu, use apache2ctl -M and search /var/log/syslog instead. A block is logged as a line similar to Blacklisting address x.x.x.x: possible attack. Many admins check Apache's own error log first, and some builds write there, so search it too:
grep -i evasive /var/log/apache2/error.log | tail -50Compare the time of any entry with your Apache access log for the same IP. If the module is not loaded, or no such entry exists, look at other layers such as a firewall, ModSecurity or a CDN.
How to Disable mod_evasive or Tune It Safely
Option 1: Turn the Module Off
If a firewall, WAF, bot protection or CDN already handles rate limiting, mod_evasive adds little. The README itself notes that the module only goes so far on its own and recommends integrating it with firewalls and routers. Remove it the way it was installed (package manager or manual build), or comment out its LoadModule line. Then test the configuration and restart Apache:
apachectl configtest
apachectl restartOption 2: Keep It and Raise the Limits
Size the limits to your heaviest page. As a rule, set DOSSiteCount above the number of files that page loads from your own server in one second, and allow a few repeat requests for the same URL. These values are examples, not a recommendation for every server:
<IfModule mod_evasive20.c>
DOSPageCount 20
DOSSiteCount 300
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
# Single IP
DOSWhitelist 203.0.113.10
# Wildcard: whitelists the whole 203.0.113.0/24 range
DOSWhitelist 203.0.113.*
</IfModule>Match the IfModule name to your build, because packages differ. Use DOSWhitelist for your own monitoring tools, office networks and API clients; the upstream documentation advises against whitelisting customers. It takes a single IP or a wildcard in place of an octet, not CIDR notation. If a control panel generates your Apache configuration, add the directives in the panel's supported custom-include location so a rebuild does not overwrite them. Restart Apache afterwards: block tables live in memory, so a restart also clears any block still active.
If you look after many servers, keeping these settings consistent is easier with 24/7 server management and support services.
Confirm the Fix
Open the site in the browser that failed, with developer tools open and Disable cache ticked, and hard-reload several times. Every logo, image and icon should load, and the system log should show no new "Blacklisting address" lines. For a burst test from a test machine, use ApacheBench (ab, from the apache2-utils or httpd-tools package), which sends requests concurrently:
ab -n 100 -c 20 https://yourdomain.com/path/to/logo.pngThis sends 100 requests, 20 at a time. A loop of sequential curl calls is not a reliable test: each request finishes before the next starts, so it may never reach a per-second limit and can pass while the problem remains. Note that ab requests a single URL, so it mainly exercises DOSPageCount. If your limit is lower than -n, the Non-2xx responses line will show failures, so keep -n below it when testing a fix.
Frequently Asked Questions
How long does a mod_evasive block last?
Ten seconds by default, set by DOSBlockingPeriod. Every request made during a block resets the timer, so a browser that keeps asking for files can stay blocked longer.
Can it block search engine crawlers or monitoring tools?
Yes. It counts requests per IP address and cannot tell a crawler from a visitor. Add your own trusted tools to DOSWhitelist.
Is it safe to turn mod_evasive off?
It is when another layer already limits request rates, such as a firewall, WAF or CDN. Without one, keep the module and raise its limits instead.
Conclusion
A fast first load can cross a limit that was set for a much smaller web. The visitor is blocked for a few seconds, a refresh works around it, and the files were never missing. Confirm the cause with your browser's developer tools and the system log, then either switch the module off where other layers protect the server, or raise its limits to fit your heaviest page. Test with the cache disabled before you call it fixed.
Not sure which layer is blocking your visitors? The server management team at SupportSages can review your Apache modules, firewall rules and logs, and fix the cause with you. Talk to a server management expert.
