A nossa posição, declarada desde já: somos a Geonode e vendemos proxies, pelo que recebemos muitas mensagens do tipo «o meu proxy não está a funcionar». O mais honesto a dizer, antes de mais nada, é que a porta quase nunca é o problema. Pela nossa experiência, a ordem de probabilidade é a seguinte: credenciais erradas, uma lista de IPs autorizados que se esqueceu de atualizar, utilização da porta HTTP normal para um pedido HTTPS, o destino a bloquear-lhe o acesso e, só depois, um número de porta efetivamente errado. Se estiver a depurar, siga essa lista em vez de experimentar números de porta ao acaso — a última abordagem parece produtiva, mas quase nunca o é.
Dito isto, compreender o que o número significa torna toda a taxonomia de falhas mais compreensível.
O que é, na verdade, uma porta
Uma máquina tem um endereço e vários programas que podem necessitar de tráfego de rede. O número da porta é a forma como o sistema operativo sabe a que programa pertence uma determinada ligação.
O endereço encaminha o pacote para a máquina. A porta encaminha-o para o processo correto nessa máquina. Um único servidor pode executar simultaneamente um servidor web na porta 443, um daemon SSH na porta 22 e um proxy na porta 8080, porque cada ligação transporta uma porta de destino que a encaminha para o ouvinte correto.
No caso específico de um proxy, a porta tem uma função adicional: um único servidor proxy está frequentemente a escutar em várias portas, cada uma configurada de forma diferente. O mesmo software, a mesma máquina, mas um comportamento diferente consoante o número a que se liga. É por isso que o seu fornecedor lhe fornece uma lista em vez de um único valor — um ponto ao qual voltaremos mais tarde.
Os três intervalos de portas
As portas vão de 0 a 65535, e a RFC 6335 divide esse espaço em três intervalos:
| Intervalo | Nome | Números | Atribuição |
|---|
| Sistema | Portas bem conhecidas | 0–1023 | Atribuídas pela IANA |
| Utilizador | Portas registadas | 1024–49151 | Atribuídas pela IANA |
| Dinâmico | Portas privadas ou efémeras | 49152–65535 | Nunca atribuídas |
Na prática, há duas consequências importantes.
As portas do sistema requerem normalmente privilégios elevados para serem ligadas. Em sistemas do tipo Unix, a ligação a uma porta inferior a 1024 requer tradicionalmente o utilizador root. Esta é a razão direta pela qual os proxies ficam convencionalmente na porta 8080 ou 3128, em vez da 80 — executar um proxy como root para ocupar uma porta baixa é uma troca pouco vantajosa por um benefício meramente cosmético.
As portas dinâmicas são a origem das suas próprias ligações. Quando se liga a um proxy na porta 8080, o seu computador escolhe uma porta de origem efémera do intervalo superior. Isto passa despercebido até que leia um registo da firewall e se pergunte por que razão o seu tráfego parece ter origem na porta 51423.
As portas de proxy mais comuns e o que a IANA realmente diz
É aqui que a sabedoria popular e os registos oficiais divergem, e essa divergência é esclarecedora. Estas entradas provêm do Registo de Nomes de Serviços e Números de Portas de Protocolos de Transporte da IANA, extraídas diretamente do ficheiro CSV publicado.
| Porta | Como as pessoas lhe chamam | O que a IANA regista efetivamente |
|---|
| 8080 | A porta de proxy predefinida | http-alt — «HTTP Alternate (ver porta 80)» |
| 3128 | A porta do Squid | ndl-aas — «Porta do servidor API ativo» |
| 1080 | SOCKS | socks — «Socks» |
| 8118 | Privoxy | privoxy — «Proxy HTTP do Privoxy» |
| 8888 | Porta de proxy alternativa | ddi-tcp-1 — «Servidor NewsEDGE TCP (TCP 1)» |
| 9050 | Tor SOCKS | versiera — «Versiera Agent Listener» |
| 8081 | Porta de proxy secundária | sunproxyadmin — «Serviço de administração do proxy Sun» |
Leia essa tabela novamente, porque ela contraria uma suposição comum. Das portas que todos consideram «portas de proxy», apenas a 1080 e a 8118 estão registadas como relacionadas com proxy.
A porta 3128 — universalmente descrita como a porta predefinida do Squid, e que de facto é a porta predefinida do Squid — está registada para algo totalmente alheio a isso. A porta 8888, utilizada por ferramentas de proxy em todo o lado, pertence a um produto de notícias. A porta 9050, que todos os utilizadores do Tor conhecem, está registada para um agente de monitorização.
A lição não é que estas ferramentas estejam a fazer algo de errado. O registo regista atribuições solicitadas, e grande parte do software amplamente implementado simplesmente escolheu um número conveniente, que se tornou uma convenção através do uso e não através do registo. Convenção e registo são sistemas diferentes e, quando entram em conflito, é a convenção que o seu software segue.
A conclusão prática: o número da porta não lhe diz nada de definitivo sobre o que está a escutar. Um proxy pode funcionar em qualquer porta. Os números convencionais existem porque alguém tem de escolher um valor predefinido, não porque o número tenha algum significado.
A porta não determina o protocolo
Este é o erro conceptual mais comum nesta área.
Ligar-se à porta 1080 não significa que a sua ligação seja SOCKS. Ligar-se à porta 8080 não significa que seja HTTP. A porta determina qual o listener que recebe a sua ligação; o protocolo é aquele que esse listener utiliza. Se houver incompatibilidade, a ligação falha de uma forma que muitas vezes é confusa — obtém um tempo de espera esgotado, um reinício da ligação ou uma sequência de bytes ilegíveis, em vez de um erro útil.
Por isso, quando o seu fornecedor lhe fornece um ponto final, precisa de três informações, sendo que a porta é apenas uma delas:
- O anfitrião
- A porta
- O protocolo que essa porta utiliza — HTTP, HTTPS, SOCKS4 ou SOCKS5
A configuração do cliente deve indicar o protocolo explicitamente. No curl, o esquema no argumento -x especifica-o:
curl -x http://proxy.example.com:8080 https://example.com
curl -x socks5://proxy.example.com:1080 https://example.com
curl -x socks5h://proxy.example.com:1080 https://example.com
Esta terceira forma é mais importante do que a diferença entre as duas primeiras. socks5h diz ao curl para enviar o nome de anfitrião ao proxy para resolução; socks5, sem nada a seguir, resolve localmente e envia o endereço. A consequência é uma fuga de DNS: o seu tráfego sai através do proxy, enquanto as suas consultas DNS vão para o seu próprio resolvedor, o que é exatamente o tipo de inconsistência que faz com que uma sessão seja sinalizada. Se estiver a utilizar SOCKS5 para qualquer situação em que seja importante parecer estar noutro local, utilize socks5h.
Como a mesma porta se comporta para HTTP, HTTPS e SOCKS
Os três casos diferem de formas que explicam a maioria dos sintomas confusos.
HTTP simples através de um proxy HTTP. O seu cliente envia o URL completo na linha de pedido e o proxy obtém-no em seu nome. O proxy vê e pode modificar tudo.
HTTPS através de um proxy HTTP. O seu cliente emite um pedido CONNECT e, se o proxy o permitir, abre um túnel TCP e retransmite os bytes sem conseguir lê-los. É por isso que um proxy HTTP processa tráfego HTTPS e que a mesma porta serve ambos.
Daí decorrem diretamente dois modos de falha. Alguns proxies restringem o CONNECT a portas de destino específicas — normalmente a 443 —, pelo que uma solicitação HTTPS para uma porta não padrão é recusada, enquanto a navegação normal funciona. E algumas portas estão configuradas apenas para HTTP simples, com o CONNECT totalmente desativado; o sintoma é que as solicitações HTTP funcionam e as solicitações HTTPS falham, o que parece ser um problema de certificado, mas não é.
SOCKS. A RFC 1928 define SOCKS5 como um protocolo que opera abaixo da camada de aplicação. Não compreende HTTP de todo — retransmite ligações TCP, o que o torna mais geral do que um proxy HTTP. Funciona com protocolos que um proxy HTTP não consegue gerir e não pode realizar nenhuma tarefa específica do HTTP, como o armazenamento em cache ou a reescrita de cabeçalhos.
Se tiver de escolher: proxies HTTP para tráfego web em que possa precisar de gestão de cabeçalhos; SOCKS5 quando precisar de redirecionar algo que não seja HTTP, ou quando quiser que o proxy saiba o mínimo possível.
Por que razão os fornecedores disponibilizam várias portas
Os terminais com várias portas confundem os novatos, mas a lógica é simples: o fornecedor codifica a configuração no número da porta para que não seja necessário transmiti-la de outra forma.
Esquemas comuns:
Comportamento de rotação. Uma porta fornece um novo endereço de saída em cada pedido; outra mantém o mesmo endereço durante uma sessão de alguns minutos. Mesmas credenciais, mesmo anfitrião, porta diferente.
Segmentação geográfica. Um bloco de portas está associado a países ou regiões.
Identidade da sessão. Um intervalo de portas em que cada número corresponde a uma sessão persistente, de modo que ligar-se repetidamente à mesma porta resulta no mesmo endereço de saída.
Protocolo. Uma porta utiliza HTTP, outra SOCKS5.
Alguns fornecedores fazem o mesmo através da sintaxe do nome de utilizador — acrescentando parâmetros ao nome de utilizador em vez de variar a porta. Ambas as abordagens existem e nenhuma é melhor; basta ler a documentação do serviço que adquiriu, porque o resultado de adivinhar é uma solicitação que é bem-sucedida, mas que faz algo diferente do que pretendia.
Vale a pena enfatizar este último ponto. Uma porta errada num esquema de rotação normalmente não produz um erro. Produz uma solicitação funcional com o comportamento errado — persistência de sessão que não pretendia ou um país que não solicitou. Esta é a classe de falhas silenciosas sobre a qual escrevemos em por que é importante testar proxies, e a confusão de portas é uma das suas causas mais comuns.
Resolução de problemas: o que cada erro indica
Erros diferentes apontam para causas diferentes, e interpretá-los corretamente evita muitas suposições.
| Sintoma | Causa provável | Verificação |
|---|
| Ligação recusada, imediatamente | Nada a escutar nessa porta | Número da porta, anfitrião |
| Tempo limite esgotado, sem resposta | Firewall a rejeitar pacotes silenciosamente | Regras de saída, estado do fornecedor |
| 407 Autenticação de proxy necessária | Credenciais erradas ou em falta | Nome de utilizador, palavra-passe, lista de IPs autorizados |
| 403 proveniente do próprio proxy | Autenticado, mas sem permissão | Limites do plano, restrições de destino |
| HTTP funciona, HTTPS não | CONNECT | |
desativado ou restrito nessa porta | Porta do protocolo, documentação do fornecedor |
| Bytes inválidos ou erros de protocolo | Incompatibilidade de protocolo | Esta porta é HTTP ou SOCKS? |
| Funciona, mas país ou sessão incorretos | Porta errada num esquema multiportas | Mapeamento de portas do fornecedor |
A distinção entre «ligação recusada» e «tempo limite esgotado» é a mais útil e a mais negligenciada. «Recusada» significa que houve resposta, mas foi recusada — o equipamento está acessível e nada está a escutar nessa porta. «Tempo limite» significa que não houve qualquer resposta — normalmente, um firewall a rejeitar pacotes, seja do seu lado ou entre si e o proxy. O primeiro caso aponta para um número de porta errado; o segundo quase nunca o faz.
Um teste rápido de isolamento:
nc -zv proxy.example.com 8080
Se houver ligação, a porta está aberta e acessível, e qualquer falha remanescente deve-se à autenticação ou ao protocolo, e não à rede. Se não houver ligação, pare de depurar a sua aplicação — o problema está a jusante dela.
E o caso do código 407 merece uma menção especial, porque é o mais comum de todos e parece um problema de porta para quem nunca o viu antes. Mas não é. Significa que chegou ao proxy com sucesso e que este pede credenciais que não forneceu, ou que forneceu incorretamente. A porta estava correta.
Portas que não deve expor
Isto é relevante se estiver a utilizar o seu próprio proxy em vez de adquirir um.
Nunca exponha um proxy não autenticado à Internet. Um proxy aberto é detetado em poucas horas — todo o espaço de endereços é analisado continuamente — e será utilizado para retransmitir tráfego que não autorizou, atribuído ao seu endereço. As consequências vão desde o seu endereço ser incluído em listas de bloqueio até situações consideravelmente piores. Se um proxy for acessível a partir da Internet, necessita de autenticação.
Restrinja por endereço de origem sempre que possível. Uma lista de endereços IP autorizados, juntamente com credenciais, constitui uma melhoria significativa em relação às credenciais por si só, e não tem qualquer custo.
Não presuma que uma porta invulgar constitui proteção. Mudar um serviço para a porta 47281 não o oculta. A varredura de todo o intervalo de portas de um único anfitrião demora segundos. A obscuridade não lhe traz qualquer benefício mensurável neste caso.
Restrinja os destinos CONNECT. Um proxy que redirecione CONNECT para qualquer porta em qualquer anfitrião é um relé de uso geral. Limitar isso à porta 443 e aos destinos de que realmente necessita reduz substancialmente as possibilidades de abuso caso as credenciais sejam divulgadas.
Configure a ligação ao localhost quando o local for tudo o que precisa. Um proxy utilizado apenas por software na mesma máquina deve estar à escuta em 127.0.0.1, e não em 0.0.0.0. Esta única linha de configuração evita toda uma categoria de problemas e é o erro mais comum em configurações auto-hospedadas.
Perguntas frequentes
Qual é a porta de proxy predefinida?
Não existe uma predefinição universal. A 8080 é a convenção mais comum para proxies HTTP, a 3128 para instalações do Squid e a 1080 para SOCKS. Nenhuma destas é obrigatória — um proxy pode escutar em qualquer porta — e o registo da IANA nem sequer regista a 8080 ou a 3128 como serviços de proxy. Utilize sempre a porta especificada pelo seu fornecedor.
A 8080 é uma porta de proxy?
Por convenção, frequentemente. Oficialmente, a IANA regista a 8080 como «http-alt», descrita como «HTTP Alternate (ver porta 80)» — uma porta alternativa de servidor web, não uma porta de proxy. Tornou-se uma convenção de proxy porque é fácil de memorizar e não requer privilégios de root para a ligação, não porque tenha qualquer significado relacionado com proxy.
Que porta utiliza o SOCKS5?
Por convenção, a 1080, e este é um dos poucos casos em que a convenção coincide com o registo: a IANA lista a 1080 como socks. As implementações individuais variam — a porta SOCKS do Tor tem como predefinição a 9050, que a IANA regista para algo totalmente alheio.
Por que razão o meu proxy funciona para HTTP, mas não para HTTPS?
Quase sempre porque essa porta não permite o método CONNECT, que é a forma como o tráfego HTTPS é encaminhado através de um proxy HTTP, ou porque CONNECT está restrito a portas de destino específicas. Verifique se o seu fornecedor oferece uma porta separada para HTTPS e confirme se a porta de destino à qual se está a ligar está permitida.
Como posso descobrir qual a porta de proxy que devo utilizar?
Consulte a documentação do seu fornecedor. Não há forma de o determinar com fiabilidade através de uma inspeção, porque o número da porta não tem qualquer significado definitivo sobre o que está a escutar. Se tiver de testar, o comando «nc -zv host port» indica-lhe se algo está a escutar, mas não qual o protocolo que utiliza.
Qual é a diferença entre uma porta de proxy e um servidor de proxy?
O servidor é o software e a máquina que processa o seu tráfego. A porta é um dos pontos de entrada numerados dessa máquina a que se liga. Um servidor está frequentemente a escutar em várias portas com configurações diferentes — comportamentos de rotação diferentes, países diferentes, protocolos diferentes —, razão pela qual os fornecedores lhe fornecem uma lista em vez de um único número.
Posso utilizar qualquer porta para um proxy?
Tecnicamente, sim, em qualquer ponto entre 1024 e 65535, sem privilégios especiais. Na prática, utiliza-se as portas que o seu fornecedor atribui, uma vez que estas correspondem à configuração do lado deles. Se utilizar o seu próprio proxy, evite o intervalo dinâmico acima de 49152, pois o seu sistema operativo atribui portas de origem efémeras a partir desse ponto e as colisões causam problemas intermitentes que são verdadeiramente difíceis de diagnosticar.
O número da porta afeta a velocidade do proxy?
Não. A porta é um detalhe de endereçamento sem características de desempenho próprias. Se portas diferentes no mesmo fornecedor apresentarem desempenhos distintos, isso deve-se ao facto de serem encaminhadas através de infraestruturas diferentes ou de comportamentos de rotação distintos, e não ao número em si.
Conclusão
A porta do proxy é um pormenor de encaminhamento: indica à máquina de destino qual o processo em escuta que deve tratar a sua ligação, e nada mais. O número em si não tem qualquer significado oficial, como o registo da IANA demonstra claramente — 3128 não está registado para o Squid, 8888 pertence a um produto de notícias e 9050 é um agente de monitorização. Trata-se de convenções estabelecidas pelo uso, e são essas convenções que o seu software segue.
O que isto significa quando algo corre mal: analise a falha em vez de adivinhar números. «Conexão recusada» indica uma porta errada. Um «timeout» aponta para uma firewall. Um 407 significa que a porta estava correta, mas as suas credenciais não. Erros de protocolo significam que se ligou a um ouvinte SOCKS que esperava HTTP, ou o contrário. Cada sintoma identifica uma camada diferente, e trocar os números das portas só ajuda no primeiro caso.
E quando lhe forem apresentadas várias portas para um ponto de extremidade, consulte a documentação em vez de escolher uma ao acaso. O modo de falha, nesse caso, não é uma mensagem de erro — é um pedido que funciona, mas que, silenciosamente, utiliza o país errado ou o comportamento de sessão incorreto, o que constitui um tipo de erro muito mais dispendioso.
