Nginx proxy manager — инструмент, который поможет создать веб-сервер. Технология применяется на многих нагруженных ресурсах, таких как мессенджеры и социальные сети. Также его применяют, как reverse tcp proxy, который распределяет нагрузку между веб-сервисами. Предоставляет возможность установить SSL-сертификаты для кэширования и соединения, для увеличения производительности. Главная задача web reverse proxy – обслуживание графического контента, например, HTML или изображений. Каждый сервер имеет порт, который побуждает принимать запросы именно от него. Применяться может для кэширования заголовков, обустройства инвертированного прокси-сервера и для других масштабных задач.
Когда мы заходим на сайт, то запрос от браузера приходит на веб-сервер, чтобы оценить его и отдать корректные данные обратно, через реверс-прокси.
Отличие engine x от обычного server
Nginx прокси не работает через единичный поток информации, то есть каждый запрос разделяется на однотипные структуры меньшего размера. Каждая структура обрабатывается отдельным процессом, а после отработки – данные вновь объединяются в блок, который возвращает системе результат. Таким образом, увеличивается количество однотипных обрабатываемых запросов до 1024.
Как еще используют nginx proxy manager
При помощи engine x возможно настроить проксирование запросов, поступающих на удаленный server, используя директиву proxy_pass.
Как работает ngx_http_proxy_module простыми словами
Модуль помогает реализовать функционал. Например, если в локальной сети есть сервисы, которые не имеют прямой доступ к Сети, но пользователь хочет его открыть. Для этого нужно осуществить настройку точки входа на сервисы при помощи nginx-сервера, а затем, при помощи него, проксировать запросы.
Пример
Опишем на примере, каким образом работает проксирование:
- Применяют для настройки чат-серверов matrix и mattermost на виртуальном сервере. Запросы проксируются на server при помощи nginx, принимающего входящие соединения.
- Допустим, у вас есть большой server с контейнерами, например, докера. На нем работает множество различных сервисов. Вы устанавливаете еще один контейнер с чистым engine x, на нем настраиваете проксирование запросов на эти контейнеры. Сами контейнеры имеют доступ только к локальному интерфейсу сервера. Таким образом, они будут полностью закрыты извне, и при этом вы можете гибко управлять доступом.
- При наличии server с гипервизором, на виртуальной машине создается шлюз и локальная сетка, состоящая из виртуальных машин, недоступная извне. В данной локальной сети шлюз настраивается по умолчанию, и представляет собой виртуальную машину. На серверах сети можно разместить сервисы, при этом настройку файервола не осуществлять. Доступ к servers проксируется через nginx, которые подключены к отдельной виртуальной машине с настроенными портами.
- Организация доступа к synology. Для этого нужно получить бесплатный сертификат Let’s encrypt, настроить проксирование через текущий IP, а затем через шлюз перебросить их внутрь локальной сети. При помощи фаервола возможно ограничить доступ к server через IP, при помощи которого работает engine x. На synology никаких настроек осуществлять не нужно.
- Если пользователь или компания разворачивает большой проект, который разделен на составляющие, размещенные на отдельных серверах. Например, отдельно находится форум и проксирование возможно перенести на отдельный сервер. При этом возможна реализация location с переадресацией.
Вариантов применения engine x – много. Рассмотрим плюсы настройки для описанных выше кейсов.
Плюсы настройки engine x
- Быстрая настройка https доступа к сервисам, которая не будет изменять и затрагивать эти сервисы. То есть, пользователь, настраивая engine x, обеспечивает передачу данных от сервера к службам через http.
- Адреса проксируемых запросов легко изменять. Например, при подготовке сайта к nginx rewrite, пользователь настраивает все на сервере, на котором проксируются запросы. Произведите изменение url сайта в engine x прокси на новый и примените настройки. Откатить изменения возможно также быстро и легко.
Пример настройки прокси
С теорией закончили. Перейдем теперь к примеру настройки прокси. В примере будем использовать следующие обозначения:
| blog.1111.ru | Имя тестового ресурса |
| nginx_srv | Внешний сервер с engine x |
| blog_srv | Локальный сервер для проксирования |
| 94.142.141.246 | внешний ip nginx_srv |
| 192.168.13.31 | ip адрес blog_srv |
| 77.37.224.139 | ip адрес для входа на сайт |
Настройка proxy_pass в engine x
Попробуем объяснить настройку на реальном примере. Технический домен blog.1111.ru. В DNS создаем запись, которая приводит запрос на сервер, с установленным nginx_srv. Проксируем запросы с сервера на blog_srv, с реальным сайтом. Конфигурация:
server {
listen 80;
server_name blog.1111.ru;
access_log /var/log/nginx/blog.1111.ru-access.log;
error_log /var/log/nginx/blog.1111.ru -error.log;
location / {
proxy_pass http://192.168.13.31;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
}
Открываем http:// blog.1111.ru. Попасть мы должны на blog_srv, на котором работает server. Представим, что он тоже на engine x. Содержимое должно быть идентично информации с http://192.168.13.31 (локалка). Логи серверов показывают, что запрос был направлен на nginx_srv, а затем произошел редирект на nginx_srv.
Реальный IP виден только в конце лога, поэтому REMOTE_ADDR не сможет вернуть настоящий IP. Но это можно исправить.
Создаем тестовую страницу chat_srv, при помощи которой будет возможно проверить IP клиента.
<?php
echo $_SERVER[‘REMOTE_ADDR’]
?>
Даем ей название, например, myip.php.
Заходим на http:// blog.1111.ru/myip.php и смотрим, определяет ли server адрес. Т.к. мы не внесли исправления, то определяется nginx_srv, а не реальный адрес клиента.
Как передать IP клиента в nginx (обратный) при proxy_pass
На принимающей стороне производим обратную замену прокси. Через:
set_real_ip_from 94.142.141.246;
real_ip_header X-Real-IP;
В итоге получаем:
server {
listen 80 default_server;
server_name blog.1111.ru;
root /usr/share/nginx/html;
set_real_ip_from 94.142.141.246;
real_ip_header X-Real-IP;
location / {
index index.php index.html index.htm;
try_files $uri $uri/ =404;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_intercept_errors on;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_ignore_client_abort off;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
Сохраняем изменения и перепроверяем http:// blog.1111.ru/myip.php. Должен отобразиться реальный IP клиента.
Сохраняем конфиг, перечитываем его и снова проверяем Вы должны увидеть свой реальный ip адрес. Его же вы увидите в логе на blog_srv.
Вопросы от пользователей по engine x
Применяя https через proxy_pass нужно ли производить настройку https бэкенда?
Не обязательно, но возможно у вас есть программное обеспечение, которое не может функционировать в таком формате. Вы получите ссылку http://site.ru:443. Тогда придется осуществить настройку обмена данными между engine x и бэкендом.
Есть ли простой способ передачи let’s encrypt с engine x на backend? (Обновление и генерация осуществляются на engine x).
Есть два способа реализации. На nginx настраивается nfs сервер и уже затем, на бэкенде можно привязать директорию /etc/letsencrypt. Это позволит использовать сертификаты таким образом, будто они находятся на локальной директории.
Вариант два – использование bash-скрипта. Он будет копировать сертификаты через scp.
На бэкенде службы нужно постоянно перезапускать, после обновления сертификата.
Когда бэкенд обращается к адресу сайта, то запрос передается на nginx reverse proxy, потому что в ДНС указан его IP. Возникает проблема с отработкой скриптов и проверкой движка.
Чтобы ответ возвращался правильно, нужно поправить host /etc/hosts на бэкенде, прописав статические данные об имени сайта и локальным IP. Соответственно, запрос будет приходить не с nginx proxy cache от server, а локально.
Nginx или haproxy выбрать для проксирования?
Софт похожий по определению, поэтому четкого ответа на заданный вопрос дать невозможно. Но в haproxy есть функционал, который для nginx доступен только в расширенной версии. Выбирать нужно в соответствии с задачей, которую предстоит решить.
Добавляет ли engine x в режиме proxy_pass дополнительные сетевые задержки?
Да, но connect timeout мал, особенно если nginx proxy manager и сервер принадлежат одной и той же локальной сети. В общем, можно пренебречь задержками. При проксировании через интернет – следите за величиной задержки. Желательно, чтобы servers располагались как можно ближе друг к другу.
Заключение
Самая распространенная задача – проксирование внешних запросов в закрытую сеть. Если закрытая сеть не открыта для постороннего доступа, то нет необходимости в https при передаче информации на бэкенд.
Надеемся, что статья была полезной и интересной! Следите за обновлениями в нашем блоге.
