L'écouteur HTTP de Squid prend-il en charge SOCKS ?
Séparez le protocole du proxy des numéros de port et distinguez le travail expérimental de Squid sur SOCKS du support standard de l'écouteur HTTP.
Le http_port de Squid accepte le trafic proxy HTTP, quel que soit le numéro de port. Le configurer sur le port 1080 le laisse un écouteur HTTP ; un client SOCKS envoie une poignée de main différente.
Une application qui prend en charge les proxys HTTP peut utiliser l'adresse et le port de Squid dans son réglage de proxy HTTP. Les destinations HTTPS peuvent passer par CONNECT, si bien que ce réglage convient aussi aux sites sécurisés lorsque le proxy autorise le tunnel.
Une application qui exige SOCKS a besoin d'un service mettant en œuvre la version SOCKS requise et d'une authentification. Pour les routes publiques autorisées, choisissez des candidats dans la liste de proxys SOCKS correspondant à cette version. Un serveur SOCKS dédié ou un transfert dynamique SSH local approprié peut fournir cette interface.
Prise en charge expérimentale et proxys amont
La page de développement SOCKS de Squid décrit des approches expérimentales et basées sur des bibliothèques, avec des limites. Elle n'établit pas qu'un écouteur HTTP standard empaqueté accepte SOCKS5 via un commutateur de configuration.
Faire utiliser SOCKS en amont à Squid est une exigence distincte pour ses connexions sortantes. Une méthode qui agit sur ces sockets n'ajoute pas de prise en charge de SOCKS entrant.
En cas d'incompatibilité de protocole, identifiez ce que l'application envoie à Squid et ce que Squid envoie vers sa destination ou son parent. Changer uniquement le numéro de port ne modifie aucune des deux conversations.