How To Find Real IP Behind CloudFlare and WAF’s

Disclaimer: The information in this article is provided for educational purpose only. The techniques described are commonly used by security researchers and penetration testers to evaluate the effectiveness of Web Application Firewall (WAF) deployments and to ensure that origin servers are properly protected.

Web application firewalls (WAFs) and the CDNs that power them—Cloudflare, Akamai, Amazon CloudFront, Fastly, etc.—sit between visitors and a site’s origin server. They proxy DNS, TLS and HTTP traffic, masking the real IP of the web server to reduce DDoS risk, absorb malicious traffic, and speed up content delivery. However, in certain cases—such as when performing a penetration test, troubleshooting performance issues, or verifying that private services are truly hidden—it becomes important to identify the actual backend server.

This is where guides on How To Find Real IP Behind CloudFlare and other WAF solutions come into play, helping security professionals confirm whether their protective layers are correctly configured.

Why You Might Need the Real IP 

• Validate security posture: Confirm that sensitive services (SSH, RDP, admin panels) are not directly exposed once the WAF is bypassed.
• Accurate vulnerability scanning: Many scanners fail when they only hit the CDN; talking to the origin reveals the true patch level and software stack.
• Latency or routing analysis: Knowing where the server actually lives lets you optimise peering, choose nearer PoPs, or relocate workloads.
• Incident response: If an attacker is targeting your backend IP directly, you need to see that traffic and block at the edge firewall.

Manual Step-by-Step Workflow to Find the Real IP Behind WAF

The goal is to gather tiny leaks—DNS records, certificates, mis-routed sub-domains—and confirm a live HTTP/S response that matches the target hostname.

Baseline DNS look-ups

• Look up the A records (IPv4/IPv6) of the domain using tools like dig, nslookup, or online services like nslookup.io.
• If the WAF is in place, the returned addresses usually belong to the provider (e.g., Cloudflare ranges).
• A quick sanity check is to try different subdomains (e.g., mail.domain.com, ftp.domain.com) to see if any are pointed directly to the origin server instead of the WAF.

Manual Testing of Returned Addresses

• Sometimes domains have multiple A records.
• You can check each one manually in the browser or with curl.
• If the WAF is active, you’ll usually see an error page or a block message. If you find one address that bypasses the WAF, it may be the origin server.

Use Shodan

• Shodan is a search engine for internet-connected devices.
• Enter the domain name, known IPs, or SSL certificate details.
• Why useful? Shodan stores historical scans of servers, including open ports, banners, and services. You may find the server’s IP address before it was placed behind the WAF, or other exposed services still resolving to the origin.

Check SecurityTrails

• SecurityTrails provides historical DNS data.
• You can review past A records (before the WAF was enabled).
• Why useful? If the website was once exposed directly, older records might still point to the origin IP. Even if the DNS has been updated, the origin may still respond at that address.

Use FOFA

• FOFA.info is a Chinese internet asset search engine (similar to Shodan or Censys).
• It indexes domains, IPs, SSL certificates, and services.
• You can search for the domain or related certificates to discover IP addresses tied to it.
• Just like with Shodan, testing those addresses in the browser can reveal whether one is the live origin.

⚠️ Important Notes. Running these tests on systems you don’t own or don’t have permission to audit may be illegal. Always limit them to your own infrastructure or with explicit authorization.Used browser extensions to see if the site is protected by a WAF (like Amazon CloudFront). ​⁠

These techniques are widely used in penetration testing, red teaming, and security audits to ensure proper WAF configuration.

If the WAF is correctly deployed and the origin IP is well-hidden, none of these methods should expose the backend. That’s the ideal security outcome.

Other Ways to Discover the Real IP Address Behind Protection

In addition to DNS history, Shodan, and FOFA, security researchers sometimes use the following methods when testing their own infrastructure to check whether a Web Application Firewall (WAF) or reverse proxy is properly hiding the backend server.

Examine SPF Records

• What it is: SPF (Sender Policy Framework) records are DNS TXT records that define which servers can send email for a domain.
• Why it matters: Sometimes, organizations accidentally include the origin server’s IP in their SPF records.
• How to check:
  • Run dig TXT domain.com or use online SPF checkers.
  • Look for direct IP addresses or hostnames that might reveal the origin.

Use ZoomEye

• What it is: ZoomEye is another internet asset search engine, similar to Shodan and FOFA, but widely used in Asia.
• Why it matters: It crawls the global internet and indexes devices, services, and SSL certificates.
• How to use:
  • Search by domain, IP, or certificate details.
  • Cross-reference results with known WAF ranges. Non-WAF IPs may be the real server.

VirusTotal and AlienVault OTX

• VirusTotal: Aggregates malware scans and network information. When users upload suspicious files or URLs, VT logs associated IPs and domains.
• AlienVault OTX (Open Threat Exchange): A collaborative threat intelligence platform that stores IP/domain relationships.
• Why it matters: Both platforms often contain historical records linking domains to IPs, including those before a WAF was added.
• How to use:
  • Search the domain on VirusTotal and AlienVault OTX.
  • Review the “Relations” or “Passive DNS” sections for possible origin IPs.

Automating with Bash Scripts

• What it is: Instead of manually checking different sources, security engineers often write simple Bash scripts to automate:
  • DNS lookups
  • API queries (Shodan, Censys, FOFA)
  • Masscurl requests against candidate IPs
• Why it matters: Saves time and ensures consistency when testing multiple domains.
• Example: A script could pull all historical IPs from SecurityTrails, then curl each one and log which respond with the real site content.

Verification (Hosts File & Burp Suite)

• Hosts file method:
  • Add a candidate IP and map it to the target domain in your /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows).
  • Open the domain in a browser. If it resolves directly to the origin and loads correctly, you’ve verified the IP.
• Burp Suite method:
  • Configure Burp Suite to intercept traffic.
  • Send requests directly to the candidate IP while setting the Host header to the target domain.
  • If the server responds with the correct website content, that confirms the origin.

Comparative Overview of WAF / WAAP Solutions

Useful Links & Tools

This table groups web-based services, CLI tools, browser extensions, and automation scripts into one place, making it easy to see their purpose.

Frequently Asked Questions