Nginx proxy что это

10 апреля, 2018 12:29 пп

В этом руководстве мы обсудим возможности HTTP-проксирования веб-сервера Nginx, которые позволяют ему передавать запросы на http-серверы бэкэнда для дальнейшей обработки. Nginx часто настраивается как обратный прокси-сервер, который помогает масштабировать инфраструктуру или передавать запросы другим серверам, которые не предназначены для обработки больших клиентских нагрузок.

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

Содержание

Основы проксирования
Директива proxy_pass
Обработка заголовков в Nginx
Настройка или сброс заголовков
Раздел Upstream для балансировки нагрузки проксируемых соединений
Изменение алгоритма балансировки в контексте upstream
Установка веса сервера для балансировки
Использование буферов для освобождения бэкэнд-серверов
Высокая доступность (опционально)
Кэширование и снижение времени ответа
Настойка прокси-кэша
Рекомендации по кэшированию результатов
1: Установка Nginx
3: Тестирование обратного прокси с помощью Gunicorn (опционально)
Virtual Hosts on nginx (CSC309)
Install nginx
CDF @UofT
Ubuntu
Mac OS
Configuration
Step 1 — Booting Servers for Virtual Hosts
Step 2 — Configure nginx’s Port
Step 3 — Configure /
Step 4 — Reload nginx’s Configuration
Step 5 — Add /blog and /mail
Step 6 — Reload Your nginx Configuration
Step 7 — Rewriting Requests
Step 8 — Reload and Test.
Exercise 1
Step 9 (optional) — Redirecting Based on Host Name
Теоретическая часть
Схема сети
Настраиваем Nginx (Revers Proxy)
Заголовки X-Scheme и X-Forwarded-Proto
Заголовки X-Real-PORT и X-Real-IP
Параметры отвечающие за буферную память
Что и куда проксируем
Настраиваем Apache2 (backend сервера)
Резервирование серверов
Проксирование и абсолютные ссылки
Дополнительная информация
Итог
Вступление
Общая информация о прокси

Основы проксирования

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

Вторя причина настроить HTTP-проксирование – это наличие в инфраструктуре серверов приложений, которые не могут обрабатывать клиентские запросы напрямую в производственных средах. Многие фреймворки предоставляют встроенные веб-серверы, но большинство из них не столь надежны, как высокопроизводительные серверы, такие как Nginx. Использование обратного прокси Nginx может улучшить пользовательский опыт и повысить безопасность.

Проксирование в Nginx осуществляется путем обработки запроса, направленного на сервер Nginx, и передачи его другим серверам для фактической обработки. Результат запроса передается обратно на Nginx, который затем передает информацию клиенту. Другими серверами в этом случае могут быть удаленные компьютеры, локальные серверы или даже другие виртуальные серверы, определенные в настройке Nginx. Серверы, к которым обращается прокси Nginx, называются upstream серверами.

Nginx может проксировать запросы на серверы, которые обмениваются данными с помощью протоколов http(s), FastCGI, SCGI и uwsgi или memcached через отдельные наборы директив для каждого типа проксирования. В этом мануале мы сосредоточимся на протоколе http. Экземпляр Nginx отвечает за передачу запроса и связь с любым компонентом обмена сообщениями в формате, который может понять upstream сервер.

Директива proxy_pass

Самый простой тип проксирования включает в себя передачу запроса на один сервер, который может связываться с помощью http. Этот тип проксирования известен как proxy pass и обрабатывается одноименной директивой proxy_pass.

Директива proxy_pass в основном встречается в контекстах location. Она также поддерживается блоками if в контексте location и limit_except. Когда запрос совпадает с адресом, указанным в proxy_pass, он пересылается по этому URL-адресу.

Рассмотрим такой пример:

В приведенном выше фрагменте конфигурации в конце блока server в определении proxy_pass не указывается URI. Для определений, соответствующих этому шаблону, запрошенный клиентом URI будет передан на upstream сервер без изменений.

Например, когда этот блок обрабатывает запрос /match/here/please, URI запроса будет отправлен на сервер example.com как http://example.com/match/here/please.

Рассмотрим альтернативный сценарий:

В приведенном выше примере прокси-сервер определяется вместе с сегментом URI в конце (/new/prefix). Когда в определении proxy_pass указывается URI, то часть запроса, которая соответствует определению location, заменяется этим URI.

К примеру, запрос /match/here/please будет передаваться на upstream сервер как http://example.com/new/prefix/please. Префикс /match/here заменяется на /new/prefix. Об этом важно помнить.

Иногда такая замена невозможна. В этих случаях URI в конце определения proxy_pass игнорируется, и на upstream сервер передается исходный URI клиента или URI, измененный другими директивами.

Например, при использованием регулярных выражений Nginx не может определить, какая часть URI соответствует выражению, поэтому он отправляет исходный URI-запрос клиента. Или, например, если директива rewrite используется в одном и том же location, она переписывает URI клиента, но он все же обрабатывается в одном блоке. В этом случае будет передан переписанный URI.

Обработка заголовков в Nginx

Чтобы upstream сервер обработал запрос должным образом, одного URI недостаточно. Запрос, поступающий от имени клиента через Nginx, будет выглядеть иначе, чем запрос, поступающий непосредственно от клиента. Большая часть этого – заголовки, которые согласуются с запросом.

Когда Nginx проксирует запрос, он автоматически вносит некоторые поправки в заголовки, полученные от клиента.

Nginx избавляется ото всех пустых заголовков. Нет смысла передавать пустые значения другому серверу; это только усложнит передачу запроса.
Все заголовки, которые содержат символы подчеркивания, Nginx по умолчанию рассматривает как недопустимые. Он удалит их из запроса. Если вы хотите, чтобы Nginx интерпретировал их как валидные, вы можете установить в директиве underscores_in_headers значение on, в противном случае такие заголовки никогда не попадут на бэкэнд-сервер.
Заголовок Host переписывается значением, определяемым переменной $proxy_host. Это может быть IP-адрес или имя и номер порта upstream сервера, как указано в директиве proxy_pass.
Заголовок Connection заменяется значением close. Этот заголовок используется для передачи информации о конкретном соединении, установленном между двумя сторонами. В этом случае Nginx устанавливает это значение, чтобы указать upstream серверу, что это соединение будет закрыто после ответа на исходный запрос. Не следует ожидать, что это upstream соединение будет постоянным.

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

Заголовок Host часто имеет такие значения:

$proxy_host: устанавливает в Host домен или IP-адрес и порт из определения proxy_pass. Это значение по умолчанию надежно с точки зрения Nginx, но оно не всегда подходит для правильной обработки запроса.
$http_host: устанавливает в Host заголовок Host из клиентского запроса. Заголовки, отправленные клиентом, всегда доступны Nginx в качестве переменных. Переменные начинаются с префикса $http_, после которого устанавливается имя заголовка в нижнем регистре, а все тире заменяются нижним подчеркиванием. Помните, что переменная $http_host не сработает, если в запросе клиента нет валидного заголовка Host.
$host: эта переменная может принимать в качестве значений имя хоста из запроса, заголовок host из клиентского запроса или имя сервера соответствующего запроса.

В большинстве случаев нужно установить в заголовке Host переменную $host. Это наиболее гибкий вариант, который обычно обеспечивает точное заполнение заголовка.

Настройка или сброс заголовков

Чтобы настроить или установить заголовки для прокси-соединений, можно использовать директиву proxy_set_header. Например, чтобы изменить заголовок Host и добавить дополнительные заголовки, нужно использовать что-то вроде этого:

Здесь заголовок Host получит значение переменной $host, в которой должна содержаться информация о запрошенном исходном хосте. Заголовок X-Forwarded-Proto предоставляет прокси-серверу информацию о схеме исходного запроса клиента (будь то http или https-запрос).

Конечно, директиву proxy_set_header стоит переместить в контекст server или http, чтоб иметь возможность ссылаться на нее:

Раздел Upstream для балансировки нагрузки проксируемых соединений

В предыдущих примерах вы увидели, как сделать настроить простое HTTP-прокси соединение на одном сервере. Nginx позволяет легко масштабировать эту конфигурацию, указав целые пулы бэкэнд-серверов, на которые можно передавать запросы.

Это можно сделать с помощью директивы upstream, которая позволяет определить пул серверов. Эта конфигурация предполагает, что любой из перечисленных серверов способен обрабатывать запрос клиента. Это позволяет масштабировать инфраструктуру практически без усилий. Директива upstream должна быть установлена в контексте http конфигурации Nginx.

Рассмотрим простой пример:

Изменение алгоритма балансировки в контексте upstream

Настроить алгоритм в пуле upstream можно с помощью таких флагов и директив:

round robin: Алгоритм балансировки нагрузки по умолчанию, который используется, если не указано других директив. Каждый запрос будет последовательно передаваться серверам, определенным в контексте upstream.
least_conn: Указывает, что новые соединения всегда должны быть привязаны к бэкэнду, который имеет наименьшее количество активных соединений. Это может быть особенно полезно в ситуациях, когда соединения с бэкэндом могут сохраняться в течение некоторого времени.
ip_hash: Этот алгоритм балансировки распределяет запросы между серверами на основе IP-адреса клиента. Первые три октета используются в качестве ключа, на основе которого выбирается сервер для обработки запроса. В результате клиенты, как правило, обслуживаются одним и тем же сервером при каждом подключении, что обеспечивает согласованность сеансов.
hash: Этот алгоритм балансировки в основном используется с прокси-сервером memcached. Серверы делятся на группы на основе значения произвольно предоставленного хэш-ключа. Ключ может быть текстом, переменной или разными комбинациями. Это единственный метод балансировки, который требует от пользователя предоставить данные (ключ).

При изменении алгоритма блок может выглядеть так:

В приведенном выше примере сервер будет выбран по наименьшему количеству соединений. Можно также добавить директиву ip_hash, чтобы обеспечить «липкость» сессии.

Что касается метода hash, вы должны указать ключ для хэша. Это может быть что угодно:

Установка веса сервера для балансировки

В объявлениях бэкэнд-серверов по умолчанию все серверы весят одинаково. Это предполагает, что каждый сервер может и должен обрабатывать одинаковый объем нагрузки (с учетом эффектов алгоритмов балансировки). Тем не менее, вы также можете установить пользовательский вес своих серверов:

Теперь host1.example.com будет получать в три раза больше трафика, чем другие два сервера. Вес каждого сервера по умолчанию равен 1.

Использование буферов для освобождения бэкэнд-серверов

Один из главных вопросов при проксировании – насколько изменится скорость работы при добавлении сервера. Увеличение или уменьшение количества серверов можно значительно смягчить с помощью системы буферизации и кэширования Nginx.

При проксировании на другой сервер на опыт клиента влияет скорость двух разных подключений:

Подключения клиента к прокси Nginx.
И подключения прокси-сервера Nginx к серверу.

Nginx имеет возможность корректировать свое поведение на основе того, какое из этих соединений вы хотите оптимизировать.

Без буферов данные с прокси-сервера сразу же отправляются к клиенту. Если клиентские соединения быстрые, буферизацию можно отключить, чтобы клиент как можно скорее мог получить данные. При использовании буферов прокси-сервер Nginx будет временно хранить ответ бэкэнда, а затем передавать эти данные клиенту. Если клиент работает медленно, это позволит серверу Nginx быстрее закрыть соединение с бэкэндом. Затем он сможет обрабатывать передачу данных клиенту любым возможным способом.

Nginx по умолчанию использует буферизацию, так как скорость соединения, как правило, меняется в зависимости от клиента. Буферизация настраивается с помощью следующих директив. Их можно установить в контексте http, server или location. Важно иметь в виду, что директивы size касаются каждого запроса, поэтому они могут повлиять на производительность серверов при поступлении множества клиентских запросов.

proxy_buffering: эта директива определяет, включена ли буферизация для этого контекста и его дочерних контекстов. По умолчанию имеет значение on.
proxy_buffers: Эта директива контролирует количество (первый аргумент) и размер (второй аргумент) буферов. По умолчанию используется 8 буферов, размер которых равен одной странице памяти (либо 4k, либо 8k). Увеличение количества буферов позволяет буферизовать дополнительную информацию.
proxy_buffer_size: Исходная часть ответа от бэкэнд-сервера, которая содержит заголовки, буферизуется отдельно от остальных данных. Эта директива устанавливает размер буфера для этой части ответа. По умолчанию она будет того же размера, что и proxy_buffers, но поскольку здесь хранятся только заголовки, ее можно уменьшить.
proxy_busy_buffers_size: Эта директива устанавливает максимальное количество занятых буферов. Хотя клиент может считывать данные только из одного буфера за раз, буферы помещаются в очередь для отправки фрагментов данных клиенту. Эта директива управляет размером буферного пространства, которое может находиться в этом состоянии.
proxy_max_temp_file_size: Это максимальный размер временного файла каждого запроса на диске. Они создаются, если ответ бэкэнда слишком велик и не помещается в буфер.
proxy_temp_file_write_size: Это количество данных, которые Nginx будет записывать во временный файл за один раз, если ответ прокси-сервера слишком велик и не помещается в буфер.
proxy_temp_path: Это путь к области на диске, где Nginx должен хранить временные файлы, когда ответ upstream сервера не помещается в буфер.

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

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

Если у вас есть быстрые клиенты, которым нужно быстро отправить данные, можно полностью отключить буферизацию. Nginx будет по-прежнему использовать буферы, если сервер upstream быстрее, чем клиент, но он попытается немедленно передать данные клиенту. Если клиент работает медленно, это может привести к тому, что upstream соединение останется открытым до тех пор, пока клиент не сможет получить данные. Когда буферизация выключена, будет использоваться только буфер, определенный директивой proxy_buffer_size:

Высокая доступность (опционально)

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

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

Кэширование и снижение времени ответа

Буферизация помогает освободить сервер бэкэнда для обработки большего количества запросов, но Nginx также может кэшировать контент с бэкэнд-серверов, устраняя необходимость подключения к upstream серверу для обработки запросов.

Настойка прокси-кэша

Для настройки кэширования ответов бэкэнд серверов можно использовать директиву proxy_cache_path, которая определяет пространство для хранения кэша. Её следует задавать в контексте http.

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

# http context proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backcache:8m max_size=50m; proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args"; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m;

Директива proxy_cache_path определяет каталог в файловой системе, где нужно хранить кэш. В этом примере это каталог /var/lib/nginx/cache. Если этот каталог не существует, вы можете создать его и определить права доступа к нему:

sudo mkdir -p /var/lib/nginx/cache sudo chown www-data /var/lib/nginx/cache sudo chmod 700 /var/lib/nginx/cache

Параметр levels= указывает, как будет организован кэш. Nginx создаст ключ кеша путем хэширования значения ключа (он настраивается ниже). В результате будет создан каталог, имя которого состоит из одного символа (это будет последний символ хешированного значения), и подкаталог с именем из двух символов (следующие два символа в конце хэша). Это помогает Nginx быстро найти соответствующие значения.

Параметр keys_zone= определяет имя зоны кеша (backcache). Здесь также указывается, сколько метаданных можно хранить. В этом случае сервер будет хранить 8 МБ ключей. На 1 мегабайте Nginx может хранить около 8000 записей. Параметр max_size устанавливает максимальный размер кэшированных данных.

Директива proxy_cache_key устанавливает ключ, который будет использоваться для хранения кешированных значений. Этот же ключ используется для проверки того, можно ли запросить данные из кеша. Здесь используется комбинация схемы (http или https), метода HTTP-запроса, а также запрошенного хоста и URI.

Директива proxy_cache_valid может быть указана несколько раз. Она позволяет определить, как долго должны храниться значения в зависимости от кода состояния. В данном примере удачные и переадресованные ответы хранятся в течение 10 минут, а ответы 404 удаляются каждую минуту.

Теперь зона кэширования настроена, но пока что Nginx не знает, когда именно применять кеширование.

Эта информация указывается в контексте location для бекэнд серверов:

Директива proxy_chache_bypass принимает значение переменной $http_cache_control. Эта переменная сообщает, запросил ли клиент свежий, не кэшированный ответ. При использовании этой директивы Nginx сможет корректно обрабатывать запросы такого типа. Никаких дальнейших настроек не для этого не требуется.

Мы также добавили дополнительный заголовок X-Proxy-Cache. Этот заголовок принимает значение переменной $upstream_cache_status. Это позволяет увидеть, обработан ли запрос из кэша, этих данных не было в кэше или клиент запросил новый ответ. Это особенно полезно для отладки.

1: Установка Nginx

Nginx доступен для установки с помощью apt через репозитории по умолчанию. Обновите индекс репозитория, а затем установите Nginx:

sudo apt update sudo apt install nginx

Чтобы подтвердить установку нажмите Y. Если будет предложено перезапустить службы, нажмите ENTER, чтобы принять настройки по умолчанию.

Нужно разрешить доступ к Nginx через брандмауэр. Для этого добавьте правило в ufw:

sudo ufw allow 'Nginx HTTP'

Теперь проверим, что Nginx работает:

systemctl status nginx

nginx.service - A high performance web server and a reverse proxy server     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)     Active: active (running) since Mon 2022-08-29 06:52:46 UTC; 39min ago   Main PID: 9919 (nginx)      Tasks: 2 (limit: 2327)             ├─9919 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"             └─9920 "nginx: worker process

Рекомендуем не редактировать конфигурацию по умолчанию, а создать пользовательский конфигурационный файл для новых блоков server. С помощью nano или другого текстового редактора создайте и откройте новый файл конфигурации Nginx:

sudo nano /etc/nginx/sites-available/your_domain

Если у вас нет сервера приложений для тестирования, по умолчанию используйте http://127.0.0.1:8000 (мы настроим сервер Gunicorn в разделе 3). Вставьте следующее в новый файл, не забудьте изменить your_domain и app_server_address:

    server_name your_domain www.your_domain;

Сохраните и закройте файл. В nano нажмите CTRL+O, затем CTRL+X.

Файл конфигурации начинается со стандартной настройки Nginx, где Nginx будет слушать порт 80 и отвечать на запросы к your_domain и www.your_domain. Обратный прокси включается с помощью директивы Nginx proxy_pass. При такой конфигурации переход к your_domain в локальном браузере будет таким же, как открытие app_server_address на удаленной машине. В этом мануале будет проксироваться только один сервер приложений, но Nginx может быть прокси-сервером для нескольких серверов сразу. Для этого нужно добавить дополнительные блоки location, одно имя сервера может объединить несколько серверов приложений через прокси в одно веб-приложение.

У всех HTTP-запросов есть заголовки, которые содержат информацию об отправившем запрос клиенте. Сюда входят сведения: IP, настройки кеша, отслеживание cookie, статус авторизации и т.д. В Nginx есть рекомендуемые настройки пересылки заголовков, которые мы включили как proxy_params, детали можно найти в /etc/nginx/proxy_params:

proxy_set_header Host $http_host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;

Цель использования обратных прокси — передать соответствующую информацию о клиенте, а иногда и информацию о самом обратном прокси. Бывают случаи, когда прокси-сервер хочет знать, какой обратный прокси-сервер обработал запрос, но обычно важная информация содержится в исходном запросе клиента. Чтобы передать эти заголовки и сделать информацию доступной в местах, где она необходима, Nginx использует директиву proxy_set_header.

Когда Nginx работает как обратный прокси-сервер, по умолчанию он изменяет два заголовка, удаляет все пустые заголовки, а затем передает запрос. У нас есть два измененных заголовка — это Host и Connection. Можете ознакомиться с подробным списком заголовков HTTP для получения дополнительной информации об их функциях (некоторые заголовки для обратных прокси мы рассмотрим дальше в этом мануале).

Пересылаемые заголовки proxy_params и переменные, в которых он хранит данные:

Host: этот заголовок содержит исходный хост, запрошенный клиентом, который является доменом сайта и портом. Nginx хранит эти данные в переменной $http_host.
X-Forwarded-For: заголовок содержит IP клиента, который отправил исходный запрос. Также в нем может быть список IP, причем первым идет исходный IP, а затем список всех IP обратных прокси-серверов, через которые прошел запрос. Nginx хранит его в переменной $proxy_add_x_forwarded_for.
X-Real-IP: всегда содержит один IP удаленного клиента. Он отличается от аналогичного X-Forwarded-For, который может содержать список адресов. Если X-Forwarded-For отсутствует, это будет то же самое, что и X-Real-IP.
X-Forwarded-Proto: содержит протокол, который исходный клиент использует для подключения (HTTP или HTTPS). Nginx хранит его в переменной $scheme.

Включите этот конфигурационный файл (Nginx считывает его при запуске). Создайте ссылку из него на каталог sites-enabled:

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

Теперь можно проверить файл конфигурации на наличие синтаксических ошибок:

sudo nginx -t

Если проблем не обнаружено, перезапустите Nginx, чтобы применить изменения:

sudo systemctl restart nginx

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

В противном случае перейдите к настройке тестового приложения и сервера с помощью Gunicorn.

3: Тестирование обратного прокси с помощью Gunicorn (опционально)

Однако, если у вас нет сервера приложений для тестирования обратного прокси-сервера, можете выполнить следующие шаги, чтобы установить Gunicorn вместе с тестовым приложением. Gunicorn — это WSGI-сервер на языке Python, который часто используется в паре с обратным прокси Nginx.

Обновите индекс репозитория apt и установите gunicorn:

sudo apt update sudo apt install gunicorn

Можно также установить Gunicorn через pip с PyPI для получения последней версии, которая может быть сопряжена с виртуальной средой Python, но apt используется здесь в качестве быстрого тестового варианта.

Далее мы напишем функцию Python для вывода HTTP-ответа “Hello World!”, который будет отображаться в браузере. Создайте test.py с помощью nano или другого текстового редактора:

Вставьте следующий код Python в файл:

def app(environ, start_response):

Это минимальный код, который нужен Gunicorn для запуска ответа HTTP, который выводит строку текста в браузере. После просмотра кода сохраните и закройте файл.

Теперь запустите сервер Gunicorn, указав test модуль Python и функцию app внутри него. Запуск сервера откроет терминал:

gunicorn --workers=2 test:app

Вывод подтверждает, что Gunicorn прослушивает адрес по умолчанию. Это адрес, который мы ранее установили для проксирования в конфигурации Nginx. Если вывод не такой, вернитесь к файлу /etc/nginx/sites-available/your_domain и отредактируйте app_server_address, связанный с директивой proxy_pass.

Откройте браузер и перейдите к домену, который настроили с помощью Nginx:

Обратный прокси-сервер Nginx теперь обслуживает сервер веб-приложений Gunicorn и выводит “Hello World!”.

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

Tags: NGINX, Ubuntu, uWSGI, uWSGI+Nginx

Virtual Hosts on nginx (CSC309)

When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com, example2.com, and example1.com/images on
the same machine using a single IP address.

How can we do that? Well, the good news is Internet browsers
send the domain name inside HTTP requests and all we need to do
is to parse the requested domain name and URL and then route the
HTTP request to the actual web server.

Oh, do I really need to parse HTTP requests? You can if you
really want to, but there are lots of tools and technologies that
readily do this for you. In this tutorial, we walk you through
how you can use nginx to proxy multiple web applications.

Install nginx

CDF @UofT

We have prepared pre-copmiled binaries for your.
You need to download nginx.tar.gz
and uncompress it:

$ wget http://www.cs.toronto.edu/~soheil/csc309/nginx.tar.gz tar -xvzf nginx.tar.gz

It creates an nginx directory for you. The config file
is in nginx/conf/nginx.conf.
We have provided a script named nginx in the directory.
To run nginx, go to the nginx directory (cd nginx) and
run ./nginx ....

Ubuntu

Install nginx using apt-get:

$ sudo apt-get install nginx

The part of the nginx‘s config file we need resides in /etc/nginx/sites-enabled/default.
To edit the config file or run nginx, you need to use sudo.

Mac OS

Install homebrew, and then install nginx using brew:

nginx‘s config file is in /usr/local/etc/nginx/nginx.conf.
To edit the config file or run nginx, you need to use sudo:
sudo nano /usr/local/etc/nginx/nginx.conf and
sudo nginx ...

Configuration

Step 1 — Booting Servers for Virtual Hosts

Write three different node applications running on different ports
(say 8080, 8181, 8282) on your machine.

Step 2 — Configure nginx’s Port

To do so, you need to edit your nginx config file.

In the config file, find the server section:

server { listen 80; ... location / { ... } ...
}

If you’re using CDF, make sure you change 80 to a vacant port number
(ask for one from your instructor). If not, you can keep using 80 or
change the port if you will.

Run ./nginx on CDF, or run sudo nginx on your local machine.
Open the browser and log on to localhost:$PORT (replace $PORT with
the port number you configured for nginx).

Step 3 — Configure /

Let say we want to configure nginx to route requests for
/, /blog, and /mail, respectively onto
localhost:8080, localhost:8181, and localhost:8282.

 +--- host --------> node.js on localhost:8080 |
users --> nginx --|--- host/blog ---> node.js on localhost:8181 | +--- host/mail ---> node.js on localhost:8282

To route /, you need to edit your nginx config file.

In the config file, find the server section:

server { listen 80; ... location / { ... } ...
}

This section is simply telling nginx how it should serve HTTP requests.

Now, change the location section to this snippet:

server { listen ...; ... location / { proxy_pass http://127.0.0.1:8080; } ...
}

proxy_pass simply tells nginx to forward requests to / to the
server listening on http://127.0.0.1:8080.

Step 4 — Reload nginx’s Configuration

To reload nginx‘s configuration run:
nginx -s reload on your machine.

Referesh your browser. Do you see the output from your node.js application?
If yes, you are all set. If no, there is a problem with your config.

Step 5 — Add /blog and /mail

To redirect /mail and /blog, you simply need to add new entries
the location section in the config file:

server { listen ...; ... location / { proxy_pass http://127.0.0.1:8080; } location /blog { proxy_pass http://127.0.0.1:8181; } location /mail { proxy_pass http://127.0.0.1:8282; } ...
}

Step 6 — Reload Your nginx Configuration

Run nginx -s reload on your machine.

Log onto localhost:$PORT/blog in your browser.
Do you see the output from your second node.js application?

Then log onto localhost:$PORT/mail.
Do you see the output from your third node.js application?

If yes & yes, you are all set. If no, there is a problem with your config.

Step 7 — Rewriting Requests

Now as you might have noticed in Step 6, nginx sends the same
HTTP request to your node.js web apps which results into a 404 error.
Why? Because, your node.js web application serves requests from /
not from /blog and /mail. But, nginx is sending requests to /blog and
/mail.

To fix this issue, we need rewrite the URL so that it matches the URL
you can serve on your node.js applications.

server { listen ...; ... location / { proxy_pass http://127.0.0.1:8080; } location /blog { rewrite ^/blog(.*) /$1 break; proxy_pass http://127.0.0.1:8181; } location /mail { rewrite ^/mail(.*) /$1 break; proxy_pass http://127.0.0.1:8282; } ...
}

This rewrite commands are simple regular expressions that transform
strings like /blogWHAT_EVER and /mailWHAT_EVER to /WHAT_EVER
in the HTTP requests.

Step 8 — Reload and Test.

Exercise 1

Configure your nginx to redirect URLs from /google to http://www.google.com

Step 9 (optional) — Redirecting Based on Host Name

Let say you want to host example1.com, example2.com, and example3.com
on your machine, respectively to localhost:8080, localhost:8181, and
localhost:8282.

Note: Since you don’t have access to a DNS server, you should
add domain name entries to your /etc/hosts (you can’t do this on CDF machines):

...
127.0.0.1 example1.com example2.com example3.com
...

server { listen 80; server_name example1.com; location / { proxy_pass http://127.0.0.1:8080; }
}
server { listen 80; server_name example2.com; location / { proxy_pass http://127.0.0.1:8181; }
}
server { listen 80; server_name example3.com; location / { proxy_pass http://127.0.0.1:8282; }
}

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

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

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

Схема работы Nginx - Reverse Proxy — 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, а также указанную страницу.

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

$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 содержит список прокси серверов по которым прошёлся клиент перед этим сервером, а переменная $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:

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

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

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

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

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

# service nginx restart

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

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

Как видим мы перешли на второй сервер. Теперь включим обратно 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 data-hren="/test/test/test.html">test</a></p> </body>
</html>

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

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

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

Теперь проверим работу на 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 ещё раз:

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

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

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

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

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

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

Итог

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

Nginx. Reverse Proxy

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

Вступление

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

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

Общая информация о прокси

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

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

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

Прокси в Nginx осуществляется путем манипулирования запросом, направленным на сервер Nginx, и передачи его на другие серверы для фактической обработки. Результат запроса передается обратно в Nginx, который затем передает информацию клиенту. Другими серверами в этом экземпляре могут быть удаленные машины, локальные серверы или даже другие виртуальные серверы, определенные в Nginx. Серверы, на которые прокси-серверы Nginx отправляют запросы, известны какupstream servers.

Nginx может прокси-запросы к серверам, которые обмениваются данными с использованием протоколов http (s), FastCGI, SCGI и uwsgi или memcached через отдельные наборы директив для каждого типа прокси. В этом руководстве мы сосредоточимся на протоколе http. Экземпляр Nginx отвечает за передачу запроса и массирование любых компонентов сообщения в формате, понятном для вышестоящего сервера.