Почему пароль каталога Apache не защищает прямой прокси
Защищённая страница приветствия и авторизованный запрос прямого прокси используют разные контексты конфигурации. Разместите политику прокси в конфигурации сервера или виртуального хоста.
Запрос пароля на главной странице Apache защищает только этот локальный ресурс. Он не доказывает, что произвольные запросы прямого прокси требуют того же входа.
.htaccess относится к поддерживаемой конфигурации каталога; это не окончательный фильтр для каждого запроса. Разделы ProxyRequests и <Proxy> относятся к конфигурации сервера или виртуального хоста. Разместите авторизацию прямого прокси там, используя синтаксис авторизации Apache 2.4 и необходимую настройку аутентификации.
Для частного сервиса сознательно объедините предполагаемые требования к источнику клиента и учётной записи. Затем проверьте виртуальный хост, выбираемый каждым слушателем, включая хосты по умолчанию и унаследованную конфигурацию. Доступ к одному защищённому имени хоста не доказывает, что другой активный хост имеет те же ограничения прокси.
ProxyPass выполняет другую роль — обычно сопоставляет локальное пространство имён с бэкендом. Его добавление не разрешает произвольные цели пересылки.
Если вы можете редактировать только файлы документов одного сайта, вам может не хватать административного охвата, чтобы установить границу доступа этого сервиса. Получите изменение конфигурации сервера или используйте одобренный существующий прокси; пароль каталога не может его заменить.