Um servidor SOCKS5 pode aceitar sua conexão TCP e ainda rejeitar a solicitação para acessar um destino. Leia a resposta na etapa correta antes de decidir qual endpoint falhou.

A seleção de método vem primeiro. A autenticação com usuário e senha, quando escolhida, tem seu próprio resultado. Só depois o servidor devolve a resposta de CONNECT ou de outro comando SOCKS. O valor de um byte de uma etapa não pode ser interpretado pela tabela de outra.

Respostas a solicitações identificam falhas diferentes

Valor da respostaSignificado na resposta a uma solicitação SOCKS5
0x01Falha geral do servidor.
0x02Conexão não permitida pelas regras.
0x03Rede inacessível.
0x04Host inacessível.
0x05Conexão recusada.
0x06TTL expirado.
0x07Comando não suportado.
0x08Tipo de endereço não suportado.

Por exemplo, uma recusa no nível da solicitação é informada depois de chegar ao serviço SOCKS. Isso difere de o sistema operacional recusar a conexão TCP inicial com esse serviço.

Um erro de tipo de endereço pode envolver uma representação IPv4, IPv6 ou de nome de host. Não significa automaticamente que o endpoint inteiro não suporte SOCKS5. Da mesma forma, um comando UDP não suportado não permite concluir nada definitivo sobre uma solicitação TCP CONNECT separada.

Coletar o contexto que torna o código útil

Ao escrever um relatório de erro, guarde com o resultado o endereço do proxy, o comando, o host e a porta de destino, a família de endereços e o modo DNS. Logs de política do servidor ajudam se você administra o endpoint. Uma rejeição por regras pede a verificação da permissão aplicável, não o aumento do tempo limite de conexão.

A resposta é o relato do servidor, não um diagnóstico independente completo da rede de destino. O texto dos clientes também varia. Registre a etapa e a resposta subjacente quando disponíveis, em vez de depender apenas de uma mensagem de erro curta traduzida.

Artigos relacionados