اگر شما پروکسی HTTP را متصل کرده‌اید و بازی سرور را پیدا نمی‌کند، تماس Discord متصل نمی‌شود و YouTube و سایت‌های HTTP/3 به سختی بارگذاری می‌شوند — مشکل از پروکسی «کیفیت پایین» نیست. مشکل از پروتکل است. پروکسی HTTP به طور فیزیکی نمی‌تواند با ترافیک UDP کار کند و به همین دلیل بازی‌ها، تماس‌های VoIP و QUIC مدرن (HTTP/3) بر اساس UDP ساخته شده‌اند. در این مقاله بررسی می‌کنیم که چرا اینگونه است و چگونه پروکسی را انتخاب کنیم که واقعاً تمام ترافیک را عبور دهد — نه فقط درخواست‌های مرورگر.
TCP در مقابل UDP: تفاوت اصلی چیست
تمام انتقال داده‌های شبکه بر اساس دو پروتکل حمل و نقل پایه — TCP و UDP ساخته شده است. TCP یک اتصال برقرار می‌کند، تحویل بسته‌ها را در ترتیب صحیح تضمین می‌کند، بسته‌های گمشده را دوباره ارسال می‌کند و دریافت هر بخش را تأیید می‌کند. این قابل اعتماد است، اما کند است: قبل از اینکه داده‌ها ارسال شوند، باید «دست دادن» (handshake) انجام شود و هر بار که یک بسته گم می‌شود، ارسال مجدد و تأخیر ایجاد می‌شود.
UDP به گونه‌ای دیگر عمل می‌کند: بسته‌ها بدون برقراری اتصال، بدون تأیید و بدون تضمین تحویل ارسال می‌شوند. اگر یک بسته گم شود — هیچ‌کس آن را دوباره ارسال نخواهد کرد، برنامه خود تصمیم می‌گیرد که با گم شدن چه کند. این به نظر یک نقص می‌آید، اما برای وظایف زمان واقعی این یک مزیت بزرگ است: بهتر است یک فریم ویدیو یا یک تیک بازی را گم کنید تا اینکه منتظر ارسال مجدد بمانید و یک تأخیر نیم ثانیه‌ای دریافت کنید.
به همین دلیل است که بر اساس UDP ساخته شده‌اند:
- بازی‌های آنلاین (Counter-Strike, Dota 2, Fortnite, تیراندازهای موبایل) — تأخیر حداقل (ping) مهم است، نه 100% تحویل هر بسته؛
- VoIP و تماس‌های ویدیویی — Discord، Zoom، Google Meet، تماس‌های WhatsApp از UDP برای صدا و ویدیو استفاده می‌کنند؛
- استریمینگ در زمان واقعی — WebRTC، پخش از طریق OBS با تأخیر کم؛
- درخواست‌های DNS — بیشتر DNS-Resolverها بر روی UDP کار می‌کنند؛
- QUIC / HTTP/3 — پروتکل حمل و نقل جدیدی که Google و Cloudflare به عنوان جایگزینی برای TCP+TLS برای ترافیک وب ترویج می‌کنند.
HTTP و HTTPS به صورت کلاسیک (HTTP/1.1، HTTP/2) بر روی TCP کار می‌کنند. بنابراین مرور وب معمولی از طریق پروکسی HTTP بدون مشکل کار می‌کند — اما همه موارد ذکر شده در بالا شروع به خراب شدن می‌کنند.
چرا پروکسی HTTP فقط با TCP کار می‌کند
پروکسی HTTP به طور اولیه برای یک وظیفه طراحی شده است — ارسال درخواست‌های HTTP. وقتی شما یک سایت HTTPS را از طریق پروکسی HTTP باز می‌کنید، مرورگر به سرور پروکسی دستور CONNECT host:port را ارسال می‌کند، پروکسی یک تونل TCP به سرور هدف ایجاد می‌کند و سپس تمام ترافیک رمزگذاری شده از طریق این تونل می‌رود. این فقط به این دلیل کار می‌کند که هم مشتری، هم پروکسی و هم سرور در تمام مراحل از TCP استفاده می‌کنند.
پروتکل HTTP CONNECT به سادگی مکانیزمی برای عبور از دیتاگرام‌های UDP ندارد. مشخصات پروکسی ایجاد «تونل بدون اتصال» را پیش‌بینی نمی‌کند — و UDP به طور خاص انتقال بدون اتصال است. بنابراین وقتی بازی یا Discord سعی می‌کنند یک بسته UDP را از طریق پروکسی HTTP تنظیم شده در سیستم ارسال کنند، سیستم‌عامل یا تنظیمات پروکسی را برای این ترافیک نادیده می‌گیرد (و بسته به طور مستقیم، دور از پروکسی می‌رود)، یا اتصال به سادگی برقرار نمی‌شود.
در عمل اینگونه بروز می‌کند: برنامه نشان می‌دهد «هیچ اتصالی به سرور وجود ندارد»، صدا در تماس هر چند ثانیه قطع می‌شود، ping در بازی به بیش از 300-500 میلی‌ثانیه می‌رسد یا سیستم جستجوی مسابقه اصلاً سرور را پیدا نمی‌کند. مشکل نه در سرعت پروکسی و نه در ارائه‌دهنده است — پروتکل HTTP-proxy به طور معماری نمی‌تواند با UDP کار کند.
QUIC و HTTP/3: دردسر جدید برای پروکسی
QUIC یک پروتکل حمل و نقل است که توسط Google توسعه یافته و در اساس HTTP/3 قرار دارد. این پروتکل بر روی UDP کار می‌کند، اما در عین حال مکانیزم خود را برای اطمینان، رمزگذاری (TLS 1.3 داخلی) و چندپخشی جریان‌ها پیاده‌سازی می‌کند — به این معنی که بهترین‌های TCP را می‌گیرد، اما بدون تأخیر در برقراری اتصال. سایت‌های Cloudflare، Google، YouTube و بسیاری از CDNها به طور پیش‌فرض از QUIC به طور گسترده استفاده می‌کنند.
مشکل این است که مرورگر به طور پیش‌فرض سعی می‌کند به سایت از طریق QUIC (پورت 443/UDP) متصل شود و اگر پروکسی HTTP از عبور UDP پشتیبانی نکند، یکی از دو اتفاق می‌افتد:
- مرورگر به HTTP/2 از طریق TCP بازمی‌گردد — ترافیک همچنان از طریق پروکسی می‌رود، اما زمان اضافی برای توافق مجدد پروتکل صرف می‌شود، به همین دلیل صفحات به وضوح دیرتر بارگذاری می‌شوند؛
- یا بسته‌های UDP QUIC به طور مستقیم با IP واقعی دور از پروکسی می‌روند — این برای وظایفی که در آن‌ها ناشناسی مهم است بحرانی است: چندحسابی، مرورگرهای ضد شناسایی، تست جغرافیایی تبلیغات. سایت بخشی از ترافیک را با IP پروکسی می‌بیند و بخشی را با IP واقعی کاربر؛
سناریوی دوم به ویژه برای افرادی که در زمینه‌های تبلیغاتی و SMM کار می‌کنند خطرناک است، که از مرورگرهای ضد شناسایی (Dolphin Anty، AdsPower، Multilogin، GoLogin) استفاده می‌کنند. اگر مرورگر در QUIC به طور مستقیم از پروکسی «فرار کند»، پلتفرمی مانند Facebook یا Google Ads می‌تواند چند حساب را با IP واقعی مرتبط کند، حتی اگر در تنظیمات پروکسی همه چیز به درستی تنظیم شده باشد. به همین دلیل بیشتر مرورگرهای ضد شناسایی مدرن QUIC را به طور اجباری غیرفعال می‌کنند یا UDP را برای پروکسی HTTP مسدود می‌کنند — اما اگر شما پروکسی را به صورت دستی در Chrome معمولی تنظیم می‌کنید، باید به این موضوع به طور مستقل توجه کنید.
SOCKS5 و UDP ASSOCIATE: چگونه کار می‌کند
SOCKS5 یک پروتکل پروکسی در سطح پایین‌تر از HTTP است. این پروتکل به یک پروتکل کاربردی خاص (HTTP، FTP و غیره) وابسته نیست و در سطح سوکت‌ها کار می‌کند، به این معنی که می‌تواند هم ترافیک TCP و هم UDP را عبور دهد. در مشخصات SOCKS5 (RFC 1928) یک دستور UDP ASSOCIATE وجود دارد که به طور خاص برای عبور از دیتاگرام‌های UDP از طریق سرور پروکسی طراحی شده است.
اینگونه کار می‌کند: مشتری ابتدا یک اتصال TCP معمولی با سرور SOCKS5 برقرار می‌کند و دستور UDP ASSOCIATE را ارسال می‌کند. سرور در پاسخ یک پورت UDP اختصاص می‌دهد که از طریق آن تبادل دیتاگرام‌ها انجام خواهد شد. سپس مشتری هر بسته UDP را در یک هدر خاص SOCKS5 قرار می‌دهد و آن را به این پورت ارسال می‌کند، و سرور محتویات را به مقصد ارسال می‌کند و هدر را حذف می‌کند. ترافیک برگشتی نیز به همین شیوه انجام می‌شود.
نکته مهم: هر پروکسی SOCKS5 در بازار واقعاً از UDP ASSOCIATE پشتیبانی نمی‌کند. بسیاری از ارائه‌دهندگان «SOCKS5» را فقط به عنوان یک روش جایگزین برای احراز هویت برای ترافیک TCP می‌فروشند و اصلاً عبور UDP را پیاده‌سازی نمی‌کنند. بنابراین اگر به پشتیبانی UDP برای بازی‌ها، تماس‌ها یا QUIC نیاز دارید — از ارائه‌دهنده به طور خاص در مورد وجود UDP ASSOCIATE سؤال کنید، نه فقط پروتکل SOCKS5 در لیست.
برای وظایفی که هم ثبات و هم IP واقعی کاربر نهایی مهم است — به عنوان مثال، تست تبلیغات در TikTok Ads یا Facebook Ads از یک منطقه خاص با در نظر گرفتن ترافیک موبایل — پروکسی‌های موبایل بهتر هستند: شبکه اپراتور و چرخش IP خطر مسدود شدن را در جلسات طولانی، از جمله در تماس‌های صوتی و استریمینگ کاهش می‌دهد.
HTTP در مقابل SOCKS5: جدول مقایسه
برای اینکه در انتخاب نوع پروکسی برای وظیفه خاصی سردرگم نشوید، پروتکل‌ها را بر اساس پارامترهای کلیدی مقایسه می‌کنیم.
| پارامتر | پروکسی HTTP/HTTPS | SOCKS5 با UDP ASSOCIATE |
|---|---|---|
| پشتیبانی از TCP | بله | بله |
| پشتیبانی از UDP | خیر | بله (با پیاده‌سازی UDP ASSOCIATE) |
| کار با QUIC/HTTP3 | بازگشت به HTTP/2 یا نشت ترافیک | عبور کامل ترافیک |
| بازی‌ها (CS، Dota، Fortnite) | کار نمی‌کند | کار می‌کند |
| VoIP/تماس‌های ویدیویی (Discord، Zoom) | قطعی‌ها و تأخیرها | اتصال پایدار |
| مرور وب معمولی | کار می‌کند | کار می‌کند |
| تنظیم در مرورگرهای ضد شناسایی | ساده | ساده، توسط همه مرورگرهای اصلی پشتیبانی می‌شود |
عملی: بازی‌ها، تماس‌ها، استریمینگ از طریق SOCKS5
سناریوهای خاصی را بررسی می‌کنیم که در آن‌ها تفاوت پروکسی HTTP و SOCKS5 در عمل نمایان می‌شود.
بازی‌های آنلاین. اگر نیاز به تغییر منطقه مسابقه یا دور زدن محدودیت جغرافیایی در بازی دارید، پروکسی HTTP به سادگی مناسب نیست — کلاینت بازی از پروتکل UDP خاص خود برای ارتباط با سرورهای بازی استفاده می‌کند و ترافیک دور از پروکسی خواهد رفت. به یک پروکسی SOCKS5 با پشتیبانی تأیید شده از UDP ASSOCIATE نیاز دارید که یا در تنظیمات خود بازی (اگر چنین گزینه‌ای وجود داشته باشد) یا از طریق سطح سیستم با استفاده از ابزارهای تونل‌زنی شخص ثالث تنظیم شود.
تماس‌های Discord و Zoom. کانال‌های متنی Discord از طریق HTTPS (TCP) کار می‌کنند و به راحتی از طریق پروکسی HTTP عبور می‌کنند. اما تماس‌های صوتی و ویدیویی از یک کانال UDP جداگانه استفاده می‌کنند — به همین دلیل است که اغلب می‌توانید در چت بنویسید، اما تماس متصل نمی‌شود یا صدا «قطع می‌شود». راه‌حل — SOCKS5 با UDP که در سطح برنامه Discord (در تنظیمات بخشی برای پروکسی وجود دارد که می‌توانید نوع SOCKS5 را مشخص کنید) یا در سطح کل سیستم از طریق کلاینت پروکسی تنظیم شده است.
استریمینگ و WebRTC. سرویس‌هایی مانند OBS با خروجی WebRTC داخلی و همچنین تماس‌های ویدیویی مرورگری (Google Meet، WhatsApp Web) از UDP برای حداقل کردن تأخیر استفاده می‌کنند. برای چنین وظایفی، پروکسی‌های مسکونی با پشتیبانی از SOCKS5 بهینه هستند — آن‌ها IP واقعی ارائه‌دهنده خانگی را ارائه می‌دهند، که احتمال مسدود شدن در دامنه‌های «مشکوک» دیتاسنتر را کاهش می‌دهد و همزمان ترافیک UDP را بدون از دست دادن عبور می‌دهند.
پارسی و اتوماسیون با WebSocket/QUIC-اندپوینت‌ها. اگر شما داده‌ها را از سایت‌هایی که به طور پیش‌فرض از HTTP/3 استفاده می‌کنند (بسیاری از سایت‌ها بر روی Cloudflare) پارس می‌کنید و پاسخ‌های ناپایداری یا مسدودیت از طریق پروکسی HTTP دریافت می‌کنید، SOCKS5 را امتحان کنید — این کار بازگشت اضافی پروتکل را حذف می‌کند و رفتار پارسر را به رفتار یک مرورگر واقعی نزدیک‌تر می‌کند.
چگونه SOCKS5 را در برنامه‌ها و مرورگرها تنظیم کنیم
تنظیم SOCKS5 بسته به برنامه متفاوت است. گزینه‌های اصلی را بررسی می‌کنیم که با آن‌ها آربیتراژکنندگان، متخصصان SMM و کاربران عادی مواجه می‌شوند.
مرورگرهای ضد شناسایی (Dolphin Anty، AdsPower، GoLogin، Multilogin، Octo Browser). در تنظیمات پروفایل باید نوع پروکسی «SOCKS5» را به جای «HTTP» انتخاب کنید، آدرس، پورت، نام کاربری و رمز عبور را مشخص کنید. تمام مرورگرهای ذکر شده به طور پیش‌فرض از SOCKS5 پشتیبانی می‌کنند — تفاوت با HTTP در رابط کاربری حداقل است، اما از نظر پشتیبانی پروتکل‌ها در موتور مرورگر اصولی است.
Discord. تنظیمات → صدا و ویدیو → پروکسی. نوع SOCKS5 را انتخاب کنید، آدرس و پورت سرور را وارد کنید. اگر ارائه‌دهنده نیاز به احراز هویت با نام کاربری و رمز عبور دارد، آن‌ها را در فیلدهای مربوطه وارد کنید.
کلاینت‌های بازی و سطح سیستم. بیشتر بازی‌ها تنظیمات داخلی پروکسی ندارند، بنابراین از انتقال ترافیک سیستم از طریق کلاینت پروکسی (به عنوان مثال، Proxifier یا ابزارهای مشابه) استفاده می‌شود که می‌تواند با SOCKS5 کار کند و بسته‌های TCP و UDP یک فرآیند بازی خاص را در سیستم عبور دهد.
مرورگر Chrome/Firefox به صورت دستی. در Chrome پشتیبانی بومی از SOCKS5 در تنظیمات وجود ندارد — باید یا مرورگر را با پرچم --proxy-server="socks5://host:port" راه‌اندازی کنید، یا از یک افزونه استفاده کنید. در Firefox پشتیبانی داخلی وجود دارد: تنظیمات → شبکه → تنظیمات اتصال → تنظیمات دستی پروکسی → SOCKS Host، نسخه SOCKS v5، و حتماً گزینه «استفاده از SOCKS v5 برای حل DNS از طریق پروکسی» را علامت‌گذاری کنید — این مهم است تا درخواست‌های DNS نیز از طریق تونل عبور کنند، نه به طور مستقیم.
نمونه‌های کد: بررسی UDP از طریق SOCKS5
برای توسعه‌دهندگانی که می‌خواهند بررسی کنند که آیا پروکسی واقعاً UDP را عبور می‌دهد، چند مثال عملی ارائه می‌دهیم.
بررسی اتصال TCP از طریق SOCKS5 با استفاده از curl:
curl -x socks5h://user:pass@proxy_host:1080 https://ifconfig.meبررسی با Python از طریق کتابخانه PySocks، که اجازه می‌دهد سوکت را در تونل SOCKS5 قرار دهید، از جمله حالت UDP:
import socks
import socket
s = socks.socksocket(socket.AF_INET, socket.SOCK_DGRAM)
s.set_proxy(socks.SOCKS5, "proxy_host", 1080, username="user", password="pass")
s.sendto(b"ping", ("8.8.8.8", 53))
data, addr = s.recvfrom(1024)
print(data)
اگر سرور از UDP ASSOCIATE پشتیبانی کند، شما پاسخ دریافت خواهید کرد. اگر کتابخانه خطای اتصال یا زمان‌تمامی را پرتاب کند — به این معنی است که پروکسی خاص فقط بخش TCP SOCKS5 را پیاده‌سازی کرده است و برای بازی‌ها یا تماس‌ها مناسب نخواهد بود. برای تست خودکار QUIC-اندپوینت‌ها می‌توانید از curl --http3 در ترکیب با تونل SOCKS5 استفاده کنید، به شرطی که نسخه curl با پشتیبانی از HTTP/3 نصب شده باشد.
چک‌لیست انتخاب پروکسی برای ترافیک UDP
- از ارائه‌دهنده سؤال کنید که آیا فقط «SOCKS5» وجود دارد یا به طور خاص پشتیبانی از دستور UDP ASSOCIATE؛
- برای بازی‌ها و تماس‌های VoIP، اتصال را از قبل آزمایش کنید — ping واقعی و ثبات مهم‌تر از سرعت اعلام شده است؛
- برای وظایف چندحسابی در مرورگرهای ضد شناسایی، بررسی کنید که آیا QUIC غیرفعال است یا به طور کامل از طریق پروکسی عبور می‌کند — در غیر این صورت ممکن است نشت IP واقعی وجود داشته باشد؛
- برای استریمینگ و تماس‌های ویدیویی، پروکسی‌هایی با ping پایین به منطقه مورد نظر را ترجیح دهید — برای چنین سناریوهایی، پروکسی‌های مسکونی به خوبی کار می‌کنند، زیرا از IPهای واقعی ارائه‌دهندگان ارتباطی استفاده می‌کنند؛
- اگر وظیفه — پارس سریع بدون نیاز به UDP (درخواست‌های HTTP/HTTPS معمولی) است، می‌توانید از پروکسی‌های دیتاسنتر ارزان‌تر و سریع‌تر استفاده کنید — در این مورد نیازی به پرداخت اضافی برای پشتیبانی UDP نیست؛
- همیشه پروکسی را در برنامه خاصی قبل از استفاده گسترده آزمایش کنید — پروکسی «همیشه کار می‌کند» جهانی وجود ندارد، رفتار به پیاده‌سازی در سمت ارائه‌دهنده بستگی دارد.
نتیجه‌گیری
پروکسی HTTP به خوبی با ترافیک وب معمولی کار می‌کند، اما به طور معماری نمی‌تواند UDP را عبور دهد — به این معنی که برای بازی‌ها، تماس‌های VoIP، استریمینگ و QUIC/HTTP3 مدرن مناسب نیست. اگر با قطع تماس‌ها، تأخیر در بازی‌ها یا رفتار عجیب سایت‌ها بر روی Cloudflare از طریق پروکسی مواجه شده‌اید — مشکل از کیفیت اتصال نیست، بلکه از خود پروتکل پروکسی است. راه‌حل — SOCKS5 با پشتیبانی تأیید شده از UDP ASSOCIATE که باید از قبل سؤال شود، نه اینکه به طور تصادفی حدس زده شود.
اگر وظیفه شما مربوط به تماس‌های ویدیویی، استریمینگ یا کار با مرورگرهای ضد شناسایی است که در آن جلوگیری از نشت ترافیک دور از پروکسی مهم است، به پروکسی‌های موبایل توجه کنید — آدرس‌های IP اپراتوری اعتماد بالایی به پلتفرم‌ها و پشتیبانی پایدار از پروتکل‌های مدرن، از جمله SOCKS5 با UDP را فراهم می‌کنند.