Apache AllowCONNECT and HTTPS Destination Ports

Your Apache proxy listens on port 3128. A client reaches it successfully, but an HTTPS service on port 8443 fails. Changing the proxy's listening port is unlikely to address that particular distinction.

The client first connects to the proxy listener. Its CONNECT request then names a separate destination host and port. Apache can accept the first connection and reject the second operation.

Read AllowCONNECT as a destination policy

For Apache 2.4, mod_proxy_connect handles incoming CONNECT requests. Its AllowCONNECT directive controls the destination ports available to those requests. The documented default is 443 and 563.

AllowCONNECT 443 8443

This example selects those two destination ports. It replaces the default selection; it does not add 8443 while silently retaining every default port. Use the directive in the applicable server or virtual-host configuration.

Keep the proxy's client authorization rules in place. A permitted destination port says nothing about which client may use the service, and it is not a substitute for a destination-host restriction when one is needed.

A reverse-proxy example answers a different question

Search results for Apache and HTTPS frequently show a public website forwarding to a fixed backend. That configuration is not how a browser asks a forward proxy to open a CONNECT tunnel to a selected website. Copying its routing directives can leave the original proxy problem untouched.

When diagnosing a failure, record the listener the client reached, the CONNECT authority it requested, and the proxy's reply. If CONNECT succeeds and TLS fails afterward, the destination-port permission has already done its part. Continue with the TLS failure instead of repeatedly widening AllowCONNECT.