Proxychains Through Squid: CONNECT Restrictions on Port 80
Distinguish ordinary HTTP proxy requests from proxychains HTTP CONNECT tunnels when destination port 80 is denied.
The browser loads an HTTP page through Squid. The same destination fails under proxychains. That does not necessarily mean either program selected the wrong proxy IP.
An ordinary HTTP-aware client can send the web request to the forward proxy in HTTP proxy form. A generic socket wrapper instead needs a byte tunnel for the connection the application wanted to open. For an HTTP proxy in its chain, proxychains uses CONNECT.
That means a plaintext website on port 80 can produce a CONNECT request for port 80. A Squid policy permitting CONNECT only to its approved TLS-port list can reject that tunnel even though normal HTTP requests to port 80 are allowed.
Compare requests, not just hostnames
The proxychains-ng documentation describes its HTTP CONNECT support. Squid's access rules can distinguish method and destination port. These are different request paths to the same website.
Read the rejection and intended policy before changing it. Expanding CONNECT access to every port is a substantial change; it should not be the default response to a wrapper mismatch.
If the application has native HTTP proxy support, using it can avoid an unnecessary generic tunnel for plaintext HTTP. If it genuinely needs a raw TCP tunnel, choose an approved proxy protocol and port policy that supplies one.
A successful browser request is useful evidence about the proxy's reachability and one supported request mode. It does not prove that every tunneling method, destination port, or application protocol is permitted through that proxy.