You rented a VPS in a country where Telegram is throttled at the network edge. The bot connects, holds for a few seconds, then drops. getUpdates returns nothing. Long polling silently dies. The classic temptation is to push the entire VPS through a VPN — and pay for it with broken apt updates, slower healthchecks, and metrics that now traverse two countries.
The narrower fix is to route only outbound to api.telegram.org through QPOL. With the CLI installed on the host you mark a single hostname as "tunnel" and leave everything else direct. apt, container pulls, Prometheus scrapes, S3 backups — all keep their normal path. Telegram traffic goes through the chosen QPOL node and back.
For multi-service stacks the cleanest pattern is a sidecar container. QPOL CLI runs alongside your bot container, exposes a SOCKS endpoint on a private network, and the bot SDK talks to it. No code changes in the bot itself — just an environment variable. When you redeploy, the sidecar moves with the bot.
A practical detail: pick a node in a country where Telegram considers traffic "boring" — typically a major European or Asian hub. Avoid exits in countries that themselves have unusual rules around Telegram, since those can have their own quirks on the API side.
If your bot needs stable outbound IP for webhooks (Telegram sends updates to a fixed URL), the public pool will rotate exits over time. For that case use a Personal server — one node, one outbound, no surprises. See the Personal server page.