Troubleshooting the Noiz ModSecurity Custom Rules on Plesk

This guide helps you diagnose and fix problems with the Noiz custom ModSecurity rule set on a Plesk server: a legitimate visitor being blocked, a rule not firing when it should, or the deployed rules not matching what was intended. It assumes the rules are already deployed as described in the companion guide Plesk ModSecurity Custom Rules: the Noiz WAF Rule Set, which explains what each rule does.

Last reviewed: 1 August 2026, against the deployed Noiz rule set v8 on Plesk with Apache + ModSecurity 2. It complements the official ModSecurity documentation; the rule IDs and thresholds below are the Noiz-specific ones.

Prerequisites

• Root shell access to the Plesk server.
• The Noiz custom rule set deployed through Websites & Domains → the domain → Web Application Firewall → Settings → Custom directives, per the companion guide. Manual edits to the generated config file are overwritten on the next GUI save.

Understand what the visitor is actually seeing

Before changing anything, establish which response the visitor received, because the two codes mean different things:

• 403 Forbidden — a named rule refused the request. A user-agent block (a blocked crawler or scraper) or the cart-flood rule (1000210) produces this.
• 429 Too Many Requests — a rate limit fired. This is the flood rules holding a flood, or a legitimate visitor tripping a per-IP threshold.

Ask the visitor for the exact code, or reproduce the request yourself and read it from the response headers. The code, the URL, and whether the visitor carried a session cookie are the three facts that narrow the cause fastest.

Symptom: a legitimate shopper gets 429

Symptom: a real customer browsing a WooCommerce shop is rate-limited (429) on normal pages.

Check whether the request carried a session cookie. Rules 1000202 and 1000203 treat a facet endpoint with no cookie, or a cookie that is not a session cookie, as a bot:

• A shopper with cookies disabled, or a privacy tool that strips them, will be blocked by 1000202 (no cookie at all) or 1000203 (a cookie whose name does not look like a WooCommerce or WordPress session).
• Confirm by replaying the URL with and without the browser’s cookies, for example with curl -b to carry the cookie jar. If the request succeeds with the cookie and 429s without it, the cookie rules are the cause, not the rate limit.

The fix is not to loosen the rules for one visitor: cookies are how a real shop session works, and a cookieless facet request is exactly the flood signature. If a genuine customer cannot hold a cookie, that is a browser or privacy-tool setting on their side, not a WAF fault.

Symptom: a legitimate shopper gets 429 only under load

Symptom: a customer is rate-limited (429) only while clicking quickly through many filtered product pages.

Rule 1000200 allows 15 counted facet requests per IP per 60 seconds. A human clicking rapidly through facet filters can exceed it:

• Count the visitor’s requests in the window. The per-IP counter is stored on disk in /var/cache/modsecurity/ and is box-global, so the limit is a real per-IP limit and not diluted across Apache workers.
• If the count is genuinely a person and not a flood, the threshold may be too tight for that shop’s behaviour. Raise it with evidence from the audit log rather than by guess: count real browsing sessions, not the flood traffic, before moving the number.

Do not raise the threshold in response to a flood report. The 15-per-minute figure was calibrated from the 31 July incident, where human browsing sat far below it and the flood blew far past it.

Symptom: a crawler you want to allow is blocked

Symptom: a search engine or AI crawler receives 403, and you want it indexed.

• A 403 to a user-agent rule means the crawler is on a deny list by name. The T3 rules block GPTBot, ClaudeBot, GraphEmbedScraper and the SEO-tool crawlers by user agent. Verified search engines (T1) and rate-limited AI crawlers (T2) are on IP allowlists instead and are exempt from the flood rules.
• If the blocked crawler should be allowed, the correct change is to the user-agent rule or the allowlist, made in the Plesk GUI textarea, not a file edit. Re-verify the allowlist entries monthly with reverse-DNS plus forward-DNS; the procedure is in the companion guide.

Symptom: the rules do not seem to be deployed at all

Symptom: floods get through, or a test request that should be blocked is not.

Verify the deployed config actually contains the rules. The Plesk GUI regenerates /etc/apache2/plesk.conf.d/modsecurity.conf from the Custom directives textarea on every save, so a manual edit can have been silently overwritten:

apachectl configtest && systemctl reload apache2
grep -c "id:1000210" /etc/apache2/plesk.conf.d/modsecurity.conf   # must be 1
grep -c "wc-ajax" /etc/apache2/plesk.conf.d/modsecurity.conf      # must be 1

Each grep must return exactly 1. Zero means the block was never saved in the GUI; more than one means it was pasted twice, which causes duplicate rule-id errors at reload. After confirming the count, check the rate-limit counters are collecting:

ls /var/cache/modsecurity/

www-data-ip.dir collection files appearing with traffic confirm the per-IP counters are live. If the directory is empty while traffic flows, the initcol rules are not running, which points back to a deployment problem rather than a threshold problem.

If the files are present but a rate limit still fails to hold, check how fragmented they are before you touch the rule. These files grow without limit and never reclaim space, and a badly fragmented collection can undercount silently. See Why ModSecurity collection files grow without limit, and how to compact them.

Symptom: the audit log is full of rule matches but traffic is not being blocked

Symptom: /var/log/modsec_audit.log shows many entries for a rule, yet the flood continues.

A rule match is not a block. For example, rule 1000202 (no-cookie facet endpoint) writes an audit entry for every facet request it sees; only the transactions that also failed the second condition of the chain received a 429. Count the 429s in the access log, not the rule matches in the audit log, when measuring blocking. A large audit-log volume with few access-log 429s means the rule is matching but the chain is not completing, which is expected behaviour, not a fault.

If you cannot resolve it

Collect the response code, the full URL, whether a session cookie was sent, and the relevant lines from /var/log/modsec_audit.log and the access log, then contact Noiz support. Those four facts turn a vague “the firewall is blocking me” report into a quick diagnosis.