Colitu Adaptive Connect 2.0 و مسیر پشتیبان آماده: یک گزارش فنی
Colitu Adaptive Connect 2.0 در قالب یک گزارش پژوهشی کوتاه. رتبه‌بندی سرورها، حافظهٔ هر شبکه، راهنمایی‌های ناشناس شبکه، بررسی سلامت، مسیر پشتیبان آماده و پایش میانِ نشست در برابر شبکه‌هایی که اتصال را مسدود یا منجمد می‌کنند، به‌همراه روش، نتایج و محدودیت‌ها.
*گزارش فنی. این صفحه طراحی، روش اندازه‌گیری و نتایجِ پشت رفتاری را توضیح می‌دهد که در Adaptive Connect در Colitu چگونه کار می‌کند و مسیر پشتیبان آماده آمده است. رفتار توصیف‌شده در اینجا در آخرین نسخه‌های برنامه‌ها وجود دارد.*
چکیده
برخی شبکه‌ها پروتکل‌های VPN را مسدود می‌کنند؛ برخی دیگر ظریف‌تر رفتار می‌کنند: اجازه می‌دهند اتصال برقرار شود و چند ده ثانیه بعد بی‌سروصدا ترافیک را متوقف می‌کنند. در چنین شبکه‌ای «به پینگ پاسخ می‌دهد» و «ترافیک را حمل می‌کند» یکسان نیستند. این گزارش مجموعه سازوکارهایی را توصیف می‌کند که برنامه‌های Colitu در برابر این مشکل به کار می‌برند، یعنی Colitu Adaptive Connect 2.0: رتبه‌بندی سرورها با در نظر گرفتن نزدیکی و حریم خصوصی، حافظهٔ هر شبکه که فقط روی دستگاه نگه داشته می‌شود، راهنمایی‌های شبکه که از شمارنده‌های ناشناس به دست می‌آیند، بررسی سلامت هنگام اتصال بر پایهٔ ترافیک واقعی، جایگزینی سرور، یک مسیر پشتیبان آماده که درون اتصال در حال اجرا آماده نگه داشته می‌شود، و ناظر میانِ نشست که همهٔ انتقال‌ها را پوشش می‌دهد. ارزیابی روی یک تلفن Android در یک شبکهٔ Wi-Fi خانگی در کشوری با بازرسی عمیق بسته (DPI) فعال انجام شد، با خطاهایی که فقط برای همین یک کلاینت روی سرور تزریق شدند. در بهترین پیکربندی، وقتی مسیر اصلی به مدت 120 ثانیه قطع شد، VPN روشن ماند، اتصال مجدد رخ نداد و وقفه حدود 5 تا 10 ثانیه طول کشید. در یک آزمون پایداری 60 دقیقه‌ای با 11 خطای تزریق‌شده روی 8 سرور، 98.8 % از پروب‌ها از طریق تونل موفق بودند؛ وقتی سرور در حال استفاده به مدت 101 ثانیه کاملاً قطع شد، کاربر فقط یک توقف حدود 5 ثانیه‌ای دید و VPN روشن ماند. محدودیت‌ها و موقعیت‌هایی که هنوز اندازه‌گیری نشده‌اند جداگانه فهرست شده‌اند.
1. مقدمه
- نخستین وظیفهٔ یک برنامهٔ VPN اتصال به سرور درست با حالت اتصال درست است. سرورهای Colitu پنج حالت اتصال از چهار خانوادهٔ پروتکل ارائه می‌دهند: Hysteria2 (UDP/QUIC)، VLESS Reality، VLESS XHTTP، Trojan و Shadowsocks 2022 (به جزئیات فنی نگاه کنید).
- روش کلاسیک سرورها را بر اساس پینگ رتبه‌بندی می‌کند و سریع‌ترین پاسخ‌دهنده را برمی‌گزیند. اما پینگ فقط یک نشانه است: در برخی شبکه‌ها سرور به پینگ پاسخ می‌دهد و با این حال هیچ ترافیکی را حمل نمی‌کند.
- حالت دشوارتری هم هست: اتصال برقرار می‌شود، برنامه «متصل» نشان می‌دهد، اما پس از مدتی ترافیک متوقف می‌شود در حالی که اتصال TCP هنوز باز به نظر می‌رسد. برای کاربر این یعنی VPN روشن است اما اینترنت رفته است.
- Adaptive Connect 1.x بخشی از این مشکلات را حل کرد، اما اندازه‌گیری‌های ما دو شکاف مهم را نشان داد: فهرست سرورها به ترتیب شناسهٔ پایگاه داده می‌آمد و ناظر میانِ نشست فقط Hysteria2 را پوشش می‌داد (بخش 4 را ببینید).
- هدف Adaptive Connect 2.0 این است: هنگام اتصال مسیری پیدا کند که واقعاً کار می‌کند، مسیری را که در حین اتصال خراب می‌شود تشخیص دهد و کاربر را به مسیر دیگری ببرد، در صورت امکان بدون خاموش کردن VPN، و همهٔ این‌ها را بدون جمع‌آوری اطلاعات دربارهٔ کاربر انجام دهد.
2. مدل تهدید و خطا
طراحی انواع خطای زیر را در نظر می‌گیرد. این‌ها بر پایهٔ رفتار دیده‌شده در برخی شبکه‌ها و نزد برخی اپراتورهای موبایل هستند، نه بر پایهٔ هیچ کشور مشخصی.
| خطا | روی شبکه چه رخ می‌دهد | کاربر چه می‌بیند |
|---|---|---|
| مسدودسازی پروتکل | اتصال یک پروتکل مشخص هرگز برقرار نمی‌شود | نمی‌تواند متصل شود |
| انجماد پنهان | اتصال برقرار می‌شود، ترافیک پس از N ثانیه متوقف می‌شود، TCP باز می‌ماند | «متصل»، اما صفحه‌ها بارگذاری نمی‌شوند |
| مسدودسازی UDP | حالت‌های مبتنی بر UDP (Hysteria2) کار نمی‌کنند، TCP کار می‌کند | در حالت UDP نمی‌تواند متصل شود |
| قطعی سرور | سرور با هیچ پروتکلی در دسترس نیست | روی آن سرور اتصالی وجود ندارد |
| تغییر شبکه | جابه‌جایی بین Wi-Fi و داده تلفن همراه، قطع شدن Wi-Fi | قطع کوتاه؛ مسدودسازی متفاوت روی شبکهٔ دیگر |
فرض‌ها:
- ممکن است یک شبکه حالتی را مسدود کند در حالی که شبکهٔ دیگر مسدود نمی‌کند، بنابراین «کار می‌کند» ویژگی شبکه است.
- ممکن است یک شبکه همهٔ حالت‌های TCP یک سرور را با هم منجمد کند؛ در این صورت حالت TCP دیگری روی همان سرور به‌عنوان پشتیبان بی‌فایده است.
- اینترنت خود دستگاه ممکن است از دست برود؛ در این صورت هیچ حالتی نباید مقصر دانسته شود.
3. طراحی
سازوکارهای زیر برای برنامه‌های Windows، Linux، Android (از جمله TV) و iOS طراحی شده‌اند. همهٔ سازوکارها در هر برنامه یکسان هستند. اندازه‌گیری‌های بخش 4 روی یک تلفن Android انجام شد.
3.1 رتبه‌بندی سرورها
- موقعیتی که کاربر انتخاب کرده همان‌طور که هست استفاده می‌شود. Colitu هرگز انتخاب دستی را خودش عوض نمی‌کند.
- در حالت خودکار («سریع‌ترین سرور») ترتیب چنین است:
| رتبه | معیار |
|---|---|
| 1 | سروری که آخرین بار در شبکه‌ای که اکنون در آن هستید کار کرده است (24 ساعت به خاطر سپرده می‌شود) |
| 2 | کمترین پینگ اندازه‌گیری‌شده؛ پینگی که از 10 دقیقه قدیمی‌تر باشد یا روی شبکهٔ دیگری اندازه‌گیری شده باشد به حساب نمی‌آید |
| 3 | سرورهای کشورهای دیگر پیش از سرورهای کشور خودتان، با کشورهای نزدیک‌تر در اولویت (وقتی هنوز پینگی نیست هم همین ترتیب است) |
| 4 | سروری که به پینگ پاسخ نداده به انتها می‌رود |
| 5 | سروری که در 30 دقیقهٔ گذشته در این شبکه ناموفق بوده در آخر قرار می‌گیرد |
- «پیشنهادی» در فهرست سرورها همیشه سروری را نشان می‌دهد که حالت خودکار به آن متصل می‌شود.
- حریم خصوصی: برای مرتب کردن فهرست، پنل کشور شما و شبکهٔ ارائه‌دهندهٔ اینترنت شما را فقط از نشانی IP همان درخواست تعیین می‌کند. چیزی ذخیره نمی‌شود. وقتی درخواست از طریق VPN می‌آید پنل نمی‌تواند آن‌ها را بداند، و برنامه آخرین مقادیری را که یاد گرفته نگه می‌دارد.
3.2 حافظهٔ هر شبکه
- «شبکه» ترکیب نوع اتصال (Wi-Fi، داده تلفن همراه، Ethernet) با شبکهٔ ارائه‌دهندهٔ اینترنت شماست. Wi-Fi خانه و داده تلفن همراه جداگانه به خاطر سپرده می‌شوند.
- حافظه فقط روی دستگاه نگه داشته می‌شود:
| مورد | مدت ماندگاری |
|---|---|
| آخرین سرور کارکرده | 24 ساعت |
| آخرین حالت کارکرده برای هر سرور | 24 ساعت |
| حالتی که ترافیکی حمل نکرد («نشانهٔ توقف») | 6 ساعت (برای استثناها به 3.8 نگاه کنید) |
| سروری که همه‌چیز در آن ناموفق بود | 30 دقیقه |
- ورودی‌های قدیمی حذف می‌شوند؛ حداکثر 200 ورودی نگه داشته می‌شود.
- در نتیجه، حالتی که در داده تلفن همراه مسدود است باز هم در Wi-Fi خانه اول امتحان می‌شود.
3.3 راهنمایی‌های شبکه
حافظهٔ یک دستگاه فقط تجربهٔ همان دستگاه را می‌داند. راهنمایی‌های شبکه تجربهٔ دستگاه‌های دیگر در همان شبکه را بدون شناسایی کسی به اشتراک می‌گذارند.
- توکن امضاشدهٔ شبکه. پنل توکنی به برنامه می‌دهد که شامل کشور و شمارهٔ شبکه (ASN) است، با HMAC امضا شده و 48 ساعت معتبر است.
- گزارش‌دهی. برنامه نتایج هر پروتکل را با این توکن می‌فرستد. نشانی IP درخواست هرگز برای مشاهدات استفاده نمی‌شود؛ در حالت اتصال، آن نشانی به هر حال یک سرور VPN است.
- شمارنده‌های ساعتی ناشناس. پنل فقط شمارنده‌های ساعتی را به ازای (کشور، ASN، پروتکل) نگه می‌دارد: موفقیت‌ها، شکست‌ها و تعداد دستگاه‌های متمایز. دستگاه‌های متمایز با نام‌های مستعار کلیددار ساعتی شمرده می‌شوند که با پایان ساعت حذف می‌شوند. این شمارش‌ها 7 روز نگه داشته می‌شوند.
- آستانه‌ها. یک پروتکل وقتی «در این شبکه مسدود» به حساب می‌آید که دست‌کم 5 دستگاه در 24 ساعت گذشته آن را امتحان کرده باشند و نرخ موفقیت کمتر از 20 % باشد. اگر شبکه داده کافی نداشته باشد، سطح کشور استفاده می‌شود: دست‌کم 20 دستگاه و کمتر از 10 % موفقیت.
- هرگز همه. همهٔ پروتکل‌های ارائه‌شده هرگز مسدود علامت‌گذاری نمی‌شوند.
- استفاده. پاسخ فهرست سرورها پروتکل‌های مسدود را گزارش می‌کند. برنامه آن‌ها را آخر امتحان می‌کند، مگر اینکه یکی در 24 ساعت گذشته روی این دستگاه در این شبکه کار کرده باشد.
3.4 بررسی سلامت هنگام اتصال و مسیر راستی‌آزمایی
- یک حالت فقط وقتی کارکرده به حساب می‌آید که ترافیک واقعی جریان داشته باشد. بررسی از طریق تونل نشانی‌های رایج آزمون اتصال (Cloudflare، Google، Microsoft) را می‌پرسد و هرگز سرورهای خود Colitu را نمی‌پرسد. برای هر حالت حدود 4 تا 6 ثانیه طول می‌کشد.
- پیش از اینکه حالتی کارنکرده علامت‌گذاری شود، برنامه بررسی می‌کند که دستگاه اصلاً آنلاین است، تا قطع شدن Wi-Fi به گردن حالت نیفتد.
- بودجهٔ زمانی: حدود 8 ثانیه برای هر حالت (شروع به‌اضافهٔ بررسی ترافیک)، حدود 20 ثانیه برای هر سرور و حداکثر حدود 45 ثانیه برای کل یک اتصال. معمولاً چند ثانیه کافی است.
- Android «متصل» را فقط پس از گذشتن بررسی نشان می‌دهد؛ تا آن زمان «در حال بررسی…» را نشان می‌دهد.
- مسیر راستی‌آزمایی. هر بار که هسته شروع می‌شود، یک ورودی بررسی خصوصی که فقط از خود دستگاه در دسترس است اضافه می‌شود (با درگاه تصادفی و مشخصات تصادفی). اولین قاعدهٔ مسیریابی آن را مستقیم به مسیر اصلی می‌فرستد. بنابراین بررسی هنگام اتصال فقط مسیر اصلی را می‌سنجد؛ مسیر اصلی خراب نمی‌تواند پشت پشتیبان پنهان شود و در اتصال بعدی از آن پرهیز می‌شود.
3.5 جایگزینی سرور
- در حالت خودکار، اگر هیچ‌یک از حالت‌های یک سرور بررسی سلامت را نگذراند، برنامه به سرور بعدی فهرست می‌رود، تا 3 سرور در هر اتصال. در این میان «در حال امتحان سرور دیگر…» نشان داده می‌شود.
- سرور ناموفق 30 دقیقه در آن شبکه در انتها می‌ماند.
- در Windows و Linux با روشن بودن قطع‌کن اضطراری، تلاش مجدد خودکار به‌جای تلاش دوباره روی همان سرور، فهرست را پایین می‌رود.
- اگر همهٔ حالت‌ها روی سروری که دستی انتخاب شده ناموفق باشند، خطا یک «سریع‌ترین سرور را امتحان کنید» با یک لمس پیشنهاد می‌دهد.
3.6 مسیر پشتیبان آماده
توپولوژی. در حالت اتصال، برنامه یک مسیر دوم را درون اتصال در حال اجرا آماده نگه می‌دارد. ترافیک از یک توزیع‌کننده (balancer) عبور می‌کند: تا وقتی مسیر اصلی سالم است همه‌چیز از آن می‌گذرد؛ اگر مسیر اصلی از کار بیفتد، ترافیک جدید خودش به پشتیبان می‌رود. VPN روشن می‌ماند و هیچ صفحهٔ «در حال اتصال مجدد» ظاهر نمی‌شود. چون تعویض درون خود اتصال انجام می‌شود و نه در صفحهٔ برنامه، وقتی برنامه در پس‌زمینه است هم کار می‌کند. پشتیبان فقط وقتی استفاده شود متصل می‌شود.
انتخاب پشتیبان.
| موقعیت | پشتیبان |
|---|---|
| حالت خودکار، یک انتقال در این شبکه اثبات شده است (در 24 ساعت گذشته روی هر سرور کار کرده) | همان انتقال روی سرور بعدی در رتبه‌بندی (همان خانواده مجاز است) |
| حالت خودکار، چیزی اثبات نشده است | خانوادهٔ دیگر روی سرور بعدی (UDP ↔ TCP): با مسیر اصلی Hysteria2 یک حالت TCP مانند VLESS Reality؛ با مسیر اصلی TCP در صورت امکان Hysteria2 |
| سرور دستی | همان سرور، خانوادهٔ دیگر؛ حالت‌های متوقف‌شده رد می‌شوند، Shadowsocks آخر (موقعیت شما تغییر نمی‌کند) |
| مسیر Multihop یا سرور تک‌حالته | بدون پشتیبان |
حالت‌ها و سرورهایی که در این شبکه ناموفق بوده‌اند هرگز پشتیبان نمی‌شوند.
تلهٔ پیشوند. در Xray، انتخابگرهای balancer و observatory برچسب‌ها را بر اساس پیشوند تطبیق می‌دهند. اگر برچسب پشتیبان با همان پیشوندِ برچسب مسیر اصلی شروع می‌شد، observatory پشتیبان را هم مسیر اصلی می‌پنداشت. بنابراین برچسب پشتیبان طوری انتخاب می‌شود که هیچ پیشوندی با مسیر اصلی مشترک نداشته باشد.
DNS. پرس‌وجوهای ماژول DNS در Xray یک قاعدهٔ صریح به balancer دارند.
مهلت کاربر TCP. وقتی پشتیبان وصل است، مسیرهای TCP از مهلت کاربر TCP 10 ثانیه‌ای استفاده می‌کنند (مفهومی از RFC 5482)، تا اتصال‌های مرده بسته شوند و معلق نمانند.
زمان تشخیص و هزینه.
| سنجه | مقدار |
|---|---|
| تشخیص و تعویض، Windows/Linux | معمولاً ظرف حدود 8 ثانیه |
| تشخیص و تعویض، تلفن‌ها | به‌طور میانگین حدود 10 تا 13 ثانیه (بدترین حالت حدود 23 ثانیه) |
| مسیر Hysteria2 روی دسکتاپ | وقتی اتصالی ناموفق شود فوری؛ وقتی مسیر فقط معلق بماند تا حدود 20 ثانیه |
| ترافیک اضافه برای بررسی مسیر اصلی | تلفن‌ها حدود 0.3 تا 2 MB در ساعت، رایانه‌ها حدود 4 تا 7 MB در ساعت |
قطع‌کن اضطراری Windows سرور پشتیبان را هم اجازه می‌دهد؛ Linux آن را به فهرست مجاز خود اضافه می‌کند. پیکربندی پشتیبان موازی با اتصال دریافت می‌شود، هرگز آن را به تأخیر نمی‌اندازد و کش می‌شود. مسیر پشتیبان آماده به‌صورت پیش‌فرض روشن است؛ می‌توان آن را در حالت پیشرفته خاموش کرد و در حالت ساده همیشه روشن است.
3.7 ناظر میانِ نشست و قاعدهٔ آگاه از پشتیبان
- در Adaptive Connect 1.x ناظر میانِ نشست فقط Hysteria2 را پوشش می‌داد. در 2.0 همهٔ انتقال‌ها پایش می‌شوند.
- ریتم: در 90 ثانیهٔ اول هر 5 ثانیه، سپس هر 30 ثانیه. سه خطای پیاپی در حالی که دستگاه آنلاین است یعنی مسیر اصلی مرده به حساب می‌آید.
- قاعدهٔ آگاه از پشتیبان. وقتی پشتیبان وصل است، ناظر دو چیز را جداگانه بررسی می‌کند: مسیر اصلی به‌تنهایی، و مسیر عادی (مسیری که balancer استفاده می‌کند).
| مسیر اصلی | مسیر عادی (با پشتیبان) | نتیجه |
|---|---|---|
| کار می‌کند | کار می‌کند | هیچ اتفاقی نمی‌افتد |
| مرده | کار می‌کند (پشتیبان ترافیک را حمل می‌کند) | اتصال مجدد انجام نمی‌شود؛ مسیر اصلی برای اتصال بعدی علامت‌گذاری می‌شود و انتقال و سرور پشتیبان دفعهٔ بعد در اولویت قرار می‌گیرند |
| مرده | مرده | اتصال مجدد |
- این قاعده اصلاح اشکالی است که در آزمایش 1 در بخش 4 دیده شد: ناظر قدیمی وقتی پشتیبان ترافیک را حمل می‌کرد اتصال را دوباره راه می‌انداخت و آن را خراب می‌کرد.
- Android و iOS پس از یک قطع غیرمنتظره خودشان دوباره متصل می‌شوند (پس از حدود 2، 5 و 15 ثانیه، سپس خطا نشان داده می‌شود) و با بازگشت شبکه دوباره. پس از اینکه قطع اتصال را بزنید، از حساب خارج شوید، یا وقتی طرح یا دستگاه متوقف باشد، چنین نمی‌کنند.
3.8 نشانه‌های توقفی که نمی‌توانند شبکه‌ای را قفل کنند
نشانه‌های توقف نادرست می‌توانند شبکه‌ای را بدون هیچ حالتی برای امتحان کردن رها کنند. دو قاعده از این جلوگیری می‌کند:
- اگر نشانه‌ها حداکثر یکی از انتقال‌های ارائه‌شده را باقی بگذارند، برای آن دور نادیده گرفته می‌شوند.
- نشانه‌هایی که در دوری پیدا شوند که در آن همه‌چیز ناموفق بود 10 دقیقه می‌مانند. ماندگاری 6 ساعته فقط وقتی اعمال می‌شود که انتقال دیگری در همان شبکه ترافیک را حمل کرده باشد، یعنی وقتی مشکل واقعاً مخصوص آن حالت بوده است.
3.9 گزارش‌های آنلاین بودن گره‌ها و بار
در هر ضربان (heartbeat)، سرورها تعداد کاربران متمایز متصل را گزارش می‌کنند (آمار کاربران آنلاین Xray و رابط آنلاین Hysteria2). پنل فقط گزارش‌های کامل را استفاده می‌کند؛ اگر آمار یک هسته قابل خواندن نبود، مقدار قبلی نگه داشته می‌شود. در نتیجه سرورهای پر دیگر پیشنهاد نمی‌شوند و توزیع مبتنی بر بار از اعداد واقعی استفاده می‌کند. این گزارش‌ها روی همهٔ سرورها فعال هستند.
3.10 پروب سلامت پشتیبان و اتصال موازی
دو سازوکار زیر در همهٔ برنامه‌ها هستند؛ هر دو در آزمون پایداری 4.3 فعال بودند:
- پروب سلامت پشتیبان. مسیر پشتیبان هم تقریباً یک بار در دقیقه از طریق ورودی بررسی خودش سنجیده می‌شود. پشتیبان مرده فقط وقتی تونل بیکار است جایگزین می‌شود، هرگز در حین تماس.
- اتصال موازی («happy eyeballs»). دو نامزد برتر همزمان بررسی می‌شوند و اولی که ترافیک را حمل کند برنده است. این ایده از رویکرد Happy Eyeballs در RFC 8305 پیروی می‌کند.
4. ارزیابی
4.1 روش
| مورد | جزئیات |
|---|---|
| دستگاه | یک تلفن Android 11 |
| شبکه | یک شبکهٔ Wi-Fi خانگی در کشوری با DPI فعال |
| تاریخ‌ها | 9 تا 10 اکتبر 2026 |
| تزریق خطا | روی سرور، با دور انداختن فقط بسته‌های همین کلاینت: یک پروتکل (روی همهٔ سرورهای فهرست‌شده) یا یک سرور کامل |
| ایمنی | قواعد برچسب‌گذاری می‌شوند و با زمان‌سنج‌های خودحذف‌شونده برداشته می‌شوند؛ هیچ چیز دیگری روی سرور و هیچ کاربر دیگری لمس نمی‌شود |
| پروب ترافیک | هر 5 تا 10 ثانیه، از دستگاه از طریق تونل |
| خروجی | طول وقفه برای هر خطا |
یک ابزار داخلی (آزمایشگاه خطا) برای این کار نوشته شد: یک پروتکل (روی همهٔ سرورهای فهرست‌شده) یا یک سرور کامل را برای یک کلاینت با قواعد فایروال برچسب‌دار قطع می‌کند، قواعد را با زمان‌سنج‌های خودحذف‌شونده برمی‌دارد، یک ساعت هر 5 ثانیه کلاینت را پروب می‌کند و طول وقفه را برای هر خطا گزارش می‌دهد. در آزمایش‌های مسیر پشتیبان آماده در 4.2 خطاها یکی‌یکی اعمال شدند؛ در آزمون پایداری در 4.3 ابزار خطاها را به ترتیب تصادفی به مدت 60 دقیقه تزریق کرد.
4.2 نتایج
رتبه‌بندی. سروری در کشور خود کاربر کمترین پینگ (13 تا 15 ms) را داشت اما به‌درستی بعد از یک سرور خارجی نزدیک (16 تا 17 ms) قرار گرفت. در Adaptive Connect 1.x فهرست به ترتیب شناسهٔ پایگاه داده می‌آمد و سروری با حدود 222 ms در قارهٔ دیگر «پیشنهادی» نشان داده می‌شد.
مشاهدهٔ انجماد. در این شبکه، هر انتقال TCP به یک سرور نزدیک (VLESS Reality، VLESS XHTTP، Trojan) حدود 30 تا 50 ثانیه پس از اتصال منجمد شد: ترافیک متوقف شد در حالی که TCP باز ماند. Hysteria2 به کار خود ادامه داد. ناظر قدیمی که فقط Hysteria2 را پوشش می‌داد، در این حالت «متصل» را بدون ترافیک نشان می‌داد. ناظر جدیدِ همهٔ انتقال‌ها انجماد را تشخیص داد و انتقال را در حدود 1.3 ثانیه عوض کرد.
خط پایه. نسخهٔ منتشرشدهٔ 2.7.0 در همان شبکه 100 ثانیه بدون وقفه روی Hysteria2 اجرا شد.
آزمایش‌های مسیر پشتیبان آماده (بسته‌های مسیر اصلی فقط برای این کلاینت روی سرور دور انداخته شدند):
| # | پیکربندی | خطا | نتیجه |
|---|---|---|---|
| 1 | همان سرور، پشتیبان Trojan | Hysteria2 قطع شد | پشتیبان در +12 ثانیه ترافیک را حمل کرد؛ سپس ناظر قدیمی اتصال را دوباره راه انداخت و آن را خراب کرد (اشکال، رفع شد) |
| 2 | همان سرور، پس از رفع | مسیر اصلی قطع شد | در این شبکه هیچ مسیر TCP روی آن سرور زنده نماند؛ حدود 48 ثانیه پس از پایان مسدودسازی بازیابی شد (در طول مسدودسازی هیچ مسیر کارکننده‌ای وجود نداشت) |
| 3 | حالت خودکار، پشتیبان روی سرور بعدی که به‌عنوان «خانوادهٔ دیگر» (Trojan) انتخاب شد | مسیر اصلی قطع شد | Trojan هم منجمد شد؛ پس از یک اتصال مجدد، یک پشتیبان Hysteria2 ترافیک را حمل کرد |
| 4 | حالت خودکار با قاعدهٔ انتقال اثبات‌شده: اصلی Hysteria2 روی سرور A، پشتیبان Hysteria2 روی سرور B | مسیر اصلی به مدت 120 ثانیه قطع شد | یک پروب ناموفق در +5 ثانیه، ترافیک از +10 ثانیه تا پایان جریان داشت؛ اتصال مجدد نبود، VPN روشن ماند. وقفه ≈ 5 تا 10 ثانیه |
4.3 آزمون پایداری
در 10 اکتبر 2026 یک آزمون پایداری 60 دقیقه‌ای روی همان تلفن و همان شبکهٔ Wi-Fi با یک بیلد Android شامل همهٔ سازوکارهای 2.0 (از جمله پروب سلامت پشتیبان و اتصال موازی) در حالت خودکار اجرا شد.
- روش. آزمایشگاه خطا 11 خطا را روی 8 سرور به ترتیب تصادفی تزریق کرد، با 2 تا 5 دقیقه فاصله بین خطاها و هر خطا 60 تا 120 ثانیه. دو نوع خطا استفاده شد: قطع یک پروتکل روی هر سرور برای این کلاینت، و قطع کامل یک سرور برای این کلاینت.
- پروب. هر 5 ثانیه یک درخواست HTTP از طریق تونل.
- نتیجه. 741 پروب از 750 موفق بود (98.8 %).
| # | خطا | مدت | طولانی‌ترین وقفه | بازگشت ترافیک پس از پایان خطا |
|---|---|---|---|---|
| 1 | VLESS Reality روی همهٔ سرورها قطع شد | 83 ثانیه | 0 ثانیه | 1 ثانیه |
| 2 | یک سرور در آلمان کاملاً قطع شد | 95 ثانیه | 0 ثانیه | 3 ثانیه |
| 3 | سرور در حال استفاده (اصلی) کاملاً قطع شد | 101 ثانیه | 5 ثانیه | 5 ثانیه |
| 4 | Shadowsocks روی همهٔ سرورها قطع شد | 102 ثانیه | 0 ثانیه | 4 ثانیه |
| 5 | VLESS Reality روی همهٔ سرورها قطع شد | 86 ثانیه | 0 ثانیه | 4 ثانیه |
| 6 | یک سرور در فنلاند کاملاً قطع شد | 65 ثانیه | 0 ثانیه | 1 ثانیه |
| 7 | Shadowsocks روی همهٔ سرورها قطع شد | 92 ثانیه | 0 ثانیه | 2 ثانیه |
| 8 | Trojan روی همهٔ سرورها قطع شد | 65 ثانیه | 0 ثانیه | 1 ثانیه |
| 9 | یک سرور در استونی کاملاً قطع شد | 120 ثانیه | 0 ثانیه | 0 ثانیه |
| 10 | سرور دیگری در فنلاند کاملاً قطع شد | 95 ثانیه | 0 ثانیه | 1 ثانیه |
| 11 | Hysteria2 روی همهٔ سرورها قطع شد | 61 ثانیه | 40 ثانیه | 2 ثانیه |
تفسیر.
- خطای 3 مورد کلیدی است: سرور در حال استفاده به مدت 101 ثانیه ناپدید شد؛ کاربر یک توقف حدود 5 ثانیه‌ای دید و VPN روشن ماند.
- خطای 11: در این شبکه هر پروتکل TCP توسط DPI منجمد می‌شود. با قطع Hysteria2 در همه‌جا هیچ پروتکل کارکننده‌ای وجود نداشت؛ ترافیک 2 ثانیه پس از پایان خطا بازگشت.
- خطاهای مربوط به پروتکل‌ها و سرورهایی که استفاده نمی‌شدند همان‌طور که انتظار می‌رفت 0 ثانیه نشان می‌دهند: خطاهای جاهای دیگر نشست را مختل نمی‌کنند.
محدودیت‌ها. یک دستگاه، یک شبکه، یک ساعت؛ خطاها در سمت سرور تزریق شدند، نه توسط یک سامانهٔ سانسور واقعی.
سازوکارهای آزمایش‌شده در همهٔ برنامه‌ها یکسان هستند (Android از جمله TV، iOS، Windows و Linux)؛ اندازه‌گیری روی یک تلفن Android انجام شد.
4.4 بحث
- آزمایش 1: یک مسیر پشتیبان آماده به‌تنهایی کافی نیست؛ ناظر باید از پشتیبان خبر داشته باشد. این آزمایش به قاعدهٔ آگاه از پشتیبان در 3.7 انجامید.
- آزمایش 2: وقتی شبکه همهٔ حالت‌های TCP آن سرور را منجمد کند، پشتیبان روی همان سرور بی‌فایده است (فرض 2). در اینجا هیچ مسیر کارکننده‌ای وجود نداشت؛ زمان اندازه‌گیری‌شده خود مسدودسازی است، نه تأخیر سازوکار.
- آزمایش 3: قاعدهٔ «خانوادهٔ دیگر» در هر شبکه‌ای درست نیست. در این شبکه خانوادهٔ TCP یکجا منجمد شد؛ انتخاب خانوادهٔ دیگر یعنی انتخاب خانواده‌ای منجمد. این آزمایش به قاعدهٔ «انتقال اثبات‌شده» در 3.6 انجامید: انتقالی که ثابت شده در این شبکه کار می‌کند روی سرور بعدی پشتیبان می‌شود.
- آزمایش 4: با ترکیب انتقال اثبات‌شده و سرور متفاوت، قطع مسیر اصلی فقط به‌صورت یک مکث کوتاه به کاربر رسید.
- آزمون پایداری: یک قطع کامل 101 ثانیه‌ای سرور در حال استفاده به یک توقف حدود 5 ثانیه‌ای تقلیل یافت؛ تنها وقفهٔ طولانی خطای 11 بود، وقتی هیچ پروتکل کارکننده‌ای باقی نمانده بود.
- مشاهدهٔ انجماد: فاصلهٔ بین «متصل» و «ترافیک جریان دارد» یک نوع خطای واقعی است، و پایش فقط یک انتقال کافی نیست.
4.5 هنوز اندازه‌گیری نشده
جابه‌جایی بین Wi-Fi و داده تلفن همراه و اندازه‌گیری iOS، Windows و Linux روی دستگاه‌های واقعی هنوز انجام نشده است.
5. محدودیت‌ها
- چرخش خروجی. این ویژگی VLESS را روی یک سرور اجباری می‌کند و مسیر پشتیبان آماده را غیرفعال می‌کند. در شبکهٔ اندازه‌گیری‌شده این به انجمادهای مکرر انجامید. این یک محدودیت مستندشده است.
- جریان‌های TCP باز. هنگام تعویض به پشتیبان، تماس‌ها پس از یک اختلال کوتاه ادامه می‌یابند و صفحه‌ها و پیام‌ها خودشان دوباره متصل می‌شوند؛ اما ممکن است دانلود بزرگی که در آن لحظه در جریان است از نو شروع شود. ادامهٔ واقعاً بدون وقفهٔ دانلودها کار آینده است.
- یک دستگاه، یک شبکه، یک ساعت. ارزیابی از یک تلفن Android در یک شبکه با آزمونی حداکثر یک ساعته استفاده کرد؛ خطاها در سمت سرور تزریق شدند، نه توسط یک سامانهٔ سانسور واقعی. نتایج را نمی‌توان به شبکه‌های دیگر تعمیم داد.
- کلید شبکهٔ کهنه. وقتی VPN روشن است، پنل نمی‌تواند ببیند درخواست از کدام شبکه می‌آید؛ برنامه تا زمانی که فهرست دوباره با VPN خاموش دریافت شود، آخرین شبکه‌ای را که یاد گرفته استفاده می‌کند.
- تعداد آنلاین‌ها. کاربرانی که از طریق sing-box متصل هستند در گزارش‌های آنلاین بودن لحاظ نمی‌شوند؛ کاربری که به دو سرور متصل است در مجموع دو بار شمرده می‌شود.
- بدون پشتیبان. با مسیرهای Multihop یا روی سرورهای تک‌حالته مسیر پشتیبان آماده وجود ندارد. sing-box نمی‌تواند XHTTP را اجرا کند.
6. کار آینده: لایهٔ نشست CSL
لایهٔ نشست Colitu (Colitu Session Layer یا CSL) لایهٔ نشستی است که بالای مسیر پشتیبان آماده برنامه‌ریزی شده است. این برنامه پیش‌نویس است و هیچ تاریخ یا نتیجه‌ای تعهد نمی‌شود.
- چه چیزی اضافه می‌کند. امروز مسیر پشتیبان آماده اتصال‌های جدید را به پشتیبان می‌برد، اما دانلودهای باز و تماس‌هایی که روی TCP حمل می‌شوند ممکن است قطع شوند. با CSL برنامه یک نشست باز می‌کند که حتی وقتی تونل زیرین (حامل) عوض شود زنده می‌ماند. در نمونهٔ اولیهٔ آزمایشگاهی طولانی‌ترین مکث 0.08 تا 1.75 ثانیه بود و ادامهٔ بی‌وقفهٔ دانلودها تأیید شد.
- حد آن. یک نشست CSL به یک سرور بسته است؛ نسخهٔ اول نمی‌تواند نشست را به سرور دیگری منتقل کند. CSL مشکلات درون همان سرور را حل می‌کند (جابه‌جایی بین Wi-Fi و داده تلفن همراه، مسدود شدن یک پروتکل، قطع لحظه‌ای). اگر خود سرور از کار بیفتد، مسیر پشتیبان آماده جای آن را می‌گیرد. این دو جایگزین یکدیگر نیستند؛ با هم کار می‌کنند.
- مرحله‌ها. نخست آزمون‌های تونل واقعی (Reality، Trojan، Hysteria2) روی سرورهای آزمایشی موقت با سناریوهای افت، مسدودسازی، تغییر شبکه و بار؛ سپس سرویس سمت سرور، یک پرچم روشن/خاموش برای هر سرور در پنل و یک کلید اضطراری که کل CSL را خاموش می‌کند؛ سپس ابتدا Windows، و پس از آن Linux، Android و در آخر iOS. اهداف شامل مکثی حداکثر 2 ثانیه هنگام تغییر حامل در حالی که پشتیبان آماده است، و دست‌کم 90 % سرعت اتصال مستقیم است.
- UDP و تماس‌ها. نسخهٔ اول فقط از TCP محافظت می‌کند؛ UDP (تماس‌های WhatsApp و Meet، QUIC/HTTP3) همچنان مانند امروز زیر محافظت مسیر پشتیبان آماده می‌ماند. گام بعدی حمل UDP به‌صورت دیتاگرام درون نشست CSL است؛ هنگام تغییر حامل فاصله‌ای کوتاه‌تر از 2 ثانیه انتظار می‌رود. یک تنظیم اختیاری «اجبار QUIC به TCP» در حالت پیشرفته هم در دست بررسی است.
- بدون CSL. اگر پرچم روی سرور خاموش باشد، CSL پاسخ ندهد، یا «مشغول» یا «رد شد» بگوید، کلاینت ظرف چند ثانیه به مسیر امروزی برمی‌گردد. نشستی که بیش از 90 ثانیه بدون حامل بماند از دست می‌رود. یک نگهبان (watchdog) کلاینت CSL گیرکرده را می‌بندد.
- کاربران چگونه آن را می‌گیرند. به‌صورت «نشست بدون وقفه (بتا)» در حالت پیشرفته؛ به‌صورت پیش‌فرض خاموش و فقط روی سرورهایی که پرچم روشن دارند نشان داده می‌شود.
7. نتیجه‌گیری
درس اصلی Adaptive Connect 2.0 این است که ترافیک واقعی، نه پینگ، تعیین می‌کند مسیری کار می‌کند یا نه، و این تصمیم به شبکه بستگی دارد. رتبه‌بندی‌ای که نزدیکی و حریم خصوصی را رعایت می‌کند، حافظهٔ شبکه که روی دستگاه نگه داشته می‌شود، راهنمایی‌های ناشناس شبکه و بررسی سلامتی که فقط مسیر اصلی را می‌سنجد، یافتن مسیر درست را ممکن می‌کنند. در حالت اتصال، مسیر پشتیبان آماده همراه با ناظری که همهٔ انتقال‌ها را پوشش می‌دهد و از پشتیبان خبر دارد، قطع مسیر اصلی را به مکثی حدود 5 تا 10 ثانیه تبدیل می‌کند. در آزمون پایداری 60 دقیقه‌ای 98.8 % از پروب‌ها موفق بودند و قطع کامل سرور در حال استفاده به‌صورت یک توقف حدود 5 ثانیه‌ای به کاربر رسید. ارزیابی محدود است؛ تغییر شبکه و اندازه‌گیری روی پلتفرم‌های دیگر گام‌های بعدی هستند.
مراجع
- RFC 8305, Happy Eyeballs Version 2: Better Connectivity Using Concurrency.
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
- RFC 5482, TCP User Timeout Option.
- مستندات پروژهٔ Hysteria2.
- مستندات پروژهٔ Xray-core.
هنوز به کمک نیاز دارید؟
Colitu Bot در چند ثانیه پاسخ می‌دهد و تیم پشتیبانی ما به سه زبان کمک می‌کند.