Проксирование запросов в nginx с помощью proxy_pass
Содержание
- Nginx proxy pass, настройка проксирования запросов в nginx
- Настройка прокси Nginx
- Test com
- Проксируем и спасаем
- Примеры настройка Nginx прокси
- Nginx. Обратный прокси-сервер
- Вопрос: nginx proxy_pass на основе метода запроса POST, PUT или DELETE
- Инструкции по настройке обратного прокси-сервера Nginx, Apache и..
- Кэширование прокси-сервера Nginx
- How To: Проксирование в приватный AWS S3 через Nginx
Nginx proxy pass, настройка проксирования запросов в nginx
Средствами Nginx можно настроить различные серверные конфигурации, часто возникает необходимость организовать проксирование, т.е.
перенаправление запросов с одного адреса на другой, доменное имя в адресной строке браузера при этом должно оставаться прежним.
В Nginx proxy pass является основной директивой, нужной для проксирования всегда, дополнительный функционал реализуется за счет других правил, прописывающихся в том же файле.
В примере рассматривается настройка проксирования запросов с subdomain.example.com на https://subdomain.example.ru/suf
На сервере, на котором настраивалось проксирование применяется Apache в качестве бэкенд сервера и Nginx в качестве фронтенд сервера. Проксирование реализовано на уровне фронтенда, т.е. до Apache запросы не доходят.
Содержание конфигурационного файла:
server <
server_name subdomain.example.com;
listen *:80;
proxy_read_timeout 200s;
access_log off;
include static.conf;
location / <
root /var/www/sites/subdomain.example.com;
proxy_pass https://subdomain.example.ru/suf;
proxy_set_header X-Forwarded-Host subdomain.example.com:80;
proxy_set_header X-Forwarded-Server subdomain.example.com;
proxy_set_header X-Forwarded-For https://subdomain.example.ru/suf;
static.conf здесь — отдельный файл в котором заданы настройки кэширования, также они могут задаваться в любом другом конфиге.
За счет приведенных ниже директив реализуется реверсивное проксирование запросов, это аналог ProxyPassReverse в Apache:
proxy_set_header X-Forwarded-Host subdomain.example.com:80;
proxy_set_header X-Forwarded-Server subdomain.example.com;
proxy_set_header X-Forwarded-For https://subdomain.example.ru/suf;
Добавив конфиг активируем его обычным способом — через создание симлинка
Проверяем конфигурацию веб-сервера
Если ошибок нет — даем команду на перечитывание конфигов
Директива nginx proxy redirect
Схожим образом можно настроить в конфигурационном файле nginx редирект с одного адреса на другой.
Применяя аналогичный конфигурационный файл, но с раскомментированный директивой proxy_redirect можно получить перенаправление, при этом адрес сайта в адресной строке браузера будет подменяться.
Очень часто используется простое проксирование на IP адрес из приватной сети
location / <
root /var/www/sites/example.com;
proxy_pass https://127.0.0.10;
С самой простой реализацией Nginx proxy pass, приведенной выше, запускаются проекты на NodeJS и фреймоворке Express. Изначально они стартуют на localhost и порту 3000
Настройка прокси Nginx
Apache и Nginx это два самых популярных и наиболее часто используемых веб-серверов с открытым исходным кодом. Оба веб-сервера имеют свои преимущества и недостатки, вы можете ознакомиться с ними более подробно в статье Nginx vs Apache.
Было бы отлично объединить эти программы, чтобы получить преимущества обоих и свести к минимуму недостатки. Это вполне возможно.
Для этого достаточно использовать Nginx в качестве прокси для Apache, такая практика очень распространена среди системных администраторов.
В этой статье мы рассмотрим как выполняется настройка прокси Nginx, а также поговорим как заставить эту связку правильно обрабатывать HTTPS запросы и передадим управление статическими файлами Nginx.
Как это будет работать?
Допустим, у нас есть несколько доменов example.com, sample.org, test.io. Первые два будут обрабатываться Apache, последний только Nginx. Все запросы будут поступать к Nginx, который работает на порту 80, если это запрос к одному из доменов Apache и он требует работы PHP, тогда он будет передан веб-серверу Apache, который работает на порту 8080.
Если же это запрос статического файла, то мы будем обрабатывать его тут же с помощью Nginx для увеличения производительности. Что касается поддержки SSL, то мы собираемся использовать модуль mod_pref чтобы заменить все необходимые заголовки для нормальной работы связки. Начнем с настройки Apache.
Настройка Apache для работы прокси
Мы не будем подробно рассматривать как настроить Apache в вашей системе, все это уже описано в статье настройка Apache, сегодня же мы остановимся на настройках, необходимых для работы прокси.
Мы будем использовать Apache с интерпретатором PHP, установленным в виде модуля php-fpm. Это обеспечит лучшую общую производительность системы. Сначала установим все нужные пакеты:
sudo apt install apache2 libapache2-mod-fastcgi php-fpm
Поскольку нам нужно, чтобы Apache работал на порту 8080 нужно изменить конфигурационные файлы веб-сервера:
sudo vi /etc/apache2/ports.conf
Замените значение строки Listen с 80 на 8080, затем сохраните изменения в файле. Далее изменим порт для веб-сайта по умолчанию:
sudo vi /etc/apache2/sites-available/000-default.conf
Точно так же замените значение порта с 80 на 8080. Затем сохраните изменения и перезапустите веб-сервер:
sudo systemctl reload apache2
Теперь вы можете проверить на каком порту будет ожидать соединений Apache, если все было сделано правильно, то это будет 8080:
sudo netstat -tlpn
Чтобы показать настройку прокси Nginx более наглядно, создадим один виртуальный хост (домен). Сначала создадим каталог для нашего хоста:
sudo mkdir /var/www/test.com/
Затем файлы index.html и phpinfo.php:
Test com
” | sudo tee /var/www/test.com/index.html
Затем настроим файлы конфигурации виртуальных хостов для каждого из доменов:
sudo vi /etc/apache2/sites-available/test.com.conf
ServerName test.com ServerAlias www.test.com DocumentRoot /var/www/test.com AllowOverride All
Обратите внимание на порт, тут тоже нужно указать 8080. Для тестирования работы php нам понадобится скрипт с вызовом функции:
echo “” | sudo tee /var/www/test.com/phpinfo.php
Осталось включить конфигурацию для только что созданного сайта и перезапустить веб-сервер:
sudo a2ensite test.com
sudo apachectl -t
sudo systemctl reload apache2
Настройка Apache для php-fpm
По умолчанию в Apache используется модуль mod-php для выполнения php скриптов. Сначала необходимо его отключить:
sudo a2dismod php7.0
Затем мы настроим работу mod_fastcgi с помощью модуля mod_actions, для этого нужно его активировать:
sudo a2enmod actions
Затем создадим конфигурационный файл fastcgi.conf:
sudo vi /etc/apache2/mods-available/fastcgi.conf
AddHandler fastcgi-script .fcgi #FastCgiWrapper /usr/lib/apache2/suexec FastCgiIpcDir /var/lib/apache2/fastcgi AddType application/x-httpd-fastphp .
php Action application/x-httpd-fastphp /php-fcgi Alias /php-fcgi /usr/lib/cgi-bin/php-fcgi FastCgiExternalServer /usr/lib/cgi-bin/php-fcgi -socket /run/php/php7.0-fpm.
sock -pass-header Authorization Require all granted
Сохраните изменения, активируйте модуль и проверьте конфигурацию веб-сервера:
sudo a2enmod fastcgi
sudo apachectl -t
Вы увидите сообщение, что с синтаксисом конфигурационных файлов все хорошо. Если программа выдаст сообщение Could not reliably determine the server's fully qualified domain name, using 127.0.1.1, его можно игнорировать. Далее перезапустите Apache:
sudo systemctl restart apache2
Проверка работы Apache
Добавьте свои домены в файл hosts, если они не зарегистрированы и доступны только с локальной машины:
sudo vi /etc/hosts
Затем откройте сайт в браузере, чтобы убедится, в том что все работает:
Теперь, когда Apache полностью готов к работе в качестве веб-сервера, перейдем к настройке прокси сервера Nginx, мы можем заняться настройкой самого Nginx. Как я уже сказал, мы будем перенаправлять все динамические запросы к Apache, чтобы пользователь смог получить поддержку файлов htaccess и другие преимущества, а статические файлы будем обрабатывать в Nginx.
Сначала установите Nginx, если вы этого еще не сделали:
sudo apt install nginx
Дальше создадим виртуальный хост Nginx с несколькими доменами, с помощью которого и будет выполняться проксирование Nginx:
sudo vi /etc/nginx/sites-available/apache
server_name test.com www.test.com;
Для использования nginx в качестве прокси мы передаем в команде proxy_pass адрес и порт веб-сервера, а в заголовках передаем те значения, которые будут нужны Apache для правильного формирования документа. Сохраните файл и активируйте его:
sudo ln -s /etc/nginx/sites-available/apache /etc/nginx/sites-enabled/apache
Затем проверьте конфигурацию и перезапустите Nginx:
sudo systemctl reload nginx
Теперь вы можете проверить работу вашего сайта в браузере, если вы откроете скрипт phpinfo, то увидите, что он был обработан с помощью Apache, но возвращен Nginx.
Как вы могли убедится, теперь применяется nginx в качестве прокси. Теперь можно закрыть прямой доступ к Apache из сети с помощью iptables:
sudo iptables -I INPUT -p tcp dport 8080 ! -s your_server_ip -j REJECT reject-with tcp-reset
Настройка правильной работы SSL
Дальше рассмотрим как выполняется настройка https прокси Nginx. Как я уже сказал, для правильной работы SSL нам понадобится модуль Apache mod_rpaf. Он устанавливает заголовки и переменные таким образом, чтобы прокси мог без проблем использовать https. Его можно установить из официальных репозиториев:
sudo apt install libapache2-mod-rpaf
Затем создайте конфигурационный файл для этого модуля:
sudo vi /etc/apache2/mods-available/rpaf.conf
RPAFEnable On RPAFHeader X-Real-Ip RPAFProxyIPs ваш_внешний_ip_адрес RPAFSetHostName On
Строка RPAFProxyIPs задает IP адрес вашего прокси. После завершения настройки активируйте модуль:
sudo a2enmod rpaf
Осталось перезапустить Apache:
sudo systemctl reload apache2
Дальше нам нужно создать наши сертификаты с помощью OpenSSL:
sudo mkdir /etc/nginx/ssl/
sudo openssl req -x509 -sha256 -newkey rsa:2048 -keyout /etc/nginx/ssl/test.com-key.pem -out /etc/nginx/ssl/test.com-cert.pem -days 3650 -nodes
А файл виртуальных хостов с поддержкой SSL теперь будет выглядеть во так:
sudo nano /etc/nginx/sites-available/apache
server_name test.com www.test.com;
ssl on; ssl_certificate /etc/nginx/ssl/test.io-cert.pem;
Сохраните файл конфигурации и перезапустите Nginx:
nginx -t
$ sudo systemctl restart nginx
Теперь вы можете открыть наш домен в браузере по HTTS и убедится что прокси отлично работает. Обратите внимание, что если вы используете самоподписанный сертификат, то вам придется добавить его в исключения браузера:
Поддержка защищенного протокола включена и SERVER_PORT имеет значение 443, все работает прозрачно, как бы проксирование nginx не осуществляется, а мы направляем запросы непосредственно к Apache.
Статические файлы через Nginx
Чтобы уменьшить нагрузку на Apache мы можем обрабатывать все статические файлы в Nginx, как правило, это очень сильно увеличивает выдерживаемую нагрузку, поскольку Nginx способен работать быстрее с большим количеством подключений и занимать меньше ресурсов.
Нам нужно добавить несколько строк в /etc/nginx/sites-available/apache
server_name test.com www.test.com;
ssl on; ssl_certificate /etc/nginx/ssl/test.com-cert.pem;
root /var/www/test.com;
index index.php index.htm index.html;
Мы устанавливаем корень сайта в /var/www/test.com, и пытаемся отдать оттуда все статические файлы, а файлы с расширением .php будем обрабатывать в Apache. Также дополнительно мы закрываем доступ ко всем скрытым файлам.
Теперь откройте несколько раз сайт в браузере, динамические страницы phpinfo.php и статическую index.html, а затем посмотрите в лог файл, где вы обнаружите что Apache обрабатывает только динамику:
Теперь проксирование Nginx работает так же как и на большинстве серверов интернета.
Выводы
В этой статье мы рассмотрели как выполняется настройка прокси Nginx, а точнее, как использовать nginx как прокси для Apache. Для новичков эти настройки могут показаться сложными, но если разобраться, то все обязательно получится. Если у вас остались вопросы, спрашивайте в комментариях.
Проксируем и спасаем
ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов.
Для одних это важнейшая политическая тема, для других повод изучить технологии шифрования и защиты анонимности, для третьих просто очередной странный закон, который приходится исполнять на бегу. Мы же поговорим о технологическом аспекте.
В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить IP и назначить любое доменное имя. Мы даже попробуем спрятать домен в url, после чего можно сохранить локально полную копию сайта.
Все упражнения можно сделать на любом виртуальном сервере — лично я использую хостинг Хетцнер и OS Debian. И конечно мы будем использовать лучший веб-сервер всех времен и народов — NGINX!
К этому абзацу пытливый читатель уже приобрел и настроил какой нибудь выделенный сервер или просто запустил Linux на старом компьютере под столом, а так же запустил Nginx последней версии со страничкой «Save me now».
Перед началом работы необходимо скомпилировать nginx c модулем ngx_http_substitutions_filter_module, прежнее название — substitutions4nginx.
Дальнейшая конфигурация будет показана на примере сайта www.6pm.com. Это сайт популярного онлайн магазина, торгующего товарами с хорошими скидками. Он отличается категорическим нежеланием давать доступ покупателям из России. Ну чем не оскал цензуры капитализма?
У нас уже есть работающий Nginx, который занимается полезными делом — крутит сайт на системе Livestreet о преимуществах зарубежного шоппинга. Чтобы поднять зеркало 6pm прописываем DNS запись с именем 6pm.pokupki-usa.ru который адресует на IP сервера.
Как вы понимаете, выбор имени для суб-домена совершенно произволен. Это имя будет устанавливаться в поле HOST при каждом обращении к нашему новому ресурсу, благодаря чему на Nginx можно будет запустить виртуальный хостинг.
В корневой секции конфигурации nginx прописываем upstream — имя сайта-донора, так будем его называть в дальнейшем. В стандартных гайдах сайт обычно называется back-end, а reverse-proxy называется front-end.http < … upstream 6pm < server www.6pm.
Дальше нужно создать секцию server, вот как она выглядит
Стандартные директивы listen и server определяют имя виртуального хоста, при обращении к которому будет срабатывать секция server. Файлы логов лучше сделать отдельными.
Объявляем корневой локейшин, указываем путь до его хранилища — root /var/www/6pm; затем используем try_files. Это очень важная директива nginx, которая позволяет организовать локальное хранилище для загруженных файлов. Директива сначала проверяет нет ли файла с именем $uri и если не находит его — переходит в именованный локейшин @ static
В нашем случае конструкция используется только для подмены файла robots.txt, чтобы запретить индексацию содержимого сайта. Однако таким образом делается зеркалирование и кеширование в nginx.
include '6pm.conf' — логика модуля substitutions.
proxy_cookie_domain — новая функция, которая появилась в nginx версии 1.1.15, без этой директивы приходилось делать так. Больше не нужно ломать голову, прописываете одну строчку и куки просто начинают работать.
proxy_set_header Accept-Encoding “”; — очень важная команда, которая заставляет сайт донор отдавать вам контент не в сжатом виде, иначе модуль substitutions не сможет выполнить замены.
proxy_set_header Host — еще одна важная команда, которая в запросе к сайту донору выставляет правильное поле HOST. Без нее будет подставляться имя нашего прокси сервера и запрос будет ошибочным.
proxy_pass — прямая адресация не работает в именованном локейшине, именно поэтому мы прописали адрес сайта донора в директиве upstream.
proxy_redirect
Примеры настройка Nginx прокси
by Денис Туляковin wiki on 2016-05-20 | tags: Nginx proxy | comments
301 Moved Permanently, редирект, говорящий что ресурс перемещен на постоянной основе.
В интернетах пишут что мол типа архинеобходимо для SEO, мол поисковики это дюже уважают), спорить не буду, не вникал.
В веб сервере Nginx 301 редирект настраивается в конфигурационном файле ( в apache можно через файл .htaccess ), таким образом:
1 вариант
2 вариант
Балансировщик
проксирование простой вариант
проксирование вариант с балансировкой
проксирование вариант с балансировкой
проксирование вариант с балансировкой Hash и IP hash Для каждого запроса Nginx вычисляет хэш, который состоит из текста, переменных веб-сервера или их комбинации, а затем сопоставляет его с бэкендами Для вычисления хэша используется схема (http или https) и полный URL
IP hash работает только с HTTP, это предопределенный вариант, в котором хэш вычисляется по IP-адресу клиента Если адрес клиента IPv4, то для хэша используется первые три октета, если IPv6, то весь адрес
- max_fails задает количество неудачных попыток подключений, после которых бэкенд определенное время считается недоступным
- fail_timeout время, в течение которого сервер считается недоступным
- round-robin Веб-сервер по умолчанию распределяет запросы равномерно между бэкендами (но с учетом весов). Этот стандартный метод в Nginx, так что директива включения отсутствует
- least_conn Запросы сначала отправляются бэкенду с наименьшим количеством активных подключений (но с учетом весов) Если количество активных соединений одинаково, то дополнительно используется метод round-robin
- max_fails задает количество неудачных попыток подключений, после которых бэкенд определенное время считается недоступным
- fail_timeout время, в течение которого сервер считается недоступным
Ссылки
Nginx. Обратный прокси-сервер
Под обратным проксированием обычно понимается процесс, в котором сервер, получающий запрос от клиента не обрабатывает его полностью самостоятельно, а частично или целиком отправляет этот запрос для обработки другим (upstream) серверам. То есть, не перенаправляет клиента, а самостоятельно отправляет запрос и возвращает полученный ответ обратно клиенту. Что это даёт?
Используя обратное проксирование вы можете:
- скрыть инфраструктуру ваших серверов, обслуживающих сайт;
- использовать application firewall, что даст вам централизованно анализировать входящий/исходящий трафик, не нагружая этим upstream-серверы;
- переместить SSL с upstream-серверов на прокси;
- балансировать нагрузку между upstream-серверами;
- кэшировать статический и динамический контент, сжимать отправляемые данные самостоятельно, снижая общую нагрузку на upstream-серверы;
В Nginx функционал проксирования обеспечивается модулем HttpProxy, который компилируется по умолчанию, если при сборке Nginx вы явно не отключили его.
Во всех современных дистрибутивах Nginx поставляется собранным с поддержкой проксирования, так что обычно никаких лишних телодвижений делать не нужно.
Тем, кто не читал предыдущих моих статей об Nginx и тем, что забыл, напоминаю о том, что все действия, описываемые в этой серии статей, тестировались и выполнялись на Debian 5 «Lenny» и в незначительной степени могут отличаться от требуемых в вашей системе.
Итак, давайте начнём экспериментировать!
Допустим, у нас имеется два сервера:
- frontend-сервер Nginx, IP-адрес 192.168.0.1, порт 80;
- upstream-сервер Apache2, IP-адрес 192.168.0.2, порт 80;
Начнём с малого: настроим проксирование абсолютно всех запросов, приходящих на frontend-сервер к upstream-серверу. Создайте отдельный файл конфигурации виртуальных хостов в /etc/nginx/sites-available/proxy со следующим содержимым:
access_log /var/log/nginx/proxy.log; proxy_pass http://192.168.0.2;
Не забудьте сделать соответствующий симлинк в каталог /etc/nginx/sites-enabled/ и перезапустить сервер:
# ln -s /etc/nginx/sites-available/proxy /etc/nginx/sites-enabled/proxy# /etc/init.d/nginx restart
Как видите, ничего революционно нового. Уже знакомые директивы server и location. Что нового, так это директива proxy_pass. Вложенная в location, она определяет URL сервера, к которому будет выполняться проксирование.
От рассмотренной выше конфигурации на практике толку мало, разве что Nginx установлен у вас на файрволе и нет прямого доступа к upstream-серверу из Интернет.
Давайте слегка усложним конфигурацию нашего серверного парка. Представим, что по каким-то причинам все файлы изображений у нас находятся на другом сервере с IP-адресом 192.168.0.3, порт 80.
Таким образом, необходимо все запросы, содержащие в URI расширения графических файлов, перенаправить на этот самый сервер.
Всё очень просто, нужно лишь добавить ещё один location, который и будет брать картинки с другого сервера:
access_log /var/log/nginx/proxy.log; proxy_pass http://192.168.0.2; location
Выполнять проксирование вовсе необязательно к другим серверам, это можно делать и в пределах localhost'а.
Например, у вас на сервере работает Apache, довольно сильно нагруженный каким-нибудь PHP-приложением.
Зачем нагружать Apache ещё больше, поручая ему ещё и отдачу статических файлов? Не лучше ли вручить бразды правления статическим контентом Nginx'у, который с этой задачей справляется на порядок быстрее.
access_log /var/log/nginx/proxy.log; proxy_pass http://127.0.0.1:8080;
Обратите внимание на содержимое второго location'a: при запросе php-файлов, Nginx будет проксировать запрос к локальному интерфейсу, на порт 8080, то есть конфигурацию вашего Apache необходимо изменить, чтобы он ожидал соединения на указанном адресе и порту.
На сегодня пока всё. Но это далеко не всё, что касается обратного проксирования. Предвкушая возгласы «тема сисек не раскрыта», сообщаю о том, что в будущих статьях об Nginx планируется рассмотреть настройку кэширования, балансировку нагрузки к upstream-серверам, а также, я надеюсь, многое-многое другое. Stay tuned 😉
Вопрос: nginx proxy_pass на основе метода запроса POST, PUT или DELETE
У меня два iKaaro экземпляры, запущенные на портах 8080 и 9080, где экземпляр 9080 доступен только для чтения.
Я не уверен, как использовать nginx, например, если метод запроса POST, PUT, DELETE, тогда отправьте экземпляр записи (8080), иначе отправьте экземпляр 9080.
Я сделал что-то, используя местоположение, используя регулярное выражение, но это неверно.
Из http://wiki.nginx.org/HttpLuaModule я вижу, что есть «константы метода HTTP», которые можно вызывать, поэтому правильно добавить блок местоположения как:
Ответы:
Я просто сделал быстрый тест, и это сработало для меня:
Я предполагаю, что у вас есть основы. I.E., вы установили Lua 5.1 или, еще лучше, LuaJIT 2.0 на свой сервер, скомпилировали Nginx с модулем ngx_lua и настроили ngx_lua по мере необходимости.
С этим на месте, это сделает работу:
ОБНОВИТЬ
Если кто-то ищет способ просто создать условия по методу запроса, синтаксис следующий:
if ($request_method = DELETE )
Я бы рекомендовал функцию отображения nginx. Это выходит за пределы вашего блока местоположения:
Затем в вашем блоке местоположения:
Это тоже все регулярные выражения, поэтому вы можете делать такие вещи, как:
Плюс это позволяет избежать использования, если вообще. Это довольно здорово. Я использовал его, чтобы направлять весь трафик записи в кластере WordPress на один сокет FastCGI TCP на удаленном узле, но отправлять трафик чтения в локальный сокет FastCGI UNIX.
Инструкции по настройке обратного прокси-сервера Nginx, Apache и..
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
Откройте виртуальный хост Apache
Изменение порта 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
* “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
Нажмите Ctrl + X, Y и Enter
Создадим символические ссылки кэша Nginx обратного прокси для WordPress виртуального хоста, чтобы его включить, когда мы перезапустим Nginx
sudo ln -s /etc/nginx/sites-available/reverse /etc/nginx/sites-enabled/reverse
Unlink Nginx виртуального хоста по умолчанию
Перезапустите 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
Который Nginx использует для создания структуры папок на основе уровней proxy_cache_path = 1: 2
Из уровней = 1: 2, 1 становится папка верхнего уровня и 2 становится его подкаталог, с оригинальным md5 хэшэм имя файла
Зная, как работает Nginx кэш означает, что мы можем выборочно удалить элементы из обратного прокси-кэша
Очистка и недействительность в Nginx обратного прокси-кэша
Благодаря модулю ngx_cache_purge, который включен в модуль Nginx-extras, у нас есть несколько способов привести к выборочному аннулированию кэша.
Наша цель состоит в том, чтобы иметь весь сайт в кэше, используя этот плагин так что ваш WordPress сайт полностью кэшируются и всегда быстро.
Когда мы обновляем контент мы хотим, чтобы очистить кэш для этих постов, страниц или категорий, которые изменяются и заменить эти старые элементы свежими новыми сразу, так что ваши пользователи получают самый быстрый возможный опыт.
- Nginx прокси кэш хранится в структуре папок в папке /var/run/proxy-cache, в котором мы можем выборочно удалить определенные элементы или удалить все, чтобы очистить весь кэш
- BYPASS позволяет принудительно обновить посты или страницы, задавая веб-серверу, где предлагается WordPress для новой версии
- Обновленный элемент заменит устаревший элемент в Nginx обратного прокси-кэша
Очистить весь кэш в обратном прокси-сервере 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.
Кэширование прокси-сервера Nginx
Когда вы разрабатываете приложения, среди многих вещей, вы должны сосредоточиться на четырех важных вещах: пользовательском опыте, безопасности, масштабируемости и производительности.
И это последнее, что не всегда 100% ясно, когда вы jr dev или только начинаете в этом мире кодирования.
В то время как наличие хорошего оборудования и быстрых интернет-восходящих линий может помочь вам получить большие скорости, иногда ваше приложение плохо кодируется и не работает должным образом, когда вы переходите от этапа разработки к производственным серверам.
Одним из лучших способов получить отличную производительность приложения является добавление кеширования слоев к вашему контенту и функциям, вы можете добавить кеш к статическим файлам (изображениям, javascript, css и т. Д.), Операциям с базами данных, а также динамическому контенту, предоставляемому PHP, Python и многие другие языки программирования.
Кэш-память Nginx
Nginx это веб-сервер, а также прокси-сервер, и одна из наиболее широко используемых функций Nginx это его прокси-технология.
Когда вы развертываете Nginx как обратный прокси-сервер или балансировщик нагрузки, вы можете включить мощные функции кеширования, и об этом говорит этот пост.
По этой теме мы попытаемся объяснить, что Кэш-память Nginx и как вы можете ускорить работу своих веб-приложений.
Что такое прокси-кэш?
Кэш-прокси это в основном данные, хранящиеся на промежуточном сервере между клиентом и конечным сервером.
В нашем случае Nginx является прокси-сервером, который сохранит копию исходного содержимого в прокси-кеше, и как только клиентский браузер запросит исходный файл, кэш-прокси предоставит копию, что позволит быстрее ускорить и сократить использование системных ресурсов ( CPU, RAM и I / O) на целевом сервере.
Как включить кеш-сервер Nginx?
Чтобы включить прокси-кеш, вам нужно отредактировать файл nginx.conf и установить две важные переменные:
- proxy_cache_path: путь, в котором вы будете хранить данные кэширования, в том месте, где вы будете настраивать настройки кеша.
- proxy_cache: директива, используемая для активации кэша прокси.
Пример полнофункциональной конфигурации прокси-кеша:
proxy_cache_path / var / nginx / cache levels = 1: 2 keys_zone = app_cache: 10m max_size = 5g неактивный = 45m use_temp_path = off; server <… … location / products
Давайте объясним каждый использованный нами вариант:
proxy_cache_path / var / nginx / cache levels = 1: 2 keys_zone = app_cache: 10m max_size = 5g неактивный = 45m use_temp_path = off;
/ Вар / Nginx / кэш / это выбранный каталог для хранения данных кеша, вы можете установить любой каталог по своему усмотрению.
Уровни = 1: 2 задает двухуровневую иерархию каталогов в / var / nginx / cache. Это полезно, когда у вас очень много кешированных файлов, чтобы избежать медленных скоростей во время доступа к файлам.
keys_zone = app_cache: 10m определяет зону общей памяти 10M, в которой будут храниться ключи кеша и информация метаданных. Это помогает ускорить проверку прокси-кешей.
max_size является максимальным пределом размера кэша, в этом случае мы устанавливаем его в 5G. Всегда рекомендуется использовать ограничение максимального размера для предотвращения проблем с дисковым пространством, как если бы вы оставили его без ограничений, Nginx будет продолжать записывать данные кэша, пока не будет использовано все свободное место на диске.
неактивный = 45m является лимит срока хранения для неактивного содержимого, он указывает, как долго кешированный элемент может оставаться в кеше без доступа. Если в течение последних минут 45 файл не доступен, он будет удален из кеша.
use_temp_path = выкл устанавливает временную директорию в off, это означает, что Nginx будет записывать временные файлы, используемые для кеша, в тот же каталог, который ранее был указан в переменной proxy_cache_path (/ var / nginx / cache в этом случае). Чтобы избежать ненужных операций ввода-вывода, мы отключили его.
proxy_cache позволяет кэшировать все содержимое, размещенное под блоком местоположения, в этом случае было задано как «location / products», но вы можете поместить его для кэширования всего содержимого вашего веб-сайта, например:
место нахождения / < proxy_cache app_cache;
proxy_pass http: // app_upstream; >
Я не хочу кэшировать некоторые объекты, что я могу сделать?
How To: Проксирование в приватный AWS S3 через Nginx
Иногда нам надо давать доступ к приватному баккету в Amazon S3 с авторизацией в наших сервисах, например LDAP или банальный Basic Auth. Стандартный Nginx, к сожалению, этого не позволяет сделать.
Но в интернете полно инструкций как это сделать с помощью LUA модуля Nginx.
Тут я расскажу как собрать Nginx с модулем LUA и всем необходимым, чтоб можно было проксировать запросы в Amazon S3 и в конце укажу на ошибку в конфигурации из сети, которая валяется почти на каждом углу. После чего мы эту ошибку исправим.
Сборка Nginx
Для сборки нам понадобятся исходники самого Nginx, модуля LUA, Nginx Development Kit и Set Misc модуль для Nginx. Итак, устанавливаев необходимое программное обеспечение
apt install build-essential automake libgd-dev libluajit-5.1-dev libgeoip-dev
Скачиваем необходимые модули и исходники:
/tmp/nginx
wget -O
/tmp/nginx/nginx.tar.gz http://nginx.org/download/nginx-1.11.1.tar.gz
cd
/tmp/nginx
tar -vxzf
/tmp/nginx/nginx.tar.gz git clone https://github.com/simpl/ngx_devel_kit.git
git clone https://github.com/openresty/lua-nginx-module.git
git clone https://github.com/openresty/set-misc-nginx-module.git
Собираем Nginx со всеми модулями:
./configure with-cc-opt='-g -O2 -fstack-protector param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' prefix=/usr/share/nginx conf-path=/etc/nginx/nginx.conf http-log-path=/var/log/nginx/access.log error-log-path=/var/log/nginx/error.log lock-path=/var/lock/nginx.lock pid-path=/run/nginx.pid http-client-body-temp-path=/var/lib/nginx/body http-fastcgi-temp-path=/var/lib/nginx/fastcgi http-proxy-temp-path=/var/lib/nginx/proxy http-scgi-temp-path=/var/lib/nginx/scgi http-uwsgi-temp-path=/var/lib/nginx/uwsgi with-debug with-pcre-jit with-ipv6 with-http_ssl_module with-http_stub_status_module with-http_realip_module with-http_addition_module with-http_dav_module with-http_geoip_module with-http_gzip_static_module with-http_image_filter_module with-http_sub_module with-http_xslt_module with-mail with-mail_ssl_module add-module=$
Останавливаем сервис Nginx и заменяем бинарный файл:
sudo service nginx stop
sudo cp -f objs/nginx /usr/sbin/nginx
Теперь рассмотрим конфигурацию. Я приведу только location, т.к. если вы задумались о проксировании в AWS, то уже должны знаете, что такое конфигурация Nginx:
x-amz-date:$
/$bucket/$url_full”; set_hmac_sha1 $aws_signature $aws_secret $string_to_sign; set_encode_base64 $aws_signature $aws_signature; resolver 8.8.8.8 valid=300s; resolver_timeout 10s; proxy_http_version 1.1; proxy_set_header Host $bucket.s3.amazonaws.com; proxy_set_header x-amz-date $now; proxy_set_header authorization “AWS $aws_access:$aws_signature”; proxy_buffering off; proxy_intercept_errors on; rewrite .* /$url_full break; proxy_pass http://$bucket.s3.amazonaws.com; >
Нужно подставить ваши ключи доступа к AWS и все должно заработать как надо. Но тут есть одна проблема. Если вы храните в баккете файлы с именами без пробелов, то вы ее не заметите. Все будет работать и так. Но если вам попадется файл с пробелом в имени, то Амазон вам его не отдаст с ошибкой о некорректной сигнатуре.
Это и есть та самая проблема о которой я говорил выше. Почему так происходит? Все дело в том, что Амазон пробел заменяет на знак “+”, а мы кодируем его как “%20”. Т.е. сервис Амазона не видит такого файла вообще.
Поскольку проблема понятна, то и решить ее можно достаточно легко с помощью все того же LUA:
set_by_lua $url_decoded “return ngx.re.gsub(ngx.var.url_full, '%20', '+')”;
Что происходит в этой строке:
И дальше в конфиге заменить везеде $url_full на $url_decoded. Результирующий конфиг будет такой:
x-amz-date:$
/$bucket/$url_decoded”; set_hmac_sha1 $aws_signature $aws_secret $string_to_sign; set_encode_base64 $aws_signature $aws_signature; resolver 8.8.8.8 valid=300s; resolver_timeout 10s; proxy_http_version 1.1; proxy_set_header Host $bucket.s3.amazonaws.com; proxy_set_header x-amz-date $now; proxy_set_header authorization “AWS $aws_access:$aws_signature”; proxy_buffering off; proxy_intercept_errors on; rewrite .* /$url_decoded break; proxy_pass http://$bucket.s3.amazonaws.com; >
Теперь можно запускать сервис Nginx:
Авторизацию, я думаю, вы и сами уже умеете прикручивать к Nginx. 😉
Источник: