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 і відповідь проксі. Якщо CONNECT успішний, а TLS згодом зазнає невдачі, дозвіл порту призначення вже виконав свою частину. Продовжуйте з помилкою TLS замість того, щоб раз за разом розширювати AllowCONNECT.