يؤدي HTTP proxy و SOCKS5 المهمة نفسها — استبدال عنوانك أمام الخادم — لكنهما يفعلان ذلك على مستويين مختلفين من حزمة الشبكة، ومن هنا ينبع كل شيء آخر: أي نوع من البيانات يمرّران، وما يمكنهما رؤيته وتعديله، وكيف يتعاملان مع DNS و UDP، ومع أي البرامج يتوافقان أصلًا. أما السرعة، خلافًا للاعتقاد الشائع، فلا علاقة لها تقريبًا بهذا الأمر. فيما يلي تحليل للبروتوكولين، وجدول بالفروقات، وقاعدة اختيار تحسم تسع حالات من عشر.
باختصار
- HTTP proxy يفهم HTTP. يقرأ الطلب، ويعرف إلى أين تتجه، ويمكنه إضافة ترويسات أو تخزين الرد مؤقتًا أو حجب عنوان. أما HTTPS فيمرّره بشكل أعمى عبر أمر
CONNECT. أما البيانات غير المتعلقة بـ HTTP فليست من شأنه. - SOCKS5 لا يفهم شيئًا ولا يريد أن يفهم. بعد مصافحة قصيرة يكتفي بتمرير البايتات في الاتجاهين: TCP لأي بروتوكول، وعند الحاجة UDP. ويمكن أن يكون داخل ذلك أي شيء — موقع أو بريد أو Telegram أو لعبة أو تورنت.
- لا هذا ولا ذاك يشفّر البيانات بحد ذاته. حماية البيانات مسؤولية البروتوكول الداخلي (HTTPS، TLS) وليست مسؤولية الـ proxy.
على أي مستوى يعمل كل منهما
يعمل HTTP proxy على مستوى التطبيق. يرسل إليه العميل طلب HTTP عاديًا، لكن مع العنوان الكامل في السطر الأول (GET http://example.com/page HTTP/1.1)، فيفتح الـ proxy بنفسه اتصالًا مع الخادم، ويستقبل الرد ويمرّره إلى العميل. ويمرّ كل المحتوى عبره كنص مكشوف، ومن حقه تعديله.
أما مع HTTPS فالآلية مختلفة: يطلب العميل من الـ proxy إنشاء نفق عبر أمر CONNECT example.com:443، فيصل الـ proxy بين مقبسين (sockets) ثم يكتفي بعد ذلك بنقل البايتات المشفّرة. يرى اسم المضيف والمنفذ، لكنه لا يرى المسار ولا الترويسات ولا جسم الطلب.
يقع SOCKS5 (وفق RFC 1928) في مستوى أدنى — بين طبقة النقل والتطبيق. يتفق العميل مع الـ proxy على طريقة المصادقة، ويحدد عنوان الوجهة (IPv4 أو IPv6 أو اسم نطاق) والمنفذ، فيفتح الـ proxy الاتصال ويصبح من تلك اللحظة أنبوبًا شفافًا. لا يعرف ما البروتوكول بالداخل، ولذلك يعمل مع أي بروتوكول. وإذا أردت تحديث الأساسيات نفسها، فابدأ بمقال ما هو خادم الـ proxy.
كيف يعمل HTTP proxy
ما يستطيعه لأنه يفهم البروتوكول
- التخزين المؤقت. قد لا تصل الطلبات المتكررة إلى المورد نفسه إلى الخادم — وهكذا تعمل proxies الشركات ومزودي الخدمة.
- الفلترة حسب URL. يرى الـ proxy العنوان ويمكنه حجبه أو إزالة أدوات التتبع أو إعادة التوجيه.
- تعديل الترويسات. يمكنه إضافة
ViaأوX-Forwarded-ForأوForwarded(RFC 7239) — وبذلك يكشف عنوانك الحقيقي. ويمكنه أيضًا إزالة ما هو زائد. - المصادقة. يُمرَّر اسم المستخدم وكلمة المرور في ترويسة
Proxy-Authorization، وفي الغالب بمخطط Basic — أي بترميز Base64، دون تشفير. وعلى قناة غير محمية يمكن رؤيتهما.
ما لا يستطيعه
كل ما ليس HTTP. بروتوكولات البريد و SSH وخوادم الألعاب وعملاء التورنت و VoIP إما لا تعمل عبر HTTP proxy إطلاقًا، أو تتطلب أن يعرف البرنامج كيف يلفّ الاتصال داخل CONNECT، وأن يسمح الـ proxy بمثل هذه الأنفاق إلى منافذ عشوائية. وكثير من الـ proxies لا تسمح بـ CONNECT إلا إلى المنفذ 443.
ثلاث درجات لإخفاء الهوية
بسبب الترويسات، يُقسَّم HTTP proxy تقليديًا إلى ثلاث فئات. الشفاف يمرّر عنوان IP الحقيقي في X-Forwarded-For ويعلن عن نفسه بصدق في Via. والمجهول يخفي العنوان لكنه يترك ترويسات الـ proxy — فيفهم الخادم أن أمامه وسيطًا. والنخبوي لا يضيف شيئًا ويبدو كعميل عادي. أما SOCKS5 فلا يوجد فيه هذا التصنيف: فهو لا يصل إلى الترويسات ولا يضيف شيئًا بحكم طبيعته.
كيف يعمل SOCKS5
المصافحة
يبدأ الاتصال بأن يعدّد العميل طرق المصادقة التي يدعمها، فيختار الخادم واحدة: بلا مصادقة، أو باسم المستخدم وكلمة المرور (RFC 1929)، أو GSS-API. ثم يرسل العميل طلبًا يتضمن الأمر ونوع العنوان والمنفذ. والأوامر ثلاثة: CONNECT — اتصال TCP صادر عادي، وBIND — استقبال اتصال وارد (يلزم مثلًا لـ FTP النشط)، وUDP ASSOCIATE — فتح إعادة إرسال لحزم UDP.
DNS عن بُعد
الفرق الجوهري عن SOCKS4: يمكن تمرير عنوان الوجهة كاسم نطاق، وعندها يحلّ الـ proxy الاسم بدلًا من جهازك. وفي curl و Python يظهر هذا الفرق في مخطط URL: socks5:// يحلّ الاسم محليًا، وsocks5h:// يحلّه على جانب الـ proxy. الخيار الأول يترك استعلامات DNS لدى مزود الخدمة، والثاني ينقلها مع البيانات. وفي المهام التي يهم فيها عدم كشف العنوان، تحتاج تحديدًا إلى socks5h.
UDP
عبر UDP ASSOCIATE يمرّ ما لا يناسبه TCP: الصوت والفيديو في تطبيقات المراسلة، و DNS، وبعض بروتوكولات الألعاب، و QUIC. وعمليًا لا تدعم كل الخوادم وكل العملاء UDP عبر SOCKS5، لذا يجب التحقق من ذلك بشكل منفصل قبل شراء proxy لهذه المهمة.
كلمة مرور بلا تشفير
يُمرَّر اسم المستخدم وكلمة المرور في SOCKS5 (طريقة RFC 1929) كنص مكشوف، تمامًا كما في HTTP Basic. والقناة إلى الـ proxy غير محمية في الحالتين؛ ولا يجعل البيانات محمية إلا TLS داخل الاتصال. وإذا كان المزود يقدم المصادقة عبر IP، فهي لا تقل أمانًا ولا تترك كلمة المرور في سجلات البرامج.
أهم الفروقات في جدول واحد
| المعيار | HTTP proxy | SOCKS5 |
|---|---|---|
| المستوى | التطبيقي (يفهم HTTP) | الجلسي (يمرّر البايتات) |
| البيانات | HTTP، و HTTPS عبر CONNECT | أي TCP، و UDP اختياريًا |
| يرى المحتوى | نعم في HTTP، والمضيف فقط في HTTPS | عنوان الوجهة فقط |
| يمكنه تعديل الطلب | نعم (ترويسات، ذاكرة مؤقتة، فلاتر) | لا |
| حلّ DNS | على الـ proxy | على الـ proxy (socks5h) أو محليًا (socks5) |
| التشفير | لا (إلا داخل HTTPS) | لا (إلا داخل البروتوكول نفسه) |
| المصادقة | Proxy-Authorization، Basic | اسم المستخدم وكلمة المرور (RFC 1929)، GSS-API، بلا مصادقة |
| الدعم في البرامج | في كل مكان تقريبًا | واسع، لكنه ليس شاملًا |
| العبء الإضافي | تحليل الترويسات | ضئيل جدًا |
السرعة: لماذا لا يوجد الفرق حيث يبحثون عنه
لا يحلّل SOCKS5 الترويسات ولا يخزّن الردود مؤقتًا، لذا يوفّر نظريًا أجزاء من الميكروثانية في كل طلب. وبالمقارنة مع زمن الشبكة إلى الـ proxy ومنه إلى الخادم، فإن ذلك غير ملحوظ. أما السرعة الفعلية فتحددها أربعة أمور: المسافة إلى خادم الـ proxy ومنه إلى الهدف، ونوع عنوان IP (القنوات المحمولة والسكنية أبطأ من قنوات مراكز البيانات — ولمزيد من التفصيل راجع مقال أنواع الـ proxy)، ومدى انشغال الخادم المعني، وعدد الاتصالات التي تفتحها بالتوازي. ولا وجود للبروتوكول في هذه القائمة.
الحالة الوحيدة التي يكون فيها HTTP proxy أسرع بشكل ملحوظ هي proxy يخزّن المحتوى مؤقتًا عند تكرار المحتوى نفسه. والحالة الوحيدة التي يكون فيها SOCKS5 أسرع بشكل ملحوظ هي البيانات التي ما كانت لتمرّ أصلًا عبر HTTP proxy.
إخفاء الهوية والتسريبات
لا يحدث تسريب العنوان عبر الـ proxy «بسبب البروتوكول»، بل بسبب آليات محددة، ولكل منها سببه.
- الترويسات. يمرّر HTTP proxy الشفاف عنوان IP الخاص بك في
X-Forwarded-For. ويُعالَج ذلك باختيار proxy نخبوي. أما SOCKS5 فلا توجد فيه هذه القناة للتسريب. - DNS. إذا حُلّ الاسم محليًا، يرى مزود الخدمة إلى أين تتجه. أما HTTP proxy و
socks5hفيحلّان الاسم من جهتهما؛ وsocks5لا يفعل ذلك. - WebRTC. قد يكشف المتصفح العنوان المحلي والخارجي عبر STUN متجاوزًا أي proxy. وهذه خاصية في المتصفح لا في الـ proxy؛ وتُغلق عبر الإعدادات أو إضافة.
- بيانات تمرّ خارج الـ proxy. يُضبط الـ proxy على تطبيق معيّن. وكل ما لم تضبطه — تحديثات النظام، متصفح آخر، تطبيق مراسلة — يمرّ مباشرة. وإذا أردت تغطية الجهاز بالكامل، فهذه مهمة VPN، راجع proxy مقابل VPN و Tor.
التوافق مع البرامج
- المتصفحات. يأخذ Chrome و Edge الـ proxy من إعدادات النظام ويفهمان النوعين؛ أما Firefox فله إعداداته الخاصة ويستطيع «تمرير DNS عبر SOCKS5» بخيار منفصل.
- curl. الأمر
curl -x http://user:pass@host:portلـ HTTP، وcurl -x socks5h://user:pass@host:portلـ SOCKS5 مع DNS عن بُعد. - Python. في
requestsوhttpxيعمل HTTP proxy مباشرة، أما SOCKS5 فيحتاج تثبيت حزمة إضافية؛ ويحوّل المخططsocks5h://أيضًا عملية الحلّ إلى الـ proxy. - Telegram و Discord وعملاء التورنت والألعاب. في الغالب SOCKS5 فقط: فبياناتها ليست HTTP.
- متصفحات anti-detect وأدوات الـ scraping. تدعم النوعين؛ وكثيرًا ما يقدّم مزودو proxies المحمولة والسكنية المنفذ نفسه في البروتوكولين.
- SSH. الأمر
ssh -D 1080 user@serverيرفع proxy محليًا من نوع SOCKS5 عبر أي خادم لديك صلاحية الوصول إليه — وهي طريقة مريحة لاختبار سلوك البرنامج مع SOCKS5.
متى تختار أيًّا منهما
| المهمة | الاختيار | السبب |
|---|---|---|
| المتصفح والعمل على المواقع | أي منهما؛ و HTTP أكثر شيوعًا | كل البيانات HTTP(S)، والدعم متاح في كل مكان |
| الـ scraping عبر مكتبة HTTP | HTTP أو socks5h | الأهم هو حلّ DNS على الـ proxy وعدم إرسال ترويسات زائدة |
| تطبيقات المراسلة والألعاب والتورنت والبريد | SOCKS5 | بيانات غير HTTP، وأحيانًا UDP |
| حسابات كثيرة في متصفح anti-detect | أي منهما؛ انظر إلى IP لا إلى البروتوكول | نظام مكافحة الاحتيال يقيّم العنوان والبصمة، لا طريقة الاتصال |
| شبكة الشركة والتحكم والتخزين المؤقت | HTTP | الحاجة إلى الفلترة والتسجيل حسب URL |
| خصوصية الجهاز الكاملة | لا هذا ولا ذاك | هذه مهمة VPN أو Tor |
القاعدة: إذا كان في البرنامج حقل «HTTP proxy» وكان يتصل عبر HTTP(S) فقط — فاختر HTTP. وإذا كان البرنامج لا علاقة له بالويب أو كان فيه «SOCKS5» فقط — فاختر SOCKS5 مع DNS عن بُعد. ولا معنى للجدال حول السرعة.
أخطاء شائعة
- توقّع التشفير من الـ proxy. لا HTTP ولا SOCKS5 يحمي البيانات حتى الـ proxy؛ ولا يحميها إلا TLS بالداخل.
- استخدام
socks5://بدلًا منsocks5h://ثم البحث عن مصدر «تسريب» DNS. - ضبط HTTP proxy في برنامج لا يتصل عبر HTTP، ثم إلقاء اللوم على «proxy سيئ» بسبب صمته.
- اختيار البروتوكول حسب السرعة. فالسرعة يحددها العنوان والمسار، ويمكن فحصهما في دقيقة — راجع كيف تفحص الـ proxy من حيث إخفاء الهوية والتسريبات والسرعة.
- اعتبار HTTP proxy النخبوي «أكثر إخفاءً للهوية» من SOCKS5. فكلاهما لا يكشف العنوان؛ والفرق فقط أن SOCKS5 لا يملك أصلًا القدرة التقنية على إضافته.
أسئلة وأجوبة
أيهما أسرع — SOCKS5 أم HTTP proxy؟
على الخادم نفسه يكون الفرق غير قابل للقياس مقارنة بزمن الشبكة. فالسرعة تحددها نوعية IP والمسافة والحمل على الخادم، لا البروتوكول.
هل يشفّر SOCKS5 البيانات؟
لا. يمرّر SOCKS5 البايتات كما هي؛ واسم المستخدم وكلمة المرور يمرّان أيضًا كنص مكشوف. وما يجعل البيانات محمية هو TLS داخل الاتصال، مثل HTTPS.
هل يمكن استخدام HTTP proxy مع Telegram أو التورنت؟
في الغالب لا: فبياناتها ليست HTTP، ومعظم HTTP proxies تمنع النفق عبر CONNECT إلى منافذ عشوائية. وتحتاج هذه البرامج إلى SOCKS5.
ما الفرق بين socks5h و socks5؟
حرف h يعني أن خادم الـ proxy هو من يحلّ اسم النطاق. وبدونه يخرج استعلام DNS من جهازك عبر مزود الخدمة، فيرى عنوان الوجهة.
أي البروتوكولين أكثر إخفاءً للهوية؟
HTTP proxy النخبوي و SOCKS5 لا يكشفان عنوانك بالقدر نفسه. أما HTTP proxy الشفاف فيكشفه عبر الترويسات؛ و SOCKS5 لا يملك هذه الآلية. وبقية التسريبات — DNS و WebRTC والبيانات الخارجة عن الـ proxy — لا تعتمد على البروتوكول.