Some users complained that while their websites were blocked by DDoS protection, legitimate users started experiencing numerous errors, such as CAPTCHAs not loading, payment pages failing to open, and frequent app timeouts. After a day's delay, they discovered that the protection strategy was mistaking their own users' traffic for attack traffic and blocking it.
This is a typical example of "false positives in DDoS protection." No matter how high the DDoS protection level, if the false positive rate is not well controlled, it's like creating problems for yourself. The industry standard is usually a false positive rate below 0.01%, but under many default configurations, this number can reach 0.5% or even higher. How do false positives occur, which parameters can be adjusted, and how should they be adjusted to make the protection both powerful and accurate?
First, let's understand: Why do DDoS protection devices sometimes falsely block traffic?
The essence of a DDoS protection device is a "traffic classifier." It needs to quickly determine which requests are attacks and which are legitimate user requests from a mixed stream of requests. The judgment is usually based on a combination of the following dimensions:
- Request rate (number of packets or connections per unit time)
- Protocol behavior characteristics (whether a three-way handshake is completed, whether a payload is carried)
- IP reputation database (historical attack records)
- Fingerprint matching (User-Agent, TLS handshake characteristics, etc.)
False blocking occurs when your normal business traffic happens to "look" like an attack. Typical scenarios with high false blocking rates include:
High-frequency heartbeat packets from mobile apps: Many apps send a heartbeat every few seconds, with a rate characteristic similar to SYN Flood, making them easily blocked under default thresholds.
Batch requests from API gateways: Legitimate business requests thousands of times per second during peak periods, triggering the "frequency limit" of CC protection.
Users using public proxies: IP ranges are blacklisted, and normal access is directly dropped.
Browsers with abnormal TLS fingerprints: Some older or customized browsers have handshake characteristics similar to scanners.
The Cost of False Blocks: More Severe Than You Imagine
Many operations and maintenance personnel underestimate the potential losses from a single false block.
E-commerce scenario: A user's order is blocked, resulting in a failed redirect → lost orders, with an average order value starting at 500 yuan.
Financial scenario: Transaction interface rate limiting → impacts real-time transactions, leading to compliance risks.
Gaming scenario: Player login is mistakenly banned → user churn, declining reputation.
A cross-border e-commerce test showed that after the false block rate decreased from 0.5% to 0.05%, monthly order volume rebounded by 12%. Therefore, adjusting parameters is not just icing on the cake, but a necessary measure to mitigate losses.
Core Parameter Adjustment: Shifting Protection from a "One-Size-Fits-All" Approach to "Refined"
Below, using mainstream hardware-based DDoS protection or cloud-based anti-dDoS platforms as a reference, we list the five most critical adjustable parameters. Specific names may vary by vendor, but the principles are universal.
Parameter 1: Connection Rate Threshold (Packets Per Second / PPS)
This is the first line of defense for L3/L4 layer protection. High-defense devices monitor the number of packets per second (PPS) or new connections per second (CPS) sent by each source IP. If the threshold is exceeded, it's considered an attack, triggering a challenge or simply dropping the connection.
Typical scenario for false positives: During peak game login times, a large number of players enter simultaneously, and a single egress IP (such as a campus network or company NAT egress) may generate over 2000 CPS, triggering protection.
Adjustment Suggestions:
Default Threshold: 500 CPS (configured by many vendors)
Suggested Adjustment:
For Mobile APIs: Relax to 2000-5000 CPS
For Websites: Maintain 1000-2000 CPS, using CAPTCHA challenges instead of directly discarding requests.
For Game Servers: Configure a separate whitelist policy, or increase the threshold to 10000 CPS.
Nginx Layer Example:
nginx
# In Nginx, use DDoS protection to allow crawlers
if ($http_user_agent ~* (baiduspider|googlebot|bingbot)) {
set $allow_bot 1;
}
if ($allow_bot = 1) {
# Bypass DDoS protection's RPS limit (requires DDoS protection to support custom header pass-through)
proxy_set_header X-Bypass-Limit 1;
}Parameter 3: TCP fingerprint verification strength (Challenge) (Level)
High-defense devices can distinguish between legitimate users and attack tools by sending TCP challenges (such as SYN cookies and retransmission verification). Higher strength results in better interception of IP spoofing attacks, but may also cause additional latency for legitimate users.
Typical scenario for false blocking: In weak mobile network environments (2G/3G/high-speed rail scenarios), frequent TCP retransmissions lead to a high challenge verification failure rate.
Adjustment suggestions:
Reduce the challenge strength from "Strict" to "Normal" or "Relaxed". Strict mode requires multiple retransmission verifications, which are prone to timeouts in weak network conditions.
Enable "Seamless Verification" mode: Only challenge suspicious IPs, allowing reputable IPs to pass directly.
Parameter 4: The granularity of IP blacklists/whitelists and regional blocking
Many administrators, for convenience, directly block entire overseas countries or IP ranges from certain cloud providers, but this can falsely affect a large number of legitimate users.
Recommended Adjustments:
Avoid directly blocking large blocks of IPs like "US" or "Europe." Instead, dynamically block specific attack source IPs with a 15-minute timeout.
For office scenarios (e.g., enterprises using a unified exit IP), add the exit IP to a whitelist to completely bypass protection checks.
Use a smart reputation database instead of a static blacklist. For example, if an IP fails to attack less than 3 times within 5 minutes, it should be automatically removed from the graylist.
Parameter 5: Protocol Validation
By default, the anti-dDoS protection checks the integrity of HTTP headers, such as whether the Host field is included and whether the User-Agent is valid. Requests from some custom clients or older SDKs may have missing fields and be judged as malformed packets.
Recommended Adjustments:
Disable the "Strict Protocol Check" option and switch to "Relaxed Mode."
If you have your own app, add its unique User-Agent or custom headers to the trust list.
Example: Allowing a specific User Agent (UA) in firewall rules:
Assuming the DDoS protection system uses iptables + string module at its core:
Allow requests containing "MyCustomApp" to bypass rate limits:
iptables -A INPUT -p tcp --dport 443 -m string --string "MyCustomApp" --algo bm -j ACCEPT
Note: Actual DDoS protection products are usually configured via the console; the above is only an illustration of the principle.
Practical Case: Optimizing the False Block Rate for a Cross-Border E-commerce Platform
Background: An independent website selling home goods has an average daily pageview (PV) of 200,000 and uses a cloud-based DDoS protection 500GB package. After deployment, the false block rate reached 0.3%, with approximately 600 real users blocked daily.
Investigation revealed the main sources of false blocks: mobile app (heartbeat packets every 5 seconds, multiple devices under a single IP → triggering CPS threshold); Russian and Brazilian buyers (heavy use of public Wi-Fi, low IP reputation); high-frequency API requests during promotional periods (RPS triggered).
The adjustment steps involved raising the CPS threshold from 800 to 3000, enabling CAPTCHA challenges instead of direct blocking; moving Russian/Brazilian IP ranges from the "blacklist" to the "medium-risk" group, enabling verification but not blocking; configuring RPS=100 for the `/api/stock` interface separately, while keeping other interfaces at 20; and adding Baidu/Google crawler IP ranges to the whitelist to bypass DDoS protection and directly access the origin server.
Result: The false positive rate decreased from 0.3% to 0.02%, while the cleaning capability remained unchanged (attack traffic was still effectively blocked).
Final step: Secure the false positive rate commitment with an SLA
Parameter optimization is a technical means, but the ultimate guarantee still lies in the contract. When purchasing DDoS protection, require the service provider to explicitly state "false positive rate ≤ 0.01%" in the SLA, and agree on the compensation method for exceeding the limit (e.g., a 5% reduction in the monthly service fee for every 0.01% false positive rate).
Furthermore, the right to test is reserved: you can periodically simulate normal user behavior (e.g., using curl to simulate real browser requests) to monitor for blocking. Once an anomaly is detected, require the service provider to provide log evidence proving that it was triggered by business behavior rather than a device bug.
Relax the rate thresholds for mobile devices, APIs, and game servers.
Add search engines and your own outbound IPs to the whitelist.
Enable seamless verification to prevent users with weak network connections from being mistakenly blocked.
Regularly review blocking logs and continuously optimize strategies.
False blocking in high-defense systems is not an "inevitable side effect," but rather a problem that can be significantly reduced through fine-tuning parameters. The core idea is simple: change protection from a "one-size-fits-all" approach to a "tailored approach."
