Guides

Reporting abuse behind Cloudflare and CDNs

Khaled Doulami, WappDev. Published 29 September 2026.

You resolve a phishing domain, look up the IP, and the network record says Cloudflare, Inc. You send a report to abuse@cloudflare.com. Days later the page is still up, and the reply, if any, says Cloudflare is a pass-through and has forwarded your report to the hosting provider. This is one of the most common dead ends in abuse handling, and it is avoidable once you know what you are looking at.

What a reverse proxy changes

A content delivery network or reverse proxy sits between visitors and the real server. Visitors, and your DNS lookup, only ever see the proxy's addresses. The real server, called the origin, is somewhere else, on some other network, with some other abuse contact. The proxy caches and forwards; it does not store the page in any sense a takedown can act on.

So the RIR record for the IP is correct, and useless. It tells you who runs the proxy. It does not tell you who runs the server.

Cloudflare is the case everyone hits because a large share of phishing kits are put behind it, both for the free TLS and because it hides the origin from exactly the lookup you just did. Fastly, Akamai, Amazon CloudFront, Google Cloud's load balancers, Imperva and DDoS-Guard produce the same effect.

How to tell you are looking at a CDN

Any one of these is a strong signal; two or more settle it.

• The network owner. RDAP or WHOIS for the IP names Cloudflare, Fastly, Akamai, Amazon (for CloudFront ranges), Google or another proxy operator rather than a hosting company.
• The CNAME chain. dig +short CNAME www.example.com returning something under cloudfront.net, fastly.net, akamaiedge.net, edgekey.net or cdn.cloudflare.net is the proxy naming itself.
• The nameservers. Cloudflare's reverse proxy is normally used with Cloudflare DNS, so dig +short NS example.com returns two ns.cloudflare.com hosts. This alone is not proof (DNS-only records exist), but with a Cloudflare IP it is.
• Response headers. curl -sI https://example.com returning server: cloudflare and a cf-ray header, or x-served-by: cache-lhr... from Fastly, or x-amz-cf-id from CloudFront.
• Two IPv4 addresses in adjacent ranges. Cloudflare typically returns a pair such as 104.21.x.x and 172.67.x.x.

What Cloudflare will and will not do

Cloudflare publishes its position plainly: for content it proxies but does not host, it forwards abuse complaints to the hosting provider and the site owner and does not itself remove content. Sending the report to the RIR abuse address gets you an automated pointer to the same process.

Use the form at abuse.cloudflare.com and choose the phishing category. Three things then happen that are worth having:

1. Cloudflare forwards the report to the origin hosting provider, who can act.
2. For phishing and malware reports, Cloudflare will normally disclose the origin hosting provider to the reporter, so you learn who to chase directly.
3. Cloudflare can place a warning interstitial in front of a confirmed phishing page. This does not remove it, but it stops most visitors reaching it.

Trademark, copyright and general "this site is bad" reports get the forwarding without the extra help, and are slower.

The other proxies

• Fastly: abuse@fastly.com, from its RIR records, is monitored and they forward to the customer. Fastly customers are mostly large legitimate sites; a phishing page behind Fastly usually means a compromised customer, so the customer's own security team is the faster route if you can identify them.
• Akamai: abuse@akamai.com. Same pattern as Fastly, with the same customer profile.
• Amazon CloudFront: report through the AWS abuse form at support.aws.amazon.com/#/contacts/report-abuse or abuse@amazonaws.com. Because CloudFront customers are usually also AWS hosting customers, AWS can often act on the origin directly.
• Google Cloud: the abuse form on Google Cloud's site. As with AWS, the origin is often within the same provider.
• DDoS-Guard and similar: forward at best. Expect nothing and rely on the registrar.

Where the report should actually go

Behind a CDN, the routing order inverts. For a directly hosted page you go to the host first, registrar second. Behind a proxy:

1. Registrar first. The registrar can suspend the domain regardless of where the origin is, and for a domain registered to phish, suspension is the right outcome anyway. Find the contact in the domain's RDAP record; the contact-finding guide walks through it.
2. CDN form in parallel. Not instead of the registrar. The forwarding reaches the host, and for phishing you may get the host's name back.
3. Origin host, once known. If the CDN discloses it, or you find it by other means (below), report there too.
4. Browser blocklists, immediately. Safe Browsing and SmartScreen do not care where the page is hosted.

Finding the origin yourself

Sometimes you can see past the proxy. None of these always works, all of them sometimes do.

• Mail records. dig +short MX example.com. A phishing kit's domain often has an MX pointing at the same cheap VPS that hosts the page, because the kit's author set up mail for receiving stolen credentials. If the MX host resolves to a non-CDN address, that is probably the origin.
• Other hostnames. direct., origin., mail., ftp., cpanel. or webmail. subdomains are frequently left unproxied. Certificate transparency logs (crt.sh) list every hostname a certificate was issued for, which reveals subdomains you would not guess.
• DNS history. If the domain existed before it was put behind the proxy, a passive DNS service will have the old A record.
• Email headers. If the phishing was sent from the same server, the Received: chain names it.
• The page itself. Kits fetch images or post forms to hard-coded URLs, occasionally on the origin IP.

When any of these gives you a non-CDN address, look up its network abuse contact and report there as you would for any hosted page. Note in the report how you established the origin; the host will want to verify it.

Recording what happened

Whichever routes you use, log which contacts you sent to and when. Behind a CDN a single incident routinely generates three reports (registrar, CDN, host) plus two blocklist submissions, and when the page finally goes down you will want to know which of them worked. Over a few hundred incidents that record tells you which registrars and hosts act on their own, which need a nudge, and which only ever respond to the registrar suspension. That is the knowledge that makes the next takedown faster.

AbuseRoute is a private API that returns the registrar and hosting abuse contacts for a domain in one call, for security and abuse teams. How it works. For individual manual lookups, use the RrSG's ACID Tool.