CDN

[MrParAziT]

Hey
is it work behind a CDNs?(Like cloudflare)

[salehMomtaz]

if they use WebSocket yes.

[salehMomtaz]

Claude: Based on my research of the tproxy-server repository, here's a comprehensive answer to your question about CDN compatibility:

No, you cannot use traditional CDNs like Cloudflare or Vercel with tproxy-server in v1.

Key Reasons:

1. Architecture Incompatibility
The tproxy-server is designed to operate with a direct connection from the Telegram client to your server. The documentation explicitly states:

"Do not put a CDN in front of v1. Long polls, in-memory session affinity, request buffering, provider terms, and CDN behavior are separate design work. DNS should point directly to this server for the first field tests."

2. Session Management & State

• tproxy-server maintains in-memory session state tied to specific server instances
• Each relay session is tied to a specific client connection and cannot be resumed across different machines
• CDNs would route requests to different edge locations/servers, breaking session affinity
• The authentication mechanism uses bearer tokens that are locally validated and tied to the specific relay instance

3. Long-Polling Protocol
The carrier protocol uses HTTP long-polling with:

• Cursor-based acknowledgment (X-Down-Cursor)
• Sequence tracking (X-Up-Seq)
• 25-second poll hold times
• CDNs would interfere with this timing and connection persistence

4. Authentication & Bridge Capability

• Bridge requests use a derived capability derived from: HMAC-SHA256(hostname + secret)
• The bridge page is dynamically generated per-session with unique nonces
• CDNs would cache or modify this, breaking the protocol

5. Carrier Modes
All carrier modes require persistent connections:

• https: Serialized long-polling
• https-lanes: Stream-specific long-polling
• websocket: Persistent WebSocket connection
• websocket-lanes: Per-stream WebSocket connections

What You CAN Do:

1. Use a load balancer (only at L4/TCP level if needed) that maintains session affinity
2. Point DNS directly to your server's IP address
3. Use Caddy as your reverse proxy (included in the deployment)
4. Run multiple independent relay instances on separate hostnames (e.g., north.example.com, south.example.com) with different secrets

Future Possibilities:

The documentation notes CDN support as a future consideration:

"WebSocket, streaming fetch, HTTP/3, WebTransport, or CDN fronting... can be reconsidered after the narrow long-poll deployment works end to end."

So CDN integration is planned for a future version, but not available in v1.

Bottom Line:

For now, deploy tproxy-server on a direct, dedicated server with its own public IP address and hostname. DNS points directly to that server without any intermediary proxy or CDN layer.