Protect the origin: close the paths your CDN cannot cover

Draw the connection you intend to protect

A CDN can inspect and absorb traffic that reaches its edge, while the origin server may still expose another route to the same application. That distinction matters during both ordinary troubleshooting and a DDoS incident. Start by drawing the path a real client is supposed to use: hostname, edge service, authenticated or restricted origin connection, reverse proxy and application listener. Then list every alternative entrance you administer. A public origin address, an old address-family record, an alternate hostname and an application port exposed directly can each create a different operational boundary. The useful question is which requests must cross the intended controls before reaching expensive work.

Cloudflare's origin-protection guidance describes several approaches, including restricted origin access, authenticated origin connections and outbound tunnels. These are different deployment choices, not interchangeable switches that every application already uses. The operating procedure in this article is our own: inventory the actual entrances, decide which callers require each one, then verify both allowed and denied paths. It applies most naturally to infrastructure you control. Do not assume a DNS dashboard setting proves that a host firewall, IPv6 listener or separately published backend port has the same policy. Each layer needs its own evidence and an owner who can recover access if the change is wrong.

Inventory hostnames, addresses and listeners together

Write down the application's public hostnames and all currently advertised A and AAAA records. Include redirects and any legacy names retained during a migration. Then inspect the server's actual listening addresses and ports through authorized administration. A listener bound to loopback has a different exposure from one bound to every interface. A container port can be published independently of the reverse proxy that owns the familiar public hostname. Inspect the runtime mapping as well as the proxy configuration. The inventory should connect a public entrance to the process and data it can reach, rather than merely collecting a list of domains and hoping they refer to the same service.

Keep the management route separate from the application route. An agent endpoint used by a control plane, a backup receiver and a deployment registry may need different caller restrictions and credentials. Restricting the website to a CDN must not accidentally cut off the only recovery channel, and preserving management access must not create an unrestricted alternate application entrance. Describe the intended exception precisely: which service connects, how it authenticates and which endpoint it needs. A generic allow rule for an administrator's changing public IP is a fragile replacement for a known management design, particularly when the incident itself affects the route used to administer the server.

DNS-only and proxied records make different promises

A DNS record can direct clients to an address without placing an HTTP security service in the request path. Conversely, a proxied hostname can send browsers through the provider's edge while other hostnames or addresses remain direct. Check the mode for each record that matters instead of assuming every domain under the account is protected identically. A website can work perfectly through a DNS-only record and still require its own network and HTTP protection. The right description is the observed path and configured controls. A familiar provider's nameservers on the domain do not establish that the provider handles the application's HTTP traffic.

During migration, retained old-origin forwarding can keep cached DNS clients working. It also extends the period in which multiple origins participate in the public path. Record the forwarding owner, allowed destination, TLS handling and retirement condition. Check both address families where they are advertised. After a cutover, an obsolete AAAA record can continue directing some clients to a different machine even when the A record looks correct. The application inventory, authoritative records and public response should agree. If they do not, treat that difference as unresolved routing evidence before claiming that the new origin is the only place where production traffic can arrive.

Restricted networks and authenticated origins solve different problems

An origin network policy can admit traffic only from the approved edge network or other specifically required callers. Keep the source ranges current through the provider's documented process, and test the result without discarding recovery access. This reduces unintended direct reachability, but it does not by itself identify the customer's particular account at a shared provider. The scope of the rule is the actual network identity it checks. Avoid describing an allowlist as proof that every accepted request belongs to the one website you intended, especially when several tenants share an upstream platform or address range.

Authenticated Origin Pulls adds client-certificate validation on the edge-to-origin connection. Cloudflare documents that its global shared certificate identifies the Cloudflare network, while customer-supplied zone or hostname certificates provide a narrower account-specific boundary. Choose the mechanism that matches the trust statement you need, and verify the server-side enforcement as well as the dashboard setting. A server certificate that lets the edge authenticate the origin is a different credential from a client certificate that lets the origin authenticate the edge. Confusing those directions can produce an encrypted connection that still lacks the caller restriction the operator thought had been installed.

Outbound tunnels change the exposure model

An outbound connector can provide a route from the application to an edge service without requiring the same public inbound application listener. This can simplify origin exposure, but the connector and its credentials become part of the service dependency and recovery plan. Inspect the real listener configuration rather than assuming that installing a tunnel automatically removed an older public port. Keep connector identity, allowed hostnames, local destination and startup behavior documented. A tunnel that points at the wrong local service is still a routing mistake, even when its own connection state appears healthy in a provider console.

Cloudflare explicitly distinguishes Tunnel from Authenticated Origin Pulls; AOP does not operate on a Tunnel-connected hostname in the same way because that path uses the connector relationship. Do not stack product labels in a runbook as if each independently validates the same connection. Explain the mechanism that actually carries requests in this deployment and the separate entrances that remain. Verify recovery after a connector restart and check what users see when the local application is unavailable. An edge connection can remain established while its backend is failing, so connector uptime and application success should be recorded as related but distinct observations.

Reconstruct client identity only through trusted proxies

Once a reverse proxy sits between a client and the application, the observed network peer and the original client address can differ. An HTTP header naming a client is not automatically trustworthy. Configure which immediate senders are allowed to supply replacement address information, and preserve the original peer where your logging supports it. Nginx's real-IP module documentation describes explicit trusted sources and header selection. Apply those settings to the topology you actually run. Trusting replacement headers from every address lets a direct caller influence the identity used for rate limits, investigation and access decisions.

Multiple proxy hops need an explicit trust chain. Determine which proxy rewrites or appends the address header, which networks are trusted at each hop and which value the next component will accept. Keep direct maintenance requests distinguishable from ordinary edge traffic. Do not silently treat a private-looking header value as evidence that the caller is an internal service. In Hostwatch investigations, network caller, page Referer and verified application identity answer different questions. A shared IP does not prove an account entitlement, and a same-site Referer does not prove that your server generated the request. Protecting the origin includes preserving the meaning of identity evidence after a request crosses the intended proxy boundary.

Verify allowed paths with the same identity clients use

Make one harmless request through the public hostname and confirm the expected TLS identity, route and application behavior. A certificate valid for a different name is not sufficient, and a redirect to an unexpected host deserves inspection. If the site needs authentication, use an authorized test flow rather than equating a login page with a working account operation. Record which address family and network path were tested. This gives the operator a positive baseline before evaluating denied direct requests. It also prevents a successful private-origin probe from being substituted for the public path that customers actually use.

The example commands below inspect only an owned endpoint and its documented origin. The names and address are placeholders, and the direct probe assumes an authorized host without an intervening client proxy. --resolve preserves the HTTPS hostname while selecting a particular destination address. Do not disable certificate validation to turn a failed direct check into a success. In some designs, a direct request is expected to fail because the origin accepts only an authenticated edge connection or a private network. That is a meaningful expected result, provided the public positive check still succeeds and the failure matches the intended policy rather than a broken listener.

# Use only a hostname and origin you administer.
NAME=monitor.example.com
ORIGIN=192.0.2.10

# Public client route: keep normal TLS verification.
curl --connect-timeout 5 --max-time 15 --silent --show-error \
  --output /dev/null --write-out 'HTTP=%{http_code} peer=%{remote_ip} TLS=%{ssl_verify_result}\n' \
  "https://$NAME/"

# A direct-origin test, only where your access policy permits it.
# --noproxy prevents a local HTTP proxy from changing this test's path.
curl --noproxy '*' --resolve "$NAME:443:$ORIGIN" \
  --connect-timeout 5 --max-time 15 --silent --show-error \
  --output /dev/null --write-out 'HTTP=%{http_code} peer=%{remote_ip} TLS=%{ssl_verify_result}\n' \
  "https://$NAME/"
# An intentional origin restriction may deny this second request.
# Distinguish network denial, TLS rejection and an HTTP response.

Negative checks must fail for the intended reason

Test the entrances that should no longer reach application work. A rejected direct connection, a required client certificate and an application-level denial establish different boundaries. Identify which one your deployment expects and inspect its evidence. A random timeout during network trouble does not prove a firewall policy is correct. An HTTP error generated by the application proves the request reached farther than a network-level rejection. Use a harmless route and a limited number of requests. The test is about verifying your own boundary, not generating an incident or evaluating an unrelated website's origin exposure.

Keep the denied-path result beside the allowed-path result and the installed policy revision. Repeat the checks for intentionally advertised IPv4 and IPv6 destinations, retained old origins and required maintenance routes. If a direct path is retained by design, describe its caller restrictions and ownership rather than hiding it from the diagram. A useful completion statement can say that the public route succeeds and a named direct route is denied by the expected control. It should not turn that limited check into a universal claim that the origin can never be reached or that every future record and listener will inherit the policy automatically.

Change access without creating a recovery incident

Before tightening a network or proxy policy, preserve a working administrative path and a reviewed reversal procedure. Know how to restore the previous rule if the edge's source ranges, certificate chain or routing assumptions are wrong. Make one bounded change, validate its syntax where supported and verify the result before expanding scope. Coordinate with the owner of certificate validation, uptime checks and backup or deployment connections that may share the host. The goal is to remove unintended entrances while retaining the ones the organization actually needs, under explicit authentication and responsibility.

A temporary transition can be appropriate during a migration, but it needs an expiry or concrete retirement condition. Record the old route's continued purpose and the evidence required to remove it. Avoid leaving an emergency direct hostname as a permanent undocumented bypass because it once helped debugging. At the same time, do not delete retained rollback data or credentials merely because DNS now points elsewhere. Route retirement, data retention and credential revocation are separate actions. A clear handoff tells the next operator which parts of the previous origin remain deliberately available and which no longer carry production traffic.

Preserve visibility at both sides of the boundary

Edge observations describe requests handled by the edge; origin observations describe work that reached the server. Compare their intervals and semantics before interpreting a difference. Requests can be cached, rejected or retried upstream, and one public action can create several origin requests. If direct origin traffic is possible, the edge's count is not a complete account of every request the host receives. Keep response classes, caller reconstruction and retained examples scoped to their collection source. The purpose of joining the data is to explain the path, not to force two counters with different meanings to match exactly.

Hostwatch adds host and service context at the origin, including configured operations and evidence about application pressure. It does not automatically hide public addresses, enroll the server into a CDN or supply upstream bandwidth protection. Those are infrastructure decisions the owner must configure and verify. Use the product to connect the observed service, runtime and traffic outcome, while keeping missing collection or unsupported enforcement explicit. A successful origin-protection change should improve the confidence of that investigation: accepted callers have a known path, denied entrances have a verified boundary and the important public flow remains usable throughout the operating change.

End with a route inventory another operator can trust

The final record should list the public hostnames, active origin destinations, edge or tunnel mechanism, trusted proxy chain, required maintenance entrances and relevant certificate identities. Include the policy revision, positive and negative checks, their timestamps and the rollback method. Retain the reason for any exception. A teammate should be able to identify where an incoming request is authenticated and where a client address becomes trusted without reading the original chat or inferring security from a provider logo. That is a practical definition of an origin boundary the team can continue to operate.

Revisit the record when adding a hostname, exposing a container port, changing address families or moving a service. These ordinary operations can change the boundary without changing the public application's branding. Treat origin protection as a maintained connection contract rather than a one-time DNS setting. The reward is useful during both quiet operation and a burst: the operator can tell which traffic crossed the intended controls, which route needs investigation and who can change each layer. That clarity makes upstream protection and local service evidence work together, with fewer hidden paths left for the next incident to discover.

• Inventory A, AAAA, proxy mode, listeners and deliberate exceptions.
• State the expected network and authentication policy for each origin path.
• Review trusted peers before accepting forwarded identity.
• Test an allowed path and a forbidden path from appropriate vantage points.
• Retain management access, a narrow rollback and a dated route inventory.