Proxy pass что означает

С самой простой реализацией Nginx proxy_pass, приведенной выше, запускаются проекты на NodeJS и фреймоворке Express. Изначально они стартуют на localhost и порту 3000

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

Здесь в закомментирвоанном виде представлены директивы для перенаправления запросов на порт 9000 к сервису php-fpm.

Читайте о том что делать если на сервере с конфигурацией с proxy_pass стала возникать ошибка с кодом 502.

Основы работы с Nginx: проксирование, балансировка нагрузки, буферизация и кэширование

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

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

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

Одной из причин использовать проксирование 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 context
location /match/here proxy_pass http://example.com;
>
. . .

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

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

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

# server context
location /match/here proxy_pass http://example.com/new/prefix;
>
. . .

В приведенном выше примере прокси-сервер определяется вместе с сегментом 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 соединение будет постоянным.

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

Также следует убедиться, что в нестандартных заголовках нет подчеркиваний, что если ваше бэкэнд-приложение будет обрабатывать такие заголовки. Если вам нужны заголовки, в которых используется символ подчеркивания, вы можете установить директиве underscores_in_headers значение on (это валидно либо в контексте http, либо в контексте объявления server по умолчанию для комбинации IP-адреса/порта). Если вы этого не сделаете, Nginx пометит эти заголовки как некорректные и просто сбросит их, прежде чем перейти к upstream серверу.

Заголовок Host имеет особое значение в большинстве прокси-сценариев. Как указано выше, по умолчанию этот заголовок получит значение переменной $proxy_host, которая содержит домен или IP-адрес и порт, взятые непосредственно из определения proxy_pass. Это поведение определяется по умолчанию, так как это единственный адрес, на который точно отвечает upstream сервер Nginx.

Заголовок 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 и добавить дополнительные заголовки, нужно использовать что-то вроде этого:

# server context
location /match/here proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://example.com/new/prefix;
>
. . .

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

X-Real-IP указывает IP-адрес клиента, чтобы прокси-сервер мог правильно принимать решения или вести лог на основе этой информации. Заголовок X-Forwarded-For – это список, содержащий IP-адрес каждого сервера, по которому проходил запрос. В приведенном выше примере устанавливается значение переменной $proxy_add_x_forwarded_for. Эта переменная принимает значение исходного X-Forwarded-Forheader, извлеченного из клиента, и добавляет IP-адрес сервера Nginx в конец.

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

# server context
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location /match/here proxy_pass http://example.com/new/prefix;
>
location /different/match proxy_pass http://example.com;
>

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

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

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

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

# http context
upstream backend_hosts server host1.example.com;
server host2.example.com;
server host3.example.com;
>
server listen 80;
server_name example.com;
location /proxy-me proxy_pass http:// backend_hosts ;
>
>

В приведенном выше примере был создан контекст upstream под названием backend_hosts. После определения это имя будет доступно в proxy pass как обычный домен. Как вы можете видеть, в блоке server все запросы, сделанные в example.com/proxy-me/…, передаются в пул, который вы определили выше. В этом пуле хост выбирается с помощью настраиваемого алгоритма. По умолчанию это простой процесс round-robin (каждый запрос будет поочередно маршрутизироваться на другой хост).

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

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

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

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

# http context
upstream backend_hosts least_conn;
server host1.example.com;
server host2.example.com;
server host3.example.com;
>
. . .

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

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

# http context
upstream backend_hosts hash $remote_addr$remote_port consistent;
server host1.example.com;
server host2.example.com;
server host3.example.com;
>
. . .

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

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

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

# http context
upstream backend_hosts server host1.example.com weight=3;
server host2.example.com;
server host3.example.com;
>
. . .

Теперь 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.

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

# server context
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
location / proxy_pass http://example.com;
>

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

# server context
proxy_buffering off;
proxy_buffer_size 4k;
location / proxy_pass http://example.com;
>

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

Проксирование 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 для бекэнд серверов:

# server context
location /proxy-me proxy_cache backcache;
proxy_cache_bypass $http_cache_control;
add_header X-Proxy-Cache $upstream_cache_status;
proxy_pass http://backend;
>
. . .

Используя директиву proxy_cache, можно указать, что для этого контекста следует использовать зону кэширования backcache. Nginx проверит запись перед тем, как перейти к серверу.

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

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

Рекомендации по кэшированию результатов

Кеширование увеличивает скорость прокси-сервера. Но не стоит забывать о нескольких нюансах.

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

Если на сайте есть динамические элементы, им следует уделить внимание. Решение этой проблемы зависит от бекэнд-сервера. Для личных данных используется заголовок Cache-Control со значением no-cache, no-store или private.

• no-cache: ответ не будет отправлен, пока сервер не проверит данные на бекэнд-сервере. Это значение используется с динамическими данными. Хэшированные метаданные заголовка Etag проверяются при каждом запросе. Если бекэнд вернет теже значения, то данные отправляются из кэша клиенту.
• no-store: данные не должны храниться в кэше ни при каких обстоятельствах. Это самый безопасный подход при работе с личными данными.
• private: данные не должны кэшироваться в общем кэше. То есть, к примеру, браузер пользователя может кешировать данные, а прокси-сервер нет.
• public: данные можно кэшировать везде.

Есть связанный с этим поведением заголовок max-age, который определяет срок хранения кэша в секундах.

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

Если вы используете nginx и на бэкэнде, добавьте директиву expires, которая определяет значение max-age заголовка Cache-Control:

location / expires 60m;
>
location /check-me expires -1;
>

Первый блок поддерживает кэш в течение часа. Второй блок присваивает заголовку Cache-Control значение no-cache. Для внесения других изменений примените директиву add_header:

location /private expires -1;
add_header Cache-Control «no-store»;
>

Nginx proxy_pass: как настроить модуль?

Nginx proxy manager — инструмент, который поможет создать веб-сервер. Технология применяется на многих нагруженных ресурсах, таких как Instagram, мессенджеры и социальные сети. Также его применяют, как reverse tcp proxy, который распределяет нагрузку между веб-сервисами. Предоставляет возможность установить SSL-сертификаты для кэширования и соединения, для увеличения производительности. Главная задача web reverse proxy – обслуживание графического контента, например, HTML или изображений. Каждый сервер имеет порт, который побуждает принимать запросы именно от него. Применяться может для кэширования заголовков, обустройства инвертированного прокси-сервера и для других масштабных задач.

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

Отличие engine x от обычного server

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

Как еще используют nginx proxy manager

При помощи engine x возможно настроить проксирование запросов, поступающих на удаленный server, используя директиву proxy_pass.

Как работает ngx_http_proxy_module простыми словами

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

Пример

Опишем на примере, каким образом работает проксирование:

1. Применяют для настройки чат-серверов matrix и mattermost на виртуальном сервере. Запросы проксируются на server при помощи nginx, принимающего входящие соединения.
2. Допустим, у вас есть большой server с контейнерами, например, докера. На нем работает множество различных сервисов. Вы устанавливаете еще один контейнер с чистым engine x, на нем настраиваете проксирование запросов на эти контейнеры. Сами контейнеры имеют доступ только к локальному интерфейсу сервера. Таким образом, они будут полностью закрыты извне, и при этом вы можете гибко управлять доступом.
3. При наличии server с гипервизором, на виртуальной машине создается шлюз и локальная сетка, состоящая из виртуальных машин, недоступная извне. В данной локальной сети шлюз настраивается по умолчанию, и представляет собой виртуальную машину. На серверах сети можно разместить сервисы, при этом настройку файервола не осуществлять. Доступ к servers проксируется через nginx, которые подключены к отдельной виртуальной машине с настроенными портами.
4. Организация доступа к synology. Для этого нужно получить бесплатный сертификат Let’s encrypt, настроить проксирование через текущий IP, а затем через шлюз перебросить их внутрь локальной сети. При помощи фаервола возможно ограничить доступ к server через IP, при помощи которого работает engine x. На synology никаких настроек осуществлять не нужно.
5. Если пользователь или компания разворачивает большой проект, который разделен на составляющие, размещенные на отдельных серверах. Например, отдельно находится форум и проксирование возможно перенести на отдельный сервер. При этом возможна реализация location с переадресацией.

Вариантов применения engine x – много. Рассмотрим плюсы настройки для описанных выше кейсов.

Плюсы настройки engine x

• Быстрая настройка https доступа к сервисам, которая не будет изменять и затрагивать эти сервисы. То есть, пользователь, настраивая engine x, обеспечивает передачу данных от сервера к службам через http.
• Адреса проксируемых запросов легко изменять. Например, при подготовке сайта к nginx rewrite, пользователь настраивает все на сервере, на котором проксируются запросы. Произведите изменение url сайта в engine x прокси на новый и примените настройки. Откатить изменения возможно также быстро и легко.

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

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

Настройка proxy_pass в engine x

Попробуем объяснить настройку на реальном примере. Технический домен blog.1111.ru. В DNS создаем запись, которая приводит запрос на сервер, с установленным nginx_srv. Проксируем запросы с сервера на blog_srv, с реальным сайтом. Конфигурация:

error_log /var/log/nginx/blog.1111.ru -error.log;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Real-IP $remote_addr;

Открываем http:// blog.1111.ru. Попасть мы должны на blog_srv, на котором работает server. Представим, что он тоже на engine x. Содержимое должно быть идентично информации с http://192.168.13.31 (локалка). Логи серверов показывают, что запрос был направлен на nginx_srv, а затем произошел редирект на nginx_srv.

Реальный IP виден только в конце лога, поэтому REMOTE_ADDR не сможет вернуть настоящий IP. Но это можно исправить.

Создаем тестовую страницу chat_srv, при помощи которой будет возможно проверить IP клиента.

Даем ей название, например, myip.php.

Заходим на http:// blog.1111.ru/myip.php и смотрим, определяет ли server адрес. Т.к. мы не внесли исправления, то определяется nginx_srv, а не реальный адрес клиента.

Как передать IP клиента в nginx (обратный) при proxy_pass

На принимающей стороне производим обратную замену прокси. Через:

В итоге получаем:

listen 80 default_server;

index index.php index.html index.htm;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

error_page 404 /404.html;

error_page 500 502 503 504 /50x.html;

Сохраняем изменения и перепроверяем http:// blog.1111.ru/myip.php. Должен отобразиться реальный IP клиента.

Сохраняем конфиг, перечитываем его и снова проверяем Вы должны увидеть свой реальный ip адрес. Его же вы увидите в логе на blog_srv.

Вопросы от пользователей по engine x

Применяя https через proxy_pass нужно ли производить настройку https бэкенда?

Не обязательно, но возможно у вас есть программное обеспечение, которое не может функционировать в таком формате. Вы получите ссылку http://site.ru:443. Тогда придется осуществить настройку обмена данными между engine x и бэкендом.

Есть ли простой способ передачи let’s encrypt с engine x на backend? (Обновление и генерация осуществляются на engine x).

Есть два способа реализации. На nginx настраивается nfs сервер и уже затем, на бэкенде можно привязать директорию /etc/letsencrypt. Это позволит использовать сертификаты таким образом, будто они находятся на локальной директории.

Вариант два – использование bash-скрипта. Он будет копировать сертификаты через scp.

На бэкенде службы нужно постоянно перезапускать, после обновления сертификата.

Когда бэкенд обращается к адресу сайта, то запрос передается на nginx reverse proxy, потому что в ДНС указан его IP. Возникает проблема с отработкой скриптов и проверкой движка.

Чтобы ответ возвращался правильно, нужно поправить host /etc/hosts на бэкенде, прописав статические данные об имени сайта и локальным IP. Соответственно, запрос будет приходить не с nginx proxy cache от server, а локально.

Nginx или haproxy выбрать для проксирования?

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

Добавляет ли engine x в режиме proxy_pass дополнительные сетевые задержки?

Да, но connect timeout мал, особенно если nginx proxy manager и сервер принадлежат одной и той же локальной сети. В общем, можно пренебречь задержками. При проксировании через интернет – следите за величиной задержки. Желательно, чтобы servers располагались как можно ближе друг к другу.

Заключение

Самая распространенная задача – проксирование внешних запросов в закрытую сеть. Если закрытая сеть не открыта для постороннего доступа, то нет необходимости в https при передаче информации на бэкенд.

Надеемся, что статья была полезной и интересной! Следите за обновлениями в нашем блоге.

Что такое прокси-сервер и как его настроить

Разбираемся, что такое прокси-сервер и какие его классификации существуют.

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

Как работает прокси-сервер

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

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

Термины «прокси-сервер» и «IP-адрес прокси» имеют разное значение, хотя они часто используются как взаимозаменяемые.

Прокси-сервер — это машина, которая содержит прокси IP-адреса.

IP-адрес прокси — это индивидуальный IP-адрес, который используется для сокрытия вашего реального «айпишника».

Прокси-сервер обрабатывает ваши запросы, но скрывает множество идентифицирующей информации: в ее числе исходный IP-адрес, геолокация, откуда пришел запрос, данные операционной системы (ОС) и многое другое. В общем, он помогает предотвратить легкое отслеживание вас третьими лицами, или так называемое «вычисление по IP». Работа прокси-сервера осуществляется на уровне приложений модели OSI (L7).

Типы прокси-серверов

На данный момент существует множество типов прокси-серверов. Выделим основные.

Публичный прокси

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

Приватный прокси

Такие прокси более быстры и безопасны, чем предыдущие. Компании, предоставляющие частные прокси, могут предлагать и другие функции, услуги, такие как WAF (web application firewall), VPN и прочие, а также техподдержку клиентов. Частный прокси может быть выделенным и общим.

Выделенный прокси

Такой вид предоставляется через высокопроизводительные серверы с выделенными ресурсами. Эти прокси позволяют подключаться и отправлять запросы только одному клиенту, решая проблему «шумных соседей» или черного списка. Последнее актуально для бесплатных прокси, когда один из ранее использовавших его пользователей допустил попадание IP-адреса в блок-лист сайта.

Прозрачный прокси

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

Есть и более специфические разновидности прокси.

HTTP-прокси

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

Прокси с использованием SSL

При использовании SSL-прокси создается только одно TCP-соединение. Это отличает его от HTTP-прокси, который создает два соединения: одно от клиента к прокси, другое от прокси к веб-серверу.

Когда пользователь инициирует веб-запрос, он посылает запрос CONNECT на веб-сервер и создает TCP-канал, по которому проходит запрос. Одним из преимуществ SSL-прокси перед HTTP-прокси является то, что их можно использовать для доступа к ресурсам как HTTPS-, так и HTTP-серверов. Этого нельзя сделать с HTTP-прокси, который можно использовать только для доступа к ресурсам HTTP-сайтов. Если пользователь попытается получить доступ к HTTPS-сайту с помощью HTTP-прокси, соединение с сайтом не будет считаться безопасным.

CGI-прокси

Прокси Common Gateway Interface (CGI) извлекает веб-контент из интернета от имени клиента. CGI-прокси используется через веб-браузер и выглядит как обычный веб-сайт. Чтобы воспользоваться им, достаточно ввести URL-адрес назначения, и CGI отобразит результаты, как если бы он был отправителем запроса. CGI-прокси работает через зашифрованную веб-форму, встроенную в другую веб-страницу с использованием SSL. CGI-прокси используются для анонимного просмотра веб-страниц и разблокировки сайтов с региональными ограничениями.

SOCKS-прокси (SOCKets Secure)

SOCKS — это еще один интернет-протокол. Он расшифровывается как SOCKet Secure и обычно используется для задач с интенсивным трафиком, таких как потоковая передача контента или обмен P2P.

SOCKS использует соединение TCP, которое предназначено для отправки и получения пакетов данных через интернет, а также для гарантии успешной доставки ресурсов по сети. При использовании SOCKS-прокси интернет-трафик направляется через прокси-сервер по TCP-соединению от имени клиента. Как и большинство других типов прокси, SOCKS скрывают IP-адрес клиента и работают в обход географических ограничений.

Для чего нужен прокси сервер

Ответим на вопрос, зачем нужен прокси. Помимо анонимизации в интернете, с помощью прокси-серверов решаются следующие задачи:

• Фильтрация доступных ресурсов. Эта опция позволяет отсечь доступ к некоторым ресурсам — например, закрыть сотрудникам доступ к соцсетям в рабочее время. При такой работе часть запросов отбрасывается и не транслируется. Также в сочетании с SWG (Secure Web Gateway), который может включать в себя, например, антивирусы, программы для обеспечения безопасности электронной почты, прокси-сервер может обеспечить дополнительную защиту ИБ.
• Ускорение работы интернета. Загрузка сайтов может производиться при помощи кэша на прокси-сервере. Кэширование и сжатие данных — эта технологическая возможность прокси-сервера схожа с режимом «Турбо» в браузерах. При ее работе загрузка ресурсов с сайта производится не напрямую на компьютер пользователя, а сначала на сервер, где она сжимается. После в уменьшенном объеме ресурсы передаются пользователю. Функция будет полезна, если вы используете тариф с ограничением трафика или при медленном соединении.
• Безопасность. При помощи прокси-сервера есть возможность настроить блокировку запросов с потенциально вредоносных сайтов.
• SEO-мониторинг. SEO-прокси используются для обхода фильтров и ограничений, наложенных поисковыми системами.
• Доступ к запрещенному контенту. Обход блокировок на государственном уровне. Иногда сайты блокируют доступ по geoIP — такие блокировки также помогает обойти proxy-сервер.

Proxy или VPN?

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

Во-первых, они работают на разных уровнях модели OSI — это существенное различие между proxy-сервером и VPN.

Популярные протоколы VPN, такие как PPTP, L2TPv3 и IPsec, работают на уровне 3 (сетевой уровень). Конечно, VPN использует уровень 4 для установления связи. Например, PPTP использует TCP (уровень 4), а L2TP и IPsec используют TCP и UDP (уровень 4) для создания туннеля. Но, как только туннель VPN создан, его протоколы работают так же, как сетевые интерфейсы. Работа на L3 означает, что VPN принимает весь ваш трафик (DNS, HTTP, P2P, VoIP и т.д.), независимо от номера порта или приложения, и шифрует его. Прокси же работает на 5-7 уровне.

Во-вторых, в их основе лежат разные технологии, обеспечивающие безопасность соединения.

Уровень конфиденциальности в VPN зависит от криптографической мощности механизма шифрования. Существуют различные алгоритмы шифрования — 3DES, AES и RSA. Они определяют, как данные скрываются в сообщении. Эти механизмы используют набор ключей и шифров (128 или 256 бит) для сокрытия информации и находят применение в различных протоколах безопасности. Примерами протоколов шифрования VPN являются PPTP, L2TP, SSTP, IKEv2, OpenVPN, IPSec, WireGuard и другие.

Прокси-серверы, с другой стороны, не предназначены для шифрования данных. По своей концепции прокси-серверы маскируют ваш IP-адрес своим, но не шифруют данные. Для компенсации отсутствия шифрования можно использовать прокси-серверы с SSL, но этот обходной путь требует технических знаний. У прокси-серверов нет накладных расходов на шифрование, поэтому они обычно быстрее VPN. Хотя серфинг интернета с VPN едва ли повлияет на ваш пользовательский опыт. Задержки касаются трафика с самой высокой нагрузкой, такого как потоковое видео, передача файлов P2P или игры.

Наконец, отличается стоимость реализации VPN и прокси.

Найти дешевые VPN для общих ресурсов и даже бесплатные (в некоторых случаях) можно, но цена на VPN для бизнеса может увеличиваться в долгосрочной перспективе. Поддержка VPN для крупного предприятия потребует большей инфраструктуры, поддержки, обслуживания и мониторинга. Локальный прокси-сервер, как правило, обходится более дешево для компаний, однако сложно представить компанию, которая пользуется ими в чистом виде.

Риски использования прокси

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

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

Как и где выбрать сервер

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

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

Десятки готовых конфигураций со скидкой

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

Подключение к прокси-серверу: инструкции

Настройка для операционных систем

Первым шагом мы рассмотрим настройку прокси на ОС Windows, Linux и Mac.

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

Для настройки на Windows вам потребуется зайти в поиск и написать Прокси либо перейти в Параметры → Сеть и интернет → Прокси-сервер.

Для Linux

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

Стоит учитывать, что задать логин и пароль для подключения так просто не получится. Для этого следует выполнить следующие шаги:

• Открыть для редактирования файл /etc/environment, введя команду sudo nano /etc/environment.
• Перейти в конец файла и добавить строки типа:

Название протокола_proxy=”Название протокола://user:pass@proxy:port/”.

• Перезагрузить систему.

Для MacOS

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

После этого перейти в пункт Дополнения и нажать кнопку Изменить настройки.

Можно также перейти в окно настройки прокси другим способом. Нажмите на значок Wi-Fi или интернета и выберите Настройки → Wi-Fi.

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

Настройка сервера прокси в браузере

Для настройки прокси в браузере механизм будет схожим. Например, для браузера Google Chrome будет достаточно зайти в настройки и написать в строке поиска Прокси, выбрать пункт открыть настройки прокси сервера для компьютера После этого браузер переадресует вас в настройки прокси-сервера Windows или другой операционной системы.

Для браузер Mozilla Firefox следует также перейти в настройки и в строке поиска написать Настройки сети. После выбора этого пункта вам станут доступны настройки соединения.

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

Аналогичный процесс и для браузера Microsoft Edge:

Настройка прокси-сервера для телефонов или планшетов на Android и iOS

Для настройки прокси-сервера в ОС Android и iOS перейдите в меню настроек. Далее выберите подключения: для Android раздел может называться по-разному, в зависимости от оболочки, на IOS это Wi-Fi. Затем зайдите в настройки сети и включите ручную настройку прокси.

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

Заключение

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

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