Ao configurar um proxy reverso com Nginx, a ocorrência de erros pode ser um desafio. Um dos códigos de status mais frequentes e frustrantes é o 502 Bad Gateway. Este erro geralmente indica um problema na comunicação entre o servidor Nginx e o servidor de upstream (o servidor de destino).

Identificando a Causa Raiz

Em muitos casos, a causa de um 502 Bad Gateway reside em problemas de rede ou falhas no servidor de upstream. Uma verificação enicial da conectividade de rede, como pings para os domínios de upstream, pode descartar problemas de rede básicos. No entanto, quando a rede parece estar estável, o foco deve se voltar para os logs do Nginx.

A análise dos logs de erro do Nginx pode revelar mensagens específicas que apontam para a origem do problema. Por exemplo, um erro como:

(SSL: error:0A000438:SSL routines::tlsv1 alert internal error:SSL alert number 80) while SSL handshaking to upstream, client: 127.0.0.1, server: uapis.cn

sugere uma falha durante o handshake SSL com o servidor de upstream. Ao pesquisar por essa mensagem de erro específica, é comum encontrar discussões em fóruns como o Stack Overflow.

Solução para Erros de Handshake SSL (SNI)

Uma causa comum para falhas no handshake SSL em cenários de proxy reverso é a ausência do suporte a Server Name Indication (SNI) por parte do Nginx. Muitos servidores de upstream modernos utilizam SNI para servir múltiplos certificados SSL em um único endereço IP. Se o Nginx não estiver configurado para repassar essa informação, o handshake falhará.

A solução geralmente envolve adicionar a seguinte diretiva à configuração do seu servidor Nginx:

proxy_ssl_server_name on;

Essa configuração instrui o Nginx a enviar o nome do host solicitado ao servidor de upstream durante o handshake SSL, permitindo que o servidor de destino selecione o certificado correto e complete a conexão com sucesso.

Lidando com Novos Erros Após a Correção Inicial

Após implementar a solução para o handshake SSL, é possível que um novo erro surja, como um 404 Not Found. Isso pode indicar que, embora a conexão com o servidor de upstream tenha sido estabelecida, a requisição não está sendo encaminhada corretamente.

Um problema comum nesse estágio é a forma como o cabeçalho Host é definido. Originalmente, pode estar configurado assim:

proxy_set_header Host $host;

Se o servidor de upstream espera um nome de host específico para processar a requisição (em vez de usar o nome de host que o cliente usou para se conectar ao proxy), o cabeçalho Host pode precisar ser explicitamente definido com o domínio correto do servidor de upstream:

proxy_set_header Host findmyip.net;

Essa modificação garante que o servidor de upstream receba o cabeçalho Host esperado, permitindo que ele processe a requisição corretamente e retorne a resposta adequada, em vez de um 404.

Configurações Adicionais Úteis

Durante a depuração de problemas de proxy reverso, várias outras configurações podem ser consideradas:

• Resolução de DNS: Definir um servidor DNS específico para o Nginx resolver nomes de domínio de upstream. ``` resolver 8.8.8.8;

• Protocolos SSL/TLS: Especificar os protocolos TLS permitidos para comunicação segura. ``` ssl_protocols TLSv1.2 TLSv1.3;

• Verificação de Certificado SSL: Em alguns casos, desabilitar a verificação do certificado SSL do servidor de upstream pode ser necessário (use com cautela). ``` proxy_ssl_verify off;

• Requisições OPTIONS (CORS): Configurar o Nginx para lidar com requisições OPTIONS, comuns em cenários de Cross-Origin Resource Sharing (CORS). ``` if ($request_method = OPTIONS) { add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; add_header Access-Control-Allow-Headers "Authorization,Content-Type"; return 204; }

• Parâmetros de Buffer e Timeout: Ajustar os tamanhos de buffer e os tempos limite para lidar com respostas grandes ou lentas do servidor de upstream. ``` proxy_buffer_size 16k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_connect_timeout 300s; proxy_read_timeout 300s; proxy_send_timeout 300s;

• server_name e Porta: Garantir que o server_name na configuração do Nginx corresponda ao nome do host que o cliente está acessando e que a porta esteja corretamente configurada.
• Tratamento de Barra Final (/): Estar ciente das diferenças entre location /path e location /path/, bem como entre proxy_pass https://example.com e proxy_pass https://example.com/. Geralmente, a barra final no proxy_pass pode ser omitida se não for estritamente necessária para reescrever caminhos.

A resolução de problemas de proxy reverso frequentemente envolve uma abordagem iterativa de análise de logs e ajuste de configurações.