پایش (Monitoring)
پایش همهٔ خروجی‌ها و endpointها را در پس‌زمینه تست می‌کند: تأخیر هر کدام را اندازه می‌گیرد و
نشانی IP و کشوری را که ترافیک از آن خارج می‌شود پیدا می‌کند. گروه‌هایی مثل
متعادل‌کننده اعضا را از روی این نتایج انتخاب می‌کنند و اپ آن‌ها را نشان
می‌دهد. پایش همیشه روشن است. تنظیماتش فیلد monitoring در بخش experimental است.
چرا از آن استفاده کنیم
- گروه‌هایی که از آن استفاده می‌کنند یک برنامهٔ تست مشترک برای کل پیکربندی دارند.
- برای هر سرور، علاوه بر تأخیر، نشانی IP خروجی، کشور و ارائه‌دهنده را می‌بینید.
- تست‌ها فقط وقتی اجرا می‌شوند که از اتصال استفاده می‌کنید، پس دستگاه بیکار مدام تست نمی‌کند.
- نتایج ذخیره می‌شوند، پس گروه‌ها درست پس از شروع، پیش از تمام شدن تست‌های تازه، می‌توانند انتخاب کنند.
چطور از فیلترینگ عبور می‌کند
خودش عبور نمی‌دهد. پیدا می‌کند کدام خروجی‌ها کار می‌کنند تا گروه‌ها از مسدودها دوری کنند.
چطور کار می‌کند
چه چیزی تست می‌شود
- همهٔ خروجی‌ها و endpointها تست می‌شوند، به‌جز گروه‌ها. هر تست نشانی تست URL را از طریق
خروجی باز می‌کند و تأخیر را اندازه می‌گیرد، همان‌طور که گروه URL test می‌کند. تستی که ناموفق
باشد یا بیش از
url_test_timeoutطول بکشد، خروجی را ناموفق علامت می‌زند. - نتیجهٔ یک گروه، نتیجهٔ عضو انتخاب‌شدهٔ آن است. اگر چنین عضوی نداشته باشد، بهترین نتیجه میان اعضایش است.
- پس از تست موفق، پایش از طریق همان خروجی از یک سرویس اطلاعات IP، نشانی IP خروجی، کشور، منطقه، شهر و شبکه را می‌پرسد. این کار را وقتی می‌کند که خروجی هنوز اطلاعات IP ندارد، یا فقط اطلاعات خوانده‌شده از کش دارد. اگر این درخواست از تست URL سریع‌تر باشد، زمانش تأخیر حساب می‌شود.
- خروجی‌ای که از طریق یک detour شماره‌گیری می‌کند، برای تأخیر و IPاش، فقط وقتی تست می‌شود که خروجی‌ای که detour به آن می‌رسد (برای گروه، عضو انتخاب‌شده‌اش) در این اجرا نتیجه داشته باشد و در حال تست دوباره نباشد. پیش از آن، تستش ناموفق می‌شد یا مسیری را می‌سنجید که در حال عوض‌شدن است.
تست‌ها کی اجرا می‌شوند
- تست‌ها با شروع sing-box آغاز می‌شوند. اول، خروجی‌ای که انتخاب هر گروه به آن می‌رسد (انتخاب
selector، عضو فعلی متعادل‌کننده، از میان گروه‌های تودرتو) پیش از همه تست می‌شود تا پینگی که
کاربر به آن نگاه می‌کند بی‌درنگ نشان داده شود. سپس تست‌ها در دوره‌هایی به فاصلهٔ
intervalاجرا می‌شوند. هر دوره خروجی‌هایی را تست می‌کند که نتیجه‌شان ازintervalقدیمی‌تر است یا برای تست علامت خورده‌اند، سریع‌ترها اول (بر اساس آخرین نتیجه، کش‌شده یا نه)، سپس تست‌نشده‌ها، و هر بارworkersتا با هم. پس دورهٔ اول، سریع‌ترین عضو اجرای قبل را اول تست می‌کند و گروهی که روی آن عضو است پیش از رسیدن بقیه آن را تأیید می‌کند. - اگر به مدت
idle_timeoutهیچ اتصالی از sing-box نگذرد، تست متوقف می‌شود. اتصال بعدی دوباره آن را راه می‌اندازد. - خروجی‌ای که هنوز آماده نیست، مثلاً سایفونی که هنوز در حال اتصال است، یا detourش هنوز نتیجه‌ای ندارد، رد می‌شود و ۳ ثانیه بعد دوباره امتحان می‌شود. پس از ۱۰ بار، به هر حال تست می‌شود.
- وقتی خروجی‌ای پس از ناموفق بودن کار کند، خروجی‌هایی که از طریق آن تست شده‌اند دوباره تست می‌شوند.
- بعضی رویدادها بی‌درنگ تست را اجرا می‌کنند: اتصالی که از طریق یک عضو متعادل‌کننده ناموفق
شود، selectorی که به خروجی دیگری جابه‌جا شود (انتخاب جدید تست می‌شود و خروجی‌های وابسته به
selector هم دوباره)، یا خروجی‌ای که اتصالش کامل شده، مثل سایفون یا DNSTT. چنین تستی همان
لحظه اجرا می‌شود، کنار تست‌های دوره نه پشت آن‌ها: منتظر یکی از
workersنمی‌ماند که یک دورهٔ پر از timeout می‌تواند چند ثانیه نگهشان دارد. نتیجه‌اش بی‌درنگ، بدون انتظارdebounce_window، به مشترکان گروه‌ها می‌رسد. - تست درخواستی مرحله‌ای اجرا می‌شود، با
on_demand_timeouts(۱، ۳ و ۱۰ ثانیه اگر تنظیم نشده باشد). تلاش اول همان لحظه شروع می‌شود. اگر ناموفق باشد یا تا مرحلهٔ اول پاسخی نیامده باشد، خروجی فعلاً «قطع» نشان داده می‌شود. تلاش ناموفق در مرحلهٔ بعد دوباره انجام می‌شود؛ همین‌طور در هر مرحله به‌جز آخری که مهلت همهٔ تلاش‌هاست. تلاشی که در یک مرحله هنوز در جریان است به حال خود می‌ماند تا پاسخ دهد، پس هر پروکسی یک بار پینگ می‌شود مگر پینگش ناموفق باشد. پاسخ بی‌درنگ نشان داده می‌شود، هرچقدر هم دیر: پاسخی در ۱٫۵ ثانیه جای «قطع» ثانیهٔ اول را می‌گیرد. وقتی آخرین تلاش ناموفق باشد و مرحله‌ای برای تلاش دیگر نمانده باشد، بدون انتظار مهلت تمام می‌شود. تستی که وقتی تست دیگری از همان خروجی در جریان است درخواست شود (تست دوره، یا ضربهٔ قبلی) به آن می‌پیوندد و نتیجه‌اش را می‌گیرد: هر خروجی هر بار یک پینگ. دو تست هم‌زمان پروکسی را دو بار پینگ می‌کردند و هر کدام دیرتر تمام می‌شد نتیجه را می‌نوشت، پس شکستی دیرهنگام جای پاسخ تازه را می‌گرفت. انتخاب تازهٔ یک گروه، اگر در ۱۵ ثانیهٔ گذشته اندازه گرفته شده باشد، دوباره تست نمی‌شود: زیر بار، آن پینگ دوم برای عضوی ۵۹ میلی‌ثانیه‌ای ۲۵۴۹ میلی‌ثانیه خواند و گروه رفت. - لاگ می‌گوید هر تست چرا اجرا می‌شود و هر گروه lowest-delay چه تصمیمی می‌گیرد: خط‌هایی با
پیشوند
MONITORING(تست، نتیجه، دوره، مرحله‌های تست مرحله‌ای) وLOWEST(عضو نگه‌داشته یا گرفته‌شده، با سریع‌ترین عضو و دلیل)، در سطح info. مرحلهٔ اول برای خروجی‌ای است که هنوز چیزی از آن معلوم نیست: نتیجه‌ای در این اجرا ندارد، یا فقط نتیجهٔ ذخیره‌شدهٔ اجرای قبل را دارد. خروجی‌ای که در این اجرا کار کرده نتیجه‌اش را از آن مرحله هم نگه می‌دارد، به‌جای این‌که با یک پاسخ کند «قطع» نشان داده شود، و مرحله‌هایش از مرحلهٔ دوم شروع می‌شوند (۳ ثانیه، بعد مهلت ۱۰ ثانیه). گروه‌ها این «قطع» موقت را نمی‌بینند و فقط آخرین نتیجهٔ قطعی را دارند، پس متعادل‌کننده عضو کندی را به خاطر قطعی که تلاش بعدی پاسخش را می‌دهد مرده نمی‌گیرد و اتصال‌هایش را نمی‌برد. - تأخیر هر تست به محض پاسخ تست URL منتشر می‌شود. جست‌وجوی IP که پس از آن می‌آید و می‌تواند همان‌قدر طول بکشد، اطلاعات IP را وقتی تمام شد می‌آورد.
- وقتی شبکه عوض شود، همهٔ خروجی‌ها ۲ ثانیه پس از آخرین تغییر دوباره تست می‌شوند. تستی که با بازنشانی شبکه قطع شده باشد دوباره اجرا می‌شود.
- تستی که پس از سه برابر
url_test_timeoutبه‌علاوهٔ ۲ ثانیه برنگشته باشد (خروجی‌ای که شماره‌گیری‌اش مهلتش را نادیده می‌گیرد، چنان‌که شماره‌گیری به یک کتابخانهٔ بومی ممکن است) ناموفق حساب می‌شود و worker آن به تست بعدی می‌رود. وگرنه چند خروجی از این دست همهٔ workerها و دوره را برای همیشه نگه می‌داشتند و دیگر هیچ چیز تست نمی‌شد.
نشانی‌ها
تست‌ها از اولین نشانی urls استفاده می‌کنند. اگر یک دورهٔ کامل هیچ تست موفقی نداشته باشد،
دوره با نشانی بعدی تکرار می‌شود، تا یکی کار کند یا فهرست تمام شود. نشانی‌ای که کار کرده از آن
به بعد به کار می‌رود.
نتایج ذخیره‌شده
نتایج در فایل کش ذخیره می‌شوند و در شروع بعدی خوانده می‌شوند. نتیجهٔ خوانده‌شده تا تست دوبارهٔ خروجی «از کش» علامت می‌خورد. متعادل‌کننده به این نتایج ۲۰٬۰۰۰ میلی‌ثانیه اضافه می‌کند تا تست تازه برنده شود.
اطلاعات IP هم خوانده می‌شود تا برنامه پیش از هر تستی IP و کشور خروجیِ اجرای قبل را نشان دهد.
این اطلاعات تا وقتی جست‌وجوی IP در این اجرا موفق شود، «از کش» (IpInfoFromCache) علامت
می‌خورد؛ تست ناموفق آن را عوض نمی‌کند. IP خروجی WARP، سایفون یا پراکسی چرخشی ممکن است بین
اجراها عوض شود، پس برنامه باید چنین IPای را هنوز تأییدنشده نشان دهد.
تست ناموفق خطای خود را در نتیجه (Error) نگه می‌دارد تا برنامه بگوید چرا پراکسی ناموفق شد:
دست‌دادنِ ردشده، پایان مهلت، خطای DNS. تستی که پاسخ بگیرد آن را پاک می‌کند. خروجی‌ای که آماده
نیست تست نمی‌شود و خطای تست ندارد؛ WARP و MASQUE به جای آن از راه adapter.StatusError می‌گویند
چرا آماده نیستند (ثبت‌نامِ ردشده، تونلی که وصل نمی‌شود).
گروه‌هایی که مشترک پایش‌اند، برای مجموعه‌ای از نتایج پشت سر هم، پس از debounce_window یک
به‌روزرسانی می‌گیرند.
سرویس‌های اطلاعات IP
اگر ipinfo_url تنظیم شده باشد، اول امتحان می‌شود. باید JSONی مثل ipapi.co برگرداند، با
فیلدهایی مثل ip، country_code، region، city، asn و org. اگر ناموفق باشد، این
سرویس‌ها به نوبت امتحان می‌شوند، با شروع از یکی به‌تصادف:
- ipapi.co
- ip-api.com
- ipinfo.io
- api.ip.sb
- ipwho.is
- api.country.is
- api.my-ip.io
وقتی همهٔ این‌ها ناموفق باشند، چنان‌که در شبکهٔ شلوغ با محدودیت نرخ یا timeout می‌شوند، از
cloudflare.com/cdn-cgi/trace خود Cloudflare، همراه api.country.is و api.my-ip.io پرسیده
می‌شود: فقط نشانی و کشور را پاسخ می‌دهد، بی محدودیت نرخ.
پیکربندی
{
"experimental": {
"monitoring": {
"interval": "5m",
"urls": [
"https://www.gstatic.com/generate_204",
"https://cp.cloudflare.com"
],
"url_test_timeout": "5s",
"on_demand_timeouts": ["1s", "3s", "10s"],
"idle_timeout": "10m"
}
}
}
| فیلد | نوع | پیش‌فرض | معنی |
|---|---|---|---|
interval |
duration | 5m |
هر چند وقت خروجی‌ها تست شوند. |
urls |
list of strings | ["https://www.gstatic.com/generate_204"] |
نشانی‌های تست، به ترتیب ترجیح. |
ipinfo_url |
string | "" |
یک سرویس اطلاعات IP که اول امتحان می‌شود، مثلاً از اشتراک شما. |
verify_ipv6 |
bool | false |
پس از تست URL هر خروجی، همان URL یک بار دیگر از نشانی IPv6 میزبان از طریق آن گرفته می‌شود، یک بار در هر اجرا، تا معلوم شود خروجی IPv6 را رد می‌کند یا نه؛ IPv6 بر اساس خروجی را ببینید. |
ipv6_declared |
شیء، تگ به bool | خروجی‌هایی که لینک IPv6شان را اعلام کرده (ipv6=1، ipv6=0)؛ از ابتدا دانسته است. |
|
ipv6_probe |
بازنشسته، بی‌اثر. | ||
workers |
int | 10 |
تعداد تست‌های هم‌زمان. |
url_test_timeout |
duration | 5s |
بیشترین زمان یک تست دوره، و یک درخواست اطلاعات IP. |
on_demand_timeouts |
list of durations | ["1s", "3s", "10s"] |
مرحله‌های تست درخواستی: در اولی بدون پاسخ فعلاً «قطع»، تلاش ناموفق در هر یک به‌جز آخری دوباره، آخری مهلت همه. مرحلهٔ اول برای خروجی‌ای که در این اجرا کار کرده رد می‌شود. |
idle_timeout |
duration | 10m |
پس از این مدت بدون اتصال، تست متوقف شود. |
debounce_window |
duration | 500ms |
مدت جمع کردن نتایج پیش از به‌روزرسانی گروه‌ها. |
سرویس‌های اطلاعات IP درخواستی از نشانی IP خروجی هر خروجی دریافت می‌کنند.