Проксирование сайта что это
Как защитить сайт от проксирования
С каждым днем поисковые системы все более привередливы к качеству сайтов. Вебмастерам приходится немало трудиться, чтоб создать качественный контент, и, впоследствии, получить долю трафика в своей нише. И вот, вроде бы, все делаешь правильно, а трафик начинает падать без весомых на то причин. Когда узнаешь о проксировании, сразу же приходит ступор. В голове крутятся десятки вопросов, а поисковые системы вместо защиты от проксирования, в один голос учат как проксировать сайты.
Что такое проксирование сайтов?
Это дыра в современном сайтостроении, которая позволяет злоумышленникам поживиться за счет других вебмастеров без каких либо вложений.
Как будто в зеркалах, в сети появляются копии ваших сайтов, о которых, возможно, вы даже не подозреваете. Большое количество копий засоряет базы данных поисковых систем и приводит к появлению дубликатов в результатах поиска.
Зачем проксируют сайты?
Как проксирование вредит сайту?
Если не принять срочные меры, с огромной долей вероятности, сайты-прокси по многим запросам встают выше своих доноров, забирая тем самым ваш золотой трафик и ваши деньги. В поиске будет появляться множество страниц с дублированным контентом с вашего сайта. Поисковые системы будут думать, что вы наделали копии своего сайта для недобросовестных целей, за что могут наложить фильтр или, что еще хуже, удалить из поиска, оставив вместо вас клонированный сайт.
Как узнать, что сайт клонировали?
Можно придумать множество способов и вариантов, как найти проксирующие сайты, но самые простые и быстрые мы опишем ниже:
1. Берем самые популярные урлы сайта и вставляем в строку поиска поисковых систем. Чаще всего эти ссылки уже проиндексированы и на сайте-паразите, что позволит вам его найти. Чтобы не просматривать сотни страниц с результатами, мы рекомендуем добавлять перед поиском параметр inurl:
например, для google inurl:/category/3344/flowers
2. Сервисы для проверки текстов на уникальность и плагиат, чаще всего, так же смогут определить сайты-клоны. Для проверки необходимо найти на вашем сайте длинный текст либо просто вписать название и описание вашего сайта без доменного имени, так как он, чаще всего, меняется автоматически либо удаляется (Учитывайте, что есть даже случаи клонирования сайта с заменой всех текстов на другой язык).
3. Google Search Console (Google Webmaster Tools) показывает ссылки на ваш сайт. Если ваши сайты перелинкованные между собой, тогда на него появится +1 ссылка с клонированного сайта;
4. Способ для тех, кто владеет администрированием или же в списке друзей или сотрудников такой имеется. Требуется детальный анализ с агрегацией логов всех используемых подсистем на наличие аномальной активности с учетом абсолютно всей доступной информации (например запрошенный URL, IP адрес запрашивающего, user-agent, cookies и много всего остального). В ручном режиме такой анализ возможно сделать, но “враг” не спит, и поэтому результаты анализа актуальны в довольно небольшом промежутке времени. Кроме того, анализ занимает много времени и ресурсов, как человеческих так вычислительных, и даже при наличии хорошего опыта в программировании и администрировании, вам будет необходимо постоянно следить и добавлять все новые и новые правила, для предотвращения клонирования вашего сайта.
Как обезвредить копии сайта?
Рассмотрим, например, такой запрос:
В данном случае нам очень интересна комбинация IP адреса запрашивающего (2е поле) и user-agent (последнее поле). Может показаться, что этот запрос приходит от гуглбота, но ознакомившись с документацией Google https://support.google.com/webmasters/answer/80553?hl=ru и выполнив нехитрую проверку.
Проксирование сайтов: когда это во благо, а когда – во вред
Проксирование сайтов – технология, которая может использоваться, как для благих намерений, так и в не совсем хороших целях. Давайте рассмотрим оба варианта. Понять, «что почем», нам помогут специалисты компании HostiServer.com – крупного провайдера, оказывающего в том числе и услуги проксирования (а также защиты от него).
Когда вам может это понадобиться
Самый яркий пример использования этой технологии во благо – обеспечение стабильной работы сайта в условиях, когда сервер, на котором он размещается, не в состоянии справиться с нагрузками (например, резкий рост трафика при минимальном тарифе, или еще хуже – атака злоумышленников). В этом случае приходит на помощь проксирование. Оно помогает справиться с возникающими проблемами и «лить трафик» на веб-ресурс через сторонний источник.
Еще один вариант использования технологии – обход блокировок. Она позволяет быстро создать полнофункциональное рабочее зеркало сайта. При этом вы можете сменить IP и даже доменное имя, быстро «переехав» на новый сервер.
Иногда проксирующие сайты создаются при заключении партнерских отношений по привлечению клиентов. Т.е. вы заказываете у кого-то услуги по привлечению покупателей в интернет-магазин, а он берет и полностью воспроизводит ваш веб-ресурс на своем сервере.
А теперь о вреде проксирования
Активно используют эту технологию и злоумышленники. Ну кто не хочет заработать на чужом узнаваемом сайте хорошего качества? Вот и прибегают к проксированию, чтобы создавать полные клоны.
Еще один вариант применения технологии – недобросовестная конкуренция. Всем известно, что дубли и полностью идентичный контент не идут веб-ресурсам на пользу. Это может негативно повлиять на продвижение и ранжирование сайта, который копируется, в поисковых системах. И тогда бюджет, потраченный на продвижение, уйдет впустую.
Проксируем и спасаем
ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов. Для одних это важнейшая политическая тема, для других повод изучить технологии шифрования и защиты анонимности, для третьих просто очередной странный закон, который приходится исполнять на бегу. Мы же поговорим о технологическом аспекте.
В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить IP и назначить любое доменное имя. Мы даже попробуем спрятать домен в url, после чего можно сохранить локально полную копию сайта. Все упражнения можно сделать на любом виртуальном сервере — лично я использую хостинг Хетцнер и OS Debian. И конечно мы будем использовать лучший веб-сервер всех времен и народов — NGINX!
К этому абзацу пытливый читатель уже приобрел и настроил какой нибудь выделенный сервер или просто запустил Linux на старом компьютере под столом, а так же запустил Nginx последней версии со страничкой «Save me now».
Перед началом работы необходимо скомпилировать nginx c модулем ngx_http_substitutions_filter_module, прежнее название — substitutions4nginx.
Дальнейшая конфигурация будет показана на примере сайта www.6pm.com. Это сайт популярного онлайн магазина, торгующего товарами с хорошими скидками. Он отличается категорическим нежеланием давать доступ покупателям из России. Ну чем не оскал цензуры капитализма?
У нас уже есть работающий Nginx, который занимается полезными делом — крутит сайт на системе Livestreet о преимуществах зарубежного шоппинга. Чтобы поднять зеркало 6pm прописываем DNS запись с именем 6pm.pokupki-usa.ru который адресует на IP сервера. Как вы понимаете, выбор имени для суб-домена совершенно произволен. Это имя будет устанавливаться в поле HOST при каждом обращении к нашему новому ресурсу, благодаря чему на Nginx можно будет запустить виртуальный хостинг.
В корневой секции конфигурации nginx прописываем upstream — имя сайта-донора, так будем его называть в дальнейшем. В стандартных гайдах сайт обычно называется back-end, а reverse-proxy называется front-end.
Дальше нужно создать секцию server, вот как она выглядит
Стандартные директивы listen и server определяют имя виртуального хоста, при обращении к которому будет срабатывать секция server. Файлы логов лучше сделать отдельными.
$uri — переменная nginx, которая содержит путь из HTTP запроса
Префикс “@” задаёт именованный location. Такой location не используется при обычной обработке запросов, а предназначен только для перенаправления в него запросов. Такие location’ы не могут быть вложенными и не могут содержать вложенные location’ы
В нашем случае конструкция используется только для подмены файла robots.txt, чтобы запретить индексацию содержимого сайта. Однако таким образом делается зеркалирование и кеширование в nginx.
include ‘6pm.conf’ — логика модуля substitutions.
proxy_cookie_domain — новая функция, которая появилась в nginx версии 1.1.15, без этой директивы приходилось делать так. Больше не нужно ломать голову, прописываете одну строчку и куки просто начинают работать.
proxy_set_header Accept-Encoding «»; — очень важная команда, которая заставляет сайт донор отдавать вам контент не в сжатом виде, иначе модуль substitutions не сможет выполнить замены.
proxy_set_header Host — еще одна важная команда, которая в запросе к сайту донору выставляет правильное поле HOST. Без нее будет подставляться имя нашего прокси сервера и запрос будет ошибочным.
proxy_pass — прямая адресация не работает в именованном локейшине, именно поэтому мы прописали адрес сайта донора в директиве upstream.
proxy_redirect — многие сайты используют редиректы для своих нужд, каждый редирект нужно отловить и перехватить здесь, иначе запрос и клиент уйдет за пределы нашего уютного доменчика.
Теперь посмотрим содержимое 6pm.conf. Я не случайно вынес логику трансформации в отдельный файл. В нем можно разместить без какой либо потери производительности тысячи правил замены и сотни килобайт фильтров. В нашем случае мы хотим лишь завершить процесс проксирования, поэтому файл содержит всего 5 строк:
Меняем коды google analytics:
Уверяю, что это самая безобидная шалость из возможных. У нас появится статистика посещений, а у сайта донора эти визиты — исчезнут.
Меняем все прямые ссылки на новые.
Как правило, в нормальных сайтах все картинки лежат на CDN сетях, которые не утруждают себя проверкой источника запросов, поэтому достаточно замены ссылок только основного домена. В нашем случае 6pm выпендрился и разместил часть картинок на доменах, которые отказывают посетителям из России. К счастью, модуль замены поддерживает регулярные выражения и не составляет никакого труда написать общее правило для группы ссылок. В нашем случае обошлось даже без regexp, просто поменяли два символа в домене. Получилось так:
Единственное, но очень серьезное ограничение модуля замены — он работает только с одной строкой. Это ограничение заложено архитектурно, поскольку модуль работает на этапе, когда страница загружена частично (chunked transfer encoding) и нет никакой возможности выполнить полнотекстовый regexp.
Все, можно посмотреть на результат, все работает, даже оплата заказа проходит без затруднений.
С п.1 все просто — мы заменяем все ссылки на новый путь с поддиректорией
С п.3 так же просто — мы ничего не трогаем и все работает само если не использовался атрибут base href. Если этот атрибут используется, что бывает крайне редко в современных сайтах, то достаточно его заменить и все будет работать.
Теоретически можно написать достаточно общий универсальный regexp, который сумеет выбрать исключительно нужные паттерны для замены, на практике гораздо проще написать несколько простых regexpов, которые будут по частям переводить нужные ссылки.
Вернемся к нашему пациенту:
Конфигурация сервера претерпела некоторые изменения.
Во-первых, вся логика перенесена из директивы sever напрямую в location. Нетрудно догадаться, что мы решили создать директорию /6pm в которую будем выводить проксируемый сайт.
proxy_cookie_path / /6pm/ — переносим куки из корня сайта в поддиректорию. Это делать не обязательно, но в случае если проксируемых сайтов окажется много, их куки могут пересечься и затереть друг друга.
rewrite ^/6pm/(.*) /$1 break; — эта магия вырезает из клиентского запроса поддиректорию, которую мы добавили, в результате директива proxy_pass отправляет на сервер-донор корректное значение.
Чуть сложнее стало ловить редиректы. Теперь все ссылки на корень нужно перебросить на /6pm.
Посмотрим на логику трансформации:
Во-первых, мы включили фильтрацию файлов css и javascript (парсинг html включен по-умолчанию)
Во-вторых, начинаем аккуратно находить и заменять разные типы ссылок относительно корня. Нам попался средней сложности сайт, в котором часть скриптов содержат такие пути.
К сожалению, мне не удалось до конца написать фильтр для случая поддиректории. Я не дошел до преобразования динамических запросов скриптов корзины с покупками, хотя не сомневаюсь что это решаемо. Просто моих знаний в Javascript не достаточно чтобы выполнить необходимую отладку, буду рад советам как запустить корзину покупок, которая сейчас в упомянутом примере не работает.
В любом случае, это, возможно, первый гайд, в котором описан метод проксирования в поддиректорию.
Прокси: что это, зачем нужен и как работает
Периодически пользователям приходится думать, как попасть на заблокированный интернет-ресурс. Например, в апреле 2018 года на территории России власти ограничили доступ к мессенджеру Telegram, а блокировку сняли только в июне 2020-го. Использование прокси стало одним из способов попасть в мессенджер, запрещенный в нашей стране более двух лет. Расскажем подробнее о том, что такое прокси, как это работает и с какой целью им пользуются.
Что такое прокси-сервер и для чего он нужен
Прокси (англ. proxy — заместитель, доверенное лицо) — это часть интернет-соединения, объединяющая устройство, с которого пользователь выходит в интернет, и сервер ресурса. Задача этого удаленного компьютера-посредника — принять и передать запросы пользователя, которому необходимо выйти в интернет, но не нужно, чтобы его компьютер напрямую соединялся с интересующим сайтом.
Прокси-сервер решает разные задачи:
Всем бы хорош прокси, но стоит помнить, что:
VPN или прокси: в чем различие
Казалось бы: и прокси, и VPN скрывают IP-адрес. Одно и то же? Но нет, это разные технологии.
Прокси — это сервер, который от своего имени выполняет пользовательский запрос. Как правило, прокси-серверы могут работать лишь по одному протоколу. Исключением являются HTTPS-прокси: у них есть возможность туннелирования любого TCP-соединения, а также SOCKS5-прокси с их возможностью передачи любых TCP- и UDP-пакетов.
Протокол TCP (Transmission Control Protocol) — сетевой протокол, который до начала обмена данными устанавливает соединение между двумя хостами — отправителем и получателем. Это очень надежный протокол, так как при передаче не теряются данные и сохраняется порядок их отправки. В нем обязателен запрос подтверждения о получении пакета данных от получателя, а если нужно, TCP повторно отправит данные. Однако этот протокол передает данные достаточно медленно, потому что при таких надежности и упорядоченности нужно больше времени по сравнению с альтернативным протоколом UDP.
Протокол UDP (User Datagram Protocol) проще в использовании. Он может передавать информацию без установки соединения между хостами, что увеличивает скорость. Перед передачей данных готовность получателя не проверяется. Это уменьшает надежность UDP, поскольку возможна утеря отдельных фрагментов данных при передаче и нарушение их упорядоченности.
VPN же, хотя и тоже скрывает истинный IP-адрес, представляет собой целую виртуальную сеть. Как правило, программы воспринимают подключение к VPN в качестве дополнительного сетевого адаптера у компьютера. Прокси-сервер всего лишь перенаправляет запросы с компьютеров пользователей, а VPN-соединение проводит маршрутизацию и является гарантией абсолютной анонимности сетевого трафика, который проходит через него.
Существенное преимущество VPN — 256-битное шифрование трафика. То есть хакеры не перехватят данные, которые с вашего компьютера отправляются через VPN-сервер.
Как работает прокси-соединение
У каждого устройства, подключенного к интернету, есть свой уникальный IP-адрес, по которому идентифицируют интернет-пользователя. Структура IP-адреса состоит из номера сети и номера узла. По IP определяется страна, регион, а также номер интернет-провайдера и персонального компьютера, который относится к сети этого провайдера. У прокси-серверов тоже есть уникальные IP-адреса.
Итак, компьютер подключился к прокси и передал запросы в интернет. При этом определится IP-адрес сервера-посредника, самому же пользователю удастся остаться инкогнито. Чтобы подключиться к прокси, нужно будет сделать настройки в браузере, через который будут отправляться запросы пользователя.
Проще говоря, провайдер подключает устройство своего абонента к удаленному серверу, который соединит это устройство с заблокированным ресурсом либо подменит IP-адрес. Дальше IP-адрес компьютера станет определяться как таковой у прокси-сервера. При переходе пользователя на какой-либо сайт его компьютер соединится с прокси и совершит запрос. Если запрос окажется корректным, то через прокси ответ достигнет компьютера абонента и соединит его с сайтом.
Зачем нужна подмена IP-адреса и что она дает
Люди по разным причинам пользуются прокси для подмены своего IP, например, чтобы избежать блокировки по IP или чтобы остаться неузнанным в интернете.
Однако подмена IP может быть и направлением хакерской атаки, в которой задействуют чужой IP для обмана системы безопасности, чтобы попасть в определенную компьютерную сеть. Такие действия называются IP-спуфингом (IP-spoofing). В переводе с английского spoof значит «мистификация»: мошенник маскируется, делая вид, что он свой, и получает доступ к нужным ему данным.
Суть IP-спуфинга заключается в том, что создаются пакеты интернет-протокола (IP), имеющие ложный источник — IP-адрес отправителя. Это позволяет ввести в заблуждение получателя, который воспримет пакеты так, словно они пришли из другого источника. Так мошенник получает пакеты данных на свой адрес, а отправитель ни о чем не подозревает.
Классификации прокси-серверов
По уровню анонимности
По протоколам
Где взять стабильные прокси
Стабильный прокси — это сервер, который постоянно работает, имеет стабильные характеристики (скорость соединения, времени отклика и т. д.) и защищен от перебоев.
Часто бесплатные прокси-серверы работают какое-то время, а потом перестают. И если списку прокси уже неделя или даже месяц, то шансы найти в нем работающие серверы заметно снижаются. Однако оставшиеся все же будут наиболее стабильными.
Поэтому нужно взять такой список и проанализировать, проверить серверы на работоспособность, а затем удалить неактуальные. Оставшиеся будут стабильными рабочими прокси.
Перечислим 10 бесплатных сервисов, которые предоставляют достаточно стабильные прокси:
Как выбрать хороший прокси-сервер
Чтобы найти качественные прокси-серверы, стоит учесть некоторые критерии:
Какие риски возникают при пользовании прокси-сервером
Поскольку существуют достаточно серьезные риски, стоит заранее изучить различные прокси-серверы.
Основы работы с 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 в определении 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 проксирует запрос, он автоматически вносит некоторые поправки в заголовки, полученные от клиента.
Первый вывод, который можно сделать из вышеизложенной информации: если вы не хотите передавать тот или иной заголовок, нужно задать ему значение пустой строки. Заголовки с такими значениями полностью удаляются из переданного запроса.
Также следует убедиться, что в нестандартных заголовках нет подчеркиваний, что если ваше бэкэнд-приложение будет обрабатывать такие заголовки. Если вам нужны заголовки, в которых используется символ подчеркивания, вы можете установить директиве underscores_in_headers значение on (это валидно либо в контексте http, либо в контексте объявления server по умолчанию для комбинации IP-адреса/порта). Если вы этого не сделаете, Nginx пометит эти заголовки как некорректные и просто сбросит их, прежде чем перейти к upstream серверу.
Заголовок Host часто имеет такие значения:
Настройка или сброс заголовков
Чтобы настроить или установить заголовки для прокси-соединений, можно использовать директиву proxy_set_header. Например, чтобы изменить заголовок Host и добавить дополнительные заголовки, нужно использовать что-то вроде этого:
Конечно, директиву proxy_set_header стоит переместить в контекст server или http, чтоб иметь возможность ссылаться на нее:
Раздел 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 можно с помощью таких флагов и директив:
При изменении алгоритма блок может выглядеть так:
В приведенном выше примере сервер будет выбран по наименьшему количеству соединений. Можно также добавить директиву ip_hash, чтобы обеспечить «липкость» сессии.
Что касается метода hash, вы должны указать ключ для хэша. Это может быть что угодно:
В приведенном выше примере запросы будут распределяться на основе значений IP-адреса и порта клиента. Также здесь есть опциональный параметр consistent, который реализует алгоритм хэширования ketama consistent. Это означает, что если upstream серверы изменятся, это будет иметь минимальное воздействие на кэш.
Установка веса сервера для балансировки
В объявлениях бэкэнд-серверов по умолчанию все серверы весят одинаково. Это предполагает, что каждый сервер может и должен обрабатывать одинаковый объем нагрузки (с учетом эффектов алгоритмов балансировки). Тем не менее, вы также можете установить пользовательский вес своих серверов:
Теперь host1.example.com будет получать в три раза больше трафика, чем другие два сервера. Вес каждого сервера по умолчанию равен 1.
Использование буферов для освобождения бэкэнд-серверов
Один из главных вопросов при проксировании – насколько изменится скорость работы при добавлении сервера. Увеличение или уменьшение количества серверов можно значительно смягчить с помощью системы буферизации и кэширования Nginx.
При проксировании на другой сервер на опыт клиента влияет скорость двух разных подключений:
Nginx имеет возможность корректировать свое поведение на основе того, какое из этих соединений вы хотите оптимизировать.
Без буферов данные с прокси-сервера сразу же отправляются к клиенту. Если клиентские соединения быстрые, буферизацию можно отключить, чтобы клиент как можно скорее мог получить данные. При использовании буферов прокси-сервер Nginx будет временно хранить ответ бэкэнда, а затем передавать эти данные клиенту. Если клиент работает медленно, это позволит серверу Nginx быстрее закрыть соединение с бэкэндом. Затем он сможет обрабатывать передачу данных клиенту любым возможным способом.
Nginx по умолчанию использует буферизацию, так как скорость соединения, как правило, меняется в зависимости от клиента. Буферизация настраивается с помощью следующих директив. Их можно установить в контексте http, server или location. Важно иметь в виду, что директивы size касаются каждого запроса, поэтому они могут повлиять на производительность серверов при поступлении множества клиентских запросов.
Как вы можете видеть, 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. Если этот каталог не существует, вы можете создать его и определить права доступа к нему:
Параметр 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_cache, можно указать, что для этого контекста следует использовать зону кэширования backcache. Nginx проверит запись перед тем, как перейти к серверу.
Рекомендации по кэшированию результатов
Кеширование увеличивает скорость прокси-сервера. Но не стоит забывать о нескольких нюансах.
Во-первых, любая личная информация пользователей ни в коем случае не должна кэшироваться, чтобы пользователи не получали в ответ данные о других пользователях. Эта проблема не касается статичных сайтов.
Если на сайте есть динамические элементы, им следует уделить внимание. Решение этой проблемы зависит от бекэнд-сервера. Для личных данных используется заголовок Cache-Control со значением no-cache, no-store или private.
Есть связанный с этим поведением заголовок max-age, который определяет срок хранения кэша в секундах.
Его значение зависит от чувствительности данных. При разумном использовании этого заголовка конфиденциальные данные будут в безопасности, а часто изменяемый контент будет своевременно обновляться.
Если вы используете nginx и на бэкэнде, добавьте директиву expires, которая определяет значение max-age заголовка Cache-Control:
Первый блок поддерживает кэш в течение часа. Второй блок присваивает заголовку Cache-Control значение no-cache. Для внесения других изменений примените директиву add_header: