HTTP Guard
Protect websites from excessive or suspicious web requests.
Where to find it: Sign in as root, open Server > Configuration, then choose HTTP Guard.
Available to: Root only.
What this page does
HTTP Guard protects a website only when it is enabled for that domain in Web Manager. This settings page lets the administrator choose shared protection options and decide which choices account users may change.
Before you start
HTTP Guard is not a network firewall and should not be enabled globally without an application baseline. Start with monitoring or a conservative profile where available, review matches, and test logins, APIs, uploads, carts, checkouts, and webhooks before enforcing broader rules.
Activation model
- Root makes HTTP Guard available and saves the global policy in Configuration.
- Root decides whether account-level overrides are allowed and defines profiles or smart-protection behavior.
- An authorized user opens the domain in Web Manager and enables HTTP Guard.
- The generated web configuration is applied for that domain.
- Logs and application tests confirm whether monitoring or enforcement behaves as intended.
Policy controls
| Control | Meaning |
|---|---|
| Allow overrides | Lets authorized account contexts choose supported domain-level policy rather than inheriting only the global value. |
| Monitor only | Records matching behavior without enforcing the same block decision; use it to establish a baseline. |
| Protected URI | Narrows protection to configured request paths where supported. |
| Smart protection | Off, monitor, or automatic behavior using the configured limited analysis policy. |
| Scan bounds | Limits inspection work so request protection remains predictable under load. |
| Profiles | Reusable combinations of supported HTTP Guard settings. |
Web stack behavior
In NGINX reverse-proxy or NGINX standalone deployments, the public edge applies the supported HTTP Guard policy. In Apache standalone mode, Apache applies the supported module behavior. Always verify the active stack in Services instead of copying configuration advice from a different topology.
When not to enable it yet
Leave enforcement off while the site is already failing, while no representative traffic baseline exists, or while an application depends on unusual request bodies that have not been tested. Fix the application baseline first; adding a guard to an unknown failure mostly gives the failure a second name.
How to use it
- Confirm the active web stack and module availability.
- Choose a conservative global policy and save it.
- Open the target domain in Web Manager and enable HTTP Guard.
- Exercise normal and suspicious request paths.
- Review matches, narrow any exception, and move from monitor to enforcement only when evidence supports it.
Smart protection and targeted URI rules
Root controls whether domains can override the policy, use protected-URI rules, and enable smart protection. The smart default can stay off until a domain is deliberately enabled. This feature configures web-request protection, not network firewall rules.
| Root control | Meaning |
|---|---|
| Scan interval and detection window | How often traffic is inspected and the period used for counting requests. |
| Requests, unique-IP, and single-IP triggers | Evidence thresholds used to identify an overloaded URL. |
| Rule TTL and rules per domain | How long an automatic rule remains active and how many rules can be kept. |
| Accounts/domains/candidates per tick and bytes per domain | Bounds the amount of inspection work. |
| Rotation tail bytes | Bounds log history inspected after rotation. |
| Auto action | The action/profile assigned to automatically selected URLs. |
| Default profile, reject status, logging, tracking memory | Shared enforcement and diagnostic defaults. |
| Apache RequestReadTimeout | Apache request-reading protection when that backend is used. |
For a domain, choose Full domain profile, Smart protection, or Targeted URI rules only in Web Manager. A URI rule can block every match, monitor only, or apply a rate profile. Test legitimate logins, uploads, APIs, and other busy paths after changing protection, and review the effective Nginx/Apache stack.
Result and next check
The selected domain's generated web configuration reports HTTP Guard enabled with the intended policy, legitimate application flows continue to work, and matching unwanted requests are monitored or blocked according to the chosen mode.
Theme color