Planning origin access restrictions behind Cloudflare

Inventory every service on the server, including shared-hosting neighbours where applicable. Keep console or another recovery route and decide whether Cloudflare Tunnel, firewall restrictions or authenticated origin connections fit the deployment.

1. Confirm the public web hostnames are correctly proxied and work under the intended TLS configuration.
2. Discuss the design with the server administrator. On shared hosting, customers should not change the server firewall or assume exclusive control of its IP.
3. If using IP restrictions, allow the current official Cloudflare ranges for the relevant web ports before adding the restrictive rule. Include required IPv4 and IPv6 paths.
4. Consider authenticated origin protection appropriate to the service so source-IP access alone is not the entire trust decision.
5. Test through Cloudflare, required administrator access and an authorised direct-origin check. Monitor for certificate-renewal or health-check failures after the change.

Public web access should follow the intended Cloudflare path while authorised operational services still function. Maintain an update process for any externally published address ranges.

An exposed DNS-only mail hostname can reveal the origin address even when the web record is proxied. Restricting all ports to Cloudflare addresses can break mail, SSH and FTP. Scope the network controls to the actual architecture.

No. Historical DNS and other services may reveal it. Enforced access controls, authentication and maintained application security provide protection beyond obscuring an address.

• Keeping mail and FTP hostnames outside Cloudflare’s web proxy
• Moving a Cloudflare site to Full strict TLS safely
• Diagnosing Cloudflare error 522 and origin connection timeouts
• Adding Cloudflare Turnstile with mandatory server-side verification

• Cloudflare: Protect Your Origin Server
• Cloudflare: Authenticated Origin Pull
• www.cloudflare.com: Ips