TLS with VPN does not work

[ariestop]

The official MTProxy works via VPN, but MTProxyMax doesn't.
Both are on fake TLS, one domain, one port.
Assumption: The TLS fingerprint is different from the official one and is detected by DPI.
I have to set up split tunneling to make it work. Which isn't very convenient...

[SamNet-dev]

Interesting report. A few questions to narrow this down:

1. Which VPN? (WireGuard, OpenVPN, commercial VPN app?) — some VPNs do their own TLS inspection or modify packets in ways that break the fake-TLS handshake.

2. What do you mean by "doesn't work"? Connection timeout, or does it connect but then drop? Any errors in docker logs mtproxymax?

3. Same device, same Telegram client? When you say the official MTProxy works via VPN but MTProxyMax doesn't — are you testing both from the same device/app at the same time, just switching the proxy link?

4. Which country/ISP? This helps identify if there's known DPI behavior.

The TLS handshake in telemt (the engine) is standard fake-TLS — it presents a cert matching your configured domain, same as the official implementation. But if a VPN is intercepting or re-wrapping TLS, the extra layer could cause issues specific to how the VPN handles it.

Split tunneling working confirms the VPN itself is interfering with the connection, not DPI blocking it.

[ariestop]

Thanks for the reply.
I'm using any of four applications: Happ, v2ray, v2box, or streisand over the VLESS protocol.

I'll describe the logic behind the problem:

1. If we use MTProto from the official repository and deploy it to the default server, then with the VPN application enabled or disabled, the proxy connection is established.

2. If we deploy MTProxyMax on a different server and try to connect, it keeps repeating "connected-connected-connected" in an endless loop.
   Disabling the VPN application and everything is fine. If I configure split tunneling, everything connects as well.

3. There are no errors in the logs, which is the problem. I can't pinpoint the cause... Not in the Docker logs, nor in the network connections. It says everything is fine, but in reality, it's not :)

4. Yes, the connection is waiting, but nothing has connected.

5. Country: Russia, any provider.

6. Different devices, different Telegram clients.

Yes, I'm testing on both the same and different devices.

[ariestop]

I installed Telemt on another server—exactly the same problem. So it's an engine issue...

[ariestop]

The Telmet author cites the guide https://github.com/telemt/telemt/blob/main/docs/XRAY-SINGBOX-ROUTING.ru.md
Although it's unclear why one would create their own domain and resolve to it if the whole point is to grab a popular domain nearby in a subnet as a fake.