MTProto на 443 порту рядом с сайтом: один VPS для прокси и веба

Для запуска MTProto прокси и веб-сайта на одном VPS через один 443 порт, когда другие порты блокируются, применяется маршрутизация на основе Server Name Indication (SNI), позволяющая фронтенд-серверу, например Nginx Stream с модулем ssl_preread, анализировать TLS-хендшейк и перенаправлять трафик либо на веб-сервер, либо на MTProto-бэкенд, работающие на локальных портах.

Зачем MTProto нужен на 443 порту, если он уже занят сайтом?

В условиях повсеместных ограничений и блокировок сетевого трафика, особенно в регионах с активной цензурой, использование стандартных и общедоступных портов становится не просто удобством, а критической необходимостью. Порт 443, традиционно используемый для HTTPS-трафика, наименее подвержен фильтрации и блокировкам, поскольку через него проходит большая часть зашифрованного веб-трафика. Если ваш Telegram MTProto proxy работает на нестандартном порту, например, 8888 или 9999, существует высокая вероятность, что этот порт будет заблокирован интернет-провайдером или государственным фаерволом. Перенос MTProto на 443 порт значительно повышает его доступность и устойчивость к блокировкам, поскольку он "маскируется" под обычный HTTPS-трафик.

Проблема блокировок и важность стандартных портов

Многие провайдеры и государственные системы фильтрации активно используют глубокий анализ пакетов (DPI) для выявления и блокировки трафика, который не соответствует стандартным протоколам на стандартных портах. Например, если на порту 443 обнаруживается трафик, который не является HTTPS, или на порту 80 трафик, не являющийся HTTP, это может стать сигналом для блокировки. MTProto, хотя и зашифрован, имеет свои характерные паттерны. Однако, если он работает на 443 порту, его трафик смешивается с огромным объемом легитимного HTTPS-трафика, что затрудняет его идентификацию и блокировку. Это особенно актуально для маскировки прокси-трафика.

Экономия ресурсов и маскировка: прокси и сайт на одном сервере

Запуск MTProto proxy и веб-сайта на одном VPS имеет двойную выгоду. Во-первых, это экономия ресурсов. Вместо того чтобы арендовать два отдельных VPS (один для сайта, другой для прокси), вы можете использовать один мощный сервер. Это сокращает затраты на аренду и упрощает управление инфраструктурой. Во-вторых, это повышает маскировку MTProto. Если на том же IP-адресе, что и прокси, работает полноценный веб-сайт, трафик к которому идет через тот же 443 порт, это создает видимость обычного, легитимного сервера. В случае проверки или анализа трафика, наличие реального сайта-прикрытия делает прокси менее заметным и подозрительным. Это особенно эффективно, когда сайт использует SSL-сертификат от известного центра сертификации, такого как Let's Encrypt, что придает трафику еще большую правдоподобность.

Принцип работы SNI-роутинга: как один 443 порт обслуживает два сервиса

Суть проблемы заключается в том, что порт 443 может быть занят только одним процессом в операционной системе. Если вы хотите, чтобы и веб-сервер (Nginx, Apache), и MTProto proxy слушали этот порт, возникает конфликт. Решение кроется в технологии Server Name Indication (SNI) и использовании фронтенд-прокси, который может анализировать начальный этап TLS-рукопожатия, не расшифровывая весь трафик.

Что такое SNI и как он помогает в маршрутизации

SNI (Server Name Indication) — это расширение протокола TLS, которое позволяет клиенту (браузеру, Telegram-клиенту) указывать имя хоста (доменное имя) сервера, к которому он пытается подключиться, еще до начала полноценного TLS-рукопожатия. Эта информация передается в незашифрованном виде в заголовке ClientHello. Фронтенд-сервер, слушающий порт 443, может перехватить этот заголовок, проанализировать SNI-имя и на его основе принять решение, куда перенаправить дальнейший зашифрованный трафик: на бэкенд веб-сервера (например, Nginx, Apache) или на бэкенд MTProto proxy.

Таким образом, для клиента все выглядит так, будто он подключается к обычному HTTPS-серверу по доменному имени (для сайта) или к MTProto proxy по IP-адресу/доменному имени (для прокси). Фронтенд-сервер действует как интеллектуальный диспетчер, направляя трафик в нужный сервис, работающий на другом, обычно локальном, порту. Это ключевой момент для реализации схемы "mtproto 443 порт" совместно с веб-сайтом.

Схема взаимодействия: фронтенд, бэкенды и сертификаты

Типичная схема выглядит следующим образом:

Клиент (браузер или Telegram-клиент) инициирует TLS-подключение к вашему VPS на порт 443.
Фронтенд-прокси (Nginx Stream или SNIProxy) перехватывает это подключение.
Фронтенд-прокси анализирует заголовок ClientHello, извлекая SNI-имя.
- Если SNI-имя соответствует домену вашего сайта (например, mysite.com), фронтенд перенаправляет трафик на локальный порт, где слушает ваш веб-сервер (Nginx/Apache), например, на 127.0.0.1:8443.
- Если SNI-имя отсутствует (что характерно для MTProto, если клиент подключается по IP) или соответствует специальному домену, который вы можете назначить для MTProto (например, proxy.mysite.com), фронтенд перенаправляет трафик на локальный порт, где слушает MTProto proxy, например, на 127.0.0.1:4433.
Бэкенд-сервер (веб-сервер или MTProto proxy) принимает трафик, обрабатывает его и отвечает клиенту.

Важно, что веб-сервер на 127.0.0.1:8443 должен иметь свой SSL-сертификат для mysite.com, а MTProto proxy на 127.0.0.1:4433 не требует своего SSL-сертификата, так как TLS-хендшейк обрабатывается на стороне фронтенда, а MTProto использует свой собственный протокол шифрования. Однако для большей правдоподобности и устойчивости к блокировкам, MTProto может быть настроен с фиктивным TLS-слоем, использующим сертификат от реального сайта. Это делает трафик MTProto неотличимым от обычного HTTPS на уровне TLS-хендшейка.

Ищете надёжный сервер для ваших проектов?

VPS от $10/мес и выделенные серверы от $9/мес с NVMe, DDoS-защитой и поддержкой 24/7.

Смотреть предложения →

Выбор фронтенда для SNI-маршрутизации: Nginx Stream vs. SNIProxy

Для реализации SNI-роутинга на 443 порту у вас есть два основных варианта: Nginx Stream с модулем ssl_preread или специализированный SNIProxy. Оба решения эффективны, но имеют свои особенности и области применения.

Nginx Stream с модулем ssl_preread: гибкость и производительность

Nginx, известный своей производительностью и гибкостью в качестве веб-сервера и обратного прокси, также может выступать в роли TCP/UDP прокси через свой модуль Stream. С добавлением модуля ssl_preread, Nginx Stream становится мощным инструментом для SNI-маршрутизации. Этот модуль позволяет Nginx анализировать SNI-имя из TLS ClientHello без расшифровки всего TLS-трафика. Это означает, что Nginx работает на уровне TCP, просто перенаправляя зашифрованные байты на нужный бэкенд на основе SNI.

Преимущества Nginx Stream:

Универсальность: Если Nginx уже используется на вашем VPS для веб-сервера, его Stream-модуль позволяет централизовать управление проксированием.
Производительность: Nginx славится своей способностью обрабатывать большое количество одновременных соединений с минимальными накладными расходами.
Гибкость: Широкие возможности конфигурации, включая балансировку нагрузки, таймауты, лимиты соединений и другие продвинутые настройки.
SSL/TLS offloading: Хотя для SNI-роутинга сам Nginx не расшифровывает трафик, он может быть настроен на SSL offloading для веб-трафика, если это необходимо.

Недостатки:

Требует компиляции Nginx с модулем --with-stream_ssl_preread_module, если он не включен по умолчанию в вашей сборке (часто включен в современных дистрибутивах).
Конфигурация может быть сложнее для новичков по сравнению с простыми прокси.

SNIProxy: легковесное решение для специфических задач

SNIProxy — это специализированный прокси-сервер, который разработан именно для SNI-маршрутизации. Он гораздо легче Nginx и не имеет такого широкого функционала, но отлично справляется со своей основной задачей: анализ SNI и перенаправление трафика. Это идеальное решение, если вам нужен только SNI-роутинг и вы не хотите использовать Nginx для других целей или предпочитаете минималистичные решения.

Преимущества SNIProxy:

Легковесность: Потребляет значительно меньше системных ресурсов по сравнению с Nginx.
Простота: Конфигурация SNIProxy обычно более проста и прямолинейна.
Специализация: Оптимизирован для своей задачи, что может быть преимуществом в некоторых сценариях.

Недостатки:

Меньше дополнительных функций по сравнению с Nginx (нет балансировки, продвинутых логов и т.д.).
Менее распространен, что может затруднить поиск готовых решений или поддержку сообщества.

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

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Пошаговая настройка Nginx Stream для MTProto и сайта

Рассмотрим детальную пошаговую настройку Nginx Stream для совместной работы MTProto proxy и веб-сайта на одном VPS, используя порт 443. Эта конфигурация позволит вашему VPS эффективно обслуживать оба сервиса, повышая их устойчивость к блокировкам и экономию ресурсов.

Подготовка VPS: установка Nginx и Let's Encrypt

Прежде всего, убедитесь, что ваш VPS от Valebyte.com готов к работе. Вам потребуется чистая установка Ubuntu Server (например, 22.04 LTS) или Debian. Для начала обновим систему и установим необходимые пакеты:

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

Убедитесь, что Nginx установлен с модулем stream_ssl_preread. В большинстве современных дистрибутивов он включен по умолчанию. Проверить можно так:

nginx -V 2>&1 | grep --color stream_ssl_preread_module

Если вывод содержит --with-stream_ssl_preread_module, то все в порядке. Если нет, вам придется скомпилировать Nginx из исходников или найти пакет с этим модулем.

Для нашего веб-сайта нам понадобится доменное имя (например, mywebsite.com). Убедитесь, что A-запись вашего домена указывает на IP-адрес вашего VPS.

Конфигурация Nginx Stream для SNI-маршрутизации

Теперь приступим к настройке Nginx. Откройте файл /etc/nginx/nginx.conf и добавьте секцию stream вне секции http. Если секция stream уже существует, используйте ее.

# Добавьте это в начало файла, после директивы 'user nginx;' или 'user www-data;'

stream {
    map $ssl_preread_server_name $name {
        hostnames;

        # Домен вашего веб-сайта
        mywebsite.com           web;
        www.mywebsite.com       web;

        # Домен для MTProto (опционально, если не используете IP)
        proxy.mywebsite.com     mtproto;

        # Если SNI не предоставлен или не соответствует ни одному из доменов,
        # по умолчанию направляем на MTProto. Это важно, так как Telegram
        # часто не отправляет SNI при подключении по IP.
        default                 mtproto;
    }

    upstream web_backend {
        server 127.0.0.1:8443; # Локальный порт для HTTPS трафика сайта
    }

    upstream mtproto_backend {
        server 127.0.0.1:4433; # Локальный порт для MTProto proxy
    }

    server {
        listen 443 reuseport;
        listen [::]:443 reuseport; # Для IPv6

        ssl_preread on;
        proxy_pass $name_backend;
        proxy_timeout 30s;
        proxy_connect_timeout 5s;
    }
}

# ... остальная часть nginx.conf (секция http и т.д.)

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

map $ssl_preread_server_name $name: Эта директива создает переменную $name, значение которой зависит от SNI-имени, полученного из TLS-хендшейка.
hostnames;: Включает поддержку сопоставления по доменным именам.
mywebsite.com web;: Если SNI-имя mywebsite.com, переменная $name принимает значение web.
default mtproto;: Если SNI-имя не найдено или не соответствует ни одному из перечисленных, трафик пойдет на mtproto. Это критично для MTProto, так как многие клиенты подключаются по IP и не передают SNI, или же MTProto по своей природе может его не использовать.
upstream web_backend: Определяет группу серверов для веб-трафика. В нашем случае это локальный порт 8443.
upstream mtproto_backend: Определяет группу серверов для MTProto. Это локальный порт 4433.
listen 443 reuseport;: Nginx слушает порт 443. Директива reuseport позволяет нескольким процессам слушать один и тот же порт, что может быть полезно для производительности, но в данном случае ключевой является сам порт.
ssl_preread on;: Включает модуль ssl_preread, который позволяет Nginx анализировать SNI.
proxy_pass $name_backend;: Самая важная директива. Она перенаправляет трафик на соответствующий upstream в зависимости от значения переменной $name.

Настройка MTProto-сервера (mtg)

Для MTProto мы будем использовать mtg (Telegram MTProto Proxy). Установите его, если еще не сделали:

sudo apt install -y snapd
sudo snap install mtg-proxy

Теперь запустите mtg на локальном порту 4433. Важно, чтобы MTProto слушал только на локальном интерфейсе (127.0.0.1), так как Nginx Stream будет проксировать к нему трафик. Создайте секрет и запустите:

SECRET=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)
sudo mtg-proxy.mtg run -p 127.0.0.1:4433 -s $SECRET --tag your_ad_tag

Замените your_ad_tag на свой рекламный тег, если он у вас есть. Запишите сгенерированный SECRET, он понадобится для подключения клиентов. Чтобы mtg запускался автоматически при перезагрузке, лучше создать systemd-сервис. Создайте файл /etc/systemd/system/mtg-proxy.service:

[Unit]
Description=MTProto Proxy
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/snap/bin/mtg-proxy.mtg run -p 127.0.0.1:4433 -s YOUR_SECRET_HERE --tag YOUR_AD_TAG_HERE
Restart=on-failure

[Install]
WantedBy=multi-user.target

Не забудьте заменить YOUR_SECRET_HERE и YOUR_AD_TAG_HERE на ваши значения. Затем:

sudo systemctl daemon-reload
sudo systemctl enable mtg-proxy.service
sudo systemctl start mtg-proxy.service
sudo systemctl status mtg-proxy.service

Убедитесь, что MTProto запущен и слушает на 127.0.0.1:4433.

Настройка веб-сервера (Nginx HTTP)

Теперь настроим Nginx как веб-сервер, который будет слушать на локальном порту 8443.

Создайте новый файл конфигурации для вашего сайта, например, /etc/nginx/sites-available/mywebsite.com:

server {
    listen 127.0.0.1:8443 ssl http2;
    listen [::1]:8443 ssl http2; # Для IPv6

    server_name mywebsite.com www.mywebsite.com;

    ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;

    root /var/www/mywebsite.com;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    # Дополнительные настройки логирования, кэширования и т.д.
}

Создайте директорию для вашего сайта и тестовый файл:

sudo mkdir -p /var/www/mywebsite.com
echo "Hello from mywebsite.com!" | sudo tee /var/www/mywebsite.com/index.html

Включите сайт и проверьте конфигурацию Nginx:

sudo ln -s /etc/nginx/sites-available/mywebsite.com /etc/nginx/sites-enabled/
sudo nginx -t

Если ошибок нет, перезагрузите Nginx:

sudo systemctl restart nginx

Получение и управление SSL-сертификатами Let's Encrypt

Для вашего сайта mywebsite.com необходим действующий SSL-сертификат. Мы будем использовать Certbot с Let's Encrypt. Поскольку Nginx Stream уже занял 443 порт, Certbot не сможет использовать свой стандартный метод --nginx или --standalone на 443 порту. Вместо этого мы можем временно отключить Nginx Stream или использовать метод --webroot, если у вас уже есть работающий веб-сервер на 80 порту (который Certbot может использовать для валидации). Или, самый простой способ: временно модифицировать Nginx Stream, чтобы он проксировал запросы Certbot на порт 80.

Способ 1: Использование --webroot

Если у вас на 80 порту уже работает Nginx HTTP (что обычно для Certbot) для перенаправления HTTP на HTTPS, вы можете использовать --webroot. Для этого убедитесь, что ваш Nginx HTTP слушает 80 порт и имеет директиву location /.well-known/acme-challenge/. Если нет, временно добавьте это в Nginx HTTP на 80 порту:

server {
    listen 80;
    listen [::]:80;
    server_name mywebsite.com www.mywebsite.com;

    location /.well-known/acme-challenge/ {
        root /var/www/mywebsite.com; # Или любой другой доступный путь
    }

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

Перезагрузите Nginx, затем:

sudo certbot certonly --webroot -w /var/www/mywebsite.com -d mywebsite.com -d www.mywebsite.com

После получения сертификатов, Certbot автоматически настроит их для вашего Nginx HTTP. Если вы используете конфигурацию Nginx Stream, как описано выше, то Certbot не сможет автоматически обновить сертификаты для веб-сервера, поскольку он слушает на 8443 порту. Вам нужно будет вручную указать пути к сертификатам в конфигурации mywebsite.com, как показано выше.

Способ 2: Временно отключить Nginx Stream и использовать --nginx (менее удобно)

Закомментируйте или удалите секцию stream из nginx.conf.
Перезагрузите Nginx: sudo systemctl restart nginx.

Получите сертификат для mywebsite.com, настроив Nginx для HTTP на 80 порту (временная конфигурация):

server {
            listen 80;
            server_name mywebsite.com www.mywebsite.com;
            location / {
                return 301 https://$host$request_uri;
            }
        }

Перезагрузите Nginx.

Запустите Certbot: sudo certbot --nginx -d mywebsite.com -d www.mywebsite.com.
После успешного получения сертификатов, восстановите конфигурацию Nginx Stream в nginx.conf и конфигурацию веб-сервера на 8443 порту.
Перезагрузите Nginx.

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

Certbot автоматически создает задание cron для обновления сертификатов. Убедитесь, что оно работает:

sudo systemctl status certbot.timer

Если сертификаты обновляются, Nginx должен их подхватить. Если вы используете Nginx HTTP на 8443 порту, после обновления сертификатов Certbot'ом, вам нужно будет перезагрузить Nginx, чтобы он загрузил новые сертификаты:

sudo systemctl reload nginx

Добавьте эту команду в скрипт обновления Certbot, если он не делает это автоматически.

Настройка SNIProxy для MTProto и сайта (альтернативный вариант)

Если вы предпочитаете SNIProxy вместо Nginx Stream, вот как его настроить. SNIProxy является более легковесным и специализированным решением.

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

Установите SNIProxy из репозиториев:

sudo apt update
sudo apt install -y sniproxy

Основной файл конфигурации SNIProxy находится по адресу /etc/sniproxy.conf. Откройте его и настройте следующим образом:

# /etc/sniproxy.conf

user sniproxy
pidfile /var/run/sniproxy.pid

# Логирование (опционально)
accesslog {
    filename /var/log/sniproxy/access.log
    # format "%t %h %p %s %T" # Пример формата
}
errorlog {
    filename /var/log/sniproxy/error.log
    # level error # Уровень логирования
}

# Слушаем входящие соединения на порту 443
listener 443 {
    proto tls
    table {
        # Маршрутизация для вашего веб-сайта
        mywebsite.com 127.0.0.1:8443
        www.mywebsite.com 127.0.0.1:8443

        # Маршрутизация для MTProto (если используется домен)
        proxy.mywebsite.com 127.0.0.1:4433

        # Правило по умолчанию для MTProto, если SNI отсутствует или не соответствует
        .* 127.0.0.1:4433
    }
}

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

user sniproxy: От имени какого пользователя будет работать SNIProxy.
listener 443 { proto tls ... }: SNIProxy будет слушать TCP-порт 443, ожидая TLS-трафик.
table { ... }: Определяет правила маршрутизации на основе SNI.
mywebsite.com 127.0.0.1:8443: Если SNI-имя mywebsite.com, трафик перенаправляется на локальный порт 8443 (где слушает ваш Nginx HTTP).
.* 127.0.0.1:4433: Это правило по умолчанию. Если SNI-имя не соответствует ни одному из перечисленных (или отсутствует), трафик перенаправляется на локальный порт 4433 (где слушает MTProto).

После настройки файла конфигурации, перезапустите SNIProxy:

sudo systemctl restart sniproxy
sudo systemctl enable sniproxy
sudo systemctl status sniproxy

Убедитесь, что SNIProxy запущен и работает без ошибок. После этого, ваши Nginx HTTP (на 127.0.0.1:8443) и MTProto (на 127.0.0.1:4433) будут получать трафик через SNIProxy на порту 443.

Дополнительные параметры и нюансы

SNIProxy, в отличие от Nginx Stream, не предоставляет столько тонких настроек, но для базовой SNI-маршрутизации этого обычно достаточно. Убедитесь, что ваши бэкенды (Nginx HTTP и MTProto) настроены на прослушивание только локальных интерфейсов (127.0.0.1 или [::1]) на своих выделенных портах (8443 и 4433 соответственно), чтобы избежать конфликтов и повысить безопасность.

Также, при использовании SNIProxy, Certbot будет работать без проблем, так как SNIProxy не вмешивается в процесс получения сертификатов (Certbot обычно использует 80 порт для валидации, а SNIProxy слушает 443).

Диагностика и устранение типовых проблем

Настройка SNI-роутинга может быть непростой, и ошибки случаются. Важно уметь диагностировать проблемы, чтобы быстро их устранить.

Проверка работы SNI-роутинга

Чтобы убедиться, что SNI-роутинг работает корректно, выполните следующие проверки:

Проверка доступности веб-сайта: Откройте ваш домен https://mywebsite.com в браузере. Если сайт загружается и отображает HTTPS-замок, значит, трафик успешно маршрутизируется на ваш веб-сервер. Вы также можете использовать curl:
```
curl -v https://mywebsite.com
        
```
Ищите в выводе информацию о TLS-хендшейке и содержимом страницы.
Проверка доступности MTProto: Попробуйте подключиться к вашему MTProto proxy с помощью Telegram-клиента. Если подключение устанавливается и вы можете отправлять/получать сообщения, значит, MTProto работает.
Для более технической проверки можно использовать openssl s_client. Если вы настроили MTProto с фиктивным TLS-слоем, имитирующим ваш сайт, вы можете попробовать подключиться к нему с указанием SNI вашего сайта:
```
openssl s_client -connect ВАШ_IP:443 -servername mywebsite.com
        
```
Если SNI-роутинг работает, вы должны получить ответ от вашего веб-сервера. Если вы не указываете -servername или указываете что-то другое, вы должны получить "мусор" или таймаут, что будет означать, что трафик пошел в MTProto. MTProto не говорит на TLS, поэтому openssl не сможет установить с ним соединение.
Проверка прослушиваемых портов: Убедитесь, что Nginx (или SNIProxy) слушает порт 443, а ваш веб-сервер и MTProto слушают только локальные порты (например, 8443 и 4433) на 127.0.0.1.
```
sudo ss -tulpn | grep 443
        sudo ss -tulpn | grep 8443
        sudo ss -tulpn | grep 4433
        
```
Вывод должен показать, что Nginx (или sniproxy) слушает на *:443, а nginx (для сайта) и mtg-proxy слушают на 127.0.0.1:8443 и 127.0.0.1:4433 соответственно.
Проверка логов: Изучите логи Nginx (/var/log/nginx/access.log, error.log) и MTProto (если вы настроили логирование или используете systemctl status mtg-proxy.service). Ошибки в логах могут указать на источник проблемы.

Частые ошибки конфигурации и их решения

Nginx Stream не запускается или выдает ошибки:
- Проблема: nginx -t выдает синтаксические ошибки, или Nginx не запускается.
- Решение: Внимательно проверьте синтаксис nginx.conf, особенно секцию stream. Убедитесь, что все скобки закрыты, директивы написаны правильно и нет опечаток. Проверьте, что Nginx скомпилирован с модулем stream_ssl_preread.
Веб-сайт недоступен по HTTPS:
- Проблема: Браузер выдает ошибку "ERR_CONNECTION_REFUSED" или "ERR_SSL_PROTOCOL_ERROR".
- Решение:
  - Убедитесь, что Nginx HTTP слушает на правильном локальном порту (например, 127.0.0.1:8443) и имеет корректные SSL-сертификаты.
  - Проверьте, что Nginx Stream правильно маршрутизирует трафик для вашего домена на web_backend (mywebsite.com web; в map).
  - Убедитесь, что Certbot успешно получил и обновил сертификаты для mywebsite.com, и Nginx HTTP использует актуальные пути к ним.
MTProto не подключается:
- Проблема: Telegram-клиент не может подключиться к прокси.
- Решение:
  - Проверьте, что mtg-proxy запущен и слушает на 127.0.0.1:4433.
  - Убедитесь, что секрет прокси в Telegram-клиенте соответствует секрету, с которым запущен mtg-proxy.
  - Проверьте, что Nginx Stream правильно маршрутизирует трафик по умолчанию (или по SNI-имени для прокси) на mtproto_backend (default mtproto;).
  - Убедитесь, что нет фаерволов (например, UFW), блокирующих входящие соединения на 443 порт или исходящие на локальные порты.
Ошибки "bind: Address already in use":
- Проблема: При запуске Nginx или SNIProxy, вы видите ошибку, что порт 443 уже занят.
- Решение: Только один процесс может слушать на внешнем интерфейсе на порту 443. Убедитесь, что у вас работает только Nginx Stream ИЛИ SNIProxy. Если вы переключаетесь между ними, остановите предыдущий сервис перед запуском нового. Также убедитесь, что ваш веб-сервер (Nginx HTTP) слушает только на локальном интерфейсе (127.0.0.1:8443), а не на 0.0.0.0:443.

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Оптимизация и безопасность: как выбрать VPS для прокси и веба

Выбор правильного VPS для одновременного хостинга MTProto proxy и веб-сайта критически важен для производительности и надежности. Valebyte.com предлагает различные тарифы, которые могут подойти для этой задачи.

Требования к ресурсам для комбинированной нагрузки

Нагрузка на VPS будет зависеть от количества одновременных пользователей MTProto proxy и трафика вашего веб-сайта. Ниже приведена ориентировочная таблица требований к ресурсам:

Для 50 одновременных подключений MTProto и умеренного веб-трафика достаточно 4 vCPU, 8 GB RAM и NVMe-диска на 80 GB.

Одновременных пользователей MTProto	vCPU	RAM (GB)	Диск (GB, тип)	Сетевой порт	Ориентировочная цена Valebyte.com ($/мес, 2024)
До 10	1-2	2-4	40-60 NVMe/SSD	1 Gbps	От 5.99$
10-50	2-4	4-8	60-80 NVMe/SSD	1 Gbps	От 9.99$
50-150	4-6	8-16	80-160 NVMe	1-10 Gbps	От 19.99$
150-300+	6-8+	16-32+	160-320+ NVMe	10 Gbps	От 39.99$

Важные замечания:

CPU: MTProto proxy и Nginx (особенно с SSL) могут быть CPU-интенсивными. Выбирайте VPS с достаточным количеством ядер.
RAM: Nginx, веб-серверы (PHP-FPM, Python-приложения) и сам MTProto потребляют RAM. 4 GB — хороший старт, но для большей нагрузки потребуется больше.
Диск: NVMe-диски значительно быстрее SSD, что критично для скорости загрузки сайта и общей отзывчивости системы. Для MTProto сам по себе диск не так важен, но для веб-сервера — очень.
Сеть: Высокоскоростной сетевой порт (1 Gbps или 10 Gbps) с неограниченным трафиком или большим лимитом необходим для прокси, так как пользователи будут активно его использовать.

Повышение безопасности вашей конфигурации

Безопасность объединенного VPS-сервера требует особого внимания:

Фаервол (UFW/iptables): Настройте UFW или iptables для разрешения только необходимых портов. Разрешите входящие соединения только на 443 (для Nginx/SNIProxy) и 22 (для SSH, но лучше с ограничением по IP).
```
sudo ufw default deny incoming
        sudo ufw default allow outgoing
        sudo ufw allow 22/tcp # Только для вашего IP, если возможно
        sudo ufw allow 443/tcp
        sudo ufw enable
        
```
Использование локальных портов: Убедитесь, что MTProto и веб-сервер слушают только на 127.0.0.1. Это предотвращает прямой доступ к ним извне, обязывая весь трафик проходить через фронтенд-прокси.
Обновление ПО: Регулярно обновляйте операционную систему и все установленное ПО (Nginx, Certbot, mtg-proxy), чтобы получать последние исправления безопасности.
Надежные пароли и SSH-ключи: Используйте сложные пароли и, по возможности, только SSH-ключи для доступа к серверу. Отключите вход по паролю для root.
Fail2ban: Установите и настройте Fail2ban для защиты SSH от брутфорс-атак.
SSL/TLS: Поддерживайте актуальные SSL-сертификаты для вашего сайта и используйте современные протоколы TLS (TLSv1.2, TLSv1.3) с сильными шифрами.

Часто задаваемые вопросы

Здесь вы найдете ответы на наиболее распространенные вопросы, касающиеся совместной работы MTProto и веб-сайта на одном VPS через 443 порт.

Можно ли использовать Nginx Stream для других протоколов, кроме MTProto?

Да, Nginx Stream очень гибок. Он может маршрутизировать любой TCP/UDP трафик на основе различных критериев, включая SNI для TLS, или просто по IP-адресу/порту. Например, вы можете настроить его для маршрутизации трафика к другим VPN-сервисам (например, OpenVPN, WireGuard), игровым серверам или базам данных, если они используют TLS и передают SNI. Главное, чтобы Nginx Stream мог определить, куда перенаправлять трафик, без его полной расшифровки.

Как обновить SSL-сертификаты Let's Encrypt, если 443 порт занят Nginx Stream?

Если 443 порт постоянно занят Nginx Stream, Certbot не сможет использовать метод --nginx или --standalone для валидации. Лучший способ – использовать метод --webroot. Для этого убедитесь, что ваш веб-сервер Nginx (который слушает на 80 порту для перенаправления HTTP на HTTPS) имеет доступ к директории, которую Certbot использует для временных файлов (например, /var/www/mywebsite.com для .well-known/acme-challenge/). Запустите Certbot с командой: sudo certbot certonly --webroot -w /var/www/mywebsite.com -d mywebsite.com -d www.mywebsite.com. После обновления Certbot автоматически перезагрузит Nginx, чтобы применить новые сертификаты.

Повлияет ли работа MTProto на производительность моего веб-сайта?

Да, любая дополнительная нагрузка на VPS будет влиять на производительность. MTProto proxy, особенно при большом количестве активных пользователей (более 50-100), может потреблять значительные ресурсы CPU и сетевого канала. Ваш веб-сайт также будет потреблять CPU и RAM. Важно правильно выбрать тариф VPS с достаточным количеством vCPU (от 4 ядер), RAM (от 8 GB) и высокоскоростным NVMe-диском. Регулярно мониторьте использование ресурсов (CPU, RAM, сеть) с помощью таких инструментов, как htop, iftop или Grafana/Prometheus, чтобы вовремя масштабировать VPS при необходимости.

Нужен ли SSL-сертификат для MTProto proxy?

Сам MTProto proxy не требует SSL-сертификата в традиционном понимании TLS, так как использует собственный протокол шифрования. Однако для повышения маскировки и обхода блокировок, некоторые реализации MTProto (например, mtg) поддерживают так называемый "fake TLS" или "TLS-wrap", который позволяет MTProto имитировать TLS-хендшейк реального сайта, используя его сертификат. Это делает трафик MTProto еще более неотличимым от обычного HTTPS на уровне начального рукопожатия. В нашей схеме Nginx Stream обрабатывает первый TLS-хендшейк и маршрутизирует трафик, поэтому MTProto-бэкенд может работать без собственного SSL-сертификата.

Какие преимущества у Valebyte.com для размещения такой конфигурации?

Valebyte.com предлагает мощные VPS с быстрыми NVMe-дисками и высокоскоростными сетевыми каналами (до 10 Gbps), что идеально подходит для ресурсоемких приложений, таких как MTProto proxy и веб-сервер. Наши тарифы начинаются от 5.99$ в месяц за конфигурацию, достаточную для небольшого проекта, и легко масштабируются до более мощных решений с 8+ vCPU и 32+ GB RAM для крупных нагрузок. Мы предоставляем надежную инфраструктуру, которая позволяет эффективно управлять трафиком и обеспечивать стабильную работу ваших сервисов 24/7.

Выводы

Использование SNI-роутинга на 443 порту для совместного размещения MTProto proxy и веб-сайта на одном VPS – это эффективное и экономичное решение для обхода блокировок и оптимизации инфраструктуры. Nginx Stream с модулем ssl_preread или SNIProxy позволяют элегантно разделить трафик, направляя его на соответствующие локальные бэкенды. Эта конфигурация не только снижает затраты, но и повышает маскировку MTProto, делая его трафик неотличимым от обычного HTTPS.

SSD NVMe

Готовы запустить свой VPS?

NVMe VPS с активацией за 60 секунд: полный root-доступ, 20+ локаций, оплата картой или криптой.

Выбрать тариф