Bunny CDN 504 Gateway Timeout while your server is fine? Check CrowdSec

Your site runs behind Bunny CDN, and every now and then it goes down. Visitors get Bunny’s “504 Gateway Timeout” page, saying “We could not establish a connection”. You log in to your server and everything looks fine: the load is normal, the logs show no errors, and the other sites on the same server keep working. A reboot doesn’t help. After a few hours the site comes back by itself, only to go down again a few days later.

We ran into exactly this. The cause wasn’t the site, the database or the server load. It was the server’s own security software blocking Bunny. If you run CrowdSec, or a similar tool that bans IP addresses based on their behaviour, on a server behind a CDN, this can happen to you too. Here’s how to recognise it, confirm it and fix it for good.

The symptoms

• Visitors get Bunny’s 504 page, usually after waiting about a minute.
• The server isn’t busy: CPU, memory and database look normal.
• Your web server and application logs show nothing unusual, because the failing requests never arrive.
• Other sites on the same server that don’t use Bunny keep working.
• Restarting services or rebooting the server doesn’t help.
• API calls to the Bunny hostname fail, while the same calls to a hostname that reaches the server directly, or through another CDN, keep working.
• The site can be down for some visitors and fine for others, depending on which Bunny location serves them.

Why it happens

Behind a CDN, your server never sees your visitors. It only sees the CDN. Every request arrives from one of a handful of Bunny edge servers near the visitor, so to your server, each edge server looks like a single, extremely busy client.

CrowdSec reads your logs and bans IP addresses that behave suspiciously, such as crawling many pages quickly or probing for paths that don’t exist. Every bot, scraper and vulnerability scanner that reaches your site through Bunny is counted against the IP address of the edge server it came through. Sooner or later one of CrowdSec’s scenarios triggers, the edge server gets banned, and the firewall drops all of its traffic.

From that moment, every visitor routed through that edge server gets a 504, while your server is perfectly healthy. Bans last hours (four by default) and survive a reboot, which explains why the problem comes and goes, and why restarting fixes nothing. Bunny’s IP addresses can also end up on CrowdSec’s community blocklist, because other CrowdSec users behind Bunny see the same pattern.

How to diagnose it

Step 1: compare Bunny with your server

Request the same URL through Bunny and directly from your server. curl’s --resolve option skips DNS and connects straight to your server’s IP address, while still sending the right hostname:

# Through Bunny
curl -s -o /dev/null -D - -w "status=%{http_code} time=%{time_total}s\n" "https://example.com/robots.txt?nocache=$RANDOM" | grep -iE "^(cdn-cache|status=)"

# Directly to your server (replace 203.0.113.10 with your server's IP address)
curl -s -o /dev/null -w "status=%{http_code} time=%{time_total}s\n" --resolve example.com:443:203.0.113.10 "https://example.com/robots.txt"

Use a static file such as robots.txt, so PHP and the database play no part. Check the cdn-cache line in the first result: if it says HIT, Bunny answered from its cache and the test tells you nothing. Depending on your pull zone settings, Bunny may ignore the query string, so try other URLs, such as a page or API endpoint Bunny doesn’t cache, until you get a MISS.

If your server answers in a fraction of a second while Bunny returns a 504 after a minute, the problem isn’t your application. Bunny can’t reach your server at all.

Step 2: check whether CrowdSec has banned Bunny

Bunny publishes the IP addresses of all its edge servers. Download the list on your server and compare it with CrowdSec’s active bans, which CrowdSec calls decisions:

curl -s https://bunnycdn.com/api/system/edgeserverlist/plain | tr -d '\r' > /tmp/bunny-ips.txt
sudo cscli decisions list --all --limit 0 -o raw | grep -wFf /tmp/bunny-ips.txt

A few notes on these commands:

• tr -d '\r' is needed because Bunny’s list uses Windows line endings. Without it, nothing matches.
• --all includes bans from the community blocklist, and --limit 0 removes the default limit of 100 results.
• grep -w prevents partial matches, so 1.2.3.4 doesn’t match 1.2.3.45.

Any output means CrowdSec is blocking Bunny. To see which scenario caused the bans, run sudo cscli alerts list.

The fix

Lift the current bans

sudo cscli decisions list --all --limit 0 -o raw | grep -woFf /tmp/bunny-ips.txt | sort -u | xargs -r -n1 sudo cscli decisions delete --ip

This deletes every active ban on a Bunny edge server. Your site should be reachable through Bunny again right away. Repeat the test from step 1 to check.

Whitelist Bunny’s edge servers

Unbanning only helps until the next ban. To stop CrowdSec from banning Bunny again, put Bunny’s IP addresses on a whitelist. Bunny adds edge servers over time, so instead of creating the whitelist once, use a small script that rebuilds it from Bunny’s current list:

#!/bin/sh
# Rebuilds the CrowdSec whitelist from Bunny's current list of edge servers
set -e
TARGET=/etc/crowdsec/parsers/s02-enrich/bunnycdn-whitelist.yaml
IPS=$(curl -sf --max-time 30 https://bunnycdn.com/api/system/edgeserverlist/plain | tr -d '\r' | grep -E '^[0-9.]+$')

# Keep the current whitelist if the download failed or looks incomplete
[ "$(printf '%s\n' "$IPS" | wc -l)" -gt 100 ] || exit 1

{
  echo 'name: local/bunnycdn-whitelist'
  echo 'description: "Never ban Bunny CDN edge servers"'
  echo 'whitelist:'
  echo '  reason: "Bunny CDN edge server"'
  echo '  ip:'
  printf '%s\n' "$IPS" | sed 's/.*/    - "&"/'
} > "$TARGET.tmp"
mv "$TARGET.tmp" "$TARGET"
systemctl reload crowdsec

Save it as /usr/local/bin/bunny-crowdsec-whitelist.sh, make it executable and run it once:

sudo chmod +x /usr/local/bin/bunny-crowdsec-whitelist.sh
sudo /usr/local/bin/bunny-crowdsec-whitelist.sh
sudo systemctl status crowdsec

The last command shows whether CrowdSec reloaded without errors. To keep the whitelist up to date, run the script weekly from root’s crontab (sudo crontab -e):

0 4 * * 1 /usr/local/bin/bunny-crowdsec-whitelist.sh

The script only replaces the whitelist when the download worked and contains a plausible number of addresses, so a failed download never leaves you without one. It covers IPv4. If your server also has an IPv6 address, Bunny may connect over IPv6 as well; Bunny publishes those addresses at bunnycdn.com/api/system/edgeserverlist/ipv6.

A note on the community blocklist

This whitelist stops CrowdSec’s own detections from banning Bunny. Bans that come from the community blocklist, shown with CAPI or lists as their source in step 2, are handled separately. Recent CrowdSec versions offer allowlists that cover blocklist entries as well; run cscli allowlists --help to see whether yours has them. On older versions, run the unban command again if Bunny shows up there.

If CrowdSec isn’t the culprit

If step 2 finds nothing, something else between Bunny and your server is dropping the traffic. Check:

• Other ban tools, such as fail2ban (sudo fail2ban-client status).
• The firewall rules on the server (sudo ufw status or sudo nft list ruleset).
• Your hosting provider’s firewall or DDoS protection, usually found in its control panel.
• The origin address in your Bunny pull zone settings, which should point to your server’s current IP address or hostname.

Going further: banning visitors behind a CDN

The underlying issue is that behind a CDN, a firewall ban can only ever hit the CDN, never the bot or attacker using it. If you want CrowdSec to keep protecting those sites, make your web server log the real visitor’s IP address instead of Bunny’s. In nginx, you do that with set_real_ip_from (listing Bunny’s addresses) and real_ip_header X-Forwarded-For. CrowdSec will then detect the actual culprits. Blocking them has to happen somewhere that sees the real visitor, such as CrowdSec’s nginx bouncer or Bunny’s own security rules, because your firewall only ever sees Bunny.

Not just Bunny

The same can happen behind any CDN or reverse proxy, including Cloudflare. Most of them publish their addresses. Cloudflare publishes ranges at cloudflare.com/ips-v4 and cloudflare.com/ips-v6, which go under cidr: instead of ip: in a CrowdSec whitelist. Otherwise the approach is the same: check your bans against the list, then whitelist it.

In short

• If Bunny returns 504 errors while your server is healthy and your other sites work, suspect a ban on Bunny’s IP addresses.
• Compare a request through Bunny with a direct request using curl --resolve, and make sure Bunny’s response isn’t a cache hit.
• Check CrowdSec’s decisions against Bunny’s published list of edge servers.
• Lift the bans, whitelist Bunny’s addresses, and refresh the whitelist weekly.

Last Updated on 5 October 2026