Protect the origin behind Cloudflare: allow-list, Authenticated Origin Pulls, or Tunnel

Who this is for: engineers who run an nginx origin behind the Cloudflare proxy and want to know which control to use, in what order, and what breaks when it goes wrong. These are the settings we check first.

What does protecting the origin mean?#

Making sure the only way to reach your application is through your Cloudflare zone, so the WAF, rate limits, and bot rules cannot be skipped by connecting to the origin IP directly. Cloudflare’s guide groups the controls into DNS, application, transport, and network layers.

The DNS points come first. Use proxied records to hide origin addresses, and rotate origin IPs after onboarding, because historical DNS records stay public. Review DNS-only, SPF, and other TXT records for leaked origin addresses, and if possible do not host mail on the same server: bounce messages can reveal its IP.

Which method should you use? The origin protection decision table#

The origin protection decision table compares the controls. “What it proves” comes from Cloudflare’s documentation; the “When to use” column is our judgment.

Cloudflare rates the allow-list moderately secure, and both Authenticated Origin Pulls and Tunnel very secure. The default ranges are shared: egress addresses reserved for a single account are an Enterprise option. Treat the last two methods as alternatives for a given hostname, not as layers: Cloudflare documents that Authenticated Origin Pulls has no effect on hostnames served through a tunnel.

How do you restore the real visitor IP in nginx?#

Behind the proxy, the TCP peer is always a Cloudflare address. Cloudflare passes the visitor’s address in the CF-Connecting-IP header and recommends it, or True-Client-IP (Enterprise only), over X-Forwarded-For, because each holds a single address. In nginx, the realip module replaces the client address, and set_real_ip_from lists “trusted addresses that are known to send correct replacement addresses”.

# one set_real_ip_from line per range, from https://www.cloudflare.com/ips-v4 and /ips-v6
set_real_ip_from 173.245.48.0/20;
# ...
real_ip_header CF-Connecting-IP;

Three rules follow. Trust only Cloudflare’s ranges; trusting more would let any client supply the header (our reading of the nginx definition). Regenerate the list on a schedule: Cloudflare says it needs regular updates, and its IPs page, intended as the definitive source, keeps an update history. If a load balancer sits between Cloudflare and nginx, trust that hop too and read X-Forwarded-For with real_ip_recursive on, which takes the last untrusted address instead of the last address.

How do Authenticated Origin Pulls work, and which mode do you pick?#

Authenticated Origin Pulls (AOP) uses mutual TLS: Cloudflare presents a client certificate, and an origin configured to require one rejects connections without it. Cloudflare documents three separate modes; turning one on or off does not change the others.

If you set up expiry notifications for uploaded zone-level or per-hostname certificates, Cloudflare sends them 30 and 14 days before expiry. AOP needs the SSL/TLS mode set to Full or Full (strict); it does not apply with Off or Flexible.

Safe rollout order. Cloudflare’s setup pages use two stages, optional and then on:

1. For zone-level or per-hostname AOP, upload your client certificate and key to Cloudflare, and for per-hostname, associate the hostnames.
2. Install the CA that signed it on the origin and point ssl_client_certificate at it.
3. Set ssl_verify_client optional; and log $ssl_client_verify, which reads SUCCESS, FAILED:reason, or NONE.
4. Enable AOP and confirm that requests show SUCCESS.
5. Switch to ssl_verify_client on;.
6. Send a request with curl directly to the origin IP: it should fail.

The Error 520 page lists AOP enabled on Cloudflare without the matching origin configuration among its causes. To roll back, return the origin to optional before changing the Cloudflare setting.

Why use Full (strict) with an Origin CA certificate?#

Full (strict) validates what Full does not: the origin certificate must be unexpired, issued by a public authority or Cloudflare Origin CA, and match the hostname. An Origin CA certificate fits origins that receive traffic only through proxied records. It encrypts only the connection between Cloudflare and the origin, so visitors who reach the origin directly, after pausing Cloudflare or switching a record to DNS-only, may see certificate errors. It can carry up to 200 hostnames or wildcards, a wildcard covers one level, and Cloudflare does not currently send expiry notices for it: track the date in your own inventory or monitoring.

When is Cloudflare Tunnel the better choice?#

When the origin can have no public IP at all. cloudflared opens outbound connections to Cloudflare, so you can configure the firewall to allow only that outbound traffic, on port 7844 over TCP and UDP, and block all inbound traffic. The cost is operational: you run and update one or more connectors on the request path. For an existing origin with a public IP, AOP adds no component to the request path, so it is usually the quicker first step; Tunnel fits when the platform is rebuilt.

What causes 520 and 524 errors at the origin?#

A 524 means the origin did not send an HTTP response before Cloudflare’s Proxy Read Timeout, 125 seconds by default (Error 524 page, updated July 23, 2026). Enterprise zones can raise it to 6,000 seconds with a cache rule or the API, and a 30-second Proxy Write Timeout can also produce a 524. Cloudflare’s fixes: shorten long-running processes, use status polling, or move long requests to a DNS-only subdomain. Long work belongs in a background job that the client polls.

A 520 means the origin returned an empty, unknown, or unexpected response. Listed causes include crashes, firewalls that block Cloudflare, headers above 128 KB, missing headers, HTTP/2 configuration, and AOP misconfiguration.

Keep-alive matters too. Cloudflare reuses idle origin connections for up to 900 seconds and asks origins to enable keep-alive; its HTTP/2-to-origin page says some 520 and 522 errors can relate to idle timeouts. The nginx default keepalive_timeout is 75 seconds. When 520s appear sporadically, compare the origin’s timeout with Cloudflare’s before looking elsewhere.

What belongs in the origin’s Cache-Control and headers?#

Make the origin’s Cache-Control the contract for caching. By default Cloudflare does not cache a response with Set-Cookie, or with private, no-store, no-cache, or max-age=0. The default cache key includes the query string, so tracking parameters can fragment the cache; exclude them with a cache rule.

A workable default: public, max-age=31536000, immutable for fingerprinted assets, no-cache or a short lifetime for HTML, and private, no-store for authenticated responses. Set HSTS and CSP in one place only: the origin, a response header Transform Rule, or Cloudflare’s HSTS setting, so two layers cannot send conflicting values.

The origin hardening checklist#

• Origin IP absent from DNS-only, SPF, and TXT records; rotated after onboarding.
• Ports 80 and 443 open only to Cloudflare’s ranges, or no inbound ports with Tunnel.
• Real visitor IP restored from CF-Connecting-IP, trusted only from Cloudflare’s ranges, list refreshed on a schedule.
• SSL/TLS mode Full (strict); origin certificate expiry tracked.
• AOP in the strictest mode you can operate; enforcement confirmed by a failed direct curl.
• Origin timeouts and keep-alive reviewed against Cloudflare’s connection limits; long work moved to background jobs.
• Cache-Control set by the origin per content type; no stray cookies on assets.
• HSTS and CSP set in one place.