AllowCONNECT de Apache e os portos de destino HTTPS

O seu proxy Apache escoita no porto 3128. Un cliente chega a el correctamente, pero un servizo HTTPS no porto 8443 falla. Cambiar o porto de escoita do proxy probablemente non resolverá esa distinción concreta.

O cliente conéctase primeiro ao escoitador do proxy. A súa solicitude CONNECT indica despois un alias de destino e un porto distintos. Apache pode aceptar a primeira conexión e rexeitar a segunda operación.

Ler AllowCONNECT como unha política de destino

Para Apache 2.4, mod_proxy_connect xestiona as solicitudes CONNECT entrantes. A súa directiva AllowCONNECT controla os portos de destino dispoñibles para esas solicitudes. O valor predeterminado documentado é 443 e 563.

AllowCONNECT 443 8443

Este exemplo selecciona eses dous portos de destino. Substitúe a selección predeterminada; non engade 8443 mentres mantén silenciosamente todos os portos predeterminados. Use a directiva na configuración do servidor ou do host virtual correspondente.

Manteña as regras de autorización de clientes do proxy no seu sitio. Un porto de destino permitido non di nada sobre que cliente pode usar o servizo, e non substitúe unha restrición de host de destino cando é necesaria.

Un exemplo de proxy inverso responde a outra pregunta

Os resultados de busca sobre Apache e HTTPS amosan frecuentemente un sitio web público que reenvía a un backend fixo. Esa configuración non é como un navegador pide a un proxy directo que abra un túnel CONNECT cara a un sitio elixido. Copiar as súas directivas de enrutamento pode deixar o problema orixinal do proxy sen tocar.

Ao diagnosticar un fallo, rexistre o escoitador ao que chegou o cliente, a autoridade CONNECT solicitada e a resposta do proxy. Se CONNECT ten éxito e TLS falla despois, o permiso do porto de destino xa fixo a súa parte. Continúe con o fallo TLS en lugar de ampliar AllowCONNECT repetidamente.