HTTP CONNECT: كيف يتعامل وكيل HTTP مع HTTPS

تعني «200 Connection Established» أن الوكيل يقبل إنشاء نفق. لم يُرجع الموقع صفحة بعد. تلي ذلك جلسة TLS مع الوجهة، ثم طلب HTTPS نفسه.

من الاتصال بالوكيل إلى استجابة الموقع

1. يتصل العميل بنقطة نهاية الوكيل.
2. يطلب من الوكيل الاتصال بمضيف الوجهة ومنفذها.
3. يقبل الوكيل هذا الطلب أو يرفضه.
4. بعد القبول، يتفاوض العميل على TLS مع الوجهة عبر النفق.
5. يرسل العميل طلب HTTPS ويتلقى استجابة الموقع داخل TLS.

رفض الاتصال بالوكيل ورفض النفق وخطأ الشهادة تقع في نقاط مختلفة من هذا التسلسل. حدد آخر خطوة اكتملت قبل تغيير الإعدادات.

تبادل CONNECT

في HTTP/1.1، يبدو التبادل المبسط كما يلي:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

HTTP/1.1 200 Connection Established

هدف الطلب هو مضيف ومنفذ، دون مسار الموقع أو معاملات الاستعلام. بعد نجاح استجابة CONNECT، ينقل الاتصال بايتات النفق. ولوجهة HTTPS، يكون التبادل التالي للعميل هو مصافحة TLS.

اقرأ رمز الحالة الرقمي بدلًا من مطابقة العبارة التفسيرية الإنجليزية. قد تستخدم الوكلاء نصوصًا مختلفة للحالة نفسها.

راقب العملية باستخدام curl

لوكيل HTTP على المنفذ المحلي 8080:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

استبدل عنوان الاستماع بنقطة نهايتك؛ وإن احتجت إلى مرشحين، فتصفح قائمة وكلاء HTTP واختبر السجل الذي تختاره. تضمن قائمة التجاوز الفارغة أن يستخدم هذا الاستدعاء الوكيل. ابحث زمنيًا عن الاتصال بالوكيل، واستجابة CONNECT، والتحقق من شهادة الوجهة، واستجابة الموقع. تعتمد الصياغة الدقيقة للسجل على بنية curl.

قد تُرجع الوجهة 404 أو 429 أو 500 بعد أن يقبل الوكيل النفق. وقد تفشل أيضًا أثناء TLS قبل إرجاع أي استجابة HTTP.

أين توقفت العملية؟

للمقارنة، أبقِ أحد الطرفين ثابتًا: جرّب وجهة أخرى عبر الوكيل نفسه، أو قارن الوجهة نفسها عبر مسار مباشر مسموح به.

لا يزال للنفق مشغّل

يعرف الوكيل وجهة CONNECT ويتعامل مع توقيت حركة البيانات وحجمها. يحمي TLS المعتاد من طرف إلى طرف محتوى تطبيق الموقع من وكيل لا ينهي جلسة TLS تلك. أما وكيل الاعتراض المُدار الذي يثق به العميل فله ترتيب ثقة مختلف.