Другая проблема обратного прокси nginx

Question

Я собираю обратный прокси nginx. Вот рабочий Nginx конф файл сниппет:

upstream my_upstream_server { 
    server 10.20.30.40:12345; 
} 

server { 
    server_name ssl-enabled.example.com; 

    listen 443 ssl; 
    ssl_certificate  /etc/ssl/server.crt; 
    ssl_certificate_key /etc/ssl/server.key; 
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2; 
    ssl_ciphers   HIGH:!aNULL:!MD5; 


    location/{ 
     proxy_pass   http://my_upstream_server/; 
     proxy_redirect  off; 
     proxy_set_header Host $host; 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
     proxy_set_header X-Forwarded-Host $server_name; 
    } 

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

Что я действительно хочу сделать, тем не менее, настроить это так, чтобы вместо того, чтобы идти в https://ssl-enabled.example.com/, мы можем направить пользователей на https://ssl-enabled.example.com/upstream/. (Я хочу сделать это, чтобы мы могли запускать несколько виртуальных хостов, каждый из которых проксировал другую службу, которую мы хотим активировать ssl.) Я попытался изменить линию местоположения от location / до location /upstream/; когда я это делаю, индексная страница приложения (https://ssl-enabled.example.com/upstream/) отображает штраф, но страницы под ним генерируют 404 ошибки. Вот пример:

This <a href="/some/link.html">link</a> is broken 

Nginx пытается служить /some/link.html вместо /upstream/some/link.html, который не работает.

Я попытался создать переписывание, которое отправило бы запрос в/вверх по потоку $ 1, но для главной страницы (который nginx теперь думает https://.../upstream/), он переходит в бесконечный цикл, пытается обслуживать/вверх по течению/вверх по течению/вверх по течению/... и, конечно, не получается.

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

Answer 1

Конфигурационных ниже должен сделать подобный редирект, как вы упомянули, не входя в цикл:

upstream my_upstream_server { 
    server 10.20.30.40:12345; 
} 

server { 
    server_name ssl-enabled.example.com; 

    listen 443 ssl; 
    ssl_certificate  /etc/ssl/server.crt; 
    ssl_certificate_key /etc/ssl/server.key; 
    ssl_protocols   TLSv1 TLSv1.1 TLSv1.2; 
    ssl_ciphers    HIGH:!aNULL:!MD5; 

    location /upstream { 
     proxy_pass   http://my_upstream_server/; 
     proxy_redirect  off; 
     proxy_set_header Host $host; 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
     proxy_set_header X-Forwarded-Host $server_name; 
    } 

    location/{ 
     return 301 https://ssl-enabled.example.com/upstream$request_uri; 
    } 
} 

В основном два блока местоположения.

Один для запросов, начинающихся с «вверх по течению», которые обслуживаются, а другой для тех, у кого нет, которые перенаправлены.

Answer 2

Alexey прав насчет/проще в использовании, и примерно в то время, когда он опубликовал свой комментарий, я пришел к пониманию, что, поскольку я могу создавать записи DNS для example.com, вместо того чтобы пытаться направить людей на https://server.example.com/upstream/, он будет гораздо проще просто создать запись DNS для https://upstream.example.com/

Так вот что я сделал, и похоже, что код делает именно то, что я хочу. Спасибо Алексею и Дайо за их ответы.