نخستین انتخاب فنی که هنگام خرید پروکسی با آن روبهرو میشوید معمولاً پروتکل است: HTTP(S) یا SOCKS5؟ هر دو ترافیک شما را از IP دیگری عبور میدهند، اما این کار را در لایههای متفاوت و با تواناییهای متفاوت انجام میدهند. پروکسی HTTP درخواستهای وب را میشناسد و با آنها کار میکند. پروکسی SOCKS اما بیآنکه به این کار داشته باشد که کدام برنامه چه میفرستد، بایتها را از یک سر به سر دیگر میرساند.
در این نوشته شیوه کار دو پروتکل را گامبهگام، تفاوتهای عملیشان، جزئیات DNS و رمزگذاری، پشتیبانی نرمافزارها و اینکه برای هر کار کدام را باید انتخاب کرد شرح میدهیم. اگر میخواهید عمیقتر به جزئیات فنی SOCKS5 نگاه کنید، نوشته پروکسی SOCKS5 چیست؟ مکمل خوبی است. برای منطق کلی کار پروکسی نوشته سرور پروکسی چیست و چگونه کار میکند؟ را ببینید.
پروکسی HTTP چگونه کار میکند؟
پروکسی HTTP همانطور که از نامش پیداست به زبان پروتکل HTTP سخن میگوید. در دو وضعیت متفاوت دو رفتار متفاوت دارد:
- در درخواستهای HTTP بدون رمزگذاری کلاینت کل درخواست را به پروکسی میفرستد. پروکسی درخواست را میخواند، به مقصد میرساند و پاسخ را بازمیگرداند. در این میان میتواند سرآیندها را ببیند، در حافظه نهان نگه دارد یا تغییر دهد.
- در درخواستهای HTTPS کلاینت نخست درخواست
CONNECT target.com:443را به پروکسی میفرستد. پروکسی با مقصد یک اتصال TCP باز میکند و از آن پس فقط بایتهای رمزگذاریشده را جابهجا میکند. محتوا را نمیبیند. این روش در استاندارد RFC 9110 تعریف شده است.
یعنی در وب امروز که بیشتر بر پایه HTTPS است، پروکسی HTTP نه به محتوای سایت، بلکه فقط به نام دامنه و درگاهی که به آن وصل میشوید دسترسی دارد.
مسیری که یک درخواست HTTPS از طریق پروکسی طی میکند چنین است:
- کلاینت با TCP به پروکسی وصل میشود و
CONNECT target.com:443 HTTP/1.1را میفرستد؛ در صورت نیاز با سرآیندProxy-Authorizationهویت خود را تأیید میکند. - پروکسی به مقصد وصل میشود و به کلاینت پاسخ
200 Connection Establishedمیدهد. - کلاینت درون همین اتصال با مقصد دستدهی TLS انجام میدهد. تأیید گواهی میان کلاینت و مقصد است.
- ترافیک رمزگذاریشده HTTP از تونل جریان مییابد؛ پروکسی فقط بایت جابهجا میکند.
عبارت «پروکسی HTTPS» اغلب همین توانایی تونلسازی را توصیف میکند؛ اتصالی که با خود پروکسی برقرار میشود معمولاً HTTP بدون رمزگذاری است. به همین دلیل نشانی پروکسی برای سایتهای HTTPS هم با http:// شروع میشود.
پروکسی SOCKS چگونه کار میکند؟
SOCKS مستقل از پروتکل برنامه کار میکند. کلاینت به پروکسی میگوید «به این نشانی و این درگاه وصل شو»؛ سرور SOCKS اتصال را برقرار میکند و ترافیک میان دو طرف را همانطور که هست جابهجا میکند. اینکه ترافیک طرف مقابل وب، بازی، ایمیل یا پایگاه داده باشد برایش اهمیتی ندارد.
SOCKS5 که نسخه کنونی است، با استاندارد RFC 1928 تعریف میشود و نسبت به SOCKS4 قدیمی سه ویژگی مهم میافزاید:
- احراز هویت (نام کاربری و رمز عبور، استاندارد RFC 1929)،
- پشتیبانی از UDP (برای ترافیک مبتنی بر UDP مانند بازیها، تماس صوتی و DNS)،
- اتصال با نام دامنه، یعنی امکان انجام تفکیک DNS در سمت پروکسی؛ و همچنین پشتیبانی از نشانی IPv6.
اتصال SOCKS5 هم در چند گام برقرار میشود: کلاینت روشهای احراز هویتی را که پشتیبانی میکند اعلام میکند، سرور یکی را برمیگزیند، هویت تأیید میشود و سپس کلاینت نشانی و درگاه مقصد را میفرستد. پس از آنکه سرور اتصال را برقرار کرد، داده خام در دو جهت جریان مییابد. این دستدهی تنها چند بایت است؛ از سرآیندهای HTTP کوچکتر است.
تفاوتهای اصلی
| معیار | پروکسی HTTP(S) | پروکسی SOCKS5 |
|---|---|---|
| لایه کار | لایه برنامه (HTTP) | لایه نشست، مستقل از پروتکل |
| ترافیکی که جابهجا میکند | درخواستهای وب | هر نوع ترافیک TCP و UDP |
| پشتیبانی از UDP | ندارد | دارد |
| دسترسی به سرآیندهای درخواست | در HTTP بدون رمزگذاری دارد | ندارد |
| حافظه نهان و پالایش محتوا | در HTTP بدون رمزگذاری ممکن است | ممکن نیست |
| احراز هویت | دارد (Proxy-Authorization) | دارد (نام کاربری و رمز عبور) |
| تفکیک DNS | در HTTPS نام دامنه مقصد به پروکسی فرستاده میشود | در کلاینت یا در پروکسی ممکن است |
| سربار دستدهی | سرآیندهای HTTP | چند بایت |
| پشتیبانی نرمافزار | مرورگرها، کتابخانههای HTTP، تقریباً همه ابزارها | مرورگرها، cURL، برنامههای رومیزی، کلاینتهای بازی؛ در برخی کتابخانهها بسته اضافه لازم است |
| کاربرد معمول | اسکرپینگ وب، سئو، پایش قیمت | بازیها، برنامههای رومیزی، پروتکلهای غیروب |
چرا تفکیک DNS مهم است؟
یکی از کمشناختهترین و در عین حال مهمترین تفاوتهای دو پروتکل این است که نام دامنه کجا به IP تبدیل میشود.
- در پروکسی HTTP، درخواست
CONNECT target.com:443نام دامنه را به پروکسی میفرستد؛ تفکیک را پروکسی انجام میدهد. هیچ پرسوجویی به سرور DNS خود کلاینت نمیرود. - در SOCKS5 دو گزینه وجود دارد. کلاینت میتواند خودش نام دامنه را تفکیک کند و IP بفرستد (در cURL با
socks5://) یا نام دامنه را به پروکسی بسپارد (در cURL باsocks5h://). در گزینه نخست پرسوجوی DNS از شبکه شما خارج میشود؛ یعنی شبکه محلی میتواند ببیند به چه سایتهایی وصل میشوید و سایت مقصد ممکن است بهجای سروری نزدیک به پروکسی، سروری دور از آن را به شما بدهد.
قاعده عملی: هنگام استفاده از SOCKS5 تفکیک از راه دور را ترجیح دهید. در کتابخانهها این معمولاً با طرح socks5h یا گزینه «DNS از راه دور» تنظیم میشود؛ برخی ابزارها بهطور پیشفرض تفکیک محلی انجام میدهند و این تفاوت از چشم میافتد.
از نظر سرعت کدام جلوتر است؟
بهطور کلی SOCKS5 چون کار کمتری انجام میدهد سربار کمتری دارد: درخواستها را تفسیر نمیکند و فقط جابهجا میکند. اما در ترافیک HTTPS، پروکسی HTTP هم پس از تونل CONNECT فقط بایت جابهجا میکند و تفاوت تا حد زیادی از میان میرود.
در عمل سرعت را بیش از پروتکل، مکان سرور پروکسی، نوع IP و کیفیت خط تعیین میکند. انتخاب نقطه خروجی نزدیک به سرور مقصد تفاوتی بسیار بیشتر از تغییر پروتکل ایجاد میکند. چگونگی سنجش این تفاوت در بازیها را در نوشته رفع پینگ بالا و از دست رفتن بسته در بازیها و اثر نوع IP بر سرعت را در نوشته تفاوت پروکسی مسکونی و دیتاسنتر توضیح دادهایم.
از نظر امنیت و حریم تفاوتی هست؟
هیچکدام از دو پروتکل ترافیک را رمزگذاری نمیکنند. رمزگذاری از پروتکلی میآید که سرویس مقصد به کار میبرد: در وب HTTPS، در پوسته از راه دور SSH و در ایمیل TLS. از این دید، گفتن اینکه «SOCKS5 امنتر است» یا «پروکسی HTTP امنتر است» نادرست است؛ هر دو به یک اندازه فقط حاملاند.
دو نقطه تفاوت وجود دارد:
- دیده شدن در HTTP بدون رمزگذاری. اگر با پروکسی HTTP به یک سایت HTTP بدون رمزگذاری وصل شوید، پروکسی میتواند کل درخواست را بخواند؛ SOCKS5 هم همان بایتها را جابهجا میکند و فقط تفسیرشان نمیکند. یعنی از نظر حریم تفاوتی نیست و در هر دو حالت ترافیک بدون رمزگذاری است.
- نشت DNS. همانطور که در بالا گفته شد، اگر در SOCKS5 تفکیک محلی انجام دهید، اینکه به چه سایتهایی میروید از شبکه محلی دیده میشود. در پروکسی HTTP این خطر وجود ندارد، چون نام دامنه همیشه به پروکسی فرستاده میشود. برای نشت IP از راه WebRTC در مرورگر و آزمون آن نوشته نشت WebRTC و DNS را ببینید.
اگر تفاوت رمزگذاری میان پروکسی و VPN برایتان پرسش است، نوشته تفاوت پروکسی و VPN را ببینید.
کی باید پروکسی HTTP را انتخاب کرد؟
- اسکرپینگ وب و خودکارسازی. کتابخانههایی مانند Requests، HTTPX و AIOHTTP در Python بدون بسته اضافه از پروکسی HTTP پشتیبانی میکنند. تفاوت این کتابخانهها را در مقایسه HTTPX، Requests و AIOHTTP و سمت Node.js را در نوشته معادل cURL در JavaScript بررسی کردهایم.
- اگر فقط ترافیک وب را مسیردهی میکنید. در مرورگر، ابزارهای سئو یا نرمافزارهای پایش قیمت، پروکسی HTTP گستردهترین سازگاری را دارد.
- ابزارهای خط فرمان. برای آزمون سریع با cURL و wget، پروکسی HTTP مستقیم کار میکند. یادآوری کنیم که wget پشتیبانی درونساخت از SOCKS ندارد؛ جزئیات در نوشته استفاده از پروکسی در wget آمده است.
- خودکارسازی مرورگر. Puppeteer، Playwright و Selenium از احراز هویت با نام کاربری و رمز عبور در پروکسی HTTP پشتیبانی میکنند؛ Chrome این احراز هویت را در SOCKS5 پشتیبانی نمیکند.
- شبکه سازمانی و حافظه نهان. نگهداری ترافیک HTTP بدون رمزگذاری در حافظه نهان یا پالایش آن فقط با پروکسی HTTP ممکن است.
گزینه مناسب برای ترافیک وب، بستههای پروکسی HTTPS است.
کی باید پروکسی SOCKS5 را انتخاب کرد؟
- بازیها و برنامههای رومیزی. کلاینتهای بازی مرورگر وب نیستند؛ با پروتکلهای خودشان و اغلب با UDP ارتباط برقرار میکنند. این ترافیک را فقط SOCKS5 میتواند جابهجا کند. پیکربندیهای سمت بازی را در راهنماهای Knight Online و Silkroad Online شرح دادهایم.
- پروتکلهای غیروب. SSH، FTP، ایمیل یا سرویسهای ویژه TCP.
- وادار کردن برنامه به استفاده از پروکسی. برنامههایی که تنظیم پروکسی ندارند را میتوان با ابزارهایی مانند Proxifier از طریق SOCKS5 مسیردهی کرد. پیکربندی آن را در راهنمای Proxifier مییابید.
- جلوگیری از نشت DNS. وقتی میخواهید تفکیک نام دامنه در سمت پروکسی انجام شود (مانند طرح
socks5h://در cURL). - سربار کم. در برنامههایی که اتصالهای کوتاه زیادی باز میکنند، دستدهی کوچک SOCKS5 میتواند تفاوتی قابل اندازهگیری ایجاد کند.
برای این سناریوها بستههای پروکسی SOCKS5 را ببینید.
پشتیبانی نرمافزارها: کدام ابزار از چه پشتیبانی میکند؟
| ابزار | پروکسی HTTP(S) | پروکسی SOCKS5 |
|---|---|---|
| Chrome، Firefox، Edge | دارد | دارد (در Chrome احراز هویت با رمز عبور ندارد) |
| cURL | دارد | دارد (socks5://، socks5h://) |
| wget | دارد | ندارد |
| Python Requests | درونساخت | با requests[socks] |
| Python HTTPX | درونساخت | با httpx[socks] |
| Node.js undici و fetch | ProxyAgent | با بسته اضافهای مانند socks-proxy-agent |
| Puppeteer و Playwright | دارد | دارد (احراز هویت با رمز عبور محدود) |
| Proxifier | دارد | دارد |
| کلاینتهای SSH | با ProxyCommand | با ProxyCommand، پشتیبانی طبیعی |
| کلاینتهای بازی | معمولاً ندارد | با ابزار مسیردهی |
همانطور که جدول نشان میدهد، پشتیبانی از پروکسی HTTP رایجتر است؛ SOCKS5 اما هر جا پشتیبانی شود، طیف گستردهتری از ترافیک را جابهجا میکند.
آیا یک پروکسی میتواند از هر دو پروتکل پشتیبانی کند؟
بله. بسیاری از ارائهدهندگان یک IP را هم از درگاه HTTP و هم از درگاه SOCKS5 ارائه میدهند؛ پروتکل را طرحی که در نشانی اتصال آمده تعیین میکند. آزمودن یک پروکسی به دو شکل با cURL سریعترین راه دیدن تفاوت است:
# Through the HTTP proxy
curl -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip
# Through SOCKS5, DNS resolved on the proxy side
curl -x "socks5h://user:pass@pr.proxynet.io:1080" https://httpbin.org/ipهر دو دستور باید IP خروجی یکسانی برگردانند. نشانی و درگاه بسته به بسته شما تغییر میکند؛ مقدارهای درست را در پنل مشتری خود مییابید. برای گزینههای دیگر پروکسی در cURL نوشته استفاده از پروکسی با cURL را ببینید.
اگر میخواهید همین دو آزمایش را در Python با Requests انجام دهید:
import requests
HTTP_PROXY = "http://user:pass@pr.proxynet.io:8000"
SOCKS_PROXY = "socks5h://user:pass@pr.proxynet.io:1080" # pip install "requests[socks]"
for proxy in (HTTP_PROXY, SOCKS_PROXY):
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(proxy.split("://")[0], r.json()["origin"])راهنمای تصمیم
| نیاز شما | پیشنهاد |
|---|---|
| اسکرپینگ وب با Python یا Node.js | HTTP(S) |
| خودکارسازی مرورگر، پروکسی با احراز هویت رمز عبور | HTTP(S) |
| ابزارهای سئو، پایش قیمت، تأیید تبلیغات | HTTP(S) |
| کلاینت بازی، ترافیک UDP | SOCKS5 |
| SSH، FTP، ایمیل، سرویس ویژه TCP | SOCKS5 |
| برنامه رومیزی بدون تنظیم پروکسی | SOCKS5 همراه Proxifier |
| ماندن پرسوجوهای DNS در سمت پروکسی | SOCKS5 (تفکیک از راه دور) یا HTTP(S) |
| دانلود با wget | HTTP(S) |
پرسشهای متداول
SOCKS5 ترافیک را رمزگذاری میکند؟
نه. SOCKS5 ترافیک را همانطور که هست جابهجا میکند. حریم اتصال را رمزگذاریای تأمین میکند که سرویس مقصد به کار میبرد (مثلاً HTTPS یا SSH). همین موضوع درباره پروکسی HTTP هم صدق میکند.
در مرورگر کدام را به کار ببرم؟
اگر فقط به وبسایتها دسترسی دارید، هر دو کار میکنند. پروکسی HTTP پشتیبانی رایجتری دارد و همه مرورگرها از احراز هویت با رمز عبور آن پشتیبانی میکنند؛ SOCKS5 اما وقتی میخواهید تفکیک DNS را به پروکسی بسپارید مزیت دارد. برای مدیریت مبتنی بر نمایه در سطح مرورگر راهنماهای SwitchyOmega و تنظیمات پروکسی Firefox را ببینید.
در Python میتوانم از SOCKS5 استفاده کنم؟
میتوانید، اما بسته به کتابخانه بسته اضافه لازم است. برای Requests بسته requests[socks] و برای HTTPX بسته httpx[socks] نصب میشود؛ سپس در نشانی پروکسی از طرح socks5:// یا socks5h:// استفاده میشود.
SOCKS4 هنوز به کار میرود؟
برخی ابزارهای قدیمی پشتیبانی میکنند، اما چون احراز هویت، UDP و پشتیبانی از نام دامنه ندارد، در پیکربندیهای تازه ترجیح داده نمیشود. اگر ارائهدهندهای «SOCKS» میگوید، امروزه منظورش SOCKS5 است.
پروکسی HTTP و پروکسی HTTPS یکی هستند؟
در کاربرد روزمره بله: «پروکسی HTTPS» یعنی پروکسی HTTP که با تونل CONNECT به سایتهای HTTPS دسترسی دارد. از نظر فنی شکلی هم وجود دارد که با خود پروکسی از طریق TLS گفتوگو میشود، اما رایج نیست و بیشتر کلاینتها از آن پشتیبانی نمیکنند.
چگونه بفهمم پروکسی از کدام پروتکل پشتیبانی میکند؟
در پنل ارائهدهنده، اطلاعات درگاه معمولاً بر پایه پروتکل داده میشود؛ برای HTTP و SOCKS5 درگاههای متفاوتی هست. اگر مطمئن نیستید، دو دستور cURL بالا را آزمایش کنید: تلاش برای اتصال با پروتکل نادرست خطای اتصال یا پاسخ بیمعنا میدهد و پروتکل درست IP را برمیگرداند.
جمعبندی
اگر ترافیک وب را مسیردهی میکنید، پروکسی HTTP(S) گستردهترین سازگاری را دارد و در بیشتر ابزارهای اسکرپینگ بیدردسر کار میکند. اگر پای بازیها، برنامههای رومیزی، ترافیک UDP یا پروتکلهای غیروب در میان است، SOCKS5 تنها انتخاب درست است؛ در این حالت فراموش نکنید تفکیک DNS را در سمت پروکسی بگذارید. تفاوت سرعت را بیش از پروتکل، مکان و نوع IP پروکسی تعیین میکند. برای بستههایی که از هر دو پروتکل پشتیبانی میکنند راهکارهای پروکسی ما را ببینید.




