Il listener HTTP di Squid supporta SOCKS?
Separate il protocollo del proxy dai numeri di porta e distinguete il lavoro sperimentale di Squid su SOCKS dal supporto standard del listener HTTP.
Il http_port di Squid accetta traffico proxy HTTP, indipendentemente dal numero di porta. Configurarlo sulla porta 1080 lo lascia un listener HTTP; un client SOCKS invia un handshake diverso.
Un'applicazione che supporta i proxy HTTP può usare l'indirizzo e la porta di Squid nella propria impostazione del proxy HTTP. Le destinazioni HTTPS possono passare attraverso CONNECT, quindi questa impostazione è adatta anche ai siti sicuri quando il proxy consente il tunnel.
Un'applicazione che richiede SOCKS ha bisogno di un servizio che implementi la versione di SOCKS richiesta e dell'autenticazione. Per le rotte pubbliche consentite, scegliete candidati dall'elenco dei proxy SOCKS corrispondenti a quella versione. Un server SOCKS dedicato o un forwarding dinamico SSH locale adatto possono fornire quell'interfaccia.
Supporto sperimentale e proxy a monte
La pagina di sviluppo SOCKS di Squid descrive approcci sperimentali e basati su librerie, con limiti. Non dimostra che un listener HTTP standard pacchettizzato accetti SOCKS5 tramite un interruttore di configurazione.
Far usare SOCKS a monte a Squid è un requisito separato per le sue connessioni in uscita. Un metodo che agisce su quei socket non aggiunge supporto per SOCKS in ingresso.
In caso di disallineamento del protocollo, individuate cosa invia l'applicazione a Squid e cosa invia Squid verso la sua destinazione o il suo parent. Cambiare solo il numero di porta non altera nessuna delle due conversazioni.