Разум просвещает чувства (Р. Роллан).

Инструкции по настройке обратного прокси-сервера Nginx, Apache и WordPress

Главное меню » Операционная система Linux » Инструкции по настройке обратного прокси-сервера Nginx, Apache и WordPress

03.02.2017

Apache не известен своей скоростью. Напротив, Apache собрал репутацию весьма раздутой и хорошо работает под высоким трафиком. Тем не менее, Apache по-прежнему самый популярный веб-сервер во всем мире и используется многими хостинговыми компаниями из-за его знакомство и htaccess. Если вы все еще любите Apache по какой-то причине, и хотите, ускорить ваш WordPress сайт, вы можете поместить решение кэширования обратным прокси Nginx перед Apache, чтобы предоставить пользователям более быстрый вариант.

Nginx как обратный прокси-кэш работает перед Apache. Nginx прослушивает порт 80, а Apache прослушивает порт 8080. Nginx будет обслуживать любое содержимое, может кэшировать, в то время как все остальные запросы направляются в Apache для обработки PHP с MySQL или MariaDB.

Примечание: Это руководство не будет работать идеально для WooCommerce, новое руководство будет опубликовано для Nginx, который работает для WooCommerce.

Общие сведения об установке

Инструкции по настройке Apache для обратного прокси-сервера Nginx

Файл открытых портов 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 и 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/reverse

Unlink Nginx виртуального хоста по умолчанию

unlink /etc/nginx/sites-enabled/default

Перезапустите Apache и Nginx

sudo service apache2 restart
sudo service nginx restart

Тестирование Nginx обратного прокси-кэша

Мы можем использовать 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.

Магазин Nginx Кэша

Если вы посмотрите в папке proxy_cache_path вы увидите кучу случайных букв и цифр, которые решаются на уровне = 1: 2. Это может показаться странным, поскольку изначально Nginx хранит кэш в виде md5 хэшей URL-адреса на основе proxy_cache_key. мы используем $scheme$host$uri, где

$scheme=http
$host=domain
$request_uri=URL

Так что для этой страницы https://andreyex.ru/kontakty

$scheme is https
$host is andreyex.ru
$request_uri is /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 кэш означает, что мы можем выборочно удалить элементы из обратного прокси-кэша

Очистка и недействительность в Nginx обратного прокси-кэша

Благодаря модулю ngx_cache_purge, который включен в модуль Nginx-extras, у нас есть несколько способов привести к выборочному аннулированию кэша. Наша цель состоит в том, чтобы иметь весь сайт в кэше, используя этот плагин так что ваш WordPress сайт полностью кэшируются и всегда быстро. Когда мы обновляем контент мы хотим, чтобы очистить кэш для этих постов, страниц или категорий, которые изменяются и заменить эти старые элементы свежими новыми сразу, так что ваши пользователи получают самый быстрый возможный опыт.

Nginx прокси кэш хранится в структуре папок в папке /var/run/proxy-cache, в котором мы можем выборочно удалить определенные элементы или удалить все, чтобы очистить весь кэш
BYPASS позволяет принудительно обновить посты или страницы, задавая веб-серверу, где предлагается WordPress для новой версии
- Обновленный элемент заменит устаревший элемент в Nginx обратного прокси-кэша
Метод PURGE, proxy_cache_purge позволяет использовать не RFC методы HTTP для очистки конкретных элементов из кэша
URL /purge, метод позволяет присоединять URL к месту очистки, чтобы очистить определенный элемент

Очистить весь кэш в обратном прокси-сервере Nginx

Если вы хотите очистить весь кэш, вы можете просто удалить содержимое папки прокси-кэша вручную

rm -R /var/run/proxy-cache/*

Можно также удалить определенные элементы, если вы хотите путем создания MD5 хэша полного URL, или вы хотите очистить и удалить конкретную папку и вложенную папку рекурсивно в папке proxy_cache_path.

Если вы хотите очистить весь кэш с помощью регулярных выражений (также известный как групповые символы) ваш единственный вариант заключается в использовании Nginx Plus, который стоит денег. Инженеры Nginx Plus знают, что иметь высокую производительность WordPress сайта означает сохранение всего сайта в кэше все время так, крупные компании будут платить за гибкое управления кэшем.

Обновить продукты в обратном прокси-сервере Nginx с помощью метода BYPASS

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

Обновление элементов в обратном прокси-сервере Nginx с помощью метода PURGE

Метод 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 в Обратном прокси-сервере Nginx с помощью метода /purge URL

Способ /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.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Просмотров поста: 90