Please implement TCP-Splitting

[rlqd]

Please add ability to host own decoy website instead of mimicking public websites (which is now automatically detected and blocked by cenzorship in some cases).

It's set up the following way:

• Web server is running nearby (on other port or even another server) with valid ssl certificate for the user-owned domain.
• Domain is pointed to server with mtproxy running on port 443
• mtproxy is acting as a proxy with a valid secret, otherwise it passes tcp trafic through to the webserver, thus when opened in a browser, it shows a fully functioning website

For more details, see how telemt proxy does it https://github.com/telemt/telemt/blob/main/docs/fronting-splitting/TLS-F-TCP-S.ru.md

[dvershinin]

This is now implemented in commit 6eadcce. The -D flag accepts host:port in addition to bare domain names.

Usage examples:

# Local nginx backend on port 8443
mtproto-proxy ... -D 127.0.0.1:8443

# IPv6 backend
mtproto-proxy ... -D [::1]:8443

# Domain with custom port
mtproto-proxy ... -D mydomain.com:8443

# Existing usage still works (defaults to port 443)
mtproto-proxy ... -D google.com

Typical setup: Run nginx on a non-standard port with a real certificate for your domain, point the domain's DNS to your server, and run MTProxy on port 443 with -D 127.0.0.1:<nginx-port>. Non-MTProxy connections get proxied to your nginx, making the server indistinguishable from a normal HTTPS site.

Docker users can set EE_DOMAIN=127.0.0.1:8443 (or any host:port).

[rlqd]

Thank you very much for implementing the change!
I've tried it out, and here's a few more things to keep in mind:

• It's required to force tls 1.3 in nginx config
• When using 127.0.0.1:<nginx-port>, client can't connect with ee secret (maybe because I have domain not as a default website in nginx). What I did: I've added 127.0.0.1 mywebsite.com entry to /etc/hosts and used -D mywebsite.com:<nginx-port>

But when configured, it works like a charm 🥇

[dvershinin]

Thanks for the detailed feedback, @rlqd! Quick follow-up question to help us improve the documentation:

When you switched from -D 127.0.0.1:<nginx-port> to -D mywebsite.com:<nginx-port> with /etc/hosts — was that because your nginx was bound to 127.0.0.1 only (loopback)? In other words, was the /etc/hosts entry needed so that MTProxy would connect to loopback where nginx was actually listening, rather than to the public IP (where nginx wouldn't be reachable on that port)?

Also, could you share the relevant nginx listen and ssl_protocols directives you used? We'd like to include a working example in the README.

[rlqd]

When you switched from -D 127.0.0.1: to -D mywebsite.com: with /etc/hosts — was that because your nginx was bound to 127.0.0.1 only (loopback)?

Yes

Also, could you share the relevant nginx listen and ssl_protocols directives you used?

server {
        listen 127.0.0.1:1443 ssl default_server;
        server_name mywebsite.com;

        ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem;

        # Important: use TLS 1.3
        ssl_protocols TLSv1.3;
        ssl_prefer_server_ciphers off;

        root /var/www/html;

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

Note that I'm using certbot with DNS-01 challenge to maintain valid letsencrypt certificate.
I'm not sure if http challenge will work with this setup.

[dvershinin]

Thanks for the detailed config, @rlqd! We've updated the README with a setup guide based on your feedback — including the default_server directive, TLS 1.3 requirement, /etc/hosts workaround for loopback-bound nginx, and the certbot DNS-01 note. Glad it's working well!