Sumário do artigo

A frase "o proxy não funciona" para um engenheiro de suporte soa mais ou menos como "dói em algum lugar aqui dentro" para um médico. A direção é clara, mas sem exames e sintomas não dá para fechar o diagnóstico. Neste guia você vai aprender a coletar exatamente o conjunto de dados que transforma uma reclamação vaga em uma tarefa concreta com uma resposta clara.

Introdução: por que "não funciona" é impossível de diagnosticar

Imagine dois tickets para o suporte da Proxeon. O primeiro: "Comprei um proxy, nada funciona, me ajudem". O segundo: "O proxy com identificador PX-48213 às 14h32 no horário de Brasília (UTC-3) retorna erro de conexão ao fazer uma requisição para api.example.com via HTTP, sendo que para outro site o mesmo proxy funciona, a conexão direta sem proxy também funciona, e o resultado do curl segue em anexo". O primeiro ticket inicia uma corrente de cinco ou seis e-mails de esclarecimento, cada um levando horas de espera. O segundo é resolvido com uma única resposta.

A diferença não está na educação nem na sorte. Está nos dados. O engenheiro não vê sua tela, não conhece seu sistema operacional, não consegue reproduzir sua requisição sem os parâmetros de origem. Tudo o que ele tem é o texto do seu e-mail. Se esse texto não tiver fatos, a primeira coisa que ele vai fazer é pedir fatos. E é exatamente essa a corrente de e-mails que arrasta a solução de um problema simples por vários dias.

O que o leitor vai levar daqui

Depois deste guia, você vai conseguir montar em 15-20 minutos um pacote de diagnóstico que contém tudo o que é necessário para resolver o problema já na primeira resposta. Você terá um script pronto que reúne os dados técnicos em um único arquivo de texto, um modelo de solicitação para copiar e uma noção clara de quais verificações fazer antes de escrever para o suporte.

Para quem é este guia

O guia é voltado para usuários de proxy de nível intermediário: quem sabe abrir o terminal ou o prompt de comando, sabe o que é uma URL e já configurou um proxy em algum aplicativo pelo menos uma vez. Usuários avançados vão encontrar aqui um script de diagnóstico pronto e uma tabela de isolamento do problema. Para iniciantes, vamos explicar cada termo em detalhes.

O que você precisa saber antes

Basta entender três coisas. Proxy é o intermediário pelo qual passa sua requisição de rede. Endereço de destino é o site ou serviço que você está acessando. Cliente é o programa que faz a requisição através do proxy (navegador, scraper, script). O resto a gente destrincha ao longo do caminho.

Quanto tempo vai levar

A primeira passada pelo guia com a configuração do script leva cerca de 30 minutos. Depois disso, a coleta do diagnóstico com o modelo pronto vai levar de 10 a 15 minutos. É incomparavelmente menos do que vários dias de troca de e-mails com esclarecimentos.

Dica: salve este guia e o script nos favoritos. Problemas com proxy acontecem raramente, e quando aparecem, é difícil lembrar de todo o procedimento de novo. Um checklist pronto à mão economiza estresse.

Preparação inicial: ferramentas e acessos

Antes de coletar os dados, confirme que você tem as ferramentas básicas. Todas são gratuitas e na maioria dos sistemas já vêm instaladas.

Ferramentas necessárias

  • curl — utilitário de linha de comando para enviar requisições de rede. É a nossa principal ferramenta de reprodução do problema. No macOS e na maioria das distribuições Linux, já vem instalado. No Windows 10 e 11 também faz parte do sistema.
  • Terminal ou prompt de comando — a janela onde você digita os comandos. No Windows é o PowerShell ou o Prompt de Comando (cmd), no macOS e Linux é o Terminal.
  • Editor de texto — Bloco de Notas, TextEdit ou qualquer outro para visualizar o arquivo coletado e remover os segredos.
  • Dados do seu proxy Proxeon — identificador, endereço, porta, login e senha. Eles foram fornecidos a você no painel de controle.

Verificando se o curl está disponível

Abra o terminal e faça uma verificação simples.

  1. No Windows, pressione a tecla Win, digite PowerShell e abra o aplicativo.
  2. No macOS, abra o Spotlight com Cmd+Espaço, digite Terminal e pressione Enter.
  3. No Linux, abra o terminal pelo menu de aplicativos ou com o atalho Ctrl+Alt+T.
  4. Digite o comando 
    curl --version
    e pressione Enter.

Se você vir uma linha do tipo "curl 8.x.x" com uma lista de protocolos suportados, a ferramenta está pronta. Se o sistema disser que o comando não foi encontrado, instale o curl: no Windows atualize o sistema para a versão mais recente, no Linux faça a instalação pelo gerenciador de pacotes da sua distribuição.

✅ Verificação: o comando 

curl --version
exibiu o número da versão e a lista de protocolos, incluindo http e https. Então está tudo pronto para começar.

O que preparar dos dados da Proxeon

Acesse o painel de controle da Proxeon em proxeon.net e abra o cartão do seu proxy. Anote ou copie em um arquivo separado os seguintes campos: identificador do proxy, host (endereço), porta, tipo (HTTP, HTTPS ou SOCKS5), login e senha. Esses dados serão necessários para montar o comando de reprodução.

⚠️ Atenção: login e senha do proxy são dados sigilosos. Vamos trabalhar com eles localmente, mas NÃO é para incluí-los no ticket para o suporte. Mais adiante há uma seção específica sobre como limpar os logs com segurança antes de enviar.

Conceitos básicos: a fronteira cliente — proxy — servidor

Para entender quais dados são importantes, é preciso visualizar o caminho da requisição. Ela passa por três trechos, e o problema pode surgir em qualquer um deles.

Três elos de uma corrente

Quando você acessa um site através de um proxy, a requisição segue assim: seu cliente envia a requisição para o servidor proxy, que a repassa ao servidor de destino, recebe a resposta e devolve para você. Três elos, duas fronteiras. Entender em qual fronteira travou é metade do diagnóstico.

  • Fronteira cliente — proxy. Se a requisição nem chegou ao proxy, o problema está do seu lado: endereço de proxy errado, porta fechada, filtro corporativo, erro nas configurações do cliente.
  • Fronteira proxy — servidor. Se o proxy aceitou a requisição, mas não conseguiu chegar ao site de destino, o problema está entre o proxy e o destino: site indisponível, recusando conexão ou respondendo com erro.

A tarefa do diagnóstico é determinar em qual fronteira tudo quebrou. O engenheiro de suporte da Proxeon, pelo seu output, vai enxergar de imediato onde a requisição parou, e isso reduz drasticamente o leque de causas.

Por que o horário exato é tão importante

A infraestrutura de proxy mantém logs. Para localizar sua requisição específica neles, o engenheiro precisa do horário exato do evento com indicação do fuso horário. "Hoje de manhã" não se busca nos logs. "14h32 no horário de Brasília, UTC-3" se encontra em segundos. A diferença de horário entre a sua formulação e o registro no log é uma causa frequente de o evento simplesmente não ser encontrado.

Dica: sempre indique o fuso horário de forma explícita. O formato "UTC-3" ou "horário de Brasília" é compreensível sem suposições. Se você estiver em outro fuso, indique o seu — o servidor faz a conversão sozinho.

Passo 1: Montar o conjunto mínimo de dados

Objetivo da etapa: registrar cinco fatos sem os quais qualquer solicitação ficará incompleta. Esta é a base, todo o resto se constrói em cima.

Cinco fatos obrigatórios

  1. Identificador do proxy. O nome ou número exato do painel da Proxeon, por exemplo PX-48213. Não "aquele proxy que comprei ontem", mas o identificador específico. Se você tem um pacote com vários proxies, indique exatamente qual é o caso.
  2. Horário exato com fuso horário. Quando exatamente o problema ocorreu. Formato: data, hora, fuso. Por exemplo: 12 de março de 2026, 14h32, UTC-3. Se o problema se repete, indique várias marcas de tempo.
  3. Endereço de destino. A URL ou host completo que você acessou. Por exemplo: https://api.example.com/v2/data. Não "um site", mas o endereço exato.
  4. O que exatamente você fez. Uma ou duas frases sobre a ação. "Enviei uma requisição GET do meu script" ou "abri o site no navegador com o proxy configurado". O contexto ajuda a entender a natureza da requisição.
  5. O que você esperava e o que recebeu. Esperava o código 200 e os dados, recebeu um erro de conexão. Esperava o carregamento da página, recebeu um carregamento infinito. A diferença entre a expectativa e a realidade é a essência do problema.

⚠️ Atenção: não substitua o concreto por emoções. "Está tudo lento e é um horror" não traz informação técnica. "A resposta chega em 40 segundos em vez dos 2 habituais" traz.

Como registrar o horário corretamente

Se o problema está acontecendo agora, olhe no relógio e anote o horário imediatamente. Se foi no passado, reconstitue o horário pelos logs do seu aplicativo ou pelo histórico do navegador. Quanto mais precisa a marca, mais rápido se encontra o registro do lado do servidor.

✅ Verificação: você tem cinco fatos anotados. Leia em voz alta. Se uma pessoa que não vê sua tela entende o que aconteceu, onde e quando, o conjunto mínimo está montado.

Passo 2: Reproduzir o problema com um único comando curl

Objetivo da etapa: reduzir o problema a um único comando que o engenheiro possa repetir mentalmente ou literalmente, e obter uma saída técnica detalhada.

O navegador e um script complexo fazem dezenas de ações ocultas. Isolar o problema neles é difícil. O utilitário curl faz exatamente uma requisição e mostra cada etapa dela. É a ferramenta ideal de reprodução.

Comando básico através do proxy Proxeon

Monte o comando com seus dados. O formato geral é este:

curl -v -x http://LOGIN:SENHA@HOST:PORTA https://ENDEREÇO-DE-DESTINO

Vamos entender as flags. -v ativa o modo detalhado (verbose): o curl mostra todo o andamento da conexão linha por linha. -x define o proxy pelo qual passa a requisição. Depois dele vem o endereço do proxy com autenticação. No final, o endereço de destino.

Exemplo com os valores preenchidos (dados fictícios):

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 https://api.example.com/v2/data

Adicionando medição de tempo e gravação em arquivo

Para deixar a saída ainda mais informativa, vamos ampliar o comando. A flag -w adiciona um resumo dos tempos ao final.

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 -w "Código final: %{http_code}, tempo total: %{time_total}s" https://api.example.com/v2/data

Agora, bem no final da saída, você vai ver o código HTTP final e o tempo total da requisição. Esses são os números-chave para diagnosticar a velocidade.

Dica: se o problema for lentidão e não erro, adicione tempos detalhados com 

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"
Isso vai mostrar em qual etapa o tempo se perde.

Para proxy SOCKS5

Se o seu proxy for do tipo SOCKS5, troque o esquema no endereço:

curl -v -x socks5://user123:secretpass@proxy.proxeon.net:1080 https://api.example.com/v2/data

⚠️ Atenção: o comando contém seu login e senha reais. Execute-o no seu terminal, mas NÃO copie o comando com os segredos para o e-mail. No ticket, login e senha são substituídos por marcadores — isso está no passo 5.

Ordem de execução

  1. Abra o terminal.
  2. Cole o comando montado, substituindo pelos seus dados reais.
  3. Pressione Enter e aguarde a conclusão.
  4. Selecione toda a saída, da primeira à última linha, e copie para um arquivo de texto.

✅ Verificação: você obteve uma saída de várias linhas, na qual aparecem linhas começando com os caracteres "*", ">" e "<". Se há saída, a reprodução deu certo, mesmo que a requisição tenha terminado em erro — o erro também é informação valiosa.

Passo 3: Ler a saída linha por linha e localizar a fronteira do problema

Objetivo da etapa: aprender a entender o que a saída do curl mostra e determinar em qual elo a requisição parou. Não vamos repetir aqui a decodificação de códigos de erro específicos — há um artigo separado na base de conhecimento da Proxeon para isso, e você pode referenciá-lo no ticket, se necessário.

Três tipos de linhas na saída

A saída detalhada do curl usa prefixos que facilitam a orientação.

  • Linhas com asterisco (*) — mensagens internas do próprio curl sobre o andamento da conexão: resolução de nome, estabelecimento da conexão com o proxy, handshake de criptografia. É a cozinha interna.
  • Linhas com seta para a direita (>) — é o que seu cliente ENVIA. Cabeçalhos da requisição, método, caminho.
  • Linhas com seta para a esquerda (<) — é o que RESPONDEM a você. Código de resposta, cabeçalhos do servidor.

Onde fica a fronteira cliente — proxy

No início da saída, o curl informa que está estabelecendo conexão com o proxy. Você vai ver uma linha do tipo "Connected to proxy.proxeon.net port 8080". Se essa linha não existe e no lugar dela há um erro de conexão, significa que a requisição não chegou ao proxy. O problema está na fronteira cliente — proxy: pode ser porta fechada, endereço errado ou um filtro local atrapalhando.

Se a linha de conexão com o proxy existe, mas depois vem um erro de autorização, significa que o proxy está acessível, mas não aceitou seu login e senha. Essa também é a fronteira cliente — proxy, mas no nível de autenticação.

Onde fica a fronteira proxy — servidor

Após a conexão bem-sucedida com o proxy, o curl mostra o estabelecimento da conexão com o servidor de destino através do proxy. Se aqui surgir um erro, significa que o proxy aceitou a requisição, mas não conseguiu chegar ao destino. O problema está na fronteira proxy — servidor: o site de destino está indisponível, recusando conexão ou respondendo lentamente.

Se você vê uma linha de resposta com seta para a esquerda, por exemplo "< HTTP/1.1 200" ou outro código, significa que toda a cadeia funcionou e você recebeu uma resposta. A partir daí, a questão é o conteúdo da resposta, não o funcionamento do proxy.

Linhas-chave que importam para o engenheiro

  1. Linha de conexão com o proxy — confirma que o primeiro elo funciona.
  2. Linha sobre a autorização no proxy — mostra se as credenciais foram aceitas.
  3. Linha sobre o handshake de criptografia (TLS) — importante para destinos HTTPS.
  4. Primeira linha de resposta com seta para a esquerda — o veredito final da cadeia.
  5. Resumo final com código e tempo da flag -w.

Dica: não tente fechar o diagnóstico sozinho pelo código de erro, se não tiver certeza. Sua tarefa é anexar a saída completa. O engenheiro da Proxeon vai ler com mais precisão. A decodificação completa dos códigos está em um artigo separado da base de conhecimento — referencie-o se quiser se aprofundar.

✅ Verificação: você consegue apontar a linha após a qual a requisição quebrou e dizer em qual fronteira isso aconteceu — cliente-proxy ou proxy-servidor. Se consegue, você passou desta etapa.

Passo 4: Fazer as verificações antes de acionar o suporte

Objetivo da etapa: por eliminação, reduzir o leque de causas antes mesmo de escrever para o suporte. Cada verificação descarta uma classe inteira de problemas.

O princípio é simples: mudamos um parâmetro por vez e vemos se o comportamento mudou. É a clássica abordagem de engenharia para isolar a falha.

Quatro verificações essenciais

  1. Outro site de destino. Repita a mesma requisição pelo mesmo proxy, mas para outro endereço. Escolha um site público comprovadamente estável. Se através dele o proxy funciona, mas para o seu destino não, o problema está relacionado ao site de destino ou à forma como ele trata o proxy, e não ao proxy em si.
  2. Outro protocolo. Se usou HTTP, tente um destino HTTPS, e vice-versa. Às vezes o problema aparece só em um protocolo, e isso é um sinal importante.
  3. Outro proxy. Se você tem um segundo proxy da Proxeon, repita a requisição por ele. Se o segundo funciona e o primeiro não, o problema está naquele proxy específico. Se os dois se comportam igual, o problema é mais sistêmico.
  4. Conexão direta. Faça a requisição ao destino SEM proxy, direto. Remova a flag -x. Se direto o site também está indisponível, o problema não é o proxy, mas o próprio site de destino ou a sua rede.

Comando para a verificação direta

curl -v https://api.example.com/v2/data

O mesmo comando, mas sem a parte do proxy. Compare o resultado com a requisição via proxy.

Tabela: o que cada verificação descarta

Abaixo, como interpretar os resultados das verificações.

  • Outro site funciona, o seu não. Descarta uma falha geral do proxy. Indica que há uma especificidade na interação do destino específico com o proxy.
  • Outro protocolo funciona, o seu não. Descarta indisponibilidade total. Localiza o problema no nível de um protocolo ou porta específicos.
  • Outro proxy funciona, o seu não. Descarta problema do seu lado e na rede. Indica um proxy específico.
  • A conexão direta também não funciona. Descarta a culpa do proxy. O problema está no site de destino ou na sua rede.
  • A direta funciona, via proxy não. Confirma que a questão é justamente a combinação com o proxy, e é exatamente aí que o suporte vai ajudar.

Dica: os resultados dessas quatro verificações são a parte mais valiosa do ticket. Eles economizam metade do trabalho do engenheiro, porque você já descartou o desnecessário. Liste-os obrigatoriamente no e-mail.

⚠️ Atenção: use esses proxies exclusivamente para tarefas legais: testar seus próprios serviços, coletar dados públicos dentro das regras e trabalhar com APIs. As verificações não se destinam a ações que violem as regras dos sites ou a legislação.

✅ Verificação: você tem os resultados das quatro verificações e consegue dizer em uma frase o que elas, em conjunto, descartam. Por exemplo: "a conexão direta e outro proxy funcionam, então a questão é o proxy específico PX-48213 ao acessar esse destino".

Passo 5: Coletar dados sobre o seu lado

Objetivo da etapa: descrever o ambiente em que o problema ocorre. Metade dos casos obscuros se explica por particularidades do cliente ou da rede local.

O que indicar sobre o ambiente

  1. Sistema operacional e versão. Windows 11, macOS 15, Ubuntu 24.04. A versão exata ajuda a reproduzir as condições.
  2. Cliente e versão. Com o que você trabalha com o proxy: navegador e versão, nome e versão do scraper ou da biblioteca, versão do curl. Clientes diferentes tratam o proxy de formas diferentes.
  3. Forma de configuração do proxy. Configurado no sistema, no navegador, passado no código, definido em variáveis de ambiente. Isso influencia como o proxy é aplicado.
  4. Presença de filtro corporativo ou local. Você trabalha de uma rede corporativa? Há antivírus com firewall de rede? Existe firewall local? Esses filtros podem interceptar ou bloquear conexões antes mesmo do proxy.
  5. Tipo de conexão com a internet. Provedor residencial, internet móvel, rede corporativa. Às vezes o provedor influencia a disponibilidade.

Como saber a versão do cliente

Para o curl, use o já conhecido comando 

curl --version
Para o navegador, abra a seção "Sobre" no menu. Para uma biblioteca no código, veja a versão no arquivo de dependências do seu projeto.

Verificação de filtro corporativo

Se você está em uma rede corporativa e suspeita de um filtro, é fácil verificar. Faça uma requisição direta ao proxy sem destino e veja se a conexão é estabelecida. Se até a conexão direta à porta do proxy não passa, mas de outra rede passa, provavelmente há um filtro corporativo nas conexões de saída.

Dica: redes corporativas frequentemente liberam apenas as portas 80 e 443. Se o seu proxy está em uma porta não padrão, pergunte ao seu administrador de rede se essa porta está aberta para fora. Essa é uma causa comum e fácil de resolver.

✅ Verificação: você tem uma lista preenchida dos cinco pontos sobre o ambiente. O engenheiro, ao ler, sabe em quais condições reproduzir o problema.

Passo 6: Automatizar a coleta do diagnóstico com um único script

Objetivo da etapa: reunir todas as informações técnicas em um único arquivo de texto, sem reescrever nada manualmente. O script faz o mesmo que você fez à mão, mas em uma única execução.

Script para macOS e Linux

Crie um arquivo diag.sh com o seguinte conteúdo. Substitua os valores das variáveis pelos seus.

#!/bin/bash
PROXY="http://LOGIN:SENHA@HOST:PORTA"
TARGET="https://ENDEREÇO-DE-DESTINO"
ALT="https://SITE-ESTÁVEL"
OUT="diag_result.txt"
echo "=== Data e hora ===" > $OUT
date >> $OUT
echo "=== Versão do curl ===" >> $OUT
curl --version >> $OUT 2>&1
echo "=== Requisição via proxy ao destino ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "=== Requisição via proxy ao site alternativo ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $ALT >> $OUT 2>&1
echo "=== Requisição direta ao destino sem proxy ===" >> $OUT
curl -v -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "Pronto. Arquivo: $OUT"

Como executar o script

  1. Salve o arquivo com o nome diag.sh.
  2. Coloque seus valores nas variáveis PROXY, TARGET e ALT.
  3. No terminal, vá até a pasta do arquivo.
  4. Torne o arquivo executável com o comando 
    chmod +x diag.sh
  5. Execute-o com o comando 
    ./diag.sh
  6. Após a conclusão, abra o arquivo diag_result.txt.

Script para Windows (PowerShell)

Crie um arquivo diag.ps1 com a mesma lógica.

$Proxy = "http://LOGIN:SENHA@HOST:PORTA"
$Target = "https://ENDEREÇO-DE-DESTINO"
$Alt = "https://SITE-ESTÁVEL"
$Out = "diag_result.txt"
"=== Data e hora ===" | Out-File $Out
Get-Date | Out-File $Out -Append
"=== Versão do curl ===" | Out-File $Out -Append
curl --version 2>&1 | Out-File $Out -Append
"=== Via proxy ao destino ===" | Out-File $Out -Append
curl -v -x $Proxy -w "code:%{http_code} total:%{time_total}s" $Target 2>&1 | Out-File $Out -Append
"=== Via proxy à alternativa ===" | Out-File $Out -Append
curl -v -x $Proxy $Alt 2>&1 | Out-File $Out -Append
"=== Requisição direta ===" | Out-File $Out -Append
curl -v $Target 2>&1 | Out-File $Out -Append

Execute-o no PowerShell com o comando 

.\diag.ps1
e abra o arquivo gerado.

⚠️ Atenção: o arquivo diag_result.txt contém seu login e senha em texto aberto, porque eles estavam na variável PROXY. Antes de enviar para o suporte, é OBRIGATÓRIO limpá-lo conforme as instruções do passo 7.

Dica: guarde o script com as variáveis vazias e insira os valores só antes de executar. Assim você não corre o risco de compartilhar acidentalmente um arquivo com segredos dentro.

✅ Verificação: o arquivo diag_result.txt foi criado e contém vários blocos: a versão do curl, as requisições via proxy para dois sites e a requisição direta. Esse é o pacote de diagnóstico técnico pronto.

Passo 7: Limpar os logs com segurança antes de enviar

Objetivo da etapa: remover dos dados coletados tudo o que é sigiloso, preservando o valor diagnóstico. Enviar logs com senhas é inaceitável em qualquer hipótese.

O que remover obrigatoriamente

  • A senha do proxy. Na saída, ela pode ter caído na linha de conexão. Encontre e substitua.
  • O login, se estiver vinculado a dados de pagamento. Normalmente o login pode ficar, mas se ele faz parte de uma combinação sensível, substitua também.
  • Tokens de autorização. Se nos cabeçalhos da requisição houver Authorization, tokens Bearer, chaves de API, cookies de sessão — remova tudo.
  • Dados pessoais. Quaisquer nomes, endereços, telefones, se caíram por acaso no corpo da requisição ou da resposta.

Por que substituir

Não remova a linha inteira — assim se perde a estrutura. Substitua o segredo por um marcador claro, mantendo o comprimento e o formato quando possível. Exemplos de substituição:

  • Senha substituída por [SENHA_OCULTA].
  • Login por [LOGIN_OCULTO].
  • Token por [TOKEN_OCULTO].

Assim o engenheiro vê que ali havia um token, mas não vê o valor. A estrutura é preservada, a segurança também.

Ordem da limpeza

  1. Abra o arquivo diag_result.txt em um editor de texto.
  2. Use a busca (Ctrl+F) pela sua senha e substitua todas as ocorrências pelo marcador.
  3. Faça o mesmo com o login, se decidiu ocultá-lo.
  4. Revise as linhas com cabeçalhos Authorization, Cookie, api-key. Substitua os valores por marcadores.
  5. Salve o arquivo com um novo nome, por exemplo diag_clean.txt, para não confundir com o original.

⚠️ Atenção: revise o arquivo duas vezes antes de enviar. A senha pode ter aparecido não só no comando, mas também nas linhas de saída do curl. Um segredo esquecido é um vazamento que pode levar à comprometimento do seu proxy.

Dica: mantenha o original diag_result.txt localmente e envie apenas a cópia limpa. Se o engenheiro pedir um esclarecimento, você tem os dados completos à mão.

✅ Verificação: abra o arquivo limpo e faça uma busca pela sua senha. Zero resultados — a limpeza deu certo. A estrutura da saída, por sua vez, está preservada.

Passo 8: Preencher o modelo de solicitação pronto

Objetivo da etapa: reunir tudo em um e-mail que o engenheiro vai ler e entender de imediato. Abaixo, um modelo para copiar.

Modelo de solicitação ao suporte Proxeon

Assunto: Problema com o proxy [IDENTIFICADOR] ao acessar [DESTINO]

1. Identificador do proxy: [por exemplo PX-48213]
2. Tipo de proxy: [HTTP / HTTPS / SOCKS5]
3. Horário do problema: [12.03.2026, 14h32, UTC-3]
4. Endereço de destino: [https://api.example.com/v2/data]
5. O que fiz: [enviei uma requisição GET pelo curl]
6. Esperava: [código 200 e os dados]
7. Recebi: [erro de conexão / resposta lenta / código de erro]

Resultados das verificações:
- Outro site por este proxy: [funciona / não funciona]
- Conexão direta sem proxy: [funciona / não funciona]
- Outro proxy para o mesmo destino: [funciona / não funciona / não tenho um segundo proxy]

Ambiente:
- SO: [Windows 11]
- Cliente: [curl 8.6.0]
- Configuração do proxy: [flag -x no curl]
- Filtro corporativo: [não / sim, portas 80 e 443]

Saída do diagnóstico (login e senha ocultos) em anexo no arquivo diag_clean.txt.

Conclusão resumida: pelas minhas verificações, o problema está na fronteira [cliente-proxy / proxy-servidor], porque [a conexão direta funciona, mas via proxy não].

Como preencher corretamente

  1. Copie o modelo para o corpo do e-mail ou do ticket.
  2. Substitua cada campo entre colchetes pelos seus dados.
  3. Anexe o arquivo limpo diag_clean.txt.
  4. Releia o e-mail inteiro: ele é compreensível para quem está de fora?
  5. Envie.

Dica: a linha "Conclusão resumida" no final é a mais útil. Nela você mesmo formula uma hipótese com base nas verificações. Mesmo que a hipótese não seja exata, ela mostra ao engenheiro o seu raciocínio e economiza tempo.

✅ Verificação: no e-mail não há nenhum campo entre colchetes — todos estão preenchidos. O arquivo limpo está anexado. Há uma conclusão resumida com hipótese. A solicitação está pronta para envio.

Verificação do resultado: checklist de prontidão da solicitação

Antes de enviar, passe por um checklist curto. Ele garante que você não esqueceu nada.

  • Foi indicado o identificador exato do proxy, não uma descrição.
  • Há o horário do evento com fuso horário explícito.
  • Foi indicado o endereço de destino completo.
  • Está descrito o que você fez, o que esperava e o que recebeu.
  • A saída completa do curl em modo detalhado está anexada.
  • Foram feitas e descritas pelo menos duas verificações de eliminação.
  • Estão indicados o SO, o cliente e sua versão.
  • Senha e todos os tokens foram removidos dos logs.
  • O arquivo de diagnóstico está anexado e nomeado de forma clara.
  • Há uma conclusão resumida com a sua hipótese.

Se todos os itens estiverem marcados, sua solicitação é daquelas que se resolvem na primeira resposta. O engenheiro não precisa esclarecer nada — ele tem o quadro completo.

✅ Verificação: todos os dez itens do checklist foram cumpridos. Esse é o indicador de sucesso: a solicitação é autossuficiente.

Erros comuns e como resolvê-los

Vamos analisar problemas frequentes na coleta do diagnóstico e as formas de resolvê-los.

Problema 1: o curl dá erro imediatamente, sem conexão com o proxy

Causa: formato de endereço do proxy incorreto ou erro de digitação no esquema (http em vez de socks5, ou o contrário).

Solução: confira o tipo de proxy no painel da Proxeon e use o esquema correto. Verifique se a porta está certa e separada por dois-pontos.

Problema 2: erro de autorização no proxy

Causa: login ou senha incorretos, ou caracteres especiais na senha não escapados.

Solução: confira as credenciais. Se a senha tiver os caracteres @, :, / — eles podem quebrar a string. Nesse caso, passe a autorização com a flag separada 

--proxy-user LOGIN:SENHA
em vez de inseri-la na URL.

Problema 3: o script não executa no Windows

Causa: a política de execução do PowerShell bloqueia scripts locais.

Solução: abra o PowerShell como administrador e permita a execução para a sessão atual definindo a política RemoteSigned no nível do processo. Após a coleta, restaure a política original.

Problema 4: a saída não traz detalhes, só a linha final

Causa: esqueceu a flag -v, que ativa o modo detalhado.

Solução: adicione -v logo após o curl. É ela que mostra o andamento da conexão linha por linha, sem a qual o diagnóstico é inútil.

Problema 5: a senha ficou por descuido no arquivo enviado

Causa: a limpeza foi feita sem atenção, e a senha apareceu na linha de saída, não só no comando.

Solução: troque imediatamente a senha do proxy no painel da Proxeon. De agora em diante, sempre faça uma busca pela senha no arquivo limpo antes de enviar.

Problema 6: o problema não se reproduz no curl, mas ocorre no navegador

Causa: o navegador adiciona cabeçalhos, cookies ou usa outra forma de configuração do proxy.

Solução: no ticket, informe com honestidade que no curl o problema não se repete, mas no navegador sim. Anexe o nome e a versão do navegador e a forma de configuração do proxy nele. Isso, por si só, já é informação de diagnóstico.

Problema 7: o horário nos logs não coincide com o seu

Causa: você indicou o horário local sem fuso horário, e o servidor opera em UTC.

Solução: sempre indique o fuso explicitamente. Em caso de dúvida, anexe as duas marcas: seu horário local e o equivalente em UTC.

Recursos adicionais: diagnóstico avançado

Se o conjunto básico não bastar, aqui vão algumas ferramentas para uma análise mais profunda. Elas serão úteis para usuários avançados.

Tempos detalhados para problemas de velocidade

Quando o proxy funciona, mas está lento, é importante entender em qual etapa o tempo se perde. A flag -w ampliada mostra o detalhamento.

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -x http://LOGIN:SENHA@HOST:PORTA https://DESTINO

Esses números mostram quanto tempo foi gasto na resolução de nome, no estabelecimento da conexão, na criptografia e na obtenção do primeiro byte. Se o ttfb estiver alto, a latência está do lado do destino. Se o connect estiver alto, o problema está na rede até o proxy.

Repetibilidade do problema

Se o problema for oscilante, colete uma série de requisições e mostre que parte passa e parte não. Um loop simples de várias requisições com registro dos códigos de resposta dará a estatística. A estabilidade ou a ausência dela é um fato importante para o suporte.

Verificação de vários destinos de uma vez

Monte uma lista de três ou quatro endereços e execute-os pelo proxy em uma única série. Assim você vê de imediato se o problema é específico de um destino ou geral.

Dica: anexe dados avançados apenas se o diagnóstico básico não bastar. Excesso de informação sem estrutura é tão prejudicial quanto a falta dela. Comece pelo mínimo, aprofunde-se a pedido do engenheiro.

FAQ: perguntas frequentes sobre a coleta de diagnóstico

É obrigatório usar especificamente o curl?

Não, mas o curl é a ferramenta mais universal e compreensível para o engenheiro. Sua saída é igual em todos os sistemas. Se você trabalha com uma biblioteca no código, anexe também a saída dela, mas a verificação com curl continua valendo como referência.

O que fazer se o problema já passou e não se repete?

Registre tudo o que lembrar: horário aproximado, destino, natureza do erro. Anexe os logs do seu aplicativo daquele período. Mesmo dados incompletos com horário exato ajudam a encontrar o registro no servidor.

Preciso anexar logs se o erro é óbvio pela descrição?

Sim. O que parece óbvio para você exige confirmação com fatos. Os logs eliminam suposições e permitem dar uma resposta exata, e não um palpite.

Posso enviar login e senha para o suporte verificar tudo sozinho?

Não. Segredos não são transmitidos em correspondência. O suporte da Proxeon tem acesso à sua conta pelo identificador, sem senha. O identificador é suficiente para a verificação do lado do servidor.

Em quanto tempo vem a resposta se tudo estiver coletado corretamente?

Uma solicitação completa reduz o tempo até a solução em várias vezes, porque elimina o ciclo de esclarecimentos. Os prazos exatos dependem da carga do suporte, mas com certeza você evita várias rodadas de troca de e-mails.

E se o curl mostra sucesso, mas o aplicativo continua não funcionando?

Esse é um fato valioso: o problema não está no proxy em si, mas em como o aplicativo o utiliza. Indique isso na solicitação, anexe as configurações de proxy no aplicativo e sua versão.

Preciso indicar o endereço de destino se ele é público?

Sim, obrigatoriamente. O comportamento do proxy pode depender do destino específico. Sem o endereço, o engenheiro não conseguirá reproduzir exatamente o seu caso.

Como saber se a porta é a minha ou se preciso de outra?

A porta está indicada no cartão do proxy no painel de controle. Tipos diferentes de proxy usam portas diferentes. Confira no painel e não use uma porta ao acaso.

É possível automatizar a limpeza dos logs de segredos?

Sobre o autor

Roman Melnikov

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

Compartilhe este artigo: