tcpdump e Wireshark ao trabalhar através de proxy: diagnóstico de quedas
Sumário do artigo
- Introdução: quando os logs do cliente já não bastam
- Fundamentos: três segmentos de uma única conexão
- Mergulho profundo: por que dentro do túnel só aparece o connect
- Tcpdump na prática: capturando sem gigabytes
- Wireshark: lendo a captura como um livro aberto
- Diagnóstico pela captura: quem exatamente derrubou a conexão
- Descriptografando o próprio tráfego via sslkeylogfile
- Cenários típicos de queda e como lê-los
- Erros típicos ao capturar e ler a captura
- Ferramentas e recursos do engenheiro
- Casos e resultados da aplicação
- Checklist de captura para abrir chamado no suporte
- Faq: perguntas frequentes sobre capturas através de proxy
Os logs do cliente são maravilhosos exatamente até o momento em que mostram alguma coisa. Mas um dia você bate numa parede: a aplicação escreve um lacônico connection reset, o proxy nos seus logs fica calado, e o servidor de destino jura que está tudo bem. Quem está mentindo? Ninguém. É só que você está olhando o problema do andar de cima, enquanto a verdade mora no nível dos pacotes. E é lá que você precisa descer.
Este artigo é um guia de engenharia detalhado sobre como trabalhar com tcpdump e Wireshark nos casos em que o tráfego passa por um proxy. Vamos destrinchar o que exatamente o observador vê antes do proxy e depois dele, por que dentro do túnel HTTPS só aparece a requisição CONNECT e mais nada, e como distinguir, a partir de uma única captura, uma queda do seu lado de uma queda no servidor de destino. Não se trata de interceptação e substituição de HTTPS no nível da aplicação — é sobre o nível de pacotes e diagnóstico honesto de quedas.
Introdução: quando os logs do cliente já não bastam
Imagine uma infraestrutura típica. Sua aplicação faz chamadas a uma API externa através de um proxy HTTP Proxeon. Normalmente tudo funciona. Mas cinco por cento das requisições falham com erro, e você não entende por quê. Os logs da aplicação mostram apenas o fato da queda. Os logs do proxy mostram que o túnel foi estabelecido. O servidor de destino está fora do seu controle. Você ficou preso entre três caixas-pretas.
É exatamente aqui que começa o diagnóstico em nível de pacotes. Uma captura de tráfego é a transcrição da conversa entre as máquinas, registrada palavra por palavra, sem interpretações e sem direito a mentira. O pacote ou chegou, ou não chegou. A flag RST ou está marcada, ou não está. O TCP não sabe fingir. E se você aprender a ler essa transcrição, vai parar de ficar no achismo.
Neste guia você vai aprender: como capturar com o comando tcpdump sem encher o disco de gigabytes; quais filtros de exibição no Wireshark economizam horas; como ler o handshake TLS mesmo sem descriptografar; como identificar o culpado pela queda pelas flags; e como descriptografar legalmente o seu próprio tráfego através da variável SSLKEYLOGFILE. No final, você tem um checklist pronto para abrir chamado no suporte e um FAQ detalhado.
Fundamentos: três segmentos de uma única conexão
A primeira coisa que precisa entrar na cabeça: quando o cliente trabalha através de um proxy, não é uma conexão só, são pelo menos duas conexões TCP diferentes. Uma — do cliente até o proxy. Outra — do proxy até o servidor de destino. Esse é o alicerce sem o qual qualquer análise posterior perde sentido.
O que é uma captura e como ela é estruturada
Uma captura de pacotes é uma sequência de pacotes de rede capturados numa interface de rede específica de uma máquina específica. A palavra-chave é específica. Você sempre vê apenas o tráfego que passa fisicamente pelo ponto de captura. Capturando no cliente, você vê a conversa cliente-proxy. Capturando no proxy, você vê os dois lados. No servidor de destino — apenas a conversa proxy-servidor.
Cada pacote carrega cabeçalhos de camadas: Ethernet, IP, TCP ou UDP, e a carga útil. Para diagnóstico de quedas, o que nos interessa em primeiro lugar é a camada TCP: números de porta, números de sequência (sequence), confirmações (ACK) e as flags — SYN, ACK, FIN, RST, PSH.
Modelo de proxy: duas conexões em vez de uma
Vamos analisar o esquema de tráfego ao trabalhar com um proxy HTTP em modo túnel:
- Segmento A (cliente - proxy). O cliente abre uma conexão TCP para o IP e a porta do proxy. Por esse canal ele envia o comando para estabelecer o túnel.
- Segmento B (proxy - servidor de destino). O proxy, em seu próprio nome, abre uma conexão TCP separada com o servidor de destino. Aqui já é outro src-IP, outra src-porta, outro estado.
- Túnel lógico. Depois do estabelecimento, o proxy começa a repassar cegamente bytes do segmento A para o segmento B e vice-versa. Ele não analisa o que está dentro.
Por que isso importa para o diagnóstico? Porque a queda pode acontecer em qualquer um dos dois segmentos, e do ponto de vista do cliente o sintoma é o mesmo — a conexão caiu. Mas a causa, e portanto a solução, são diferentes.
Proxy HTTP, SOCKS e tunelamento
Numa requisição HTTP comum sem criptografia, o proxy vê o método, a URL e os cabeçalhos. Mas assim que se fala em HTTPS, o cenário muda. O cliente não pode entregar ao proxy uma requisição não criptografada — senão perde o sentido da criptografia. Por isso aplica-se o mecanismo de tunelamento: o cliente diz ao proxy conecte-me a este host nesta porta e daí em diante não se meta. Esse comando é o CONNECT.
Mergulho profundo: por que dentro do túnel só aparece o CONNECT
Essa é, sem dúvida, a fonte mais comum de perplexidade para engenheiros que abrem pela primeira vez uma captura de tráfego HTTPS através de proxy. Você espera ver requisições e respostas, e vê uma linha só e depois uma papa ilegível. Vamos entender por que é assim e por que isso está certo.
Anatomia do CONNECT
Quando o cliente quer estabelecer uma conexão segura através do proxy, ele envia ao proxy uma requisição assim, em texto aberto:
CONNECT api.example.com:443 HTTP/1.1\r\nHost: api.example.com:443\r\n\r\nO proxy abre uma conexão TCP com api.example.com na porta 443 e, se tudo der certo, responde ao cliente:
HTTP/1.1 200 Connection established\r\n\r\nA partir desse momento o proxy se transforma num cano burro. Tudo o que o cliente enviar em seguida, o proxy repassa ao servidor byte a byte, e vice-versa. E o que o cliente envia em seguida? TLS ClientHello, o início do handshake. Troca criptografada. O proxy não tem as chaves e fisicamente não consegue olhar para dentro.
O que isso significa para o observador com a captura
Se você captura no cliente ou no proxy, vai ver:
- O estabelecimento da conexão TCP com o proxy (SYN, SYN-ACK, ACK).
- O texto aberto da requisição CONNECT com o nome do host de destino e a porta.
- A resposta do proxy sobre o status de estabelecimento do túnel.
- E daí em diante — apenas registros TLS, fluxo criptografado, do qual a olho nu só se lê metadados do handshake.
Eis o insight principal: o nome do host de destino na captura é sempre visível — na linha do CONNECT. Mesmo sem um único byte descriptografado, você sabe exatamente para onde o cliente tentou ir. Isso é impagável no diagnóstico: você já corta de imediato a pergunta será que a requisição foi mesmo para lá.
TLS SNI: a segunda fonte do nome do host
Mesmo que não houvesse CONNECT (por exemplo, numa conexão direta sem proxy), o nome do host costuma ser visível no campo SNI dentro do ClientHello. O Server Name Indication é transmitido em texto aberto no início do handshake. O Wireshark o exibe perfeitamente. Nas redes modernas ganha força o Encrypted Client Hello, que oculta o SNI, mas ao trabalhar através de um túnel CONNECT isso não atrapalha o diagnóstico — o nome do host já foi dito no próprio CONNECT.
tcpdump na prática: capturando sem gigabytes
Vamos ao trabalho. O tcpdump é um utilitário de linha de comando para captura de pacotes, disponível em praticamente qualquer sistema Unix-like. É poderoso, leve e indispensável em servidores sem interface gráfica. Vamos ver os cenários-chave.
Captura básica na interface certa
Primeiro, veja a lista de interfaces:
tcpdump -DCaptura numa interface específica com saída na tela:
tcpdump -i eth0 -nA flag -n desliga a resolução de nomes, para o tcpdump não travar em consultas DNS e mostrar IPs puros. Isso é importante: a resolução em tempo real distorce o cenário e deixa a captura mais lenta.
Filtragem por host e porta
Capturar todo o tráfego de uma interface num servidor carregado é caminho certo para gigabytes de lixo. Filtre desde o começo. Captura de tráfego para um proxy específico por IP e porta:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080Captura apenas para o servidor de destino (útil do lado do proxy):
tcpdump -i eth0 -n host api.example.com and port 443Combinação: tráfego para o proxy OU para o servidor de destino:
tcpdump -i eth0 -n "(host 203.0.113.10 and port 8080) or (host 198.51.100.5 and port 443)"Repare nas aspas: quando a expressão tem parênteses e operadores lógicos, envolva o filtro em aspas para que o shell não interprete os caracteres especiais.
Gravação em arquivo e o formato correto
Para análise posterior no Wireshark, é preciso um arquivo no formato pcap. A flag -w grava os pacotes brutos em arquivo:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump.pcapDetalhe importantíssimo: -s 0 ou o comportamento padrão moderno captura o pacote inteiro (snaplen). Versões antigas cortavam os pacotes. Se você precisa dos dados completos, garanta que o snaplen é suficiente:
tcpdump -i eth0 -n -s 0 host 203.0.113.10 and port 8080 -w dump.pcapSe, por outro lado, você só precisa dos cabeçalhos para diagnosticar quedas (flags, seq, ack) e não do conteúdo, limite o snaplen para o arquivo ficar mais compacto:
tcpdump -i eth0 -n -s 96 host 203.0.113.10 and port 8080 -w headers.pcapRotação de arquivos: como não encher o disco
Em diagnósticos longos de problemas intermitentes, a captura pode durar horas. Para não gerar um único arquivo monstruoso, use rotação por tamanho e número de arquivos. A flag -C define o tamanho do arquivo em megabytes, -W — o número de arquivos no buffer circular:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump-%Y%m%d-%H%M%S.pcap -C 100 -W 10Esse comando cria até dez arquivos de cem megabytes. Quando o décimo encher, o tcpdump começa a sobrescrever o primeiro. Assim você sempre guarda aproximadamente o último gigabyte de tráfego e nunca estoura o disco. O padrão de data no nome do arquivo deixa o acervo legível.
Alternativa — rotação por tempo. A flag -G define o intervalo em segundos após o qual um novo arquivo é criado:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -G 3600 -w dump-%Y%m%d-%H%M%S.pcapCada hora — um novo arquivo. Conveniente quando depois você precisa encontrar rapidamente o intervalo pelo horário do incidente.
Captura ao redor do evento: pegando uma queda rara
A situação mais traiçoeira é quando o problema se reproduz de vez em quando, de forma imprevisível. Você liga o buffer circular e espera. Assim que a aplicação registra o erro, você anota a hora exata e para a captura. Depois, na análise, vai até o segundo certo. Truque prático: faça a aplicação escrever no log o timestamp exato com milissegundos no momento do erro — é a sua âncora na captura.
Filtro por flags TCP direto no tcpdump
Às vezes é útil capturar apenas pacotes com determinadas flags. Por exemplo, apenas pacotes com a flag RST, para entender logo de cara se há resets voando:
tcpdump -i eth0 -n "tcp[tcpflags] & tcp-rst != 0"Apenas pacotes SYN — prático para acompanhar tentativas de estabelecer conexão:
tcpdump -i eth0 -n "tcp[tcpflags] & tcp-syn != 0"Combinação de RST ou FIN para monitorar encerramentos de conexão com o proxy:
tcpdump -i eth0 -n "host 203.0.113.10 and (tcp[tcpflags] & (tcp-rst|tcp-fin) != 0)"Wireshark: lendo a captura como um livro aberto
O tcpdump pega, o Wireshark lê. É um analisador gráfico com um sistema riquíssimo de filtros de exibição e decodificadores de protocolos. Você abre o arquivo pcap salvo e começa a investigação. Vamos ver as ferramentas que realmente importam para a nossa tarefa.
Filtros de exibição versus filtros de captura
Importante não confundir. O filtro de captura (o do tcpdump) descarta pacotes antes da gravação — o que não foi capturado, não existe. O filtro de exibição no Wireshark é uma lente: ele apenas esconde o que é supérfluo do arquivo já carregado, sem nada apagar. A sintaxe é diferente. Abaixo estão filtros de exibição, especificamente.
Filtros de exibição básicos
Mostrar só o tráfego para um IP específico:
ip.addr == 203.0.113.10Apenas a porta TCP do proxy:
tcp.port == 8080Combinação de host e porta:
ip.addr == 203.0.113.10 && tcp.port == 8080Mostrar apenas pacotes com a flag RST — num instante você vê todos os resets de conexão:
tcp.flags.reset == 1Apenas pacotes com FIN:
tcp.flags.fin == 1Apenas SYN sem ACK — tentativas de abrir conexão:
tcp.flags.syn == 1 && tcp.flags.ack == 0Busca por CONNECT e cabeçalhos HTTP
Para encontrar na captura a própria requisição CONNECT:
http.request.method == "CONNECT"A resposta do proxy sobre o estabelecimento do túnel aparece como resposta HTTP. Filtrar todas as requisições HTTP:
http.requestTodas as respostas HTTP com códigos:
http.responseFollow TCP Stream: reunindo a conversa
Essa é, talvez, a função mais valiosa do Wireshark para a nossa tarefa. Clique com o botão direito em qualquer pacote da conexão, depois Follow, depois TCP Stream. O Wireshark reúne todo o diálogo bidirecional numa única janela, onde os dados do cliente e do servidor aparecem em cores diferentes. Para tráfego não criptografado, você vê texto puro: a requisição CONNECT, a resposta do proxy, e depois bytes TLS ilegíveis.
É justamente no Follow Stream que você vê com clareza a quebra no CONNECT. As primeiras linhas se leem como texto humano, depois começa a área criptografada. Isso confirma: o túnel está estabelecido, daí em diante vem a criptografia, e sem as chaves não dá para ir mais fundo — o que é absolutamente normal.
Lendo o handshake TLS sem descriptografia
Mesmo sem ter as chaves, o handshake TLS conta muita coisa. Filtre os registros de handshake:
tls.handshakeEncontrar o ClientHello, onde o cliente se apresenta ao servidor:
tls.handshake.type == 1Encontrar o ServerHello, a resposta do servidor:
tls.handshake.type == 2O que esse par dá? Se você vê o ClientHello, mas nunca vê o ServerHello — o servidor não respondeu ao handshake. Causa: ou o servidor de destino está inacessível atrás do proxy, ou a queda aconteceu antes da resposta. Se você vê os dois, mas depois vem a queda — o problema está mais fundo, já na troca protegida ou no nível da aplicação.
Dentro do ClientHello, sem nenhuma descriptografia, lê-se o campo SNI — o nome do host acessado:
tls.handshake.extensions_server_name == "api.example.com"Você também vê as versões de TLS oferecidas e os conjuntos de cifras. Se o servidor responde com Alert em vez de ServerHello, o handshake foi rejeitado — por exemplo, incompatibilidade de versões ou de cifras. Filtro para os alertas:
tls.alert_messageDiagnóstico pela captura: quem exatamente derrubou a conexão
Chegamos ao coração do artigo. A conexão caiu — a pergunta é quem a derrubou e por quê. O TCP deixa pistas, e por elas é possível dar o veredicto. Vamos ver os sinais-chave.
Encerramento normal: FIN
O fechamento em ordem da conexão acontece pela troca de pacotes FIN. Um lado diz terminei de transmitir, o outro confirma e também envia FIN. É uma despedida educada. Se na captura você vê uma troca caprichada de FIN-ACK-FIN-ACK, a conexão fechou corretamente. A única questão é se o seu cliente esperava esse fechamento. Se o servidor mandou FIN depois de entregar a resposta completa, tudo bem. Se o FIN chegou no meio dos dados esperados — o servidor fechou antes do tempo.
Encerramento abrupto: RST
A flag RST é uma quebra bruta. Não é despedida, é porta batendo. RST significa: essa conexão é inválida, esqueça-a imediatamente. As causas são variadas:
- Porta fechada — não há ninguém escutando do outro lado. O RST chega quase instantaneamente depois do SYN.
- A aplicação do outro lado fechou o socket de forma anormal.
- Um dispositivo intermediário (firewall, balanceador, o próprio proxy) forçou o reset da conexão por timeout ou política.
- Um dos lados recebeu um pacote para uma conexão da qual já tinha esquecido.
A chave do enigma é quem enviou o RST. Olhe o source IP do pacote com RST. Se o RST veio do IP do proxy — quem derrubou foi o proxy ou algo entre o proxy e você. Se veio do IP do servidor de destino — então o segmento proxy-servidor chegou até o servidor, e quem derrubou foi ele ou um dispositivo ao lado dele.
Mas lembre-se dos dois segmentos. Capturando no cliente, você só vê o RST com o IP do proxy, porque não fala diretamente com o servidor — entre vocês está o proxy. Para entender o que acontece no segmento B, é preciso capturar do lado do proxy. Falaremos disso na seção do checklist.
Retransmissões: retransmission
O Wireshark marca automaticamente as retransmissões. Filtro:
tcp.analysis.retransmissionUma retransmissão significa que o remetente não recebeu o ACK do segmento enviado a tempo e o envia de novo. Retransmissões isoladas são normais na internet. Mas uma avalanche de retransmissões é sintoma de perda de pacotes no caminho. Especialmente típico em redes móveis e instáveis.
Filtros úteis relacionados. ACKs duplicados, que sinalizam um segmento perdido:
tcp.analysis.duplicate_ackTodos os eventos problemáticos que o Wireshark conseguiu reconhecer:
tcp.analysis.flagsSe você vê uma série de retransmissões seguida de RST, o quadro se monta: os pacotes se perdiam, um dos lados cansou de esperar e derrubou a conexão. Essa é a história típica de canal ruim.
Zero Window: o receptor se atolou
O TCP tem um mecanismo de controle de fluxo através da janela de recepção. Se o receptor não consegue processar os dados a tempo, ele anuncia zero window — o buffer está cheio, diminua o ritmo. Filtro:
tcp.analysis.zero_windowZero window não é perda de rede, é o sinal de que a aplicação receptora está lenta para ler do socket. Por exemplo, seu cliente recebe uma resposta grande, mas a processa numa única thread e não dá conta. O remetente espera, a janela não abre, e no fim pode estourar o timeout. Se depois do zero window vem um window update, tudo se normalizou. Se depois do zero window vem silêncio e depois RST — o receptor travou ou caiu.
Um sinal relacionado — window full, quando o remetente bate na janela anunciada e não consegue mais enviar:
tcp.analysis.window_fullMatriz de veredictos
Vamos reunir a lógica num framework prático. Olhe os últimos pacotes da conexão viva antes da queda:
- Tem SYN, não tem SYN-ACK, depois RST ou silêncio. A conexão não se estabeleceu. O ponto de destino está inacessível ou a porta está fechada. Ao trabalhar através de proxy, o RST virá do proxy se o servidor atrás dele estiver inacessível.
- O estabelecimento passou, o CONNECT foi enviado, não há resposta. O proxy aceitou o comando, mas não conseguiu alcançar o servidor de destino, ou ele está calado. Espere o timeout.
- Tem ClientHello, não tem ServerHello. O servidor de destino não respondeu ao handshake. O problema está no segmento proxy-servidor.
- Os dados fluíram, depois RST do servidor. O servidor fechou a conexão de forma abrupta — sobrecarga, erro de aplicação, timeout do lado dele.
- Os dados fluíram, depois FIN do servidor no meio da resposta. O servidor fechou em ordem, mas antes do que o cliente esperava — provavelmente limite de tamanho da resposta ou timeout da requisição.
- Avalanche de retransmission, depois RST. Perdas no canal. Procure o problema na rede — conexão móvel, rota sobrecarregada.
- Zero window, depois silêncio. Seu cliente não leu os dados rápido o suficiente. O problema está do seu lado, no processamento.
Descriptografando o próprio tráfego via SSLKEYLOGFILE
Às vezes só os metadados não bastam — é preciso ver o conteúdo da troca criptografada. Isso é legal e correto apenas quando o tráfego é seu próprio: seu cliente, suas chaves, sua aplicação. Não interceptamos tráfego alheio nem trocamos certificados. Pedimos ao nosso próprio cliente que gentilmente grave as chaves de sessão em arquivo, para depois alimentá-las ao Wireshark.
Como funciona
Muitas bibliotecas clientes de TLS suportam a variável de ambiente SSLKEYLOGFILE. Se ela estiver definida, a biblioteca anexa ao arquivo indicado os segredos de sessão num formato padrão. O Wireshark sabe ler esse arquivo e descriptografar as sessões correspondentes na captura. Nada de mágica nem de invasão — o cliente entrega voluntariamente suas chaves, porque você, dono do cliente, assim determinou.
Exemplo para linha de comando e navegadores em motor com suporte
Definir a variável antes de iniciar a aplicação em sistema Unix-like:
export SSLKEYLOGFILE=/home/user/tls-keys.logIniciar o cliente, por exemplo o curl, que suporta essa variável quando compilado com a biblioteca adequada:
SSLKEYLOGFILE=/home/user/tls-keys.log curl -x http://203.0.113.10:8080 https://api.example.com/statusAqui a flag -x define o proxy Proxeon, e o SSLKEYLOGFILE faz gravar as chaves de sessão. Em paralelo, você captura com o tcpdump. Depois disso, você tem tanto o pcap quanto o arquivo de chaves.
Conectando as chaves no Wireshark
No Wireshark, abra as configurações, encontre a seção do protocolo TLS, indique o caminho do arquivo de chaves no campo para o log de pré-master secrets. Depois disso, releia a captura. Os registros TLS antes ilegíveis ficam descriptografados: você vê as requisições e respostas HTTP reais dentro do túnel. Agora o Follow TLS Stream mostra toda a troca de aplicação.
Limites importantes de aplicabilidade
- Só é descriptografado o tráfego cujas chaves entraram no arquivo. Sessões alheias continuam criptografadas — e isso é o certo.
- As chaves são sensíveis. O arquivo tls-keys.log na prática abre o conteúdo das suas sessões. Guarde-o como segredo, delete-o após a depuração.
- O método é destinado à depuração das próprias aplicações, não à observação de tráfego alheio. Essa é uma fronteira ética e jurídica fundamental.
Cenários típicos de queda e como lê-los
A teoria sem padrões reconhecíveis evapora rápido. Vamos ver alguns cenários característicos que você vai encontrar de novo e de novo. Aprenda a reconhecê-los à primeira vista.
Timeout de conexão: servidor atrás do proxy inacessível
Cenário na captura do cliente: o TCP com o proxy se estabeleceu normalmente, o cliente enviou o CONNECT, e veio o silêncio. Não há resposta 200 do proxy. Com o tempo, ou chega um RST do proxy, ou a aplicação mesma fecha a conexão pelo seu próprio timeout.
O que isso significa: o proxy aceitou seu comando, tentou abrir o segmento B com o servidor de destino, mas ele não respondeu. O servidor de destino caiu, a porta está fechada ou a rota até ele está interrompida. Sua ponta e o proxy funcionam normalmente. Ação: verificar a disponibilidade do host de destino, se necessário capturar do lado do proxy para ver o segmento B.
Queda no meio da resposta
Cenário: o túnel foi estabelecido, o TLS funcionou, os dados começaram a fluir, parte da resposta foi recebida, e de repente vem FIN ou RST do lado do servidor. O cliente recebeu resposta incompleta e reclama de conteúdo truncado.
Se for FIN, o servidor fechou em ordem, mas prematuramente — talvez tenha estourado um limite de tempo de geração da resposta ou uma restrição de tamanho do lado dele. Se for RST, o servidor ou um dispositivo ao lado dele cortou de forma abrupta. Ação: se o problema se repete em respostas grandes — procurar timeouts e limites. A descriptografia do próprio tráfego via SSLKEYLOGFILE ajuda a ver se o cabeçalho HTTP foi recebido e quanto do corpo chegou a vir.
Perdas em rede móvel
Cenário: vários pacotes marcados como retransmission, aparecem duplicate ack, observam-se saltos notáveis de tempo entre pacotes. A conexão ou fica dolorosamente lenta, ou acaba caindo por timeout.
É o clássico do canal de rádio instável. Os pacotes se perdem, o TCP os retransmite, a velocidade cai. Redes móveis também tendem a derrubar conexões ociosas por muito tempo através de NAT-timeouts de equipamentos intermediários da operadora: no meio do silêncio, de repente chega um RST, quando um dos lados tenta retomar a troca numa conexão que a operadora já esqueceu. Ação: configurar keep-alives e timeouts razoáveis, novas tentativas no nível da aplicação, não manter conexões ociosas por muito tempo.
Proxy inacessível de todo
Cenário: o cliente manda SYN para o IP e a porta do proxy, mas não recebe SYN-ACK. Ou silêncio e retransmissões de SYN, ou RST instantâneo. Se for silêncio — algo entre você e o proxy filtra pacotes, ou o proxy não está escutando. Se for RST instantâneo — ninguém responde nessa porta. Ação: verificar o endereço e a porta do proxy, a disponibilidade de rede, a correção da configuração.
Cliente lento: zero window
Cenário: a troca flui, mas de vez em quando o cliente anuncia zero window, o remetente pausa, e depois o window update retoma o fluxo. Se isso se repete com frequência, sua aplicação lê do socket mais devagar do que o servidor entrega. Ação: otimizar o processamento da resposta, ler o fluxo numa thread separada, aumentar os buffers.
Erros típicos ao capturar e ler a captura
Experiência é uma coleção de galos na cabeça. Vamos reunir os erros mais frequentes para você não repeti-los.
- Capturar no lugar errado. Você procura a queda no segmento proxy-servidor, mas capturou no cliente, onde esse segmento nem aparece. Sempre pense em qual segmento você precisa e capture no ponto certo.
- Capturar tudo. Sem filtro num servidor carregado, você vai receber gigabytes e se afogar neles. Filtre por host e porta desde o começo.
- Snaplen truncado onde os dados são necessários. Se você quer ver o conteúdo e colocou snaplen curto, a carga útil vai sair truncada e o Follow Stream vai mostrar pedaços.
- Resolução de nomes ligada. Esqueceu a flag -n, e o tcpdump trava no DNS, distorcendo os tempos. Sempre -n na captura.
- Ignorar a direção do RST. Veem o RST e tiram conclusão sem olhar quem o enviou. O source IP do pacote RST é metade da resposta.
- Confundir FIN normal com acidente. FIN é fechamento normal. O motivo de pânico não é o próprio FIN, mas o FIN que chega antes do fim esperado dos dados.
- Esquecer fusos horários e hora exata. Os logs da aplicação e a captura devem estar sincronizados no tempo, senão você não encontra o momento certo. Mantenha o NTP em ordem.
- Guardar o arquivo de chaves SSLKEYLOGFILE. Após a depuração ele deve ser apagado. É um segredo que revela o conteúdo das suas sessões.
- Tirar conclusões de uma única conexão. Problemas intermitentes exigem estatística. Uma requisição que caiu pode ser coincidência, um padrão de dez — diagnóstico.
Ferramentas e recursos do engenheiro
Vamos reunir o arsenal que vale a pena ter à mão ao trabalhar com tráfego de proxy.
Captura
- tcpdump — a ferramenta principal de captura em servidores e no console. Leve, sempre disponível, filtro flexível.
- dumpcap — utilitário de console do pacote Wireshark, feito especialmente para captura eficiente com rotação.
- tshark — o Wireshark de console. Permite aplicar filtros de exibição sem interface gráfica, prático para scripts e servidores remotos.
Análise
- Wireshark — analisador gráfico, decodificadores de centenas de protocolos, sistema poderoso de filtros, Follow Stream, estatísticas por conexão.
- Informações de especialista do Wireshark — painel embutido que destaca anomalias: retransmissões, resets, zero window. Comece a investigação exatamente por ele.
- Estatísticas de conversações — tabela de todas as conexões TCP na captura com bytes e duração. Dá para ver logo qual conexão é anormalmente curta.
Truques úteis de linha de comando
Ver rapidamente o conteúdo do pcap no console via tshark com filtro de exibição:
tshark -r dump.pcap -Y "tcp.flags.reset == 1"Mostrar apenas as requisições CONNECT do arquivo:
tshark -r dump.pcap -Y "http.request.method == \"CONNECT\""Ver todas as retransmissões:
tshark -r dump.pcap -Y "tcp.analysis.retransmission"Esses comandos são impagáveis quando não há gráfico e é preciso resolver aqui e agora, por ssh.
Casos e resultados da aplicação
Nada convence mais do que histórias reais. Vou apresentar casos coletivos que refletem a prática real de engenharia no diagnóstico de tráfego de proxy.
Caso 1: cinco por cento das requisições caem à noite
A equipe de integração reclamava: cerca de cinco por cento das requisições a uma API externa através do proxy caíam com resposta truncada, principalmente à noite. Os logs da aplicação mostravam conteúdo incompleto. Os logs do proxy — túneis estabelecidos sem erro.
Capturamos no cliente com rotação circular por várias horas e com marca exata do erro no log. No momento do incidente, vimos: túnel estabelecido, TLS funcionou, parte do corpo da resposta chegou, depois FIN do proxy. A descriptografia do próprio tráfego via SSLKEYLOGFILE mostrou: chegava o cabeçalho HTTP correto com o tamanho do corpo indicado, mas o corpo se interrompia no meio. Conclusão: o servidor de destino fechava a conexão pelo seu próprio timeout de geração dos relatórios noturnos grandes. A solução do lado da integração foi requisitar os dados paginados em porções menores. O problema sumiu por completo.
Caso 2: o misterioso RST instantâneo
Outro engenheiro recebia um reset instantâneo logo após enviar o CONNECT para um host específico, enquanto para outros hosts tudo funcionava. A primeira suspeita caiu sobre o proxy.
A captura no cliente mostrou: o CONNECT saiu e quase instantaneamente voltou um RST com o IP do proxy. Mas a instantaneidade chamou a atenção — normalmente a indisponibilidade do servidor gera timeout, não reset instantâneo. Capturamos do lado do proxy e vimos o segmento B: o proxy abria conexão com o host de destino na porta certa, e o servidor de destino respondia RST ao SYN — a porta estava fechada. O proxy honestamente transmitiu essa recusa ao cliente. Acabou sendo que o serviço de destino tinha mudado de porta recentemente. Conclusão: RST instantâneo quase sempre é porta fechada, não problema do proxy. A porta correta restaurou o funcionamento.
Caso 3: degradação no segmento móvel
A aplicação em dispositivos móveis, trabalhando através de proxy, perdia a conexão regularmente com parte dos usuários. A captura do dispositivo na zona problemática de cobertura mostrou o quadro clássico: séries de retransmissões, ACKs duplicados, intervalos crescentes, e no final RST depois de uma longa ociosidade — resultado do NAT-timeout da operadora.
Conclusão: a rede, não o proxy e não o servidor. Solução — no nível da aplicação, introduzimos novas tentativas adaptativas, keep-alives razoáveis e tratamento gracioso das quedas com reestabelecimento de conexão. O número de erros visíveis ao usuário caiu várias vezes, embora o canal de rádio tenha permanecido o mesmo. A captura de pacotes permitiu não perder tempo com hipóteses falsas sobre o proxy e focar na causa real.
Insight geral dos casos
Nas três histórias, a captura economizou semanas de troca de e-mails e acusações mútuas entre equipes. Os pacotes não mentem. Assim que aparece na mesa uma captura com a direção do RST, presença ou ausência de ServerHello e o quadro de retransmissões, a discussão sobre o culpado se encerra em minutos. Esse é o principal valor do método: ele tira o diagnóstico do plano das opiniões e o coloca no plano dos fatos.
Checklist de captura para abrir chamado no suporte
Quando você recorre ao suporte — seja do provedor de proxy Proxeon, seja do dono da API de destino — uma captura bem feita acelera a solução várias vezes. Aqui vai um checklist que vale cumprir antes de abrir o chamado.
Antes da captura
- Anote o horário exato do início do diagnóstico e sincronize os relógios por NTP em todas as máquinas envolvidas.
- Defina os pontos de captura: no mínimo no cliente, se possível — também do lado ao qual você tem acesso.
- Reúna os dados de contexto: IP e porta do proxy, nome e porta do host de destino, comportamento esperado e comportamento real.
Durante a captura
- Inicie o tcpdump com filtro por host do proxy e porta de destino, com snaplen completo e rotação:
tcpdump -i eth0 -n -s 0 "host 203.0.113.10 and port 8080" -w support-%Y%m%d-%H%M%S.pcap -C 100 -W 10 - Reproduza o problema e registre o horário exato do incidente com milissegundos a partir do log da aplicação.
- Não esqueça de salvar em paralelo os logs da aplicação do mesmo intervalo.
O que anexar ao chamado
- O próprio arquivo pcap, cortado até o intervalo de tempo relevante, para não enviar gigabytes.
- Os timestamps exatos do incidente e o fuso horário.
- IP e porta do proxy, nome e porta do host de destino, descrição do cenário.
- Trecho dos logs da aplicação com o erro.
- Sua análise preliminar: quem enviou o RST ou FIN, se houve ServerHello, se houve retransmissões. Isso mostra que você fez o dever de casa.
Como cortar o pcap até o intervalo desejado
Um arquivo enorme pode ser recortado por tempo via tshark ou editcap. Exemplo de recorte por número de pacotes ou por filtro:
tshark -r big.pcap -Y "frame.time >= \"2026-01-01 03:00:00\" && frame.time <= \"2026-01-01 03:05:00\"" -w small.pcapUma captura assim, enxuta e focada, o suporte processa rápido, porque não vai precisar procurar agulha no palheiro.
FAQ: perguntas frequentes sobre capturas através de proxy
Por que na captura de tráfego HTTPS através de proxy eu só vejo o CONNECT e depois algo ilegível?
Porque após o estabelecimento do túnel o proxy apenas repassa os bytes TLS criptografados, sem ter as chaves deles. Em texto aberto só vai o comando CONNECT com o nome do host e a resposta do proxy sobre o estabelecimento. Todo o resto está protegido por criptografia — e é exatamente para isso que o HTTPS existe. Para ver o conteúdo do seu próprio tráfego, use o SSLKEYLOGFILE.
Como saber se a conexão foi derrubada pelo servidor de destino e não pelo proxy?
Olhe o source IP do pacote com RST ou FIN. Mas lembre-se dos dois segmentos: numa captura do cliente você só vê o IP do proxy, porque não fala diretamente com o servidor. Para atribuir com certeza a queda ao servidor de destino, é preciso capturar do lado do proxy, onde o segmento proxy-servidor é visível. Se o RST no segmento B vem do IP do servidor — quem derrubou foi ele.
Qual a diferença entre retransmission e RST em termos de diagnóstico?
Retransmission é o reenvio de um segmento não confirmado, sinal de perda de pacotes no canal, mas a conexão ainda está viva e lutando. RST é o encerramento, a ordem de esquecer a conexão. Uma avalanche de retransmissões que vira RST se lê assim: o canal perdia pacotes, o lado cansou de esperar e derrubou. Retransmissões isoladas são normais na internet.
O que significa zero window e o proxy tem culpa nele?
Zero window é anunciado pelo receptor, cujo buffer de recepção está cheio, porque a aplicação está lenta
