Erro de proxy 407, 502, 504 e tunnel failed: diagnóstico passo a passo para iniciantes

Introdução: o que você vai aprender neste guia

Se você trabalha com proxies móveis, mais cedo ou mais tarde vai ver no log do seu parser, no console do navegador antidetect ou direto na janela da conta de anúncios uma linha como «407 Proxy Authentication Required», «502 Bad Gateway», «504 Gateway Timeout» ou o curto e assustador «tunnel failed». Um erro de servidor proxy nesse momento parece uma caixa preta: não dá para saber se a culpa é do próprio proxy, do seu software, do site de destino ou apenas de uma senha desatualizada. Este guia transforma a caixa preta em um esquema de ações compreensível.

Deliberadamente limitamos o tema: analisamos apenas os códigos e mensagens que a camada de proxy retorna. Os timeouts de rede no nível da conexão (quando não há resposta alguma e o próprio cliente interrompe a espera) são tratados em outro artigo do blog, e aqui não os repetimos. Se no seu log está exatamente um código ou a frase sobre túnel, você está no lugar certo.

O que você vai obter no final

• Vai entender o que significa cada um dos quatro erros e em que ponto exato da cadeia «seu software — proxy — site de destino» ele nasce.
• Vai aprender a identificar a origem do problema em dois ou três minutos usando o curl, utilitário presente em qualquer sistema.
• Vai receber sequências prontas de ações para 407, 502, 504 e tunnel failed, que podem ser executadas como um checklist.
• Vai configurar seu software para reagir corretamente a cada código: alguns erros devem ser repetidos, outros não fazem sentido repetir.
• Vai montar um diário pessoal de incidentes que vai economizar horas no próximo problema.

Para quem é este guia

O guia foi escrito para profissionais de marketing, afiliados, donos de pequenas equipes e desenvolvedores que usam proxies móveis, mas não precisam ser engenheiros de redes. A parte principal é voltada para iniciantes: cada comando é explicado, cada ação é detalhada. Para quem escreve os próprios scripts e quer ir mais fundo, há um bloco avançado separado no final.

O que você precisa saber de antemão

Basta saber abrir o terminal ou o prompt de comando, copiar texto nele e ler o resultado. Entender o que é um endereço IP e uma porta ajuda, mas vamos relembrar isso rapidamente. Não é necessário ter experiência em programação.

Quanto tempo vai levar

A leitura completa e o primeiro diagnóstico levam de 60 a 120 minutos. Se você tem um erro específico acontecendo agora, vá direto ao passo correspondente: cada erro individual leva de 15 a 25 minutos, incluindo as verificações.

Preparação prévia: ferramentas e acessos

O diagnóstico de erros da camada de proxy não exige instalar programas pesados. Quase tudo já está no seu sistema operacional. Mesmo assim, vale a pena se preparar com antecedência, para não ficar procurando senhas nem lembrando onde está o arquivo de configuração na hora do problema.

Ferramentas necessárias

1. Terminal ou prompt de comando. No Windows 10 e 11, abra o menu «Iniciar», digite «cmd» ou «PowerShell» e pressione Enter. No macOS, abra «Aplicativos», depois «Utilitários» e depois «Terminal». No Linux, o terminal normalmente abre com Ctrl+Alt+T.
2. O utilitário curl. Ele vem integrado ao Windows a partir da versão 10 (build 1803), ao macOS e à maioria das distribuições Linux. Confira: digite no terminal curl --version e pressione Enter. Deve aparecer uma linha com o número da versão, como «curl 8.x.x». Se em vez disso aparecer que o comando não foi encontrado, instale o curl pelo gerenciador de pacotes do seu sistema.
3. Um navegador comum com ferramentas de desenvolvedor. Qualquer navegador moderno serve, desde que a tecla F12 abra um painel com a aba «Network» (Rede).
4. Um editor de texto para manter o diário de incidentes. Um Bloco de Notas resolve, mas algo com realce de sintaxe é mais prático para enxergar a estrutura dos logs.
5. Seu software de trabalho: navegador antidetect, parser, gerenciador de contas de anúncios ou seu próprio script. Vamos precisar de acesso às configurações de proxy e aos logs dele.

Acessos necessários

• Login no painel do provedor de proxy. Para usuários da mobileproxy.space, é a página de gerenciamento dos seus canais, onde aparecem host, porta, login, senha, tipo de autenticação e o link para trocar de IP.
• Credenciais atualizadas de pelo menos um proxy: endereço (host), porta, login e senha ou IP confirmado para autenticação por endereço.
• Entender qual protocolo você usa: proxy HTTP(S) ou SOCKS5. Essa informação também aparece no painel.

Requisitos de sistema

Qualquer sistema operacional lançado nos últimos oito anos. Conexão de internet que alcance o host do proxy. Nada mais é necessário.

Backups

Antes de mudar as configurações de proxy no seu software de trabalho, salve o estado atual. Isso leva cinco minutos e evita a situação em que você «consertou» o erro e ao mesmo tempo perdeu a configuração funcional de dez contas.

1. No navegador antidetect, exporte a lista de perfis junto com as configurações de proxy. Normalmente a função de exportação fica no menu de perfis e gera um arquivo CSV ou JSON.
2. No parser ou script, copie o arquivo de configuração para uma pasta separada com a data no nome, por exemplo «config_backup_2026-03-14».
3. No painel, copie para um arquivo de texto as credenciais de todos os canais. Guarde esse arquivo onde ninguém de fora tenha acesso.
4. Anote qual é o IP do seu computador ou servidor agora. Você vai precisar dele se usar autenticação por IP.

Dica: crie um arquivo de texto «Diário do proxy» e registre nele cada erro no formato «data, hora, código, host do proxy, site de destino, o que fiz, o que resolveu». Em um mês você terá uma base de conhecimento pessoal mais útil que qualquer artigo.

Verificação: o terminal abre, o comando curl mostra a versão, você entrou no painel e vê as credenciais de pelo menos um proxy, os backups dos arquivos de configuração estão numa pasta separada. Pode seguir adiante.

Conceitos básicos: como funciona a camada de proxy e de onde vêm os códigos

Para corrigir um erro de servidor proxy com consciência, e não por tentativa e erro, é preciso visualizar o caminho da requisição. Ele tem três trechos, e cada um dos nossos quatro erros mora em um trecho diferente.

Os três trechos do caminho da requisição

• Cliente — proxy. Seu navegador, parser ou script se conecta ao host e à porta do proxy. Nesse trecho é verificada a autenticação. Aqui nasce o erro 407 e parte dos casos de tunnel failed.
• Proxy — rede móvel — site de destino. O servidor proxy, ao receber sua requisição, abre em nome próprio uma conexão pelo modem com o chip da operadora até o site desejado. Aqui surgem o 502 e o 504.
• Site de destino — caminho de volta. A resposta do site volta pelos mesmos nós. Se o site devolveu um código próprio, como 403 ou 429, isso já não é erro da camada de proxy, e é importante aprender a distingui-los.

Classes de códigos em linguagem simples

O código de resposta é um número de três dígitos que o servidor envia na primeira linha da resposta. O primeiro dígito indica a classe. Os códigos 4xx significam «problema do seu lado, corrija a requisição». Os códigos 5xx significam «problema do lado do servidor ou atrás dele». Para a camada de proxy funciona assim:

• 407 Proxy Authentication Required — o proxy diz: «Não sei quem você é, ou seus dados estão errados». Classe 4xx: precisa corrigir do seu lado.
• 502 Bad Gateway — o proxy diz: «Tentei chegar mais adiante, mas recebi uma queda ou lixo no lugar da resposta». Classe 5xx: o problema está atrás do proxy ou no próprio proxy.
• 504 Gateway Timeout — o proxy diz: «Esperei a resposta do próximo nó pelo tempo previsto e não recebi». Também é 5xx.

Diferença entre o código 504 e um timeout de rede

Essa é a distinção-chave de todo o artigo. Quando você vê o código 504, significa que o servidor proxy está vivo, aceitou sua requisição, esperou ele mesmo a resposta do site e te informou da falha. A conexão entre você e o proxy funcionou perfeitamente. Já quando o seu cliente escreve «connection timed out» ou «operation timed out» sem código, significa que não houve resposta alguma, e a interrupção foi iniciada pelo seu software. O primeiro caso é o tema deste guia. O segundo é outro assunto, tratado em materiais relacionados do blog. Um sinal simples: se há um número de três dígitos na resposta, continue lendo aqui.

O que é um túnel e por que ele «cai»

Quando você abre um site por HTTPS através de um proxy HTTP, o navegador primeiro envia ao proxy o comando especial CONNECT com o endereço e a porta de destino. O proxy abre a conexão com o site e responde «200 Connection established». Depois disso, o fluxo criptografado passa pelo proxy, que já não consegue lê-lo. Essa conexão é chamada de túnel. Se, ao comando CONNECT, o proxy respondeu com algo diferente de 200, o cliente escreve «tunnel failed» e geralmente indica ao lado qual código veio. Ou seja, tunnel failed não é um erro independente, mas um embrulho em torno de um dos códigos.

Duas formas de autenticação

• Login e senha. O cliente os envia no cabeçalho Proxy-Authorization. É a forma mais comum e a fonte mais frequente de 407.
• Autenticação por IP. Você cadastra previamente no painel o endereço do seu computador ou servidor, e o proxy libera todas as requisições desse endereço sem senha. É prático, mas quebra quando seu IP muda.

Cabeçalhos de serviço que revelam o autor da resposta

O proxy costuma adicionar às suas respostas os cabeçalhos Via, Proxy-Agent ou X-Proxy. Os sites de destino não os colocam. Se na resposta com código 502 existe um cabeçalho Proxy-Agent, você sabe com certeza que o proxy respondeu. Se não há esses cabeçalhos, mas existe um Server com o nome do servidor web do site, é resposta do próprio site. Vamos usar bastante esse sinal.

Dica: memorize a regra mnemônica: «quatro, olhe do seu lado; cinco, olhe atrás do proxy; túnel, veja qual número está ao lado». Ela resolve metade dos casos sem precisar ler mais nada.

Passo 1: Identificar quem exatamente retornou o erro

Objetivo da etapa: em poucos minutos, estabelecer com precisão se quem respondeu foi o servidor proxy, o site de destino ou o seu próprio software, e registrar o texto completo da resposta para o trabalho seguinte.

Instruções

1. Abra o painel e copie as credenciais do proxy com problema: host, porta, login, senha. Para o exemplo, vamos supor que o host é proxy.example.net, a porta é 8080, o login é user1 e a senha é pass1. Substitua pelos seus valores.
2. Abra o terminal.
3. Digite o comando, trocando as credenciais e o endereço de destino pelos seus, e pressione Enter: curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. A opção -v ativa a saída detalhada, a opção -x define o proxy.
4. Aguarde o término do comando. Normalmente leva de um a três segundos. Se o comando «travar» por mais de 30 segundos, pressione Ctrl+C: provavelmente é um timeout de rede, não um código, e não é o nosso caso.
5. Encontre na saída as linhas que começam com o sinal de «maior» (é o que o curl enviou) e com o sinal de «menor» (é o que veio na resposta). A primeira linha da resposta será algo como «HTTP/1.1 407 Proxy Authentication Required» ou «HTTP/1.1 200 Connection established».
6. Olhe para a linha com a palavra CONNECT. Se logo depois dela veio um código diferente de 200, o erro foi retornado pelo proxy na fase do túnel. Se o CONNECT recebeu 200 e o código de erro veio depois, após as linhas do handshake TLS, então quem respondeu foi o site de destino.
7. Encontre os cabeçalhos da resposta. A presença de Proxy-Agent, Via ou cabeçalhos de serviço semelhantes indica sem dúvida o proxy. O cabeçalho Server com o nome do servidor web e o cabeçalho Set-Cookie indicam o site de destino.
8. Repita o mesmo comando sem a opção -x, ou seja, direto: curl -v https://example.com/. Se o site responde 200 e através do proxy vem 5xx, o problema está localizado no trecho atrás do proxy.
9. Repita o comando através do proxy, mas para outro site, por exemplo qualquer recurso grande e estável. Se o segundo site abre, o problema está ligado a um destino específico, e não ao proxy como um todo.
10. Copie toda a saída para o diário do proxy junto com data e hora. Você vai precisar dela nos próximos passos.

Caminho alternativo pelo navegador

Se não for prático trabalhar no terminal, abra o navegador com o proxy configurado, pressione F12, vá até a aba «Network», marque a caixa «Preserve log» (Preservar log) e recarregue a página. Na lista de requisições, encontre a linha com o código vermelho, clique nela e, na aba «Headers», examine o bloco «Response Headers». A lógica é a mesma: procure os cabeçalhos de serviço do proxy. A desvantagem é que o navegador costuma ocultar detalhes da fase CONNECT, então, para tunnel failed, o terminal é preferível.

Atenção: o comando com a opção -v exibe login e senha do proxy em texto aberto. Não cole essa saída em chats públicos, tickets de suporte e capturas de tela sem substituir a senha por asteriscos.

Dica: adicione ao comando a opção -sS junto com -o e a indicação de um dispositivo vazio, para não poluir a tela com o corpo da resposta: curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. No Windows, em vez de /dev/null, use NUL.

Resultado esperado

No diário apareceu um registro com a resposta completa, e você consegue dizer com segurança uma das três coisas: «quem respondeu foi o proxy na fase de autenticação», «quem respondeu foi o proxy na fase de acesso ao site» ou «quem respondeu foi o próprio site». Isso direciona você ao passo 2, 3-4 ou para fora deste artigo.

Possíveis problemas

• O comando diz «Could not resolve proxy». Erro de digitação no host. Confira com o painel, caractere por caractere.
• O comando diz «Failed to connect to proxy». Porta fechada ou incorreta. É um problema de transporte, não um código, verifique a porta e tente outro canal.
• A saída para na linha do TLS sem código. Significa que o túnel foi estabelecido, mas o site não respondeu no tempo definido pelo seu cliente. Não confunda com 504: se não há código, não é o nosso caso.

Verificação: você consegue nomear o autor da resposta e o código exato ou a frase, e a linha da saída do curl está salva no diário.

Passo 2: Resolver o erro 407 Proxy Authentication Required

Objetivo da etapa: fazer com que, ao comando CONNECT, o proxy responda «200 Connection established» em vez de 407, e entender a causa para que o erro não volte.

Por que o 407 acontece

O proxy não aceitou suas credenciais. Normalmente há seis causas, e vamos verificá-las em ordem crescente de complexidade: erro de digitação, caracteres especiais na senha, mudança do seu IP quando a autenticação é por endereço, validade do canal expirada, o software não envia os dados de jeito nenhum, cache de dados antigos no navegador.

Instruções

1. Abra o painel e encontre o canal com problema. Confirme que a validade dele não expirou e que o status está ativo. Se a validade acabou, renove e repita a requisição depois de um minuto; nesse caso, não precisa seguir adiante.
2. Verifique qual tipo de autenticação está ativada para o canal: login e senha ou por endereço IP. Muitos painéis permitem ativar os dois ao mesmo tempo.
3. Se a autenticação por IP estiver ativada, descubra o endereço externo atual do seu computador ou servidor. Abra no navegador, sem proxy, qualquer serviço que mostre seu IP e compare com o endereço cadastrado no painel. Provedores domésticos e operadoras móveis costumam trocar o endereço após reiniciar o roteador. Se os endereços divergirem, atualize no painel e aguarde um ou dois minutos: as mudanças não se aplicam instantaneamente.
4. Se você usa login e senha, copie-os novamente do painel, sem digitar à mão. Cole no comando curl do passo 1 e execute. Metade dos casos de 407 termina aqui.
5. Olhe a senha. Se houver os caracteres @, :, /, #, ?, % ou espaço, na transmissão dentro da string de endereço eles precisam ser codificados. O @ vira %40, os dois-pontos viram %3A, a cerquilha vira %23, o sinal de porcentagem vira %25. Por exemplo, a senha p@ss:1 na URL fica p%40ss%3A1. Para não codificar, passe os dados em uma opção separada: curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Aqui o curl resolve os caracteres sozinho.
6. Se o curl passa, mas seu software continua recebendo 407, o problema está no próprio software. Abra as configurações de proxy dele. Confira se login e senha estão em campos separados, e não colados ao endereço, caso o programa não espere isso. Verifique se não há um espaço no fim da senha: ele costuma aparecer ao copiar e colar.
7. No navegador antidetect, abra as configurações do perfil específico, e não as globais. Muitos usuários mudam a senha na lista geral de proxies, mas o perfil continua guardando uma cópia antiga. Salve novamente o proxy no perfil e reinicie o perfil.
8. Se o navegador memorizou os dados antigos e não pede os novos, limpe as senhas salvas para esse host nas configurações do navegador ou crie um perfil novo para testar.
9. Preste atenção no cabeçalho Proxy-Authenticate da resposta 407. Se ali está escrito «Basic», o proxy espera um par comum de login e senha. Se indica outro esquema, seu software precisa suportá-lo; para proxies móveis quase sempre se usa Basic, e a divergência significa erro na configuração do tipo de proxy.
10. Repita a requisição curl e confirme que agora o CONNECT recebe 200.

Atenção: não tente «resolver» o 407 repetindo requisições em massa. Alguns servidores proxy bloqueiam temporariamente o endereço após uma série de autenticações incorretas, e você ganha um problema extra em cima do original. Uma verificação, uma correção, uma verificação.

Dica: se você tem várias dezenas de canais, guarde-os em uma tabela, com login e senha em colunas separadas e, ao lado, uma coluna com a senha já codificada para URL. Assim você nunca vai trocar qual versão vai em cada lugar.

Resultado esperado

Na saída do curl, a linha de resposta ao CONNECT virou «HTTP/1.1 200 Connection established», o site entregou conteúdo. No software de trabalho, as requisições passam. No diário está registrada a causa: erro de digitação, codificação, mudança de IP, validade expirada ou cache.

Possíveis problemas

• O código 407 vem duas vezes: primeiro no CONNECT, depois dentro do túnel. Isso indica que o software envia os dados só em uma das fases. Atualize o programa ou ative nele a opção de enviar autenticação no CONNECT.
• O painel diz que o IP foi adicionado, mas o 407 continua. Você provavelmente trabalha através de uma rede corporativa ou servidor com vários endereços de saída. Verifique o endereço exatamente na máquina de onde saem as requisições.
• Funciona com você, não funciona com o colega usando os mesmos dados. Com autenticação por IP isso é esperado: o colega tem outro endereço. Mude para login e senha ou adicione um segundo IP.

Verificação: três requisições seguidas pelo curl e pelo software de trabalho passaram sem 407, e a causa está registrada no diário.

Passo 3: Entender o erro 502 Bad Gateway do proxy

Objetivo da etapa: distinguir uma falha momentânea no instante da troca de IP de um problema persistente com o destino ou o canal, e escolher a reação correta para cada caso.

Por que o proxy retorna 502

O proxy aceitou sua requisição, tentou abrir uma conexão adiante e recebeu uma queda, uma recusa ou uma resposta ilegível. Para proxies móveis, as causas típicas são estas: o modem estava trocando de endereço IP ou se registrando de novo na rede da operadora naquele momento; o site de destino derrubou a conexão; do lado do proxy não foi possível resolver o nome de domínio do site; o canal está sobrecarregado com um número excessivo de fluxos simultâneos; o site está indisponível para todos.

Instruções

1. Registre a hora exata em que o 502 apareceu, com segundos. Isso importa para o próximo item.
2. Abra no painel o histórico de troca de IP desse canal ou lembre se você ativou a rotação automática por horário. Se a rotação ocorreu nos mesmos segundos do erro, você lidou com um comportamento normal: durante a troca de endereço, as requisições recebem 502 por dois a dez segundos. A solução é repetir a requisição depois de uma pausa.
3. Aguarde dez segundos e repita o comando curl do passo 1. Se a resposta virou 200, registre no diário «502 no momento da rotação» e siga para a configuração de repetições no item 6.
4. Se o 502 se repete de forma persistente, teste outro site pelo mesmo proxy. Se abriu, o problema está no destino. Se não abriu, o problema está no canal.
5. Para o problema de destino: abra o site de destino direto, sem proxy. Se ele também estiver indisponível direto ou retornar 5xx, o proxy não tem culpa: o site está fora do ar. Se direto tudo funciona, o site provavelmente está derrubando conexões dos endereços dessa operadora. Troque o IP pelo link do painel e repita. Se não resolveu, tente um canal de outra operadora ou região.
6. Para o problema de canal: verifique no painel o status do equipamento. Muitos provedores têm um indicador de estado do modem. Status vermelho ou amarelo significa que o canal está se recuperando, e só resta esperar ou migrar para um backup.
7. Verifique a carga. Veja no seu software quantos fluxos simultâneos vão por esse canal. O canal móvel tem capacidade limitada e, com dezenas de conexões paralelas, o proxy começa a recusar parte das requisições exatamente com 502. Reduza o paralelismo pela metade e repita o teste.
8. Verifique se o problema é de DNS. Faça uma requisição ao site pelo endereço IP em vez do domínio, se o site permitir, ou mude para o esquema socks5h, no qual os nomes são resolvidos pelo proxy, e compare o resultado. Se por nome dá 502 e por IP funciona, o problema está na resolução de nomes do lado do proxy; informe ao provedor o nome exato do domínio.
9. Se nada funcionou em 15 minutos, reúna a saída do curl -v, o horário, o host do canal, o domínio de destino e envie ao suporte do provedor. Informação bem reunida encurta a solução de um dia para uma hora.

Dica: ao trabalhar com rotação por horário, sincronize as pausas do software com o intervalo de troca de IP. Se o endereço muda a cada 5 minutos, deixe o parser fazer uma pausa de 15 segundos no início de cada bloco de cinco minutos. O número de 502 cai quase a zero sem uma única linha de código complexo.

Resultado esperado

Você sabe exatamente a qual categoria pertence seu 502: momento da rotação, destino específico, sobrecarga do canal, falha de equipamento ou site indisponível. Para as três primeiras você tem correção, para as duas últimas, a compreensão de quanto esperar e a quem escrever.

Possíveis problemas

• O 502 só aparece em arquivos grandes. O site fecha a conexão por causa da velocidade lenta de envio. Reduza o tamanho dos dados solicitados ou use um canal com melhor cobertura.
• O 502 vem do site, não do proxy. Verifique os cabeçalhos: se houver o Server do site e não houver Proxy-Agent, é uma falha interna do site, repita mais tarde.
• O 502 alterna com 200 sem lógica aparente. Sinal clássico de sobrecarga do canal. Reduza o paralelismo até obter resultado estável.

Verificação: dez requisições seguidas, com pausa de dois segundos, pelo canal problemático para um site estável retornam 200, ou você tem em mãos um ticket no suporte com todos os dados.

Passo 4: Lidar com o código 504 Gateway Timeout

Objetivo da etapa: entender em que trecho atrás do proxy o tempo se perde e reduzir a proporção de 504 a um nível aceitável, sem confundir o código com um timeout de rede do cliente.

O que exatamente significa o 504 do proxy

O servidor proxy tem um limite interno de espera pela resposta do site. Quando o site não responde dentro desse limite, o proxy encerra a espera e informa honestamente pelo código 504. Seu cliente, nesse caso, não derrubou a conexão, a resposta chegou. Por isso é importante que o limite de espera do seu software seja maior que o do proxy: caso contrário, você vai ver um timeout de rede sem código e não conseguirá entender o que está acontecendo.

Instruções

1. Verifique o limite de espera no seu software. Na maioria dos programas, ele se chama timeout, «tempo de espera da resposta» ou «Read timeout». Se for menor que 30 segundos, coloque 60 temporariamente. É um passo de diagnóstico: você precisa esperar justamente o código do proxy.
2. Meça o tempo até a resposta através do proxy. Execute: curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. A opção -w exibe quatro números: o código, o tempo até a conexão, o tempo até o primeiro byte e o tempo total em segundos.
3. Execute o mesmo comando sem a opção -x. Compare o tempo até o primeiro byte. Se direto o site responde em 0,4 segundo e através do proxy em 8 segundos, o atraso no trecho «proxy — site» é grande, e o 504 vai aparecer a qualquer oscilação da rede móvel.
4. Verifique em qual requisição o 504 aparece. Faça uma requisição com o método HEAD, que não baixa o corpo da página: curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Se o HEAD passa e o GET da página dá 504, o problema está no tamanho ou na geração lenta da página, e não na conexão em si.
5. Troque o IP do canal pelo link do painel. A rede móvel não é homogênea: um endereço pode sair por uma estação-base sobrecarregada e outro por uma livre. Repita a medição. Se o tempo caiu várias vezes, adicione ao software uma regra: em caso de 504, primeiro trocar o IP, depois repetir a requisição.
6. Verifique o peso da página de destino. Alguns sites só entregam a resposta após operações longas no servidor. Se seu objetivo são dados específicos, tente acessar um endereço mais leve do mesmo site: uma API, a versão móvel, uma página sem parâmetros de ordenação.
7. Se o 504 só aparece em um domínio específico e apenas por canais de uma operadora, registre isso no diário e redistribua o trabalho com esse domínio para canais de outra operadora.
8. Volte o limite de espera do software ao valor de trabalho, mas agora com consciência: ele deve ser um pouco maior que o tempo típico de resposta pelo proxy e menor que o tempo que você está disposto a esperar dentro da tarefa. Para a maioria dos cenários, são 30-45 segundos.

Atenção: não coloque o limite de espera do software em vários minutos «por via das dúvidas» nem o deixe assim para sempre. Um fluxo travado vai bloquear uma vaga na fila, e uma dezena de fluxos travados cria a ilusão de que o proxy não funciona, quando o problema está em um site lento.

Dica: adicione ao log do seu software uma coluna «tempo até o primeiro byte». Por ela dá para ver se o canal degrada gradualmente ou cai de repente. O crescimento gradual indica sobrecarga ou cobertura ruim, a queda brusca costuma indicar rotação ou falha da operadora.

Resultado esperado

Você conhece o tempo típico de resposta por cada canal, definiu no software um limite maior que o do proxy, e os 504 viraram um evento raro, para o qual existe uma reação automática configurada.

Possíveis problemas

• Você aumentou o limite e, em vez de 504, começou a receber timeout de rede. Significa que o proxy espera mais do que você imaginava, ou que a conexão com o próprio proxy está instável. Isso já está fora dos códigos, veja os materiais relacionados sobre timeouts.
• 504 apenas em determinados horários. Pico de carga noturno nas redes móveis. Transfira as tarefas pesadas para a noite ou a manhã.
• 504 na primeira requisição a um site novo, depois tudo rápido. Resolução inicial de nome e estabelecimento de conexão do lado do proxy. Adicione uma requisição de aquecimento antes da série principal.

Verificação: uma série de vinte requisições a um site de trabalho mostra o tempo até o primeiro byte dentro de uma faixa previsível e não mais que um ou dois 504, e o software, ao receber 504, troca de IP e repete a requisição.

Passo 5: Corrigir o erro tunnel failed

Objetivo da etapa: aprender a ler o número ao lado da frase tunnel failed, associá-lo à causa real e corrigir as configurações de protocolo, porta e tipo de proxy.

Como aparece e o que significa

No curl, a mensagem aparece assim: «CONNECT tunnel failed, response 407». Em navegadores e soluções antidetect, podem ser as frases «Proxy tunnel failed», «Unable to establish tunnel» ou «Tunnel connection failed». O ponto em comum é um só: o cliente enviou o comando CONNECT e o proxy respondeu algo diferente de 200. O número ao lado é exatamente aquele código, e trabalhar com ele se resume aos passos anteriores mais alguns casos especiais que só aparecem na fase do túnel.

Instruções

1. Execute o curl com a opção -v para um endereço HTTPS e encontre a linha com tunnel failed. Anote o número depois da palavra response.
2. Se for 407, volte ao passo 2. A diferença é só uma: confirme que o software envia a autenticação justamente na fase CONNECT. Em versões antigas de alguns programas, a caixa «Autenticação de proxy» só funciona para requisições HTTP, e o túnel sai sem senha.
3. Se for 502 ou 504, volte aos passos 3 e 4. O proxy não conseguiu abrir conexão com a porta 443 do site ou não esperou por ele.
4. Se for 403, o proxy recusou abrir o túnel para a porta ou o host indicado. Verifique a qual porta você está se conectando. Proxies móveis geralmente permitem túneis para 443 e algumas portas comuns. Se o seu serviço escuta em uma porta não padrão, confirme no painel ou com o provedor se ela é permitida.
5. Se for 400, o proxy não entendeu o comando. A causa mais comum é você ter indicado um proxy SOCKS5 como HTTP ou vice-versa. Abra o painel e veja qual protocolo e porta foram fornecidos. Em muitos provedores, HTTP e SOCKS5 usam portas diferentes do mesmo canal.
6. Corrija o esquema no comando. Para SOCKS5 use: curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. A letra h em socks5h significa que os nomes de domínio são resolvidos pelo proxy, e não pelo seu computador. Para proxies móveis, essa é a opção preferível.
7. Se você está no navegador antidetect, abra as configurações de proxy do perfil e encontre a lista suspensa de tipo: HTTP, HTTPS, SOCKS5. Escolha o que está indicado no painel e confira a porta. Depois de salvar, reinicie o perfil por completo, e não apenas recarregue a aba.
8. Se o número ao lado de tunnel failed não aparece, e só há a frase, ative no software o log detalhado ou reproduza a situação pelo curl para obter o código.
9. Verifique se o seu software não está tentando estabelecer uma conexão TLS com o próprio proxy. Alguns programas, ao escolher o tipo «HTTPS», criptografam não só o tráfego até o site, mas também a conexão com o proxy. Se o proxy não suporta isso, você recebe tunnel failed ou um erro de handshake. Mude para o tipo «HTTP» na conexão com o proxy: o tráfego até o site continua criptografado dentro do túnel de qualquer forma.
10. Repita o teste e confirme que o CONNECT recebe 200 e a página carrega.

Dica: transforme duas requisições curtas de teste em parte da rotina diária: uma para um endereço via HTTP e outra para o mesmo endereço via HTTPS. Se a primeira passa e a segunda cai com tunnel failed, em um segundo você entende que o problema está no túnel, e não na autenticação ou no canal.

Resultado esperado

A frase tunnel failed desapareceu dos logs, para cada canal estão registrados o tipo e a porta corretos, e no software não há criptografia desnecessária na conexão com o proxy.

Possíveis problemas

• O túnel é estabelecido, mas depois há erro de certificado. Isso já não é a camada de proxy: é o site ou o conjunto de certificados do seu sistema. Verifique data e hora no computador.
• Funciona no curl, mas não funciona no software com os mesmos dados. O software aplica outro esquema ou adiciona seu próprio prefixo. Estude a documentação dele sobre o formato da string de proxy.
• tunnel failed só para um site. O site usa uma porta não padrão, volte ao item sobre 403.

Verificação: uma requisição HTTPS pelo curl e pelo software de trabalho retorna 200 no CONNECT, e o tipo e a porta de todos os canais estão registrados na tabela.

Passo 6: Configurar a reação correta do software a cada código

Objetivo da etapa: fazer com que os erros de servidor proxy sejam tratados automaticamente: uns repetidos com pausa, outros disparando alerta imediato, e você recebendo logs compreensíveis em vez de um fluxo de linhas vermelhas.

Princípio: nem todos os erros são iguais

Repetir a requisição em caso de 407 não faz sentido: a senha não vai ficar correta por repetição. Repetir em caso de 502 no momento da rotação é necessário: em cinco segundos tudo volta a funcionar. Repetir em caso de 504 é melhor depois de trocar o IP. Essas três regras formam a base de um tratamento saudável de erros.

Instruções para software pronto

1. Abra as configurações do parser ou do gerenciador de contas e encontre a seção responsável pelas repetições. Ela pode se chamar «Retries», «Tentativas repetidas», «Tratamento de erros».
2. Defina o número de repetições para 5xx em 3, e a pausa inicial entre elas em 5 segundos, dobrando a cada vez: 5, 10, 20 segundos. Esse crescimento das pausas se chama atraso exponencial e evita que seu software sobrecarregue ainda mais um canal já sobrecarregado.
3. Se o software permite definir uma lista de códigos para repetição, indique 502 e 504. Não inclua o 407.
4. Encontre a configuração de ação em caso de 407. Se não existir, coloque o número de repetições na seção geral no mínimo e ative a notificação de requisições malsucedidas. Seu objetivo é ver o 407 nos primeiros minutos, e não depois de um dia de parada.
5. Encontre o campo para o link de troca de IP, se houver. Cole ali o link do painel para o canal correspondente e ative a opção «Trocar IP em caso de erro» ou «Rotação em caso de falha».
6. Limite o número de fluxos simultâneos por canal móvel. Comece com 3-5 e aumente até que a proporção de 502 fique abaixo de um por cento.
7. Ative o log detalhado, com registro do código de resposta e dos cabeçalhos. Confirme que o log mostra a diferença entre o código do proxy e o código do site: muitos programas exibem isso em uma coluna separada «Proxy status».
8. Salve as configurações, reinicie o software e faça uma série de teste de 50 requisições.

Instruções para script próprio

Se você escreve código, a lógica é a mesma. Em pseudocódigo em Python com a biblioteca requests, fica assim:

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Preste atenção em três pontos. Primeiro: em caso de 407 saímos do laço imediatamente e enviamos a notificação. Segundo: em caso de 502 e 504 primeiro trocamos o IP, depois esperamos a pausa crescente. Terceiro: o valor de timeout foi escolhido para esperar o código do proxy, e não para interromper a conexão antes.

Atenção: em algumas bibliotecas, o erro na fase CONNECT chega não como uma resposta com código, mas como uma exceção com texto contendo tunnel failed e o número. Capture essas exceções separadamente e extraia o código do texto, senão sua lógica de repetição não vai funcionar.

Dica: calcule as proporções de códigos por canal por dia e exiba em uma tabela simples. O canal cujos 5xx estão consistentemente acima dos outros deve ser verificado primeiro, mesmo que formalmente esteja funcionando.

Resultado esperado

O software repete automaticamente as requisições em caso de 502 e 504, com pausa crescente e troca de IP, avisa imediatamente sobre 407, limita o número de fluxos e mantém um log com separação dos códigos de proxy e de site.

Possíveis problemas

• O software também repete o 407, e com isso o proxy bloqueia temporariamente o endereço. Desative as repetições para 4xx por completo ou reduza o número total de repetições para uma.
• Depois de ativar a rotação em caso de erro, o IP muda com frequência demais. Estabeleça um intervalo mínimo entre trocas, por exemplo 60 segundos, para que uma série de 502 não dispare cinco rotações seguidas.
• O log cresce até gigabytes. Grave os cabeçalhos apenas para respostas com códigos de erro e, para o 200, salve uma única linha.

Verificação: uma série de teste de 50 requisições terminou sem intervenção manual, no log aparecem repetições com pausas de 5, 10, 20 segundos para 5xx, e, ao inserir uma senha incorreta, o software parou e exibiu a notificação de 407.

Verificação do resultado: checklist e testes

Percorra a lista e marque cada item. Se pelo menos um não estiver cumprido, volte ao passo correspondente.

Checklist

• O comando curl com a opção -v executa, e você sabe encontrar na saída a linha de resposta ao CONNECT e os cabeçalhos de serviço do proxy.
• Para cada canal, a tabela registra host, porta, tipo de protocolo, forma de autenticação e senha codificada.
• Com autenticação por IP, o endereço atual da sua máquina coincide com o endereço no painel.
• Uma requisição HTTPS por cada canal recebe 200 no CONNECT.
• O tempo típico até o primeiro byte por cada canal foi medido, e o limite de espera no software o supera com folga.
• No software estão configuradas repetições apenas para 502 e 504, com pausas de 5, 10, 20 segundos e troca de IP antes da repetição.
• Em caso de 407, o software para e notifica.
• O número de fluxos por canal está limitado, e a proporção de 5xx na série de teste está abaixo de um por cento.
• O diário de incidentes é mantido e contém pelo menos um registro totalmente analisado.

Como testar

1. Insira deliberadamente uma senha incorreta e execute uma requisição. Esperado: 407 no curl e notificação no software, sem série de repetições.
2. Devolva a senha correta e execute 30 requisições a um site estável, com pausa de um segundo. Esperado: todas 200, ou no máximo um 5xx com repetição bem-sucedida.
3. Durante a série, clique no link de troca de IP no painel. Esperado: um ou dois 502 no log, depois repetição automática e continuação da série.
4. Indique nas configurações o tipo SOCKS5 para um canal fornecido como HTTP e faça a requisição. Esperado: tunnel failed ou erro de protocolo, que você reconhece em um segundo. Devolva o tipo correto.

Indicadores de sucesso

A proporção de erros da camada de proxy nas séries de trabalho não passa de um a dois por cento, cada erro é classificado pelo código, e nenhum exige intervenção manual, exceto o 407. O tempo de reação ao 407 é de minutos, e não de horas.

Erros típicos e soluções

Problema: 407 após cada reinício do roteador

Causa: autenticação por IP, e o provedor fornece endereço dinâmico.

Solução: mude para autenticação por login e senha ou ative as duas formas ao mesmo tempo. Se precisar mesmo do IP, contrate um endereço estático com o provedor.

Problema: a senha está correta, mas dá 407 no navegador, embora o curl passe

Causa: o navegador ou o perfil do navegador antidetect guardou dados antigos em cache.

Solução: salve novamente o proxy nas configurações do perfil específico e reinicie o perfil; se necessário, limpe as senhas salvas para o host do proxy.

Problema: 502 exatamente a cada N minutos

Causa: coincide com o intervalo da rotação automática de IP.

Solução: sincronize as pausas do software com o cronograma de rotação ou mude para a troca de IP por link, em momentos convenientes entre as tarefas.

Problema: 502 com muitos fluxos, com poucos tudo funciona

Causa: sobrecarga do canal móvel.

Solução: reduza o paralelismo para 3-5 fluxos por canal e distribua a carga entre vários canais.

Problema: 504 só em um site, os outros são rápidos

Causa: o site gera a página lentamente ou restringe endereços de operadoras móveis.

Solução: use endereços mais leves do site, troque o IP antes de repetir e, se o problema for persistente, transfira o trabalho com esse site para um canal de outra operadora.

Problema: em vez de 504, começou a chegar uma queda sem código

Causa: o limite de espera do software é menor que o limite interno do proxy.

Solução: aumente o limite no software para um valor que permita receber o código, normalmente 30-60 segundos.

Problema: tunnel failed, response 400

Causa: a porta SOCKS5 foi indicada como proxy HTTP, ou vice-versa.

Solução: confira tipo e porta com o painel; para SOCKS5 use o esquema socks5h, para HTTP use http.

Problema: tunnel failed, response 403 para uma porta não padrão

Causa: o proxy não permite túneis para essa porta.

Solução: confirme a lista de portas permitidas com o provedor e, se possível, reconfigura o serviço de destino para a porta 443.

Problema: o código 502 ou 504 vem com o cabeçalho Server do site

Causa: é resposta do próprio site, e não da camada de proxy: o site tem problemas com seus serviços internos.

Solução: espere e repita mais tarde; trocar de proxy não vai ajudar.

Recursos adicionais para usuários avançados

Se o diagnóstico básico já foi dominado, as técnicas a seguir tornam o trabalho com erros da camada de proxy quase automático.

Envio manual do cabeçalho de autorização

Às vezes é útil verificar como o proxy reage a um cabeçalho específico. Codifique o par login:senha em Base64 com qualquer ferramenta local e envie o cabeçalho você mesmo: curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. Esse método funciona para requisições HTTP comuns e ajuda a entender se o proxy aceita os dados em geral, independentemente de como o seu software os monta. Para CONNECT, use a opção --proxy-header em vez de -H.

Resolução de nomes do lado do proxy

O esquema socks5h e o túnel HTTP entregam o nome de domínio ao servidor proxy, em vez de resolvê-lo localmente. Isso traz duas vantagens: o site vê uma requisição saindo totalmente da rede móvel, e você se livra de divergências quando o seu DNS local entrega um endereço e a rede da operadora outro. Se você vê 502 apenas com resolução local, a migração para socks5h costuma resolver o problema sem precisar acionar o provedor.

Automação pela API do provedor

A mobileproxy.space tem uma interface programática para trocar IP e obter o status dos canais. Embute a chamada de troca de IP no tratador de 504, e a verificação de status do canal no tratador de 502 persistentes. Assim o script decide sozinho se repete a requisição pelo mesmo canal ou muda para um backup. Um algoritmo simples: três 502 seguidos em um minuto — consultar o status; se o canal estiver normal, trocar o IP; se não, marcar o canal como indisponível por cinco minutos e passar ao próximo.

Separação de métricas de proxy e de site

Crie no sistema de monitoramento duas métricas distintas: códigos que chegaram com cabeçalhos de proxy e códigos que chegaram sem eles. A primeira métrica fala da saúde da sua infraestrutura de proxy, a segunda, do comportamento dos sites de destino. Enquanto estiverem misturadas, você vai procurar erro de servidor proxy onde ele não existe, e vice-versa.

Pool de canais com pesos

Atribua a cada canal um peso, que diminui a cada 5xx e se recupera lentamente com o tempo. Distribua as requisições proporcionalmente aos pesos. Essa abordagem afasta automaticamente a carga de uma operadora ou região problemática e a devolve quando o canal se recupera, sem nenhuma troca manual.

Exportação de HAR do navegador

Para casos complexos no navegador antidetect, abra a aba Network, reproduza o erro e escolha «Save all as HAR». O arquivo contém todos os cabeçalhos de requisição e resposta, inclusive fases que não são visíveis no log comum do programa. Antes de enviar ao suporte, remova do arquivo os valores de Proxy-Authorization e os cookies.

Otimização dos limites de espera

Reúna estatísticas do tempo até o primeiro byte por canal e por destino ao longo de uma semana. Defina o limite de espera no software no nível do percentil 95 mais 10 segundos. Esse limite raramente interrompe requisições vivas e ao mesmo tempo libera rápido os fluxos em travamentos reais.

FAQ: perguntas frequentes sobre diagnóstico

Como entender se o 502 veio do proxy e não do site?

Olhe os cabeçalhos da resposta. Se houver Proxy-Agent, Via ou outros cabeçalhos de serviço do proxy e não houver Set-Cookie nem Server do site, a resposta é do proxy. Além disso: se o código veio logo em resposta ao CONNECT, é com certeza o proxy.

Vale a pena repetir a requisição em caso de 407?

Não. As credenciais não vão ficar corretas por repetição, e uma série de tentativas erradas pode levar a um bloqueio temporário do seu endereço do lado do proxy. Corrija os dados e repita uma vez.

Por que no curl tudo funciona, e no meu software não?

Na maioria das vezes, o software monta a string de proxy de outra forma, não codifica caracteres especiais da senha, aplica outro tipo de protocolo ou não envia a autenticação no CONNECT. Compare a string exata das configurações do software com o comando curl que funciona, caractere por caractere.

Como gravar corretamente uma senha com caracteres especiais?

Na string de endereço, codifique: @ como %40, : como %3A, # como %23, % como %25, espaço como %20. Nos campos separados de login e senha, digite a senha como ela é, sem codificação.

Qual a diferença entre 504 e o timeout sobre o qual outros artigos falam?

O 504 é um código que o proxy retornou ele mesmo, após esperar o próprio limite de resposta do site. O timeout sem código significa que a conexão foi interrompida pelo seu cliente, sem receber nada. São tratados de formas diferentes, e por isso estão separados em materiais distintos.

Quantos fluxos posso enviar por um canal móvel?

Não existe um número universal. Comece com 3-5 e aumente até que a proporção de 502 fique abaixo de um por cento. Para páginas pesadas o número será menor, para requisições leves de API, maior.

É preciso trocar de IP a cada erro?

Em caso de 504 e 502 persistentes, sim, é a primeira ação. Em caso de 407, não; a troca de IP não influencia a autenticação. Estabeleça um intervalo mínimo entre trocas, para que uma série de erros não cause uma avalanche de rotações.

O que enviar ao suporte para resolver a questão mais rápido?

A saída completa do curl -v com a senha substituída por asteriscos, o horário exato com segundos e fuso horário, o host e a porta do canal, o domínio de destino, o tipo de autenticação e o resultado de uma requisição direta, sem proxy. Com esse conjunto, o suporte costuma responder já na primeira mensagem.

Posso usar HTTPS para conectar ao próprio proxy?

Só se o provedor suportar isso explicitamente. Na maioria dos casos, para proxies móveis a conexão com o proxy é por HTTP comum ou SOCKS5, e a criptografia do tráfego até o site fica por conta do túnel. Ativar uma criptografia extra até o proxy gera tunnel failed ou erro de handshake.

Conclusão

Você percorreu o caminho de uma linha vermelha incompreensível no log até um sistema completo de diagnóstico. Agora você sabe identificar quem exatamente retornou a resposta, lê o 407 como sinal de verificar credenciais e forma de autenticação, o 502 como indício de falha atrás do proxy ou no momento da rotação, o 504 como relato honesto do proxy sobre um site lento, e o tunnel failed como um embrulho em torno de um desses códigos, com a dica no formato do número. Seu software não repete mais o que não faz sentido nem desiste no que é temporário.

O que fazer a seguir

1. Mantenha um diário de incidentes por pelo menos um mês. Em duas semanas você já vai notar padrões recorrentes e eliminar as causas deles.
2. Uma vez por semana, revise as proporções de códigos por canal e redistribua a carga.
3. Automatize a troca de IP e a verificação de status pela API do provedor, para que os 5xx rotineiros se resolvam sem você.
4. Estude os materiais relacionados do blog sobre timeouts de rede e sobre o comportamento dos sites de destino, para fechar os dois trechos restantes do caminho da requisição.

Para onde evoluir

O próximo nível é construir seu próprio pool de canais com pesos e monitoramento, no qual um erro de servidor proxy deixa de ser motivo de pânico e vira um ponto no gráfico que o sistema trata sozinho. Todas as ferramentas para isso você já tem: compreensão dos códigos, curl, painel do provedor e o hábito de registrar. Bom trabalho e muitos 200 estáveis.

Sobre o autor

Roman Melnikov

Technical Writer and System Administrator

Experiência profissional: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.

Formação: Bauman Moscow State Technical University. Information Systems and Technologies

Especialização:

Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting