You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 5, 2026. It is now read-only.
Users report that in --direct mode, some media in channels fails to fully load, while normal ME relay mode works fine (reported in #64).
Analysis
The direct relay code (tcp_direct_relay()) was audited — no data loss or corruption bugs found. The relay does a clean zero-copy move from input buffer to output queue. DC table covers all 5 production DCs, media DCs (negative IDs) are correctly handled, and TCP keepalive is enabled on DC sockets.
The root cause is inherent to direct mode's architecture vs ME relays:
Aspect
ME Relay Mode
Direct Mode
Network path to DCs
ME relays are close to DCs, optimized links
Proxy server connects from wherever it is
Connection failure
ME may retry/reroute internally
Both sides closed immediately
DC addressing
ME knows all DC IPs dynamically
1 hardcoded IPv4 per DC, no IPv6
Flow control
ME handles buffering/backpressure
No backpressure mechanism
Most likely causes
Network quality: proxy server's path to Telegram DC IPs may have higher latency/loss — media downloads (large, long-lived) are more affected than chat messages
No retry: DC connection drop = immediate close of both sides, no recovery
Single IP per DC: one hardcoded IPv4 address, no alternatives
No IPv6: some networks have better IPv6 paths to Telegram
DPI/ISP interference: direct obfuscated2 connections (no TLS) to well-known Telegram IPs may be throttled
What's been done
Added diagnostic logging and stats counters (commit 1eb2fa8):
Per-connection close logging: DC number, duration, which side (client vs DC) initiated close
direct_dc_connections_failed — connections that failed to establish (unknown DC, socket error)
direct_dc_connections_dc_closed — connections closed by the DC side (not the client)
Exposed in plain text stats (:8888), Prometheus metrics, and verbose logs (-v 1)
Planned improvements
Add IPv6 DC addresses with fallback
Multiple IPs per DC for redundancy
Connection retry with backoff on DC connection failure
Configurable DC address table (runtime override)
Information needed
To diagnose specific cases, we need:
Server location (country/provider)
Verbose logs (-v 2) captured during media loading failure
Which type of media fails (images, videos, large files, specific channels?)
Problem
Users report that in
--directmode, some media in channels fails to fully load, while normal ME relay mode works fine (reported in #64).Analysis
The direct relay code (
tcp_direct_relay()) was audited — no data loss or corruption bugs found. The relay does a clean zero-copy move from input buffer to output queue. DC table covers all 5 production DCs, media DCs (negative IDs) are correctly handled, and TCP keepalive is enabled on DC sockets.The root cause is inherent to direct mode's architecture vs ME relays:
Most likely causes
What's been done
Added diagnostic logging and stats counters (commit 1eb2fa8):
direct_dc_connections_failed— connections that failed to establish (unknown DC, socket error)direct_dc_connections_dc_closed— connections closed by the DC side (not the client):8888), Prometheus metrics, and verbose logs (-v 1)Planned improvements
Information needed
To diagnose specific cases, we need:
-v 2) captured during media loading failureRelated: #64