Introduction

A site can be behind Cloudflare and still leak its origin IP through one overlooked DNS-only record. Once that happens, attackers and scanners can bypass Cloudflare protections and reach the server directly. The problem often hides in subdomains, legacy records, or service hostnames that were left gray-clouded during a migration. The fix is to identify which records expose the origin and then decide whether they should be proxied, removed, or locked down at the server.

Symptoms

  • The origin server IP is easy to discover from DNS lookups
  • Firewall logs show direct traffic hitting the origin outside Cloudflare ranges
  • One hostname is protected by Cloudflare while another points straight to the same server
  • Security tooling reports that the site origin is exposed publicly
  • The issue started after adding subdomains, mail records, or migration leftovers

Common Causes

  • A Cloudflare DNS record was left as DNS-only instead of proxied
  • Legacy subdomains still point to the production server directly
  • Teams proxied the main hostname but forgot supporting hostnames that share the same origin
  • The origin firewall allows general public access even though Cloudflare is meant to front the site
  • Operational records were kept public without checking whether they reveal the same server IP

Step-by-Step Fix

  1. Review all public DNS records and identify which hostnames still resolve directly to the origin server.
  2. Decide which of those records truly need to stay DNS-only, because some services should not be proxied while others should.
  3. Proxy the web-facing records that belong behind Cloudflare and remove any legacy entries that no longer serve a real purpose.
  4. Restrict the origin firewall so direct web traffic is accepted only from Cloudflare proxy ranges where possible.
  5. Check whether admin, staging, API, or forgotten subdomains still reveal the same backend IP even after the main hostname is protected.
  6. Verify that mail-related records, verification records, and other non-proxied services do not accidentally point to the shared production web origin.
  7. Re-test from public DNS and direct-origin access paths after the changes to confirm the server is no longer openly exposed.
  8. Review server logs for continued direct hits that may indicate another hostname or historical record is still leaking the origin.
  9. Keep an inventory of proxied versus DNS-only records so future DNS changes do not reopen the same exposure.