Servidor proxy não responde: diagnóstico passo a passo de timeouts, portas e firewall

Introdução: o que você vai aprender com este guia

A situação é familiar para qualquer um que trabalha com proxy: ontem tudo voava, e hoje o navegador gira a roda de carregamento, o script de scraping trava na primeira requisição, o navegador antidetect diz que o servidor proxy não responde. Nenhuma mensagem clara, só espera e silêncio. A vontade é escrever para o suporte ou trocar de provedor, mas na maioria dos casos a causa está do seu lado e se resolve em dez minutos.

Este guia prático vai te ajudar a percorrer o caminho de "nada funciona" até "conexão estável" sem adivinhação. Vamos analisar os três vilões de rede mais comuns: timeouts, portas fechadas ou erradas e firewall. Você vai aprender a identificar onde exatamente a corrente se rompe entre o seu computador e o proxy, e vai receber um conjunto de comandos que mostram a origem do problema em um minuto.

Fronteira importante: aqui falamos apenas de causas de rede, quando a conexão não se estabelece de jeito nenhum ou trava. Situações em que o proxy responde, mas devolve um código de erro como 407 ou 502, são um assunto separado, e não vamos abordar isso. Se você vê um código HTTP específico na resposta, significa que o proxy está vivo, e o seu caso não é sobre este artigo.

Para quem é este guia

• Profissionais de marketing e SMM que gerenciam várias contas via proxy móvel e se depararam com o navegador não conectando.
• Afiliados cujas configurações pararam de funcionar de repente, e as contas de anúncios não abrem através do proxy.
• Desenvolvedores cujos scripts em Python, Node.js ou Go recebem timeout em vez de resposta.
• Donos de negócio que configuraram proxy para funcionários e querem entender por que funciona para um e não para outro.

O que você precisa saber antes

Praticamente nada de especial. Basta saber abrir o prompt de comando ou terminal, copiar comandos e ler o que eles mostram. Vamos explicar todos os termos ao longo do caminho. Se você nunca abriu o terminal, não se preocupe: cada ação está detalhada no nível de "pressione esta tecla, digite este texto".

Quanto tempo vai levar

O diagnóstico completo por todas as etapas leva de 30 a 60 minutos. Na maioria das vezes, o problema é encontrado na primeira ou segunda etapa, e aí você resolve em 10-15 minutos. O bloco avançado no final pode ser estudado separadamente, quando a conexão básica já estiver restaurada.

Preparação inicial: ferramentas e dados

Antes de começar, reúna tudo o que precisa em um só lugar. Isso economiza tempo e evita ficar pulando entre abas na hora mais inoportuna.

Dados do seu proxy

Abra o painel do provedor e anote em um arquivo de texto os seguintes parâmetros. Eles serão necessários em quase todas as etapas.

1. Endereço do servidor (host). É um nome de domínio como proxy.example.net ou um endereço IP como 185.10.20.30.
2. Porta para conexão HTTP. Em proxies móveis, costuma ser um número de cinco dígitos, por exemplo 30001 ou 51234.
3. Porta para SOCKS5, se o provedor fornecer separadamente. Às vezes difere da porta HTTP em uma unidade ou em alguns milhares.
4. Login e senha para autenticação, se você usa autenticação por credenciais.
5. Lista de IPs permitidos, se você tem autenticação por endereço IP ativada. Verifique qual endereço está lá.
6. Link para troca de IP e informações sobre o modo de rotação: por agendamento, por link ou a cada requisição.

Dica: salve esses dados não só no gerenciador de senhas, mas também em um arquivo de texto simples durante o diagnóstico. Você vai colar esses dados nos comandos dezenas de vezes, e ficar alternando entre janelas é cansativo.

Ferramentas que já existem no seu sistema

Boa notícia: quase tudo o que você precisa já vem embutido no sistema operacional. Não vai precisar comprar nada.

• Windows 10 e 11: PowerShell (encontre pela busca no menu Iniciar) e o prompt de comando cmd. No PowerShell há o comando Test-NetConnection, que substitui utilitários separados.
• macOS: aplicativo Terminal (Aplicativos, pasta Utilitários). Os utilitários nc e curl já estão instalados.
• Linux (Ubuntu, Debian, Fedora): qualquer terminal. Pode ser necessário instalar os pacotes curl, netcat e mtr pelo gerenciador de pacotes do seu sistema.

O que é bom instalar adicionalmente

1. curl para Windows. No Windows 10 versão 1803 e mais recentes, e também no Windows 11, o curl já vem. Verifique: abra o cmd e digite curl --version. Se aparecer o número da versão, está tudo certo.
2. Um segundo dispositivo para comparação: smartphone, segundo notebook ou máquina virtual. Não é um programa, mas uma ferramenta muito útil sobre a qual falaremos na primeira etapa.
3. Acesso às configurações do roteador: endereço do painel (na maioria das vezes 192.168.0.1 ou 192.168.1.1) e senha do administrador. Será necessário na quinta etapa.

Backups antes de começar

Vamos mexer nas configurações do firewall e, possivelmente, do roteador. Antes disso, faça duas coisas para sempre poder voltar ao estado original.

1. No Windows, crie um ponto de restauração: abra a busca, digite "Criar um ponto de restauração", clique em Criar e dê um nome claro, por exemplo "Antes da configuração de proxy".
2. Exporte as regras atuais do Firewall do Windows. Abra o PowerShell como administrador e execute o comando netsh advfirewall export "C:/firewall-backup.wfw". O arquivo aparecerá na raiz do disco C.
3. No painel do roteador, encontre uma seção como "Sistema", "Manutenção" ou "Backup" e salve o arquivo de configuração no computador.

Atenção: não desligue o firewall inteiro "por precaução" e não o deixe desligado. Durante o diagnóstico, vamos desativar a proteção no máximo por dois minutos para testar a hipótese, e depois voltar tudo e criar uma regra específica.

Conceitos básicos: o que acontece quando o proxy não responde

Para que o diagnóstico seja coerente e não uma tentativa aleatória, é importante entender como funciona a cadeia de conexão. Aí cada etapa do guia verifica um trecho específico dessa cadeia.

O caminho da requisição até o site

Quando você trabalha via proxy móvel, a requisição percorre este caminho. Primeiro, seu aplicativo (navegador, script, antidetect) envia dados ao sistema operacional. O sistema os passa pelo seu firewall e repassa ao roteador. O roteador entrega o tráfego ao seu provedor de internet. O provedor entrega os pacotes ao servidor proxy. O servidor proxy redireciona a requisição através de um modem móvel com chip SIM para a rede da operadora de celular. E só então a requisição segue para o site de destino. A resposta percorre o mesmo caminho na ordem inversa.

A interrupção pode ocorrer em qualquer um desses trechos. A frase "servidor proxy não responde" na verdade significa apenas uma coisa: a resposta não chegou ao seu aplicativo dentro do tempo previsto. Onde exatamente ela se perdeu é o que vamos descobrir.

Porta: a porta de entrada do servidor

Qualquer servidor tem um único endereço IP, mas várias portas, numeradas de 1 a 65535. Imagine um prédio com um único endereço e milhares de apartamentos. O serviço de proxy "mora" em um apartamento específico, ou seja, escuta uma porta específica. Se você bate em outra porta, ninguém abre, e você espera até o timeout expirar. E o servidor, mesmo assim, está totalmente funcional.

As portas podem estar abertas, fechadas ou filtradas. Porta aberta responde à tentativa de conexão com concordância. Porta fechada responde imediatamente com recusa, e você recebe um erro instantâneo como "connection refused". Porta filtrada fica em silêncio: seus pacotes são descartados no caminho, e você não recebe nada. É justamente a filtragem que dá o quadro clássico de travamento sem resposta, e o culpado nela é quase sempre algum firewall.

Timeout: quanto esperar antes de desistir

Timeout é o limite de espera, após o qual o aplicativo encerra a tentativa e reporta um erro. Existem vários tipos de timeout, e não vale a pena confundi-los.

• Timeout de conexão (connect timeout). Quanto esperar até o servidor concordar em estabelecer a conexão. Se ele expirou, significa que você não conseguiu chegar à porta do proxy.
• Timeout de leitura (read timeout). Quanto esperar por dados depois que a conexão foi estabelecida. Se ele expirou, significa que o proxy te aceitou, mas o site de destino ou a rede móvel responderam devagar demais.
• Timeout total da requisição. O limite superior para tudo junto.

Proxies móveis funcionam via rede celular, onde as latências são naturalmente maiores do que as de datacenters. Se o seu software está configurado com timeout de 5 segundos, ele pode cair em um proxy móvel perfeitamente funcional só porque a resposta chegou no sexto segundo.

Firewall: o filtro que decide o que passar

Firewall é um programa ou dispositivo que examina pacotes de rede e decide se os deixa passar ou descarta. Na sua cadeia, pode haver três ou quatro firewalls: o embutido no Windows ou macOS, o do antivírus, o do roteador e o do administrador corporativo. Qualquer um deles é capaz de descartar silenciosamente pacotes em uma porta não padronizada, e você verá apenas um travamento.

Autenticação por IP: um firewall invisível do lado do proxy

Muitos provedores de proxy móvel têm um modo em que, em vez de login e senha, usa-se uma lista de IPs permitidos. O servidor aceita conexões apenas de endereços da lista, e pode simplesmente ignorar outras tentativas. Se o seu IP residencial mudou (isso acontece ao reiniciar o roteador na maioria dos provedores), o proxy deixa de te reconhecer. Externamente, isso parece exatamente o mesmo que uma porta bloqueada.

Agora que o quadro está claro, vamos à prática. Cada etapa seguinte verifica um trecho da cadeia e ou tira a suspeita dele ou encontra o culpado.

Etapa 1: Determinamos onde a conexão se rompe

Objetivo da etapa: em cinco minutos, entender se o problema está do seu lado, do lado da rede ou do lado do proxy. Esta é a etapa mais importante, porque elimina metade das causas possíveis de imediato.

Verificamos a internet sem proxy

1. Abra o navegador e, nas configurações, desative temporariamente o proxy. No Chrome, é Configurações, seção Sistema, item "Abrir as configurações de proxy do computador". No navegador antidetect, crie um perfil sem proxy ou escolha o modo "Sem proxy" nas configurações do perfil.
2. Abra qualquer site grande, por exemplo a página de um buscador. Ela deve carregar em um ou dois segundos.
3. Se o site não abrir nem sem proxy, o problema não é o proxy. Reinicie o roteador, verifique o cabo ou Wi-Fi e volte a este guia depois.

Verificamos o proxy de outro dispositivo

1. Pegue um smartphone e desligue o Wi-Fi dele, para que funcione via internet móvel. Assim você estará em uma rede completamente diferente, sem passar pelo seu roteador e provedor.
2. Instale no celular qualquer navegador com suporte a proxy ou use as configurações do sistema: no Android, nas propriedades do ponto de acesso, isso é feito via APN, mas é mais simples instalar um aplicativo de navegador com entrada manual de proxy.
3. Digite o endereço, a porta, o login e a senha do seu proxy e abra qualquer site que mostre seu endereço IP.
4. Se o proxy funcionar pelo celular, significa que o proxy está vivo e o problema está entre o seu computador e a internet: firewall, roteador ou configurações do software. Vá para as etapas 2, 3, 4 e 5.
5. Se pelo celular também não funcionar, o problema está ou no próprio proxy, ou nas configurações de autenticação dele. Passe para a etapa 6 e depois para o suporte.

Dica: se não tiver um segundo dispositivo, tente conectar o computador ao ponto de acesso móvel do celular. Trocar de rede dá o mesmo efeito que testar de outro dispositivo.

Verificamos o status do proxy no painel

1. Faça login no painel do provedor de proxy móvel.
2. Encontre o cartão do seu proxy e veja o indicador de status. Na maioria dos serviços, ele mostra se o modem está online e quando foi a última atividade.
3. Se o indicador mostrar que o proxy está desligado ou o modem está offline, não precisa mais diagnosticar: a causa está no equipamento, e quem resolve é o suporte.

Verificação: ao final desta etapa, você deve ter a resposta para uma pergunta: o proxy funciona pelo menos de algum lugar ou não funciona de lugar nenhum. Anote essa conclusão. Ela define quais etapas serão as principais daqui para frente.

Possíveis problemas nesta etapa

Às vezes o proxy funciona pelo celular e para de funcionar um minuto depois. Isso pode ser a rotação de IP no proxy ou a instabilidade da rede celular do modem. Repita a verificação duas ou três vezes com intervalo de um minuto, para não tirar conclusões falsas de uma única tentativa.

Etapa 2: Verificamos o endereço e a porta do proxy

Objetivo da etapa: garantir que a porta do proxy está aberta e acessível justamente do seu computador. Esta é a verificação-chave: se a porta não responde, todo o resto é inútil.

Por que o ping não serve

O primeiro pensamento de muitos: pingar o servidor. Mas o ping verifica apenas a disponibilidade do endereço IP pelo protocolo ICMP, e não a abertura de uma porta específica. Muitos servidores proxy nem respondem a ping por questões de segurança. Então, um ping bem-sucedido não garante nada, e um ping malsucedido não significa nada. Precisamos verificar especificamente a porta TCP.

Verificação da porta no Windows

1. Pressione a tecla Windows, digite PowerShell e abra-o.
2. Digite o comando, substituindo pelo seu endereço e porta:

   Test-NetConnection -ComputerName proxy.example.net -Port 30001

3. Pressione Enter e aguarde. O comando pode demorar até 20 segundos.
4. Encontre na saída a linha TcpTestSucceeded. O valor True significa que a porta está aberta e aceitando conexões. O valor False significa que não foi possível chegar à porta.
5. Preste atenção na linha PingSucceeded. Se for False, mas TcpTestSucceeded for True, está tudo certo: o servidor simplesmente não responde a ping.

Verificação da porta no macOS e Linux

1. Abra o Terminal.
2. Digite o comando:

   nc -zv proxy.example.net 30001

3. A opção -z diz ao utilitário para não enviar dados, apenas verificar a conexão. A opção -v ativa a saída detalhada.
4. Uma resposta como succeeded ou Connection to ... port 30001 succeeded! significa sucesso. A resposta Connection refused significa que a porta está fechada, e o servidor recusou imediatamente. Se o comando ficar travado sem resposta e depois mostrar timed out, a porta está sendo filtrada em algum ponto do caminho.

Verificação via curl em qualquer sistema

O curl não apenas verifica a porta, mas já faz uma requisição através do proxy. Este é o próximo nível de verificação.

1. Digite o comando, substituindo pelos seus dados:

   curl -x http://login:password@proxy.example.net:30001 --connect-timeout 15 -v https://api.ipify.org

2. A opção -x define o proxy. A opção -v mostra todas as etapas da conexão. A opção --connect-timeout limita a espera pelo estabelecimento da conexão a 15 segundos.
3. Leia a saída de cima para baixo. A linha Connected to proxy.example.net significa que a porta está aberta. A linha CONNECT api.ipify.org:443 mostra que o curl pediu ao proxy para estabelecer um túnel. Se depois disso veio a resposta 200 e no final você vê um endereço IP, o proxy está funcionando completamente.
4. Se a saída parou na linha Trying 185.10.20.30:30001... e depois de 15 segundos apareceu Connection timed out, a porta está inacessível do seu computador.

Dica: se a senha tiver caracteres especiais como @ ou #, o curl pode interpretar o endereço errado. Use a opção separada -U para as credenciais: curl -x http://proxy.example.net:30001 -U login:password ... Assim a senha não se mistura com o endereço.

Verificamos o protocolo e a porta SOCKS5

Erro comum: indicar a porta HTTP onde o software espera SOCKS5, ou vice-versa. A conexão até se estabelece, mas os dados não passam, e o aplicativo pode dar timeout.

1. Verifique no painel do provedor quais portas foram fornecidas para HTTP e para SOCKS5.
2. Faça a verificação via curl com o protocolo SOCKS5:

   curl -x socks5://login:password@proxy.example.net:30002 --connect-timeout 15 https://api.ipify.org

3. Certifique-se de que no seu aplicativo está selecionado o mesmo protocolo que funcionou no comando curl.

Verificação: após esta etapa, você sabe com certeza uma de três coisas: a porta está aberta e o proxy responde via curl (então o problema está nas configurações do seu aplicativo, vá para a etapa 3); a porta está aberta, mas a requisição via proxy trava (problema de autenticação ou do lado do proxy, etapa 6); a porta não responde (problema no firewall ou na rede, etapas 4 e 5).

Possíveis problemas nesta etapa

Se o Test-NetConnection der erro de resolução de nome, significa que o computador não consegue converter o nome de domínio em endereço IP. Tente substituir o nome pelo endereço IP do painel. Se funcionar com o IP e não com o nome, você tem um problema de DNS: troque o servidor DNS nas configurações do adaptador de rede por um público e repita.

Etapa 3: Lidamos com os timeouts no seu software

Objetivo da etapa: garantir que o aplicativo dá ao proxy móvel tempo suficiente para responder, e aprender a diferenciar timeout de conexão de timeout de leitura.

Medimos o tempo real de resposta

1. Execute o comando curl com saída de timing:

   curl -x http://login:password@proxy.example.net:30001 -o /dev/null -s -w "connect: %{time_connect}s total: %{time_total}s" https://api.ipify.org

   No Windows, use NUL em vez de /dev/null.
2. O valor connect mostra em quanto tempo a conexão TCP com o proxy foi estabelecida. Normal para proxies móveis: de 0,05 a 0,5 segundo.
3. O valor total mostra o tempo da requisição inteira. Para proxies móveis, é normal ver de 1 a 4 segundos, e nos horários de pico da rede celular, até 6-8 segundos.
4. Repita o comando cinco vezes e anote a variação. Se o connect é consistentemente baixo, mas o total às vezes salta para 10 segundos, seu software precisa estar preparado para essas latências.

Configuramos os timeouts nas ferramentas populares

Python e a biblioteca requests

O parâmetro timeout aceita uma tupla de dois valores: timeout de conexão e timeout de leitura. Valores recomendados para proxies móveis: 10 segundos para conexão e 30 segundos para leitura.

proxies = {"http": "http://login:password@proxy.example.net:30001", "https": "http://login:password@proxy.example.net:30001"}
response = requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

Se você indica um único número, por exemplo timeout=5, ele se aplica a ambos os timeouts, e isso é uma causa frequente de mensagens falsas de que o servidor proxy não responde.

Node.js e axios

No axios, o parâmetro timeout é único e geral. Defina-o em não menos que 30000 milissegundos. Para proxy, use um agente, por exemplo do pacote https-proxy-agent, e passe-o no parâmetro httpsAgent.

Navegadores antidetect

1. Abra as configurações do perfil, seção de proxy.
2. Encontre o botão de verificação de conexão. Ele existe em praticamente todos os antidetects modernos.
3. Preste atenção em quanto tempo o resultado chega. Se a verificação demora mais de 10 segundos e termina em falha, mas o curl funciona, procure nas configurações gerais do navegador o parâmetro de timeout do proxy e aumente-o.
4. Certifique-se de que no campo de protocolo está selecionado exatamente HTTP ou SOCKS5 de acordo com a porta que passou na verificação da etapa 2.

Ferramentas de scraping e automação

No Scrapy, quem responde é o parâmetro DOWNLOAD_TIMEOUT, por padrão 180 segundos, e raramente é problema. No Puppeteer e Playwright, o timeout de navegação por padrão é 30 segundos, mas ao trabalhar através de uma rede celular lenta, páginas pesadas podem não dar conta: aumente para 60 segundos através do parâmetro timeout no método goto.

Dica: não coloque timeouts muito grandes. 30-60 segundos para leitura é um limite razoável. Se colocar 300 segundos, seu script vai ficar horas travado em conexões mortas, em vez de repetir a requisição rapidamente.

Diferenciamos timeout de conexão de timeout de leitura

Isso é importante, porque eles se tratam de formas diferentes.

• Timeout de conexão no curl aparece como "Connection timed out after 15001 milliseconds" logo após a linha Trying. No Python requests, é a exceção ConnectTimeout. Tratamento: etapas 4, 5 e 6, porque você não chegou à porta.
• Timeout de leitura no curl aparece como "Operation timed out after 30000 milliseconds with 0 bytes received" já depois da linha Connected. No Python, é o ReadTimeout. Tratamento: aumentar o timeout de leitura, verificar se não está havendo rotação de IP no proxy naquele momento, e garantir que o site de destino está acessível.

Verificação: após esta etapa, o tempo de resposta do proxy via curl cabe nos timeouts do seu aplicativo com folga de pelo menos o dobro. Se o curl responde em 3 segundos, no software deve estar configurado não menos que 10 segundos para leitura.

Etapa 4: Verificamos o firewall e o antivírus no seu dispositivo

Objetivo da etapa: garantir que o software de proteção no computador não está bloqueando conexões de saída para a porta do proxy, e, se necessário, criar uma regra de permissão específica.

Teste rápido: desativação temporária

Antes de mexer nas regras, vamos testar a hipótese da forma mais simples. Desligamos a proteção por um minuto, repetimos a verificação da porta, ligamos de volta.

1. No Windows, abra a busca, digite "Firewall do Windows Defender" e abra-o.
2. À esquerda, clique em "Ativar ou desativar o Firewall do Windows Defender".
3. Para o perfil de rede ativo no momento (geralmente Privada ou Pública), selecione "Desativar" e clique em OK.
4. Imediatamente execute o Test-NetConnection da etapa 2.
5. Volte o botão para "Ativar" imediatamente e clique em OK.

Atenção: não trabalhe com o firewall desligado mais do que o necessário para uma verificação. Um comando leva segundos, e um sistema aberto na rede é um risco real. Se você esquecer de ligar de volta, o Windows vai avisar com uma notificação, mas é melhor não contar com isso.

Se com o firewall desligado a porta ficou acessível, o culpado foi encontrado. Se não, verificamos o antivírus da mesma forma: na maioria dos produtos há um item "Pausar proteção por 5 minutos" no menu de contexto do ícone na bandeja. Repita a verificação da porta e reative a proteção.

Criamos uma regra de permissão no Firewall do Windows

Não se pode desligar o firewall para sempre. Em vez disso, criaremos uma regra que permite especificamente ao seu aplicativo conexões de saída.

1. Abra o "Firewall do Windows Defender" e, à esquerda, clique em "Configurações avançadas". Abrirá uma janela com configurações avançadas.
2. Na coluna da esquerda, selecione "Regras de saída".
3. Na coluna da direita, clique em "Nova Regra".
4. Escolha o tipo "Programa" e clique em Avançar.
5. Escolha "Caminho do programa" e, pelo botão Procurar, indique o executável do seu aplicativo: navegador, antidetect ou interpretador Python. Clique em Avançar.
6. Escolha "Permitir a conexão" e clique em Avançar.
7. Marque os três perfis: Domínio, Particular, Público. Clique em Avançar.
8. Dê à regra um nome claro, por exemplo "Permitir proxy para navegador antidetect", e clique em Concluir.

Alternativa, se houver muitos aplicativos: criar uma regra do tipo "Porta", escolher o protocolo TCP, indicar a porta remota específica do proxy e permiti-la para todos os programas. Para isso, no quarto passo, escolha "Personalizada", na seção "Protocolo e Portas" indique TCP e no campo "Porta remota" digite o número da porta do proxy.

Verificamos se não há uma regra de bloqueio

Às vezes o problema não é a ausência de permissão, mas a presença de um bloqueio criado pelo antivírus ou por uma política corporativa.

1. Na mesma janela de configurações avançadas, abra "Regras de saída".
2. Clique no cabeçalho da coluna "Ação" para ordenar a lista. As regras com ação "Bloquear" ficarão juntas.
3. Revise-as. Se vir uma regra bloqueando seu aplicativo ou um intervalo de portas no qual a porta do proxy se encaixa, clique com o botão direito e escolha "Desativar Regra".
4. Repita a verificação da porta.

Firewall no macOS

1. Abra Ajustes do Sistema, seção Rede, depois Firewall.
2. Se o firewall estiver ativado, clique em Opções.
3. Certifique-se de que seu aplicativo na lista tem o status "Permitir conexões de entrada". Embora estejamos interessados nas de saída, alguns aplicativos abrem uma porta local para trabalhar com proxy.
4. Desmarque a opção "Bloquear todas as conexões de entrada", se estiver marcada, e repita a verificação.

Verifique separadamente utilitários de terceiros como Little Snitch ou LuLu: eles controlam justamente o tráfego de saída e podem ter registrado sua recusa a um pedido de permissão no passado. Encontre seu aplicativo na lista de regras deles e permita conexões para o endereço do proxy.

Firewall no Linux

1. Verifique o status do ufw com o comando sudo ufw status verbose. Preste atenção na linha Default: se para outgoing estiver deny, as conexões de saída são bloqueadas por padrão.
2. Permita conexão de saída para a porta do proxy:

   sudo ufw allow out to 185.10.20.30 port 30001 proto tcp

3. Se usar iptables diretamente, veja as regras com o comando sudo iptables -L OUTPUT -n -v e encontre linhas com DROP ou REJECT nas quais seu tráfego se encaixa.
4. Em servidores com Docker, lembre-se de que os contêineres usam um subsistema de rede separado. Verifique a acessibilidade da porta de dentro do contêiner, não apenas do host.

Dica: anote a hora exata em que você alterou as regras do firewall. Se algo quebrar em uma semana, você vai lembrar rapidamente qual alteração pode ter sido a causa e reverter usando o arquivo exportado na preparação.

Verificação: após esta etapa, o Test-NetConnection ou nc mostram conexão bem-sucedida com o firewall ligado e o antivírus ativo. Se a porta ainda estiver inacessível, e com a proteção desligada também não abriu, o problema está mais acima, no nível do roteador ou da rede. Vá para a etapa 5.

Etapa 5: Verificamos o roteador, a rede corporativa e o provedor

Objetivo da etapa: descobrir se o equipamento entre o computador e o servidor proxy está descartando seu tráfego, e, se necessário, corrigir as configurações do roteador ou trocar de rede.

Vemos onde exatamente os pacotes se perdem

O utilitário de rastreamento mostra a lista de nós pelos quais os pacotes passam até o servidor. Se os pacotes chegam a algum nó e depois desaparecem, você vê de quem é o nó: seu roteador, o provedor ou algo adiante.

1. No Windows, abra o cmd e execute tracert 185.10.20.30, substituindo pelo IP do proxy.
2. No macOS, execute traceroute 185.10.20.30. No Linux, é melhor usar mtr -n 185.10.20.30: ele mostra estatísticas em tempo real e perdas em cada nó.
3. A primeira linha é o seu roteador. A segunda e a terceira, geralmente, são equipamentos do provedor. Depois, nós de backbone e, no final, o servidor proxy.
4. Se a resposta vem de todos os nós, exceto o último, isso é normal: servidores proxy frequentemente não respondem a essas requisições. Olhe as perdas no meio do caminho.
5. Se os asteriscos começam logo depois do primeiro nó, seu roteador ou provedor não está deixando o tráfego passar para este endereço.

Lembre-se: o rastreamento usa ICMP ou UDP, e não TCP na porta desejada, então ele mostra a disponibilidade geral da rota, e não a abertura da porta. É uma ferramenta complementar, e não substitui a verificação da etapa 2.

Verificamos o roteador

1. Abra o navegador e digite na barra de endereços o endereço do roteador, geralmente 192.168.0.1 ou 192.168.1.1. O login e a senha estão na etiqueta embaixo do aparelho, se você não os mudou.
2. Encontre uma seção com nome como "Segurança", "Firewall", "Filtragem" ou "Controle dos pais".
3. Veja se há filtragem por portas ou por URL ativada. Alguns roteadores têm perfis predefinidos como "Nível alto de proteção", que bloqueiam tudo, exceto as portas 80 e 443. Mude para o nível padrão.
4. Verifique a seção "Controle de acesso" ou "Agendamento": pode haver uma regra limitando a internet do seu dispositivo em determinados horários.
5. Encontre a configuração SPI Firewall ou "Proteção contra DoS". Às vezes, uma proteção agressiva demais interpreta muitas conexões paralelas para um mesmo endereço como ataque e começa a cortá-las. Se você tem dezenas de threads de scraping, tente desativar temporariamente essa proteção e repetir a verificação.
6. Salve as alterações e, se necessário, reinicie o roteador.

Atenção: não altere configurações do roteador cujo propósito você não entende, especialmente nas seções WAN e DHCP. Um erro ali deixa a casa ou o escritório inteiro sem internet. Se estiver em dúvida, faça um backup da configuração, como descrito na preparação, e altere apenas um parâmetro por vez.

Verificamos o MTU

MTU é o tamanho máximo de um pacote de dados. Se estiver configurado incorretamente, requisições pequenas passam, mas respostas grandes se perdem. O sintoma é característico: a conexão com o proxy se estabelece, páginas pequenas abrem, e as grandes travam.

1. No Windows, execute no cmd: ping -f -l 1472 8.8.8.8. Se os pacotes passarem, o MTU 1500 está certo. Se aparecer "é necessário fragmentar", reduza o número de 10 em 10 até passar.
2. Encontre no roteador a configuração MTU (geralmente na seção WAN ou Internet) e defina o valor encontrado mais 28.
3. Valores típicos: 1500 para conexão a cabo comum, 1492 para PPPoE, 1400-1450 para alguns canais móveis e satélite.

Rede corporativa e Wi-Fi público

Se você trabalha em escritório, coworking ou hotel, entre você e a internet quase certamente há um gateway corporativo com firewall próprio. Esses gateways muito frequentemente permitem apenas as portas 80 e 443 e cortam todo o resto. A porta de cinco dígitos do proxy móvel simplesmente não passa.

1. Conecte-se ao ponto de acesso móvel do celular e repita a verificação da porta. Se funcionar, o culpado é o gateway corporativo.
2. Procure o administrador de sistemas com um pedido específico: permitir conexões TCP de saída para tal IP e tal porta. Quanto mais preciso o pedido, mais rápido será atendido.
3. Pergunte ao provedor de proxy se há possibilidade de obter uma porta da faixa padrão, por exemplo 443 ou 8080. Em muitos serviços isso é configurável.

Provedor residencial

Provedores residenciais raramente bloqueiam portas de saída, mas alguns cortam faixas conhecidas, associadas a torrents ou servidores de e-mail. Se, depois de todas as verificações, a porta não responde da rede residencial, mas responde pela internet móvel, ligue para o suporte do provedor e pergunte diretamente se eles filtram conexões de saída para a porta indicada.

Dica: salve a saída do rastreamento e da verificação de porta da sua rede e da rede móvel em um único arquivo. Quando for escrever para o provedor ou administrador, anexe os dois resultados. Isso reduz o diálogo de uma semana para um dia.

Verificação: a porta do proxy está acessível da sua rede pelo comando da etapa 2, o rastreamento não mostra perdas nos nós do provedor, e o ping com a opção -f passa no tamanho 1472. Se as três condições forem atendidas, e o proxy ainda não responder, o problema está nas configurações dele. Vamos para a etapa 6.

Etapa 6: Verificamos as configurações do lado do proxy

Objetivo da etapa: garantir que o servidor proxy aceita justamente você: seu IP está na lista de permissões, o modem está online, a rotação não coincide com suas requisições, e o limite de conexões não foi excedido.

Verificamos a autenticação por IP

Esta é a causa mais comum quando o proxy funciona pelo celular, mas não funciona pelo computador, ou funcionava ontem e hoje não.

1. Descubra seu IP externo atual. Abra sem proxy qualquer site que mostre IP, ou execute curl https://api.ipify.org no terminal.
2. Abra o painel do provedor de proxy, seção de configurações de autenticação.
3. Compare o endereço da lista de permissões com o seu atual. Se forem diferentes, aí está a causa: seu provedor atribuiu um novo endereço após reiniciar o roteador ou por agendamento.
4. Atualize o endereço na lista de permissões ou mude para autenticação por login e senha. A segunda opção é mais confiável, se seu IP externo muda.
5. Espere um ou dois minutos: as configurações no servidor proxy não são aplicadas instantaneamente.
6. Repita a verificação via curl da etapa 2.

Dica: se você trabalha de casa com IP dinâmico, a autenticação por login e senha vai livrar você desse problema para sempre. A lista de permissões é prática para servidores com endereço estático, e não para computadores residenciais.

Verificamos o estado do modem e a rotação

1. No painel, encontre informações sobre o IP atual do proxy e a hora da última troca.
2. Se você tem rotação automática a cada poucos minutos, preste atenção: no momento da troca de IP, o modem se reconecta à rede celular, e por 5-20 segundos o proxy realmente não responde. Isso é comportamento normal, e não defeito.
3. Se suas requisições pegam timeout regularmente justamente no momento da rotação, aumente o intervalo de rotação ou mude para troca de IP por link, para controlar o momento da reconexão você mesmo.
4. Tente forçar a troca de IP pelo link do painel. Se depois da troca o proxy voltar a funcionar, o problema era naquele IP específico ou em uma conexão travada do modem.

Verificamos o limite de conexões simultâneas

Proxies móveis têm um limite de conexões paralelas de uma mesma porta. Se seu scraper abriu cem threads e o limite é cinquenta, as conexões excedentes vão ficar na fila e cair por timeout.

1. Confirme o limite na descrição do plano ou no painel.
2. Feche todos os aplicativos que usam proxy e faça uma requisição única via curl. Se a requisição única passa, mas sob carga começam os timeouts, você está batendo no limite.
3. Reduza o número de threads nas configurações do scraper ou antidetect para um valor abaixo do limite. Para proxies móveis, um início razoável: 5-10 conexões paralelas por porta.

Verificamos fusos horários e rede celular

O modem do proxy está fisicamente em uma cidade específica e conectado a uma operadora específica. Nos horários de pico da noite, quando as redes celulares estão sobrecarregadas, as latências crescem várias vezes. Se os timeouts aparecem só das 19h às 23h no fuso da região do proxy, é a rede celular, e não sua configuração. Solução: aumentar os timeouts nesse horário ou distribuir a carga para outros horários.

Verificação: seu IP atual coincide com a lista de permissões ou é usada autenticação por senha, o modem no painel mostra status "online", a requisição única via curl passa, e o número de threads no software não excede o limite. Se tudo isso foi feito, e o servidor proxy não responde, é hora de escrever para o suporte do provedor anexando os resultados de todas as seis etapas.

Verificação do resultado: checklist de conexão estável

Você passou por todas as etapas. Agora vamos garantir que o resultado foi alcançado não por acaso e não por um minuto. Percorra o checklist e marque cada item.

Checklist

• Test-NetConnection ou nc mostram conexão TCP bem-sucedida com a porta do proxy com o firewall e o antivírus ativos.
• O curl via proxy retorna o endereço IP da operadora móvel em não mais que 5 segundos em cinco tentativas seguidas.
• O timeout de conexão no seu software é de pelo menos 10 segundos, e o timeout de leitura, de pelo menos 30 segundos.
• O protocolo no aplicativo (HTTP ou SOCKS5) coincide com a porta que passou na verificação via curl.
• No firewall foi criada uma regra de permissão específica, e não desativada a proteção inteira.
• Seu IP externo coincide com a lista de permissões ou é usada autenticação por senha.
• O número de conexões paralelas no aplicativo é menor que o limite do plano.
• Backups das configurações do firewall e do roteador foram salvos para eventual reversão.

Teste de carga

Uma requisição única é uma coisa, mas o trabalho real são dezenas de requisições seguidas. Vamos fazer um teste curto.

1. Execute no terminal um ciclo de 20 requisições. No macOS e Linux:

   for i in $(seq 1 20); do curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -w "%{http_code} %{time_total}\n" https://api.ipify.org; done

   No PowerShell, use o ciclo 1..20 | ForEach-Object com o mesmo comando curl dentro.
2. Na saída você verá 20 linhas com o código de resposta e o tempo. Todos os códigos devem ser 200, e o tempo não deve exceder 5-6 segundos.
3. Se uma ou duas requisições de vinte demoraram mais, isso é aceitável em rede móvel. Se a cada três requisições uma cai em timeout, volte à etapa 6 e verifique o limite de conexões e a rotação.

Teste no aplicativo real

1. Abra o perfil do navegador antidetect com o proxy configurado e clique em verificar conexão. O resultado deve chegar em 2-4 segundos e mostrar o IP da operadora móvel.
2. Abra uma página pesada, por exemplo o feed de uma rede social. Ela deve carregar completamente em 10-15 segundos.
3. Deixe a aba aberta por 10 minutos e atualize a página. Se ela carregou, a conexão sobrevive a pausas e não cai por inatividade.
4. Para scripts: rode uma tarefa de trabalho com 50-100 requisições e veja a porcentagem de sucesso. Meta de sucesso: não menos que 95 por cento sem repetições.

Indicadores de execução bem-sucedida: a porta está acessível, o tempo de resposta é previsível, o aplicativo não reclama de timeouts durante 30 minutos de trabalho, e você sabe exatamente qual das seis etapas foi a causa do problema. Esta última informação é especialmente valiosa: da próxima vez, você começará o diagnóstico justamente por ela.

Erros típicos e suas soluções

Aqui estão reunidas as situações que os usuários de proxy móvel encontram com mais frequência. Formato: o que você vê, por que acontece, o que fazer.

O proxy funciona pelo celular, mas não pelo computador

Causa: o firewall ou antivírus no computador bloqueia a conexão de saída para uma porta não padronizada, ou o seu IP residencial não coincide com a lista de permissões, e o celular se autentica de outra forma.

Solução: faça o teste rápido com o firewall desligado da etapa 4. Se não ajudar, confira o IP externo do computador com a lista de permissões seguindo as instruções da etapa 6.

A conexão se estabelece, mas a página não carrega

Causa: você indicou a porta HTTP onde o aplicativo espera SOCKS5, ou vice-versa. A conexão abre, mas o aplicativo e o proxy falam línguas diferentes, e os dados não passam.

Solução: verifique os dois protocolos via curl com as opções http:// e socks5:// e defina no aplicativo o que funcionou.

Funcionou uma semana, depois parou sem mudanças do seu lado

Causa: o IP externo do seu provedor de internet mudou, e no painel do proxy está configurada autenticação por IP. Segunda possibilidade: uma atualização do antivírus adicionou uma nova regra de bloqueio.

Solução: atualize a lista de permissões ou mude para autenticação por senha. Verifique a lista de regras de bloqueio no firewall seguindo as instruções da etapa 4.

Timeouts só à noite

Causa: sobrecarga da rede celular na região onde está o modem do proxy. É uma característica da internet móvel, e não um defeito.

Solução: aumente o timeout de leitura para 45-60 segundos nos horários noturnos, adicione repetições de requisições e, se possível, transfira tarefas pesadas para a manhã.

A cada dez requisições, uma cai por timeout

Causa: coincidência das requisições com o momento da rotação automática de IP, ou excesso do limite de conexões paralelas.

Solução: mude a rotação para troca por link e chame-a entre lotes de requisições. Reduza o número de threads para 5-10.

No escritório não funciona, em casa funciona

Causa: o gateway corporativo só deixa passar as portas 80 e 443.

Solução: solicite ao administrador permissão para o IP e a porta específicos, ou obtenha com o provedor de proxy uma porta da faixa padrão.

O Test-NetConnection mostra True, mas o navegador continua travado

Causa: a porta está aberta, mas no navegador está configurada outra porta, outro endereço, ou há uma exceção no sistema que faz o tráfego passar fora do proxy. Também é possível que uma extensão de proxy conflite com as configurações do sistema.

Solução: confira caractere por caractere o endereço e a porta no navegador com o que você testou no comando. Desative todas as extensões relacionadas a proxy e configure o proxy de uma única forma.

Páginas pequenas abrem, as grandes travam

Causa: MTU incorreto no roteador ou no provedor. Pacotes grandes não passam.

Solução: descubra o MTU com o comando ping com a opção -f da etapa 5 e configure-o no roteador.

Recursos adicionais para usuários avançados

Se a conexão básica foi restaurada e você quer mais controle, esta seção é para você. Aqui estão ferramentas e abordagens que transformam um diagnóstico pontual em monitoramento contínuo.

Olhamos os pacotes: Wireshark e tcpdump

Quando os comandos das etapas principais não dão uma resposta inequívoca, dá para olhar o tráfego de rede diretamente.

1. No Linux ou macOS, execute:

   sudo tcpdump -i any host 185.10.20.30 and port 30001 -nn

   No Windows, instale o Wireshark e no filtro de exibição digite ip.addr == 185.10.20.30 and tcp.port == 30001.
2. Inicie a verificação de porta da etapa 2 e observe os pacotes capturados.
3. Se você vê pacotes de saída com a flag SYN, mas não há SYN-ACK de resposta, seus pacotes saem, mas a resposta não volta. O bloqueio está em algum lugar fora do computador.
4. Se não há pacotes SYN, o firewall local os descarta antes mesmo de saírem para a rede.
5. Se a resposta traz um RST, a porta no servidor está fechada ou o servidor está recusando justamente você.

Repetições automáticas com pausa crescente

A rede móvel é instável por natureza. Em vez de cair no primeiro timeout, configure repetições com atraso exponencial: primeira tentativa em 1 segundo, segunda em 2, terceira em 4. Em Python, isso é feito com um adaptador com a classe Retry do urllib3; em Node.js, com o pacote axios-retry. Três repetições com esse esquema eliminam 90 por cento dos timeouts aleatórios sem perda de dados.

Conexões persistentes e pools

Cada nova conexão TCP via proxy móvel custa de 100 a 500 milissegundos para ser estabelecida. Se seu script abre uma nova conexão a cada requisição, você perde tempo e bate no limite mais rápido. Use sessões: em Python, requests.Session; em Node.js, um agente com keepAlive: true. Uma única conexão será reaproveitada para dezenas de requisições.

Monitoramento de disponibilidade

Configure uma verificação simples a cada minuto: o script faz uma requisição via proxy e registra o tempo de resposta e o código. Em uma semana, você terá um panorama de em quais horários o proxy é mais rápido e quando pega timeouts. Isso permite planejar a carga e ver a degradação antecipadamente, em vez de descobri-la com tarefas quebradas.

*/1 * * * * curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -m 20 -w "$(date +%H:%M) %{http_code} %{time_total}\n" https://api.ipify.org >> /var/log/proxy-check.log

DNS via proxy

Por padrão, alguns aplicativos resolvem nomes de domínio localmente, e não via proxy. Isso pode causar vazamento de informações e situações em que o DNS local retorna um endereço inacessível da rede móvel. Nas configurações de navegadores e antidetects, procure a opção "DNS via proxy" ou use o protocolo socks5h em vez de socks5 no curl e no Python: a letra h significa que os nomes serão resolvidos pelo próprio proxy.

Troca da porta para uma padrão

Se você trabalha com frequência em redes diferentes, pergunte ao provedor sobre a possibilidade de atribuir ao proxy a porta 443 ou 8080. Essas portas estão abertas em praticamente todos os lugares, e você não precisará brigar com firewalls corporativos toda vez.

Ajuste fino da rotação

Cenário avançado: vincular a troca de IP à lógica da aplicação. Antes de iniciar um novo lote de requisições, o script aciona o link de troca de IP, espera 10-15 segundos, verifica via api.ipify.org que o endereço realmente mudou, e só então começa o trabalho. Assim você elimina completamente os timeouts por coincidência aleatória da requisição com a rotação.

Dica: adicione ao log de cada requisição não só o horário, mas também o IP atual do proxy. Quando, daqui a um mês, você for analisar por que os indicadores caíram, a correlação entre IPs específicos e timeouts vai indicar imediatamente quais endereços da operadora eram problemáticos.

FAQ: perguntas frequentes sobre diagnóstico

O servidor proxy não responde, mas o ping passa. O que isso significa?

O ping verifica apenas a disponibilidade do IP pelo protocolo ICMP, e não a abertura da porta. O servidor pode estar vivo e responder ao ping, mas a porta do proxy estar sendo filtrada pelo firewall ou o serviço nela não estar rodando. Sempre verifique a porta TCP especificamente com os comandos da etapa 2.

Quanto esperar antes de considerar que o proxy não responde?

Para estabelecer conexão com um proxy móvel, é normal até 1 segundo, e o limite é 10 segundos. Para receber dados, é normal até 5 segundos, e o limite é 30-45 segundos. Se a conexão não se estabeleceu em 10 segundos, esperar mais é inútil: a resposta não virá.

Posso simplesmente desligar o firewall e trabalhar assim?

Não. Desligar a proteção é aceitável apenas por um minuto para testar a hipótese. Depois disso, crie uma regra específica para o aplicativo ou a porta, como descrito na etapa 4, e ligue o firewall de volta. Um computador sem proteção na rede é um risco para suas contas e dados.

Por que o proxy funciona em um navegador e não funciona em outro?

Geralmente porque um navegador usa as configurações de proxy do sistema, e o outro as suas próprias, e nelas estão dados diferentes. Segunda possibilidade: o firewall permitiu um executável e não permitiu o outro. Verifique as configurações dos dois navegadores e a lista de regras do firewall.

Como saber se o problema é a rotação de IP, e não minhas configurações?

Anote o horário de cada timeout durante uma hora e compare com o intervalo de rotação do painel. Se os timeouts chegam com a mesma periodicidade da troca de IP, é a rotação. Mude para troca por link, e o problema desaparece.

É obrigatório usar o terminal? Não existem ferramentas gráficas?

O terminal é mais rápido e preciso, mas há alternativas. Navegadores antidetect têm verificação de proxy embutida com exibição do tempo de resposta. Existem programas de desktop para verificar listas de proxies com indicação de portas abertas. No entanto, para encontrar a causa no seu caso específico, o terminal é insubstituível: ele mostra em que etapa a conexão parou.

O que fazer se todas as seis etapas foram concluídas e o problema persistir?

Escreva para o suporte do provedor de proxy e anexe: a saída do Test-NetConnection ou nc, a saída do curl com a opção -v, o resultado do rastreamento, seu IP externo, o horário das tentativas e a informação sobre se o proxy funciona de outra rede. Com esses dados, o especialista encontrará a causa em uma resposta, e não em cinco perguntas de esclarecimento.

É preciso reiniciar o computador depois de alterar as regras do firewall?

Não, as regras de firewall do Windows, macOS e Linux são aplicadas instantaneamente. A reinicialização é necessária apenas para o roteador após alterar MTU ou perfis de segurança, e mesmo assim não em todos os modelos.

Posso usar a mesma abordagem para proxies de datacenter?

Sim, as etapas de 1 a 5 são universais para qualquer tipo de proxy. A etapa 3 é diferente: proxies de datacenter respondem mais rápido, e os timeouts podem ser menores. E a etapa 6: proxies de datacenter não têm rotação por reconexão de modem, então não haverá pausas no momento da troca de IP.

Conclusão

Vamos resumir. Você aprendeu a não entrar em pânico com a mensagem de que o servidor proxy não responde, mas a analisar a situação por partes. Primeiro, você determinou se o proxy funciona pelo menos de algum lugar. Depois, verificou se a porta está aberta justamente do seu dispositivo. Lidou com os timeouts e entendeu a diferença entre timeout de conexão e timeout de leitura. Verificou o firewall e o antivírus e criou uma regra específica em vez de desligar a proteção. Estudou o roteador, o MTU e o gateway corporativo. E, por fim, garantiu que o próprio proxy aceita justamente você: lista de permissões, modem, rotação, limites.

O resultado principal não é nem que a conexão foi restaurada. É que agora você tem um método. Da próxima vez que algo travar, você não vai adivinhar nem testar configurações aleatoriamente. Você vai abrir o terminal, executar dois comandos e em um minuto saber em que trecho da cadeia está a interrupção.

O que fazer a seguir

1. Salve o arquivo com os comandos que funcionaram e seus dados de proxy em um lugar prático. Esse é o seu kit de primeiros socorros.
2. Mude a autenticação para login e senha, se você ainda usa lista de permissões de um computador residencial.
3. Verifique os timeouts em todos os aplicativos que funcionam via proxy móvel e ajuste-os para os valores recomendados.
4. Configure o monitoramento por minuto da seção avançada em pelo menos um proxy, para ver em uma semana o panorama real de estabilidade.

Para onde evoluir

O próximo nível é a automação do tratamento de falhas: repetições com pausa crescente, rotação controlada, pools de conexões e registro de cada requisição vinculado ao IP. Dominando isso, você vai parar de notar timeouts isolados de vez: seu sistema vai superá-los sozinho, e você verá apenas as métricas finais. Boa sorte no trabalho, e que seus proxies respondam sempre de primeira.