Run MTProto Proxy on Port 443 with Nginx on a Single VPS

You can set up a Telegram MTProto proxy and a website to share port 443 on a single VPS by using SNI routing with Nginx Stream's ssl_preread module, which analyzes the TLS handshake to direct traffic to either the web server on 127.0.0.1:8443 or the MTProto backend on 127.0.0.1:4433.

Why Run a Telegram MTProto Proxy on Port 443 When It's Already Used by a Website?

In an environment of widespread network traffic restrictions and blocking, especially in regions with active censorship, using standard and commonly accessible ports becomes not just a convenience, but a critical necessity. Port 443, traditionally used for HTTPS traffic, is the least susceptible to filtering and blocking because most encrypted web traffic passes through it. If your Telegram MTProto proxy operates on a non-standard port, such as 8888 or 9999, there's a high probability that this port will be blocked by an internet service provider (ISP) or a state firewall. Moving MTProto to port 443 significantly increases its availability and resilience to blocking, as it "masquerades" as regular HTTPS traffic.

The Problem of Blocking and the Importance of Standard Ports

Many ISPs and state filtering systems actively use deep packet inspection (DPI) to identify and block traffic that does not conform to standard protocols on standard ports. For example, if traffic on port 443 is detected as non-HTTPS, or traffic on port 80 as non-HTTP, this can trigger a block. MTProto, although encrypted, has its characteristic patterns. However, if it operates on port 443, its traffic blends with a vast volume of legitimate HTTPS traffic, making it harder to identify and block. This is especially relevant for masking proxy traffic.

Resource Efficiency and Camouflage: Proxy and Website on One Server

Running an MTProto proxy and a website on a single VPS offers a dual benefit. Firstly, it provides resource efficiency. Instead of renting two separate VPS instances (one for the website, another for the proxy), you can use one powerful server. This reduces rental costs and simplifies infrastructure management. Secondly, it enhances MTProto's camouflage. If a fully functional website operates on the same IP address as the proxy, with traffic flowing through the same port 443, it creates the appearance of a normal, legitimate server. In case of inspection or traffic analysis, the presence of a real decoy website makes the proxy less noticeable and suspicious. This is particularly effective when the website uses an SSL certificate from a well-known Certificate Authority, such as Let's Encrypt, which lends even greater credibility to the traffic.

How SNI Routing Works: Sharing Port 443 for Two Services (Telegram Proxy & Website)

The core problem is that port 443 can only be listened to by one process on the operating system. If you want both a web server (Nginx, Apache) and an MTProto proxy to listen on this port, a conflict arises. The solution lies in Server Name Indication (SNI) technology and the use of a frontend proxy that can analyze the initial stage of the TLS handshake without decrypting the entire traffic.

What is SNI and How It Helps with Routing

SNI (Server Name Indication) is an extension to the TLS protocol that allows a client (browser, Telegram client) to specify the hostname (domain name) of the server it is trying to connect to, even before the full TLS handshake begins. This information is transmitted unencrypted in the ClientHello header. A frontend server listening on port 443 can intercept this header, analyze the SNI name, and based on it, decide where to redirect the subsequent encrypted traffic: to the web server backend (e.g., Nginx, Apache) or to the MTProto proxy backend.

Thus, to the client, it appears as if it is connecting to a regular HTTPS server via a domain name (for the website) or to an MTProto proxy via an IP address/domain name (for the proxy). The frontend server acts as an intelligent dispatcher, directing traffic to the correct service, which operates on another, usually local, port. This is a key aspect for implementing the "telegram proxy 443 port" scheme alongside a website.

Interaction Scheme: Frontend, Backends, and Certificates

A typical scheme looks like this:

Client (browser or Telegram client) initiates a TLS connection to your VPS on port 443.
Frontend proxy (Nginx Stream or SNIProxy) intercepts this connection.
The frontend proxy analyzes the ClientHello header, extracting the SNI name.
- If the SNI name matches your website's domain (e.g., mysite.com), the frontend redirects traffic to the local port where your web server (Nginx/Apache) is listening, for example, on 127.0.0.1:8443.
- If the SNI name is absent (which is typical for MTProto if the client connects by IP) or matches a special domain you might assign for MTProto (e.g., proxy.mysite.com), the frontend redirects traffic to the local port where the MTProto proxy is listening, for example, on 127.0.0.1:4433.
Backend server (web server or MTProto proxy) receives the traffic, processes it, and responds to the client.

It's important that the web server on 127.0.0.1:8443 must have its own SSL certificate for mysite.com, while the MTProto proxy on 127.0.0.1:4433 does not require its own SSL certificate, as the TLS handshake is handled by the frontend, and MTProto uses its own encryption protocol. However, for greater credibility and resilience to blocking, MTProto can be configured with a fake TLS layer using a certificate from a real website. This makes MTProto traffic indistinguishable from regular HTTPS at the TLS handshake level.

Looking for a reliable server for your projects?

VPS from $10/month and dedicated servers from $9/month with NVMe, DDoS protection, and 24/7 support.

View Offers →

Choosing a Frontend for SNI Routing: Nginx Stream vs. SNIProxy for Telegram Proxy 443

To implement SNI routing on port 443, you have two main options: Nginx Stream with the ssl_preread module or a specialized SNIProxy. Both solutions are effective but have their own characteristics and use cases.

Nginx Stream with ssl_preread Module: Flexibility and Performance

Nginx, renowned for its performance and flexibility as a web server and reverse proxy, can also act as a TCP/UDP proxy through its Stream module. With the addition of the ssl_preread module, Nginx Stream becomes a powerful tool for SNI routing. This module allows Nginx to analyze the SNI name from the TLS ClientHello without decrypting the entire TLS traffic. This means Nginx operates at the TCP level, simply forwarding encrypted bytes to the correct backend based on SNI.

Advantages of Nginx Stream:

Versatility: If Nginx is already used on your VPS for a web server, its Stream module allows for centralized proxy management.
Performance: Nginx is known for its ability to handle a large number of concurrent connections with minimal overhead.
Flexibility: Extensive configuration options, including load balancing, timeouts, connection limits, and other advanced settings.
SSL/TLS offloading: Although Nginx itself does not decrypt traffic for SNI routing, it can be configured for SSL offloading for web traffic if needed.

Disadvantages:

Requires Nginx to be compiled with the --with-stream_ssl_preread_module module if it's not included by default in your build (often included in modern distributions).
Configuration can be more complex for beginners compared to simpler proxies.

SNIProxy: A Lightweight Solution for Specific Tasks

SNIProxy is a specialized proxy server designed specifically for SNI routing. It is much lighter than Nginx and does not have such broad functionality, but it excels at its primary task: SNI analysis and traffic redirection. This is an ideal solution if you only need SNI routing and don't want to use Nginx for other purposes or prefer minimalistic solutions.

Advantages of SNIProxy:

Lightweight: Consumes significantly fewer system resources compared to Nginx.
Simplicity: SNIProxy configuration is usually simpler and more straightforward.
Specialization: Optimized for its specific task, which can be an advantage in certain scenarios.

Disadvantages:

Fewer additional features compared to Nginx (no load balancing, advanced logs, etc.).
Less common, which can make it harder to find ready-made solutions or community support.

For most users, especially those already using Nginx for a web server, Nginx Stream is the preferred choice due to its versatility and performance. However, if you are looking for a maximally lightweight and simple solution exclusively for SNI routing, SNIProxy will also be an excellent option.

Quick pick

Need a dedicated server?

Bare metal with NVMe in 70+ locations — configure and order in minutes.

Browse servers

Step-by-Step Guide: Setting Up Nginx Stream for Telegram MTProto Proxy and a Website on Port 443

Let's look at a detailed step-by-step setup of Nginx Stream for the simultaneous operation of an MTProto proxy and a website on a single VPS, using port 443. This configuration will allow your VPS to efficiently serve both services, increasing their resilience to blocking and saving resources.

VPS Preparation: Installing Nginx and Let's Encrypt

First, ensure your VPS from Valebyte.com is ready. You will need a clean installation of Ubuntu Server (e.g., 22.04 LTS) or Debian. To start, let's update the system and install the necessary packages:

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

Make sure Nginx is installed with the stream_ssl_preread module. In most modern distributions, it is included by default. You can check this as follows:

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

If the output contains --with-stream_ssl_preread_module, then everything is in order. If not, you will have to compile Nginx from source or find a package with this module.

For our website, we will need a domain name (e.g., mywebsite.com). Ensure that the A record for your domain points to your VPS's IP address.

Configuring Nginx Stream for SNI Routing

Now let's proceed with Nginx configuration. Open the /etc/nginx/nginx.conf file and add the stream section outside the http section. If the stream section already exists, use it.

# Добавьте это в начало файла, после директивы '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 и т.d.)

Configuration Explanation:

map $ssl_preread_server_name $name: This directive creates a variable $name, whose value depends on the SNI name obtained from the TLS handshake.
hostnames;: Enables hostname matching support.
mywebsite.com web;: If the SNI name is mywebsite.com, the variable $name takes the value web.
default mtproto;: If the SNI name is not found or does not match any of the listed ones, traffic will go to mtproto. This is critical for MTProto, as many clients connect by IP and do not transmit SNI, or MTProto by its nature may not use it.
upstream web_backend: Defines a group of servers for web traffic. In our case, this is local port 8443.
upstream mtproto_backend: Defines a group of servers for MTProto. This is local port 4433.
listen 443 reuseport;: Nginx listens on port 443. The reuseport directive allows multiple processes to listen on the same port, which can be useful for performance, but in this case, the port itself is key.
ssl_preread on;: Enables the ssl_preread module, which allows Nginx to analyze SNI.
proxy_pass $name_backend;: The most important directive. It redirects traffic to the corresponding upstream depending on the value of the $name variable.

Setting Up the MTProto Server (mtg)

For MTProto, we will use mtg (Telegram MTProto Proxy). Install it if you haven't already:

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

Now, run mtg on local port 4433. It's crucial that MTProto listens only on the local interface (127.0.0.1), as Nginx Stream will proxy traffic to it. Create a secret and run:

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

Replace your_ad_tag with your advertising tag, if you have one. Write down the generated SECRET, you will need it for client connections. To make mtg start automatically on reboot, it's best to create a systemd service. Create the file /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

Don't forget to replace YOUR_SECRET_HERE and YOUR_AD_TAG_HERE with your values. Then:

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

Ensure that MTProto is running and listening on 127.0.0.1:4433.

Setting Up the Web Server (Nginx HTTP)

Now let's configure Nginx as a web server that will listen on local port 8443.

Create a new configuration file for your site, for example, /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;
    }

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

Create a directory for your site and a test file:

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

Enable the site and check the Nginx configuration:

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

If there are no errors, restart Nginx:

sudo systemctl restart nginx

Obtaining and Managing Let's Encrypt SSL Certificates

For your website mywebsite.com, a valid SSL certificate is required. We will use Certbot with Let's Encrypt. Since Nginx Stream has already occupied port 443, Certbot will not be able to use its standard --nginx or --standalone method on port 443. Instead, we can temporarily disable Nginx Stream or use the --webroot method if you already have a working web server on port 80 (which Certbot can use for validation). Or, the simplest way: temporarily modify Nginx Stream to proxy Certbot requests to port 80.

Method 1: Using --webroot

If you already have Nginx HTTP running on port 80 (which is common for Certbot) to redirect HTTP to HTTPS, you can use --webroot. For this, ensure your Nginx HTTP listens on port 80 and has a location /.well-known/acme-challenge/ directive. If not, temporarily add this to Nginx HTTP on port 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;
    }
}

Reload Nginx, then:

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

After obtaining the certificates, Certbot will automatically configure them for your Nginx HTTP. If you are using the Nginx Stream configuration as described above, Certbot will not be able to automatically update certificates for the web server, as it listens on port 8443. You will need to manually specify the certificate paths in the mywebsite.com configuration, as shown above.

Method 2: Temporarily Disable Nginx Stream and Use --nginx (less convenient)

Comment out or remove the stream section from nginx.conf.
Restart Nginx: sudo systemctl restart nginx.

Obtain a certificate for mywebsite.com by configuring Nginx for HTTP on port 80 (temporary configuration):

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

Reload Nginx.

Run Certbot: sudo certbot --nginx -d mywebsite.com -d www.mywebsite.com.
After successfully obtaining certificates, restore the Nginx Stream configuration in nginx.conf and the web server configuration on port 8443.
Reload Nginx.

Automatic Certificate Renewal:

Certbot automatically creates a cron job for certificate renewal. Ensure it is working:

sudo systemctl status certbot.timer

If certificates are renewed, Nginx needs to pick them up. If you are using Nginx HTTP on port 8443, after Certbot renews the certificates, you will need to reload Nginx for it to load the new certificates:

sudo systemctl reload nginx

Add this command to your Certbot renewal script if it doesn't do it automatically.

Setting Up SNIProxy for Telegram MTProto Proxy and a Website (Alternative to Nginx Stream)

If you prefer SNIProxy instead of Nginx Stream, here's how to set it up. SNIProxy is a more lightweight and specialized solution.

Installation and Basic SNIProxy Configuration

Install SNIProxy from the repositories:

sudo apt update
sudo apt install -y sniproxy

The main SNIProxy configuration file is located at /etc/sniproxy.conf. Open it and configure it as follows:

# /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
    }
}

Configuration Explanation:

user sniproxy: The user under which SNIProxy will run.
listener 443 { proto tls ... }: SNIProxy will listen on TCP port 443, expecting TLS traffic.
table { ... }: Defines routing rules based on SNI.
mywebsite.com 127.0.0.1:8443: If the SNI name is mywebsite.com, traffic is redirected to local port 8443 (where your Nginx HTTP is listening).
.* 127.0.0.1:4433: This is the default rule. If the SNI name does not match any of the listed ones (or is absent), traffic is redirected to local port 4433 (where MTProto is listening).

After configuring the file, restart SNIProxy:

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

Ensure that SNIProxy is running and working without errors. After this, your Nginx HTTP (on 127.0.0.1:8443) and MTProto (on 127.0.0.1:4433) will receive traffic via SNIProxy on port 443.

Additional Parameters and Nuances

SNIProxy, unlike Nginx Stream, does not provide as many fine-grained settings, but for basic SNI routing, this is usually sufficient. Ensure that your backends (Nginx HTTP and MTProto) are configured to listen only on local interfaces (127.0.0.1 or [::1]) on their dedicated ports (8443 and 4433 respectively) to avoid conflicts and enhance security.

Also, when using SNIProxy, Certbot will work without issues, as SNIProxy does not interfere with the certificate acquisition process (Certbot typically uses port 80 for validation, while SNIProxy listens on 443).

Troubleshooting Common Issues with Telegram MTProto Proxy and Website on Port 443

Setting up SNI routing can be tricky, and errors happen. It's important to know how to diagnose problems to resolve them quickly.

Verifying SNI Routing Operation

To ensure that SNI routing is working correctly, perform the following checks:

Check website accessibility: Open your domain https://mywebsite.com in a browser. If the site loads and displays an HTTPS lock, traffic is successfully routed to your web server. You can also use curl:
```
curl -v https://mywebsite.com
        
```
Look for information about the TLS handshake and page content in the output.
Check MTProto accessibility: Try connecting to your MTProto proxy using a Telegram client. If the connection is established and you can send/receive messages, then MTProto is working.
For a more technical check, you can use openssl s_client. If you have configured MTProto with a fake TLS layer mimicking your site, you can try connecting to it by specifying your site's SNI:
```
openssl s_client -connect ВАШ_IP:443 -servername mywebsite.com
        
```
If SNI routing is working, you should receive a response from your web server. If you do not specify -servername or specify something else, you should receive "garbage" or a timeout, which would mean that the traffic went to MTProto. MTProto does not speak TLS, so openssl will not be able to establish a connection with it.
Check listening ports: Ensure that Nginx (or SNIProxy) is listening on port 443, and your web server and MTProto are listening only on local ports (e.g., 8443 and 4433) on 127.0.0.1.
```
sudo ss -tulpn | grep 443
        sudo ss -tulpn | grep 8443
        sudo ss -tulpn | grep 4433
        
```
The output should show that Nginx (or sniproxy) is listening on *:443, and nginx (for the site) and mtg-proxy are listening on 127.0.0.1:8443 and 127.0.0.1:4433 respectively.
Check logs: Examine Nginx logs (/var/log/nginx/access.log, error.log) and MTProto (if you have configured logging or are using systemctl status mtg-proxy.service). Errors in the logs can indicate the source of the problem.

Common Configuration Errors and Their Solutions

Nginx Stream fails to start or throws errors:
- Problem: nginx -t reports syntax errors, or Nginx fails to start.
- Solution: Carefully check the syntax of nginx.conf, especially the stream section. Ensure all braces are closed, directives are spelled correctly, and there are no typos. Verify that Nginx is compiled with the stream_ssl_preread module.
Website inaccessible via HTTPS:
- Problem: The browser displays an "ERR_CONNECTION_REFUSED" or "ERR_SSL_PROTOCOL_ERROR" error.
- Solution:
  - Ensure that Nginx HTTP is listening on the correct local port (e.g., 127.0.0.1:8443) and has valid SSL certificates.
  - Verify that Nginx Stream correctly routes traffic for your domain to web_backend (mywebsite.com web; in the map).
  - Ensure that Certbot has successfully obtained and renewed certificates for mywebsite.com, and Nginx HTTP is using the current paths to them.
MTProto fails to connect:
- Problem: The Telegram client cannot connect to the proxy.
- Solution:
  - Verify that mtg-proxy is running and listening on 127.0.0.1:4433.
  - Ensure that the proxy secret in the Telegram client matches the secret with which mtg-proxy was started.
  - Verify that Nginx Stream correctly routes default traffic (or traffic by SNI name for the proxy) to mtproto_backend (default mtproto;).
  - Ensure there are no firewalls (e.g., UFW) blocking incoming connections on port 443 or outgoing connections to local ports.
"bind: Address already in use" errors:
- Problem: When starting Nginx or SNIProxy, you see an error that port 443 is already in use.
- Solution: Only one process can listen on the external interface on port 443. Ensure that you are running only Nginx Stream OR SNIProxy. If you are switching between them, stop the previous service before starting the new one. Also, ensure that your web server (Nginx HTTP) is listening only on the local interface (127.0.0.1:8443), not on 0.0.0.0:443.

Quick pick

Need a dedicated server?

Bare metal with NVMe in 70+ locations — configure and order in minutes.

Browse servers

Optimization and Security: Choosing a VPS for Your Telegram MTProto Proxy and Website

Choosing the right VPS for simultaneously hosting an MTProto proxy and a website is critically important for performance and reliability. Valebyte.com offers various plans that can be suitable for this task.

Resource Requirements for Combined Workloads

The load on the VPS will depend on the number of concurrent MTProto proxy users and your website's traffic. Below is an approximate table of resource requirements:

For 50 concurrent MTProto connections and moderate web traffic, a VPS with 4 vCPU, 8 GB RAM, and an 80 GB NVMe disk is sufficient.

Concurrent MTProto Users	vCPU	RAM (GB)	Disk (GB, Type)	Network Port	Estimated Valebyte.com Price ($/month, 2024)
Up to 10	1-2	2-4	40-60 NVMe/SSD	1 Gbps	From $5.99
10-50	2-4	4-8	60-80 NVMe/SSD	1 Gbps	From $9.99
50-150	4-6	8-16	80-160 NVMe	1-10 Gbps	From $19.99
150-300+	6-8+	16-32+	160-320+ NVMe	10 Gbps	From $39.99

Important Notes:

CPU: MTProto proxy and Nginx (especially with SSL) can be CPU-intensive. Choose a VPS with a sufficient number of cores.
RAM: Nginx, web servers (PHP-FPM, Python applications), and MTProto itself consume RAM. 4 GB is a good start, but more will be needed for higher loads.
Disk: NVMe disks are significantly faster than SSDs, which is critical for website loading speed and overall system responsiveness. For MTProto itself, disk speed is less critical, but for a web server, it's very important.
Network: A high-speed network port (1 Gbps or 10 Gbps) with unmetered bandwidth or a generous limit is essential for a proxy, as users will actively use it.

Enhancing Your Configuration's Security

The security of a combined VPS server requires special attention:

Firewall (UFW/iptables): Configure UFW or iptables to allow only necessary ports. Allow incoming connections only on 443 (for Nginx/SNIProxy) and 22 (for SSH, but preferably with IP restriction).

sudo ufw default deny incoming
        sudo ufw default allow outgoing
        sudo ufw allow 22/tcp # Только для вашего IP, если возможно
        sudo ufw allow 443/tcp
        sudo ufw enable

Using Local Ports: Ensure that MTProto and the web server listen only on 127.0.0.1. This prevents direct external access to them, forcing all traffic to pass through the frontend proxy.
Software Updates: Regularly update the operating system and all installed software (Nginx, Certbot, mtg-proxy) to receive the latest security patches.
Strong Passwords and SSH Keys: Use complex passwords and, if possible, only SSH keys for server access. Disable password login for root.
Fail2ban: Install and configure Fail2ban to protect SSH from brute-force attacks.
SSL/TLS: Maintain up-to-date SSL certificates for your site and use modern TLS protocols (TLSv1.2, TLSv1.3) with strong ciphers.

Frequently Asked Questions

Here you will find answers to the most common questions regarding the joint operation of MTProto and a website on a single VPS via port 443.

Can Nginx Stream be used for protocols other than MTProto?

Yes, Nginx Stream is very flexible. It can route any TCP/UDP traffic based on various criteria, including SNI for TLS, or simply by IP address/port. For example, you can configure it to route traffic to other VPN services (e.g., OpenVPN, WireGuard), game servers, or databases, if they use TLS and transmit SNI. The main thing is that Nginx Stream can determine where to redirect traffic without fully decrypting it.

How to renew Let's Encrypt SSL certificates if port 443 is occupied by Nginx Stream?

If port 443 is constantly occupied by Nginx Stream, Certbot will not be able to use the --nginx or --standalone method for validation. The best way is to use the --webroot method. For this, ensure that your Nginx web server (which listens on port 80 for HTTP to HTTPS redirection) has access to the directory that Certbot uses for temporary files (e.g., /var/www/mywebsite.com for .well-known/acme-challenge/). Run Certbot with the command: sudo certbot certonly --webroot -w /var/www/mywebsite.com -d mywebsite.com -d www.mywebsite.com. After renewal, Certbot will automatically reload Nginx to apply the new certificates.

Will running MTProto affect my website's performance?

Yes, any additional load on the VPS will affect performance. An MTProto proxy, especially with a large number of active users (more than 50-100), can consume significant CPU and network bandwidth resources. Your website will also consume CPU and RAM. It's important to choose a VPS plan with a sufficient number of vCPUs (4+ cores), RAM (8+ GB), and a high-speed NVMe disk. Regularly monitor resource usage (CPU, RAM, network) with tools like htop, iftop, or Grafana/Prometheus to scale your VPS in time if necessary.

Is an SSL certificate required for an MTProto proxy?

The MTProto proxy itself does not require an SSL certificate in the traditional sense of TLS, as it uses its own encryption protocol. However, to enhance camouflage and bypass blocking, some MTProto implementations (e.g., mtg) support a so-called "fake TLS" or "TLS-wrap," which allows MTProto to mimic a real website's TLS handshake using its certificate. This makes MTProto traffic even more indistinguishable from regular HTTPS at the initial handshake level. In our scheme, Nginx Stream handles the first TLS handshake and routes the traffic, so the MTProto backend can operate without its own SSL certificate.

What are the advantages of Valebyte.com for hosting such a configuration?

Valebyte.com offers powerful VPS instances with fast NVMe disks and high-speed network channels (up to 10 Gbps), which is ideal for resource-intensive applications such as an MTProto proxy and a web server. Our plans start from $5.99 per month for a configuration sufficient for a small project and easily scale up to more powerful solutions with 8+ vCPUs and 32+ GB RAM for larger workloads. We provide reliable infrastructure that allows for efficient traffic management and ensures stable operation of your services 24/7.

Conclusion

Using SNI routing on port 443 to co-host a Telegram MTProto proxy and a website on a single VPS is an effective and economical solution for bypassing blocking and optimizing infrastructure. Nginx Stream with the ssl_preread module or SNIProxy allows for elegant traffic separation, directing it to the appropriate local backends. This configuration not only reduces costs but also enhances MTProto's camouflage, making its traffic indistinguishable from regular HTTPS.

SSD NVMe

Ready to launch your VPS?

NVMe VPS with 60-second activation: full root access, 20+ locations, pay by card or crypto.

Choose a Plan