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.