Как проксировать панель 3x-UI на определённый путь на веб-сервере Nginx с переписыванием путей к ресурсам?

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение
Пояснения к конфигурации
Выводы

Вопрос или проблема

У меня есть два VPS:

Первый используется для vpn/прокси. На нем запущен 3x-ui, который, проще говоря, позволяет создавать и управлять vpn/прокси через UI. IP-адрес VPS подключен к https://new-york.vpn.utils.example.com. Я использовал CloudFlare DNS и настроил ssl согласно инструкциям на странице github 3x-ui (с использованием CloudFlare Global API Key). Административная панель находится на :2053/secret_code/.
Второй планируется использовать как место для всех моих утилит и инструментов (одним из которых является этот vpn). В настоящее время это просто сервер на Linux с Nginx. Он доступен через https://utils.example.com. Тот же домен CloudFlare, в полном (строгом) режиме. Этот сервер является проксируемым.

Я хочу, чтобы админ-панель с первого VPS (которая находится на https://new-york.vpn.utils.example.com:2053/secret_code/) была доступна через https://utils.example.com/vpn/new-york/admin (который работает на втором VPS).

Я перепробовал миллионы различных конфигураций для Nginx (vps2), но ничего не работает должным образом. Я не эксперт в nginx, 3x-ui и также в DNS конфигурациях, поэтому я включу как можно больше информации, надеясь, что это чем-то поможет.

Вот одна из конфигураций nginx, которую я попробовал:

GNU nano 6.2      /etc/nginx/sites-available/utils.example.com
server {
    listen 80;
    server_name utils.example.com www.utils.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name utils.example.com www.utils.example.com;

    ssl_certificate /etc/nginx/ssl/cloudflare.crt;
    ssl_certificate_key /etc/nginx/ssl/cloudflare.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers '...';
    ssl_prefer_server_ciphers on;

    root /var/www/utils.example.com;
    index index.html;

    location = /404.html {
        internal;
    }

    location /vpn/new-york/admin {
        proxy_pass https://new-york.vpn.utils.example.com:2053/secret_code/;
    }

}

И кажется, что это работает, но не полностью. Результат — пустой белый экран (вместо интерфейса входа); однако, во время инспектирования страницы я обнаружил некоторые html элементы оригинальной страницы.

blank_screen

вместо

expected_screen

Я также заметил много ошибок 404 как в логах доступа nginx, так и в консоли js браузера. Я считаю, что это основная проблема, но я не знаю, как ее исправить. (По сути, ассеты не загружаются из-за неверного пути, вызванного проксированием)

errors

На странице 3x-ui также есть раздел о конфигурации Nginx. Но я не совсем понимаю, как и где его использовать. И я не уверен, применимо ли это в моем случае.

Также, в конфигурационной странице 3x-ui есть обратная вкладка, может быть, я должен что-то добавить там.

reserve_tab

Ответ или решение

Для решения задачи проксирования панели администрирования 3x-UI, запущенной на первом VPS, с использованием пути на втором VPS с Nginx, требуется учесть ряд технических аспектов. Основная проблема, с которой вы сталкиваетесь, связана с некорректным отображением ресурса из-за путей к статическим элементам (ассетам), которые неправильно переписываются при проксировании. Давайте разберем теоретические аспекты и предложим решение вашей задачи.

Теория

Для реализации проксирования веб-приложений через Nginx весьма распространенным является использование директивы proxy_pass. Однако, простая настройка proxy_pass может недостаточно работать в случае, если статические ресурсы не помещены в корень документа или если они не правильно переписываются. Проблема с "пустым экраном" и множеством ошибок 404 в логах доступа и консоли браузера обычно вызвана тем, что статические файлы (например, CSS, JS, изображения) не загружаются из-за некорректного пути.

Пример

Предположим, панель 3x-UI использует относительные пути для загрузки своих статических ресурсов. При проксировании пути вида /vpn/new-york/admin на другой сервер веб-ресурсы могли быть запрошены относительно этого нового базового пути, что приводит к 404 ошибкам.

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

Применение

Вот пример улучшенной конфигурации Nginx для вашего случая, который может помочь в решении возникшей проблемы:

server {
    listen 80;
    server_name utils.example.com www.utils.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name utils.example.com www.utils.example.com;

    ssl_certificate /etc/nginx/ssl/cloudflare.crt;
    ssl_certificate_key /etc/nginx/ssl/cloudflare.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers '...';
    ssl_prefer_server_ciphers on;

    root /var/www/utils.example.com;
    index index.html;

    location = /404.html {
        internal;
    }

    location /vpn/new-york/admin {
        proxy_pass https://new-york.vpn.utils.example.com:2053/secret_code/;
        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-Proto $scheme;

        # Переписывание путей для статических ресурсов
        sub_filter_types text/css;
        sub_filter '/secret_code/' '/vpn/new-york/admin/';
        sub_filter_once off;
    }

    location /vpn/new-york/admin/assets/ {
        proxy_pass https://new-york.vpn.utils.example.com:2053/secret_code/assets/;
    }
}

Пояснения к конфигурации

Директива proxy_pass: Эта директива занимается пересылкой всех запросов по указанному пути к серверу назначения. Здесь важно указать не только сервер, но и корректный подкаталог.
Заголовки Proxy: proxy_set_header используется для передачи исходных заголовков клиента на целевой сервер, что важно для правильной обработки запросов и аутентификации.
Переписывание путей sub_filter: Эта директива позволяет подменять пути прямо в теле HTML/CSS ответов от проксируемого серверного приложения. Это необходимо, чтобы относительные пути к ассетам указывали на правильное место.
Отдельная локация для ассетов: Можно использовать отдельные локации для статических ресурсов, если их структура сложна и они расположены не в предположительном месте.

Выводы

Важно не только настроить проксирование, но и понять, как веб-приложение работает с файлами на сервере назначения. Внимательно следите за логами Nginx и используйте инструменты разработчика в браузере для мониторинга сетевой активности – это поможет определить, какие именно ресурсы не загружаются и почему. Настройка переписывания путей и заголовков поможет в правильной маршрутизации ресурсов. Возможно, потребуется также внести изменения в конфигурацию самого управления 3x-UI, чтобы оно корректно работало через прокси.