رفتن به محتوای اصلی
FA

خانه / وبلاگ / DNS و شبکه

ترافیک و تعداد اتصال و گذردهی — پیدا کردن ریشهٔ مشکل از صفحهٔ اتصال‌ها

DNS و شبکه2026-05-201426 واژه3 دقیقه مطالعه
ترافیک و تعداد اتصال و گذردهی — پیدا کردن ریشهٔ مشکل از صفحهٔ اتصال‌ها

«کند است»، «سهمیهٔ ترافیکم ناپدید شد» و «کلاینت حافظهٔ زیادی می‌خورد» — پاسخ هر سه در صفحهٔ اتصال‌ها زندگی می‌کند.

شش ستون

ستونمعنیارزش تشخیصی
Hostدامنه یا IP مقصدنشان می‌دهد به چه چیزی دسترسی گرفته می‌شود
Ruleقاعده‌ای که تطبیق خوردهمی‌گوید مسیریابی درست است یا نه
Chainزنجیرهٔ سیاستی که در نهایت به کار رفتهتأیید می‌کند کدام گره برداشته شده
Processبرنامه‌ای که اتصال را باز کردهنشان می‌دهد چه کسی به شبکه رفته
DL / ULترافیک انباشتهٔ این اتصالمصرف‌کننده‌های سنگین را پیدا می‌کند
Timeچه مدت اتصال باز بودهاتصال‌های طولانی را نشان می‌دهد

ستون Chain مسیر کامل را نشان می‌دهد، مثلاً 🚀 انتخاب ← ♻️ خودکار ← HK-01، از چپ به راست بر پایهٔ تودرتویی گروه‌های سیاست، و خروجی واقعی سمت راست.

حالت ۱: چه چیزی ترافیکم را می‌خورد

بر اساس ستون DL نزولی مرتب کنید و ده تای بالا را ببینید.

مصرف‌کننده‌های سنگین رایج1به‌روزرسانی سیستمWindows Update یا به‌روزرسانی مک، هر بار چند گیگابایت2همگام‌سازی فضای ابریOneDrive و iCloud و امثالشان در پس‌زمینه همگام می‌شوند3پخش خودکار ویدیوزبانهٔ باز مرورگری که ویدیو را حلقه‌وار پخش می‌کند4به‌روزرسانی سکوهای بازیSteam در پس‌زمینه بازی‌ها را به‌روز می‌کند5بیت‌تورنت P2P6تله‌متری و گزارش لاگحجمش کم است ولی تعداد اتصال زیاد
ستون Process می‌گوید کدام برنامه است

بعد از پیدا کردنش دو راه دارید:

مستقیمش کنید (پیشنهادی، تا از طرحتان خرج نکند):

prepend-rules:
  - PROCESS-NAME,OneDrive.exe,DIRECT
  - PROCESS-NAME,SteamService.exe,DIRECT
  - DOMAIN-SUFFIX,windowsupdate.com,DIRECT

کاملاً مسدودش کنید:

prepend-rules:
  - DOMAIN-SUFFIX,یک-دامنهٔ-تله‌متری,REJECT

قواعد فرایندی به find-process-mode: strict نیاز دارند؛ توضیح قواعد فرایندی را ببینید.

حالت ۲: تعداد اتصال منفجر می‌شود

مرور معمولی در حد چند ده است. اگر صدها یا هزاران دیدید و رو به بالا بود:

چطور بررسی کنیمروی «بستن همهٔ اتصال‌ها» بزنیدفهرست فعلی را پاک می‌کندچند ثانیه نگاه کنیدببینید کدام‌ها فوری برمی‌گردندبر اساس Process گروه کنیدبرنامه‌ای که بیشتر از همه دوباره وصل می‌شود را پیدا کنیدعلت را تعیین کنیدتلاش دوباره است یا برنامه ذاتاً چنداتصاله است
آن‌هایی که فوری برمی‌گردند مشکل شمایند

علت‌های رایج:

چه می‌بینیدعلت
یک دامنه مدام پیدا می‌شود و سریع ناپدید می‌شوداتصال‌های ناموفق دوباره تلاش می‌کنند. ببینید گره‌ای که آن قاعده به آن اشاره می‌کند قابل استفاده هست یا نه
اتصال‌های زیاد به یک بازهٔ IPیک برنامهٔ P2P (بیت‌تورنت یا شتاب P2P یک فضای ابری)
شمارنده آرام بالا می‌رود و پایین نمی‌آیدنشت اتصال، یا برنامه‌ای با اتصال‌های ماندگار (اعلان فوری، WebSocket)
همه از یک فرایندآن برنامه مشکل دارد، یا ذاتاً همروندی بالایی دارد

حالت ۳: گذردهی بالا نمی‌رود

اول مشخص کنید گلوگاه در کدام لایه است:

لایه به لایه1لایهٔ اول — سرعت مستقیمپروکسی را خاموش کنید و یک فایل بزرگ محلی دانلود کنید تا از سلامت اینترنت خودتان مطمئن شوید2لایهٔ دوم — پهنای باند گرهبه گرهٔ دیگری بروید و مقایسه کنید؛ تفاوت بزرگ به گره اشاره دارد3لایهٔ سوم — سربار پروتکلپروتکل‌های مبتنی بر QUIC مثل Hysteria2 روی لینک‌های پرافت بهتر عمل می‌کنند4لایهٔ چهارم — پیکربندی کلاینتپشتهٔ TUN و MTU و اندازهٔ مجموعه‌قواعد همه مهم‌اند5لایهٔ پنجم — کارایی محلیآیا پردازنده پیشاپیش اشباع شده
از بیرون به داخل بروید؛ با عوض کردن پیکربندی شروع نکنید

مشکل از گره است؟

یک فایل بزرگ را از سه گره در سه منطقه دانلود کنید و مقایسه کنید.

  • همه کند ← شبکهٔ محلی یا پیکربندی کلاینت
  • فقط یکی کند ← مشکل آن خط است، گره را عوض کنید
  • روز سریع شب کند ← خط در ساعت اوج شلوغ می‌شود، نشانهٔ خط ارزان مشترک

گلوگاه کلاینت است؟

مصرف پردازنده را ببینید. اگر هنگام دانلود فرایند Clash به اشباع یک هسته نزدیک می‌شود:

کم کردن سربار کلاینتپشتهٔ TUN را از gvisor به system ببرید (کارایی بالاتر)مجموعه‌قواعد را کم کنید و آنچه به کار نمی‌برید را بیندازیدمقدار log-level را از debug به warning ببریدمقدار find-process-mode را از always به strict ببریداگر تشخیص‌دهنده لازم نیست خاموشش کنیدمجموعه‌قواعد را به قالب دودویی mrs ببرید

نشانهٔ عجیبی که MTU می‌سازد

فایل‌های کوچک درست، دانلودهای بزرگ وسط کار گیر می‌کنند.

این از دست رفتن تکه‌ها به‌خاطر MTU بزرگ است. tun.mtu را از ۱۵۰۰ به ۱۴۰۰ پایین بیاورید و امتحان کنید.

پایش پیوسته از راه API

صفحهٔ اتصال‌ها فقط لحظهٔ حال را نشان می‌دهد. برای مشاهدهٔ پیوسته سراغ API بروید.

گذردهی زنده

نقطهٔ پایانی /traffic یک WebSocket است که ثانیه‌ای یک بار می‌فرستد:

{"up": 12345, "down": 678901}

واحدها بایت بر ثانیه‌اند.

websocat "ws://127.0.0.1:9090/traffic?token=secret-شما"

عکس‌های دوره‌ای از تعداد اتصال

#!/bin/bash
# conn-watch.sh
API="http://127.0.0.1:9090"
SECRET="secret-شما"

while true; do
  N=$(curl -s -H "Authorization: Bearer $SECRET" "$API/connections" | jq '.connections | length')
  echo "$(date '+%F %T') اتصال‌ها=$N"
  [ "$N" -gt 500 ] && echo "  ⚠ تعداد اتصال غیرعادی به نظر می‌رسد"
  sleep 30
done

ده تای برتر بر پایهٔ ترافیک

curl -s -H "Authorization: Bearer $SECRET" http://127.0.0.1:9090/connections \
  | jq -r '.connections
      | sort_by(-.download)
      | .[:10][]
      | "\(.download/1048576 | floor)MB\t\(.metadata.host // .metadata.destinationIP)\t\(.metadata.processPath // "-")"'

ترافیک به‌ازای گروه سیاست

curl -s -H "Authorization: Bearer $SECRET" http://127.0.0.1:9090/connections \
  | jq -r '.connections
      | group_by(.chains[-1])
      | map({node: .[0].chains[-1], mb: ([.[].download] | add / 1048576 | floor)})
      | sort_by(-.mb)[]
      | "\(.mb)MB\t\(.node)"'

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

بررسی مصرف حافظه

حافظهٔ Clash Verge به سه جا می‌رود:

ترکیب حافظه (نسبت تقریبی)WebView رابطبستن پنجره یا حالت سبک آزادش می‌کندمجموعه‌قواعد و پایگاه دادهٔ GeoIPصدها هزار قاعده صدها مگابایت خرج می‌گذارداتصال‌های فعال و بافرهابا تعداد اتصال رشد می‌کندسربار پایهٔ هستهبخش ثابتنسبت‌ها با اندازهٔ پیکربندی جابه‌جا می‌شوند؛ این را فقط کمک جهت‌یابی بدانید

راه‌حل‌های متناظر:

  • رابط بیشترین سهم را دارد ← «auto enter lite mode» را روشن کنید تا وقتی نگاهش نمی‌کنید WebView آزاد شود
  • مجموعه‌قواعد بیشترین سهم را دارند ← کمشان کنید یا به قالب mrs بروید
  • اتصال‌ها بیشترین سهم را دارند ← دوره‌ای اتصال‌ها را پاک کنید و دنبال نشت بگردید

نکته‌ای که راحت از قلم می‌افتد: آمار برابر با صورت‌حساب نیست

ترافیکی که کلاینت نشان می‌دهد و مصرفی که در پنل ارائه‌دهنده هست اغلب نمی‌خوانند، چون:

چرا عددها فرق دارندنقطهٔ اندازه‌گیری متفاوتکلاینت دادهٔ لایهٔ کاربرد را می‌شمارد، ارائه‌دهنده بایت واقعاً منتقل‌شده را با سربار پروتکلترافیک مستقیم صورت‌حساب نمی‌شودکلاینت همه را می‌شمارد، ارائه‌دهنده فقط آنچه از گره گذشتهضریب‌هاگره‌ای که 2x علامت خورده دو برابر آنچه کلاینت نشان می‌دهد مصرف می‌کنددورهٔ شمارشکلاینت با راه‌اندازی دوباره صفر می‌شود، ارائه‌دهنده ماهانه جمع می‌کند
عدد پنل ارائه‌دهنده را مرجع بدانید

خلاصه

  • ترافیک غیرمنتظره ← بر اساس DL مرتب کنید و ستون Process را بخوانید
  • انفجار تعداد اتصال ← فهرست را پاک کنید و ببینید چه چیزی فوری برمی‌گردد
  • گذردهی بالا نمی‌رود ← لایه‌ها را طی کنید: محلی ← گره ← پروتکل ← کلاینت ← پردازنده
  • حافظهٔ بالا ← حالت سبک به‌علاوهٔ مجموعه‌قواعد کم‌شده
  • پیوسته از راه API بپایید؛ /connections و /traffic تمام آن چیزی است که لازم دارید
  • به عدد ترافیک ارائه‌دهنده اعتماد کنید؛ عدد کلاینت فقط مرجع است

بیشتر بخوانید: راهنمای API کنترل و توضیح قواعد فرایندی.


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

پیکربندی DNS در Clash — fake-ip یا redir-host؟
DNS و شبکه پیکربندی DNS در Clash — fake-ip یا redir-host؟

fake-ip واقعاً چطور کار می‌کند، چه فرقی با redir-host دارد، تقسیم کار میان nameserver و fallback، چطور جلوی نشت DNS را بگیریم، و چرا نام‌های داخلی از حل شدن بازمی‌مانند.

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