What nodes add to requests and responses
Headers nodes send to origins, response headers and cookies visitors get, and paths nodes answer themselves: for origin developers and scanners.
Request headers sent to the origin
A node rewrites these headers on every origin request. An empty value sends no header, so a visitor's own header of the same name is never passed through as is.
| Request header | Value | When |
|---|---|---|
Host | The visitor's Host by default; the origin settings can use the origin address or a custom value | Every origin request |
X-Forwarded-For | The peer address the node sees. When the peer is a trusted proxy of the site, its chain is kept and the peer is appended | Every origin request; not on the node's own cache prewarm |
X-Real-IP | The peer address; a trusted proxy's X-Real-IP is kept when it is a valid address | As above |
X-Forwarded-Proto | The protocol of the visitor's connection, http or https | As above |
Upgrade, Connection | A WebSocket upgrade's Upgrade as sent, Connection: upgrade | WebSocket sites only |
X-Client-Verify, X-Client-Cert-Fingerprint, X-Client-Cert-Subject | The client certificate result, fingerprint and subject | HTTPS sites with client certificate authentication only; every other site removes these three headers from the visitor's request so they cannot be forged |
Between node tiers the upper node adds an internal marker X-Cdnca-L2-Hop; origins never receive it, and a visitor's own value is overwritten.
When the origin answers with a Location or Refresh pointing at its own address, the node rewrites it to the visitor's domain, so visitors are not sent to the origin IP.
Response headers visitors get
| Response header | Value | When |
|---|---|---|
X-CDN-Cache | HIT, MISS, EXPIRED, STALE, UPDATING, REVALIDATED or BYPASS | Sites with caching and "Show cache status in response headers" on (the default); not sent while attack escalation holds the site at level B or above |
X-CDN-Cache-Reason | Why the cache was bypassed; values on the cache reference page | As above, only with BYPASS |
Server | cdnca by default; change it under System settings → Nginx, empty sends none | Every response |
Alt-Svc | h3=":<port>"; ma=86400 | The site has HTTP/3 on that port |
Strict-Transport-Security | Per the site's HSTS setting | The site has HSTS on |
X-Cdnca-Challenge | The challenge mode (such as delay, slider), redirect, banned, expired, failed | Verification pages, redirects and ban pages from CC rules |
X-Cdnca-WAF | challenge, banned, expired, failed | Verification and ban pages from WAF rules |
X-Cdnca-Ban | listed (status 403) | The visitor's IP is on the site's block list |
X-Cdnca-Referer-Check | rejected (status 403) | Hotlink protection refused the request |
Retry-After | Seconds | 429, ban pages, verification pages |
Nodes remove X-CDN-Cache, X-CDN-Cache-Reason, X-Cdnca-Cache-Key and X-Cdnca-Site from origin responses, so an origin cannot fake the cache status. The last two appear only on the node's own cache prewarm requests; visitors never see them.
Error and block pages a node generates itself also carry Cache-Control: no-store, max-age=0, a Content-Security-Policy that loads nothing external, Referrer-Policy: no-referrer and X-Content-Type-Options: nosniff, and drop Set-Cookie, Location, ETag, Via and similar headers.
Cookies nodes set
Nodes write these cookies when a visitor passes a verification or enters session persistence; they serve security checks or load balancing. If your site has a privacy notice, you may need to list them.
| Cookie | Purpose | Lifetime | Attributes |
|---|---|---|---|
__cdnca_cc_pass | Proof of a passed CC verification, signed over the site, rule, visitor network and User-Agent | The rule's pass duration, 60 s to 7 days | HttpOnly, SameSite=Lax, Secure over HTTPS; Domain when a challenge cookie domain is set |
__cdnca_cc_probe | One-time nonce of the 302 redirect check | The verification page lifetime, 30 to 3600 s | HttpOnly, SameSite=Lax |
__cdnca_waf_pass | Proof of a passed WAF verification, signed over the site rule, visitor network and User-Agent | The rule's pass duration | HttpOnly, SameSite=Lax, Secure over HTTPS |
__cdnca_waf_probe | One-time token when WAF redirects a non-GET request to verification first | 300 s | HttpOnly, SameSite=Lax |
__cdnca_waf_grey | Proof of a passed managed WAF grey zone challenge | 3600 s by default | As __cdnca_waf_pass |
__cdnca_ad | Proof of the automatic defense L1 challenge, written by the page script, bound to the site, visitor address and hour | 3600 s | SameSite=Lax (written by script, so no HttpOnly) |
| Challenge policy pass | Proof of a passed challenge policy; the policy names it and the name must start with __Host- | The policy's pass duration | Secure, HttpOnly, SameSite=Lax |
| Session persistence cookie | With cookie persistence in origin load balancing, remembers which origin the visitor uses; you choose the name | Browser session | HttpOnly, SameSite=Lax |
Do not give your own cookies names starting with __cdnca_.
Paths nodes answer themselves
These paths never reach the origin. When a security scanner reports them, you can cite this page: they belong to the CDN node.
| Path | Purpose | When it exists |
|---|---|---|
/_guard/verify | Answers of the CC verification page | The site has a CC rule with a verification action |
/.cdnca/waf/verify | Answers of the WAF verification page | The site has a WAF rule with a verification action |
/.cdnca/challenge/verify, solver.js, picture | Challenge policy submission, solver script and images | The site has a challenge policy |
/.well-known/acme-challenge/ | Certificate file validation (HTTP-01) | Tokens the node holds are answered by the node; others go to the origin when the site has "Origin requests certificates" on, otherwise 404 |
/.well-known/cdnca-market-probe, /.well-known/cdnca-market-benchmark | Node market probing and speed tests | Only on port 80 of node market supply nodes, and only for domains no site uses; a configured site's domain is proxied as usual |
Paths starting with /_cdnca302/ | Landing address of 302 scheduling | Only on plain HTTP ports with 302 scheduling on |
The request ID on node error pages
Error pages a node generates show a request ID, the node and the visitor's IP at the bottom. Ask visitors who report a problem for these three; an administrator finds the request in the access logs by its request ID.
Common questions
The origin sees the node's address as the visitor IP
Read the first address of X-Forwarded-For or X-Real-IP. If your own proxy (such as a load balancer) sits in front of the node, add it as a trusted proxy in the site settings so the node keeps its address chain.
The browser shows no X-CDN-Cache
Check that the site caches, that "Show cache status in response headers" is on, and that the site is not at attack escalation level B or above.
An origin redirect sends visitors to the origin IP
Nodes only rewrite Location and Refresh that point at the origin's own address. When the origin names another domain the node leaves it alone; fix the redirect on the origin.