Проксирование запросов в nginx с помощью proxy_pass

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

Источник: https://server-gu.ru/nginx-proxy/

Настройка прокси 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 8080

Замените значение строки 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:

echo ”

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<\p>

Обратите внимание на порт, тут тоже нужно указать 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<\p>

Сохраните изменения, активируйте модуль и проверьте конфигурацию веб-сервера:

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

127.0.0.1 test.com

Затем откройте сайт в браузере, чтобы убедится, в том что все работает:

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

Сначала установите Nginx, если вы этого еще не сделали:

sudo apt install nginx

Дальше создадим виртуальный хост Nginx с несколькими доменами, с помощью которого и будет выполняться проксирование Nginx:

sudo vi /etc/nginx/sites-available/apache

server { listen 80;

server_name test.com www.test.com;

location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }

}

Для использования nginx в качестве прокси мы передаем в команде proxy_pass адрес и порт веб-сервера, а в заголовках передаем те значения, которые будут нужны Apache для правильного формирования документа. Сохраните файл и активируйте его:

sudo ln -s /etc/nginx/sites-available/apache /etc/nginx/sites-enabled/apache

Затем проверьте конфигурацию и перезапустите Nginx:

sudo nginx -t

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 { listen 80; listen 443 ssl;

server_name test.com www.test.com;

ssl on; ssl_certificate /etc/nginx/ssl/test.io-cert.pem;

ssl_certificate_key /etc/nginx/ssl/test.io-key.pem;

location / { proxy_pass http://your_server_ip:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }

}

Сохраните файл конфигурации и перезапустите Nginx:

nginx -t
$ sudo systemctl restart nginx

Теперь вы можете открыть наш домен в браузере по HTTS и убедится что прокси отлично работает. Обратите внимание, что если вы используете самоподписанный сертификат, то вам придется добавить его в исключения браузера:

Поддержка защищенного протокола включена и SERVER_PORT имеет значение 443, все работает прозрачно, как бы проксирование nginx не осуществляется, а мы направляем запросы непосредственно к Apache.

Статические файлы через Nginx

Чтобы уменьшить нагрузку на Apache мы можем обрабатывать все статические файлы в Nginx, как правило, это очень сильно увеличивает выдерживаемую нагрузку, поскольку Nginx способен работать быстрее с большим количеством подключений и занимать меньше ресурсов.

Нам нужно добавить несколько строк в /etc/nginx/sites-available/apache

server { listen 80; listen 443 ssl;

server_name test.com www.test.com;

ssl on; ssl_certificate /etc/nginx/ssl/test.com-cert.pem;

ssl_certificate_key /etc/nginx/ssl/test.com-key.pem;

root /var/www/test.com;
index index.php index.htm index.html;

location / { try_files $uri $uri/ /index.php;

}

location ~ .php$ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;

}

location ~ /. { deny all; }

}

Мы устанавливаем корень сайта в /var/www/test.com, и пытаемся отдать оттуда все статические файлы, а файлы с расширением .php будем обрабатывать в Apache. Также дополнительно мы закрываем доступ ко всем скрытым файлам.

Теперь откройте несколько раз сайт в браузере, динамические страницы phpinfo.php и статическую index.html, а затем посмотрите в лог файл, где вы обнаружите что Apache обрабатывает только динамику:

cat /var/log/apache2/other_vhosts_access.log

Теперь проксирование Nginx работает так же как и на большинстве серверов интернета.

Выводы

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

Источник: https://losst.ru/nastrojka-proksi-nginx

Проксируем и спасаем

ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов.

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

В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить 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.

com; }

Дальше нужно создать секцию server, вот как она выглядит

server { listen 80; server_name 6pm.pokupki-usa.ru; limit_conn gulag 64; access_log /var/log/nginx/6pm.access.log; error_log /var/log/nginx/6pm.error.log; location / { root /var/www/6pm; try_files $uri @static; } location @static { include '6pm.conf'; proxy_cookie_domain 6pm.com 6pm.pokupki-usa.ru; proxy_set_header Accept-Encoding “”; proxy_set_header Host www.6pm.com; proxy_pass http://6pm; proxy_redirect http://www.6pm.com http://6pm.pokupki-usa.ru; proxy_redirect https://secure-www.6pm.com https://6pm.pokupki-usa.ru; } }

Стандартные директивы 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

Источник: https://habr.com/post/158393/

Примеры настройка Nginx прокси

by Денис Туляковin wiki on 2016-05-20 | tags: Nginx proxy | comments

301 Moved Permanently, редирект, говорящий что ресурс перемещен на постоянной основе.

В интернетах пишут что мол типа архинеобходимо для SEO, мол поисковики это дюже уважают), спорить не буду, не вникал.

В веб сервере Nginx 301 редирект настраивается в конфигурационном файле ( в apache можно через файл .htaccess ), таким образом:

1 вариант

1 2 3 4 5 6 7 8 9 10 11 12 13 14

server { listen 80; server_name www.dtulyakov.ru; rewrite ^ http://dtulyakov.ru$request_uri? permanent; #301 redirect } server { listen 80; server_name dtulyakov; ….. основной конфиг ….. }

2 вариант

server { server_name dtulyakov.ru; if ( $host = 'www.dtulyakov.ru' ) { rewrite ^/(.*)$ http://dtulyakov.ru/$1 permanent; }

Балансировщик

проксирование простой вариант

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

upstream j_server { server 10.0.3.100:8080 fail_timeout=0; } server { listen 80; server_name jenkins.dtulyakov.ru; reset_timedout_connection on; charset UTF-8; location / { proxy_pass http://j_server; proxy_next_upstream error timeout invalid_header http_500 http_503; #proxy_set_header Host $host; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_redirect off; proxy_connect_timeout 30; } }

проксирование вариант с балансировкой

upstream j_server { server 10.0.3.100:8080 weight=10; server 10.0.3.101:8080 max_fails=3 fail_timeout=30s; server 10.0.3.102:8080 max_fails=2; server 10.0.3.103:8080 backup fail_timeout=0; } ….. основной конфиг …..

проксирование вариант с балансировкой

upstream j_server { least_conn; server 10.0.3.100:8080 weight=10; server 10.0.3.101:8080 max_fails=3 fail_timeout=30s; server 10.0.3.102:8080 max_fails=2; server 10.0.3.103:8080 backup fail_timeout=0; } ….. основной конфиг …..

проксирование вариант с балансировкой Hash и IP hash Для каждого запроса Nginx вычисляет хэш, который состоит из текста, переменных веб-сервера или их комбинации, а затем сопоставляет его с бэкендами Для вычисления хэша используется схема (http или https) и полный URL

upstream j_server { hash $scheme$request_uri; server 10.0.3.100:8080 weight=10; server 10.0.3.101:8080 max_fails=3 fail_timeout=30s; server 10.0.3.102:8080 max_fails=2; server 10.0.3.103:8080 backup fail_timeout=0; } ….. основной конфиг …..

IP hash работает только с HTTP, это предопределенный вариант, в котором хэш вычисляется по IP-адресу клиента Если адрес клиента IPv4, то для хэша используется первые три октета, если IPv6, то весь адрес

upstream j_server { ip_hash; server 10.0.3.100:8080 weight=10; server 10.0.3.101:8080 max_fails=3 fail_timeout=30s; server 10.0.3.102:8080 max_fails=2; server 10.0.3.103:8080 backup fail_timeout=0; } ….. основной конфиг …..

• max_fails – задает количество неудачных попыток подключений, после которых бэкенд определенное время считается недоступным
• fail_timeout – время, в течение которого сервер считается недоступным
• round-robin – Веб-сервер по умолчанию распределяет запросы равномерно между бэкендами (но с учетом весов). Этот стандартный метод в Nginx, так что директива включения отсутствует
• least_conn – Запросы сначала отправляются бэкенду с наименьшим количеством активных подключений (но с учетом весов) Если количество активных соединений одинаково, то дополнительно используется метод round-robin
• max_fails – задает количество неудачных попыток подключений, после которых бэкенд определенное время считается недоступным
• fail_timeout – время, в течение которого сервер считается недоступным

Ссылки

Источник: http://www.dtulyakov.ru/nginx.html

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 ~* .(gif|jpg|jpeg|png)$ {     proxy_pass http://192.168.0.3;

Выполнять проксирование вовсе необязательно к другим серверам, это можно делать и в пределах 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 😉

Источник: http://ashep.org/2011/nginx-obratnyj-proksi-server/

Вопрос: nginx proxy_pass на основе метода запроса POST, PUT или DELETE

У меня два iKaaro  экземпляры, запущенные на портах 8080 и 9080, где экземпляр 9080 доступен только для чтения.

Я не уверен, как использовать nginx, например, если метод запроса POST, PUT, DELETE, тогда отправьте экземпляр записи (8080), иначе отправьте экземпляр 9080.

Я сделал что-то, используя местоположение, используя регулярное выражение, но это неверно.

Из http://wiki.nginx.org/HttpLuaModule  я вижу, что есть «константы метода HTTP», которые можно вызывать, поэтому правильно добавить блок местоположения как:

location ~* “(ngx.HTTP_POST|ngx.HTTP_DELETE|ngx.HTTP_PUT)” { proxy_pass http://127.0.0.1:8080;

благодаря

20

2017-12-21 14:43

источник<\p>

Ответы:

Я просто сделал быстрый тест, и это сработало для меня:

server { location / { # This proxy_pass is used for requests that don't # match the limit_except proxy_pass http://127.0.0.1:8080; # For requests that *aren't* a PUT, POST, or DELETE, # pass to :9080 limit_except PUT POST DELETE { proxy_pass http://127.0.0.1:9080; } }
}

34

2017-12-21 19:05

Я предполагаю, что у вас есть основы. I.E., вы установили Lua 5.1 или, еще лучше, LuaJIT 2.0 на свой сервер, скомпилировали Nginx с модулем ngx_lua и настроили ngx_lua по мере необходимости.

С этим на месте, это сделает работу:

location /test { content_by_lua ' local reqType = ngx.var.request_method if reqType == ngx.HTTP_POST OR reqType == ngx.HTTP_DELETE OR reqType == ngx.HTTP_PUT then res = ngx.location.capture(“/write_instance”) else res = ngx.location.capture(“/read_instance”) end ngx.say(res.body) ';
}
location /write_instance { internal; proxy_pass http://127.0.0.1:8080;
}
location /read_instance { internal; proxy_pass http://127.0.0.1:9080;
}

ОБНОВИТЬ

10

2017-12-21 17:01

Если кто-то ищет способ просто создать условия по методу запроса, синтаксис следующий:

if ($request_method = DELETE ) { . . . }

1

2018-06-30 12:32

Я бы рекомендовал функцию отображения nginx. Это выходит за пределы вашего блока местоположения:

map $request_method $destination { default 8080; PUT 9080; POST 9080; DELETE 9080;
}

Затем в вашем блоке местоположения:

proxy_pass http://127.0.0.1:$destination

Это тоже все регулярные выражения, поэтому вы можете делать такие вещи, как:

map $request_method $cookie_auth $destination { default 8080; “^POST ” 9080; “^PUT someAuthCookieValue” 9080;
}

Плюс это позволяет избежать использования, если вообще. Это довольно здорово. Я использовал его, чтобы направлять весь трафик записи в кластере WordPress на один сокет FastCGI TCP на удаленном узле, но отправлять трафик чтения в локальный сокет FastCGI UNIX.

1

2018-04-24 17:54

Источник: http://programmerz.ru/questions/20542/nginx-proxy-pass-based-on-whether-request-method-is-post-put-or-delete-question

Инструкции по настройке обратного прокси-сервера 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

Listen 8080

Откройте виртуальный хост Apache

nano /etc/apache2/sites-available/wordpress.conf

Изменение порта 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.

Источник: https://andreyex.ru/operacionnaya-sistema-linux/instrukcii-po-nastrojke-obratnogo-proksi-servera-nginx-dlya-apache-i-kesha-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 app_cache; proxy_pass http: // app_upstream; } … …}

Давайте объясним каждый использованный нами вариант:

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; }

Я не хочу кэшировать некоторые объекты, что я могу сделать?

Источник: https://websetnet.net/ru/nginx-proxy-cache-explained/

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

Скачиваем необходимые модули и исходники:

mkdir -p ~/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=${HOME}/tmp/nginx/ngx_devel_kit –add-module=${HOME}/tmp/nginx/set-misc-nginx-module –add-module=${HOME}/tmp/nginx/lua-nginx-module

Останавливаем сервис Nginx и заменяем бинарный файл:

sudo service nginx stop
sudo cp -f objs/nginx /usr/sbin/nginx

Теперь рассмотрим конфигурацию. Я приведу только location, т.к. если вы задумались о проксировании в AWS, то уже должны знаете, что такое конфигурация Nginx:

location ~* ^/(.*) { set $bucket 'bucket-name'; set $aws_access 'AWS_ACCESS_TOKEN'; set $aws_secret 'AWS_ACCESS_SECRET'; set $url_full “$1”; set_by_lua $now “return ngx.cookie_time(ngx.time())”; set $string_to_sign “$request_method

x-amz-date:${now}
/$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', '+')”;

Что происходит в этой строке:

1. Устанавливаем переменную $url_decoded с помощью LUA
2. Пишем в нее результат от ngx.re.gsub – это функции замены
3. ngx.var.url_full – переменная в которой будет делаться поиск
4. '%20' – то, что ищем
5. '+' – то, на что меняем

И дальше в конфиге заменить везеде $url_full на $url_decoded. Результирующий конфиг будет такой:

location ~* ^/(.*) { set $bucket 'bucket-name'; set $aws_access 'AKIAJAL2RFUF73T66RBA'; set $aws_secret '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'; set $url_full “$1”; set_by_lua $url_decoded “return ngx.re.gsub(ngx.var.url_full, '%20', '+')”; set_by_lua $now “return ngx.cookie_time(ngx.time())”; set $string_to_sign “$request_method

x-amz-date:${now}
/$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. 😉

Источник: https://lyalyuev.info/2016/06/30/how-to-proksirovanie-v-privatny-j-aws-s3-cherez-nginx/