Put a proxy in front with a clear trust model
Understand DNS, origin encryption and access before enabling a Cloudflare proxy.
Content revised · English
- Guide type
- Operate & secure
- Examples
- Illustrative, environment-specific
- Integration scope
- No remote machine connected
Decide which paths the proxy should carry
A web reverse proxy changes the path between visitors and your HTTP origin. It does not automatically proxy SSH, mail or every arbitrary protocol. Identify DNS-only records and the impact on mail, validation and administration before enabling the web proxy.
Delegate the zone and verify records
Create the zone with the provider, review imported records and change the registrar’s nameservers to the assigned values. Test the delegation, then proxy the intended A/AAAA or CNAME web records. Keep MX targets and unsupported service paths configured correctly.
Authenticate the origin with Full (strict)
Install an origin certificate that is valid for the requested name and supported by the proxy, then use Full (strict). Confirm the origin answers securely before restricting it. An edge padlock alone does not prove the edge-to-origin connection is authenticated.
Restrict direct origin access without losing administration
Use the provider’s current published IPv4 and IPv6 ranges for the web allow-list, with a maintenance plan for changes. Keep a separate verified administrative path. Review every origin hostname and listener; a DNS-only service on the same IP can reveal the destination.
Test the trust chain and application behaviour
Check HTTPS redirects, certificate names, mixed content, cache rules and logged client IP handling. Trust forwarded visitor headers only from the authorised proxy sources. Application WAF rules and bot controls are a separate layer from network DDoS mitigation.
Leave with a verifiable result.
- Decide which paths the proxy should carry.
- Test the trust chain and application behaviour.
- Keep recovery information and secrets outside public files.