اوت ۲۰۲۶: کالبدشکافی فناوری پروکسی جدید
رسمی تلگرام WEB-Proxy

در ۲۱ اوت ۲۰۲۶، تلگرام رسماً یک فناوری آزمایشی جدید ضد سانسور به نام WEB-Proxy معرفی کرد و سپس پشتیبانی رسمی از آن را در Telegram Desktop 7.1.0 اضافه کرد. برخلاف MTProxy سنتی، WEB-Proxy دیگر سعی نمی‌کند خود را «استتار» کند. در عوض، ترافیک پروکسی تلگرام واقعاً داخل یک WebView اجرا می‌شود و اتصالات استاندارد HTTPS یا WebSocket را از طریق موتور مرورگر برقرار می‌کند، به‌گونه‌ای که برای سیستم‌های سانسور از مرور وب عادی قابل تشخیص نیست.

در این مقاله این فناوری را در چهار محور بررسی می‌کنیم: فلسفه طراحی، وضعیت فعلی DPI، معماری فنی و نتایج واقعی.

۱. فلسفه طراحی: حل شدن در ترافیک، نه استتار

فلسفه اصلی WEB-Proxy را می‌توان در چهار کلمه خلاصه کرد: حل شدن در ترافیک، نه استتار.

۱.۱ از «استتار» به «حل شدن»

استراتژی MTProxy سنتی «استتار» است: تلاش می‌کند ترافیک خود را شبیه HTTPS معمولی نشان دهد. اما هر چقدر هم خوب استتار کند، رفتار اتصال پروکسی MTProto همچنان ویژگی‌های قابل شناسایی دارد. MTProxy قدیمی سعی می‌کرد «شبیه» ترافیک وب معمولی به نظر برسد، در حالی که WEB-Proxy از پشته واقعی وب استفاده می‌کند. فیلترهای شبکه با ترافیک استاندارد TLS و HTTPS تولیدشده توسط موتور مرورگر روبرو می‌شوند.

ماهیت این تغییر: به جای فریب دادن DPI («من شبیه یک صفحه وب هستم»)، ترافیک ذاتاً ترافیک وب است.

۱.۲ فقط برای تلگرام، نه یک پروکسی جهانی

تلگرام به جای ارائه یک VPN یا پروکسی جهانی، مسیر MTProxy را ادامه می‌دهد. این پشت یک محاسبه استراتژیک روشن است: اولویت حل مشکل دسترسی خود تلگرام و عدم ارائه عمدی قابلیت پروکسی جهانی. اگر WEB-Proxy به یک زیرساخت عمومی عبور از سانسور تبدیل می‌شد، بلافاصله هدف مسدودسازی هدفمند قرار می‌گرفت، تا جایی که ممکن بود سایت‌های عادی مورد استفاده به عنوان پوشش نیز مسدود شوند. سرویس‌دهی فقط به ترافیک تلگرام به این معناست که مسدود کردن آن بیشتر شبیه مسدود کردن یک پیام‌رسان است تا یک سرویس عمومی عبور از سانسور، و ریسک «هدف‌گیری بیش از حد» را کاهش می‌دهد.

۱.۳ رله بدون دانش (Zero-Knowledge): رله هیچ چیز نمی‌بیند

یکی دیگر از اصول طراحی اصلی WEB-Proxy رله بدون دانش است. بخش سرور tproxy-server فریم‌های DATA را به عنوان بایت‌های مبهم در نظر می‌گیرد: نه می‌تواند مقصد تلگرام را انتخاب کند و نه می‌تواند جریان MTProxy را رمزگشایی کند. کلاینت قابلیت bridge را به صورت محلی استخراج می‌کند و کلید خام هرگز در JavaScript افشا نمی‌شود. این بدان معناست که حتی اپراتور پروکسی هم نمی‌تواند محتوای ارتباطات را ببیند.

۲. وضعیت فعلی DPI: تشدید ۲۰۲۶

۲.۱ گاه‌شمار موج مسدودسازی ۲۰۲۶

سال ۲۰۲۶ سال سخت‌ترین مسدودسازی تلگرام در روسیه و مناطق دیگر بود. مسدودسازی در چند مرحله پیش رفت:

• مارس ۲۰۲۶: RKN الگوریتم‌های جدید تشخیص اتصال پروکسی را روی سیستم TSPU مستقر کرد. این الگوریتم‌ها می‌توانستند تفاوت بین کلاینت‌های تلگرام و مرورگرها را هنگام برقراری اتصالات رمزنگاری‌شده تشخیص دهند.
• آوریل ۲۰۲۶: تلگرام به‌روزرسانی کلاینت را منتشر کرد که برقراری اتصال رمزنگاری‌شده را شبیه‌تر به مرورگر کرد و مشکل را موقتاً حل کرد.
• اواخر مه ۲۰۲۶: TSPU شروع به آزمایش الگوریتم‌های جدیدی کرد که نه تنها نحوه برقراری اتصال، بلکه امضای پروتکل را نیز برای تشخیص کلاینت‌های MTProto از مرورگرهای واقعی تحلیل می‌کرد. موج جدید مسدودسازی از اواخر مه و ژوئن آغاز شد.
• از ۵ ژوئن ۲۰۲۶: تلگرام در روسیه تقریباً غیرقابل استفاده شد. پروکسی‌های رسمی MTProto (از جمله Fake TLS داخلی) به طور کامل توسط DPI مسدود شدند و همه کلاینت‌ها (Desktop، Android، iOS) و همه ISPهای اصلی (Rostelecom، MTS، Beeline) را تحت تأثیر قرار دادند.

۲.۲ ابزار فنی: اثر انگشت JA4

روش اصلی تشخیص سیستم‌های DPI فعلی تحلیل اثر انگشت TLS JA4 است. کلاینت رسمی تلگرام از یک اثر انگشت JA4 ثابت در ClientHello استفاده می‌کند؛ سیستم DPI پس از شناسایی، بلافاصله بسته‌های RST را تزریق کرده و اتصال را قطع می‌کند. حتی با استفاده از Fake TLS، پشته TLS کلاینت هنوز با مرورگر واقعی متفاوت است و بنابراین قابل تشخیص است.

جامعه تأیید کرده که این یک مشکل سمت کلاینت است: فورک‌هایی با چرخش پویا JA4 بلافاصله روی همان پروکسی و شبکه کار می‌کنند.

۲.۳ تحلیل ویژگی‌های رفتاری

علاوه بر اثر انگشت TLS، سیستم‌های DPI در سال ۲۰۲۶ ویژگی‌های رفتاری ترافیک را نیز تحلیل می‌کنند. تحلیلگران اندازه بسته‌ها، فواصل بین آن‌ها، ساختار اتصال TLS و سایر نشانه‌های غیرمستقیم را بررسی می‌کنند. اگر ترافیک مانند یک پروکسی رفتار کند، استتار به‌عنوان HTTPS دیگر کافی نیست. سناریوی معمول «مشکل ۱۶ کیلوبایت» است: اتصال با موفقیت برقرار می‌شود و داده‌های اولیه را منتقل می‌کند، سپس ناگهان محدود یا قطع می‌شود.

۳. ویژگی‌های فنی: معماری اصلی WEB-Proxy

۳.۱ معماری کلی

معماری WEB-Proxy را می‌توان به صورت زیر خلاصه کرد:

Telegram App
  → اتصال MTProto (حفظ کپسوله‌سازی و رمزنگاری عادی MTProxy)
  → آداپتور پروکسی WEB محلی (یک جریان منطقی برای هر اتصال برنامه)
  → یک ترابری WebView + نشست رله تأییدشده
  → فریم‌های مالتی‌پلکس‌شده (حامل HTTPS یا WebSocket)
  → tproxy-server
  → یک اتصال TCP محلی برای هر جریان → MTProxy رسمی

کلاینت فقط دو مقدار را پیکربندی می‌کند: hostname و کلید MTProxy. قابلیت bridge را به صورت محلی استخراج می‌کند و کلید خام هرگز در JavaScript افشا نمی‌شود. WebView صفحه bridge را باز می‌کند، توکن bootstrap کوتاه‌مدت را با یک نشست رله مبادله می‌کند و سپس در حالت حاملی که توسط پروفایل سرور مطابق انتخاب شده اجرا می‌شود. فریم‌های OPEN، DATA، WINDOW و CLOSE همه اتصالات تلگرام را مالتی‌پلکس می‌کنند.

۳.۲ چهار حالت حامل

WEB-Proxy از چهار حالت حامل ترابری پشتیبانی می‌کند که با کلید/پروفایل انتخاب می‌شوند و نیازی به تنظیمات اضافی در کلاینت ندارند:

۳.۳ ویژگی‌های امنیتی

WEB-Proxy چند ویژگی امنیتی کلیدی دارد:

• استتار دامنه: hostname پیکربندی‌شده همزمان یک وب‌سایت HTTPS عادی است. درخواست‌های بدون اعتبارنامه احراز هویت، سایت عمومی را می‌بینند؛ فقط GET /?bridge=<capability معتبر> bridge را آشکار می‌کند.
• کلید امضای پایدار: سرور از یک کلید امضای پایدار (token.key) استفاده می‌کند. نبود یا مجوز نامناسب کلید، شروع را متوقف می‌کند؛ کلید موقت بی‌صدا تولید نمی‌شود.
• سیاست سخت‌گیرانه فرانت‌اند: صفحه bridge از کوکی، حافظه مرورگر، منابع خارجی، worker، frame، رسانه، پاپ‌آپ، دانلود، فرم، مجوزهای دستگاه، API کلیپ‌بورد یا درخواست‌های cross-origin استفاده نمی‌کند.
• کنترل ظرفیت: محدودیت‌های سراسری فرآیند یک مرز امنیتی اجباری است. پیش‌فرض‌ها: max_sessions_global = ۱۲۸، max_streams_global = ۴۰۹۶، max_backend_dials_in_flight = ۲۵۶.

۳.۴ معماری استقرار

معماری استقرار مرجع:

Internet :80/:443 → Caddy → 127.0.0.1:8080 tproxy-server → سایت اپراتور
                                                   → 127.0.0.1:2398 MTProxy رسمی

فقط Caddy به رابط‌های خارجی گوش می‌دهد. رله، نقاط پایانی مدیریت، پورت کلاینت MTProxy و آمار محلی باقی می‌مانند. رله هرگز آدرس بک‌اند انتخاب‌شده توسط کلاینت را دریافت نمی‌کند و هرگز جریان MTProxy را رمزگشایی نمی‌کند. Caddy همه مسیرها را به رله پروکسی می‌کند؛ مسیر عمومی جداگانه‌ای برای بررسی‌کنندگان غیرمجاز وجود ندارد که بتوان آن را با سایت عمومی مقایسه کرد.

۴. نتایج واقعی: وضعیت فعلی و بازخورد

۴.۱ وضعیت پشتیبانی کلاینت

تا اوت ۲۰۲۶، پشتیبانی کلاینت به شرح زیر است:

• Telegram Desktop: پشتیبانی رسمی از WEB-Proxy از نسخه 7.1.0، در 7.1.1 برخی اشکالات رفع شد و در 7.1.2 اتصال در ویندوز بهبود یافت.
• Android: پشتیبانی در کلاینت‌های بتا.
• iOS: هنوز در مرحله برنامه‌ریزی است.

در کلاینت، کاربر فقط باید hostname و کلید را وارد کند؛ نیازی به پیکربندی پورت یا پروتکل نیست. قالب لینک قابل اشتراک:

https://t.me/webproxy?server=proxy.example.com&secret=000102030405060708090a0b0c0d0e0f

۴.۲ آستانه و هزینه استقرار به‌مراتب بالاتر است

در مقایسه با MTProxy سنتی یا پروکسی معمولی، آستانه استقرار، دشواری فنی و هزینه WEB-Proxy به‌مراتب بالاتر است. دیگر یک راه‌حل سبک «IP و پورت را وارد کن و تمام» نیست؛ نیازمند مهارت کامل عملیات سرور است: دامنه و سرور عمومی اختصاصی، پیکربندی DNS، پروکسی معکوس Caddy، سرویس‌های systemd، قوانین nftables و درک اصول حامل‌های WebView و پروتکل فریم. نصب‌کننده رسمی تا حدی خودکارسازی دارد، اما همچنان برای «سرور تمیز که Caddy مالک پورت‌های 80/443 است» طراحی شده؛ سرورهایی که قبلاً سایت‌های دیگر را میزبانی می‌کنند نیاز به ادغام دستی دارند. برای کاربر عادی، این به معنای переход از «استفاده از پروکسی عمومی» به «راه‌اندازی یک سرویس وب کوچک» است که هزینه‌های زمانی، فنی و نگهداری مداوم را به طور قابل توجهی افزایش می‌دهد. به همین دلیل، WEB-Proxy در کوتاه‌مدت بیشتر توسط جوامع فنی، کاربران سازمانی و کاربران پیشرفته‌ای که حاضر به آزمایش هستند پذیرفته می‌شود، نه اینکه مانند MTProxy عمومی به طور گسترده رایج شود.

۴.۳ ارزیابی اثربخشی

مزایا:

• از دید سیستم‌های سانسور شبکه، ترافیک WEB-Proxy تقریباً از بازدید عادی یک وب‌سایت معمولی قابل تشخیص نیست. ناظر خارجی فقط ترافیک TLS به دامنه شما را می‌بیند؛ بدون رمزگشایی HTTPS نمی‌توان آن را از بازدید یک سایت معمولی تشخیص داد.
• از آنجا که ترافیک از موتور مرورگر واقعی می‌آید، اثر انگشت TLS آن با مرورگر واقعی مطابقت دارد و مشکل افشای اثر انگشت JA4 در Fake TLS سنتی را حل می‌کند.
• چهار حالت حامل را می‌توان به صورت انعطاف‌پذیر بر اساس محیط شبکه انتخاب کرد و توانایی تطبیق با استراتژی‌های مختلف مسدودسازی را افزایش داد.

محدودیت‌ها:

• بخش سرور tproxy-server هنوز رسماً به عنوان proof-of-concept علامت‌گذاری شده و نسخه پایدار ندارد.
• نیازمند دامنه و سرور اختصاصی است و دشواری فنی و هزینه استقرار بالاتر است؛ کاربر نمی‌تواند مانند MTProxy عمومی مستقیماً سرویس دریافت کند.
• در زمان اجرا، WebView صفحه ارائه‌دهنده پروکسی را در پس‌زمینه بارگذاری می‌کند؛ ارائه‌دهنده ممکن است کانال‌های تبلیغاتی تزریق کند که یک ریسک بالقوه است. تلگرام هشدار رسمی داده است.
• راه‌اندازی مجدد رله نشست‌های حامل فعال را باطل می‌کند و کلاینت‌ها باید دوباره متصل شوند.
• در macOS WebKit، دست‌دادن‌های WebSocket ممکن است سریالی شوند و در حالت websocket-lanes اتصال را کند کنند؛ در این صورت باید به حالت websocket تغییر دهید.

۴.۴ مقایسه با سایر راه‌حل‌ها

۵. نتیجه‌گیری

WEB-Proxy نشان‌دهنده یک تحول مهم در فناوری ضد سانسور تلگرام است. با اجرای واقعی ترافیک پروکسی داخل WebView، از «استتار به عنوان ترافیک وب» به «بودن ترافیک وب» می‌رسد و مسیر بقای جدیدی در محیط DPI سخت‌گیرانه ۲۰۲۶ فراهم می‌کند. فلسفه طراحی آن — فقط برای تلگرام، رله بدون دانش، بدون پروکسی جهانی — تعادل ظریف رسمی بین «قابلیت استفاده» و «عدم جلب هدف‌گیری بیش از حد» را نشان می‌دهد.

لازم به ذکر است که آستانه استقرار، دشواری فنی و هزینه WEB-Proxy همگی بالاتر از MTProxy سنتی است. این یک راه‌حل یک‌کلیکی برای کاربران عادی نیست، بلکه نیازمند توانایی اپراتور در دامنه، سرور و عملیات سرویس وب است. در حال حاضر WEB-Proxy هنوز در مرحله proof-of-concept است، اما با پشتیبانی رسمی در Telegram Desktop و کلاینت‌های Android، و مشارکت فعال جامعه، انتظار می‌رود این فناوری در آینده به یکی از راه‌حل‌های اصلی دسترسی به تلگرام در محیط‌های شبکه محدود تبدیل شود.

🎁 می‌خواهید خودتان یک راه‌حل ضد سانسور را امتحان کنید؟