> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sevalla.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> These are the docs for Sevalla, a platform for deploying applications, databases, static sites, object storage and load balancers. The dashboard is at https://app.sevalla.com.
> Bold text in steps is an exact dashboard label.
> To act on a Sevalla account, prefer the Sevalla MCP server (https://mcp.sevalla.com/mcp, see https://docs.sevalla.com/ai-agents/overview.md), then the Sevalla CLI (https://docs.sevalla.com/developer-tools/cli.md), then the REST API (https://api-docs.sevalla.com, OpenAPI spec at https://api.sevalla.com/v3/openapi.json).
> Every page index is at https://docs.sevalla.com/llms.txt.

# Request headers

> The HTTP headers Cloudflare and Sevalla add to requests before they reach an application, how to get the visitor's real IP and country, and the headers Sevalla adds to responses.

Every request to an application passes through Cloudflare and Sevalla's ingress before it reaches the web process, and each adds headers on the way. This page lists those headers, the ones you'll use most (the visitor's IP address, country and protocol), and the headers Sevalla adds to your responses.

## Common headers

| To get | Read | Example |
| - | - | - |
| The visitor's IP address | `CF-Connecting-IP` | `203.0.113.7` |
| The visitor's country | `CF-IPCountry` | `DE` (ISO 3166-1 alpha-2 code) |
| The protocol the visitor used | `X-Forwarded-Proto` | `https` |
| The domain the visitor requested | `Host` | `shop.example.com` |
| An ID to trace one request in your logs | `X-Request-ID` | `4f1c2e…` |

Don't use the address of the TCP connection as the visitor's IP: it's Sevalla's ingress. Configure your framework to trust the proxy headers, for example `app.set("trust proxy", true)` in Express or the `TrustProxies` middleware in Laravel, so that `request.ip`, `request.secure` and generated URLs are right.

## Headers Cloudflare adds

Every request to the application's domains passes through Cloudflare, in every location.

| Header | Value |
| - | - |
| `CF-Connecting-IP` | The visitor's IP address |
| `CF-IPCountry` | The visitor's country, as a two-letter code |
| `CF-Ray` | A unique ID for the request in Cloudflare's network. Support can use it to trace a request |
| `CF-Visitor` | The visitor's scheme, as JSON: `{"scheme":"https"}` |
| `X-Forwarded-For` | The visitor's IP address, followed by any proxies in between |
| `X-Forwarded-Proto` | `https`; plain HTTP requests are redirected to HTTPS before they reach the application |
| `CDN-Loop` | `cloudflare`, used to detect request loops |
| `CF-Worker` | The Cloudflare zone of the Sevalla worker that forwarded the request, for example `sevalla.app` |
| `CF-EW-Via` | Set because a Cloudflare Worker forwarded the request |

Cloudflare also passes on the visitor's own headers, such as `User-Agent`, `Accept`, `Accept-Language`, `Cookie` and `Referer`.

## Headers the ingress adds

After Cloudflare, Sevalla's ingress in the application's location routes the request to the web process and adds its own headers. They depend on the location's cloud.

| Location type | Headers |
| - | - |
| Google Cloud | `X-Request-ID`, `X-Real-IP` (the visitor's IP address), `X-Forwarded-Host`, `X-Forwarded-Port`, `X-Forwarded-Scheme`, `X-Scheme`, `X-Original-Forwarded-For`, `X-Original-URI`. `X-Forwarded-For` is extended with the addresses the request passed through |
| Oracle Cloud Infrastructure | `X-Request-Id`, headers starting with `X-Envoy-`. `X-Forwarded-For` is extended with the addresses the request passed through |

Requests can also carry headers Sevalla uses internally, such as `x-svl-origin-port`. Don't build on them: they can change without notice. Rely on the headers in [Common headers](#common-headers), which are the same in every location.

## Headers Sevalla adds to responses

| Header | When | Value |
| - | - | - |
| `Access-Control-Allow-Origin` | Your response doesn't set it | `*`: any website can read the response from the browser. Set this header yourself to allow only your own origins |
| `sv-custom-metadata` | Responses from your application | JSON with the application's ID, the company's ID and the resource type, used by Sevalla to attribute traffic |
| `svid` | Responses from your application | An encrypted form of the same data |
| `CF-Worker-Custom-Field` | Responses from your application | The same data in an older format, kept for compatibility |
| `Cache-Control` | The [CDN or edge caching](/applications/caching) is on and your response doesn't set it | See [How long responses stay cached](/applications/caching#how-long-responses-stay-cached) |
| `X-Content-Type-Options` | Google Cloud locations | `nosniff` |
| `Retry-After`, `Cache-Control` | [Maintenance mode](/applications/maintenance-mode) is on | `300` and `no-store`, with status `503` |
| `Server`, `CF-Ray` | Every response, from Cloudflare | `cloudflare` and the request's ray ID |

Sevalla doesn't change the other headers your application sends.

## See the headers your application receives

The headers a request carries are visible only to the application. To list them, log them from your code, for example with a temporary route in a Node.js application:

```javascript server.js theme={null}
import express from "express"

const app = express()

app.get("/debug/headers", (req, res) => {
  console.log(req.headers)
  res.json(req.headers)
})

app.listen(process.env.PORT || 8080, "0.0.0.0")
```

Open `https://shop.example.com/debug/headers`, read the result or the [runtime logs](/applications/logs), and remove the route afterwards: it shows request details to anyone who opens it. To see response headers, run `curl -I https://shop.example.com`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.