روش صحیح تست سرعت و کیفیت VPN

چرا یک Speedtest کافی نیست؟

نتیجه یک تست کوتاه می‌تواند تحت تأثیر انتخاب خودکار سرور نزدیک، cache، ازدحام لحظه‌ای، Wi‑Fi و حتی روش چنداتصالی ابزار باشد. ممکن است دانلود ۲۰۰ مگابیت باشد اما تماس تصویری به‌دلیل جیتر و افت بسته قطع شود؛ یا سرور تست نزدیک VPN باشد ولی مقصد کاری شما مسیر ضعیفی داشته باشد. بنابراین هدف، ساختن یک آزمایش کنترل‌شده است، نه شکار بهترین عدد.

پیش از تست محیط را ثابت کنید

1. در صورت امکان از کابل شبکه استفاده کنید؛ روی موبایل در یک نقطه ثابت و با سیگنال مناسب بمانید.
2. دانلود، همگام‌سازی ابری، آپدیت و استریم سایر دستگاه‌ها را متوقف کنید.
3. حالت Battery Saver و Data Saver را موقتاً خاموش کنید.
4. نام شبکه، ساعت، دستگاه، نسخه برنامه و سرور VPN را یادداشت کنید.
5. برای مقایسه دو سرور، همه متغیرها جز سرور را ثابت نگه دارید.

مرحله اول: Baseline بدون VPN

قبل از اتصال، سه بار با فاصله کوتاه تست بگیرید. دانلود، آپلود، idle latency، loaded latency، jitter و loss را ثبت کنید. میانه سه نتیجه از یک عدد تصادفی قابل‌اعتمادتر است. سپس IP عمومی، IPv4/IPv6 و DNS را یادداشت کنید. این baseline سقف عملی شبکه شما در همان زمان است.

مرحله دوم: دانلود و آپلود

به VPN وصل شوید و ابتدا همان سرور Speedtest را دستی انتخاب کنید. سه بار آزمایش بگیرید و میانه را محاسبه کنید. سپس یک مقصد دورتر یا نزدیک به سرویس واقعی خود را هم امتحان کنید. برای دانلود واقعی می‌توانید یک فایل نسبتاً بزرگ از منبع معتبر بگیرید؛ سرعت پایدار در ۳۰ تا ۶۰ ثانیه مهم‌تر از جهش اولیه است.

نسبت سرعت VPN به baseline تصویر بهتری می‌دهد. مثلاً اگر خط بدون VPN برابر ۱۰۰ و با VPN برابر ۸۰ مگابیت باشد، بازده تقریبی ۸۰ درصد است. انتظار ۱۰۰ درصد همیشه واقع‌بینانه نیست، چون کپسوله‌سازی، رمزنگاری و مسیر اضافه سربار دارند.

مرحله سوم: پینگ، جیتر و افت بسته

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

مرحله چهارم: تست زیر بار و Bufferbloat

درحالی‌که دانلود یا آپلود شبکه را پر کرده است، latency را اندازه بگیرید. اگر پینگ از مثلاً ۳۰ به ۵۰۰ میلی‌ثانیه برسد، صف‌های طولانی یا Bufferbloat محتمل است. این مشکل ممکن است در روتر خانه یا شبکه اپراتور باشد، نه خود VPN. نتیجه را با تست زیر بار بدون VPN مقایسه کنید.

مرحله پنجم: مسیر و مقصد واقعی

برای کاربری خود سناریو بسازید: تماس ۱۵ دقیقه‌ای، ویدئوی باکیفیت، انتقال فایل، بازی یا دسترسی Remote Desktop. یک سرور ممکن است در Speedtest عالی باشد اما به سرویس مقصد peering ضعیفی داشته باشد. traceroute می‌تواند محل تقریبی افزایش تأخیر را نشان دهد، ولی بعضی hopها به ICMP پاسخ نمی‌دهند و ستاره الزاماً به معنای خرابی نیست.

مرحله ششم: DNS، IPv4 و IPv6

پس از اتصال IP خروجی IPv4 و IPv6 را جداگانه بررسی کنید. سپس resolver DNS را کنترل کنید. اگر انتظار دارید همه ترافیک تونل شود ولی یکی از خانواده‌های IP یا DNS مستقیم است، تنظیمات نیاز به بررسی دارد. در Split Tunneling ممکن است مسیر مستقیم عمدی باشد؛ نتیجه باید با سیاست مورد انتظار مقایسه شود، نه یک قانون کلی.

مرحله هفتم: پایداری طولانی و تغییر شبکه

تونل را حداقل ۳۰ تا ۶۰ دقیقه زیر استفاده واقعی نگه دارید و رشد RX/TX را دنبال کنید. گوشی را یک بار از Wi‑Fi به دیتای موبایل و برعکس منتقل کنید، صفحه را خاموش و دوباره روشن کنید و بررسی کنید آیا اینترنت واقعاً عبور می‌کند. نمایش «متصل» بدون تبادل داده نشانه تونل سالم نیست. بازیابی خودکار باید محدود، کنترل‌شده و بدون حلقه قطع‌و‌وصل باشد.

چگونه نتیجه نهایی بدهیم؟

به‌جای یک رتبه کلی، برای هر کاربرد امتیاز جدا بسازید:

• وب و دانلود: throughput پایدار، زمان DNS و loaded latency.
• تماس و بازی: median latency، jitter، loss و جهش‌های حداکثری.
• کار طولانی: uptime، تغییر شبکه، reconnect و ثبات IP.
• حریم مسیر: هماهنگی IPv4، IPv6 و DNS با سیاست تونل.

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

برگه پیشنهادی ثبت تست

تحریریه فنی WithUs Connect · روش آزمایش بر پایه مقایسه کنترل‌شده و چندنمونه‌ای