Cloudflare in Front of Your Stack: DNS, CDN, TLS and Origins

Putting a reverse proxy such as Cloudflare in front of your application changes how every request reaches your servers. Done well, it reduces bandwidth costs, absorbs traffic spikes and hides your origin IP. Done carelessly, it caches pages that should never be cached, breaks API calls or leaves your origin reachable directly from the internet. This guide explains the moving parts in plain terms.

What the proxy actually does

Cloudflare is authoritative DNS plus a globally distributed reverse proxy. When a record is set to proxied (the orange cloud in the dashboard), DNS answers with Cloudflare's anycast IP addresses instead of your server's IP. The visitor connects to the nearest edge location, and Cloudflare opens a separate connection to your origin.

That means two TLS sessions, two sets of headers and two logs for a single request. Understanding this split explains most of the confusing behaviour people run into later.

Proxied vs. DNS-only records

Proxied (orange): HTTP/HTTPS traffic on standard web ports goes through the edge. You get caching, WAF, bot rules and IP masking.
DNS-only (grey): Cloudflare simply answers the DNS query with your real IP. Required for anything that is not HTTP over the supported ports — SSH, SMTP, SMPP sessions, database connections, custom TCP daemons.

A common mistake is proxying a record used for mail or a raw protocol endpoint and then wondering why connections time out. Keep those records grey.

Caching: the part that breaks things

By default, Cloudflare caches static file extensions and respects your origin's Cache-Control headers for the rest. Two rules keep you out of trouble:

Let the origin be the source of truth. Send explicit Cache-Control headers from your application rather than relying on edge defaults. public, max-age=31536000, immutable for fingerprinted assets; no-store for anything user-specific.
Never cache dynamic endpoints. Login pages, dashboards, cart pages, and above all API routes and webhook receivers must bypass the cache. A cached API response served to the wrong tenant is a data leak, not a performance win.

If you enable aggressive options such as caching HTML for everyone, pair them with a bypass rule for authenticated sessions (for example, when a session cookie is present) and a purge step in your deployment pipeline.

Cache keys and query strings

The default cache key includes the host, path and query string. Tracking parameters like utm_source therefore create separate cache entries for identical content. Normalising or ignoring known tracking parameters in the cache key improves your hit ratio without changing what users see.

TLS modes worth understanding

The encryption mode controls the second leg — edge to origin:

Flexible: encrypted to the visitor, plain HTTP to your origin. Avoid it. It creates a false padlock and can cause redirect loops.
Full: HTTPS to the origin, but the certificate is not validated. Better, still not ideal.
Full (strict): HTTPS with a valid, trusted certificate on the origin. This is the target configuration.

You can satisfy strict mode with a normal publicly trusted certificate or with a Cloudflare-issued origin certificate that is only trusted by the edge. Either way, automate renewal — expired origin certificates are a classic cause of sudden 5xx storms.

Protecting the origin

Hiding your IP behind a proxy is only useful if the origin refuses direct traffic. Otherwise an attacker who finds the address through historical DNS data, certificate transparency logs or a leaky mail header can bypass every edge rule you configured.

Firewall the origin so ports 80 and 443 accept connections only from the proxy's published IP ranges.
Require a shared secret header or client certificate (mutual TLS) between edge and origin.
Send outbound mail and notifications from a separate host or provider so your web origin IP never appears in message headers.
Do not reuse the same IP for a grey-clouded subdomain such as direct.example.com.

APIs, webhooks and delivery callbacks

Anything machine-to-machine deserves separate treatment. Bot management and challenge pages are designed to stop browsers, and an HTML challenge returned to an HTTP client looks like a failure — the caller sees a 403 or a body it cannot parse, and often stops retrying.

Practical steps:

Put API traffic on its own hostname or path prefix and create rules that skip challenges, rate-limit sensibly and bypass cache.
If a provider publishes source IP ranges for its callbacks, allowlist them explicitly.
Return proper status codes: a 200 for accepted webhooks, a 5xx only when you genuinely want a retry.
Log at both layers so you can tell whether a missing callback never arrived or was blocked at the edge.

This matters for delivery reports and status callbacks in general. If you consume SMS or OTP delivery webhooks — including those sent by UIPAPP — the receiving endpoint should sit behind a rule set that skips bot challenges and caching, otherwise reports may look delayed when they were simply refused at the edge.

Observability before optimisation

Before tightening anything, check the response headers the edge adds: cache status, ray identifier and server timing values tell you whether a request was served from cache, revalidated or forwarded. Compare edge logs with origin logs for the same time window. Most "Cloudflare broke my site" incidents turn out to be a cache rule, a redirect loop from a mismatched TLS mode, or an origin firewall change.

Treat the edge as part of your application configuration: version the rules, document exceptions and test after every change. The performance gains are real, but they only hold when dynamic and machine-to-machine traffic is explicitly carved out.