Windows nginx reverse proxy — Ваш верный помощник с OS Windows

Sometimes we need to access our web projects running on local environments by domain names. We can reverse proxy a virtual domain by Nginx. Then we can use configured domain names to visit our local projects.

Downloading Nginx for Windows

Downloading Nginx for Windows from Nginx.

Configuring hosts file of Windows

Configuring virtual domains in C:\Windows\System32\drivers\etc\hosts

127.0.0.1 example1.com
127.0.0.1 example2.com

Check if the virtual domains are working

Open CMD terminal on Windows, and run the virtual domain test command. e.g. ping example1.com

Pinging example1.com [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=64
Reply from 127.0.0.1: bytes=32 time<1ms TTL=64
Reply from 127.0.0.1: bytes=32 time<1ms TTL=64
Reply from 127.0.0.1: bytes=32 time<1ms TTL=64
...

Configuring Nginx Reverse Proxy

Configuring Nginx reverse proxy in conf\nginx.conf

http {
	...
    server {
        listen       80;
        server_name  example1.com;
        location / {
            proxy_pass http://127.0.0.1:8081;
        }
    }
    
    server {
        listen       80;
        server_name  example2.com;
        location / {
            proxy_pass http://127.0.0.1:8082;
        }
    }

}

Starting Nginx

cd D:\nginx-1.18.0
start nginx.exe

Check if your Nginx server is up and running

Visit http://localhost to see the “welcome to nginx!” page

Visit

Visit the virtual domain (server name) URL http://example1.com/{your_app_request_path}

Warning: Ensure you are not using an HTTP proxy client such as v2rayN before accessing virtual domain URLs.

Stop Nginx

CMD of Windows

cd D:\nginx-1.18.0

# fast shutdown
nginx -s stop

# graceful shutdown
nginx -s quit

Git bash

cd D:\nginx-1.18.0

# fast shutdown
./nginx.exe -s stop

# graceful shutdown
./nginx.exe -s quit

Reload the configuration of Nginx

CMD of Windows

cd D:\nginx-1.18.0
nginx -s reload

Git bash

cd D:\nginx-1.18.0
./nginx.exe -s reload

Note

Ensure that the ports 80, 433… where Nginx is listening are not occupied.
Ensure you are not using an HTTP proxy client such as v2rayN before accessing virtual domain URLs.
You must use Nginx commands to start and stop Nginx. Else you can’t stop the Nginx. Unless the Nginx process is killed in the task manager-Windows details or the Windows system is restarted.
Before running start nginx, you must check if an Nginx server is running. If an Nginx server is running, you must run nginx -s stop first. Repeatedly running start nginx will start multiple Nginx servers, and you can’t stop all Nginx servers. Unless the Nginx process is killed in the task manager-Windows details or the Windows system is restarted.

Источник

Setting up Nginx as a Reverse Proxy on Windows

Feb 20, 2023

Setting up Nginx as a Reverse Proxy on Windows
- Prerequisites
- Download and install Nginx
- Configure Nginx
- Set up a backend server
- Set up a reverse proxy
- Set up HTTPS
- Set up gzip compression
- Set up caching
- Test the setup
- Conclusion

Setting up Nginx as a Reverse Proxy on Windows

Hi there, in this article, I want to show you how to set up Nginx as a reverse proxy on Windows. Nginx is a fast and reliable web server that can also act as a reverse proxy. It can be used to proxy requests to a backend server and provide load balancing, caching, and other features.

Prerequisites

Before starting, you will need to have the following:

A Windows machine to install and run Nginx.
Administrative access to the machine.
The latest stable version of Nginx, which you can download from the official website.

Download and install Nginx

To get started, you need to download and install Nginx on your Windows machine. You can download the latest version of Nginx from the official website, https://nginx.org/. Once the download is complete, run the installer and follow the installation wizard.

Configure Nginx

After installation, navigate to the installation directory of Nginx, which is usually located at C:\nginx. Open the nginx.conf file in a text editor.

Set up a backend server

Next, we need to set up a backend server to which Nginx will forward requests. In this example, let’s assume that our backend server is running on http://localhost:8080.

Set up a reverse proxy

To set up a reverse proxy, we need to create a new location block in the nginx.conf file that will forward requests to the backend server. Add the following code to the file:

location / {
    proxy_pass http://localhost:8080;
}

After you’ve set up the reverse proxy, It’s time to test it. Start the Nginx server and navigate to http://localhost in your web browser. If everything is set up correctly, you should see the same content that is being served by your backend server.

Set up HTTPS

To secure your connection, you can set up HTTPS using an SSL certificate. To do this, you’ll need to obtain an SSL certificate from a trusted certificate authority. Once you have the certificate, open the nginx.conf file and add the following code:

server {
    listen       443 ssl;
    server_name  localhost;

    ssl_certificate      path/to/your/certificate;
    ssl_certificate_key  path/to/your/private_key;

    location / {
        proxy_pass https://localhost:8080;
    }
}

Replace path/to/your/certificate and path/to/your/private_key with the actual paths to our certificate and private key files. Restart the Nginx server to apply the changes.

Set up gzip compression

To improve the performance of your website, you can enable gzip compression in Nginx. This will compress the response data before sending it to the client, resulting in faster page load times. To enable gzip compression, add the following code to the nginx.conf file:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_min_length 1000;
gzip_proxied any;

This code enables gzip compression and specifies the file types that should be compressed. It also sets the minimum file size that should be compressed and specifies that gzip compression should be used for all types of proxied requests.

Set up caching

Finally, we can improve the performance of our website even further by setting up caching in Nginx. Caching stores the response data from the backend server so that it can be served faster to clients who make the same request. To enable caching, add the following code to the nginx.conf file:

proxy_cache_path  C:/nginx/proxy_cache keys_zone=my_cache:10m;

proxy_cache_key "$scheme$request_method$host$request_uri";

proxy_cache_valid  200 302  60m;
proxy_cache_valid  404      1m;

These directives do the following:

proxy_cache_path: This sets the path to the directory where Nginx will store its cache. keys_zone=my_cache:10m sets up a shared memory zone for storing the cache keys, which can be accessed by all worker processes. The 10m value sets the size of the shared memory zone to 10 megabytes.
proxy_cache_key: This sets the cache key. In this case, we’re using a combination of the request method ($request_method), the scheme ($scheme), the host ($host), and the request URI ($request_uri) to generate the cache key.
proxy_cache_valid: This sets the cache expiration time for different response codes. In this example, we’re caching successful responses (200 and 302) for 60 minutes, and 404 responses for 1 minute.

Save the file and restart Nginx.

nginx -s reload

Your Nginx server is now caching responses to requests made to the backend server. This can help speed up your website by reducing the number of requests made to the backend server.

After configuring everything your nginx conf file should be looking like this:

Without SSL

http {
    include       mime.types;
    default_type  application/octet-stream;

    # Logging settings
    access_log  logs/access.log;
    error_log   logs/error.log;

    # Enable Gzip compression
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # Server block
    server {
        listen       80;
        server_name  example.com; # Replace with your domain

        # Location block to handle all requests
        location / {
            # Reverse proxy configuration
            proxy_pass http://localhost:8080; # Replace with your backend server address
            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;
        }

        # Additional location blocks can be defined as needed
        # Example: location /images/ { ... }
    }
}

With SSL

http {
    include       mime.types;
    default_type  application/octet-stream;

    # Logging settings
    access_log  logs/access.log;
    error_log   logs/error.log;

    # Enable Gzip compression
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # SSL settings
    ssl_certificate      /path/to/your/certificate.crt; # Update with your SSL certificate path
    ssl_certificate_key  /path/to/your/private.key;    # Update with your SSL key path
    ssl_protocols        TLSv1 TLSv1.1 TLSv1.2;        # Adjust protocols as needed
    ssl_ciphers          HIGH:!aNULL:!MD5;

    # Server block for HTTPS
    server {
        listen       443 ssl;
        server_name  example.com; # Replace with your domain

        # SSL configuration
        ssl on;

        # Location block to handle all requests
        location / {
            # Reverse proxy configuration
            proxy_pass http://localhost:8080; # Replace with your backend server address
            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;
        }
    }

    # Server block for HTTP to redirect to HTTPS
    server {
        listen      80;
        server_name example.com; # Replace with your domain
        return      301 https://$host$request_uri;
    }
}

Test the setup

To test the setup, open a web browser and enter the IP address of your Nginx server in the address bar. You should see the default Nginx page.

Next, enter the IP address of backend server followed by /app/index.html. You should see the web application.

Congratulations! You have successfully set up Nginx as a reverse proxy on Windows, and configured it to handle HTTPS, compression, and caching. We can now use Nginx to serve multiple web applications and scale our infrastructure as our needs grow.

Conclusion

In this tutorial, we went through the steps to set up Nginx as a reverse proxy on Windows. Nginx is a powerful tool that can help you improve the performance, security, and scalability of your web applications. With the help of this tutorial, you should be able to set up a reverse proxy for your web application and serve it through Nginx.

Источник

Многие знают NGINX как быстрый и эффективный веб-сервер, но это не единственное его применение. Не менее популярно его использование в качестве обратного прокси-сервера, который позволяет получить через единственный внешний адрес доступ сразу к нескольким внутренним ресурсам. Потребность в этом может возникнуть, если у вас существует несколько веб-публикаций 1С:Предприятие на разных серверах к которым нужно организовать доступ для внешних клиентов. Также NGINX поможет обеспечить нам безопасность, взяв на себя SSL-шифрование и парольную аутентификацию.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Почему именно NGINX и именно обратный прокси? Давайте разберем простой пример: в нашей сети есть два условных сервера 1С, каждый из которых имеет веб-публикации, допустим на IIS и Apache. Оба сервера используют одни и те же порты и просто так одновременный доступ к ним организовать не получится, как минимум один из них придется размещать на нестандартном порту, что не добавляет удобства в эксплуатации.

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

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

Для понимания роли и места обратного прокси в инфраструктуре мы создали простую схему:

В нашей условной сети есть два веб-сервера на которых опубликованы информационные базы 1С:Предприятия:

IIS-SRV-1C.LOC — IIS, информационные базы Зарплата и Управление персоналом
APH-SRV-1C.LOC — Apache, информационные базы Бухгалтерия предприятия

Также есть внешний адрес, с которым сопоставлено доменное имя 1с.it-31.lab, наличие доменного имени является обязательным условием для использования сертификатов Let’s Encrypt. Использовать самоподписанные сертификаты для доступа внешних пользователей мы категорически не советуем, так как это поощряет использование нежелательных практик игнорирования ошибок сертификатов, что негативно сказывается на безопасности.

Кроме того, именно NGINX будет дополнительно заниматься парольной аутентификацией, что позволит иметь единую базу пользователей и паролей.

Данная инструкция предназначена для актуальных версий Debian или Ubuntu, все указанные команды следует выполнять с правами суперпользователя root.

Установка и первичная настройка NGINX

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

Поэтому мы рекомендуем подключить репозитории разработчика и установить пакет оттуда. В настоящий момент поддерживаются версии Debian 11 и 12, а также Ubuntu 20.04 и 22.04.

Прежде всего установим необходимые зависимости:

apt install curl gnupg2

Затем получим и установим в хранилище ключ репозитория:

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor > /usr/share/keyrings/nginx-archive-keyring.gpg

И подключим дополнительный репозиторий.

Для Debian:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/debian `lsb_release -cs` nginx"  > /etc/apt/sources.list.d/nginx.list

Для Ubuntu:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" > /etc/apt/sources.list.d/nginx.list

Затем обновим список пакетов и установим NGINX:

apt update
apt install nginx

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

systemctl start nginx
systemctl status nginx

Теперь можете набрать в браузере адрес сервера и вам будет показана стандартная заглушка NGINX.

Создадим некоторые дополнительные директории, в которых мы будем размещать наши конфигурационные файлы:

mkdir /etc/nginx/sites-available
mkdir  /etc/nginx/sites-enabled

Теперь откроем файл /etc/nginx/nginx.conf и после строки:

include /etc/nginx/conf.d/*.conf;

Добавим:

include /etc/nginx/sites-enabled/*;

Проверим правильность конфигурации и перезапустим веб-сервер:

nginx -t 
nginx -s reload

На этом первичная установка и настройка NGINX закончена.

Получение сертификата Let’s Encrypt и настройка SSL-шифрования

Вопрос защиты в наше время стоит достаточно остро и варианты без шифрования сегодня даже не рассматриваются, поэтому займемся этим вопросом в первую очередь. Сначала установим Certbot для работы с сертификатами Let’s Encrypt:

apt install certbot

Теперь создадим файл конфигурации нашего виртуального хоста и приступим к его редактированию, мы будем использовать для этого редактор nano, если вы предпочитаете редактор MC, то замените в команде nano на mcedit:

nano /etc/nginx/sites-available/00-1c.it-31.lab.conf

Имя файла может быть произвольным, но мы советуем называть их по имени обслуживаемого домена.

Затем внесем в него следующий текст:

server {listen 80;
server_name 1c.it-31.lab;
  location ^~ /.well-known/acme-challenge/ {
     default_type "text/plain";
     root /var/www/letsencrypt;
  }
  location = /.well-known/acme-challenge/ {
     return 404;
  }
  return 301 https://$host$request_uri;
}

В данной конфигурации мы указываем, что на порту 80 следует принимать запросы для узла 1c.it-31.lab, ниже идут параметры для работы с Let’s Encrypt, а все остальные запросы будут перенаправляться на защищенную версию ресурса.

Сохраняем конфигурацию и создаем символическую ссылку на нее в директорию /etc/nginx/sites-enabled:

ln -s  /etc/nginx/sites-available/00-1c.it-31.lab.conf /etc/nginx/sites-enabled

Проверяем конфигурацию и перезапускаем веб-сервер:

nginx -t 
nginx -s reload

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

mkdir /var/www/letsencrypt
chown -R nginx:nginx /var/www/letsencrypt

Теперь запустим Certbot и получим сертификат для нашего домена:

certbot certonly --webroot -w /var/www/letsencrypt -d 1c.it-31.lab

После успешного получения сертификата откроем файл с настройками домена /etc/letsencrypt/renewal/1c.it-31.lab.conf и внесем в секцию [renewalparams] следующую опцию:

[renewalparams]
...
renew_hook = nginx -s reload

Это обеспечит перезапуск NGINX после успешного обновления сертификата.

Для режима совершенной прямой секретности создадим файл параметров Диффи-Хелмана:

openssl dhparam -out /etc/ssl/private/dhparam.pem 2048

Теперь откроем /etc/nginx/sites-available/00-1c.it-31.lab.conf и добавим в него секцию:

server {  listen 443 ssl http2;
  server_name 1c.it-31.lab;
  ssl_certificate /etc/letsencrypt/live/1c.it-31.lab/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/1c.it-31.lab/privkey.pem;
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:50m;
  ssl_session_tickets off;
  ssl_dhparam /etc/ssl/private/dhparam.pem;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;
  add_header Strict-Transport-Security "max-age=63072000" always;
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/1c.it-31.lab/chain.pem;
  resolver 8.8.8.8;
}

Еще раз проверим конфигурацию и перезапустим сервер:

nginx -t 
nginx -s reload

Если теперь снова набрать в браузере адрес сервера, то мы снова попадем на страницу-заглушку, но уже через HTTPS-протокол.

Настройка переадресации запросов для веб-публикации 1С:Предприятие

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

http://IIS-SRV-1C.LOC/HRM-1
http://APH-SRV-1C.LOC/ACC-30

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

Для работы обратного прокси мы должны для каждой базы создать отдельный URL с ее именем. Снова откроем /etc/nginx/sites-available/00-1c.it-31.lab.conf и добавим внутрь секции server вложенную секцию:

location /HRM-1/ {
   proxy_pass http://IIS-SRV-1C.LOC/HRM-1/;
   proxy_redirect off;
   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 https;
 }

Первая строка определяет адрес куда мы перенаправляем все запросы пришедшие на URL 1c.it-31.ru/HRM-1, обратите внимание на закрывающие слеши, они обязательны. Остальные опции определяют необходимый режим работы и передачу проксируемому серверу служебных заголовков.

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

location /ACC-30/ {
   proxy_pass http://APH-SRV-1C.LOC/ACC-30/;
   proxy_redirect off;
   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 https;
 }

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

https:// 1c.it-31.ru/HRM-1
https:// 1c.it-31.ru/ACC-30

Чтобы применить изменения сохраните файл конфигурации, проверьте и перезапустите NGINX:

nginx -t 
nginx -s reload

Основная задача выполнена, мы опубликовали для внешних пользователей информационные базы 1С:Предприятие с разных серверов и защитили их надежным шифрованием.

Настройка дополнительной аутентификации по паролю

У нас нет основания сомневаться во встроенном механизме аутентификации 1С:Предприятия, во всяком случае в онлайн-сервисах дополнительной аутентификации не предусмотрено, но есть слабое место — пользователи. Во многих базах могут использоваться простые пароли или не использоваться вообще, часть таких паролей могут использоваться скриптами и средствами автоматизации, поэтому взять и установить сразу всем сложные пароли будет не так-то просто.

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

Для этого установим дополнительный набор утилит:

apt install apache2-utils

Теперь создадим базу пользователей, первого пользователя заводим с использованием ключа -с, в этом случае будет создан новый файл паролей, а существующий перезаписан:

htpasswd -c /etc/nginx/.htpasswd glavbuch

Для следующих пользователей используйте команду:

htpasswd /etc/nginx/.htpasswd buch1

После чего в каждую секцию с информационной базой в /etc/nginx/sites-available/00-1c.it-31.lab.conf добавим строки:

location /HRM-1/ {
   auth_basic "1C users only";
   auth_basic_user_file /etc/nginx/.htpasswd;

Еще раз проверим конфигурацию и перезапустим сервер:

nginx -t 
nginx -s reload

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

Источник

Разберём, что такое Reverse Proxy. А также я покажу как настроить Nginx в качестве Reverse Proxy (обратного прокси сервера).

Теоретическая часть

Иногда бывает нужно чтобы различные url запросы обрабатывались на разных серверах, но первоначально приходили на один сервер. Например, вы пробросили порт на своем роутере на один веб-сервер в вашей внутренней сети. Но хотите чтобы каталог /xxx открывался на втором веб-сервере, а /yyy открывался на третьем, и не хотите пробрасывать порты на каждый web-сервер. Получается вот такая схема:

Nginx — Reverse Proxy

То что мы хотим сделать из сервера web1, называется reverse proxy (обратный прокси).

В то время как forward proxy (прямой прокси) работают от имени клиентов, то есть нам нужно настраивать браузер (клиент), чтобы тот ходил через прямой прокси сервер. Обратные же прокси работают от имени серверов, то есть клиент не знает, что он обращается на прокси сервер.

Reverse proxy принимает запросы от клиентов для того чтобы проксировать их на проксируемые web-сервера (как показано на рисунке).

В качестве обратного прокси сервера для веб серверов может выступать apace или nginx. Есть и другие решения, но в этой статье разберём настройку nginx. На официальном сайте nginx есть небольшой раздел, посвящённый reverse proxy.

Схема сети

Я буду использовать операционную систему Devuan, это облегченный вариант Debian без systemd. Про установку Devuan я уже писал здесь.

У нас будет три сервера:

proxy — reverse proxy — установлен nginx;
web1 — backend web server — установлен apache2;
web2 — backend web server — установлен apache2;

Настраиваем Nginx (Revers Proxy)

Устанавливаем nginx на сервере proxy:

# apt install -y nginx

У меня установился nginx такой версией:

# nginx -v
nginx version: nginx/1.14.2

Для настройки прокси создадим новый виртуальный хост:

# nano /etc/nginx/sites-available/proxy
server {
        # Основные настройки
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name proxy;

        # Управление заголовками на прокси сервере
        proxy_set_header X-Scheme http;
        proxy_set_header X-Forwarded-Proto http;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-PORT $remote_port;
        proxy_set_header X-Real-IP $remote_addr;

        # настройка буфера для прокси сервера
        proxy_buffering on;
        proxy_buffer_size 8k;
        proxy_buffers 8 8k;

        location / {
                # вначале попытаемся обработать запрос как файл,
                # затем как каталог, затем вернём ошибку 404
                try_files $uri $uri/ =404;
        }
        
        # проксируем запрос /xxx на web1
        location /xxx {
                proxy_pass http://web1/test/;
        }
        
        # проксируем запрос /yyy на web2
        location /yyy {
                proxy_pass http://web2/test/;
        }
}

После чего отключим конфиг «default«, включим созданный нами конфиг «proxy» и перезагрузим службу сервера:

# rm /etc/nginx/sites-enabled/default
# ln -s /etc/nginx/sites-available/proxy /etc/nginx/sites-enabled/proxy
# service nginx restart

На основных настройках я не буду заострять внимание, потому как они не относятся к настройке reverse proxy. Если вкратце там мы указали какие порты слушает наш сервер, корень сайта, индексные страницы и имя сервера.

Далее рассмотрим те опции, которые относятся к самому проксированию.

Заголовки X-Scheme и X-Forwarded-Proto

При проксировании мы можем менять заголовки, чтобы backend сервер правильно обрабатывал запросы.

Вначале нужно поменять схему и протокол в запросе, если у вас backend сервер работает на одном протоколе (например http), а к proxy подключаются по другому протоколу (например https). То-есть в заголовках X-Scheme и X-Forwarded-Proto нужно указать протокол подключения к backend серверу.

Схема и протокол это разные понятия. То что вы пишите в браузере (http или https) — это схема. А уже схема указывает браузеру по какому протоколу подключаться к серверу.

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

proxy_set_header X-Scheme http;
proxy_set_header X-Forwarded-Proto http;

Заголовок host

Заголовок host, один из самых важных заголовков. Он определяет адрес домена, который запрашивает браузер. Сервер, получив запрос, ищет у себя сайт с доменом из заголовка host, а также указанную страницу.

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

$http_host — это то что указано в адресной строке вместе с портом, если он указан в адресной строке. Это работает только если порт не стандартный, например 8080. В нашем случае это proxy;
$host — это имя прокси сервера. Оно записано в /etc/nginx/sites-available/proxy, в параметре server_name. В нашем случае proxy;
$proxy_host — это имя backend сервер на который мы проксируем. В нашем случае это web1 или web2.

В конфиге мы указали следующее:

proxy_set_header Host $http_host;

Заголовок X-Forwarded-For

Заголовок X-Forwarded-For содержит список прокси серверов по которым прошёлся клиент перед этим сервером, а переменная $proxy_add_x_forwarded_for содержит полученный заголовок X-Forwarder-For плюс добавляет свой сервер в этот список (это используется для передачи реального ip-клиента на backend).

В конфиге мы указали следующее:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Заголовки X-Real-PORT и X-Real-IP

Эти заголовки содержать содержат ip адрес и порт с которого подключается клиент. Чтобы передать эти значения backend серверу, мы указали следующие параметры:

proxy_set_header X-Real-PORT $remote_port;
proxy_set_header X-Real-IP $remote_addr;

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

А следующие строки отвечают за настройку работы буферной памяти для проксируемой информации:

proxy_buffering — позволяет включить или отключить буферную память для прокси сервера;
proxy_buffer_size — размер буфера для первой части ответа получаемого от проксируемого сервера, такая часть ответа включает в себя только заголовки и хранится отдельно от остальной информации;
proxy_buffers — число и размер буферов для одного соединения, а вот сюда помещается ответ от проксируемого сервера.

proxy_buffering on;
proxy_buffer_size 8k;
proxy_buffers 8 8k;

Что и куда проксируем

Теперь разберем часть конфига, где мы указываем что проксировать и куда проксировать:

location /xxx {
        proxy_pass http://web1/test/;
}

location /yyy {
        proxy_pass http://web2/test/;
}

/xxx — запрос который будем проксировать;
proxy_pass http://web1/test/ — куда будем проксировать, то есть на сервер web1 и на каталог /test.
Ниже подобный блок для /yyy .

Настраиваем Apache2 (backend сервера)

На обоих серверах проделаем одно и тоже! Во-первых установим apache2, затем создадим новый каталог /var/www/html/test. В этом каталоге сделаем индексную страничку index.html в которую запишем html код. Вдобавок поменяем владельца нового каталога на www-data.

Проделываем следующее на обоих серверах:

# apt install -y apache2
# mkdir /var/www/html/test

# nano /var/www/html/test/index.html #(на втором сервере поменяйте web1 на web2)
<!DOCTYPE HTML>
 <html>
  <head>
   <title>web1</title>
  </head>
 <body>
  <p>web1</p>
 </body>
</html>

# chown -R www-data:www-data /var/www/html/test/

Проверка

Используя адрес прокси сервера, откроем xxx:

web1

Используя адрес прокси сервера, откроем yyy:

web2

Как видим у нас открылись разные странички, которые лежат на разных серверах!

Резервирование серверов

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

/xxx — проксируем на http:/web1/test/ — если он доступен;
а если не доступен, то проксируем на http://web2/test/.

Для этого поправим наш конфиг /etc/nginx/sites-enabled/proxy и перед блоком server добавим блок upstream:

# nano /etc/nginx/sites-enabled/proxy
upstream backend {
        server web1:80 fail_timeout=120s max_fails=3;
        server web2:80 backup;
}

server {
        listen 80 default_server;

*** сократил ***

В этом блоке указываем оба web-сервера. При этом web1 будет основным сервером. Но если proxy в течении 120 секунд получит три ошибки при обращении к web1, то на 120 секунд все запросы пойдут на web2.

Ниже в блоке server, где мы указывали что на что проксировать (блоки location), поменяем записи. Вместо web1 укажем название апстрима, которое мы придумали выше (backend). Второй блок (location /yyy) — удаляем. Получится так:

# проксируем запрос /xxx
location /xxx {
         proxy_pass http://backend/test/;
}

Полностью конфиг будет выглядеть так:

upstream backend {
        server web1:80 fail_timeout=120s max_fails=3;
        server web2:80 backup;
}

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name proxy;

        proxy_set_header X-Scheme http;
        proxy_set_header X-Forwarded-Proto http;
        proxy_set_header Host $proxy_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-PORT $remote_port;
        proxy_set_header X-Real-IP $remote_addr;

        proxy_buffering on;
        proxy_buffer_size 8k;
        proxy_buffers 8 8k;

        location / {
                try_files $uri $uri/ =404;
        }

        location /xxx {
                proxy_pass http://backend/test/;
        }
}

Перезапустим nginx:

# service nginx restart

Проверка резервирования

В браузере, используя адрес прокси сервера, открываем /xxx:

Запрос xxx идет на web1

Затем отключаем сервер web1 и обновляем страничку:

Запрос xxx идет на web2

Как видим мы перешли на второй сервер. Теперь включим обратно web1 и обновим страничку еще раз:

Запрос xxx идет на web1

Теперь мы вернулись на первый сервер.

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

Проксирование и абсолютные ссылки

Теперь приведу одну проблему revers proxy серверов — абсолютные ссылки. Пусть наш сайт (на сервере web1) будет содержать ссылку на некоторую свою страничку. Создадим каталог и в нём новую страничку:

# mkdir /var/www/html/test/test/
# nano /var/www/html/test/test/test.html
<!DOCTYPE HTML>
<html>
 <body>
  <p>Hello WEB1</p>
 </body>
</html>

Там же поправим индексную страничку и добавим в неё ссылку:

# nano /var/www/html/test/index.html
<!DOCTYPE HTML>
 <html>
  <head>
   <title>web1</title>
  </head>
 <body>
  <p>web1</p>
  <p><a href="/test/test/test.html">test</a></p>
 </body>
</html>

Обратите внимание, ссылка не относительная, а абсолютная. То-есть начинается с корня сайта.

Откроем web1 напрямую и проверим работу ссылки:

Проверка работы перехода по ссылки на web1

Как видим, при нажатии на ссылку мы переходим по адресу http://web1/test/test/test.html. И у нас всё работает!

Теперь проверим работу на proxy:

Проверка работы перехода по ссылки на proxy

На proxy ссылка не работает. Обратите внимание, на каталог к которому мы пытаемся подключиться /test/test/test.html. А у нас на proxy есть только /xxx, который проксируется на /test. А самого /test нет, вот поэтому мы получили ошибку.

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

# nano /etc/nginx/sites-enabled/proxy
location /test {
        proxy_pass http://backend/test/;
}

# service nginx restart

Проверим работу ссылки на proxy ещё раз:

Проверка работы перехода по ссылки на proxy

Дополнительная информация

Вообще проксирование не простая тема.

Например, проксировать можно https на http или наоборот, но при этом могут возникать проблемы, так как приложение работающее на backend сервере может генерировать ссылки основываясь на схеме. Получается вы к прокси подключаетесь по https, передаёте на backend в заголовке схему http. Затем backend отвечает на http, и приложение генерирует другие ссылки на http и ваш браузер перескакивает на работу по http к proxy, а он допустим умеет только https (и редирект на https не настроен). Получается вот такая картина:

Проблема проксирования, когда proxy и backend работают на разных протоколах

Поэтому, в идеале, нужно чтобы Revers Proxy работал на том же протоколе, что и Backend сервер.

Или проблема может быть ещё хуже. Ссылки на Backend сервере абсолютные и помимо пути содержат адрес сервера, например такие: http://backend/test/ . Это приведёт к тому, что нажав на ссылку вы перескочите с Proxy сервера к Backend серверу, а он может быть напрямую и недоступен.

Поэтому revers proxy делают в основном к своим внутренним сервисам, которые тоже контролируются. А не на внешние сайты. Которые могут и не уметь работать через revers proxy. Для этой задачи применяют forward proxy, например Squid.

Практический пример

Допустим у вас в компании есть свои внутренние сервисы, например сервер управления проектами (project.example.domain — https://192.168.0.5), сервер хранения документов (doc.example.domain — https://192.168.0.6), свой сайт (site.example.domain — https://192.168.0.7). Это всё какие-то приложения с web-интерфейсами. Создадим nginx-proxy для доступа к этим сервисам через него.

Вот конфиг для прокси на сервер управления проектами:

# nano /etc/nginx/sites-enabled/pm
server {
    listen 80;
    server_name project.example.domain;

    return 301 https://$host$request_uri;
}

server {
        listen 443 ssl;
        server_name project.example.domain;

        ssl_certificate     /etc/nginx/ssl/fullchain1.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey1.pem;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!aNULL:!MD5;

        proxy_set_header X-Scheme https;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-PORT $remote_port;
        proxy_set_header X-Real-IP $remote_addr;

        proxy_buffering on;
        proxy_buffer_size 8k;
        proxy_buffers 8 8k;

        location / {
                proxy_pass https://192.168.0.5;
                proxy_redirect off;
        }

}

По аналогии делаем другие конфиги, меняя в них параметры:

server_name — доменное имя сервиса;
proxy_pass — адрес во внутренней сети;

В этом конфиге я добавил редирект с 80 порта на 443 порт, так что вам понадобиться корректный ssl-сертификат. А уже на 443 порту будет происходить проксирование на внутренний сервис.

После этого перезагружаем службу nginx:

# service nginx restart

Все имена, с помощью dns сервера, заворачиваем на адрес nginx-proxy. Прокидываем в интернет 2 порта (80 и 443) на адрес nginx-proxy. И из интернета по разным доменным именам попадаем на один прокси, а уже с него попадаем на внутренние сервисы компании.

Итог

Здесь я разобрал многое, но не всё. Например, можно настроить не резервирование, а балансировку. Про неё, кстати, статей в интернете больше чем про резервный сервер. Я постарался использовать многие http заголовки, чтобы показать как их можно изменять при проксировании. Возможно не все заголовки вам будут нужны в реальной конфигурации. Это зависит от web-приложения, которое вы используете. Буфер для прокси сервера тоже нужно настраивать под конкретную задачу. Поэтому просто копировать приведённые выше конфиги не желательно, нужно анализировать свои действия и все перепроверять.

Если понравилась статья, подпишись на мой канал в VK или Telegram.

Источник

При развертывании высоконагруженных веб-приложений часто приходится взаимодействовать с прокси-сервером. Помимо прямого прокси-сервера (Forward Proxy Server), существуют также обратный прокси-сервер (Reverse Proxy Server), цель которого заключается в повышении безопасности и производительности, а также в управлении трафиком путем обработки запросов от клиентов и распределения их между несколькими внутренними сервисами. Также обратный прокси-сервер используется для сокрытия реального IP-адреса сервиса, тем самым повышая уровень безопасности. Сегодня мы рассмотрим программный продукт Nginx Proxy Manager, который можно использовать как reverse proxy (обратный прокси) для веб-приложений.

Nginx Proxy Manager — это обратный прокси-сервер (reverse proxy) с поддержкой графического интерфейса, разработанный для упрощения настройки и управлением обратными прокси на основе веб-сервера Nginx. Сервис используется для организации доступа к различным веб-приложениям через единую точку входа (в качестве единой точки входа может выступать, например, доменное имя или IP-адрес) с дальнейшей маршрутизацией до конечного приложения.

Главная особенность Nginx Proxy Manager заключается в отсутствии необходимости вручную редактировать конфигурационные файлы. Вместо этого вся настройка осуществляется через встроенный веб-интерфейс. Проект является полностью бесплатным и не обладает дополнительными платными тарифами, а также имеет открытый исходный код, доступный на платформе GitHub.

Отличие Nginx Proxy Manager от Nginx

Несмотря на наличие слова «Nginx» в название программы, Nginx Proxy Manager не имеет прямого отношения к компании NGINX Inc., которая является коммерческим разработчиком оригинального веб-сервера Nginx. Однако Nginx Proxy Manager основан на оригинальном исходном коде Nginx и использует его в качестве основы для своей работы.

Также NPM обладает расширенным функционалом, который включает в себя следующие особенности:

Встроенный веб-интерфейс.
Быстрая и удобная настройка переадресации доменов, использование встроенной функции Streams для настройки потоков данных, проходящих через протоколы TCP/UDP, а также кастомизация страниц с кодом ошибки 404.
Наличие встроенного сервиса Let’s Encrypt для выпуска бесплатных SSL сертификатов. Также сохраняется возможность использования самоподписанных сертификатов и сертификатов, выпущенных сторонними удостоверяющими центрами.
Функционал по обеспечению безопасности, включающий в себя списки доступов (Access-control list) и HTTP-аутентификацию (HTTP Basic Auth).
Управление пользователями, настройка прав доступа и аудит лог файлов.

Предварительные требования

Чтобы установить и использовать Nginx Proxy Manager, нам понадобится следующее:

Один сервер или одна виртуальная машина с любым предустановленным дистрибутивом Linux. В данной статье в качестве примера мы будем использовать дистрибутив Ubuntu 24.04.

Сервер должен соответствовать следующим требованиям:

Минимум 1 ГБ оперативной памяти. Данный объем подойдет только для тестирования Nginx Proxy Manager и не предназначен для решения реальных задач. Для production-решений необходимо минимум 2 ГБ оперативной памяти. При тестировании конфигурации на собственном устройстве будет достаточно менее 1 ГБ оперативной памяти.
Минимум 1-ядерный процессор для тестирования конфигурации. Для выполнения реальных задач рекомендуется 4-ядерный процессор.

Сервер можно создать в панели управления в разделе «Облачные серверы». В процессе:

Выберите регион с минимальным пингом для быстрой передачи данных.
Выберите конфигурацию, достаточную для ваших задач. В рамках данной статьи для запуска и тестового использования Nginx Proxy Manager без реальной нагрузки будет достаточно конфигурации с одноядерном процессором, 1 ГБ оперативной памяти и 15 ГБ места на NVMe-диске.

Остальные параметры можно оставить без изменений.

Сервер будет запущен через пару минут, и вы сможете найти IP-адрес, логин и пароль для подключения на Дашборде сервера.

cloud

Подготовка сервера

Настройка Firewall

На сервере должны быть открыты порты 80, 81 и 443, которые Nginx Proxy Manager использует в своей работе. По умолчанию в дистрибутиве Ubuntu используется утилита UFW. Необходимо открыть данные порты, используя следующие команды:

Для протокола TCP:

ufw allow 80,81,443/tcp

Для протокола UDP:

ufw allow 80,81,443/udp

Либо UFW можно выключить совсем, если он не используется:

systemctl stop ufw && systemctl disable ufw

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

Для входящих соединений по протоколу TCP:

iptables -A INPUT -p tcp --match multiport --dports 80,81,443 -j ACCEPT

Для входящих соединений по протоколу UDP:

iptables -A INPUT -p udp --match multiport --dports 80,81,443 -j ACCEPT

Для исходящих соединений по протоколу TCP:

iptables -A OUTPUT -p tcp --match multiport --dports 80,81,443 -j ACCEPT

Для исходящих соединений по протоколу UDP:

iptables -A OUTPUT -p udp --match multiport --dports 80,81,443 -j ACCEPT

Установка Docker и Docker Compose

Для работы с Nginx Proxy Manager нам потребуются Docker и Docker Compose, которые мы установим из официального репозитория Docker. Для этого выполняем следующие шаги:

Создаем директорию /etc/apt/keyrings с правами доступа 0755:

sudo install -m 0755 -d /etc/apt/keyrings

При помощи утилиты curl скачиваем GPG-ключ от официального репозитория Docker и перемещаем его в ранее созданную директорию /etc/apt/keyrings:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

Выставляем права на чтение для скачанного ключа:

chmod a+r /etc/apt/keyrings/docker.asc

Добавляем адрес официального репозитория Docker в систему:

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Обновляем индекс репозиториев и устанавливаем пакеты docker и docker-compose:

apt update && apt -y install docker-ce docker-compose-plugin

Проверьте успешность установки.

Для проверки установки Docker:

docker --version




          Картинка с сайта: timeweb.cloud

Для проверки установки Docker Compose:

docker compose version




          Картинка с сайта: timeweb.cloud

Если обе команды вернули версии программ, то Docker и Docker Compose успешно установлены в системе.

Подготовка тестовых приложений

В качестве теста мы будем использовать три контейнера Docker с веб-сервером Nginx. У каждого запущенного контейнера свой уникальный порт, при обращении к которому будет отображаться своя фраза. Цель будет заключаться в следующем: используя Nginx Proxy Manager, «опубликовать» все три сервиса, чтобы они были доступны пользователям в рамках частной сети по доменным именам и возвращали пользователям свой уникальный контент. Для этого нам понадобится три доменных имени. Так как все действия производятся сугубо для тестирования, мы воспользуемся локальными доменами, а именно пропишем тестовые доменные в файле /etc/hosts.

По умолчанию, Docker создает свою подсеть с адресом 172.17.0.1:




          Картинка с сайта: timeweb.cloud

Открываем на редактирование при помощи любого текстового редактора файл hosts:

nano /etc/hosts

И прописываем три тестовых домена, используя в качестве IP-адреса адрес интерфейса Docker — docker0.

172.17.0.1 nginx1.test.com
172.17.0.1 nginx2.test.com
172.17.0.1 nginx3.test.com




          Картинка с сайта: timeweb.cloud

Сохраняем изменения и выходим из файла.

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

mkdir nginx-test-apps && cd nginx-test-apps

Создаем файл с именем docker-compose.yml:

nano docker-compose.yml

Используем следующее содержимое:

services:
  nginx1:
    image: nginx:alpine3.21
    ports:
      - "8081:80"
    volumes:
      - ./nginx1/html:/usr/share/nginx/html
    command: ["/bin/sh", "-c", "echo 'Hello from nginx1!' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'"]

  nginx2:
    image: nginx:alpine3.21
    ports:
      - "8082:80"
    volumes:
      - ./nginx2/html:/usr/share/nginx/html
    command: ["/bin/sh", "-c", "echo 'Hello from nginx2!' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'"]

  nginx3:
    image: nginx:alpine3.21
    ports:
      - "8083:80"
    volumes:
      - ./nginx3/html:/usr/share/nginx/html
    command: ["/bin/sh", "-c", "echo 'Hello from nginx3!' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'"]




          Картинка с сайта: timeweb.cloud

Сохраняем изменения и выходим из файла.

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

docker compose up -d

Убедимся, что все три контейнера успешно запущены, используя команду:

docker ps




          Картинка с сайта: timeweb.cloud

Также проверим что все три приложения возвращаю в ответе свою фразу. Для этого используем команду curl с указанием IP-адреса сервера и порта контейнера:

curl 172.17.0.1:8081
curl 172.17.0.1:8082
curl 172.17.0.1:8083




          Картинка с сайта: timeweb.cloud

Все три контейнера возвращают свои уникальные ответы. На этом подготовка тестовых приложений завершена.

Запуск и настройка Nginx Proxy Manager

Далее мы подробно рассмотрим процесс запуска и настройки Nginx Proxy Manager.

Запуск базовой конфигурации

Для начала рассмотрим базовый запуск программы, используя минимальный набор параметров.

Создаем новую директорию для проекта и переходим в нее:

mkdir nginx-proxy-manager-basic && cd nginx-proxy-manager-basic

Внутри директории создаем новый файл с именем docker-compose.yml:

nano docker-compose.yml

И используем следующую конфигурацию:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt




          Картинка с сайта: timeweb.cloud

Сохраняем изменения и выходим из файла.

Для запуска воспользуемся командой:

docker compose up -d




          Картинка с сайта: timeweb.cloud

При первом запуске дожидаемся процесса скачивания образа. При успешном завершении процесса команда сообщит о том, что контейнер был запущен:




          Картинка с сайта: timeweb.cloud

По итогу у нас будет запущен один контейнер с Nginx Proxy Manager, у которого проброшены порты 80, 81 и 443.

На этом процесс запуска успешно завершен. Далее мы рассмотрим настройку Nginx Proxy Manager для трех веб-приложений, запущенных в контейнерах Docker.

Первоначальная настройка Nginx Proxy Manager

Ранее мы упоминали, что настройка Nginx Proxy Manager осуществляется исключительно через веб-интерфейс. Веб-консоль доступна на 81 порту. Открываем браузер и переходим по IP-адресу сервера, используя порт 81:




          Картинка с сайта: timeweb.cloud

Логин (Email) и пароль по умолчанию следующие:

Email: admin@example.com
Password: changeme

При первом входе программа предложит поменять данные стандартного пользователя. Имя пользователя и псевдоним (nickname) можно поменять по желанию, однако адрес электронный почты надо обязательно сменить со стандартного на другой:




          Картинка с сайта: timeweb.cloud

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




          Картинка с сайта: timeweb.cloud

После этого отобразится главная страница Nginx Proxy Manager:




          Картинка с сайта: timeweb.cloud

Настройка и использование Nginx Proxy Manager

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

В веб-интерфейсе Nginx Proxy Manager переходим в раздел Proxy Hosts:




          Картинка с сайта: timeweb.cloud

Далее нажимаем на кнопку Add Proxy Host:




          Картинка с сайта: timeweb.cloud

Далее:
- В поле Domain name вводим доменное имя, по которому будет доступно приложение.
- В поле Forward Hostname / IP вводим IP адрес контейнера (в нашем случае это внутренний IP-адрес интерфейса Docker).
- В разделе Forward Port необходимо указать порт контейнера, который «слушает» сервис.




          Картинка с сайта: timeweb.cloud

Для сохранения конфигурации используем кнопку Save.

Для добавления нового прокси-хоста нажимаем на кнопку Add Proxy Host, которая располагается справа сверху:




          Картинка с сайта: timeweb.cloud

По аналогии добавляем второе приложение:




          Картинка с сайта: timeweb.cloud

И третье:




          Картинка с сайта: timeweb.cloud

В итоге у нас будут добавлены три приложения:




          Картинка с сайта: timeweb.cloud

После того как все приложения будут добавлены, возвращаемся на сервер и при помощи утилиты curl отправляем запрос на каждый из доменных имен:




          Картинка с сайта: timeweb.cloud

По итогу мы получили уникальный ответ от каждого приложения.

Подключение MySQL/MariaDB

По умолчанию для хранения конфигурации и данных Nginx Proxy Manager использует встраиваемую СУБД SQLite. Однако при желании SQLite можно поменять на MySQL или на MariaDB. В качестве минимально поддерживаемых версий заявлены следующие:

MySQL версии 5.7.8 и выше
MariaDB версии 10.2.7 и выше

Ниже приведен пример использования конфигурации с СУБД MySQL/MariaDB:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    environment:
      DB_MYSQL_HOST: "db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "npm"
      DB_MYSQL_NAME: "npm"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - db

  db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: 'npm'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'npm'
      MARIADB_AUTO_UPGRADE: '1'
    volumes:
      - ./mysql:/var/lib/mysql

В качестве переменных окружения используются следующие:

DB_MYSQL_HOST — Адрес сервера, на котором запущена база данных.
DB_MYSQL_PORT — Номер порта, через который осуществляется подключение к базе данных.
DB_MYSQL_USER — Имя пользователя, используемое для аутентификации в базе данных.
DB_MYSQL_PASSWORD — Пароль пользователя, из-под которого осуществляется подключение к базе данных.
DB_MYSQL_NAME — Название базы данных, к которой производиться подключение.
MYSQL_ROOT_PASSWORD — Пароль пользователя root в MySQL.
MYSQL_DATABASE — Название базы данных, которая будет автоматически создана при запуске MySQL.
MYSQL_USER — Имя дополнительного пользователя, из-под имени которого будет запущена база данных.
MYSQL_PASSWORD — Пароль для пользователя, указанного в переменной MYSQL_USER.
MARIADB_AUTO_UPGRADE — Параметр, отвечающий за необходимость автоматического обновления схемы базы данных MariaDB до последней версии при запуске.

Все значения переменных, перечисленных выше, можно поменять в соответствии с вашими требованиями.

Подключение PostgreSQL

Помимо MySQL и MariaDB, в официальной документации по Nginx Proxy Manager упоминается и PostgreSQL, но официально поддержка PostgreSQL не заявлена. Однако в тестовых целях PostgreSQL можно использовать. Для этого достаточно применить следующую конфигурацию:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    environment:
      DB_POSTGRES_HOST: 'db'
      DB_POSTGRES_PORT: '5432'
      DB_POSTGRES_USER: 'npm'
      DB_POSTGRES_PASSWORD: 'npmpass'
      DB_POSTGRES_NAME: 'npm'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - db

  db:
    image: postgres:latest
    environment:
      POSTGRES_USER: 'npm'
      POSTGRES_PASSWORD: 'npmpass'
      POSTGRES_DB: 'npm'
    volumes:
      - ./postgres:/var/lib/postgresql/data

Обратите внимание, что в качестве тега для образа postgres задан тег latest, что может привести к неработоспособности сервиса или содержать недоработки, а также проблемы, связанные с безопасностью.

Заключение

Nginx Proxy Manager — это удобный инструмент для тех пользователей, кому необходимо настроить прокси-сервер без лишних неудобств. Сервис легко и быстро разворачивается в Docker, а вся настройка происходит исключительно в веб-интерфейсе, благодаря чему с программой сможет работать даже начинающий пользователь. Nginx Proxy Manager обладает самым необходимым функционалом, включающим управление доменами, настройку SSL, переадресацию и даже защиту доступа.

Источник

Downloading Nginx for Windows

Configuring hosts file of Windows

Configuring Nginx Reverse Proxy

Starting Nginx

Starting Nginx

Visit

Stop Nginx

Reload the configuration of Nginx

Table of Contents

Setting up Nginx as a Reverse Proxy on Windows

Prerequisites

Download and install Nginx

Configure Nginx

Set up a backend server

Set up a reverse proxy

Set up HTTPS

Set up gzip compression

Set up caching

Test the setup

Conclusion

Установка и первичная настройка NGINX

Получение сертификата Let’s Encrypt и настройка SSL-шифрования

Настройка переадресации запросов для веб-публикации 1С:Предприятие

Настройка дополнительной аутентификации по паролю

Теоретическая часть

Схема сети

Настраиваем Nginx (Revers Proxy)

Заголовки X-Scheme и X-Forwarded-Proto

Заголовок host

Заголовок X-Forwarded-For

Заголовки X-Real-PORT и X-Real-IP

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

Что и куда проксируем

Настраиваем Apache2 (backend сервера)

Проверка

Резервирование серверов

Проверка резервирования

Проксирование и абсолютные ссылки

Дополнительная информация

Практический пример

Итог

Отличие Nginx Proxy Manager от Nginx

Предварительные требования

Подготовка сервера

Настройка Firewall

Установка Docker и Docker Compose

Подготовка тестовых приложений

Запуск и настройка Nginx Proxy Manager

Запуск базовой конфигурации

Первоначальная настройка Nginx Proxy Manager

Настройка и использование Nginx Proxy Manager

Подключение MySQL/MariaDB

Подключение PostgreSQL

Заключение