AllowCONNECT d'Apache et les ports de destination HTTPS

Votre proxy Apache écoute sur le port 3128. Un client l'atteint correctement, mais un service HTTPS sur le port 8443 échoue. Changer le port d'écoute du proxy ne résoudra probablement pas cette différence précise.

Le client se connecte d'abord à l'écouteur du proxy. Sa requête CONNECT désigne ensuite un hôte et un port de destination distincts. Apache peut accepter la première connexion et refuser la seconde opération.

Lire AllowCONNECT comme une politique de destination

Pour Apache 2.4, mod_proxy_connect gère les requêtes CONNECT entrantes. Sa directive AllowCONNECT contrôle les ports de destination disponibles pour ces requêtes. La valeur par défaut documentée est 443 et 563.

AllowCONNECT 443 8443

Cet exemple sélectionne ces deux ports de destination. Il remplace la sélection par défaut ; il n'ajoute pas 8443 tout en conservant silencieusement tous les ports par défaut. Utilisez la directive dans la configuration du serveur ou de l'hôte virtuel concerné.

Conservez les règles d'autorisation des clients du proxy en place. Un port de destination autorisé ne dit rien sur le client qui peut utiliser le service, et il ne remplace pas une restriction d'hôte de destination lorsqu'une telle restriction est nécessaire.

Un exemple de proxy inverse répond à une autre question

Les résultats de recherche sur Apache et HTTPS montrent souvent un site public qui redirige vers un backend fixe. Cette configuration n'est pas la façon dont un navigateur demande à un proxy direct d'ouvrir un tunnel CONNECT vers un site choisi. Copier ses directives de routage peut laisser le problème initial du proxy intact.

Lors du diagnostic d'un échec, notez l'écouteur atteint par le client, l'autorité CONNECT demandée et la réponse du proxy. Si CONNECT réussit et que TLS échoue ensuite, l'autorisation de port de destination a déjà fait son travail. Poursuivez avec l'échec TLS au lieu d'élargir AllowCONNECT à répétition.