Telegram plugin: SNI-based DPI on institutional networks silently blocks all bot traffic — diagnostic and workaround

Resolved 💬 3 comments Opened Apr 6, 2026 by cversek Closed May 22, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

The Telegram plugin silently fails to connect on networks that perform SNI-based Deep Packet Inspection (DPI) — common on university, corporate, and some carrier networks. The bot process starts, MCP shows "connected," but no messages arrive and no errors appear in the Claude Code UI. The failure is completely silent from the user's perspective.

Root Cause

Many institutional networks inspect the TLS ClientHello packet's Server Name Indication (SNI) field. When they see api.telegram.org, they reset the TCP connection. The Telegram Bot API uses long-polling over HTTPS, so the bot process can't reach Telegram's servers at all.

Symptoms

  • Telegram plugin shows "connected" in /mcp
  • Bot process (Bun) is running
  • No messages from Telegram reach Claude Code
  • No error messages in Claude Code UI
  • server.log shows no new entries after startup
  • Killing and reconnecting the plugin doesn't help
  • Problem persists across different WiFi networks on the same campus

Sure-Fire Diagnostic

Run this in your terminal — it definitively identifies SNI-based blocking in 2 seconds:

# Test 1: WITHOUT SNI (should succeed if network allows TCP to Telegram)
echo | openssl s_client -connect 149.154.166.110:443 -noservername 2>&1 | grep -E "CONNECTED|errno"

# Test 2: WITH SNI (will fail if DPI is blocking)
echo | openssl s_client -connect 149.154.166.110:443 -servername api.telegram.org 2>&1 | grep -E "CONNECTED|errno"

If Test 1 shows CONNECTED but Test 2 shows errno=54 (connection reset), your network is doing SNI-based DPI on Telegram.

Workaround

Install Cloudflare WARP (free, no account needed):

brew install cloudflare-warp
warp-cli connect

WARP encrypts all traffic including the SNI field (via ECH/QUIC), bypassing the DPI inspection. Telegram plugin works immediately after connecting.

Suggestion for Plugin

The plugin could improve the user experience by:

  1. Detecting the failure: If the bot's getUpdates long-poll fails with ECONNRESET repeatedly, log a visible warning
  2. Suggesting the diagnostic: Print the openssl SNI test commands when connection failures are detected
  3. Documenting the issue: Add a "Institutional Networks" section to the plugin README

Environment

  • Claude Code: 2.1.87
  • macOS (Darwin 24.5.0)
  • Bun: 1.2.x
  • Plugin: telegram@claude-plugins-official
  • Network: University campus WiFi (confirmed on multiple SSIDs + cellular hotspot on same campus)
  • Workaround confirmed: Cloudflare WARP

Related Issues

Many "messages not arriving" issues (#37189, #38477, #43627, #43653, #44135) may have SNI-based DPI as an undiagnosed root cause, especially for users on institutional networks.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗