HTTP headers can be found in both the HTTP Request and HTTP Response.
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
This header represents the protocol of the forwarded server, typically
https in production and
ip address of the client that made the request.
This header represents the unique deployment, not the preview URL or production domain. For example,
This header is identical to the
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.
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 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)
A stale response was found in the edge but revalidated synchronously due to
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.
There are a few methods to enable the Network Layer cache with the
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
pragma: no-cacheby default, which reveals the true load time of the page with the synchronous update to the cache.