Настройка обратного прокси Nginx для 3x UI: конфигурация, WebSocket и HTTPS | AdminWiki
Logo

Настройка обратного прокси Nginx для 3x UI: конфигурация, WebSocket и HTTPS

01 августа 2026 9 мин. чтения
Содержание статьи

Вы развернули панель 3x UI на внутреннем порту и хотите предоставить к ней безопасный доступ извне. Прямой проброс порта панели наружу - плохая практика: вы теряете централизованный контроль над трафиком, не можете гибко управлять шифрованием и оставляете поверхность для атак открытой. Nginx в роли обратного прокси решает эти задачи: он принимает клиентские соединения по HTTPS, проверяет заголовки и прозрачно передаёт трафик на бэкенд 3x UI. В этой инструкции вы получите готовую конфигурацию с поддержкой WebSocket, корректной передачей URI и автоматическим SSL от Let's Encrypt - всё, что нужно для запуска в production в 2026 году.

Зачем нужен обратный прокси для 3x UI

Обратный прокси - это прослойка между клиентом и сервером приложения. Когда вы настраиваете Nginx перед 3x UI, вы получаете три ключевых преимущества. Первое: SSL-терминация. Nginx обрабатывает HTTPS, разгружая панель от криптографических операций. Вы можете использовать один сертификат Let's Encrypt для десятка сервисов за прокси. Второе: унификация точки входа. Все запросы приходят на 80 и 443 порты одного IP-адреса, а Nginx маршрутизирует их по разным бэкендам на основе доменного имени. Это критично, когда на сервере крутятся несколько веб-приложений. Третье: безопасность. Панель 3x UI слушает на localhost:54321 и физически недоступна из внешней сети. Злоумышленник не может атаковать её напрямую - он вынужден проходить через Nginx, где вы можете настроить rate limiting, фильтрацию по IP и fail2ban.

Типичный сценарий: у вас один VPS с публичным IP, на нём развёрнуты 3x UI, Zabbix и пара внутренних сервисов. Без прокси вам пришлось бы открывать три разных порта и настраивать SSL для каждого. С Nginx вы открываете только 443 порт, а маршрутизация идёт по доменным именам - panel.example.com, zabbix.example.com. О том, как построить такую инфраструктуру с нуля, читайте в полном руководстве по настройке Nginx Reverse Proxy.

Предварительные требования и исходные данные

Перед началом настройки убедитесь, что у вас есть всё перечисленное ниже. Отсутствие любого пункта приведёт к ошибке на одном из этапов.

  • Сервер с Linux. Подойдёт Ubuntu 22.04/24.04 LTS, Debian 12 или RHEL 9. Все команды в статье приведены для Debian-семейства.
  • Установленный Nginx. Версия не ниже 1.24. Проверить: nginx -v. Если Nginx не установлен - apt update && apt install nginx -y.
  • Работающая панель 3x UI. Панель должна быть доступна локально. Стандартный порт - 54321. Проверьте: curl -I http://localhost:54321. Ответ 200 OK означает, что бэкенд жив.
  • Доменное имя. A-запись должна указывать на публичный IP вашего сервера. Для тестов можно использовать /etc/hosts на клиентской машине, но для Let's Encrypt нужен реальный DNS.
  • Права root или sudo. Конфигурация Nginx и запуск certbot требуют привилегий.

В этой статье мы используем тестовый стенд со следующими параметрами: Ubuntu 24.04, Nginx 1.26, панель 3x UI на порту 54321, домен panel.example.com. Заменяйте эти значения на свои при копировании конфигураций.

Базовая конфигурация обратного прокси

Начнём с минимальной рабочей конфигурации. Она перенаправляет HTTP-запросы с Nginx на локальный порт панели 3x UI. Создайте файл /etc/nginx/sites-available/3x-ui:

server {
    listen 80;
    server_name panel.example.com;

    location / {
        proxy_pass http://127.0.0.1:54321;
        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;
    }
}

Активируйте конфигурацию и перезагрузите Nginx:

ln -s /etc/nginx/sites-available/3x-ui /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

Разберём директивы. proxy_pass http://127.0.0.1:54321; - точка назначения трафика. Nginx принимает запрос на 80 порту и транслирует его на локальный адрес панели. Четыре заголовка proxy_set_header критичны: Host передаёт оригинальное доменное имя, чтобы панель знала, куда клиент обращался; X-Real-IP содержит IP клиента; X-Forwarded-For - цепочку прокси-серверов; X-Forwarded-Proto сообщает бэкенду, по какому протоколу пришёл запрос (http или https). Без этих заголовков панель 3x UI будет видеть все соединения как пришедшие с 127.0.0.1, что сломает логирование и работу некоторых функций.

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

Поведение proxy_pass зависит от наличия завершающего слеша в URI. Это частая причина ошибок 404 после настройки прокси. Рассмотрим два варианта:

  • proxy_pass http://127.0.0.1:54321; - Nginx передаёт URI без изменений. Запрос к /panel/inbounds уйдёт как /panel/inbounds.
  • proxy_pass http://127.0.0.1:54321/; - Nginx заменяет часть location на слеш. Если location /app/, а запрос пришёл на /app/inbounds, бэкенд получит /inbounds.

Для 3x UI используйте вариант без завершающего слеша. Панель ожидает полные пути, и обрезание URI приведёт к битым ссылкам на статические ресурсы и API-эндпоинты. Дополнительно убедитесь, что заголовок X-Forwarded-Proto передаётся - панель может использовать его для формирования абсолютных URL в ответах API.

Настройка поддержки WebSocket

3x UI использует WebSocket-соединения для мониторинга в реальном времени: графики трафика, статус подключений, логи. Без специальной настройки Nginx эти соединения будут обрываться или не устанавливаться вовсе. Прокси по умолчанию работает с HTTP/1.0, а WebSocket требует HTTP/1.1 и явного апгрейда соединения.

Добавьте в блок location / три директивы:

location / {
    proxy_pass http://127.0.0.1:54321;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    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;
}

proxy_http_version 1.1 принудительно включает HTTP/1.1 для соединения с бэкендом. proxy_set_header Upgrade $http_upgrade пробрасывает заголовок апгрейда от клиента. proxy_set_header Connection "upgrade" заменяет стандартный заголовок Connection на upgrade - именно это значение запускает механизм смены протокола. Если клиент не запрашивает WebSocket, заголовок Upgrade будет пустым, и Nginx корректно отработает обычный HTTP-запрос.

Проверка работы WebSocket описана в разделе «Тестирование и устранение неполадок». Сейчас важно запомнить: без этих трёх строк графики в панели будут статичными, а статус подключений перестанет обновляться.

Обеспечение безопасного доступа через HTTPS

Панель 3x UI передаёт учётные данные и управляет VPN-подключениями. Передача этой информации по открытому HTTP недопустима. Let's Encrypt предоставляет бесплатные SSL-сертификаты с автоматическим обновлением - интегрируем их в нашу конфигурацию.

Установка и настройка Certbot

Установите certbot и плагин для Nginx. На Ubuntu 24.04 это делается одной командой:

apt update && apt install certbot python3-certbot-nginx -y

Перед запуском certbot убедитесь, что базовая конфигурация из предыдущего раздела активна и домен panel.example.com резолвится в IP вашего сервера. Затем запустите мастер:

certbot --nginx -d panel.example.com

Certbot просканирует конфигурацию Nginx, найдёт блок server с соответствующим server_name и предложит выбор: редирект с HTTP на HTTPS или раздельный доступ. Выберите вариант с редиректом - это гарантирует, что все клиенты будут использовать шифрованное соединение. После подтверждения certbot самостоятельно пропишет пути к сертификатам в конфигурацию Nginx и добавит блок для редиректа.

Автоматическое обновление сертификата

Сертификаты Let's Encrypt действительны 90 дней. Certbot при установке создаёт systemd-таймер, который проверяет необходимость обновления дважды в сутки. Убедитесь, что таймер активен:

systemctl status certbot.timer

Для тестового запуска обновления выполните:

certbot renew --dry-run

Если команда завершилась без ошибок, автоматическое обновление работает. Никаких дополнительных действий не требуется - таймер обновит сертификат за 30 дней до истечения и перезагрузит Nginx.

Финальная конфигурация Nginx для 3x UI

Ниже - полный конфигурационный файл, объединяющий все настройки: HTTP-редирект, HTTPS с сертификатами Let's Encrypt, проксирование с заголовками и поддержку WebSocket. Скопируйте его в /etc/nginx/sites-available/3x-ui, заменив panel.example.com на ваш домен, и выполните nginx -t && systemctl reload nginx.

# Редирект с HTTP на HTTPS
server {
    listen 80;
    server_name panel.example.com;
    return 301 https://$host$request_uri;
}

# Основной HTTPS-сервер
server {
    listen 443 ssl http2;
    server_name panel.example.com;

    # Сертификаты Let's Encrypt
    ssl_certificate /etc/letsencrypt/live/panel.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/panel.example.com/privkey.pem;

    # Безопасные параметры SSL
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    # Проксирование на 3x UI
    location / {
        proxy_pass http://127.0.0.1:54321;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

Пояснения к дополнительным директивам: proxy_read_timeout и proxy_send_timeout установлены в 24 часа. Это предотвращает обрыв долгоживущих WebSocket-соединений при отсутствии трафика. Без этих параметров Nginx по умолчанию разрывает соединение через 60 секунд неактивности. Блок ssl_protocols и ssl_ciphers задаёт современный набор шифров - он совместим со всеми актуальными браузерами и проходит проверку на Qualys SSL Labs с оценкой A+. Подробнее о выборе шифров и настройке TLS читайте в статье Nginx HTTPS в 2026 году: TLS 1.3, Let's Encrypt и безопасная конфигурация.

Тестирование и устранение неполадок

После применения конфигурации проведите серию проверок. Они выявят проблемы до того, как с ними столкнутся пользователи.

Проверка доступности. Откройте браузер и перейдите по адресу https://panel.example.com. Вы должны увидеть страницу входа в 3x UI. Иконка замка в адресной строке подтверждает, что сертификат работает. Если страница не открывается - проверьте, слушает ли панель на 127.0.0.1:54321: ss -tlnp | grep 54321.

Проверка редиректа. Перейдите по http://panel.example.com. Вас должно автоматически перенаправить на HTTPS-версию. Код ответа - 301 Moved Permanently.

Проверка работы WebSocket

Откройте инструменты разработчика в браузере (F12), перейдите на вкладку Network и выберите фильтр WS. Обновите страницу панели 3x UI. В списке должны появиться соединения со статусом 101 Switching Protocols. Это подтверждает, что апгрейд до WebSocket прошёл успешно. Если вы видите статус 200 или соединения в фильтре WS отсутствуют - проверьте наличие директив proxy_http_version 1.1 и proxy_set_header Upgrade в конфигурации.

Типовые ошибки и их причины. Ошибка 502 Bad Gateway означает, что Nginx не может достучаться до бэкенда. Панель 3x UI не запущена или слушает на другом порту. Проверьте статус панели и соответствие порта в proxy_pass. Ошибка 504 Gateway Timeout возникает при зависании бэкенда - увеличьте proxy_read_timeout. Ошибки сертификата (NET::ERR_CERT_AUTHORITY_INVALID) появляются, если сертификат не был выпущен для этого домена или истёк - запустите certbot certificates для диагностики.

Логи Nginx - ваш главный инструмент отладки. Включите подробное логирование для проблемного location:

error_log /var/log/nginx/3x-ui-error.log debug;

После воспроизведения ошибки изучите лог. Записи о upstream prematurely closed connection указывают на падение бэкенда. SSL_do_handshake() failed сигнализирует о проблемах с сертификатом.

Дополнительные рекомендации по безопасности

Базовая конфигурация закрывает основные риски. Следующие меры усилят защиту и характерны для production-окружений.

Ограничение доступа по IP. Если панель 3x UI используется только из офиса или через VPN, заблокируйте все остальные адреса. Добавьте в блок location:

allow 203.0.113.0/24;  # IP офисной сети
allow 198.51.100.5;     # IP администратора
deny all;

Nginx проверит IP до передачи запроса бэкенду. Неавторизованные адреса получат 403 Forbidden.

Скрытие версии Nginx. В главном конфигурационном файле /etc/nginx/nginx.conf добавьте в секцию http: server_tokens off;. Это уберёт версию Nginx из заголовков ответа и страниц ошибок, усложняя fingerprinting.

Интеграция с fail2ban. Настройте фильтр для отслеживания неудачных попыток входа в 3x UI через логи Nginx. При превышении порога fail2ban заблокирует IP на уровне iptables. Это защитит панель от брутфорса эффективнее, чем встроенные механизмы.

Нестандартный порт SSH. Смените порт SSH с 22 на другой, если сервер доступен из интернета. Это не относится напрямую к Nginx, но снижает количество автоматических атак на сервер в целом. Для хостинга проектов, требующих гибкой облачной инфраструктуры, обратите внимание на облачные серверы Timeweb Cloud - они предоставляют VDS с мгновенным масштабированием ресурсов.

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

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

Поделиться:
Сохранить гайд? В закладки браузера