#1134939 MTProto proxy did not work, connect loop

Package:
telegram-desktop
Source:
telegram-desktop
Description:
fast and secure messaging application
Submitter:
Nikolas Kyx
Date:
2026-05-01 20:25:02 UTC
Severity:
normal
Tags:
#1134939#5
Date:
2026-04-26 08:32:55 UTC
From:
To:
Steps to reproduce:
1) Use 5.7.2+ds-4 and connect to MTProxy without problems
2) Upgrade from ds-4 to ds-5, be happy about qt6 part
3) Now telegram could not connect to the same single working proxy,
while other devices sharing the same public IP can
4) "Try now" (retry) button cannot help either
5) Rollback to ds-4 and all is good

Nothing related in stdout/err.
#1134939#10
Date:
2026-04-27 15:27:59 UTC
From:
To:
Control: tag -1 unreproducible

Sorry, I cannot reproduce the bug you are reporting in a chroot environment
with Debian testing. In my case, an MTPROTO proxy works, Telegram Desktop of
version 5.7.2+ds-5 successfully connects to the server. Does this issue relate
to a specific type of proxy? Can you check SOCKS5 or HTTP proxy?
#1134939#17
Date:
2026-04-29 11:05:10 UTC
From:
To:
Ehh, no repro in your env is very sad, I still can distinguish clearly
between those two telegram versions to narrow down issues to the newer
one, MTProxy in question also talks well with all devices.
Checked SOCKS5, it works as usual.
I will investigate proxy logs and maybe handshake packets and come back here.
Maybe telegram does have some debug flag / config option with very
verbose logging?
#1134939#22
Date:
2026-04-30 05:08:05 UTC
From:
To:
TCP traffic capture shows that ds-5 is not sending any packets to
MTProxy IP. Btw, I'm using an EE-type proxy (secret starts with 'ee',
it mimics TLS handshake, i.e. plain web traffic). Have you tried using
such a proxy? I was able to spot Google DNS, Google LLC and CloudFlare
Inc ASes, also lesser known subnets, but not the proxy IP! So in my
case, ds-5 is not even trying to use a proxy actually. Tried to remove
and re-add that same proxy, but it did not help.
#1134939#27
Date:
2026-05-01 20:23:20 UTC
From:
To:
I also found nice log file log.txt in TelegramDesktop folder, looks
like the culprit in ds-5 is:
`Config Error: No 'Date' header received.`
So smth bad happens in SpecialConfigRequest::handleHeaderUnixtime (and
likely before that call).
I will investigate what is a "Special Config" and why it is being
obtained without proxy.
For now, I just want to load telegram in gdb, but gdb-add-index (that
is what happens on debug file loading anyway) for
telegram-desktop-dbgsym requires > 16 GB of RAM.