Un numéro de port SOCKS ne dit pas à Chrome quel protocole utiliser
Spécifiez explicitement le protocole SOCKS là où Chrome le prend en charge. Un port tel que 1080 ou 27977 n'est qu'un port d'écoute.
Un service SOCKS5 sur le port 27977 reste du SOCKS5. Le port 1080 est une convention, pas un détecteur de protocole.
Lorsque vous configurez Chrome via une interface de proxy explicite prise en charge, le schéma identifie le protocole visé, par exemple socks5://proxy.example:27977. La liste de proxys SOCKS5 propose des candidats publics pour ce protocole ; vérifiez l'exigence d'authentification du point de terminaison choisi. Un autre port ne transforme pas SOCKS5 en SOCKS4, et une adresse nue ne garantit pas qu'un paramètre système sera interprété comme la version que vous vouliez.
Vérifiez la configuration effective de Chrome ainsi que le protocole du serveur. Une politique gérée ou un autre processus de navigateur en cours d'exécution peut rendre inopérants les arguments modifiés d'un raccourci. Un profil de test Chrome séparé facilite l'inspection du lancement prévu.
Vérifiez aussi l'authentification avant d'accuser le port. La documentation SOCKS de Chromium indique que sa prise en charge de SOCKS5 n'inclut pas les méthodes d'authentification. Un service exigeant un nom d'utilisateur et un mot de passe SOCKS présente donc un problème de compatibilité qu'un nouveau numéro de port ne peut pas résoudre.
Choisissez un client compatible ou un arrangement de service approuvé. Changer à plusieurs reprises un point de terminaison SOCKS5 connu pour des libellés de protocole sans rapport ne change que les octets envoyés au même écouteur.