Understand DDoS protection behind a proxy

When a site is behind Cloudflare or another reverse proxy, network connections to the origin can come from the proxy instead of the visitor. cPFence v4+ IPDB connection counts and WAF request inspection therefore have different inputs.

Check CDN access

Check the actual origin-connecting address on the affected server. Select the image for full size; use browser Back to return.

You can use cPFence alongside Cloudflare, Quic.Cloud, BunnyCDN, Gcore, CacheFly or Fastly. A CDN’s caching and edge protection can complement protection at your origin.

Check the current allowlist

cPFence combines its supplied IP allowlists with your own entries. Check your CDN’s current origin addresses with IP status before changing policy. If an address is missing, verify it with the provider and whitelist the required range. Do not assume every provider range is already allowed.

Check visitor addresses

1. Confirm that the web server trusts visitor-IP headers only from your configured proxy network.
2. Check that access logs record the expected real visitor address.
3. Compare the network peer, logged visitor IP and WAF event for the same request.
4. Inspect the current proxy/whitelist policy before blaming a missing block on an inactive firewall.

Do not block your CDN accidentally

Blocking a shared proxy address can disconnect many legitimate visitors. Do not trust arbitrary client-supplied forwarded headers or remove trusted proxy exceptions without reviewing origin access.

Limits do not provide universal proxy protection

The default connection limit measures connections visible at the origin. Access-log checks can be delayed, and a WAF block does not prove that every body type or proxy path is inspected.

See WAF engine limits and IP status. Configure edge protection with your proxy provider for attacks that do not reach the origin as distinct visitor connections.