Cloudflare proxy and Worker connections can now use operator-selected edge
IPs instead of accepting whichever anycast edge DNS assigns.
Why
Cloudflare's DNS choice is not always the best route from a censored or
poorly-peered network. Operators commonly scan Cloudflare's address ranges for
a reachable, low-latency edge, but the proxy previously had no way to dial
those results without changing DNS outside the process.
Added
--cf-ip <IP>/TG_CF_IPaccepts one or more IPv4 or IPv6 addresses
(comma-separated or repeated) for both the regular CF proxy and CF Worker
tiers.- Each logical CF connection rotates which address gets first chance, then
tries every configured address not already cooling before that hostname
fails. Pool refills and--checkuse the same list. - Edges whose direct TCP connection times out enter the existing CF failure
cooldown and are skipped by later connections. TLS, WebSocket, and HTTP
errors do not penalize an edge globally. If every edge is cooling, one
rotating candidate is still retried so recovery does not require a restart. - The preferred IP changes only the TCP destination. TLS SNI and HTTP
Host
remain the realkws{N}/ Worker hostname, preserving certificate
verification and Cloudflare's internal routing.
The list is global rather than per DC because it selects the Cloudflare edge,
not the Telegram backend. While --cf-ip is set, CF connections never fall
back to DNS; remove the flag to restore normal DNS/anycast selection. Direct
WebSocket, upstream MTProto proxy, and raw TCP tiers are unaffected.
Cost
The first failure can consume up to the number of attempted hostnames times the
number of preferred IPs times one CF connect timeout. Keep the list short and
periodically retest it; a long stale list trades resilience for slow initial
fallback. Cooldowns reduce repeated cost after that first failure. With no
--cf-ip, behavior and latency are unchanged.