nginx proxy redirect proxy pass

🐹 Nginx: Проксирование запросов с помощью proxy_pass.

Опубликовано 2020-11-12 · Обновлено 2021-01-30

Содержание:

На чем было опробовано:

1. Введение.

В nginx имеется одна интересная директива proxy_pass. Она позволяет проксировать запросы на удалённый сервер.

2. Настройка proxy_pass в nginx.

Проксирование ресурса с IP-адреса за NAT в интернет, мы передаем реальный IP-адрес клиента с помощью директивы proxy_set_header, которая добавляет в заголовок X-Real-IP настоящий IP-адрес клиента.

Будем проксировать файл myip.php с содержимым.

Текст файла конфигурации примет вид:

3. Передача реального IP-адреса (Real IP) клиента в nginx при proxy_pass.

В этом примере нужно на принимающей стороне, то есть test_srv сделать обратную замену — заменить информацию об адресе отправителя на ту, что указана в заголовке X-Real-IP.

Добавляем в секцию server следующие параметры:

Полностью секция server на test_srv в самом простом варианте получается следующей:

4. Передача https через nginx с помощью proxy pass.

Рассмотрим пример с бесплатным сертификатом Let’s Encrypt.

Очень удобно настроить на одном сервере автоматическое получение всех необходимых сертификатов.

Полная секция server нашего тестового сайта на момент получения сертификата будет выглядеть вот так:

Пересчитываем файл конфигурации nginx и получаем сертификат.

После этого файл конфигурации меняем на следующий:

Происходит проксирование с другого IP-адреса и шифрование по https.

5. Проксирование определенной директории или файлов.

Вы можете отдавать картинки с одного сервера, а все остальное с другого. В моем примере, картинки будут жить на том же сервере, где nginx, а остальной сайт на другом сервере.

6. Руководство пользователя.

Подробнее о модуле ngx_http_proxy_module можно узнать из официальной документации по nginx.

Источник

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

Задача: Заставить работать 2 сайта на 1 внешнем ip адресе.

Решение: Создаем на Proxmox новый контейнер в нашем случаи с порядковым номером 103. В качестве операционной системы возьмем debian 10 и после установления ОС дополнительно устанавливаем туда nginx. Он и будет обрабатывать все запросы и проксировать их на контейнеры.

Переходим к настройке. На сервере 103 переходим к настройке ngnix:

создаем конфигурацию (config)

где listen 80; это порт приема трафика

название вашего домена server_name example1.com;

сохранение логов (log file) из access_log /var/log/nginx/example1.com;

К слову Большой синоним узнай здесь.

указываем куда будет транслироваться трафик на виртуальный сервер proxy_pass http://192.168.88.10:80;

Конечно, есть смысл перенести директиву proxy_set_header в раздел серверного или http контекста, чтобы можно было ссылаться на неё из разных мест настройки.

memcached

Для ускорения ответа запроса можно использовать систему кеширование memcached лучше всего запустить ее на отдельной виртуальной машине как пример у меня она доступна по адресу 192.168.88.252

рекомендация чтобы на в наружу не светилась так как есть атаки на эти сервисы

Вставить его в вашу конфигурацию в директории /etc/nginx/sites-available proxy между location

HTTPS

Для доступа сайта по HTTPS на сервере nginx proxy_pass лучше использовать сервис для создание сертификатов бесплатный certbot.

Для выпуска сертификата устанавливаем certbot командой

Для выпуска сертификата нужно выполнить команду

Выбрать сайт который вы хотите перевести на https подтверждаете и переводите на https

вы вбираете 2 Redirect теперь сайт доступен по https

Приводите конфигурации в порядок в директории /etc/nginx/sites-available

Пример конфигурации с https

Для удобства лучше отдельно размещать файлы конфигурации nginx в директории /etc/nginx/sites-available для каждого сервер

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

Источник

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

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

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

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

Стандартные директивы listen и server определяют имя виртуального хоста, при обращении к которому будет срабатывать секция server. Файлы логов лучше сделать отдельными.

$uri — переменная nginx, которая содержит путь из HTTP запроса

Префикс “@” задаёт именованный location. Такой location не используется при обычной обработке запросов, а предназначен только для перенаправления в него запросов. Такие location’ы не могут быть вложенными и не могут содержать вложенные location’ы

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

Теперь посмотрим содержимое 6pm.conf. Я не случайно вынес логику трансформации в отдельный файл. В нем можно разместить без какой либо потери производительности тысячи правил замены и сотни килобайт фильтров. В нашем случае мы хотим лишь завершить процесс проксирования, поэтому файл содержит всего 5 строк:

Меняем коды google analytics:

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

Меняем все прямые ссылки на новые.

Как правило, в нормальных сайтах все картинки лежат на CDN сетях, которые не утруждают себя проверкой источника запросов, поэтому достаточно замены ссылок только основного домена. В нашем случае 6pm выпендрился и разместил часть картинок на доменах, которые отказывают посетителям из России. К счастью, модуль замены поддерживает регулярные выражения и не составляет никакого труда написать общее правило для группы ссылок. В нашем случае обошлось даже без regexp, просто поменяли два символа в домене. Получилось так:

Единственное, но очень серьезное ограничение модуля замены — он работает только с одной строкой. Это ограничение заложено архитектурно, поскольку модуль работает на этапе, когда страница загружена частично (chunked transfer encoding) и нет никакой возможности выполнить полнотекстовый regexp.

Все, можно посмотреть на результат, все работает, даже оплата заказа проходит без затруднений.

С п.1 все просто — мы заменяем все ссылки на новый путь с поддиректорией
С п.3 так же просто — мы ничего не трогаем и все работает само если не использовался атрибут base href. Если этот атрибут используется, что бывает крайне редко в современных сайтах, то достаточно его заменить и все будет работать.

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

Вернемся к нашему пациенту:

Конфигурация сервера претерпела некоторые изменения.

Во-первых, вся логика перенесена из директивы sever напрямую в location. Нетрудно догадаться, что мы решили создать директорию /6pm в которую будем выводить проксируемый сайт.

proxy_cookie_path / /6pm/ — переносим куки из корня сайта в поддиректорию. Это делать не обязательно, но в случае если проксируемых сайтов окажется много, их куки могут пересечься и затереть друг друга.

rewrite ^/6pm/(.*) /$1 break; — эта магия вырезает из клиентского запроса поддиректорию, которую мы добавили, в результате директива proxy_pass отправляет на сервер-донор корректное значение.

Чуть сложнее стало ловить редиректы. Теперь все ссылки на корень нужно перебросить на /6pm.

Посмотрим на логику трансформации:

Во-первых, мы включили фильтрацию файлов css и javascript (парсинг html включен по-умолчанию)
Во-вторых, начинаем аккуратно находить и заменять разные типы ссылок относительно корня. Нам попался средней сложности сайт, в котором часть скриптов содержат такие пути.

К сожалению, мне не удалось до конца написать фильтр для случая поддиректории. Я не дошел до преобразования динамических запросов скриптов корзины с покупками, хотя не сомневаюсь что это решаемо. Просто моих знаний в Javascript не достаточно чтобы выполнить необходимую отладку, буду рад советам как запустить корзину покупок, которая сейчас в упомянутом примере не работает.

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

Источник

Примеры редиректов в NGINX

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

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

Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В Linux на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.

Саму настройку на перенаправление в NGINX можно прописать несколькими способами.

* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:

* где коды могут использоваться любые, но чаще всего — 301, 302, 404.

Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используются оба варианта.

После внесения изменений, необходимо проверить их корректность:

И для их применения перезапустить веб-сервер:

systemctl restart nginx

service nginx restart

* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.

Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.

С HTTP на HTTPS (другой порт)

Пример конфигурации для перенаправления запросов на другой порт — с 80 (http) на 443 (https):

server <
listen 80;
server_name domain.ru www.domain.ru;
return 301 https://$host$request_uri;
>

* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).

Также мы можем добавить условие, чтобы не перенаправлять на https для определенных ссылок, например:

/page.html) <
return 301 https://$host$request_uri;
>
>

* в данном примере запрос на страницу /page.html будет открыт по http.

С одного домена на другой

server <
.
server_name domain1.ru;
return 302 http://domain2.ru$request_uri;
>

C домена без www на домен с www

server <
.
server_name domain.ru;
return 301 http://www.$host$request_uri;
>

С www на без www

Все домены, которые обслуживает nginx:

C index.php на / (корень)

Данная настройка позволит перевести все запросы с /index.php на корневой адрес /:

server <
.
if ($request_uri

Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)

Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:

server <
listen 80 default_server;
return 302 https://welcome.domain.ru$request_uri;
>

или независимо от протокола:

ssl on;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
>

* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабатывать запросы по https, необходимо указывать в настройках пути к сертификатам.

С IP-адреса на домен

В данном случае мы переводим все запросы по IP-адресу на конкретный домен:

server <
listen 80;
server_name 192.168.1.15;
return 301 http://site.ru$request_uri;
>

* при отправке http-запроса на сервер 192.168.1.15 по IP-адресу, он будет переведен на домен site.ru.

Редирект домена и всех его поддоменов

server <
.
server_name domain domain.*;
return 301 https://$host$request_uri;
>

На другой файл

Это скорее не перенаправление, а алиас или rewrite. Позволяет по запросу одного из файлов, отдать другой:

server <
.
location = /robots.txt <
rewrite ^/robots.txt$ /robots2.txt;
>
>

* в данном примере по запросу robots.txt, сервер отдаст содержимое robots2.txt.

Часть url на другой сервер

Перенаправить запрос на другой сервер при обращении по url page1:

server <
.
server_name domain1.ru;
location

* в данном примере для всех запросов, начинающихся на /page1/. будет работать перенаправление на другой домен domain2.ru.

Редирект со слешем

1. Убрать слеш в конце url

2. Добавить слеш в конце url

Удаляем расширение

Для перенаправления запроса, где в URL есть полное название файла скрипта (с расширением) используем конфигурацию:

server <
.
if ($request_uri

* в данном случае все запросы, которые заканчиваются на .php или .html, будут перенаправляться на страницы без данных расширений.

Для примера, запрос http://site-example.ru/page.php будет переведен на http://site-example.ru/page.

На другую страницу

Нам может понадобиться перенаправлять запросы с одной страницы сайта на другую. Приведем примеры, как это сделать с помощью return и rewrite.

а) с помощью rewrite:

server <
.
rewrite ^/page1$ /page2 permanent;
>

б) с помощью return:

server <
.
location = /page1 <
return 301 /page2;
>
>

Удалить часть URL

Иногда нужно удалять часть url. Это можно сделать следующими способами:

server <
.
rewrite /deleted-url/(.*) /$1 permanent;
>

server <
.
if ($request_uri

* в данном примере из url мы удалим deleted-url/.

Перенаправить запрос в случае обращения к несуществующим файлам

Перевод запросов, если файла не существует

Данное действие не является редиректом, но близко по смыслу — NGINX проверяет наличие файла скрипта, к которому идет обращение, и если его нет, переводит запрос на другой файл. Как правило, это используется для того, чтобы перевести все обращения на файл index.php.

* в данном примере мы скажем веб-серверу все запросы обрабатывать с помощью файла index.php в корневой директории.

Проксирование

Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.

Хоть это и не совсем редирект, рассмотрим примеры его настройки, так как очень часто нужно не перенаправление, а, как раз, обратное проксирование.

1. На другой сервер

Пример внутреннего перенаправления http-запроса на другой веб-сервер:

* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.

Использование NGINX в качестве http-прокси:

* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.

HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):

server <
.
location / <
proxy_pass http://10.10.10.10/page/;
proxy_set_header Authorization «Basic dGVzdDp0ZXN0»;
.
>
>

* где 10.10.10.10/page — страница, на которую будут перекинуты запросы; dGVzdDp0ZXN0 — логин:пароль test:test, закодированные в формате base64.

2. Часть url на другой сервер

Выше мы рассмотрели пример перенаправления запроса по части веб-адреса. По схожему сценарию мы можем делать проксирование:

3. На другой сайт

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

* в данном случае мы при обращении к нашему серверу (до доменному имени dmosk.local) будем попадать на сайт https://www.dmosk.ru. Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси.

4. На другой сайт по части URL

Если нам нужно настроить проксирование на другой сайт при обращении к определенной странице сайта, настраиваем NGINX так:

* в данном примере, если мы перейдем на страницу www.dmosk.ru/page, то мы попадем на сайт www.site.ru.

5. Редиректы при проксировании

Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:

proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
>
>

* в конкретном случае мы проксируем запросы http://dmosk.local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.

Немного о 301 и 302

В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.

301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и то же. Таким образом, результаты ранжирования необходимо сохранить для новой страницы.

302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.

Источник

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

Хочу рассказать об одной полезной возможности nginx, которую регулярно использую в своих делах. Речь пойдет о настройке проксирования запросов на удаленный сервер с помощью nginx и директивы proxy_pass. Я приведу примеры различных настроек и расскажу, где сам использую данный модуль популярного веб сервера.

Введение

Расскажу на конкретных примерах, где я это использую. Для наглядности и простоты буду прям по порядку перечислять эти варианты:

Надеюсь в общем и целом понятно, о чем идет речь. Вариантов использования много. Я привел самые распространенные, которые пришли в голову и которые использую сам. Из плюсов, которые считаю наиболее полезными именно из своих кейсов, отмечу 2:

С теорией закончил. Перейдем теперь к примерам настройки. В своих примерах я буду использовать следующие обозначения:

Настройка proxy_pass в nginx

Заходим по адресу http://blog.zeroxzed.ru. Мы должны попасть на blog_srv, где тоже должен работать какой-то веб сервер. В моем случае это будет тоже nginx. У вас должно открыться содержимое, аналогичное тому, что вы увидите, набрав http://192.168.13.31 в локальной сети. Если что-то не работает, то проверьте сначала, что по адресу директивы proxy_pass у вас все корректно работает.

Посмотрим логи на обоих сервера. На nginx_srv вижу свой запрос:

Как мы видим, запрос сначала пришел на nginx_srv, был переправлен на blog_srv, куда он пришел уже с адресом отправителя 94.142.141.246. Это адрес nginx_srv. Реальный же ip адрес клиента мы видим только в самом конце лога. Это неудобно, так как директива php REMOTE_ADDR не будет возвращать настоящий ip адрес клиента. А он очень часто бывает нужен. Мы это дальше исправим, а пока создадим в корне сайта на chat_srv тестовую страничку для проверки ip адреса клиента следующего содержания:

Назовем ее myip.php. Перейдем по адресу http://blog.zeroxzed.ru/myip.php и проверим, как сервер определит наш адрес. Никак не определит 🙂 Он покажет адрес nginx_srv. Исправляем это и учим nginx передавать реальный ip адрес клиента на сервер.

Передача реального ip (real ip) адреса клиента в nginx при proxy_pass

Полностью секция server на blog_srv в самом простом варианте получается следующей:

Сохраняем конфиг, перечитываем его и снова проверяем http://blog.zeroxzed.ru/myip.php. Вы должны увидеть свой реальный ip адрес. Его же вы увидите в логе web сервера на blog_srv.

Дальше рассмотрим более сложные конфигурации.

Передача https через nginx с помощью proxy pass

Если у вас сайт работает по https, то достаточно настроить ssl только на nginx_srv, если вы не беспокоитесь за передачу информации от nginx_srv к blog_srv. Она может осуществляться по незащищенному протоколу. Рассмотрю пример с бесплатным сертификатом let’s encrypt. Это как раз один из кейсов, когда я использую proxy_pass. Очень удобно настроить на одном сервере автоматическое получение всех необходимых сертификатов. Подробно настройку let’s encrypt я рассматривал отдельно. Сейчас будем считать, что у вас стоит certbot и все готово для нового сертификата, который потом будет автоматически обновляться.

Перечитывайте конфиг nginx и получайте сертификат. После этого конфиг меняется на следующий:

Проверяем, что получилось.

Наш сайт работает по https, при том, что мы вообще не трогали сервер, где этот сайт располагается. Конкретно с web сайтом это может быть не так актуально, но если вы проксируете запросы не на обычный сайт, а на какой-то нестандартный сервис, который трудно перевести на https, это может быть хорошим решением.

Проксирование определенной директории или файлов

Рассмотрим еще один пример. Допустим, у вас форум живет в директории http://blog.zeroxzed.ru/forum/, вы хотите вынести форум на отдельный web сервер для увеличения быстродействия. Для этого к предыдущему конфигу добавьте еще один location.

Еще одно популярное решение. Вы можете отдавать картинки с одного сервера, а все остальное с другого. В моем примере, картинки будут жить на том же сервере, где nginx, а остальной сайт на другом сервере. Тогда у нас должна быть примерно такая конфигурация локаций.

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

Существует очень много директив для управления прокси-соединениями. Все они описаны в соответствующей документации nginx. Я не большой специалист по настройке nginx. В основном использую свои готовые конфиги, зачастую даже не вникая в суть, если получается сразу решить задачу. Подсматриваю что-то у других, записываю к себе, стараюсь разобраться.

Особое внимание следует уделить директивам кэширования proxy_cache, если в этом есть потребность. Можно существенно увеличить отклик веб сайта, если подходящим образом настроить отдачу кэша. Но это тонкий момент и нужно настраивать в каждом конкретном случае отдельно. Готовых рецептов тут не бывает.

Более подробно о комплексной настройке nginx читайте в отдельной большой статье с моими личными примерами.

Часто задаваемые вопросы по теме статьи (FAQ)

В общем случае не обязательно. Но есть некоторый софт, который не может корректно работать в таком режиме. Он не понимает, как корректно обрабатывать такую ситуацию. Может создавать ссылки вида http://site.ru:443, которые будут являться ошибочными. В таком случае необходимо настроить обмен между nginx и бэк сервером тоже https соединение.

В такой ситуации может помочь правка файла /etc/hosts на самом бэкенде. Сделайте там статическую запись с именем сайта и локальным ip адресом. Тогда запросы с самого сервера будут приходить на него же локально, а не на nginx proxy.

Однозначного ответа на этот вопрос не может быть. В чем-то это схожий софт, но есть и существенные отличия. В общем случае, описанном в статье, принципиальной разницы нет. У haproxy в бесплатной версии есть функционал, который присутсвует только в nginx plus. Так что нужно смотреть по конкретным задачам и решать, какой продукт подойдет лучше.

Конечно да. Но на практике они очень малы, если nginx и целевой сервер находятся в общей локальной сети. С учетом задержек при передачи пакетов по сети интернет, этими локальными задержками можно пренебречь. Они будут ничтожно малы. Если же вы проксируете запросы через интернет, то нужно внимательно смотреть величину задержек между nginx и бэкендом. Желательно их делать минимальными, располагая сервера поближе друг к другу.

Заключение

На этом у меня все. Не рассмотрел еще один возможный вариант, когда вы проксируете https сайт и передаете инфу на бэкенд тоже по https. Нет под рукой готового примера, чтобы проверить, а заочно не стал рисовать конфиг. По идее, ничего сложного в этом нет, настраиваете nginx на обоих серверах с одним и тем же сертификатом. Но наверняка не скажу, что все заработает при этом. Возможно, есть какие-то нюансы с таким проксированием. Мне обычно не приходится так делать.

Как я уже писал в начале, в основном проксирую запросы с одного внешнего веб сервера на закрытый периметр сети, куда нет никому доступа. В этом случае у меня нет необходимости использовать https при передаче запросов на бэкенд. В качестве бэкенда не обязательно будет отдельный сервер. Это запросто может быть контейнер на этом же сервере.

Источник