Apache AllowCONNECT и одредишни HTTPS портови
Разликујте порт који клијенти користе за приступ Apache проксију од одредишних портова које mod_proxy_connect дозвољава унутар тунела.
Ваш Apache прокси слуша на порту 3128. Клијент га успешно достиже, али HTTPS услуга на порту 8443 не успева. Промена порта на ком прокси слуша вероватно неће решити ту разлику.
Клијент се прво повезује са слушаоцем проксија. Његов CONNECT захтев затим наводи засебан одредишни хост и порт. Apache може прихватити прву везу и одбити другу операцију.
Читајте AllowCONNECT као одредишну политику
За Apache 2.4, mod_proxy_connect обрађује долазне CONNECT захтеве. Његова директива AllowCONNECT контролише одредишне портове доступне тим захтевима. Документована подразумевана вредност је 443 и 563.
AllowCONNECT 443 8443Овај пример бира та два одредишна порта. Он замењује подразумевани избор; не додаје 8443 док тихо задржава све подразумеване портове. Користите директиву у одговарајућој конфигурацији сервера или виртуелног хоста.
Задржите правила ауторизације клијената проксија. Дозвољени одредишни порт не говори ништа о томе који клијент сме да користи услугу и није замена за ограничење одредишног хоста када је оно потребно.
Пример обрнутог проксија одговара на друго питање
Резултати претраге за Apache и HTTPS често приказују јавну веб страницу која прослеђује на фиксни backend. Та конфигурација није начин на који прегледач тражи од forward проксија да отвори CONNECT тунел до изабране веб странице. Копирање њених директива усмеравања може оставити изворни проблем проксија нетакнутим.
Приликом дијагностике квара забележите слушаоца до ког је клијент дошао, затражени CONNECT ауторитет и одговор проксија. Ако CONNECT успе, а TLS затим не успе, дозвола одредишног порта је већ обавила свој део. Наставите са TLS кваром уместо да изнова ширитете AllowCONNECT.