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

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

Содержание

• Зачем нужен обратный прокси для 3x UI
• Предварительные требования и исходные данные
• Базовая конфигурация обратного прокси
• Настройка поддержки WebSocket
• Обеспечение безопасного доступа через HTTPS
• Финальная конфигурация Nginx для 3x UI
• Тестирование и устранение неполадок
• Дополнительные рекомендации по безопасности
• Частые вопросы (FAQ)

Зачем нужен обратный прокси для 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 требуют привилегий.

Чек-лист готовности:

• ☐ Nginx установлен и запущен (systemctl status nginx)
• ☐ Панель 3x UI отвечает на http://localhost:54321
• ☐ A-запись домена указывает на IP сервера
• ☐ Порт 80 и 443 открыты в файрволе
• ☐ Есть доступ по SSH с правами root или sudo

В этой статье мы используем тестовый стенд со следующими параметрами: 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 в конфигурации.

Типовые ошибки и их причины. Ниже — таблица с самыми частыми проблемами при настройке прокси для 3x UI:

Логи 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.

Частые вопросы (FAQ)

Почему не работает WebSocket после настройки прокси?

В 90% случаев проблема в отсутствии трёх директив: proxy_http_version 1.1, proxy_set_header Upgrade $http_upgrade и proxy_set_header Connection "upgrade". Проверьте, что все три строки присутствуют в блоке location /. Также убедитесь, что таймауты proxy_read_timeout и proxy_send_timeout установлены не менее чем на 3600s для долгоживущих соединений.

Как обновить сертификат Let's Encrypt вручную?

Выполните команду certbot renew. Если хотите проверить механизм без реального обновления — используйте certbot renew --dry-run. После успешного обновления Nginx перезагрузится автоматически благодаря хуку, который certbot добавляет при установке.

Что делать, если панель 3x UI доступна локально, но через Nginx отдаёт 502?

Проверьте, на каком адресе слушает панель. Если она привязана к 127.0.0.1, а в proxy_pass указан другой адрес — Nginx не сможет подключиться. Выполните ss -tlnp | grep 54321 и убедитесь, что адрес и порт совпадают с конфигурацией.

Можно ли использовать один сертификат для нескольких доменов?

Да, Let's Encrypt поддерживает мультидоменные сертификаты. При запуске certbot укажите все домены через -d: certbot --nginx -d panel.example.com -d zabbix.example.com. Сертификат будет выпущен для всех перечисленных доменов.

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