ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)
Apache не известен своей скоростью. Напротив, Apache собрал репутацию весьма раздутой и хорошо работает под высоким трафиком. Тем не менее, Apache по-прежнему самый популярный веб-сервер во всем мире и используется многими хостинговыми компаниями из-за его знакомство и htaccess. Если вы все еще любите Apache по какой-то причине, и хотите, ускорить ваш WordPress сайт, вы можете поместить решение кэширования обратным прокси Nginx перед Apache, чтобы предоставить пользователям более быстрый вариант.
Nginx как обратный прокси-кэш работает перед Apache. Nginx прослушивает порт 80, а Apache прослушивает порт 8080. Nginx будет обслуживать любое содержимое, может кэшировать, в то время как все остальные запросы направляются в Apache для обработки PHP с MySQL или MariaDB.
Примечание: Это руководство не будет работать идеально для WooCommerce, новое руководство будет опубликовано для Nginx, который работает для WooCommerce.
Файл открытых портов Apache
sudo nano /etc/apache2/ports.confИзменение порта на 8080
Listen 8080Откройте виртуальный хост Apache
nano /etc/apache2/sites-available/wordpress.confИзменение порта 8080 в виртуальном хосте
<VirtualHost *:8080>
Нажмите Ctrl + X, Y и Enter, чтобы сохранить
Вам нужно будет изменить все ваши виртуальные хосты Apache, чтобы прослушивать порт 8080.
Apache будет возобновлен после того, как будет установлен и настроен, чтобы избежать каких-либо простоев Nginx.
Установите Nginx и Nginx-extras, чтобы получить модуль ngx_cache_purge, который сделает его легче управлять Nginx прокси – кэшэм.
sudo apt-get install nginx nginx-extras -yСоздание конфигурации Nginx
sudo nano /etc/nginx/sites-available/reverseВставьте конфигурацию Nginx, нам нужен буфер в верхней части, чтобы предотвратить эту ошибку ( источник )
upstream sent too big header while reading response header from upstream errors with buffersВот реальная конфигурация кэша Nginx прокси, обратите внимание, что он не оптимизирован для WooCommerce.
#fix 504 gateway timeouts, can go in nginx.conf
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
#set the location of the cached files, zone, name, size (1000 MB) and how long to cache for 600 minutes
proxy_cache_path /var/run/proxy_cache levels=1:2 keys_zone=WORDPRESS-PROXY:10m max_size=1000m inactive=600m;
proxy_cache_key $scheme$host$request_uri;
#prevent header too large errors
proxy_buffers 256 16k;
proxy_buffer_size 32k;
#httpoxy exploit protection
proxy_set_header Proxy "";
server {
listen 80 default;
access_log /var/log/nginx/proxy-access.log;
error_log /var/log/nginx/proxy-error.log;
add_header X-Cache $upstream_cache_status;
set $do_not_cache 0;
set $bypass 0;
#security for bypass
if ($remote_addr ~ "^(127.0.0.1|Web.Server.IP)$") {
set $bypass $http_secret_header;
}
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
location / {
proxy_set_header Host $host;
proxy_redirect off;
proxy_cache WORDPRESS-PROXY;
proxy_cache_revalidate on;
proxy_ignore_headers Expires Cache-Control;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_cache_bypass $bypass $do_not_cache;
proxy_no_cache $do_not_cache;
proxy_cache_valid 200 301 302 500m;
proxy_cache_valid 404 1m;
#can rename PURGE to whatever you want, should restrict it to backend server requests for security
proxy_cache_purge PURGE from 127.0.0.1 Web.Server.IP;
proxy_pass http://127.0.0.1:8080;
}
location ~ /purge(/.*) {
allow 127.0.0.1;
allow Web.Server.IP;
deny all;
proxy_cache_purge WORDPRESS-PROXY $scheme$host$1;
}
}
Нажмите Ctrl + X, Y и Enter
Создадим символические ссылки кэша Nginx обратного прокси для WordPress виртуального хоста, чтобы его включить, когда мы перезапустим Nginx
sudo ln -s /etc/nginx/sites-available/reverse /etc/nginx/sites-enabled/reverseUnlink Nginx виртуального хоста по умолчанию
unlink /etc/nginx/sites-enabled/defaultПерезапустите Apache и Nginx
sudo service apache2 restart
sudo service nginx restartМы можем использовать curl, чтобы проверить, что обратный прокси-кэш Nginx работает на нашем WordPress сайте.
sudo apt-get install curl -yТеперь Curl установлен, мы можем начать тестирование Nginx обратного прокси перед Apache.
Используйте SSH на веб-сервере, чтобы запустить команду cURL. Это позволит проверить, что ваша домашняя страница кэшируется обратным прокси-сервером, а флаг -I гарантирует, что мы получаем заголовки ответа назад от обратного прокси-сервера
curl -I https://andreyex.ru/Ключевое значение здесь статус X-Cache
HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: HIT
Если домашняя страница не кэшируется, вы получите в ответе X-Cache
HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: MISS
Иногда вам может понадобиться cURL тот же URL дважды, чтобы получить ответ HIT.
Если вы посмотрите в папке proxy_cache_path вы увидите кучу случайных букв и цифр, которые решаются на уровне = 1: 2. Это может показаться странным, поскольку изначально Nginx хранит кэш в виде md5 хэшей URL-адреса на основе proxy_cache_key. мы используем $scheme$host$uri, где
Так что для этой страницы https://andreyex.ru/kontakty
Мы можем передать это через md5 генератор на Debian
echo https://andreyex.ru/kontakty | md5sum
Он генерирует эту сумму md5
c301d2e9d39fa7434a56322a09dbab17
Который Nginx использует для создания структуры папок на основе уровней proxy_cache_path = 1: 2
c301d2e9d39fa7434a56322a09dbab17
Из уровней = 1: 2, 1 становится папка верхнего уровня и 2 становится его подкаталог, с оригинальным md5 хэшэм имя файла
/var/run/proxy-cache/7/b1/c301d2e9d39fa7434a56322a09dbab17
Зная, как работает Nginx кэш означает, что мы можем выборочно удалить элементы из обратного прокси-кэша
Благодаря модулю ngx_cache_purge, который включен в модуль Nginx-extras, у нас есть несколько способов привести к выборочному аннулированию кэша. Наша цель состоит в том, чтобы иметь весь сайт в кэше, используя этот плагин так что ваш WordPress сайт полностью кэшируются и всегда быстро. Когда мы обновляем контент мы хотим, чтобы очистить кэш для этих постов, страниц или категорий, которые изменяются и заменить эти старые элементы свежими новыми сразу, так что ваши пользователи получают самый быстрый возможный опыт.
Если вы хотите очистить весь кэш, вы можете просто удалить содержимое папки прокси-кэша вручную
rm -R /var/run/proxy-cache/*Можно также удалить определенные элементы, если вы хотите путем создания MD5 хэша полного URL, или вы хотите очистить и удалить конкретную папку и вложенную папку рекурсивно в папке proxy_cache_path.
Если вы хотите очистить весь кэш с помощью регулярных выражений (также известный как групповые символы) ваш единственный вариант заключается в использовании Nginx Plus, который стоит денег. Инженеры Nginx Plus знают, что иметь высокую производительность WordPress сайта означает сохранение всего сайта в кэше все время так, крупные компании будут платить за гибкое управления кэшем.
Bypass, безусловно, лучший способ обновления Nginx кэша обратного прокси-сервера. С proxy_cache_bypass вы принудительно принесете новую версию URL с веб-сервера под управлением WordPress и замените старую устаревшую версию с новой свежей версии. Ваши пользователи никогда не получат старый контент таким образом, и никогда не будет получать медленную компиляцию PHP на лету с вашего веб-сервера (если только они не являются кэшируемым).
В блоке выше мы реализовали proxy_cache_bypass только для запросов, которые приходят с нашего веб – сервера или сам обратный прокси – сервер
Мы позволили секретный заголовок для входящих запросов от веб-сервера и обратный прокси-сервер, поэтому мы можем проверить с помощью секретного заголовка с Curl из этих серверов.
curl -I https://andreyex.ru -H "secret-header: true"Вы увидите этот вывод , показывающий BYPASSвX-Cache header
HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: BYPASS
Если попробовать ту же Curl команду с другого сервера вы просто увидите ответ HIT
HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:28:26 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Cache: HIT
Метод PURGE любезно предоставлен модулем ngx_cache_purge в пакете Nginx-extras.
Для работы этого метода я нашел proxy_cache_key, который должен был быть установлен в $scheme$host$request_uri, но ваш опыт может варьироваться.
Чтобы отправить запрос на PURGE, используйте этот синтаксис, модуль proxy_cache_purge будет переводить запрос в md5 хэш URL и удалит элемент из папки proxy_cache_path указанного в Nginx обратного прокси-сервера виртуального хоста.
curl -X PURGE -I https://andreyex.ru
Если обратный прокси-сервер имеет файл, то вы получите ответ 200, что означает, успешным
HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 277 Connection: keep-alive
Если Nginx обратный прокси-сервер не имеет такой закэшированный специфический URL то вы получите 404
HTTP/1.1 404 Not Found Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 168 Connection: keep-alive
Если Nginx обратный прокси-сервер обнаруживает, что на вашем IP-адресе не разрешено выполнять запросы PURGE вы получите ответ: 403 Forbidden
HTTP/1.1 403 Forbidden Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 168 Connection: keep-alive
Этот тип Nginx обратного прокси-безопасности имеет важное значение, поскольку он ограничивает запросы PURGE белым списком ваших доверенных серверов
Способ /purge URL использует определенный URL для вызова метода Nginx proxy_cache_purge который мы реализованный выше.
Для очистки с помощью URL используется команда Curl, чтобы очистить домашнюю страницу, представлен слэш
curl https://andreyex.ru/purge/ -I
Вы увидите этот ответ, если домашняя страница кэшируются в обратный прокси-серверt Nginx и вы успешно очистите ее
HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 277 Connection: keep-alive
Если ваш обратный прокси-сервер Nginx не имеет закэшированную домашнюю страницу в WordPress, вы увидите сообщение об ошибке 404
HTTP/1.1 404 Not Found Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 168 Connection: keep-alive
Если ваш обратный прокси-сервер Nginx не позволяет вам получить доступ к местоположению /purge, вы получите ошибку: 403 Forbidden
HTTP/1.1 403 Forbidden Server: nginx/1.8.1 Date: Fri, 03 Feb 2017 13:38:26 GMT Content-Type: text/html Content-Length: 168 Connection: keep-alive
Аналогично методу PURGE мы ограничиваем доступ к месту /purge с помощью белого списка IP-адресов, так что злоумышленники не могут перегрузить ваш веб-сервер под управлением WordPress.
Тэги: , Nginx, настройка Linux, прокси-сервер, ядро Linux Категории: Настройка Linux
