NginX ProxyPass работает только через поддомен, а не через domain.com/path

В настоящее время я работаю над настройкой обратного прокси-сервера nginx для веб-клиента esxi html5. Я видел два зарегистрированных рабочих конфига.

Вот такой:

 server {
 listen 443 ssl;
 server_name vmware.xxxxxxxxxx.org;
 location / {
 proxy_pass https://192.168.xxx.xxx/;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection “upgrade”;
 }

И этот:

location ^~ /vhost1 { # https://nginxserveraddress/vhost1 (will take you here)
    proxy_pass              https://serveripaddr/ui;
    proxy_http_version      1.1;
    proxy_set_header        Upgrade $http_upgrade;
    proxy_set_header        Connection "Upgrade";
    proxy_read_timeout      86400;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-Server $host;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        Authorization "";
    proxy_redirect          off;
}

У меня успешно прокси-сервер subdomain.domain.com с "точной" конфигурацией прокси-сервера, который не работает, когда я использую domain.com/ui.

Это работает:

server {
listen 443 ssl;

server_name subdomain.domain.com;

ssl on;
ssl_certificate /etc/ssl/certs/ssl-bundle.crt;
ssl_certificate_key /etc/ssl/private/server.key;

location / {

        proxy_pass          https://ip/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout      86400;
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-Server $host;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Authorization "";
        proxy_redirect          off;
}
}

Но это не так:

server {
listen 443 ssl;
server_name domain.com;


location /ui {
        proxy_pass          https://ip/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout      86400;
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-Server $host;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Authorization "";
        proxy_redirect          off;
    }
}

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

[Обновление] Так что это своего рода работа. Мне нужно войти в систему, но я все еще не могу получить доступ к файлам в корневом каталоге, даже если я проксирую базу веб-корневого каталога в моей конфигурации proxy_pass. Поэтому местоположение должно быть / not / ui. А для работы / работы мне нужно использовать поддомен, потому что у меня уже есть местоположение / в моем основном домене.

Надеюсь это имеет смысл...

Пример:

Я использовал это для проксирования корневого веб-сервера сервера:

location /ui {

  proxy_pass              https://192.168.*.*:443/;

Вместо того

location /ui {

  proxy_pass              https://192.168.*.*:443/ui;

Я заметил это и в другом приложении. Конкретно потоп не будет прокси domain.com/deluge

но работает через deluge.domain.com/

Я как бы сдался, так как получил сертификат SSL с подстановочными знаками и просто решил жить с поддоменами, и что не все работает через domain.com/path proxypass.

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