← Cloudflare DDoS Protection / ddos-protection / advanced-ddos-systems
Troubleshooting Advanced TCP Protection
Mode transition behavior
Advanced TCP Protection rules have three execution modes: Disabled, Monitoring (logs only, no drops), and Mitigation (Enabled) (active mitigation).
Always transition from Monitoring mode to Mitigation (Enabled) mode. Do not switch directly from Disabled to Mitigation (Enabled).
When you switch directly from Disabled to Mitigation (Enabled), Advanced TCP Protection begins a learning period to observe existing connection state. Long-lived connections that pre-date this learning period may be dropped because they have no state in the tracker.
Recommended procedure:
- Set to Monitoring mode for at least 4 hours (longer if your network has long-lived connections).
- Review the Monitoring mode logs in Network Analytics to confirm legitimate traffic patterns.
- Switch to Mitigation (Enabled) mode.
Legitimate traffic is being dropped (false positives)
Check the Mitigation reason field in the Advanced TCP Protection tab of Network Analytics and use the reason to identify the cause:
| Mitigation reason | Likely cause | Action |
|---|---|---|
| Not found | Learning period was incomplete, or long-lived connections pre-date ATP activation | Set to Monitoring mode for 4+ hours, then switch to Mitigation (Enabled) |
| Unexpected | ECMP rehashing — packets from the same flow arriving at different Cloudflare data centers | Set to Monitoring mode; increase burst sensitivity threshold for affected colos; escalate if persistent |
| Out of sequence | Packet reordering or packet loss in the network path | Increase burst sensitivity threshold for the affected colo |
| Drops during traffic spikes only | Burst sensitivity threshold too low | Increase burst sensitivity (keep rate sensitivity the same) |
Threshold tuning: Adjust burst sensitivity before rate sensitivity. Burst sensitivity handles momentary spikes; rate sensitivity controls sustained packet rates.
Traffic from known sources is being challenged
The ATP allowlist allows you to bypass mitigation for specific source IP prefixes. However:
- The allowlist supports approximately 200 IP addresses per allowlist expression. For more information, refer to Add an IP or prefix to the allowlist.
- The allowlist is not a security control — it is bypass-by-IP-address, which is vulnerable to IP address spoofing. Do not add large IP ranges (for example, entire data center IP blocks) to the allowlist.
- For large-scale legitimate traffic sources, prefer adjusting rule sensitivities rather than adding broad allowlist entries.
Known limitations
- TCP only: Advanced TCP Protection covers TCP traffic. UDP and ICMP flood attacks are handled by HTTP DDoS Attack Protection managed rulesets or Cloudflare Network Firewall rules.
- ECMP "shifty flows": When packets from the same TCP flow arrive at different Cloudflare data centers (due to ECMP load balancing upstream), ATP loses connection state and may drop packets with the Unexpected mitigation reason. This is a known architecture constraint. Mitigation: reduce burst sensitivity or adjust per-colo thresholds for affected colos.
Attacks not being blocked (false negatives)
- Confirm the rule mode is Mitigation (Enabled), not Monitoring — Monitoring mode logs but does not drop.
- Check that rule sensitivities are set appropriately for the attack traffic volume. Lower sensitivity means more traffic must exceed the threshold before mitigation triggers.
- For distributed attacks spread across many source IPs and colos: adjust per-colo thresholds for the top-traffic colos.
- Confirm filters are not bypassing the mitigation — a filter that matches attack traffic will override the rule's execution mode.