Cloudflare HTTP request headers
Cloudflare passes all HTTP request headers to your origin web server and adds additional headers as specified below.
For incoming requests, the value of this header will always be set to accept-encoding: br, gzip. If the client set a different value, such as accept-encoding: deflate, it will be overwritten and the original value will be available in request.cf.clientAcceptEncoding.
CF-Connecting-IP provides the client IP address connecting to Cloudflare to the origin web server.
This header will only be sent on the traffic from Cloudflare’s edge to your origin web server.
For guidance on logging your visitor’s original IP address, refer to Restoring original visitor IPs.
Alternatively, if you do not wish to receive the CF-Connecting-IP header or any HTTP header that may contain the visitor’s IP address, enable the Remove visitor IP headers Managed Transform.
In same-zone Worker subrequests, the value of CF-Connecting-IP reflects the value of x-real-ip (the client’s IP). x-real-ip can be altered by the user in their Worker script.
In cross-zone subrequests from one Cloudflare zone to another Cloudflare zone, the CF-Connecting-IP value will be set to the Worker client IP address '2a06:98c0:3600::103' for security reasons.
For Worker subrequests destined for a non-Cloudflare customer zone, the CF-Connecting-IP and x-real-ip headers will both reflect the client’s IP address, with only the x-real-ip header able to be altered.
When no Worker subrequest is triggered, cf-connecting-ip reflects the client’s IP address and the x-real-ip header is stripped.
Cloudflare provides free IPv6 support to all domains without requiring additional configuration or hardware. To support migrating to IPv6, Cloudflare’s Pseudo IPv4 provides an IPv6 to IPv4 translation service for all Cloudflare domains.
If Pseudo IPv4 is set to Overwrite Headers - Cloudflare overwrites the existing Cf-Connecting-IP and X-Forwarded-For headers with a pseudo IPv4 address while preserving the real IPv6 address in CF-Connecting-IPv6 header.
This header is used for loop detection, similar to the CDN-Loop header ↗.
If Pseudo IPv4 is set to Add Header - Cloudflare automatically adds the CF-Pseudo-IPv4 header with a Class E IPv4 address hashed from the original IPv6 address.
True-Client-IP provides the original client IP address to the origin web server. True-Client-IP is only available on an Enterprise plan. In the example below, 203.0.113.1 is the original visitor IP address. For example: True-Client-IP: 203.0.113.1
There is no difference between the True-Client-IP and CF-Connecting-IP headers besides the name of the header. Some Enterprise customers with legacy devices need True-Client-IP to avoid updating firewalls or load-balancers to read a custom header name.
To add a True-Client-IP HTTP header to requests, enable the Add “True-Client-IP” header Managed Transform.
Alternatively, if you do not wish to receive the True-Client-IP header or any HTTP header that may contain the visitor’s IP address, enable the Remove visitor IP headers Managed Transform.
X-Forwarded-For maintains proxy server and original visitor IP addresses. If there was no existing X-Forwarded-Forheader in the request sent to Cloudflare, X-Forwarded-For has an identical value to the CF-Connecting-IP header.
For example, if the original visitor IP address is 203.0.113.1 and the request sent to Cloudflare does not contain an X-Forwarded-For header, then Cloudflare will send X-Forwarded-For: 203.0.113.1 to the origin.
If, on the other hand, an X-Forwarded-For header was already present in the request to Cloudflare, Cloudflare will append the IP address of the HTTP proxy connecting to Cloudflare to the header. For example, if the original visitor IP address is 203.0.113.1 and a request is proxied through two proxies: proxy A with an IP address of 198.51.100.101 and proxy B with an IP address of 198.51.100.102 before being proxied to Cloudflare, then Cloudflare will send X-Forwarded-For: 203.0.113.1,198.51.100.101,198.51.100.102 to the origin. Proxy A will append the original visitor’s IP address (203.0.113.1) to X-Forwarded-For before proxying the request to proxy B which, in turn, will append Proxy A’s IP address (198.51.100.101) to X-Forwarded-For before proxying the request to Cloudflare. And finally, Cloudflare will append proxy B’s IP address (198.51.100.102) to X-Forwarded-For before proxying the request to the origin.
If you do not wish to receive the visitor’s IP address in the X-Forwarded-For header, or any HTTP header that may contain the visitor’s IP address, enable the Remove visitor IP headers Managed Transform.
X-Forwarded-Proto is used to identify the protocol (HTTP or HTTPS) that Cloudflare uses to connect to origin web server. By default, it is http. Certain encryption mode may change this header to https if the connection is encrypted.
For incoming requests, the value of this header will be set to the protocol the client used (http or https). If the client set a different value, it will be overwritten.
The CF-ray header (otherwise known as a Ray ID) is a hashed value that encodes information about the data center and the visitor’s request. For example: CF-RAY: 230b030023ae2822-SJC.
Add the CF-Ray header to your origin web server logs to match requests proxied to Cloudflare to requests in your server logs.
Enterprise customers can also see all requests via Cloudflare Logs.
The CF-IPCountry header contains a two-character country code of the originating visitor’s country.
Besides the ISO-3166-1 alpha-2 codes ↗, Cloudflare uses the following special country codes:
XX- Used for clients without country code data.T1- Used for clients using the Tor network.
To add this header to requests, along with other HTTP headers with location information for the visitor’s IP address, enable the Add visitor location headers Managed Transform.
Currently, this header is a JSON object, containing only one key called “scheme”. The header will be either HTTP or HTTPS, and it is only relevant if you need to enable Flexible SSL in your Cloudflare settings. For example: CF-Visitor: { \"scheme\":\"https\"}.
CDN-Loop allows Cloudflare to specify how many times a request can enter Cloudflare’s network before it is blocked as a looping request. For example: CDN-Loop: cloudflare
The CF-Worker request header is added to an edge Worker subrequest that identifies the host that spawned the subrequest. This is useful when you want to protect yourself against cross-zone worker subrequests. For example: CF-Worker: example.com.
You can add CF-Worker header on server logs similar to the way you add the CF-RAY header. To do that, add $http_cf_worker in the log format file: log_format cf_custom "CF-Worker:$http_cf_worker"'
CF-Worker is added to all Worker subrequests sent via fetch(). It is set to the name of the zone which owns the Worker making the subrequest. For example, a Worker script on route for foo.example.com/* from example.com will have all subrequests with the header:
CF-Worker: example.com
The intended purpose of this header is to provide a means for recipients (for example, origins, load balancers, other Workers) to recognize, filter, and route traffic generated by Workers on specific zones.
For incoming requests, the value of this header will always be set to Keep-Alive. If the client set a different value, such as close, it will be overwritten. Note that is also the case when the client uses HTTP/2 or HTTP/3 to connect.
When using Spectrum with a TCP application, these headers are not visible at the origin as they are HTTP headers. If you wish to utilize these in your application, there are two options:
- Use an HTTP or HTTPS Spectrum app instead of TCP
- Use the Proxy Protocol feature