Uma porta TCP aberta não prova que um proxy funciona
Uma verificação de porta bem-sucedida apenas estabelece uma conexão. Confira também a negociação do proxy e a resposta esperada do destino.
Uma porta TCP aberta mostra que um listener aceitou uma conexão. Pode ser um proxy, um servidor web comum ou outro serviço; a porta 8080 não identifica o protocolo.
Para um endpoint documentado como proxy HTTP, use seu endereço real em uma requisição HTTPS com limites de tempo:
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/Substitua o endereço de documentação pelo seu endpoint HTTP ou por um candidato da lista de proxies HTTP. Para SOCKS, use o modo de cliente SOCKS correspondente e conclua a negociação. Um handshake incorreto pode falhar logo após a aceitação TCP.
| Etapa observada | O que comprova |
|---|---|
| TCP aceito | O listener está acessível. |
| Handshake do proxy aceito | O listener aceitou esta operação de proxy. |
| TLS do destino verificado | O cliente concluiu a conexão segura pretendida conforme suas configurações de confiança. |
| Status e conteúdo esperados recebidos | A requisição da aplicação produziu o resultado esperado. |
Para HTTPS por um proxy HTTP, CONNECT precisa ser permitido à porta de destino. Mesmo CONNECT 200 é uma etapa intermediária: o túnel pode fechar antes de TLS ou da requisição final ter sucesso. Um sucesso com HTTP sem criptografia não comprova essa capacidade de túnel.
Use um destino com conteúdo previsível, preferencialmente sob seu controle, e inspecione seu registro de requisições quando disponível. Um listener HTTP sem criptografia pode devolver uma página fixa com status 200 sem sequer contatar o destino. Receber algum status de sucesso é uma evidência mais fraca que obter a resposta esperada; a verificação de identidade HTTPS oferece proteção adicional.
Registre a última etapa bem-sucedida. “Porta aberta, negociação SOCKS rejeitada” fornece um ponto de partida útil para a investigação seguinte.