Apache AllowCONNECT e portas de destino HTTPS

O seu proxy Apache escuta na porta 3128. Um cliente alcança-o com sucesso, mas um serviço HTTPS na porta 8443 falha. Alterar a porta de escuta do proxy dificilmente resolverá essa distinção.

O cliente primeiro liga-se ao listener do proxy. O seu pedido CONNECT nomeia depois um host e uma porta de destino separados. O Apache pode aceitar a primeira ligação e rejeitar a segunda operação.

Leia o AllowCONNECT como uma política de destino

No Apache 2.4, o mod_proxy_connect trata os pedidos CONNECT recebidos. A sua diretiva AllowCONNECT controla as portas de destino disponíveis para esses pedidos. O valor predefinido documentado é 443 e 563.

AllowCONNECT 443 8443

Este exemplo seleciona essas duas portas de destino. Substitui a seleção predefinida; não acrescenta 8443 mantendo silenciosamente todas as portas predefinidas. Use a diretiva na configuração aplicável do servidor ou do host virtual.

Mantenha as regras de autorização de clientes do proxy em vigor. Uma porta de destino permitida nada diz sobre qual cliente pode usar o serviço, e não substitui uma restrição de host de destino quando esta é necessária.

Um exemplo de proxy reverso responde a outra pergunta

Os resultados de pesquisa para Apache e HTTPS mostram frequentemente um site público a encaminhar para um backend fixo. Essa configuração não é a forma como um navegador pede a um proxy forward que abra um túnel CONNECT para um site escolhido. Copiar as suas diretivas de encaminhamento pode deixar o problema original do proxy intacto.

Ao diagnosticar uma falha, registe o listener alcançado pelo cliente, a autoridade CONNECT pedida e a resposta do proxy. Se o CONNECT tiver sucesso e o TLS falhar depois, a permissão da porta de destino já cumpriu a sua parte. Continue com a falha de TLS em vez de alargar repetidamente o AllowCONNECT.