HTTP headers can be found in both the HTTP Request and HTTP Response.

Request Headers

The following headers are sent to each Vercel deployment and can be used to process the request before sending back a response. These headers can be read from the Request object in your Serverless Function.


This header represents the domain name as it was accessed by the client. If the deployment has been assigned to a preview URL or production domain and the client visits the domain URL, it contains the custom domain instead of the underlying deployment URL.


A unique identifier for each request. Contains a list of regions through which the request has traversed, usually the region closest to the visitor.


This header is identical to the host header.


This header represents the protocol of the forwarded server, typically https in production and httpin development.


The public IP address of the client that made the request. If you are trying to use Vercel behind a proxy, we currently overwrite the X-Forwarded-For header and do not forward external IPs. This restriction is in place to prevent IP spoofing. Please contact us if allowing Vercel to trust your X-Forwarded-For IP is a feature your Team needs.


This header is identical to the x-forwarded-for header. However, x-forwarded-for could be overwritten if you're using a proxy on top of Vercel.


This header is identical to the x-forwarded-for header.


This header represents the unique deployment, not the preview URL or production domain. For example,


A two-character ISO 3166-1 country code for the country associated with the location of the requester's public IP address.


A string of up to three characters containing the region-portion of the ISO 3166-2 code for the first level region associated with the requester's public IP address. Some countries have two levels of subdivisions, in which case this is the least specific one. For example, in the United Kingdom this will be a country like "England", not a county like "Devon".


The city name for the location of the requester's public IP address. Non-ASCII characters are encoded according to RFC3986.

Response Headers

The following headers are included in Vercel deployment responses and indicate certain factors of the environment. These headers can be viewed from the Browser's Dev Tools or using an HTTP client such as curl -I <DEPLOYMENT_URL>.


Used to specify directives for caching mechanisms in both the Network layer cache and the browser cache. See the Cache Control Headers section for more detail. The default value is cache-control: public, max-age=0, must-revalidate which instructs the network layer and the browser not to cache.


An integer that indicates the number of bytes in the response.


The media type that describes the nature and format of the response.


A timestamp indicating when the response was generated.

server: Vercel

Shows where the request came from. This header can be overridden by other proxies (e.g., Cloudflare).


A header often abbreviated as HSTS that tells browsers that the resource should only be requested over HTTPS. The default value is strict-transport-security: max-age=63072000 (2 years)


This header is automatically added with noindex to Preview Deployments to prevent search engines from crawling them. A deployment without this header can be created by pointing a production domain to it. If this is not desired, one can always disable the header manually using the headers configuration.


This header's value indicates whether the response was served from Vercel's edge cache.

The following values are possible when the content being served is static or uses Cache-Control header.

The response was not found in the edge and thus fetched from an origin server.
The response was served from the edge.
The cache was bypassed and so the response was served from an origin server.
The response is stale (served from the edge). A background request to the origin was made to get a fresh version. (see Stale-While-Revalidate for more info)
The response was served from static storage.
A stale response was found in the edge but revalidated synchronously due to Pragma: no-cache.


The unique identifier for each request. Contains a list of regions through which the request has traversed, usually the region center closest to the visitor.

Cache-Control Header

There are a few methods to enable the Network Layer cache with the Cache-Control header.


Setting the directive to s-maxage=60 will instruct the Network Layer to cache the response for 60 seconds. A request can be cached anywhere from 1-31,536,000 seconds (max 1 year). When s-maxage is set, the Network Layer strips the s-maxage directive and does not return it to the client.


In addition to setting s-maxage the cache control directive can be combined with stale-while-revalidate in order to serve a stale response from the cache and update the cache in the background:

cache-control: s-maxage=1, stale-while-revalidate

This instructs the Network Layer cache to:

  • Serve from the cache for 1 second.
  • Return a stale request (if requested after 1 second).
  • Update the cache in the background asynchronously (if requested after 1 second).

If you need to do a synchronous revalidation you can set the pragma: no-cache header along with the cache-control header. This can be used to get an idea of how long the background revalidation is taking and sets the x-vercel-cache header to REVALIDATED.

Note: Many browser developer tools set pragma: no-cache by default, which reveals the true load time of the page with the synchronous update to the cache.

Custom Response Headers

Using configuration, you can assign custom headers to each response.

Custom headers can be configured with the headers property in next.config.js for Next.js projects, or it can be configured in vercel.json for all other projects.

Alternatively, a Serverless Function can assign headers to the Response object.