Использование sse вместо websockets для однонаправленного потока данных через http / 2

Введение

Просто настроить gitlab за nginx в режиме proxy_pass не представляет никакой сложности. Трудности возникают именно тогда, когда вы хотите использовать встроенный Container Registry. Я несколько раз подходил к этой задаче и каждый раз отступал, либо отказываясь от registry, либо от nginx proxy.

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

С registry не получалось корректно настроить работу за прокси. Я перепробовал все советы, что только нашел в интернете. Перечитал всю документацию, но так ничего не получилось. Команда docker login успешно отрабатывала на сервере, а вот запушить образ в реджистри gitlab никак не получалось. Получал ошибку.

Проблему я в итоге решил, когда залез во внутренности gitlab и разобрался, как там все устроено. Когда все понял, придумал рабочее решение, которым с вами делюсь.

Настройка прокси Nginx

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

Сначала установите Nginx, если вы этого еще не сделали:

Дальше создадим виртуальный хост Nginx с несколькими доменами, с помощью которого и будет выполняться проксирование Nginx:

Для использования nginx в качестве прокси мы передаем в команде proxy_pass адрес и порт веб-сервера, а в заголовках передаем те значения, которые будут нужны Apache для правильного формирования документа. Сохраните файл и активируйте его:

Затем проверьте конфигурацию и перезапустите Nginx:

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

Как вы могли убедится, теперь применяется nginx в качестве прокси. Теперь можно закрыть прямой доступ к Apache из сети с помощью iptables:

Passing a Request to a Proxied Server

When NGINX proxies a request, it sends the request to a specified proxied server, fetches the response, and sends it back to the client. It is possible to proxy requests to an HTTP server (another NGINX server or any other server) or a non-HTTP server (which can run an application developed with a specific framework, such as PHP or Python) using a specified protocol. Supported protocols include FastCGI, uwsgi, SCGI, and memcached.

To pass a request to an HTTP proxied server, the directive is specified inside a . For example:

This example configuration results in passing all requests processed in this location to the proxied server at the specified address. This address can be specified as a domain name or an IP address. The address may also include a port:

Note that in the first example above, the address of the proxied server is followed by a URI, . If the URI is specified along with the address, it replaces the part of the request URI that matches the location parameter. For example, here the request with the URI will be proxied to . If the address is specified without a URI, or it is not possible to determine the part of URI to be replaced, the full request URI is passed (possibly, modified).

To pass a request to a non-HTTP proxied server, the appropriate directive should be used:

• passes a request to a FastCGI server
• passes a request to a uwsgi server
• passes a request to an SCGI server
• passes a request to a memcached server

Note that in these cases, the rules for specifying addresses may be different. You may also need to pass additional parameters to the server (see the reference documentation for more detail).

The directive can also point to a of servers. In this case, requests are distributed among the servers in the group according to the specified method.

Управление службами с помощью systemctl

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

После завершения установки Nginx уже настроен для автоматического запуска. Nginx выполняется как daemon. Состояние деймона можно проверить с помощью systemctl.

Команда используется для управления «службами» для таких задач, как отображение состояния службы или ее запуск и остановка. Некоторые доступные параметры: запуск, остановка, перезапуск, включить, отключить и состояние. Чтобы проверить состояние Nginx, запустите .

Эта команда создает некоторые полезные сведения. Как показано на этом скриншоте, Nginx находится в состоянии, а iD процесса экземпляра Nginx — 8539

Кроме того, обратите внимание на и заявления. означает, что этот daemon начнется при перезапуске машины и означает, что nginx включен по умолчанию при установке

Поэтому при запуске сервера Nginx запустится автоматически.

Настройка basic auth

При настройке http-авторизации на прокси-сервере с Nginx может случиться проблема с авторизацией на сайте с битрикс.

Пример следующий: на стороне Nginx basic auth успешно проходит после ввода верного логина\пароля, и пускает пользователя дальше на проксируемый ресурс. Но битрикс почему-то принимает логин и пароль от basic auth в свою веб-форму авторизации и выдает ошибку “неверный логин или пароль”. Данная проблема по началу может смутить, т.к. на первый взгляд нет никакой связи между файлом для basic auth, созданным через htpasswd, и веб-формы авторизации сайта.

Но объяснение этого достаточно просто: при использовании модуля ngx_http_auth_basic_module формируется HTTP-заголовок “Authorization”, где зашиваются зашифрованные в base64 логин и пароль, которые пользователь вводит при появлении окна basic auth. А после того, как логин\пароль введён верно, запрос пользователя проксируется на сайт с битрикс, а вместе с ним и заголовок “Authorization”. И тут в игру вступает битрикс и веб-сервер apache – по умолчанию в файле .htaccess сайта, созданного через bitrix-env, есть следующая строка:

В переменную REMOTE_USER добавляется значение из HTTP-заголовка HTTP:Authorization, в котором содержится логин\пароль для basic auth. А дальше битрикс пробует авторизовать пользователя уже в своей форме на основе REMOTE_USER, делается это через код.

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

1. В .htaccess можно просто закомментировать строку RewriteRule .* – . Это допустимо при условии, что в дальнейшем не потребуется SSO через Kerberos или NTLM, т.к. как раз на основе переменной REMOTE_USER битрикс и производит сквозную авторизацию.
2. И самое правильное решение, разумеется, находится на стороне Nginx. Для заголовка HTTP:Authorization просто подставляется пустое значение, а потому битриксу будет неоткуда взять значение для REMOTE_USER, и сайт попросит ввести логин\пароль уже в стандартную форму.

Как закрыть директорию паролем

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

В каталоге, к которому хотим ограничить доступ по паролю, создаем файл .htaccess с такими директивами:

Путь обозначает полный путь к файлу паролей на диске нашего сервера. Если, например, вы поместите файл .htpasswd (в нем будут пароли) в домашний каталог, куда вы попадаете зайдя на сервер по FTP, то путь к этому файлу будет иметь вид /home/uXXXXX/.htpasswd, где uXXXXX — наименование вашей виртуальной площадки (например, u12345).

В директиве AuthUserFile указываем абсолютный путь к файлу с логинами/паролями, который мы создадим чуть позже

Если вы создаете файл .htaccess на своем компьютере, а не сразу на сервере при помощи текстового редактора, обратите внимание на то, что .htaccess должен передаваться по FTP строго в текстовом (ASCII) режиме

Создаем файл паролей. Файл с паролями должен содержать строки вида login:password. Пароль должен быть зашифрован с использованием алгоритма MD5. Один из способов создать такой файл — воспользоваться программой, входящей в поставку Apache — htpasswd (на нашем сервере она находится в каталоге /usr/local/bin/, полный путь — /usr/local/bin/htpasswd).

Рассмотрим как создать файл паролей в unix shell прямо на сервере. Зайдем в shell, и будем выполнять следующие команды:

* htpasswd -mbc .htpasswd user1 sNQ7j9oR2w создаем новый файл .htpasswd, в который добавляем запись для пользователя user1 с паролем, указанным в командной строке. Просьба обязательно заменить sNQ7j9oR2w на любой собственный пароль — здесь этот пароль указан только для примера * htpasswd .htpasswd user2 добавляем в уже существующий файл .htpasswd пользователя user2, а пароль вводим вручную в ответ на соответствующий запрос программы

Если вы используете Windows и не хотите пользоваться unix shell для генерации паролей, можно загрузить Windows-версию программы htpasswd здесь и создать файл с паролями на своем компьютере, после чего загрузить его на сервер. Если у вас уже установлена Windows-версия Apache, файл htpasswd.exe можно найти в каталоге Program Files\Apache Group\Apache\bin\.

Итак, получите htpasswd.exe и используйте его для генерации паролей таким образом:

* htpasswd.exe -mc .htpasswd user1 создаем новый файл паролей htpasswd.exe, пароль и его подтверждение будут запрошены интерактивно * htpasswd.exe -m .htpasswd user2 добавляем пользователя user2 в существующий файл паролей htpasswd.exe, запросив пароль интерактивно

После окончания заведения всех логинов файл нужно загрузить на сервер.

Настройка Apache для php-fpm

По умолчанию в Apache используется модуль mod-php для выполнения php скриптов. Сначала необходимо его отключить:

Затем мы настроим работу mod_fastcgi с помощью модуля mod_actions, для этого нужно его активировать:

Затем создадим конфигурационный файл fastcgi.conf:

Сохраните изменения, активируйте модуль и проверьте конфигурацию веб-сервера:

Вы увидите сообщение, что с синтаксисом конфигурационных файлов все хорошо. Если программа выдаст сообщение Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1, его можно игнорировать. Далее перезапустите Apache:

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

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

• /xxx – проксируем на http://172.30.93.84/test/ – если он доступен;
• а если не доступен, то проксируем на http://172.30.93.83/test/.

Для этого поправим наш конфиг /etc/nginx/sites-enabled/proxy и перед блоком server добавим блок upstream:

# nano /etc/nginx/sites-enabled/proxy
upstream backend {
        server 192.168.5.84:80 fail_timeout=120s max_fails=3;
        server 192.168.5.83:80 backup;
}

server {
        listen 80 default_server;

*** сократил ***

В этом блоке указываем оба web-сервера. При этом webбудет основным сервером. Но если proxy в течении 120 секунд получит три ошибки при обращении к web1, то на 120 секунд все запросы пойдут на web2.

Ниже в блоке server, где мы указывали что на что проксировать (блоки location), поменяем записи. Вместо ip-адреса web-сервера укажем название апстрима, которое мы придумали выше (backend). Второй блок (location /yyy) – удаляем. Получится так:

# проксируем запрос /xxx
location /xxx {
         proxy_pass http://backend/test/;
}

Полностью конфиг будет выглядеть так:

upstream backend {
        server 192.168.5.84:80 fail_timeout=3s max_fails=2;
        server 192.168.5.83:80 backup;
}

server {
        listen 80 default_server;
        listen :80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name proxy;

        # Управление заголовками на прокси сервере
        proxy_set_header X-Scheme https;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-PORT $remote_port;
        proxy_set_header X-Real-IP $remote_addr;

        # настройка буфера для прокси сервера
        proxy_buffering  on;
        proxy_buffer_size 32k;
        proxy_buffers 20 512k;

        location / {
                # вначале попытаемся обработать запрос как файл,
                # затем как каталог, затем вернём ошибку 404
                try_files $uri $uri/ =404;
        }

        # проксируем запрос /xxx
        location /xxx {
                proxy_pass http://backend/test/;
        }
}

Перезапустим nginx:

# service nginx restart

Проверка резервирования

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

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

Как видим мы перешли на второй сервер. Теперь включим обратно первый сервер и обновим страничку еще раз:

Теперь мы вернулись на первый сервер.

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

Пример двойного редиректа

Для того, чтобы было понятно, о чем идет речь, приведу пример. Допустим, у вас настроен и добавление к урлу в конце слеш. То есть вы хотите такое преобразование:

http://site.ru/catalog -> https://site.ru/catalog

Допустим, у вас сначала был настроен редирект на https подобным образом:

server {
 listen 80;
 root   /var/www/site.ru/public;

 location / {
  return 301 https://site.ru$request_uri;
 }
}

А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.

server {
 listen 443 http2;
...................
 location / {
  rewrite ^(*)$ $1/ permanent;
...................
}

# curl -I -L http://site.ru/catalog

HTTP/1.1 301 Moved Permanently
Server: nginx
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://site.ru/catalog

HTTP/2 301 
server: nginx
content-type: text/html
content-length: 162
location: https://site.ru/catalog/

HTTP/2 200 
server: nginx
content-type: text/html; charset=utf-8
vary: Accept-Encoding

На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:

server {
 listen 80;
 server_name site.ru www.site.ru;
 root   /var/www/site.ru/public;

 location / {
  return 301 https://site.ru$request_uri/;
 }
}

Вроде бы все нормально. Теперь редирект будет автоматически добавлять слеш в конец запроса. Но проблемы начнутся со ссылками на медиа файлы. Например, запрос http://site.ru/catalog/img.png будет превращаться в https://site.ru/catalog/img.png, что нам совершенно не нужно. Чтобы это исправить, надо сделать так.

server {
 listen 80;
 server_name site.ru www.site.ru;

 location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
  return 301 https://site.ru$request_uri;
 }

 location / {
  return 301 https://site.ru$request_uri/;
 }
}

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

Что важно понимать про HTTP

1. HTTP — это протокол общения клиент-серверных приложений в вебе. Набор правил, который помогает клиентам (прежде всего браузерам) и веб-серверам понимать друг друга.
2. HTTP — это про формат общения, а не про управление сервером HTTP-командами. Клиент может отправить что угодно: удали страницу сайта, создай нового пользователя, выдай список всех пользователей — но сервер не обязан их выполнять, он лишь обязан ответить в формате HTTP, чтобы клиент его понял. То есть благодаря HTTP сервер поймёт, что клиент хочет, а потом уже решит, как это обработать и вернёт результат. Может быть удалит страницу, а может и нет.
3. В HTTP общение всегда начинает клиент. А веб-сервер висит и ждёт. Сейчас есть способы инициировать запрос с сервера, но изначально протокол для этого не предназначен.
4. HTTP-протокол не имеет шифрования, поэтому передавать персональные данные и прочие приватные данные через него не безопасно. В таком случае нужно использовать HTTPS.
5. Простой способ изучить заголовки запроса и ответа — открыть консоль браузера на нужной странице и обновить её. В разделе Network/Сеть отобразятся все запросы с этой страницы, включая запросы на картинки и статические файлы.

Копирование числовых ячеек из 1С в Excel Промо

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

Копирование числовых ячеек из 1С в Excel Промо

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

Ограничения на подстановочные знаки в URI перенаправления

URI с подстановочными знаками, такие как , кажутся удобными, но их следует избегать из-за проблем с безопасностью. Согласно спецификации OAuth 2.0 (), URI конечной точки перенаправления должен быть абсолютным.

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

Чтобы добавить URI перенаправления с подстановочными знаками для зарегистрированных приложений, которые входят в рабочие или учебные учетные записи, используйте редактор манифеста приложения в разделе Регистрация приложений на портале Azure. Хотя с помощью редактора манифеста действительно можно задать URI перенаправления с подстановочными знаками, мы настоятельно рекомендуем придерживаться требований раздела 3.1.2 RFC 6749 и использовать только абсолютные URI.

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

Использование параметра состояния

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

Если вы используете этот подход:

1. Создайте «общий» URI перенаправления для каждого приложения, чтобы обрабатывать маркеры безопасности, полученные от конечной точки авторизации.
2. Приложение может отсылать параметры, зависящие от приложения (например, URL-адрес поддомена, откуда перешел пользователь, или настройки фирменного оформления), в параметр состояния. При использовании параметра состояния необходимо предотвратить защиту CSRF, как указано ).
3. Параметры, зависящие от приложения, будут включать всю информацию, необходимую приложению для корректного отображения для пользователя, то есть для создания соответствующего состояния приложения. Конечная точка авторизации Azure AD удаляет HTML-код из параметра состояния, поэтому не передавайте HTML-содержимое в этом параметре.
4. Когда Azure AD отправляет ответ на общий URI перенаправления, он отправляет параметр состояния обратно в приложение.
5. Затем приложение может использовать значение в параметре состояния, чтобы определить URL-адрес для отправки пользователю. Убедитесь, что вы проверили защиту CSRF.

Предупреждение

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

Практическая часть

Настраиваем nginx

Устанавливаем nginx на сервере proxy:

# apt install -y nginx

У меня установился nginx такой версией:

# nginx -v
nginx version: nginx/1.14.2

Для настройки прокси создадим новый виртуальный хост:

# nano /etc/nginx/sites-available/proxy
server {
        # Основные настройки
        listen 80 default_server;
        listen :80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name proxy;

        # Управление заголовками на прокси сервере
        proxy_set_header X-Scheme http;
        proxy_set_header X-Forwarded-Proto http;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-PORT $remote_port;
        proxy_set_header X-Real-IP $remote_addr;

        # настройка буфера для прокси сервера
        proxy_buffering  on;
        proxy_buffer_size 8k;
        proxy_buffers 8 8k;

        location / {
                # вначале попытаемся обработать запрос как файл,
                # затем как каталог, затем вернём ошибку 404
                try_files $uri $uri/ =404;
        }
        
        # проксируем запрос /xxx на web1
        location /xxx {
                proxy_pass http://192.168.5.84/test/;
        }
        
        # проксируем запрос /yyy на web2
        location /yyy {
                proxy_pass http://192.168.5.83/test/;
        }
}

Разбор конфига

На основных настройках я не буду заострять внимание, потому как они не относятся к настройке reverse proxy. Если вкратце там мы указали какие порты слушает наш сервер, корень сайта, индексные страницы и имя сервера

Следующие опции управляют http заголовками на прокси сервере:

• proxy_set_header X-Scheme http; – схема по которой подключается клиент (http или https);
• proxy_set_header X-Forwarded-Proto http; – протокол который использует клиент (http или https);
• proxy_set_header Host $http_host; – url-адрес по умолчанию, в качестве значения можем указать следующие переменные:
  • $http_host – то что клиент фактически набрал в адресной строке в браузере;
  • $proxy_host – имя и порт проксируемого сервера (web1 или web2), как указано в proxy_pass;
  • $host – имя этого сервера, как указано в server_name (proxy);
• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; – этот заголовок содержит список прокси серверов по которым прошёлся клиент перед этим сервером, а переменная $proxy_add_x_forwarded_for содержит полученный заголовок X-Forwarder-For плюс добавляет свой сервер в этот список (это используется для передачи реального ip-клиента на backend);
• proxy_set_header X-Real-PORT $remote_port; – заголовок содержит порт клиента и переменная $remote_port содержит тоже порт клиента;
• proxy_set_header X-Real-IP $remote_addr; – заголовок содержит ip-адрес клиента и переменная $remote_addr содержит тоже самое.

А следующие строки отвечают за настройку работы буферной памяти для проксируемой информации:

• proxy_buffering on; – включаем буфер для прокси сервера;
• proxy_buffer_size 8k; – размер буфера для первой части ответа получаемого от проксируемого сервера, такая часть ответа включает в себя только заголовки и хранится отдельно от остальной информации;
• proxy_buffers 8 8k; – число и размер буферов для одного соединения, а вот сюда помещается ответ от проксируемого сервера.

Теперь разберем часть где мы указываем что проксировать и куда проксировать:

location /xxx {
         proxy_pass http://192.168.5.84/test/;
}

• /xxx – запрос который будем проксировать;
• proxy_pass http://192.168.5.84/test/; – куда будем проксировать, то есть на сервер 192.168.5.84 и на каталог /test.
• Ниже подобный блок для /yyy .

Отключим конфиг “default“, включим созданный нами конфиг “proxy” и перезагрузим службу сервера:

# rm /etc/nginx/sites-enabled/default
# ln -s /etc/nginx/sites-available/proxy /etc/nginx/sites-enabled/proxy
# service nginx restart

Настраиваем backend сервера

На обоих серверах проделаем одно и тоже! Во-первых установим apache2, затем создадим новый каталог /var/www/html/test. В этом каталоге сделаем индексную страничку index.html в которую запишем имя сервера. Вдобавок поменяем владельца нового каталога на www-data.

Проделываем следующее на обоих серверах:

# apt install apache2
# mkdir /var/www/html/test
# echo $HOSTNAME > /var/www/html/test/index.html
# chown -R www-data:www-data /var/www/html/test/

Проверка

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

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

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

web1 лежит на сервере с адресом 192.168.5.84 в каталоге test:

web2 лежит на сервере с адресом 192.168.5.83 в каталоге test:

Итог

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

Сводка

Имя статьи
Nginx. Reverse Proxy

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