nginx proxy redirect off
Помогите разобраться с директивами Nginx
Не могу понять почему во всех конфигах, что я видел в сети, при проксировании с помощью Nginx выключают следующую директиву: proxy_redirect off. Насколько я понял прочитав документацию (в принципе там и понимать нечего, там это черным по белому написано), эта директива меняет ответ проксируемого сервера. По идее её обязательно следует использовать, а её все вырубают. Отсюда следует, что я что-то не догоняю. Буду признателен за разъяснение.
По идее её обязательно следует использовать
совсем не обязательно
Так в этом и непонятки. Без этой директивы в ответе клиенту придет что-то типа «Location: http://localhost:8000/two/some/uri/», так на кой черт клиенту вообще знать о существовании бэкенда?
минимум 95% ЦМСок хранят хостнейм в базе, и юзают его при отдаче редиректа
Т.е. работа по изменению соответствующего заголовка перекладывается на другие компоненты, и поэтому proxy_redirect off;. Я правильно понимаю? А если у меня стоит только nginx и проксируемый Apach, и больше ничего (ни CMS, ни чего бы то ни было). То как тогда быть с данной директивой?
если приложение узнает свой хостнейм из настроек, то директива не нужна. если приложение определяет свой хостнейм из хттп заголовков, то директива нужна
все зависит от конкретного случая, но в случае с массовыми цмсками, хостнейм обычно хранится в базе, по этому по дефолту она отключена
Настройка проксирования запросов в nginx с использованием директивы Nginx proxy pass
В примере рассматривается настройка проксирования запросов с subdomain.example.com на https://subdomain.example.ru/suf
На сервере, на котором настраивалось проксирование применяется Apache в качестве бэкенд сервера и Nginx в качестве фронтенд сервера. Проксирование реализовано на уровне фронтенда, т.е. до Apache запросы не доходят.
Содержание конфигурационного файла:
server <
server_name subdomain.example.com;
listen *:80;
proxy_read_timeout 200s;
access_log off;
include static.conf;
location / <
root /var/www/sites/subdomain.example.com;
proxy_pass https://subdomain.example.ru/suf;
proxy_set_header X-Forwarded-Host subdomain.example.com:80;
proxy_set_header X-Forwarded-Server subdomain.example.com;
proxy_set_header X-Forwarded-For https://subdomain.example.ru/suf;
static.conf здесь — отдельный файл в котором заданы настройки кэширования, также они могут задаваться в любом другом конфиге.
За счет приведенных ниже директив реализуется реверсивное проксирование запросов, это аналог ProxyPassReverse в Apache:
proxy_set_header X-Forwarded-Host subdomain.example.com:80;
proxy_set_header X-Forwarded-Server subdomain.example.com;
proxy_set_header X-Forwarded-For https://subdomain.example.ru/suf;
Добавив конфиг активируем его обычным способом — через создание симлинка
Проверяем конфигурацию веб-сервера
Если ошибок нет — даем команду на перечитывание конфигов
Директива nginx proxy redirect
Схожим образом можно настроить в конфигурационном файле nginx редирект с одного адреса на другой.
Применяя аналогичный конфигурационный файл, но с раскомментированный директивой proxy_redirect можно получить перенаправление, при этом адрес сайта в адресной строке браузера будет подменяться.
Очень часто используется простое проксирование на IP адрес из приватной сети
location / <
root /var/www/sites/example.com;
proxy_pass https://127.0.0.10;
С самой простой реализацией Nginx proxy pass, приведенной выше, запускаются проекты на NodeJS и фреймоворке Express. Изначально они стартуют на localhost и порту 3000
Примеры редиректов в NGINX
В данной инструкции мы рассмотрим, в большей степени, перенаправления запросов на другие страницы с помощью NGINX. Также мы немного разберем проксирование и перенаправление на другие файлы.
Настройка перенаправлений
Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В Linux на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.
Саму настройку на перенаправление в NGINX можно прописать несколькими способами.
* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:
* где коды могут использоваться любые, но чаще всего — 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используются оба варианта.
После внесения изменений, необходимо проверить их корректность:
И для их применения перезапустить веб-сервер:
systemctl restart nginx
service nginx restart
* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.
Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.
С HTTP на HTTPS (другой порт)
Пример конфигурации для перенаправления запросов на другой порт — с 80 (http) на 443 (https):
server <
listen 80;
server_name domain.ru www.domain.ru;
return 301 https://$host$request_uri;
>
* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).
Также мы можем добавить условие, чтобы не перенаправлять на https для определенных ссылок, например:
/page.html) <
return 301 https://$host$request_uri;
>
>
* в данном примере запрос на страницу /page.html будет открыт по http.
С одного домена на другой
server <
.
server_name domain1.ru;
return 302 http://domain2.ru$request_uri;
>
C домена без www на домен с www
server <
.
server_name domain.ru;
return 301 http://www.$host$request_uri;
>
С www на без www
Все домены, которые обслуживает nginx:
C index.php на / (корень)
Данная настройка позволит перевести все запросы с /index.php на корневой адрес /:
server <
.
if ($request_uri
Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)
Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:
server <
listen 80 default_server;
return 302 https://welcome.domain.ru$request_uri;
>
или независимо от протокола:
ssl on;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
>
* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабатывать запросы по https, необходимо указывать в настройках пути к сертификатам.
С IP-адреса на домен
В данном случае мы переводим все запросы по IP-адресу на конкретный домен:
server <
listen 80;
server_name 192.168.1.15;
return 301 http://site.ru$request_uri;
>
* при отправке http-запроса на сервер 192.168.1.15 по IP-адресу, он будет переведен на домен site.ru.
Редирект домена и всех его поддоменов
server <
.
server_name domain domain.*;
return 301 https://$host$request_uri;
>
На другой файл
Это скорее не перенаправление, а алиас или rewrite. Позволяет по запросу одного из файлов, отдать другой:
server <
.
location = /robots.txt <
rewrite ^/robots.txt$ /robots2.txt;
>
>
* в данном примере по запросу robots.txt, сервер отдаст содержимое robots2.txt.
Часть url на другой сервер
Перенаправить запрос на другой сервер при обращении по url page1:
server <
.
server_name domain1.ru;
location
* в данном примере для всех запросов, начинающихся на /page1/. будет работать перенаправление на другой домен domain2.ru.
Редирект со слешем
1. Убрать слеш в конце url
2. Добавить слеш в конце url
Удаляем расширение
Для перенаправления запроса, где в URL есть полное название файла скрипта (с расширением) используем конфигурацию:
server <
.
if ($request_uri
* в данном случае все запросы, которые заканчиваются на .php или .html, будут перенаправляться на страницы без данных расширений.
Для примера, запрос http://site-example.ru/page.php будет переведен на http://site-example.ru/page.
На другую страницу
Нам может понадобиться перенаправлять запросы с одной страницы сайта на другую. Приведем примеры, как это сделать с помощью return и rewrite.
а) с помощью rewrite:
server <
.
rewrite ^/page1$ /page2 permanent;
>
б) с помощью return:
server <
.
location = /page1 <
return 301 /page2;
>
>
Удалить часть URL
Иногда нужно удалять часть url. Это можно сделать следующими способами:
server <
.
rewrite /deleted-url/(.*) /$1 permanent;
>
server <
.
if ($request_uri
* в данном примере из url мы удалим deleted-url/.
Перенаправить запрос в случае обращения к несуществующим файлам
Перевод запросов, если файла не существует
Данное действие не является редиректом, но близко по смыслу — NGINX проверяет наличие файла скрипта, к которому идет обращение, и если его нет, переводит запрос на другой файл. Как правило, это используется для того, чтобы перевести все обращения на файл index.php.
* в данном примере мы скажем веб-серверу все запросы обрабатывать с помощью файла index.php в корневой директории.
Проксирование
Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.
Хоть это и не совсем редирект, рассмотрим примеры его настройки, так как очень часто нужно не перенаправление, а, как раз, обратное проксирование.
1. На другой сервер
Пример внутреннего перенаправления http-запроса на другой веб-сервер:
* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.
Использование NGINX в качестве http-прокси:
* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.
HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):
server <
.
location / <
proxy_pass http://10.10.10.10/page/;
proxy_set_header Authorization «Basic dGVzdDp0ZXN0»;
.
>
>
* где 10.10.10.10/page — страница, на которую будут перекинуты запросы; dGVzdDp0ZXN0 — логин:пароль test:test, закодированные в формате base64.
2. Часть url на другой сервер
Выше мы рассмотрели пример перенаправления запроса по части веб-адреса. По схожему сценарию мы можем делать проксирование:
3. На другой сайт
Мы можем сделать так, что при переходе по одному адресу у нас будет открываться совершенно другой сайт:
* в данном случае мы при обращении к нашему серверу (до доменному имени dmosk.local) будем попадать на сайт https://www.dmosk.ru. Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси.
4. На другой сайт по части URL
Если нам нужно настроить проксирование на другой сайт при обращении к определенной странице сайта, настраиваем NGINX так:
* в данном примере, если мы перейдем на страницу www.dmosk.ru/page, то мы попадем на сайт www.site.ru.
5. Редиректы при проксировании
Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:
proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
>
>
* в конкретном случае мы проксируем запросы http://dmosk.local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.
Немного о 301 и 302
В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.
301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и то же. Таким образом, результаты ранжирования необходимо сохранить для новой страницы.
302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.
Примеры настройки перенаправлений на NGINX
Где настраивать редирект в Nginx
Эти файлы с параметрами, которые идентичны, вне зависимости от используемого дистрибутива Linux. Тем не менее, их расположение может отличаться:
Как применить настройки редиректа
Чтобы применить редиректы на веб-сервере Nginx, необходимо выполнить последовательно два действия:
Настройка редиректа
Ниже разберем два основных способа настройки редиректов для выбранных веб-страниц. Так как общепринятого мнения, какой из них является оптимальным, в практике не сложилось, в последующих примерах будут использоваться оба.
Способ №1
Первый представляет собой строку:
При настройке можно выбрать следующие флаги ( ):
Способ №2
По завершении редактирования файлов остается проверить, правильны ли они:
Чтобы их применить, необходима перезагрузка Nginx:
Первая команда используется в новых версиях Linux. Вторая — для устаревших версий и FreeBSD.
Практическое использование редиректов
Редирект с www на без www
Это наиболее распространенное перенаправление, которое позволяет направить весь трафик непосредственно на домен, минуя поддомены. Код редиректа:
Если необходимо получить противоположный эффект (перенаправление на «www» c «без www»):
Редирект на другой домен
Чтобы организовать перенаправление на другой сайт — например, после изменения адреса сайта — можно воспользоваться командой:
Второй вариант проще:
Редирект с http на https
Установить перенаправление с http на https (защищенный протокол SSL ) можно следующим образом:
Здесь при всех обращениях domain.ru по протоколу http сработает перенаправление на 443-порт с использованием 301 редиректа для склейки доменов.
Редирект на другой сервер
При необходимости использовать перенаправление на другой сервер всех запросов:
Здесь за прием запросов браузера и ответ на них отвечает веб-сервер Nginx. Их обработка выполняется сервером с IP-адресом 192.168.0.12 (порт 8080 ). Таким же образом осуществляется и перенаправление на другой Nginx.
Редирект с IP адреса на домен
Перенаправление домена без www на домен с www
В противном случае (редирект с www на без www) нужно использовать такое сочитание:
Перенаправление одного URL
Перенаправление на index.php
Сделать так, чтобы запросы из браузера обрабатывались через index.php можно таким образом:
Если же файл расположен в корневом каталоге, перенаправление на index.php указывается командой:
Перенаправление «после слэша» (/)
Следующий блок позволяет установить перенаправление «после слэша» для домена:
Это приведет к тому, что после ввода адреса http://domain.com/mail пользователь будет перенаправлен на https://mail-server.com/mail-panel.
Стоит добавить в приведенный пример знак « = », чтобы перенаправление относилось только к этому элементу (почта), а не ко всему, что начинается с «mail»:
Перенаправление с изменением типа файла
Еще один вариант будет полезным, когда ссылку на файл HTML нужно автоматически заменить ссылкой на файл PHP:
Несколько доменов, один каталог и один основной домен
Этот прием пригодится при наличии нескольких доменов. Для примера возьмем следующие домены:
Все эти домены указывают на один и тот же каталог на сервере. Соответственно, они отображают одну и ту же страницу/контент, хотя и при вводе разных адресов.
Не стоит забывать об исключении ошибки 404 («страница не найдена»), которая может возникнуть, если кто-то воспользуется ссылкой на товар/страницу с одного из альтернативных доменов. Решить эту задачу можно следующим способом:
Таким образом, все альтернативные адреса, отличные от «.ru», будут направлены на «new-address.ru», который является основным адресом.
Техническое обслуживание сайта
Следующий сценарий подойдет для сайта, который находится на техническом обслуживании. То есть в случае необходимости внесения изменений на сайте. При этом перенаправление будет работать в случае обращения к определенному IP-адресу.
Задача заключается в перенаправлении оставшихся посетителей на страницу, которая будет содержать информацию, подобную «На сайте ведутся технические работы…». Это можно осуществить следующим способом:
Вместо подстановочных значений «123.123.123.123» в примере следует вписать IP-адрес своего сервера.
Дополнительные настройки
Свой IP-адрес нужно исключить с редиректа, чтобы сохранить полный доступ к сайту:
Вместо 123.123.123.123 следует указать IP адрес своего сервера.
Благодаря примеру ниже можно обнаружить, существует ли такой файл (technical-break.html) на сервере:
Если да, перенаправление сработает, в противном случае сайт открывается в обычном режиме.
Работа над новой версией сайта с перенаправлением на старую
Перенаправить пользователей на старую версию:
Вместо «123.123.123.123» необходимо подставить IP адрес своего сервера (или адреса).
В случае, если возникает циклическое перенаправление на странице, следует добавить:
Перенаправление в зависимости от IP-адреса посетителя
Приведённый ниже способ предпочтителен с точки зрения SEO-оптимизации, так как при выполнении сценария в ссылках ничего не меняется:
При посещении сайта, сервер предоставляет владельца или администратору ресурса ( MY_IP ) файлы из каталога new-version («новая-версия»). Когда страница посещается «сторонним лицом», сервер открывает старую версию сайта.
Перенаправление в зависимости от IP-адреса посетителя и браузера
Ситуация становится немного сложнее, когда нужно нужно организовать подключение с использованием сразу двух условий:
К сожалению, Nginx не поддерживает правила объединения, поэтому здесь следует применить небольшой трюк:
Редирект в зависимости от файлов cookie
В то время как на рабочем месте часто используется статический IP-адрес, бывает, что работу над сайтом нужно проводить удалённо, с другого IP-адреса.
Хотя в таких ситуациях может помочь подключение через VPN, это не всегда возможно. Здесь применяется еще одно условие — проверка cookie:
Если в браузере будет сохранен cookie с контентом «text», то файлы нового сайта будут открываться без редиректа.
Очевидно, понадобится механизм для сохранения соответствующего куки в браузере. Здесь достаточно применить директиву PHP:
Она сохраняется на сервере (например, в файле cookie.php). Он добавляется в каталог со старой (для создания cookie) и новой страницей (обновления cookie до его истечения). Данный код выполняет следующую инструкцию:
В приведенном выше примере cookie действителен в течение 5 минут (300 секунд), после чего — если он не будет создан снова — вместо новой страницы снова будет отображаться старая страница. Когда новая страница готова, достаточно удалить эти несколько строк.
Nginx и CloudFlare
В случае использования CloudFlare существует высокая вероятность того, что редирект не будет работать правильно для выбранного IP-адреса, то есть сервис не будет его распознавать.
В этом случае в файле конфигурации виртуального хоста следует добавить:
Адреса в примере взяты из текущего списка адресов, используемых CloudFlare, размещенного на официальной странице https://www.cloudflare.com/ips/. Это список актуален на момент публикации, но может со временем меняться
Начни экономить на хостинге сейчас — 14 дней бесплатно!
Проксируем и спасаем
ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов. Для одних это важнейшая политическая тема, для других повод изучить технологии шифрования и защиты анонимности, для третьих просто очередной странный закон, который приходится исполнять на бегу. Мы же поговорим о технологическом аспекте.
В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить 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 не достаточно чтобы выполнить необходимую отладку, буду рад советам как запустить корзину покупок, которая сейчас в упомянутом примере не работает.
В любом случае, это, возможно, первый гайд, в котором описан метод проксирования в поддиректорию.