Telegram videos\images problem with xray vless tcp reality

[devopg]

I am using 'vless tcp Reality' with the standard settings provided by x3ui. My clients include both Android\Iphone phones and laptops. More than 15 different complex applications that I use work perfectly, including streaming platforms like YouTube and Twitch. The only application that works poorly is TELEGRAM, as it periodically fails to load videos/images, while text, chat updates, etc., have no issues.

If we look at it from a technical perspective, it turns out that the protocols Telegram uses to communicate with the servers are functioning correctly. However, I believe that videos and images are stored on some Amazon S3 servers. Is it really that 'xray/vless tcp Reality' cannot work with S3?

What are the possible solutions to the problems with videos/images Telegram?

[Seerafimm]

i have same problem, it would've been nice to figure it out

[peromax]

I don't think Xray-core is the root of the problem, as I have tens of thousands of users and no one has complained about this issue, and I've never encountered the problem in Telegram with connected by xray vless tls reality.
I recommend you compare your libraries and their versions to understand what's common and find the source of issue, but it's definitely not Xray-core.

[Seerafimm]

its strange because i just installed it on vps with Debian 12. works great, except this strange telegram under android situation. i don't think package comparsion would help as it runs in docker container with 'em preinstalled

[DifferentialOrange]

Yeah, I have the same issue on different devices (Android, Linux PC)

[PLASTn]

I have same problem, after restart xray service telegram work well.
I create cron job to restart the service.
It hard to understand what root of problem. But only telegram work bad for me

[Seerafimm]

i solved it actually, for me it was to lower a bit the MTU value in client. 1280 to 1140 as example. That's because of large files try to send them partially as big chunks, that's how i understood this as*. So the lower value prevents big data chunks to slice in half so it loads media faster.

[PLASTn]

i solved it actually, for me it was to lower a bit the MTU value in client. 1280 to 1140 as example. That's because of large files try to send them partially as big chunks, that's how i understood this as*. So the lower value prevents big data chunks to slice in half so it loads media faster.

1500 was install by default on my client. I tried to change that different values but didn't see difference.

[dimzon]

try to use sniffing for route only.

[PLASTn]

What do you mean?
Why it should help?

[dimzon]

well, sniffing will override original destination IP using SNI from tls hello. maybe telegram client sends it's request to "better" CDN node and XRay replace it's IP . just try to use "route only" to keep original destination IP untouched. Xray makes dns request to SNI and override destination IP. Sometimes it resolve to "good" IP sometimes to "not good". Also XRay cache IP resolution - that's why restarting xray may help you

[PLASTn]

Nothing changed