Como corrigir o erro 502 Bad Gateway ao usar proxies

Um erro 502 Bad Gateway ao usar proxies indica que o servidor proxy, atuando como gateway, recebeu uma resposta inválida do servidor upstream ou do site de destino. Resolver esse problema exige uma abordagem de diagnóstico sistemática para determinar se a falha vem da configuração local do cliente, da infraestrutura do provedor de proxy ou das proteções anti-bot do servidor de destino.

Entendendo a mecânica de um erro 502 em ambientes com proxy

No contexto de web scraping, monitoramento de SEO ou uso geral de proxies, o "gateway" normalmente é o próprio servidor proxy. Quando você envia uma requisição, ela vai do seu cliente até o proxy, que então a encaminha ao servidor de destino. Se o servidor de destino encerrar a conexão abruptamente, devolver um cabeçalho HTTP malformado ou estiver temporariamente sobrecarregado, o proxy não consegue concluir a requisição e retorna um código de status 502 para a sua aplicação.

Diferente de um 404 (Not Found) ou de um 403 (Forbidden), o erro 502 é especificamente uma falha de comunicação entre dois servidores. Para quem usa serviços de alto desempenho como o GProxy, ver um 502 muitas vezes significa que o proxy está funcionando corretamente como intermediário, mas está com dificuldade para obter um "handshake" ou uma resposta válida do próximo salto da cadeia. Esse próximo salto pode ser um nó de entrada, um servidor back-connect ou o site de destino final.

A cadeia de proxy, ponto a ponto

Arquiteturas modernas de proxy costumam envolver várias camadas. Uma única requisição pode passar por um balanceador de carga, um gerenciador de rotação e, por fim, um nó de saída. Um erro 502 pode ocorrer em qualquer uma dessas junções:

• Cliente para balanceador de carga: raramente causa 502; geralmente resulta em timeout de conexão.
• Balanceador de carga para gerenciador de rotação: ocorre quando a tabela de roteamento interna está mal configurada.
• Nó de saída para o site de destino: a causa mais comum, quando o site de destino rejeita o IP do nó de saída ou o nó de saída está offline.

Causas comuns de erros 502 Bad Gateway

Identificar a causa raiz é o primeiro passo para a correção. Embora a mensagem de erro seja genérica, o contexto em que ela aparece dá pistas. A tabela a seguir resume os principais fatores por trás dos erros 502 ao usar proxies residenciais ou de datacenter.

Passos de diagnóstico para isolar o problema

Antes de modificar seu código ou sua infraestrutura, execute estes passos de diagnóstico para reduzir o escopo da origem do erro 502.

1. Teste sem o proxy

Tente acessar a URL de destino a partir do seu IP local ou de outra rede. Se o site continuar retornando 502, o problema está inteiramente do lado do servidor de destino. Nesse cenário, nenhuma configuração de proxy vai resolver; você precisa esperar o administrador do site corrigir os problemas internos do servidor dele.

2. Verifique as credenciais e o status do proxy

Confirme que seu painel GProxy mostra uma assinatura ativa e que sua whitelist de IP ou as credenciais de usuário/senha estão corretas. Ocasionalmente, uma falha de autenticação no nível do gateway é reportada incorretamente como 502 em vez de 407 (Proxy Authentication Required) por certas configurações de middleware.

3. Verifique incompatibilidades de protocolo

Certifique-se de estar usando o protocolo correto (HTTP, HTTPS ou SOCKS5). Enviar tráfego HTTPS por uma porta de proxy somente HTTP sem o tunelamento CONNECT adequado costuma disparar um erro 502, já que o proxy não consegue interpretar o fluxo de dados criptografado.

Correções práticas para erros 502

Depois de diagnosticar que o erro provavelmente está relacionado à interação proxy-destino, implemente as seguintes soluções técnicas.

Implementando uma lógica de retry robusta

Como muitos erros 502 são transitórios — causados por uma instabilidade momentânea de rede ou por um nó de saída específico falhando —, a solução mais eficaz é um mecanismo inteligente de retry. Não repita a requisição imediatamente; use uma estratégia de backoff exponencial.

import requests
from urllib3.util import Retry
from requests.adapters import HTTPAdapter

def fetch_url_with_retry(url, proxy_url):
    session = requests.Session()
    # Define a estratégia de retry: repetir em 502, 503, 504
    retries = Retry(
        total=5,
        backoff_factor=1,
        status_forcelist=[502, 503, 504],
        raise_on_status=False
    )

    proxies = {
        "http": proxy_url,
        "https": proxy_url
    }

    session.mount("http://", HTTPAdapter(max_retries=retries))
    session.mount("https://", HTTPAdapter(max_retries=retries))

    try:
        response = session.get(url, proxies=proxies, timeout=10)
        return response
    except Exception as e:
        print(f"Request failed: {e}")
        return None

# Exemplo de uso com GProxy
proxy = "http://username:[email protected]:8000"
result = fetch_url_with_retry("https://api.targetsite.com/data", proxy)

Ajustando as configurações de rotação do proxy

Se você usa um pool de proxies rotativos e encontra 502 com frequência, a frequência de rotação pode estar alta demais, ou você pode estar caindo em nós "zumbis". Provedores de alta qualidade como o GProxy minimizam isso, mas você pode mitigar ainda mais:

• Aumentando a persistência de sessão: use "sticky sessions" para manter o mesmo IP por alguns minutos. Isso evita o custo de negociar novas conexões o tempo todo.
• Filtrando por região: às vezes os 502 estão localizados em regiões geográficas específicas onde o CDN do site de destino está com problemas. Mude as configurações do GProxy para outro país ou cidade.

Otimizando os cabeçalhos das requisições

Servidores de destino frequentemente retornam 502 quando os cabeçalhos enviados pelo proxy estão incompletos ou parecem suspeitos. Garanta que sua requisição pareça vinda de um navegador legítimo. Um erro comum é usar o User-Agent padrão "python-requests", que muitos WAFs bloqueiam derrubando a conexão, resultando em um 502 no nível do proxy.

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.5",
    "Accept-Encoding": "gzip, deflate, br",
    "Connection": "keep-alive",
    "Upgrade-Insecure-Requests": "1"
}

Configuração avançada do lado do servidor

Se você roda seu próprio servidor proxy (por exemplo, usando Nginx ou Squid como forward proxy) e vê erros 502, o problema provavelmente está na configuração interna. Para quem usa Nginx, as configurações padrão de buffer e timeout costumam ser restritivas demais para cadeias de proxy complexas.

Buffers e timeouts de proxy no Nginx

Quando o Nginx atua como proxy e a resposta do upstream é grande demais para os buffers alocados, ele pode truncar a resposta e devolver um 502. Aumente esses valores no seu nginx.conf:

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;

O proxy_read_timeout é especialmente crítico. Se o site de destino leva 30 segundos para gerar uma resposta, mas seu proxy está configurado com timeout de 10 segundos, o proxy fecha a conexão e devolve um 502 ao cliente.

Escolhendo o tipo de proxy certo para evitar 502

O tipo de proxy que você usa impacta significativamente a frequência dos erros 502. Proxies de datacenter são mais rápidos, mas também mais fáceis de detectar e bloquear pelos sites de destino, o que leva a resets de conexão e 502. Proxies residenciais, como os oferecidos pelo GProxy, usam IPs reais atribuídos por ISP, o que torna muito menos provável disparar as respostas agressivas de WAF que causam erros de gateway.

O GProxy utiliza uma camada de roteamento inteligente que detecta automaticamente quando um nó de saída está retornando 502. Em muitos casos, nossa infraestrutura repete a requisição de forma transparente por outro nó antes mesmo que o erro chegue à sua aplicação, entregando uma taxa de sucesso bem maior em tarefas de scraping de alto volume.

Comparação: resiliência de datacenter vs. residencial

• Proxies de datacenter: alta velocidade, mas alta "taxa de queima". Assim que uma sub-rede é sinalizada, os erros 502 e 403 se tornam constantes.
• Proxies residenciais: melhor reputação. Mesmo que um IP encontre um 502 (talvez o roteador do usuário doméstico tenha reiniciado), o pool imenso permite uma troca imediata e bem-sucedida.
• Proxies móveis: os mais resilientes. IPs móveis são compartilhados por milhares de usuários; os sites hesitam muito em bloquear ou derrubar conexões vindas desses IPs, o que praticamente elimina os 502 causados por bloqueio baseado em IP.

Principais conclusões

O erro 502 Bad Gateway é sinal de uma falha de comunicação entre o proxy e o destino. Por mais frustrante que seja, geralmente ele é resolvível com mudanças de configuração e boas práticas de código.

• Identifique a origem: determine se o erro é universal (site de destino fora do ar) ou específico do proxy (IP bloqueado ou morto).
• Implemente retries: use backoff exponencial e filtragem por código de status no seu código para tratar 502 transitórios automaticamente.
• Confira seus cabeçalhos: garanta que suas requisições imitem o comportamento de um navegador real para não serem derrubadas pelos firewalls de destino.
• Aproveite uma infraestrutura de qualidade: use os pools residencial ou móvel do GProxy para reduzir a chance de cair em nós bloqueados que disparam erros de gateway.

Dica prática 1: monitore sempre a frequência dos 502. Um pico repentino normalmente indica que seu padrão de scraping foi detectado e está na hora de rotacionar o User-Agent ou reduzir a taxa de requisições.

Dica prática 2: se você usa um proxy back-connect, tente trocar de porta. Muitas vezes portas diferentes roteiam por nós de entrada diferentes, o que pode contornar um problema de 502 localizado na rede do provedor.