Does Squid’s HTTP Listener Support SOCKS?
Separate proxy protocol from port numbers and distinguish experimental Squid SOCKS work from standard HTTP listener support.
Squid's http_port accepts HTTP proxy traffic, regardless of the port number. Configuring it on port 1080 leaves it an HTTP listener; a SOCKS client sends a different handshake.
An application supporting HTTP proxies can use Squid's address and port in its HTTP proxy setting. HTTPS destinations can pass through CONNECT, so this setting is also suitable for secure websites when the proxy permits the tunnel.
An application requiring SOCKS needs a service implementing the required SOCKS version and authentication. For permitted public routes, choose candidates from the SOCKS proxy list matching that version. A dedicated SOCKS server or an appropriate local SSH dynamic forward can provide that interface.
Experimental support and upstream proxies
Squid's SOCKS development page describes experimental and library-based approaches with limitations. It does not establish that a standard packaged HTTP listener accepts SOCKS5 through a configuration switch.
Making Squid use SOCKS upstream is a separate requirement on its outgoing connections. A method affecting those sockets does not add incoming SOCKS support.
For a protocol mismatch, identify what the application sends to Squid and what Squid sends toward its destination or parent. Adjusting the port number alone changes neither conversation.