Title: Rate-Limiting maximum? Last modified: May 29, 2026 --- # Rate-Limiting maximum? * Resolved [pdjp](https://wordpress.org/support/users/pdjp/) * (@pdjp) * [2 weeks, 3 days ago](https://wordpress.org/support/topic/rate-limiting-maximum/) * Is there a reason to have a maximum requests of 500 in the firewall setting? I have a problem on one website where people sometimes get blocked (with the standard 120 requests/min). I don’t know if 500 would be better, so i disabled rate limiting for this site. There is a plugin wich loads a bigger size of small images, so i think this could be the reason. Wordfence for example uses settings like 480/960/1920/unlimited, but Vigilant has 500 max. * Are these the same request you see in the developer settings of your browser? Many sites have hundreds of requests on load, so what would be a good overall setting? Viewing 3 replies - 1 through 3 (of 3 total) * Plugin Author [Fernando Tellado](https://wordpress.org/support/users/fernandot/) * (@fernandot) * [2 weeks, 3 days ago](https://wordpress.org/support/topic/rate-limiting-maximum/#post-18922835) * Hi again [@pdjp](https://wordpress.org/support/users/pdjp/) 🙂 * Very good question, again, and the Wordfence comparison is exactly the root of the confusion, so let me clear that up. * **The numbers aren’t comparable.** Vigilant’s rate limit counts only PHP requests that load WordPress (pages, `admin-ajax.php`, REST API, `wp-login.php`) from a single IP. It does **not** count the static assets you see in your browser’s Network tab (CSS, JS, fonts, images), because your web server delivers those without booting WordPress. A page that shows 80 requests in the browser usually counts as just 1–2 against the rate limit. Wordfence’s 480/960/1920 count differently( and segment humans vs crawlers vs 404s), so matching the raw number is misleading. Their “unlimited” is really “rate limiting off”. * **Why you’re getting blocked at 120/min:** that almost always means a plugin is loading content through PHP on the fly, via `admin-ajax.php` or the REST API. If your image plugin pipes each thumbnail through PHP instead of serving a direct URL, one page load can rack up dozens of PHP hits. That’s the first thing to check. * **About the 500 max:** it isn’t an arbitrary cap, it’s a deliberate ceiling. 500 PHP requests per minute from a single IP is a lot. Normal human traffic never reaches it; whatever does is usually a bot, which is exactly what the rate limit is meant to catch. * So instead of disabling rate limiting (which leaves you with no protection at all), I’d suggest: - See whether that image plugin can serve images as direct URLs / static files instead of through PHP. That fixes the cause. - If it can’t, raise the limit to **240–480** rather than turning it off. That still protects you while giving the plugin room. - If it’s only you or a known service hitting the cap, whitelist that IP in the firewall settings (logged-in admins are already exempt automatically). * Good overall values: 120/min is fine for most sites; WooCommerce / membership/ AJAX-heavy sites are comfortable at 240–480. * One thing your question made clear: the setting doesn’t explain any of this in the UI. I’ll add a short description to that field in the next release so it’s obvious what counts as a request. Thanks for the feedback 😉 * Thread Starter [pdjp](https://wordpress.org/support/users/pdjp/) * (@pdjp) * [2 weeks ago](https://wordpress.org/support/topic/rate-limiting-maximum/#post-18924696) * Thx for the explanation, only PHP requests makes sense. 🙂 * The suspicious function is not a normal WP plugin, it’s the Pano2VR player, which loads tons of images and additional product information from the normal WP posts via iframe. I don’t know how it works, but the complaining people were all using that function before it happened. * Plugin Author [Fernando Tellado](https://wordpress.org/support/users/fernandot/) * (@fernandot) * [2 weeks ago](https://wordpress.org/support/topic/rate-limiting-maximum/#post-18924952) * Thanks, that’s the missing piece, Pano2VR explains it perfectly. * Vigilant’s rate limit only counts requests that boot WordPress (PHP). Pano2VR creates two very different kinds of load: - The panorama tiles (the “tons of images”) are normally static `.jpg` files served straight from `/wp-content/uploads/`. Your web server delivers those without loading WordPress, so they **don’t** count toward the limit. - The iframes pulling product info from your WP posts are the real cause: each one is a full WordPress page load, so it **does** count. A tour with 30–50 hotspots opening iframes to posts can fire 30–50 PHP hits in a single viewing session, all from one visitor’s IP. That’s why only the people using the tour got blocked — they weren’t abusing anything, the tour just makes a lot of genuine WordPress requests per visit. * Because those visitors come from many different IPs, whitelisting won’t help here. The right move is to give the limit more room rather than switch it off( turning it off removes the protection completely): * **Try raising “Requests per Minute” to 300 (and to 480 if needed) then re-test the tour.** A real attacking bot still blows past those numbers, so you stay protected while letting a normal tour session through. * To find the right value, open the tour with your browser’s DevTools > Network tab and watch the requests. The `.jpg` files under `/uploads/` are static and don’t matter; the ones that load WordPress (posts, REST, admin-ajax) are what count. Tally how many a normal session makes and set your limit comfortably above that. * If raising the limit still isn’t enough, there’s a more surgical option, a small code snippet that exempts only the tour’s URLs while keeping the strict limit everywhere else. Try the higher limit first, and if it doesn’t do it, let me know and I’ll send it over. Viewing 3 replies - 1 through 3 (of 3 total) You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Frate-limiting-maximum%2F%3Foutput_format%3Dmd&locale=en_US) to reply to this topic. * ![](https://ps.w.org/vigilante/assets/icon-256x256.png?rev=3482619) * [Vigilant - 100% Free Security Suite: Firewall, 2FA, Login, Headers, Scanner…](https://wordpress.org/plugins/vigilante/) * [Frequently Asked Questions](https://wordpress.org/plugins/vigilante/#faq) * [Support Threads](https://wordpress.org/support/plugin/vigilante/) * [Active Topics](https://wordpress.org/support/plugin/vigilante/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/vigilante/unresolved/) * [Reviews](https://wordpress.org/support/plugin/vigilante/reviews/) * 3 replies * 2 participants * Last reply from: [Fernando Tellado](https://wordpress.org/support/users/fernandot/) * Last activity: [2 weeks ago](https://wordpress.org/support/topic/rate-limiting-maximum/#post-18924952) * Status: resolved