Cabeçalhos HTTP

Os cabeçalhos HTTP de proxy, como X-Forwarded-For e Via, são usados por servidores proxy para transmitir ao servidor upstream informações sobre o cliente original, o caminho da requisição e outros dados contextuais que, de outra forma, seriam ocultados pela presença do proxy.

Quando uma requisição HTTP passa por um ou mais servidores proxy, o servidor upstream imediato normalmente vê o endereço IP do último proxy, e não o do cliente original. Os cabeçalhos de proxy resolvem isso adicionando ou modificando cabeçalhos HTTP específicos, permitindo que o IP do cliente original, o protocolo, o host e a sequência de proxies sejam comunicados ao servidor de destino final.

X-Forwarded-For

O cabeçalho X-Forwarded-For (XFF) é um cabeçalho padrão de fato usado para identificar o endereço IP de origem de um cliente que se conecta a um servidor web por meio de um proxy HTTP ou balanceador de carga.

Finalidade

Sua finalidade principal é permitir que o servidor web acesse o endereço IP do cliente original para registro em log, analytics, segurança e lógica específica da aplicação (por exemplo, controle de acesso baseado em IP, geolocalização). Sem o XFF, todas as requisições pareceriam originar-se do endereço IP do servidor proxy.

Formato e exemplos

O cabeçalho XFF pode conter uma lista de endereços IP separados por vírgula. Quando uma requisição passa por vários proxies, cada proxy acrescenta ao cabeçalho XFF o endereço IP do cliente que se conectou a ele.

• X-Forwarded-For: <client>, <proxy1>, <proxy2>

Exemplo 1: proxy único
Um cliente (192.0.2.1) conecta-se a um proxy (198.51.100.1), que então se conecta ao servidor de origem.
O proxy adiciona:

X-Forwarded-For: 192.0.2.1

O servidor de origem vê a requisição vindo de 198.51.100.1 e X-Forwarded-For: 192.0.2.1.

Exemplo 2: múltiplos proxies
Um cliente (192.0.2.1) conecta-se ao Proxy A (198.51.100.1), que se conecta ao Proxy B (203.0.113.1), que então se conecta ao servidor de origem.
1. Cliente para Proxy A: o Proxy A adiciona X-Forwarded-For: 192.0.2.1.
2. Proxy A para Proxy B: o Proxy B recebe X-Forwarded-For: 192.0.2.1. O Proxy B acrescenta 198.51.100.1 a ele.
O cabeçalho torna-se: X-Forwarded-For: 192.0.2.1, 198.51.100.1.
3. Proxy B para servidor de origem: o servidor de origem recebe X-Forwarded-For: 192.0.2.1, 198.51.100.1.

Em uma cadeia de proxies, o endereço IP mais à esquerda normalmente é o cliente original. O endereço IP mais à direita é o IP do proxy upstream imediato (o cliente que se conectou ao proxy atual).

Considerações de segurança sobre o X-Forwarded-For

O cabeçalho X-Forwarded-For pode ser facilmente forjado por um cliente malicioso. Um cliente pode enviar uma requisição com um cabeçalho X-Forwarded-For fabricado.

GET / HTTP/1.1
Host: example.com
X-Forwarded-For: 10.0.0.1, 1.1.1.1

Se um proxy simplesmente acrescentar informação a isso, o cabeçalho recebido pelo servidor de origem pode ficar assim: X-Forwarded-For: 10.0.0.1, 1.1.1.1, <proxy_ip>.
Portanto, as aplicações downstream não devem confiar diretamente em todo o valor do cabeçalho X-Forwarded-For. A prática geralmente aceita é confiar apenas no endereço IP não confiável mais à direita da lista como o IP real do cliente, depois de remover quaisquer entradas pertencentes a proxies confiáveis conhecidos. Muitos servidores web e frameworks de aplicação oferecem mecanismos para especificar uma lista de proxies confiáveis.

Via

O cabeçalho Via é um cabeçalho HTTP padrão que indica os proxies e gateways intermediários pelos quais uma requisição (ou resposta) passou.

Finalidade

O cabeçalho Via serve a vários propósitos:
* Rastreabilidade: fornece um rastro da cadeia de proxies, útil para depurar caminhos de rede.
* Detecção de laços: pode ajudar a detectar laços de requisição em cadeias de proxies.
* Compatibilidade de protocolo: sinaliza as versões de protocolo usadas por cada proxy intermediário, o que pode ser relevante para conversões de protocolo.

Formato e exemplos

Cada proxy adiciona sua própria entrada Via ao cabeçalho. O formato de cada entrada é protocol-name/protocol-version host:port (comment). O campo comment é opcional e pode conter informação arbitrária.

Via: <protocol-name>/<protocol-version> <host>:<port> (comment)

Exemplo:
Um cliente envia uma requisição que passa pelo Proxy A (hostname proxy-a.example.com, porta 8080) e pelo Proxy B (hostname proxy-b.example.com, porta 80).

1. Cliente para Proxy A: o Proxy A adiciona Via: HTTP/1.1 proxy-a.example.com:8080.
2. Proxy A para Proxy B: o Proxy B recebe Via: HTTP/1.1 proxy-a.example.com:8080. O Proxy B insere sua própria entrada no início.
   O cabeçalho torna-se: Via: 1.1 proxy-b.example.com, 1.1 proxy-a.example.com:8080.
   (Observação: HTTP/ costuma ser omitido quando o protocolo é HTTP, e as portas 80/443 podem ser omitidas.)
3. Proxy B para servidor de origem: o servidor de origem recebe o cabeçalho Via completo.

Considerações de privacidade e operação

O cabeçalho Via expõe a topologia interna da rede e nomes de host, o que pode ser uma preocupação de segurança ou privacidade em algumas implantações. Organizações podem optar por remover ou modificar esse cabeçalho em proxies voltados para fora, a fim de evitar a divulgação da rede interna.

Forwarded

O cabeçalho Forwarded é um cabeçalho padronizado definido na RFC 7239, destinado a substituir os cabeçalhos de fato X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto.

Finalidade

Ele oferece uma forma mais estruturada e extensível de transmitir ao servidor upstream informações sobre o cliente original, o próprio proxy e o contexto da requisição original (host, protocolo).

Formato e exemplos

O cabeçalho Forwarded pode conter um ou mais conjuntos de parâmetros, separados por vírgulas, representando cada proxy da cadeia. Cada conjunto de parâmetros usa pares chave-valor. Parâmetros comuns incluem:
* for: o endereço IP (ou identificador ofuscado) do cliente original.
* by: o endereço IP (ou identificador ofuscado) do proxy que encaminhou a requisição.
* host: o cabeçalho Host original solicitado pelo cliente.
* proto: o protocolo original (por exemplo, http ou https) usado pelo cliente.

Forwarded: for=<client_ip>; proto=<protocol>; host=<original_host>
Forwarded: for=<client_ip>, for=<proxy_ip>; proto=<protocol>

Exemplo 1: proxy único
Um cliente (192.0.2.1) conecta-se via HTTPS a um proxy (198.51.100.1) solicitando example.com.
O proxy adiciona:

Forwarded: for=192.0.2.1; proto=https; host=example.com

Exemplo 2: múltiplos proxies
Cliente (192.0.2.1) -> Proxy A (198.51.100.1) -> Proxy B (203.0.113.1) -> servidor de origem.
1. Cliente para Proxy A: o Proxy A adiciona Forwarded: for=192.0.2.1; proto=https; host=example.com.
2. Proxy A para Proxy B: o Proxy B recebe o cabeçalho. O Proxy B acrescenta sua própria entrada, incluindo by para se identificar.
O cabeçalho torna-se:
Forwarded: for=192.0.2.1; proto=https; host=example.com, for=198.51.100.1; by=203.0.113.1
(Observação: os parâmetros host e proto normalmente só são incluídos na primeira entrada, referente ao cliente original, a menos que um proxy faça reescrita de protocolo ou de host.)

Comparação: X-Forwarded-For vs. Forwarded

Outros cabeçalhos de proxy

X-Forwarded-Host

Esse cabeçalho de fato identifica o Host original solicitado pelo cliente no cabeçalho de requisição HTTP Host. É útil quando um proxy ou balanceador de carga modifica o cabeçalho Host (por exemplo, para roteamento interno) antes de encaminhar a requisição ao servidor upstream, mas a aplicação precisa saber qual host o cliente solicitou originalmente para tarefas como gerar URLs absolutas ou lidar com hosts virtuais.

Exemplo:
O cliente solicita example.com. O proxy encaminha para o host interno app-server-1.

Host: app-server-1
X-Forwarded-Host: example.com

X-Forwarded-Proto

Esse cabeçalho de fato identifica o protocolo (HTTP ou HTTPS) que o cliente usou para se conectar ao proxy ou balanceador de carga. Isso é crucial quando o proxy faz terminação SSL/TLS, ou seja, o cliente conecta via HTTPS mas o proxy se comunica com o servidor backend em HTTP puro. A aplicação precisa saber o protocolo original para gerar links corretos (por exemplo, https:// em vez de http://).

Exemplo:
O cliente conecta via HTTPS a um balanceador de carga. O balanceador conecta via HTTP ao backend.

X-Forwarded-Proto: https

X-Real-IP

Esse é outro cabeçalho de fato, comumente usado pelo NGINX, para transmitir o endereço IP do cliente original. Diferente do X-Forwarded-For, ele normalmente contém apenas um único endereço IP — o do cliente original ou o do proxy confiável upstream imediato. Costuma ser definido pelo primeiro proxy da cadeia após validar o cabeçalho X-Forwarded-For.

Exemplo:

X-Real-IP: 192.0.2.1

Implicações práticas e casos de uso

Os cabeçalhos de proxy são fundamentais para o funcionamento correto e a segurança de arquiteturas web modernas que envolvem proxies, balanceadores de carga e CDNs.

• Logs e analytics: endereços IP de cliente precisos são essenciais para logs de acesso do servidor web, análise de tráfego e acompanhamento do comportamento do usuário.
• Segurança:
  • Controle de acesso baseado em IP: restringir o acesso a determinados recursos com base nos endereços IP dos clientes.
  • Rate limiting: evitar abusos ou ataques DDoS limitando as requisições por IP de cliente.
  • Web Application Firewalls (WAFs): aplicar regras de segurança com base na identidade do cliente original.
  • Geolocalização: determinar a localização geográfica do usuário para personalização de conteúdo ou conformidade regulatória.
• Lógica da aplicação:
  • Geração de URLs: as aplicações precisam de X-Forwarded-Host e X-Forwarded-Proto para construir URLs absolutas corretas (por exemplo, para redirecionamentos ou links internos) que correspondam à requisição original do cliente.
  • Gerenciamento de sessão: alguns mecanismos de sessão podem estar atrelados a endereços IP.
  • Aplicações multi-tenant: distinguir tenants com base no cabeçalho Host original.
• Depuração e resolução de problemas: o cabeçalho Via e a cadeia completa de X-Forwarded-For ajudam a diagnosticar problemas no caminho de rede e identificar proxies problemáticos.

Configuração de proxy e boas práticas de segurança

Configurar os proxies para tratar corretamente esses cabeçalhos é essencial.

• Limites de confiança: confie apenas nas entradas de X-Forwarded-For (ou Forwarded) provenientes de proxies upstream conhecidos e confiáveis. Implemente lógica para fazer o parsing do cabeçalho, identificar os IPs de proxies confiáveis e derivar o IP real do cliente a partir da entrada não confiável mais à direita.
• Remoção/sanitização de cabeçalhos: em proxies voltados para fora, considere remover ou sanitizar os cabeçalhos Via e quaisquer cabeçalhos X- internos personalizados, para evitar a divulgação de informações sobre a topologia interna da rede.
• Consistência: garanta que todos os proxies e balanceadores de carga de uma cadeia estejam configurados de forma consistente para acrescentar ou definir esses cabeçalhos corretamente.
• Padrão vs. personalizado: embora Forwarded seja o padrão, X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto continuam amplamente usados. As implementações costumam suportar ambos ou priorizar o cabeçalho Forwarded quando ele está presente.