The investigation into connection stability revealed that the proxy service was not the source of the errors. Despite logs showing no errors over a nine-hour period, the system processed 2,415 client sessions and transferred 482 MB of data before experiencing connectivity drops.
Analysis identified a pattern where upstream connections were terminated after exactly 0.1 seconds. Data transfers during these sessions were limited to approximately 800 bytes upstream and 8–28 bytes downstream. These issues occurred exclusively on the direct connection stage.
Technical inspection of the network path to Telegram showed that out of 1,270 tested addresses, only one responds via TCP. This address belongs to a service node rather than a data center and enforces a silent limit on concurrent connections.
The client application attempts to open 13 sockets simultaneously. The service node accepts only seven of these, while the remaining six are dropped without sending any response packets. This behavior remains invisible to standard application logs.
