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 часта паказваюць публічны сайт, які перанакіроўвае на фіксаваны бэкэнд. Гэтая канфігурацыя не адпавядае таму, як браўзер просіць прамы проксі адкрыць тунель CONNECT да выбранага сайта. Капіраванне яе дырэктыў маршрутызацыі можа пакінуць першапачатковую праблему проксі некранутай.

Пры дыягностыцы збою запішыце слухач, да якога далучыўся кліент, запытаны CONNECT authority і адказ проксі. Калі CONNECT паспяховы, а TLS потым збоіць, дазвол на порт прызначэння ўжо выканаў сваю частку. Працягвайце з збоем TLS, а не з пастаянным пашырэннем AllowCONNECT.