Routing Telegram Traffic through SOCKS5 Proxy on Foreign VPS

A group of Python services interacting with the Telegram Bot API is hosted on a server in a region where direct access to api.telegram.org is restricted. To enable stable access to Telegram, a rented VPS in Germany (Hetzner) with a SOCKS5 proxy listening on port 1080 has been set up, routing all Telegram traffic through this node while other connections go directly.

Selective routing

The key technical solution is selective (split) routing: only requests to Telegram (long polling getUpdates, sendMessage, sendDocument, getFile, and file uploads) go through the proxy, while connections to PostgreSQL and Google API remain direct. This minimizes latency and avoids routing heavy traffic (uploads, files) through a foreign node unnecessarily. The socks5h scheme is used (instead of socks5): the 'h' suffix indicates that the domain name is resolved on the proxy side (remote DNS), circumventing DNS-level blocks and preventing DNS queries to Telegram from being exposed to the local resolver. SOCKS support in Python is provided by the PySocks library.

Two Telegram clients

The project features two Telegram clients, so the proxy is connected in two ways. For services using the pyTelegramBotAPI library, the configuration is centralized in a common module (proxy_config.py): it sets the global apihelper.proxy = {"http": ..., "https": ...} once and is imported by the service before polling starts — all outgoing library calls automatically go through the proxy. For services using pure requests, a more targeted approach is applied: a separate requests.Session is created exclusively for Telegram calls, where proxies are set, and importantly, trust_env = False is specified — this session ignores system environment variables (HTTP_PROXY/NO_PROXY, etc.), ensuring that the proxy is only applied to the Telegram session and does not 'leak' to requests to the database and Google, which are executed directly using regular requests.

Centralized configuration

The proxy configuration is centralized (single address and port for the node), simplifying server or port changes across all services from one point. This approach was gradually introduced and rolled out to all services interacting with Telegram.