၂၀၂၆ ခုနှစ် သြဂုတ်လ： Telegram ၏
တရားဝင် ပရောက်စီနည်းပညာအသစ် WEB-Proxy ကို ခွဲခြမ်းလေ့လာခြင်း

၂၀၂၆ ခုနှစ် သြဂုတ်လ ၂၁ ရက်နေ့တွင် Telegram သည် WEB-Proxy ဟုခေါ်သော ဆင်ဆာဖြတ်တောက်မှုကို ဆန့်ကျင်သည့် စမ်းသပ်နည်းပညာအသစ်ကို တရားဝင် စတင်ထုတ်လုပ်ခဲ့ပြီး နောက်ပိုင်းတွင် Telegram Desktop 7.1.0 ၌ တရားဝင် client ပံ့ပိုးမှု ရရှိခဲ့သည်။ ရိုးရာ MTProxy နှင့် မတူဘဲ WEB-Proxy သည် မိမိကိုယ်ကို ဝဘ်လမ်းကြောင်းအဖြစ် "အယောင်ဆောင်" ရန် မကြိုးစားတော့ပါ။ ယင်းအစား Telegram ၏ ပရောက်စီလမ်းကြောင်းကို WebView အတွင်းတွင် အမှန်တကယ် လည်ပတ်စေပြီး browser engine မှတစ်ဆင့် စံ HTTPS သို့မဟုတ် WebSocket ချိတ်ဆက်မှုများကို စတင်ကာ ဆင်ဆာစနစ်များအတွက် သာမန်ဝဘ်ကြည့်ရှုခြင်းနှင့် ခွဲခြားမရနိုင်အောင် ပြုလုပ်သည်။

ဤဆောင်းပါးတွင် ဒီဇိုင်းအတွေးအခေါ်၊ လက်ရှိ DPI အခြေအနေ၊ နည်းပညာဗိသုကာနှင့် လက်တွေ့ရလဒ် ဟူသော ရှုထောင့်လေးခုဖြင့် ခွဲခြမ်းလေ့လာထားသည်။

၁။ ဒီဇိုင်းအတွေးအခေါ်： အယောင်ဆောင်ခြင်းမဟုတ်၊ ရောနှောခြင်း

WEB-Proxy ၏ အဓိကဒီဇိုင်းအတွေးအခေါ်ကို စကားလုံးလေးလုံးဖြင့် အနှစ်ချုပ်နိုင်သည်： ရောနှောပါ၊ အယောင်ဆောင်မနေပါ။

၁.၁ "အယောင်ဆောင်" မှ "ရောနှော" သို့

ရိုးရာ MTProxy ၏ ဗျူဟာမှာ "အယောင်ဆောင်" ဖြစ်သည် — ၎င်း၏ လမ်းကြောင်းကို သာမန် HTTPS လမ်းကြောင်းကဲ့သို့ ဖြစ်စေရန် ကြိုးစားသည်။ သို့သော် မည်မျှပင် အယောင်ဆောင်ကောင်းစေကာမူ MTProto ပရောက်စီ၏ ချိတ်ဆက်မှုအပြုအမူတွင် ဖော်ထုတ်နိုင်သော လက္ခဏာများ ရှိနေဆဲဖြစ်သည်။ ရှေး MTProxy သည် "သာမန်ဝဘ်လမ်းကြောင်းကဲ့သို့ ပေါ်ရန်" ကြိုးစားခဲ့သော်လည်း WEB-Proxy သည် အမှန်တကယ် ဝဘ်နည်းပညာ stack ကို အသုံးပြုသည်။ ကွန်ရက်စစ်ထုတ်စက်များသည် browser engine မှ ထုတ်ပေးသော စံ TLS နှင့် HTTPS လမ်းကြောင်းများကိုသာ တွေ့ရသည်။

ဤပြောင်းလဲမှု၏ အနှစ်သာရမှာ — DPI ကို "ငါ ဝဘ်စာမျက်နှာနှင့် တူသည်" ဟု လှည့်ဖြားရန် မကြိုးစားတော့ဘဲ လမ်းကြောင်းသည် အခြေခံအားဖြင့် ဝဘ်လမ်းကြောင်း ဖြစ်နေခြင်း ဖြစ်သည်။

၁.၂ Telegram အတွက်သာ၊ ကမ္ဘာလုံးဆိုင်ရာ ပရောက်စီ မဟုတ်

Telegram သည် ယေဘုယျ VPN သို့မဟုတ် ကမ္ဘာလုံးဆိုင်ရာ ပရောက်စီကို ထုတ်လုပ်မည့်အစား MTProxy လမ်းကြောင်းကို ပိုမိုနက်ရှိုင်းစွာ ဆက်လက်လုပ်ဆောင်နေသည်။ ၎င်းသည် ရှင်းလင်းသော မဟာဗျူဟာအတွေးအခေါ်ကို ထင်ဟပ်စေသည်： Telegram ၏ ကိုယ်ပိုင်အသုံးပြုနိုင်မှုကို ဦးစားပေးဖြေရှင်းရန်နှင့် ကမ္ဘာလုံးဆိုင်ရာ ပရောက်စီစွမ်းရည်ကို တမင်မပေးအပ်ရန်။ အကယ်၍ WEB-Proxy သည် ယေဘုယျ ရှောင်ကွင်းအခြေခံအဆောက်အအုံ ဖြစ်လာပါက ဆင်ဆာစနစ်များ၏ ပစ်မှတ်ထားပိတ်ဆို့မှုကို ချက်ချင်းခံရမည်ဖြစ်ပြီး အယောင်ဆောင်အဖြစ် အသုံးပြုသော သာမန်ဝဘ်ဆိုက်များကိုပါ ထိခိုက်စေနိုင်သည်။ Telegram လမ်းကြောင်းကိုသာ ဝန်ဆောင်မှုပေးခြင်းဖြင့် ၎င်းကို ပိတ်ဆို့ခြင်းသည် ယေဘုယျ ရှောင်ကွင်းဝန်ဆောင်မှုကို ပိတ်ဆို့ခြင်းထက် ဆက်သွယ်ရေးအက်ပ်တစ်ခုကို ပိတ်ဆို့ခြင်းကဲ့သို့ ပိုမိုပေါ်လွင်စေပြီး "အလွန်အကျွံပစ်မှတ်ထားခံရခြင်း" အန္တရာယ်ကို လျှော့ချသည်။

၁.၃ သိမှုကင်းသော Relay： Relay သည် ဘာမှမမြင်ပါ

WEB-Proxy ၏ နောက်ထပ် အဓိကဒီဇိုင်းမူမှာ သိမှုကင်းသော Relay ဖြစ်သည်။ ဆာဗာဘက်ရှိ tproxy-server သည် DATA frame များကို ဖောက်ထွင်းမမြင်နိုင်သော byte များအဖြစ် သတ်မှတ်သည် — ၎င်းသည် Telegram ဦးတည်ရာကို ရွေးချယ်နိုင်မည်မဟုတ်သလို MTProxy stream ကိုလည်း decrypt လုပ်နိုင်မည်မဟုတ်ပါ။ client သည် bridge စွမ်းရည်ကို locally ရယူပြီး မူရင်း secret ကို JavaScript သို့ ဘယ်တော့မှ မဖော်ထုတ်ပါ။ ဆိုလိုသည်မှာ ပရောက်စီ အော်ပရေတာပင် အသုံးပြုသူ၏ ဆက်သွယ်မှုများကို ကြည့်ရှုနိုင်မည်မဟုတ်ပါ။

၂။ လက်ရှိ DPI အခြေအနေ： ၂၀၂၆ ခုနှစ် တိုးမြင့်လာမှု

၂.၁ ၂၀၂၆ ပိတ်ဆို့မှုလှိုင်း အချိန်ဇယား

၂၀၂၆ ခုနှစ်သည် Telegram သည် ရုရှားနှင့် အခြားဒေသများတွင် အပြင်းထန်ဆုံး ပိတ်ဆို့မှုကို ရင်ဆိုင်ခဲ့ရသော နှစ်ဖြစ်သည်။ ပိတ်ဆို့မှုသည် အဆင့်များစွာဖြင့် ဖြစ်ပွားခဲ့သည်：

• ၂၀၂၆ မတ်လ： RKN သည် TSPU စနစ်တွင် ပရောက်စီချိတ်ဆက်မှု ရှာဖွေစက်အယ်လဂိုရီသမ်အသစ်များကို ဖြန့်ကျက်ခဲ့သည်။ ဤအယ်လဂိုရီသမ်များသည် Telegram client များနှင့် browser များ ကုဒ်ဝှက်ချိတ်ဆက်မှု တည်ဆောက်ရာတွင် ကွာခြားချက်များကို ဖော်ထုတ်နိုင်ခဲ့သည်။
• ၂၀၂၆ ဧပြီလ： Telegram သည် client update ထုတ်လုပ်ပြီး ကုဒ်ဝှက်ချိတ်ဆက်မှုများကို browser နှင့် ပိုတူအောင် ပြုလုပ်ခဲ့သဖြင့် ပြဿနာကို ယာယီဖြေရှင်းနိုင်ခဲ့သည်။
• ၂၀၂၆ မေလနှောင်းပိုင်း： TSPU သည် ချိတ်ဆက်မှုတည်ဆောက်ခြင်းသာမက protocol လက္ခဏာများကိုပါ ခွဲခြမ်းစိတ်ဖြာကာ MTProto client များနှင့် တကယ့် browser များကို ခွဲခြားသည့် အယ်လဂိုရီသမ်အသစ်များကို စတင်စမ်းသပ်ခဲ့သည်။ မေလနှောင်းပိုင်းနှင့် ဇွန်လတွင် ပိတ်ဆို့မှုလှိုင်းအသစ် စတင်ခဲ့သည်။
• ၂၀၂၆ ဇွန်လ ၅ ရက်မှစ၍： Telegram သည် ရုရှားတွင် အသုံးပြု၍မရလုနီးပါး ဖြစ်လာခဲ့သည်။ တရားဝင် MTProto ပရောက်စီများ (built-in Fake TLS အပါအဝင်) ကို DPI မှ လုံးဝပိတ်ဆို့ခဲ့ပြီး client အားလုံး (Desktop, Android, iOS) နှင့် ISP အဓိကအားလုံး (Rostelecom, MTS, Beeline) ကို ထိခိုက်စေခဲ့သည်။

၂.၂ နည်းပညာနည်းလမ်း： JA4 လက်ဗွေရာ

လက်ရှိ DPI စနစ်၏ အဓိကရှာဖွေရေးနည်းလမ်းမှာ JA4 TLS လက်ဗွေရာ ဖြစ်သည်။ တရားဝင် Telegram client သည် ၎င်း၏ ClientHello တွင် တည်ငြိမ်သော JA4 လက်ဗွေရာကို အသုံးပြုသည်။ DPI စနစ်က ၎င်းကို ဖော်ထုတ်လိုက်သည်နှင့် ချိတ်ဆက်မှုကို အဆုံးသတ်ရန် RST packet များကို ချက်ချင်း inject လုပ်သည်။ Fake TLS ဖြင့်ပင် client ၏ TLS stack သည် တကယ့် browser နှင့် ကွာခြားနေဆဲဖြစ်သဖြင့် ဖော်ထုတ်နိုင်ဆဲဖြစ်သည်။

Community မှ ဤအချက်ကို အတည်ပြုခဲ့သည်： dynamic JA4 rotation ပါသော community fork များသည် တူညီသော ပရောက်စီနှင့် ကွန်ရက်ပေါ်တွင် ချက်ချင်း အလုပ်လုပ်သည်။

၂.၃ အပြုအမူခွဲခြမ်းစိတ်ဖြာခြင်း

TLS လက်ဗွေရာများအပြင် ၂၀၂၆ DPI စနစ်များသည် လမ်းကြောင်း၏ အပြုအမူလက္ခဏာများကိုလည်း ခွဲခြမ်းစိတ်ဖြာသည်။ ခွဲခြမ်းစိတ်ဖြာသူများသည် packet အရွယ်အစား၊ packet များအကြား အချိန်ကွာဟမှု၊ TLS ချိတ်ဆက်မှုဖွဲ့စည်းပုံနှင့် အခြား သွယ်ဝိုက်လက္ခဏာများကို စစ်ဆေးသည်။ လမ်းကြောင်းသည် ပရောက်စီကဲ့သို့ ပြုမူပါက HTTPS အဖြစ် အယောင်ဆောင်ခြင်းသည် မလုံလောက်တော့ပါ။ ပုံမှန်အခြေအနေတစ်ခုမှာ "16KB ပြဿနာ" ဖြစ်သည်： ချိတ်ဆက်မှု အောင်မြင်စွာတည်ဆောက်ပြီး ကနဦးဒေတာ ပို့ဆောင်ပြီးနောက် ရုတ်တရက် အမြန်နှုန်းကန့်သတ်ခံရခြင်း သို့မဟုတ် ချိတ်ဆက်မှုဖြတ်တောက်ခံရခြင်း ဖြစ်သည်။

၃။ နည်းပညာဗိသုကာ： WEB-Proxy ၏ အဓိကဒီဇိုင်း

၃.၁ အလုံးစုံဗိသုကာ

WEB-Proxy ဗိသုကာကို အောက်ပါအတိုင်း အနှစ်ချုပ်နိုင်သည်：

Telegram App
  → MTProto connection (keeps normal MTProxy framing and encryption)
  → Local WEB proxy adapter (one logical stream per app connection)
  → One WebView transport + authenticated relay session
  → Multiplexed frames (HTTPS or WebSocket carrier)
  → tproxy-server
  → One local TCP connection per stream → Official MTProxy

client သည် တန်ဖိုးနှစ်ခုသာ ပြင်ဆင်သည်： hostname နှင့် MTProxy secret။ ၎င်းသည် bridge စွမ်းရည်ကို locally ရယူပြီး မူရင်း secret ကို JavaScript သို့ ဘယ်တော့မှ မဖော်ထုတ်ပါ။ WebView သည် bridge စာမျက်နှာကို ဖွင့်ပြီး ခဏတာအသက်တမ်းရှိ bootstrap token ကို relay session အဖြစ် လဲလှယ်ကာ သက်ဆိုင်ရာ ဆာဗာ profile မှ ရွေးချယ်ထားသော carrier မုဒ်ကို လည်ပတ်စေသည်။ OPEN, DATA, WINDOW, နှင့် CLOSE frame များသည် Telegram ချိတ်ဆက်မှုအားလုံးကို multiplex လုပ်သည်။

၃.၂ carrier မုဒ်လေးမျိုး

WEB-Proxy သည် transport carrier မုဒ်လေးမျိုးကို ပံ့ပိုးသည်၊ ၎င်းတို့ကို secret/profile မှ ရွေးချယ်ပြီး client ဘက်မှ ထပ်ဆောင်း ပြင်ဆင်ရန် မလိုပါ：

၃.၃ လုံခြုံရေးဒီဇိုင်း

WEB-Proxy တွင် အဓိကလုံခြုံရေးအင်္ဂါရပ်များ ရှိသည်：

• ဒိုမိန်းအယောင်ဆောင်ခြင်း： ပြင်ဆင်ထားသော hostname သည် သာမန် HTTPS ဝဘ်ဆိုက်လည်း ဖြစ်သည်။ စစ်မှန်သော credential မပါသော request များသည် အများပြည်သူဆိုက်ကို မြင်ရသည်； GET /?bridge=<valid capability> သာ bridge ကို ဖော်ပြသည်။
• တည်မြဲသော signing key： ဆာဗာသည် တည်မြဲသော signing key (token.key) ကို အသုံးပြုသည်။ key မရှိခြင်း သို့မဟုတ် ခွင့်ပြုချက်မမှန်ကန်ခြင်းသည် စတင်ခြင်းကို တားဆီးသည်； ephemeral key ကို တိတ်တဆိတ် ထုတ်လုပ်ခြင်းမရှိပါ။
• တင်းကျပ်သော frontend မူဝါဒ： bridge စာမျက်နှာသည် cookies, browser storage, external resources, workers, frames, media, popups, downloads, forms, device permissions, clipboard APIs, သို့မဟုတ် cross-origin requests များကို အသုံးမပြုပါ။
• စွမ်းရည်ထိန်းချုပ်မှုများ： process-wide limits များသည် မဖြစ်မနေ လိုအပ်သော လုံခြုံရေးနယ်နိမိတ် ဖြစ်သည်။ ပုံသေ： max_sessions_global 128, max_streams_global 4096, max_backend_dials_in_flight 256။

၃.၄ ဖြန့်ကျက်ဗိသုကာ

ရည်ညွှန်း ဖြန့်ကျက်ဗိသုကာမှာ：

Internet :80/:443 → Caddy → 127.0.0.1:8080 tproxy-server → Operator Site
                                                   → 127.0.0.1:2398 Official MTProxy

Caddy သာ ပြင်ပ interface များတွင် listen လုပ်သည်။ relay, admin endpoint များ၊ MTProxy client port နှင့် စာရင်းအင်းများသည် local တွင် ရှိနေသည်။ relay သည် client ရွေးချယ်သော backend address ကို ဘယ်တော့မှ လက်ခံမည်မဟုတ်သလို MTProxy stream ကိုလည်း decrypt မလုပ်ပါ။ Caddy သည် path အားလုံးကို relay သို့ proxy လုပ်ပြီး အတည်မပြုရသေးသော prober များ နှိုင်းယှဉ်နိုင်ရန် သီးခြား public path မရှိပါ။

၄။ လက်တွေ့ရလဒ်များ： လက်ရှိအခြေအနေနှင့် တုံ့ပြန်ချက်

၄.၁ client ပံ့ပိုးမှုအခြေအနေ

၂၀၂၆ ခုနှစ် သြဂုတ်လအထိ client ပံ့ပိုးမှုမှာ အောက်ပါအတိုင်း ဖြစ်သည်：

• Telegram Desktop： 7.1.0 တွင် WEB-Proxy ကို တရားဝင်ပံ့ပိုးသည်၊ 7.1.1 သည် bug အချို့ကို ပြုပြင်ပြီး 7.1.2 သည် Windows တွင် ချိတ်ဆက်မှုကို ပိုမိုကောင်းမွန်စေသည်။
• Android： beta client များတွင် ပံ့ပိုးသည်။
• iOS： စီမံကိန်းအဆင့်တွင်သာ ရှိသေးသည်။

client တွင် အသုံးပြုသူများသည် hostname နှင့် secret သာ ဖြည့်ရန်လိုပြီး port သို့မဟုတ် protocol ပြင်ဆင်ရန် မလိုပါ။ မျှဝေနိုင်သော link ပုံစံမှာ：

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

၄.၂ ဖြန့်ကျက်ရန် အဆင့်နှင့် ကုန်ကျစရိတ် သိသိသာသာ မြင့်မားသည်

ရိုးရာ MTProxy သို့မဟုတ် သာမန်ပရောက်စီများနှင့် နှိုင်းယှဉ်ပါက WEB-Proxy ၏ ဖြန့်ကျက်ရန်အဆင့်၊ နည်းပညာအခက်အခဲနှင့် ကုန်ကျစရိတ်တို့သည် သိသိသာသာ မြင့်မားသည်။ ၎င်းသည် "IP နှင့် port ဖြည့်ပြီး သွားရန်" ကဲ့သို့ ပေါ့ပါးသော ဖြေရှင်းနည်း မဟုတ်တော့ပါ။ အော်ပရေတာသည် ဆာဗာလည်ပတ်မှု စွမ်းရည်အပြည့်အဝ ရှိရန် လိုအပ်သည်： ဒိုမိန်းနှင့် public server ပိုင်ဆိုင်ခြင်း၊ DNS ပြင်ဆင်ခြင်း၊ Caddy reverse proxy၊ systemd service များ၊ nftables firewall စည်းမျဉ်းများ ပြင်ဆင်ခြင်း၊ WebView carrier နှင့် frame protocol အခြေခံများကို နားလည်ခြင်း။ တရားဝင် installer သည် အလိုအလျောက်လုပ်ဆောင်မှုအချို့ကို ပေးသော်လည်း ၎င်းသည် "Caddy က ports 80/443 ကို ပိုင်ဆိုင်သော သန့်ရှင်းသည့်ဆာဗာ" အတွက် ရည်ရွယ်ဆဲဖြစ်သည်； အခြားဆိုက်များ လက်ရှိလည်ပတ်နေသော ဆာဗာများတွင် manual integration လိုအပ်သည်။ သာမန်အသုံးပြုသူများအတွက် ဤအရာသည် "အများပြည်သူပရောက်စီသုံးခြင်း" မှ "ဝဘ်ဝန်ဆောင်မှုငယ်တစ်ခု လည်ပတ်ခြင်း" သို့ ရွေ့သွားခြင်းဖြစ်ပြီး အချိန်၊ နည်းပညာနှင့် ဆက်လက်ထိန်းသိမ်းရေး ကုန်ကျစရိတ်များ သိသိသာသာ မြင့်မားသည်။ ထို့ကြောင့် WEB-Proxy သည် ကာလတိုအတွင်း နည်းပညာအသိုင်းအဝိုင်း၊ အဖွဲ့အစည်းအသုံးပြုသူများနှင့် စမ်းသပ်လိုသော အဆင့်မြင့်အသုံးပြုသူများမှ ပိုမိုလက်ခံနိုင်ဖွယ်ရှိပြီး အများပြည်သူ MTProxy ကဲ့သို့ ကျယ်ပြန့်လာဖွယ် မရှိပါ။

၄.၃ ထိရောက်မှု အကဲဖြတ်

အားသာချက်များ：

• ကွန်ရက်ဆင်ဆာစနစ်များ၏ ရှုထောင့်မှကြည့်ပါက WEB-Proxy လမ်းကြောင်းသည် အသုံးပြုသူ သာမန်ဝဘ်ဆိုက်တစ်ခုကို သာမန်ကြည့်ရှုနေခြင်းနှင့် ခွဲခြားမရနိုင်လုနီးပါး ဖြစ်သည်။ ပြင်ပလေ့လာသူများသည် သင့်ဒိုမိန်းသို့ TLS လမ်းကြောင်းများကိုသာ မြင်ရပြီး HTTPS decryption မပြုလုပ်ပါက သာမန်ဝဘ်ဆိုက်သို့ ဝင်ရောက်ခြင်းနှင့် ခွဲခြားနိုင်မည်မဟုတ်ပါ။
• လမ်းကြောင်းသည် တကယ့် browser engine မှ လာသောကြောင့် TLS လက်ဗွေရာသည် တကယ့် browser နှင့် ကိုက်ညီပြီး ရိုးရာ Fake TLS ၏ JA4 လက်ဗွေရာ ဖော်ထုတ်ခံရမှုပြဿနာကို ဖြေရှင်းသည်။
• carrier မုဒ်လေးမျိုးကို ကွန်ရက်ပတ်ဝန်းကျင်အလိုက် လိုက်လျောညီထွေ ရွေးချယ်နိုင်သဖြင့် မတူညီသော ပိတ်ဆို့ရေးဗျူဟာများနှင့် လိုက်လျောညီထွေဖြစ်နိုင်စွမ်း တိုးလာသည်။

ကန့်သတ်ချက်များ：

• ဆာဗာဘက်ရှိ tproxy-server ကို တရားဝင်မှ proof-of-concept အဖြစ် သတ်မှတ်ထားဆဲဖြစ်ပြီး တည်ငြိမ်သော release မဟုတ်သေးပါ။
• ကိုယ်ပိုင်ဒိုမိန်းနှင့် ဆာဗာ လိုအပ်ပြီး ဖြန့်ကျက်ရန် နည်းပညာအခက်အခဲနှင့် ကုန်ကျစရိတ် မြင့်မားသည်။ အသုံးပြုသူများသည် အများပြည်သူ MTProxy သုံးသကဲ့သို့ ဝန်ဆောင်မှုကို တိုက်ရိုက်ရယူနိုင်မည် မဟုတ်ပါ။
• လည်ပတ်စဉ် WebView သည် ပရောက်စီပံ့ပိုးသူ၏ ဝဘ်စာမျက်နှာကို နောက်ခံတွင် load လုပ်သည်။ ပံ့ပိုးသူများသည် sponsored channel များ inject လုပ်နိုင်ပြီး ဖြစ်နိုင်ချေရှိသော အန္တရာယ် ရှိသည်။ Telegram သည် ဤအချက်နှင့်ပတ်သက်၍ သတိပေးချက် ထုတ်ပြန်ခဲ့သည်။
• relay ကို restart လုပ်ပါက လက်ရှိ carrier session များ သက်တမ်းကုန်ဆုံးပြီး client များ ပြန်လည်ချိတ်ဆက်ရန် လိုအပ်သည်။
• macOS WebKit တွင် WebSocket handshake များ serialized ဖြစ်နိုင်ပြီး websocket-lanes မုဒ်တွင် ချိတ်ဆက်မှုတည်ဆောက်ရန် နှေးကွေးစေနိုင်သည်； ဤအခြေအနေတွင် websocket မုဒ်သို့ ပြောင်းပါ။

၄.၄ အခြားဖြေရှင်းနည်းများနှင့် နှိုင်းယှဉ်ချက်

၅။ နိဂုံး

WEB-Proxy သည် Telegram ၏ ဆင်ဆာဆန့်ကျင်ရေးနည်းပညာတွင် အဓိကဆင့်ကဲပြောင်းလဲမှုကို ကိုယ်စားပြုသည်။ ပရောက်စီလမ်းကြောင်းကို WebView အတွင်းတွင် အမှန်တကယ် လည်ပတ်စေခြင်းဖြင့် "ဝဘ်လမ်းကြောင်းအဖြစ် အယောင်ဆောင်" မှ "ဝဘ်လမ်းကြောင်း ဖြစ်ခြင်း" သို့ ရွေ့လျားကာ ၂၀၂၆ ခုနှစ်၏ ပိုမိုကြမ်းတမ်းလာသော DPI ပတ်ဝန်းကျင်တွင် အသက်ရှင်ရေးလမ်းကြောင်းအသစ်ကို ပေးသည်။ ၎င်း၏ ဒီဇိုင်းအတွေးအခေါ် — Telegram အတွက်သာ၊ သိမှုကင်းသော relay၊ ကမ္ဘာလုံးဆိုင်ရာပရောက်စီမဟုတ် — သည် "အသုံးပြုနိုင်မှု" နှင့် "အလွန်အကျွံပစ်မှတ်ထားခံရခြင်းမှ ရှောင်ရှားရေး" အကြား တရားဝင်၏ သိမ်မွေ့သော ချိန်ခွင်လျှာကို ထင်ဟပ်စေသည်။

သတိပြုရန်အချက်မှာ WEB-Proxy ၏ ဖြန့်ကျက်ရန်အဆင့်၊ နည်းပညာအခက်အခဲနှင့် ကုန်ကျစရိတ်တို့သည် ရိုးရာ MTProxy ထက် မြင့်မားသည်။ ၎င်းသည် သာမန်အသုံးပြုသူများအတွက် one-click ဖြေရှင်းနည်း မဟုတ်ဘဲ အော်ပရေတာများတွင် ဒိုမိန်း၊ ဆာဗာနှင့် ဝဘ်ဝန်ဆောင်မှု လည်ပတ်မှုစွမ်းရည်များ လိုအပ်သည်။ လက်ရှိတွင် WEB-Proxy သည် proof-of-concept အဆင့်တွင် ရှိသေးသော်လည်း Telegram Desktop နှင့် Android client များတွင် တရားဝင်ပံ့ပိုးမှုနှင့် community ၏ တက်ကြွစွာပါဝင်မှုနှင့်အတူ ဤနည်းပညာသည် ကန့်သတ်ကွန်ရက်ပတ်ဝန်းကျင်များတွင် Telegram အသုံးပြုရန် အဓိကဖြေရှင်းနည်းများထဲမှ တစ်ခု ဖြစ်လာနိုင်ဖွယ်ရှိသည်။

🎁 ဆင်ဆာဆန့်ကျင်ရေးဖြေရှင်းနည်းကို ကိုယ်တိုင်စမ်းသပ်လိုပါသလား？