Назад | Перейти на главную страницу

обратный прокси-сервер apache с конфигурацией кеша лак

У меня есть обратный прокси-сервер Apache, который обслуживает контент с другого сайта через Интернет. Между пользователем и прокси, а также между прокси и исходным сервером существует SSL-сертификат.

В тесте Apache для получения сайта с прокси-сервера постоянно требуется в два раза больше времени, чем непосредственно с исходного сервера. Мне интересно, какой кеш я мог бы настроить, чтобы ускорить это.

Пробовал покрыть лаком, но не понял. У меня это в настройках прокси:

SSLProxyEngine On
<Proxy *>
Order deny,allow
Allow from all
</Proxy> 
ProxyPass /.well-known !

ProxyPreserveHost On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

ProxyPass / https://freakingips.wpengine.com/
ProxyPassReverse / https://freakingips.wpengine.com/

Вы можете видеть, что проблема здесь в том, что proxyPass уже используется для прямого доступа к исходному серверу, но эту конфигурацию необходимо использовать для кеша лака, например:

ProxyPass / http://127.0.0.1:80

Поэтому мне интересно, как я могу настроить лак для этой конфигурации, или какая другая служба кеширования может быть лучше в этом случае.

  1. Включить модули proxy_http и headers
sudo a2enmod proxy_http
sudo a2enmod headers
sudo service apache2 restart
  1. Настройка конфигурации виртуального хоста обратного прокси
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:6081/
RequestHeader set X-Forwarded-Port "443"
RequestHeader set X-Forwarded-Proto "https"
  1. Добавьте директивы RemoteIPHeader и RemoteIPInternalProxy к виртуальному хосту, если хотите получить удаленный IP-адрес.
sudo a2enmod remoteip
sudo service apache2 restart

конфигурации виртуального хоста:

<VirtualHost *:80>
ServerAlias www.sitename.com
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1/32
...
</VirtualHost>

Мне нравится думать о том, как запрос будет проходить через каждую часть настройки от клиента до конечного пункта назначения.

Varnish не передает HTTPS ни с серверными модулями (проксируемым веб-сайтом), ни с клиентами, поэтому я думаю, вам следует выполнить настройку следующим образом для каждого запроса:

Клиентские запросы https://yours.example.com -> Apache SSL (это требуется для поддержки SSL с Varnish) -> Varnish (уровень кэширования) -> Apache http-прокси (это позаботится о выборке данных с удаленного сервера и "разделении" SSL для Varnish, чтобы понять данные)

Таким образом, вы получаете один экземпляр Apache, который имеет два виртуальных хоста, составляющих "бутерброд", описанный выше.

1. Прекращение действия SSL в Apache

Это виртуальный хост Apache, который по сути будет выполнять проксирование запроса к Varnish. При условии, что Varnish хранится в порте по умолчанию (и это совершенно нормально), важным битом здесь будет:

ProxyPass / http://127.0.0.1:6081

Этот виртуальный хост прослушивает SSL-порт 443, поэтому здесь у вас будут такие вещи, как SSLProxyEngine On, сертификаты и др.

2. Лак

В вашем VCL вы должны настроить бэкэнд с портом 80

3. Удаленный прокси Apache

Финал интересен. Здесь вы сохраните свои существующие директивы:

ProxyPass / https://freakingips.wpengine.com/
ProxyPassReverse / https://freakingips.wpengine.com/

Но вам необходимо иметь не только запрос прокси-сервера Apache для удаления сервера через HTTPS, но и доставку его через HTTP. Этот виртуальный хост должен быть только http (там нет директив SSL).

Я не эксперт по Apache, поэтому Google может быть вашим лучшим другом :) это поток, кажется, указывает, что ProxyRequests off Директива необходима для прокси с https на http.