Skip to content

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:

  1. Set to Monitoring mode for at least 4 hours (longer if your network has long-lived connections).
  2. Review the Monitoring mode logs in Network Analytics to confirm legitimate traffic patterns.
  3. 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 reasonLikely causeAction
Not foundLearning period was incomplete, or long-lived connections pre-date ATP activationSet to Monitoring mode for 4+ hours, then switch to Mitigation (Enabled)
UnexpectedECMP rehashing — packets from the same flow arriving at different Cloudflare data centersSet to Monitoring mode; increase burst sensitivity threshold for affected colos; escalate if persistent
Out of sequencePacket reordering or packet loss in the network pathIncrease burst sensitivity threshold for the affected colo
Drops during traffic spikes onlyBurst sensitivity threshold too lowIncrease 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)

  1. Confirm the rule mode is Mitigation (Enabled), not Monitoring — Monitoring mode logs but does not drop.
  2. Check that rule sensitivities are set appropriately for the attack traffic volume. Lower sensitivity means more traffic must exceed the threshold before mitigation triggers.
  3. For distributed attacks spread across many source IPs and colos: adjust per-colo thresholds for the top-traffic colos.
  4. Confirm filters are not bypassing the mitigation — a filter that matches attack traffic will override the rule's execution mode.