Возврат URL-адресов перенаправления в NGINX
NGINX предоставляет две ключевые директивы для настройки перенаправления URL-адресов: returnи rewrite. Эти директивы имеют решающее значение для направления веб-трафика с одного URL-адреса на другой.
301 перенаправления в NGINX
Перенаправление 301 необходимо для постоянного перенаправления. Обычно оно используется, когда веб-сайт или веб-страница навсегда перемещены на новый URL. Чтобы настроить перенаправление 301 в NGINX, используйте директиву returnв блоке сервера, указав код статуса 301. Это гарантирует, что и пользователи, и поисковые системы будут направлены на новый URL.
Пример 301 редиректа
Предположим, вам нужно перенаправить трафик с oldsite.com на newsite.com. Конфигурация NGINX будет выглядеть так:
server {
listen 80;
server_name oldsite.com;
location / {
return 301 $scheme://www.newsite.com$request_uri;
}
}
Эта конфигурация эффективно перенаправляет все входящие запросы с oldsite.comна www.newsite.com, сохраняя исходный URI запроса. Этот простой, но мощный метод гарантирует, что пользователи и поисковые системы найдут ваше новое местоположение веб-сайта.
302 перенаправления в NGINX
В отличие от постоянного перенаправления, перенаправление 302 используется для сценариев временного перенаправления. Например, вы можете временно перенаправлять пользователей во время обслуживания веб-сайта или когда страница временно перемещается.
Пример 302 редиректа
Для иллюстрации предположим, что вы хотите временно перенаправить трафик с temp.com на another-site.com. Настройка NGINX будет такой:
server {
listen 80;
server_name temp.com;
location / {
return 302 $scheme://www.another-site.com$request_uri;
}
}
В этой конфигурации весь трафик на temp.comвременно перенаправляется на www.another-site.com. Использование кода статуса 302 указывает на то, что это перенаправление временное, что важно для поддержания целостности SEO во время краткосрочных изменений.
Директива перезаписи URL-адресов перенаправления в NGINX
Директива rewriteв NGINX — мощный инструмент для обработки сложных сценариев перенаправления URL. В отличие от простой returnдирективы, rewriteиспользует регулярные выражения и более широкий диапазон переменных. Эта гибкость позволяет точно контролировать, как перенаправляются URL, особенно в сценариях, где простого перенаправления недостаточно.
Перенаправление на основе расширения файла
Перенаправление определенных типов файлов
Распространенным требованием является перенаправление определенных типов файлов. Например, перенаправление всех .jpg запросов изображений в новый каталог:
server {
listen 80;
server_name www.example.com;
location ~* \.jpg$ {
rewrite ^/images/(.*)\.jpg$ /new-images/$1.jpg permanent;
}
}
В этой конфигурации любой запрос к .jpg файлу в /images/ каталоге перенаправляется на /new-images/. Регулярное выражение \.(jpg)$гарантирует, что .jpg будут затронуты только URL-адреса, заканчивающиеся на .
Динамическое перенаправление на основе URI
Перенаправление с помощью манипуляции URI
Другой распространенный сценарий включает динамическое перенаправление URL-адресов на основе их компонентов URI. Рассмотрите возможность перенаправления пользователей на основе категорий продуктов:
server {
listen 80;
server_name www.example.com;
location ~* ^/category/(.*)$ {
rewrite ^/category/(.*)$ /new-category/$1 permanent;
}
}
Эта настройка захватывает любой URL-адрес в разделе /category/ и перенаправляет его на соответствующий URL-адрес в разделе /new-category/, сохраняя последнюю часть URI.
Обработка устаревших структур URL
Перенаправление старых URL-адресов на новый шаблон
Веб-сайты часто меняют свою структуру URL с течением времени. rewriteДиректива может плавно обрабатывать такие переходы:
server {
listen 80;
server_name www.example.com;
location ~* ^/old-structure/(.*)$ {
rewrite ^/old-structure/(.*)/info$ /new-structure/$1/details permanent;
}
}
В этом примере показано, как перенаправить URL-адреса со старого шаблона ( /old-structure/[identifier]/info) на новый шаблон ( /new-structure/[identifier]/details).
Географическое перенаправление
Перенаправление пользователей по географическому положению
NGINX также может выполнять перенаправление на основе географического местоположения, используя $geoip_country_code переменную:
server {
listen 80;
server_name www.example.com;
if ($geoip_country_code = "US") {
rewrite ^/(.*)$ /us/$1 permanent;
}
}
В этой конфигурации посетители из США перенаправляются на раздел сайта, предназначенный для США. Этот подход требует включения модуля GeoIP в NGINX.
Балансировка нагрузки URL-адресов перенаправления в NGINX
NGINX отлично справляется с управлением сетевым трафиком благодаря возможностям балансировки нагрузки и перенаправления. Балансировка нагрузки в NGINX подразумевает распределение входящего трафика по нескольким серверам. Эта стратегия предотвращает перегрузку любого отдельного сервера, тем самым повышая общую производительность и надежность системы.
Настройка NGINX для балансировки нагрузки
Настройка балансировки нагрузки
Базовая балансировка нагрузки
Вот пример настройки NGINX для балансировки нагрузки:
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
В этой конфигурации NGINX действует как обратный прокси-сервер и равномерно распределяет входящие запросы на один из трех указанных внутренних серверов: backend1.example.com, backend2.example.com и backend3.example.com. Такая настройка имеет решающее значение для веб-сайтов с высоким трафиком, поскольку она обеспечивает эффективную обработку запросов, тем самым поддерживая быстрое время отклика и минимизируя время простоя сервера.
Расширенная балансировка нагрузки с проверками работоспособности
Для повышения надежности вы можете настроить NGINX для выполнения проверок работоспособности внутренних серверов и отправки трафика только на исправные серверы:
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
# Enable health checks
health_check;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
При такой настройке NGINX периодически проверяет работоспособность внутренних серверов и исключает любые серверы, которые не работают, из пула балансировки нагрузки. Это гарантирует, что трафик будет направлен только на серверы, способные обрабатывать запросы, что повышает общую надежность.
Лучшие практики балансировки нагрузки
Реализация сохранения сеанса (липкие сеансы)
Для приложений, требующих сохранения сеанса, можно использовать закрепленные сеансы, чтобы гарантировать, что пользователь последовательно перенаправляется на один и тот же внутренний сервер:
http {
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
В этой конфигурации ip_hash директива гарантирует, что запросы с одного и того же клиентского IP-адреса всегда будут направляться на один и тот же внутренний сервер, поддерживая согласованность сеанса.
Настройка завершения SSL
Для обеспечения безопасности связи лучше всего завершать SSL на балансировщике нагрузки:
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
location / {
proxy_pass http://backend;
}
}
}
В этой настройке NGINX обрабатывает SSL-терминацию, расшифровывая входящие SSL-запросы и перенаправляя их на бэкенд-серверы как обычные HTTP-запросы. Это разгружает обработку SSL с бэкенд-серверов, повышая их производительность.