Un serveur SOCKS5 peut accepter votre connexion TCP tout en refusant la demande d’accès à une destination. Lisez la réponse à la bonne étape avant de décider quel point a échoué.

La sélection de méthode vient d’abord. L’authentification par nom d’utilisateur et mot de passe, si elle est choisie, a son propre résultat. Le serveur répond ensuite seulement à CONNECT ou à une autre commande SOCKS. Une valeur d’octet d’une étape ne s’interprète pas avec la table d’une autre.

Les réponses aux requêtes distinguent les échecs

Valeur de réponseSens dans la réponse à une requête SOCKS5
0x01Échec général du serveur.
0x02Connexion interdite par les règles.
0x03Réseau inaccessible.
0x04Hôte inaccessible.
0x05Connexion refusée.
0x06TTL expiré.
0x07Commande non prise en charge.
0x08Type d’adresse non pris en charge.

Par exemple, un refus au niveau de la requête est signalé après avoir atteint le service SOCKS. Il diffère du refus de la connexion TCP initiale vers ce service par votre système d’exploitation.

Une erreur de type d’adresse peut concerner une représentation IPv4, IPv6 ou nom d’hôte. Elle ne signifie pas automatiquement que le point entier ne prend pas SOCKS5 en charge. De même, une commande UDP non prise en charge ne permet aucune conclusion définitive sur une requête TCP CONNECT distincte.

Recueillir le contexte qui rend le code utile

Lors de la rédaction d’un rapport d’erreur, conservez avec le résultat l’adresse du proxy, la commande, l’hôte et le port cibles, la famille d’adresses et le mode DNS. Les journaux de politique côté serveur sont utiles si vous administrez le point. Un refus par les règles invite à vérifier l’autorisation applicable, pas à augmenter le délai de connexion.

La réponse est le rapport du serveur, pas un diagnostic indépendant complet du réseau de destination. Les formulations des clients varient aussi. Notez l’étape et la réponse sous-jacente lorsqu’elles sont disponibles plutôt que de vous fier uniquement à un court message d’erreur traduit.

Articles similaires