پهنای باند سرور مجازی — ترافیک ماهانه را چطور اندازه بگیریم و کم کنیم

فروشنده می‌گوید «پورت یک گیگابیت با ۵ ترابایت ترافیک ماهانه» و شما نمی‌دانید کدام عدد اول تمام می‌شود؛ بعد هم پنل هاست رقمی نشان می‌دهد که با عدد خود سرور جور درنمی‌آید. در این راهنما می‌بینید پهنای باند و ترافیک چه فرقی دارند، سرویس‌دهنده کجا اندازه می‌گیرد، چطور با vnstat و شمارنده‌های کرنل عدد درست را دربیاورید و کدام کارها واقعاً مصرف را نصف می‌کنند.

پهنای باند و ترافیک دو چیز کاملاً متفاوت‌اند

تقریباً همه‌ی سوءتفاهم‌های صورت‌حساب از این‌جا شروع می‌شود که یک کلمه برای دو مفهوم متفاوت به‌کار می‌رود:

• پهنای باند (bandwidth) یک ظرفیت است، نه انبار. واحدش بیت بر ثانیه است و می‌گوید در هر ثانیه حداکثر چقدر داده می‌تواند از پورت شبکه رد شود. مثل قطر لوله‌ی آب.
• ترافیک یا مصرف (transfer) یک حجم است. واحدش گیگابایت یا ترابایت در ماه است و می‌گوید در یک دوره‌ی صورت‌حساب مجموعاً چند بایت جابه‌جا شده. مثل کنتور آب.

لوله‌ی گشاد گران نیست؛ آبی که از آن رد می‌شود گران است. برای همین سرویس‌دهنده پورت ۱ گیگابیت را رایگان می‌دهد ولی روی حجم ماهانه سخت‌گیری می‌کند. برای درک مقیاس، پورت ۱ گیگابیتی را تصور کنید که بدون یک ثانیه وقفه اشباع باشد:

1 Gbps  = 1000 Mbit/s / 8 = 125 MB/s
125 MB/s x 86400 s        = 10,800,000 MB  = 10.8 TB  در روز
10.8 TB x 30              = 324 TB         در ماه

حالا این ۳۲۴ ترابایت را کنار سهمیه‌ی معمول بگذارید: پلنی با ۵ ترابایت ترافیک ماهانه یعنی اجازه دارید حدود ۱.۵ درصد ظرفیت تئوریک آن پورت را مصرف کنید. برعکسش هم گویاست؛ همان ۵ ترابایت اگر یکنواخت روی ماه پخش شود میانگین پایداری در حد ۱۵ مگابیت بر ثانیه است. پورت گیگابیتی برای شما یک ظرفیت لحظه‌ای است، نه یک وعده‌ی دائمی.

و اما «پهنای باند نامحدود»: در عمل یکی از این دو مدل پشتش است. یا سهمیه‌ای نانوشته به‌اسم fair usage دارد که بعد از عبور از آن پورت را از ۱ گیگابیت به ۱۰۰ یا حتی ۱۰ مگابیت می‌آورند (throttle)، یا پورت از اول کند بسته شده و «نامحدود» فقط یعنی روی حجم حسابرسی نمی‌کنند. قبل از خرید صریحاً بپرسید کدام‌یک است — این سؤال در راهنمای خرید سرور مجازی هم جزو معیارهای اصلی آمده.

جهت ترافیک: ورودی، خروجی، و این‌که کدام را از شما می‌گیرند

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

• ورودی / ingress (rx) — داده‌ای که به سرور می‌رسد: درخواست‌های HTTP، آپلود فایل، دانلود بسته‌ها با apt، و پکت‌های حمله.
• خروجی / egress (tx) — داده‌ای که سرور می‌فرستد: صفحه‌ها و تصاویر و ویدیوها، پاسخ API، بکاپی که به بیرون می‌رود.

این دو برای یک وب‌سرور هم‌اندازه نیستند: درخواست مرورگر چند صد بایت هدر است و پاسخش می‌تواند ۲۰۰ کیلوبایت باشد؛ حتی با احتساب ACKهای TCP، نسبت خروجی به ورودی روی یک سایت معمولی بین ۱۰ تا ۳۰ برابر درمی‌آید. برعکسش، روی سروری که مقصد بکاپ است یا کاربران در آن فایل آپلود می‌کنند ورودی بزرگ‌تر است.

و نکته‌ی پولی: بیشتر سرویس‌دهنده‌های بزرگ فقط خروجی را حساب می‌کنند و ورودی رایگان است، چون خروجیِ آن‌ها به شبکه‌ی بالادست همان چیزی است که برایشان خرج دارد. بعضی‌ها مجموع دو جهت را می‌شمارند و بعضی‌ها «هرکدام که بیشتر بود». برای فهمیدن مدلتان، به‌جای خواندن قرارداد عدد پنل را با عدد خود سرور مقایسه کنید:

vnstat -d -i eth0        # rx / tx تفکیک‌شده به تفکیک روز

اگر عدد پنل تقریباً برابر tx بود فقط خروجی را می‌فروشند؛ اگر نزدیک rx + tx بود مجموع را می‌شمارند. اگر با هیچ‌کدام جور نبود، مستقیم بپرسید.

اندازه‌گیری روی خود سرور، با ابزارهای واقعی

اول ببینید کدام کارت شبکه مسیر خروجی شماست؛ روی خیلی از سرورها چند اینترفیس هست (lo، docker0، تونل‌ها) و اندازه‌گیری روی اینترفیس اشتباه یعنی نتیجه‌ی بی‌معنی:

ip -o -4 route show to default | awk '{print $5}'
# eth0

vnstat — تنها ابزاری که تاریخچه نگه می‌دارد

vnstat یک دیمن سبک است که هر چند ثانیه شمارنده‌های کرنل را می‌خواند و در یک دیتابیس SQLite نگه می‌دارد. مصرف منابعش عملاً صفر است:

sudo apt install vnstat          # Debian / Ubuntu
sudo dnf install vnstat          # AlmaLinux / Rocky
sudo systemctl enable --now vnstat

vnstat                 # خلاصه‌ی کلی
vnstat -d              # تفکیک روزانه
vnstat -m              # تفکیک ماهانه — همانی که با صورت‌حساب مقایسه می‌کنید
vnstat -h              # ۲۴ ساعت گذشته، ساعت‌به‌ساعت
vnstat -t              # پرمصرف‌ترین روزها
vnstat -l              # نمایش زنده
vnstat --json m        # خروجی ماشین‌خوان برای اسکریپت و هشدار

 eth0  /  monthly

       month        rx      |     tx      |    total    |   avg. rate
    ------------+-----------+-------------+-------------+---------------
      2026-06     94.16 GiB |   1.42 TiB  |   1.51 TiB  |    4.79 Mbit/s
      2026-07    118.03 GiB |   2.06 TiB  |   2.18 TiB  |    7.21 Mbit/s

دو نکته که خیلی‌ها را گمراه می‌کند. اول: vnstat فقط از لحظه‌ی نصب به بعد را می‌شمارد، پس همین امروز نصبش کنید تا ماه بعد داده‌ی مستقل داشته باشید. دوم: خروجی پیش‌فرض بر مبنای GiB (ضریب ۱۰۲۴) است ولی فاکتور سرویس‌دهنده معمولاً GB (ضریب ۱۰۰۰)؛ همین به‌تنهایی ۷ درصد اختلاف می‌سازد و در /etc/vnstat.conf قابل تغییر است.

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

sudo apt install iftop nload nethogs

sudo iftop -i eth0 -nNP    # پرترافیک‌ترین اتصال‌ها، با آی‌پی و پورت
nload eth0                 # نمودار ساده‌ی ورودی/خروجی
sudo nethogs eth0          # ترافیک به تفکیک پروسه — برای پیداکردن مقصر بی‌رقیب است

سوییچ‌های -nNP یعنی نام دامنه و سرویس را حل نکن و شماره‌ی پورت را نشان بده؛ بدون آن‌ها خروجی هم کند است و هم برای عیب‌یابی بی‌فایده. nethogs تنها ابزاری است که به سؤال «کدام پروسه؟» جواب می‌دهد و معمولاً همان‌جا معلوم می‌شود مقصر یک اسکریپت PHP یا یک rsync فراموش‌شده است.

شمارنده‌های خام کرنل

زیر همه‌ی این ابزارها یک چیز ساده هست: کرنل برای هر اینترفیس یک شمارنده‌ی تجمعی نگه می‌دارد.

cat /sys/class/net/eth0/statistics/rx_bytes
cat /sys/class/net/eth0/statistics/tx_bytes
cat /proc/net/dev

این‌ها همیشه در دسترس‌اند و نصبی نمی‌خواهند، اما یک تله‌ی جدی دارند: با هر ری‌بوت و حتی با یک ip link set eth0 down/up از صفر شروع می‌شوند. اگر اسکریپت شما کورکورانه «مقدار حالا منهای مقدار ذخیره‌شده» را حساب کند، بعد از ری‌بوت عددی منفی — یا در محاسبات بدون علامت، رقمی نجومی در حد پتابایت — تولید می‌کند. تشخیصش ساده است: اگر مقدار فعلی از مقدار ذخیره‌شده کمتر بود ریست اتفاق افتاده و خودِ مقدار فعلی همان دلتا است:

#!/bin/bash
# NIC counters restart at zero after a reboot or an `ip link` down/up, so a
# blind (current - stored) subtraction invents petabytes of traffic. A reading
# lower than the stored one is the only reliable signature of that reset.
IF=${1:-eth0}
DB=/var/lib/bwsnap-$IF

rx=$(cat /sys/class/net/$IF/statistics/rx_bytes)
tx=$(cat /sys/class/net/$IF/statistics/tx_bytes)

prev_rx=0; prev_tx=0; acc_rx=0; acc_tx=0
[ -r "$DB" ] && read -r prev_rx prev_tx acc_rx acc_tx < "$DB"

if [ "$rx" -lt "$prev_rx" ] || [ "$tx" -lt "$prev_tx" ]; then
    acc_rx=$((acc_rx + rx));            acc_tx=$((acc_tx + tx))
else
    acc_rx=$((acc_rx + rx - prev_rx));  acc_tx=$((acc_tx + tx - prev_tx))
fi

echo "$rx $tx $acc_rx $acc_tx" > "$DB"
printf 'in: %d MB   out: %d MB\n' $((acc_rx / 1048576)) $((acc_tx / 1048576))

*/5 * * * * /usr/local/bin/bwsnap.sh eth0 >/dev/null 2>&1

هر پنج دقیقه کافی است؛ فاصله‌ی کوتاه‌تر دقت اضافه نمی‌کند چون شمارنده تجمعی است و چیزی بین دو نمونه گم نمی‌شود — فقط ریست را زودتر می‌گیرد. الگوی ترکیب این اسکریپت با هشدار تلگرام در راهنمای مانیتورینگ سرور لینوکس آمده است.

چرا عدد شما هیچ‌وقت دقیقاً با عدد سرویس‌دهنده یکی نمی‌شود

این تفاوت همیشه هست و همیشه هم تقلب نیست؛ پنج دلیل واقعی دارد:

• نقطه‌ی اندازه‌گیری. شما داخل سیستم‌عامل مهمان می‌شمارید؛ سرویس‌دهنده روی پورت سوییچ یا اینترفیس tap در سمت هایپروایزر. پیامد مهمش این است: پکتی که فایروال شما دور می‌اندازد، بایت‌هایش قبلاً از پورت رد شده و شمرده شده‌اند — یک اسکن یا حمله‌ی کوچک در صورت‌حساب ظاهر می‌شود بدون اثر متناسب در vnstat.
• سربار لایه‌های پایین. شمارنده‌ی مهمان فریم اترنت را می‌شمارد؛ چیزی که روی سیم می‌رود preamble و فاصله‌ی بین فریم‌ها را هم دارد. برای بسته‌های ۱۵۰۰ بایتی ۲ تا ۳ درصد اختلاف می‌سازد و برای بسته‌های کوچک (API، بازی، DNS) بیشتر.
• فاصله‌ی نمونه‌برداری. خیلی‌ها با SNMP هر پنج دقیقه نمونه می‌گیرند و بین نمونه‌ها را درون‌یابی می‌کنند؛ اوج‌های کوتاه صاف می‌شوند و خطای گردکردن روی هزاران نمونه جمع می‌شود.
• چه چیزی اصلاً شمرده می‌شود. ترافیک IPv6 در بعضی پنل‌ها حساب نمی‌شود؛ ترافیک شبکه‌ی خصوصی و آینه‌های داخلی سرویس‌دهنده هم معمولاً رایگان است ولی vnstat آن را روی همان اینترفیس می‌شمارد.
• مرز دوره. سرور شما احتمالاً روی UTC است و دوره‌ی صورت‌حساب روی وقت تهران بسته می‌شود؛ ۳.۵ ساعت جابه‌جایی در روز آخر ماه چند گیگابایت را به ماه بعد می‌برد.

جمع‌بندی عملی: اختلاف ۲ تا ۵ درصد کاملاً عادی است و تا ۱۰ درصد هم قابل توجیه. اگر اختلاف پایدار از ۱۵ درصد گذشت وقت تیکت‌زدن است — با خروجی vnstat -m و vnstat -d همان بازه، نه با اسکرین‌شات داشبورد.

چه چیزی واقعاً ترافیک می‌خورد — به ترتیب اهمیت

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

awk '{bytes[$7] += $10}
     END {for (u in bytes) printf "%9.1f MB  %s\n", bytes[u]/1048576, u}' \
    /var/log/nginx/access.log | sort -rn | head -20

و همان کار به تفکیک مرورگر و ربات، که معمولاً غافلگیرکننده‌تر است:

awk '{b = $10; split($0, q, "\""); ua[q[6]] += b}
     END {for (u in ua) printf "%9.1f MB  %s\n", ua[u]/1048576, substr(u, 1, 55)}' \
    /var/log/nginx/access.log | sort -rn | head -15

حالا فهرست مقصرها، از پرمصرف به کم‌مصرف بر اساس چیزی که روی سایت‌های واقعی دیده می‌شود:

1. تصاویر بهینه‌نشده. بی‌رقیب اول است. عکس مستقیم دوربین یا موبایل ۳ تا ۵ مگابایت و ۴۰۰۰ پیکسل عرض دارد، در حالی که جای نمایشش ۸۰۰ پیکسل است؛ همان تصویر با تغییر اندازه به ۱۶۰۰ پیکسل و تبدیل به WebP حدود ۱۵۰ کیلوبایت می‌شود، یعنی بیش از ۹۵ درصد صرفه‌جویی. صفحه‌ای با ۱۵ تصویر خام یعنی ۴۵ مگابایت در هر بازدید و ۱.۳ ترابایت در ماه به‌ازای ۳۰ هزار بازدید — فقط برای عکس.
2. نبود کش مرورگر. بدون هدر Cache-Control، بازدیدکننده‌ی تکراری همه‌ی CSS و JS و فونت‌ها را دوباره می‌گیرد؛ روی سایتی که ۴۰ درصد کاربرانش برمی‌گردند، حدود یک‌سوم ترافیک شما دوباره‌کاری محض است.
3. نبود فشرده‌سازی. HTML و CSS و JS و JSON با gzip حدود ۷۰ تا ۸۵ درصد کوچک می‌شوند و با brotli کمی بیشتر: باندل ۳۰۰ کیلوبایتی جاوااسکریپت به ترتیب به ۸۵ و ۷۲ کیلوبایت می‌رسد.
4. ویدیو از روی سرور خودتان. ویدیوی ۱۰۸۰p با نرخ ۴.۵ مگابیت بر ثانیه، هر ساعت تماشا حدود ۲ گیگابایت خروجی است و ۵۰۰ بار تماشای کامل یعنی ۱ ترابایت. ویدیو تقریباً هیچ‌وقت نباید از origin سرو شود.
5. بکاپ کامل شبانه به بیرون. ۲۰ گیگابایت بکاپ کامل هر شب یعنی ۶۰۰ گیگابایت خروجی در ماه؛ همان داده با بکاپ افزایشی (borg یا restic) روزی ۳۰۰ تا ۸۰۰ مگابایت می‌شود، حدود یک‌سی‌ام. روشش در راهنمای بکاپ‌گیری در لینوکس آمده است.
6. ربات‌ها و اسکرپرها. خزنده‌های هوش مصنوعی و ابزارهای سئو ۲۰ تا ۴۰ درصد درخواست‌ها را می‌سازند و چون از کش استفاده نمی‌کنند و نسخه‌ی تمام‌اندازه‌ی تصاویر را می‌گیرند، سهمشان از بایت بیشتر از سهمشان از درخواست است.
7. سرور آلوده. صریح می‌گوییم: یک جهش ناگهانی چند برابری در ترافیک خروجی، تا خلاف آن ثابت نشود یعنی حادثه‌ی امنیتی. رایج‌ترین حالت‌ها ارسال هرزنامه، شرکت در حمله‌ی DDoS و میزبانی فایل غیرمجاز است. علامت مشخصه‌اش این است که خروجی چند برابر شده ولی تعداد بازدید صفحه ثابت مانده و اوجش ساعت سه بامداد است.

ss -tunp | awk 'NR>1 {print $6}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head   # پرتکرارترین مقصدها
postqueue -p | tail -1        # Postfix: تعداد ایمیل در صف
exim -bpc                     # Exim: همان عدد
sudo nethogs eth0             # کدام پروسه دارد می‌فرستد

اگر صف ایمیل هزاران پیام دارد یا پروسه‌ای ناشناس در nethogs بالای فهرست است، مسئله ترافیک نیست، نفوذ است. سرور را از شبکه جدا کنید و از چک‌لیست امنیت سرور لینوکس شروع کنید.

کم‌کردن ترافیک — کارهایی که واقعاً جواب می‌دهند

۱. فشرده‌سازی را روشن کنید

# /etc/nginx/conf.d/compression.conf
gzip              on;
gzip_comp_level   5;
gzip_min_length   1024;
gzip_vary         on;
gzip_proxied      any;
gzip_types        text/plain text/css text/xml application/json
                  application/javascript application/rss+xml image/svg+xml;

# ngx_brotli اگر ماژول نصب است
brotli            on;
brotli_comp_level 5;
brotli_types      text/plain text/css application/json
                  application/javascript image/svg+xml;

سطح فشرده‌سازی را روی ۵ بگذارید نه ۹؛ بالاتر از ۵ حجم چند درصد کم می‌شود ولی مصرف CPU چند برابر. و هرگز JPEG و PNG و MP4 را در gzip_types نگذارید — از قبل فشرده‌اند و gzip فقط CPU می‌سوزاند. بقیه‌ی پیکربندی پایه در راهنمای نصب Nginx آمده است.

۲. هدرهای کش را درست بگذارید

location ~* \.(css|js|woff2|png|jpe?g|webp|avif|svg|ico)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

location ~* \.html$ {
    add_header Cache-Control "public, max-age=0, must-revalidate";
}

کلمه‌ی immutable به مرورگر می‌گوید حتی درخواست تأییدیه هم نفرست، و فقط وقتی درست است که نام فایل‌های استاتیک نسخه‌دار باشد (مثل app.4f2a1c.css)؛ وگرنه کاربران تا یک سال نسخه‌ی قدیمی را می‌بینند. HTML هم هرگز نباید طولانی کش شود.

۳. تصاویر را به WebP یا AVIF ببرید

sudo apt install webp libavif-bin

cwebp -q 80 -resize 1600 0 photo.jpg -o photo.webp
avifenc --min 24 --max 32 photo.jpg photo.avif

# تبدیل دسته‌جمعی پوشه‌ی آپلودها
find /var/www/uploads -type f -name '*.jpg' \
     -exec sh -c 'cwebp -q 80 -resize 1600 0 "$1" -o "${1%.jpg}.webp"' _ {} \;

پارامتر -resize 1600 0 مهم‌تر از خود تبدیل فرمت است (صفر یعنی ارتفاع متناسب و خودکار): اول اندازه را درست کنید، بعد فرمت را. در وردپرس افزونه‌ها همین کار را خودکار می‌کنند — جزئیاتش در راهنمای افزایش سرعت وردپرس.

۴. یک CDN جلوی سایت بگذارید

مؤثرترین کار تک‌مرحله‌ای همین است: وقتی فایل‌های استاتیک از لبه سرو می‌شوند، ۶۰ تا ۹۰ درصد بایت‌ها اصلاً به سرور شما نمی‌رسند و در سهمیه شمرده نمی‌شوند. برای مخاطب ایرانی دو نکته را در نظر بگیرید: مسیر رفت‌وبرگشت ممکن است طولانی‌تر شود (بحثش در مقاله‌ی کاهش پینگ کاربران ایرانی)، و ترافیکی که از خارج به کاربر داخلی می‌رود بین‌الملل حساب می‌شود.

۵. جلوی خزنده‌های زیاده‌خواه را بگیرید

robots.txt فقط یک خواهش مؤدبانه است و ربات بدرفتار به آن اعتنا نمی‌کند؛ پس هم آن را بنویسید، هم یک محدودیت واقعی بگذارید:

# robots.txt
User-agent: GPTBot
Disallow: /

User-agent: SemrushBot
Disallow: /

User-agent: *
Disallow: /*?s=
Disallow: /wp-json/

# nginx.conf — محدودیتی که واقعاً اجرا می‌شود
map $http_user_agent $bad_bot {
    default                                              0;
    "~*(Bytespider|SemrushBot|AhrefsBot|MJ12bot|DotBot)"  1;
}

limit_req_zone $binary_remote_addr zone=crawl:10m rate=2r/s;

server {
    if ($bad_bot) { return 429; }

    location / {
        limit_req zone=crawl burst=20 nodelay;
    }
}

۶. کارهای سنگین را به ساعت خلوت ببرید

# سقف ۵ مگابایت بر ثانیه تا بکاپ شبانه سهم کاربران را نخورد
rsync -az --bwlimit=5000 --delete /var/www/ backup@storage:/srv/www/

# بکاپ افزایشی و فشرده
borg create --stats --compression zstd,10 \
     ssh://backup@storage/./repo::www-{now:%Y-%m-%d} /var/www

# /etc/systemd/system/backup.timer
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

حواستان به منطقه‌ی زمانی سرور باشد؛ ۳:۳۰ روی UTC می‌شود ۷ صبح تهران که دیگر خلوت نیست. با timedatectl set-timezone Asia/Tehran یکسانش کنید.

اقتصاد ترافیک: سهمیه‌ی ثابت یا پرداخت به‌اندازه‌ی مصرف؟

مسئله‌ی اصلی الگوی مصرف است، نه میانگین آن. فروشگاهی را در نظر بگیرید که ده ماه سال حدود ۹۰۰ گیگابایت مصرف می‌کند و در دو ماه کمپین به ۴.۵ ترابایت می‌رسد. با سهمیه‌ی ثابت دو انتخاب بد دارید: پلن ۱ ترابایتی بگیرید و در ماه کمپین — دقیقاً وقتی فروش دارید — یا قطع شوید یا جریمه بدهید؛ یا از اول پلن ۵ ترابایتی بخرید و ده ماه بابت ظرفیت بلااستفاده پول بدهید.

مدل ساعتی و مصرف‌محور برای همین شکل از مصرف ساخته شده: در ماه‌های عادی هزینه‌ی همان ۹۰۰ گیگابایت را می‌دهید و در ماه کمپین بدون تغییر پلن سرور بالا می‌ماند. منطق کامل قیمت‌گذاری‌اش در راهنمای سرور ابری ساعتی آمده است.

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

#!/bin/bash
# Alert while there is still room to react — not after the bill is issued.
LIMIT_GB=5000
TOKEN=... ; CHAT=...

used=$(vnstat --json m -i eth0 \
       | jq '.interfaces[0].traffic.month[-1] | (.rx + .tx) / 1000000000 | floor')
pct=$(( 100 * used / LIMIT_GB ))

if [ "$pct" -ge 80 ]; then
    curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
         -d chat_id="$CHAT" \
         -d text="traffic ${used}GB / ${LIMIT_GB}GB (${pct}%)"
fi

دوم، یک ترمز اضطراری. این دستور پورت را روی ۲۰ مگابیت می‌بندد؛ سایت کند می‌شود ولی بالا می‌ماند و کنتور دیوانه‌وار بالا نمی‌رود:

sudo tc qdisc add dev eth0 root tbf rate 20mbit burst 32kbit latency 400ms
sudo tc qdisc del dev eth0 root      # برداشتن محدودیت

سؤالات پرتکرار

پهنای باند نامحدود واقعاً وجود دارد؟

نه به معنای واقعی. پشت هر «نامحدود» یا سقف نانوشته‌ی fair usage است که بعد از آن سرعت پورت را پایین می‌آورند، یا پورتی است که از اول کند بسته شده. بپرسید بعد از چه حجمی و به چه سرعتی محدود می‌شوید؛ اگر جواب روشنی ندادند، پلنی با سهمیه‌ی مشخص بگیرید.

ترافیک ورودی هم از سهمیه‌ی من کم می‌شود؟

بستگی به سرویس‌دهنده دارد؛ بسیاری فقط خروجی را می‌شمارند. ساده‌ترین راه تشخیص این است که عدد پنل را با خروجی vnstat -d مقایسه کنید و ببینید به tx نزدیک‌تر است یا به rx + tx.

عدد vnstat با پنل هاست فرق دارد، یعنی سرویس‌دهنده اشتباه می‌کند؟

لزوماً نه. اختلاف ۲ تا ۵ درصد طبیعی است و از تفاوت نقطه‌ی اندازه‌گیری، سربار لایه‌ی پیوند، فاصله‌ی نمونه‌برداری و تفاوت GiB با GB می‌آید؛ ضمناً پکت‌هایی که فایروال شما دور می‌ریزد در پورت شمرده شده‌اند ولی در vnstat نمی‌آیند. اختلاف پایدار بالای ۱۵ درصد ارزش تیکت‌زدن دارد.

ترافیک داخلی و بین‌الملل چه فرقی دارند؟

ترافیک داخلی یعنی داده‌ای که مقصد یا مبدأش داخل شبکه‌ی کشور است؛ چون از لینک‌های بین‌المللی رد نمی‌شود ارزان‌تر تمام می‌شود و با نرخ پایین‌تری حساب می‌شود. اگر مخاطب اصلی سایتتان داخل ایران است، نسبت این دو کنتور می‌تواند صورت‌حسابتان را چند برابر تغییر دهد.

حمله‌ی DDoS از سهمیه‌ی من کم می‌شود؟

ترافیک ورودی حمله در پورت شمرده می‌شود حتی اگر فایروال شما همه‌اش را دور بیندازد، چون بایت‌ها پیش از رسیدن به فایروال از پورت رد شده‌اند؛ پس اگر سرویس‌دهنده ورودی را حساب نکند عملاً بی‌ضرر است. بخش خطرناک‌تر پاسخ‌های خود سرور است که قطعاً شمرده می‌شود.

اگر سهمیه‌ام وسط ماه تمام شود چه می‌شود؟

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

قدم بعدی

ترتیب کار روشن است. همین امروز vnstat را روی همه‌ی سرورهایتان نصب کنید تا ماه آینده داده‌ی مستقل داشته باشید. بعد با آن دو دستور awk ببینید بایت‌هایتان دقیقاً کجا خرج می‌شوند و از پرمصرف‌ترین قلم — که تقریباً همیشه تصاویر است — شروع کنید. بعد فشرده‌سازی و هدرهای کش را روشن کنید و در آخر یک هشدار ۸۰ درصد بگذارید تا هیچ صورت‌حسابی غافلگیرتان نکند.

و اگر دارید بین پلن‌ها انتخاب می‌کنید، به‌جای حدس‌زدن یک ماه اندازه بگیرید: یک سرور ابری ساعتی بسازید، سایت را رویش بیاورید، vnstat -m را نگاه کنید و با عدد واقعی تصمیم بگیرید — هزینه‌اش فقط همان ساعت‌هایی است که روشن بوده.