Apache AllowCONNECT и порты назначения HTTPS

Ваш прокси Apache слушает порт 3128. Клиент успешно подключается к нему, но HTTPS-служба на порту 8443 не работает. Изменение порта прослушивания прокси вряд ли устранит это различие.

Сначала клиент подключается к слушателю прокси. Затем его запрос CONNECT указывает отдельный хост и порт назначения. Apache может принять первое соединение и отклонить вторую операцию.

Читайте AllowCONNECT как политику портов назначения

В Apache 2.4 mod_proxy_connect обрабатывает входящие запросы CONNECT. Его директива AllowCONNECT управляет портами назначения, доступными для этих запросов. Задокументированное значение по умолчанию — 443 и 563.

AllowCONNECT 443 8443

Этот пример выбирает два указанных порта назначения. Он заменяет выбор по умолчанию; он не добавляет 8443, молча сохраняя все порты по умолчанию. Применяйте директиву в соответствующей конфигурации сервера или виртуального хоста.

Сохраняйте правила авторизации клиентов прокси в силе. Разрешённый порт назначения ничего не говорит о том, какой клиент может пользоваться службой, и не заменяет ограничение хоста назначения, когда оно необходимо.

Пример обратного прокси отвечает на другой вопрос

Результаты поиска по Apache и HTTPS часто показывают публичный сайт, пересылающий запросы на фиксированный backend. Такая конфигурация — не то, как браузер просит прямой прокси открыть туннель CONNECT к выбранному сайту. Копирование её директив маршрутизации может оставить исходную проблему прокси нетронутой.

При диагностике сбоя фиксируйте слушатель, к которому подключился клиент, запрошенный полномочие CONNECT и ответ прокси. Если CONNECT проходит, а TLS затем сбоит, разрешение порта назначения уже выполнило свою часть. Переходите к сбою TLS, а не расширяйте AllowCONNECT снова и снова.