> ## Documentation Index > Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt > Use this file to discover all available pages before exploring further. # Request Headers KnoxCall Does Not Forward > The exact request headers KnoxCall withholds from your upstream on proxied traffic, and what to do if your upstream needs one of them # Request headers KnoxCall does not forward When KnoxCall proxies a request for you, a fixed set of request headers is withheld from your upstream. They describe the connection between your caller and KnoxCall, or they are instructions and credentials meant for KnoxCall itself, so they stop here. This page is the complete list of those headers. It applies to proxied traffic on every path: * your **routes**, in the cloud and on a self-hosted proxy * the **AI Gateway** (`/v1/ai/...`) * the **ephemeral proxy** (`/v1/proxy`) * **inbound-webhook forwards** (`hooks.knoxcall.com`) The match is on the **exact header name**, in any letter case. There is no prefix rule behind this list: a header that merely starts with `CF-`, `X-Forwarded-` or `X-KnoxCall-` and is not named below is not withheld by it. This page covers which headers are withheld. It is not a full description of how each path builds the request it sends to your upstream; that is on each path's own page. ## The list ### Headers that address KnoxCall These tell KnoxCall who is calling and which route to use. KnoxCall reads them and does not pass them on. | Header | What it is | | - | - | | `X-KnoxCall-Key` | Your KnoxCall API key | | `X-KnoxCall-API-Key` | The API key header of KnoxCall's interactive demo | | `X-KnoxCall-Route` | The route to call | | `X-KnoxCall-Environment` | The environment to use | | `X-KnoxCall-Signature` | The request signature, on a route that requires signed requests | | `X-KnoxCall-Agent-Id` | Agent credentials | | `X-KnoxCall-Agent-Token` | Agent credentials | | `X-KnoxCall-Client-Assertion` | A signed assertion KnoxCall's own services use to identify themselves | | `X-KnoxCall-Origin` | The marker the SDKs' route-aware interceptor sends | | `X-KnoxCall-Env` | An internal routing label KnoxCall's edge sets | | `Cookie` | The cookies a browser attached. On a KnoxCall host these include a signed-in KnoxCall session | ### Headers a proxy in front of KnoxCall adds A reverse proxy or CDN adds these to say where the request came from. They describe your caller's connection to KnoxCall, not the request your upstream should see. | Header | What it is | | - | - | | `X-Forwarded-For` | The caller's address | | `X-Forwarded-Host` | The host the caller used | | `X-Forwarded-Proto` | The scheme the caller used | | `X-Forwarded-Server` | The proxy's own name | | `X-Real-IP` | The caller's address | | `True-Client-IP` | The caller's address | | `X-Client-Cert-Verify` | Result of mutual-TLS client verification | | `X-Client-Cert-Thumbprint` | The client certificate's thumbprint | | `X-Client-Cert-Subject` | The client certificate's subject | ### Headers Cloudflare adds KnoxCall's cloud edge runs on Cloudflare. These are the request headers Cloudflare itself can add on the way in. | Header | What it is | | - | - | | `CF-Connecting-IP` | The caller's address | | `CF-Connecting-IPv6` | The caller's address | | `CF-Pseudo-IPv4` | The caller's address | | `CF-Connecting-O2O` | An edge routing marker | | `CF-Ray` | Cloudflare's request ID | | `CF-Visitor` | The scheme the caller used | | `CDN-Loop` | Loop detection | | `CF-Worker` | Edge routing detail | | `CF-EW-Via` | Edge routing detail | | `CF-IPCountry` | The caller's location | | `CF-IPCity` | The caller's location | | `CF-IPContinent` | The caller's location | | `CF-IPLatitude` | The caller's location | | `CF-IPLongitude` | The caller's location | | `CF-Region` | The caller's location | | `CF-Region-Code` | The caller's location | | `CF-Metro-Code` | The caller's location | | `CF-Postal-Code` | The caller's location | | `CF-Timezone` | The caller's location | | `CF-Bot-Score` | Cloudflare's bot assessment of the caller | | `CF-Verified-Bot` | Cloudflare's bot assessment of the caller | | `CF-JA3-Hash` | The caller's TLS fingerprint | | `CF-JA4` | The caller's TLS fingerprint | | `Exposed-Credential-Check` | Cloudflare's leaked-credentials check | | `Malicious-Uploads-Detection` | Cloudflare's upload scan | | `Cf-Access-Jwt-Assertion` | A Cloudflare Access token for a signed-in person | | `CF-Cert-Presented` | The caller's client certificate, as the edge saw it | | `CF-Cert-Verified` | The caller's client certificate, as the edge saw it | | `CF-Cert-Revoked` | The caller's client certificate, as the edge saw it | | `CF-Cert-Issuer-DN` | The caller's client certificate, as the edge saw it | | `CF-Cert-Subject-DN` | The caller's client certificate, as the edge saw it | | `CF-Cert-Issuer-DN-RFC2253` | The caller's client certificate, as the edge saw it | | `CF-Cert-Subject-DN-RFC2253` | The caller's client certificate, as the edge saw it | | `CF-Cert-Issuer-DN-Legacy` | The caller's client certificate, as the edge saw it | | `CF-Cert-Subject-DN-Legacy` | The caller's client certificate, as the edge saw it | | `CF-Cert-Serial` | The caller's client certificate, as the edge saw it | | `CF-Cert-Issuer-Serial` | The caller's client certificate, as the edge saw it | | `CF-Cert-SHA256` | The caller's client certificate, as the edge saw it | | `CF-Cert-SHA1` | The caller's client certificate, as the edge saw it | | `CF-Cert-Not-Before` | The caller's client certificate, as the edge saw it | | `CF-Cert-Not-After` | The caller's client certificate, as the edge saw it | | `CF-Cert-SKI` | The caller's client certificate, as the edge saw it | | `CF-Cert-Issuer-SKI` | The caller's client certificate, as the edge saw it | ### Headers that belong to one connection These describe a single network hop. KnoxCall opens its own connection to your upstream and sets what that connection needs itself. | Header | What it is | | - | - | | `Host` | Set from your upstream's URL | | `Content-Length` | Set from the body KnoxCall sends | | `Connection` | Hop-by-hop | | `Keep-Alive` | Hop-by-hop | | `Proxy-Authenticate` | Hop-by-hop | | `Proxy-Authorization` | Hop-by-hop | | `TE` | Hop-by-hop | | `Trailers` | Hop-by-hop | | `Transfer-Encoding` | Hop-by-hop | | `Upgrade` | Hop-by-hop | ## Each path also keeps back its own credentials The list above is shared by every path. Each path additionally keeps back the credential you used to authenticate to KnoxCall on that path: * **Routes.** `Authorization` and `DPoP` when the `Authorization` value is a KnoxCall access token (`Bearer kc_…` or `DPoP kc_…`), and `X-Api-Key` when it holds a KnoxCall credential. An `Authorization` or `X-Api-Key` that carries your upstream's own credential is forwarded. * **AI Gateway.** `Authorization`, `X-Api-Key`, `X-Knox-AI-Key` and `DPoP`. The gateway authenticates you with these and supplies your provider's credential from the route. * **Ephemeral proxy.** `Authorization`, every header beginning `X-Knox-`, and `X-Api-Key` when it holds a KnoxCall credential. See [Invoke the ephemeral proxy](/api-reference/ephemeral-proxy/invoke). * **Inbound-webhook forwards.** Every header beginning `X-Knox-`. KnoxCall sets those itself to tell your receiver whether the signature verified. A delivery whose signature did not verify, where you have chosen to forward those, carries `Content-Type` and KnoxCall's own `X-Knox-` headers and nothing else the sender sent. ## Cloudflare Access credentials for your own upstream are forwarded If your upstream sits behind Cloudflare Access, the headers your caller sends to authenticate to it are yours and are forwarded: `CF-Access-Client-Id`, `CF-Access-Client-Secret` and `cf-access-token`. Only the token Cloudflare Access adds on the way in to KnoxCall, `Cf-Access-Jwt-Assertion`, is withheld. ## If your upstream needs one of these headers There is no response header or error when a header is withheld. The request is forwarded without it. * **On a route, including the route behind an AI Gateway agent**, add the header to the route's injected headers. A header the route injects is sent to your upstream even when its name is in one of the first three tables above; the route's value is sent and the value your caller put in that header is not. There is no template helper for the caller's IP address, so this suits a fixed value. The connection-level headers in the last table are always set by KnoxCall. * **On the ephemeral proxy and on inbound-webhook forwards** there are no injected headers, so a header on this list cannot be sent to the upstream on those paths. Send the value under a header name that is not on this list. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.