Reverse Proxy Security Calculator
Model WAF load on a reverse proxy: rule evaluations, CPU cores, TLS handshake utilisation, blocked traffic and false positives.
Inputs
Tuned blocking-mode WAFs run at 0.01–0.1%; anything higher is unusable in production.
False Positives per Hour
21,600
Blocked Requests per Second
480.0req/s
Block Precision
98.75%
Inspection CPU Cores Required
36
Rule Evaluations per Second
10,200,000
TLS Handshake Utilisation
30.0%
Step by step
Values used
Requests per second = 12,000 req/s; WAF rules evaluated per request = 850 rules; Inspection CPU time per request = 3 ms; TLS handshakes per second = 1,500 handshakes/s; TLS handshake capacity = 5,000 handshakes/s; Requests blocked by policy = 4 %; False positive rate = 0.0500 %
Reverse Proxy Security
false positives per hour = rps × false positive rate × 3600; cores = ceil(rps × CPU ms per request ÷ 1000).
False Positives per Hour
= 21,600
Blocked Requests per Second
= 480.0 req/s
Block Precision
= 98.75
Inspection CPU Cores Required
= 36
Rule Evaluations per Second
= 10,200,000
TLS Handshake Utilisation
= 30.0
How it works
A core delivers 1000 milliseconds of CPU per second, so the core count is simply request rate times per-request inspection cost divided by 1000. Precision is the share of blocked requests that were genuinely malicious — at a 4% block rate and a 0.05% false positive rate, precision is high, but the absolute false positive count per hour is what your support desk experiences. A WAF that looks accurate in percentage terms can still generate tens of thousands of blocked legitimate requests per hour at scale, which is why teams disable blocking mode and lose the control entirely.
Formula
Reverse Proxy Security
false positives per hour = rps × false positive rate × 3600; cores = ceil(rps × CPU ms per request ÷ 1000).
- CPU ms per request
- Milliseconds of CPU the rule set consumes per request
- precision
- Share of blocks that were genuinely malicious
Frequently Asked Questions
How is Reverse Proxy Security calculated?
false positives per hour = rps × false positive rate × 3600; cores = ceil(rps × CPU ms per request ÷ 1000). A core delivers 1000 milliseconds of CPU per second, so the core count is simply request rate times per-request inspection cost divided by 1000. Precision is the share of blocked requests that were genuinely malicious — at a 4% block rate and a 0.05% false positive rate, precision is high, but the absolute false positive count per hour is what your support desk experiences.
Why does Reverse Proxy Security matter?
A WAF that looks accurate in percentage terms can still generate tens of thousands of blocked legitimate requests per hour at scale, which is why teams disable blocking mode and lose the control entirely.
What values do I need to enter?
This calculator takes 7 inputs: Requests per second, WAF rules evaluated per request, Inspection CPU time per request, TLS handshakes per second, TLS handshake capacity, Requests blocked by policy, False positive rate. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why does a 0.05% false positive rate still hurt?
Because it is 0.05% of everything, not of attacks. At 12,000 requests per second that is 6 blocked legitimate requests every second — over 21,000 an hour. Percentages hide absolute volume, so always convert to per-hour counts before agreeing a threshold with the application owners.