سنجش تأخیر واقعاً چطور کار می‌کند و interval و tolerance و lazy چه باید باشند

آن عدد میلی‌ثانیه‌ای کنار هر گره از کجا می‌آید؟ چرا این‌قدر با چیزی که ping می‌گوید فاصله دارد؟ و چرا گروه خودکار مدام عوض می‌کند؟

این نوشته کل ماجرای سنجش تأخیر را باز می‌کند.

این ping نیست، یک درخواست کامل HTTP است

گام‌هایی که Clash طی می‌کند:

این با ping تفاوت بنیادی دارد:

پس اینکه Clash عدد ۱۸۰ میلی‌ثانیه نشان بدهد و ping بگوید ۶۰، کاملاً طبیعی است — تفاوت از هزینهٔ دست‌دادن به‌علاوهٔ مسیر گره تا سایت هدف می‌آید.

unified-delay: قابل‌مقایسه کردن پروتکل‌ها

هزینهٔ دست‌دادن میان پروتکل‌ها خیلی فرق دارد. Trojan (با TLS) ذاتاً یک رفت‌وبرگشت بیشتر از Shadowsocks (بدون TLS) خرج می‌کند، و Hysteria2 روی QUIC باز داستان دیگری است.

مقایسهٔ عدد خام نسبت به بعضی پروتکل‌ها ناعادلانه است. این را روشن کنید:

unified-delay: true

هسته دست‌دادن را دو بار می‌سنجد، هزینهٔ ذاتی پروتکل را کم می‌کند و فقط بخش قابل‌مقایسه را نگه می‌دارد.

سه پارامتر مهم

- name: "♻️ خودکار"
  type: url-test
  proxies: [...]
  url: "http://www.gstatic.com/generate_204"
  interval: 300
  tolerance: 50
  lazy: true
  timeout: 5000
  max-failed-times: 5

interval: هر چند وقت بسنجیم

tolerance: مهم‌ترین و پرت‌شده‌ترین

رواداری برحسب میلی‌ثانیه. یعنی: گرهٔ تازه باید این‌قدر سریع‌تر باشد تا تعویض بیارزد.

مقدارهای پیشنهادی:

• تأخیر گره‌ها عمدتاً زیر ۱۰۰ میلی‌ثانیه ← tolerance: 30
• عمدتاً ۱۰۰ تا ۳۰۰ ← tolerance: 50
• پراکندگی زیاد ← tolerance: 100

lazy: در بی‌کاری نسنج

lazy: true

با این پارامتر، وقتی همین الان ترافیکی از گروه نمی‌گذرد، سنجش رد می‌شود.

مزیت‌ها: صرفه‌جویی در باتری و ترافیک، و نبود اتصال‌های بیهوده. روی لپ‌تاپ و گوشی به‌ویژه محسوس است.

بها: وقتی به گروه برمی‌گردید، انتخاب اول ممکن است بر پایهٔ دادهٔ کهنه باشد تا یک دور سنجش کامل شود.

برای استفادهٔ روزمره روشنش کنید.

timeout و max-failed-times

timeout: 5000            # مهلت یک سنجش، برحسب میلی‌ثانیه
max-failed-times: 5      # چند شکست پیاپی تا گره مرده حساب شود

timeout خیلی کوتاه گره‌های کند را نادرست غیرقابل‌استفاده می‌شمارد؛ خیلی بلند هر دور را طولانی می‌کند. ۵۰۰۰ میلی‌ثانیه مقدار معقولی است.

انتخاب URL سنجش

مقدار پیش‌فرض http://www.gstatic.com/generate_204 دو ویژگی دارد: پاسخ خالی ۲۰۴ برمی‌گرداند (تقریباً هیچ داده‌ای منتقل نمی‌شود) و روی یک CDN جهانی مستقر است.

جایگزین‌ها:

تأخیر کم مساوی سرعت زیاد نیست

این نکته‌ای است که بیش از همه به روشن شدن نیاز دارد.

url-test فقط تأخیر را می‌سنجد. اینکه گره‌ای بار سنگین را تاب می‌آورد یا نه فقط با دانلود واقعی چیزی معلوم می‌شود.

اگر کاربرد اصلی‌تان ویدیو و فایل‌های بزرگ است، کاملاً به گروه خودکار تکیه نکنید — چند گره را خودتان بسنجید و برنده را با گروه select ثابت کنید.

یک چیدمان مفید: سنجش لایه‌ای

proxy-groups:
  # گروه اصلی: رواداری کم، سنجش مکرر، دنبال پاسخ‌گویی
  - name: "⚡ پاسخ‌گو"
    type: url-test
    include-all: true
    filter: "(?i)HK|Hong|JP|Japan"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 30
    lazy: true

  # ترافیک سنگین: رواداری بالا، تعویض کم، تا دانلود قطع نشود
  - name: "📦 انتقال حجیم"
    type: fallback
    include-all: true
    filter: "(?i)IPLC|dedicated|premium"
    interval: 600

  # بیمه: هر چیزی که کار کند
  - name: "🛡 پشتیبان نهایی"
    type: fallback
    include-all: true
    interval: 900

چرا انتقال حجیم از fallback استفاده می‌کند نه url-test: هنگام دانلود یا تماشای ویدیو بدترین چیز عوض شدن گره وسط کار است — اتصال می‌شکند و پیشرفت از دست می‌رود. fallback فقط وقتی گرهٔ فعلی واقعاً بمیرد عوض می‌کند و به‌مراتب پایدارتر است.

سنجش دستی، به‌درستی

آیکون آذرخش در رابط یک دور برای گروه فعلی اجرا می‌کند. چند نکته:

راه انداختن سنجش از راه API

هنگام نوشتن اسکریپت مفید است:

# سنجش یک گره
curl "http://127.0.0.1:9090/proxies/HK-01/delay?timeout=5000&url=http%3A%2F%2Fwww.gstatic.com%2Fgenerate_204" \
  -H "Authorization: Bearer secret-شما"

# سنجش یک گروه کامل
curl "http://127.0.0.1:9090/group/%E2%99%BB%EF%B8%8F%20Auto/delay?timeout=5000&url=..." \
  -H "Authorization: Bearer secret-شما"

نام گروه‌هایی که فاصله یا ایموجی دارند باید URL-encode شوند.

خلاصه

• رفت‌وبرگشت کامل تا سایت هدف از راه گره سنجیده می‌شود که با ping یکی نیست
• همیشه tolerance بگذارید؛ عدد ۵۰ نقطهٔ شروع خوبی است و بدونش گروه این‌ور و آن‌ور می‌پرد
• برای interval عدد ۳۰۰ بگذارید؛ خیلی کمتر از آن می‌تواند کنترل ریسک ارائه‌دهنده را فعال کند
• lazy را روشن بگذارید تا در باتری و ترافیک صرفه‌جویی شود
• unified-delay را فعال کنید تا گره‌های پروتکل‌های مختلف قابل‌مقایسه شوند
• تأخیر دربارهٔ پهنای باند چیزی نمی‌گوید — برای انتقال‌های سنگین fallback بردارید نه url-test

بیشتر بخوانید: پنج نوع proxy-groups و نام‌گذاری گره و گروه‌بندی خودکار.

مستندات مرتبط

مبانی پیکربندی ساختار YAML پیکربندی Clash — هرکدام از هشت فیلد سطح بالا چه کار می‌کنند

یک پیکربندی Clash / Mihomo از بالا تا پایین باز می‌شود — پورت‌ها، حالت، DNS، proxies، proxy-groups، rules و rule-providers — به‌همراه یک پیکربندی کمینهٔ کارآمد که مستقیم می‌شود چسباند.

2026-08-021413 واژه3 دقیقه مطالعه

مبانی پیکربندی پنج نوع proxy-groups — انواع select و url-test و fallback و load-balance و relay

هر گروه سیاست واقعاً چه می‌کند، کِی به کارش ببریم، کدام پارامترها مهم‌اند، به‌علاوهٔ یک ساختار گروه‌بندی آمادهٔ کپی و گزینه‌های include-all و filter در Mihomo.

2026-07-291503 واژه4 دقیقه مطالعه

مبانی پیکربندی توسعهٔ اشتراک با Merge، تا ویرایش‌هایتان از به‌روزرسانی جان به در ببرند

ویرایش پیکربندی دانلودشده در به‌روزرسانی بعدی از بین می‌رود. پیکربندی توسعه‌یافتهٔ Clash Verge چطور کار می‌کند: نحو prepend/append/override، ترتیب ادغام، و مجموعه‌ای از قطعه‌های کاربردی.

2026-07-091299 واژه3 دقیقه مطالعه