عند إعداد بروكسي في الشبكة أو أدوات التطوير، تظهر أحياناً رسالتان متكررتان تسببان ارتباكاً كبيراً: خطأ HTTP 407 وأخطاء المهلة. كثير من المستخدمين يخلطون بينهما فيبدأون بتعديل إعدادات لا علاقة لها بالمشكلة، فتضيع ساعات بلا نتيجة. الحقيقة أن 407 إشارة صلاحيات واضحة، بينما المهلة إشارة اتصال وأداء. هذه المقالة موجّهة لمن يضبط بروكسي على جهاز عمل أو خادم أو أداة سطر أوامر، وتقدّم مسار تشخيص منطقياً يبدأ من قراءة الرسالة نفسها، ثم فحص بيانات الاعتماد وصيغة الترويسة ونظام المصادقة، ثم تفكيك مراحل الاتصال لمعرفة أين تتوقف المهلة بالضبط. الهدف ليس زيادة المهلة أو تكرار المحاولات عشوائياً، بل الوصول إلى السبب الجذري بخطوات قابلة للتكرار والتوثيق.
الفرق الجوهري بين خطأ 407 وأخطاء المهلة
خطأ HTTP 407 هو استجابة يرجعها البروكسي عندما يطلب من العميل أن يثبت هويته قبل تمرير الطلب، وترافقه عادةً ترويسة Proxy-Authenticate التي تحدّد نظام المصادقة المطلوب. أما أخطاء المهلة فتعني أن الاتصال لم يكتمل خلال المدة المحددة، وقد تحدث قبل الوصول إلى البروكسي أثناء الانتظار، أو بعده داخل النفق، أو أثناء انتظار رد الموقع الأصلي. التمييز بين الحالتين أساسي لأن الأول يخصّ الصلاحيات والثاني يخصّ الاتصال والأداء وطبيعة الشبكة.
عملياً، حين تظهر لك 407 فالمشكلة غالباً في بيانات الاعتماد أو صيغة الترويسة أو نظام المصادقة المطلوب، ولا فائدة تُذكر من زيادة المهلة. وحين تظهر أخطاء المهلة فقد تكون بيانات الاعتماد صحيحة تماماً لكن الشبكة بطيئة أو المنفذ محجوب أو البروكسي مزدحم ولا يستجيب. لذلك ابدأ بتحديد نوع الخطأ من الرسالة نفسها قبل تغيير أي إعداد، لأن الخلط بين الحالتين يدفع إلى تعديلات عشوائية تطيل زمن الحل وتشتّت التشخيص بدل أن تقرّبه.
الأسباب الشائعة لخطأ 407 عند ضبط البروكسي
أكثر سبب لخطأ 407 هو غياب ترويسة Proxy-Authorization أو وجودها بصيغة خاطئة، مثل نسيان كلمة Basic أو عدم ترميز اسم المستخدم وكلمة المرور بشكل صحيح. وقد يحدث أيضاً عند تغيير كلمة المرور دون تحديث إعدادات النظام أو مدير الحزم أو أدوات الطرفية التي تحتفظ بنسخة قديمة. بعض البروكسيات تفرّق بين مصادقة النطاق المحلي ومصادقة الحساب السحابي، فينجح تسجيل الدخول إلى الجهاز ويفشل البروكسي لأنه يتطلب صيغة أو نطاقاً مختلفاً.
سبب آخر شائع هو الاعتماد على مصدر إعدادات مختلف عن الذي تظنه فعّالاً: متغيرات البيئة في الطرفية تتقدم أحياناً على إعدادات النظام، وبعض التطبيقات تتجاهل متغيرات النظام وتقرأ ملف إعداد خاصاً بها. كذلك قد يحجب جدار الحماية أو برنامج الحماية ترويسة المصادقة أو يعيد كتابتها أثناء المرور. تحقق من المصدر الفعلي للإعداد قبل تعديل كلمة المرور، لأن تكرار المحاولات الفاشلة قد يؤدي إلى قفل الحساب مؤقتاً ويزيد تعقيد التشخيص.
أنظمة المصادقة: Basic و Digest و NTLM و Kerberos
تحدّد ترويسة Proxy-Authenticate في استجابة 407 النظام الذي يطلبه البروكسي. في نظام Basic تُرسل بيانات الاعتماد مرمّزة بنظام Base64 دون تشفير حقيقي، لذا يجب أن يكون الاتصال إلى البروكسي محمياً ب ـ TLS وإلا تعرّضت البيانات للاعتراض على الشبكة. وفي نظام Digest يُستخدم تحدٍّ وعنصر nonce لتجنّب إرسال كلمة المرور مباشرةً، ما يجعله أكثر أماناً لكنه يتطلب مزامنة صحيحة للوقت والخوارزمية لكل من العميل والبروكسي.
أما NTLM و Kerberos فشائعان في بيئات الشركات المرتبطة ب ـ Active Directory، وغالباً لا يعملان مع عميل لا يدعم تفاوض المصادقة أو لا ينتمي إلى النطاق. عند مشاهدة أخطاء متكررة رغم صحة كلمة المرور، تحقق من نوع النظام المطلوب ومن دعم العميل له، لأن إرسال بيانات Basic إلى بروكسي يتوقع Negotiate ينتج 407 متكرراً حتى مع بيانات صحيحة تماماً. هنا يكون الحل في مطابقة نوع المصادقة لا في تغيير كلمة المرور.
تشخيص 407 عملياً عبر curl وأدوات الفحص
أداة curl طريقة سريعة لعزل المشكلة، إذ يمكنك توجيه طلب إلى مورد معروف مع تحديد البروكسي صراحةً، ثم قراءة الترويسات المطبوعة لمعرفة نوع المصادقة المطلوبة. مرّر بيانات الاعتماد عبر المفتاح المخصص مع فصل الحقلين بنقطتين، واستخدم المفتاح الذي يجبر curl على إظهار الترويسات قبل تتبع التحويلات. إن نجح الطلب مع تجاهل التحقق من الشهادة وتعطيل البروكسي، فالمشكلة في إعداد البروكسي لا في الموقع الهدف.
قارن بين تشغيل الأمر داخل الطرفية وخارجها، وبين حساب مستخدم وآخر، لتحديد إن كان الخطأ في متغيرات البيئة أو في سياسة الحساب. سجّل القيم دون كشف كلمة المرور، وتجنب لصق الأسرار في سجلات طويلة الأمد. إن ظهر 407 من دون ترويسة Proxy-Authenticate أصلاً، فالبروكسي أو جهاز وسيط يعيد الاستجابة بشكل غير قياسي، وهنا يلزم فحص سجل البروكسي نفسه بدل الاعتماد على رسالة العميل وحدها.
تفكيك Timeout: أين تتوقف مراحل الاتصال
تتضمّن رحلة الطلب عبر البروكسي عدة مراحل: حلّ اسم المضيف، ثم فتح اتصال TCP، ثم التفاوض على TLS إن كان الاتصال محمياً، ثم إرسال طلب CONNECT للمواقع المشفّرة، ثم انتظار رد الموقع الأصلي. لكل مرحلة مهلة قد تنتهي منفصلة، ومعرفة المرحلة المتعثرة تحدّد الحل المناسب. مهلة عند حلّ الاسم تشير إلى مشكلة في DNS، ومهلة عند TCP تشير إلى منفذ مغلق أو حجب، ومهلة بعد الاتصال تشير إلى خادم بطيء.
تظهر أخطاء المهلة أيضاً عند استخدام بروكسي وسيط بطيء أو مزدحم، أو عند تمرير طلبات كبيرة عبر اتصال محدود النطاق. زيادة المهلة العمياء قد تخفي السبب وتؤخر ظهور الفشل دون إصلاحه. سجّل الزمن لكل مرحلة إن أمكن، وقارن مهلة الاتصال بمهلة القراءة، لأن انتظار رد طويل بعد نجاح الاتصال يشير غالباً إلى مشكلة في الخادم الهدف أو إلى عنق زجاجة في الشبكة نفسها.
ضبط المهلة وترويسات الاتصال بشكل صحيح
افصل دائماً بين مهلة إنشاء الاتصال ومهلة قراءة الاستجابة. المهلة القصيرة جداً تفشل مع الشبكات بطيئة الاستجابة، والطويلة جداً تجعل التطبيق يتجمد عند انقطاع البروكسي. اختر قيمة معقولة لمهلة الاتصال بحيث لا تتجاوز زمن انتظار المستخدم المقبول، واجعل مهلة القراءة أكبر للموارد الضخمة. عند العمل مع خدمات تدفّق البيانات أو التنزيلات الكبيرة، اضبط المهلة لتناسب طبيعة المصدر بدل استخدام قيمة واحدة للجميع.
لا تنسَ ترويسة إبقاء الاتصال، إذ يقلّل الاتصال المعاد استخدامه زمن المصافحة المتكررة عبر البروكسي. لكن بعض البروكسيات تغلق الاتصال الخامل بسرعة، فتسبب أخطاء مهلة مفاجئة بعد فترات سكون. راقب سلوك الإغلاق واضبط زمن إعادة الاستخدام أقل من مهلة البروكسي الخاملة، وتأكد من أن مكدّس الشبكة يعيد المحاولة مرة واحدة على الأقل قبل إعلان الفشل للمستخدم النهائي.
بروكسي HTTPS وطلب CONNECT
عند تصفّح موقع مشفّر عبر بروكسي، يرسل العميل طلب CONNECT يحدّد الهدف ورقم المنفذ، وينشئ البروكسي نفقاً شفافاً يمرّر البيانات المشفّرة. هذا النفق يعني أن البروكسي لا يرى المحتوى، لكنه قد يطلب المصادقة أولاً، فيرد ب ـ 407 على طلب CONNECT نفسه. إن تجاهل العميل هذا الرد أو لم يعاود الطلب مع الترويسة المناسبة، فسيبدو الأمر كفشل اتصال لا كخطأ صلاحيات، وهذا سبب شائع للالتباس.
بعض البروكسيات تسمح بمنافذ محددة فقط، مثل منفذ HTTPS القياسي، وترفض المنافذ غير المعتادة بأخطاء مهلة بدل رفض صريح. إن نجح الوصول إلى موقع على المنفذ القياسي وفشل موقع على منفذ مخصص عبر البروكسي نفسه، فالسبب غالباً سياسة المنافذ لا بيانات الاعتماد. وثّق المنافذ المسموح بها من مسؤول الشبكة بدلاً من تخمينها، لأن معرفة الحدود المسموحة تختصر نصف مسار التشخيص.
متغيرات البيئة و NO_PROXY وسلوك التطبيقات
تعتمد معظم أدوات سطر الأوامر على متغيرات مثل HTTP_PROXY و HTTPS_PROXY و ALL_PROXY، مع اختلاف ملحوظ في حالة الأحرف بين الأنظمة والبرامج. هذا الاختلاف قد يسبب سلوكاً متبايناً: أداة تقرأ المتغير بحروف كبيرة وأخرى بحروف صغيرة. اضبط الصيغتين معاً لتغطية أغلب الحالات، وتأكد من أن قيمة المتغير تحتوي على المخطط والمنفذ بشكل صحيح، لأن قيمة ناقصة تنتج أخطاء لا تشبه أخطاء المصادقة إطلاقاً.
متغير NO_PROXY مهم لتجاوز البروكسي للموارد الداخلية والعناوين المحلية، وخطأ نمطه يعني محاولة تمرير عنوان محلي عبر بروكسي خارجي فيفشل أو يبطؤ بلا داعٍ. استخدم أنماطاً دقيقة تشمل النطاقات الفرعية المطلوبة دون تعميم زائد. واعلم أن بعض التطبيقات الرسومية لا تقرأ هذه المتغيرات أصلاً، بل تعتمد إعدادات نظام أو ملف تكوين خاصاً بها، فيجب ضبطها منفصلة واختبارها بذاتها.
قراءة السجلات وربط الاستجابة بالسبب
سجلات البروكسي هي المرجع الحاسم عند الشك، إذ تحتوي على رمز الحالة والهدف والزمن وسبب الرفض. ابحث عن نمط 407 المتكرر: هل يرتبط بحساب معيّن أو ببرنامج محدد؟ فالتكرار من عميل واحد يشير إلى إعداد خاطئ في ذلك العميل لا إلى تعطّل عام في البروكسي. طابق الطوابع الزمنية مع أخطاء المهلة لتحديد إن كانت مرتبطة بارتفاع الحمل أو بحدث شبكي في وقت محدد.
شغّل عميلاً بسيطاً واحداً في وقت واحد لعزل المتغيرات، وثبّت باقي الإعدادات دون تغيير، وسجّل ما تغيّر بين محاولة ناجحة وأخرى فاشلة. اقرأ رسالة الخطأ كما هي بدل الاعتماد على ترجمة برامج ذات واجهة رسومية قد تكون مضللة أو منقوصة. عند الحاجة، اطلب من مسؤول البروكسي رؤية سبب الرفض من جانبه، فسجل الخادم يكشف تفاصيل لا يراها العميل على الإطلاق.
قائمة تشخيص عملية خطوة بخطوة
ابدأ بتأكيد أنك تستخدم البروكسي فعلاً وأن عنوانه ومنفذه مطابقان لما تظنه. ثم اختبر اتصالاً مباشراً بسيطاً للتأكد من عمل الشبكة الأساسية قبل إدخال البروكسي في المعادلة. بعدها أرسل طلباً مع بيانات اعتماد صحيحة وتحقّق من ترويسة المصادقة. إن ظهر 407 فالمشكلة صلاحيات، وإن ظهرت مهلة فانتقل إلى فحص المراحل: DNS، ثم TCP، ثم TLS، ثم CONNECT.
عند كل خطوة، غيّر متغيراً واحداً فقط ودوّن النتيجة، لأنه لا يمكن الجزم بأي تعديل لاحق إن تراكمت التغييرات معاً. تحقّق من توقيت النظام، إذ يؤثر انحراف الساعة على أنظمة المصادقة المعتمدة على الوقت. وأخيراً وثّق التكوين النهائي الذي نجح في ملف مرجعي واضح، حتى تعيده بسرعة عند تغيير الجهاز أو الشبكة أو ترقية الأدوات لاحقاً.
أسئلة شائعة
ما سبب خطأ 407 رغم صحة اسم المستخدم وكلمة المرور؟
السبب غالباً ليس كلمة المرور بل نوع المصادقة أو صيغة الترويسة. قد يتوقع البروكسي نظام Negotiate بينما يرسل العميل بيانات Basic، أو قد تكون الترويسة ناقصة أو غير مرمّزة بشكل صحيح. تحقّق من ترويسة Proxy-Authenticate في الاستجابة لمعرفة المطلوب، وطابق إعدادات العميل معه قبل إعادة المحاولة.
كيف أفرّق بين Timeout سببه البروكسي و Timeout سببه الموقع؟
اختبر الموقع نفسه دون بروكسي: إن نجح الاتصال المباشر وفشل الاتصال عبر البروكسي فالمشكلة في البروكسي أو الشبكة الوسيطة. وإن فشل الاتصال في الحالتين فالمشكلة غالباً في الموقع الهدف أو في الشبكة المحلية. يساعدك قياس زمن كل مرحلة على تحديد موضع التعطّل بدقة أكبر.
هل زيادة مهلة الانتظار تحلّ مشكلة المهلة؟
ليست حلاً جذرياً في أغلب الحالات، لكنها مفيدة أحياناً لتشخيص مشكلة أداء حقيقية. زيادة المهلة دون فهم السبب قد تخفي الخطأ وتؤخر ظهوره للمستخدم. الأفضل تحديد المرحلة المتعثرة أولاً، ثم ضبط قيمة مهلة مناسبة لكل مرحلة على حدة بدل قيمة واحدة عامة.
لماذا يظهر خطأ 407 فقط عند فتح مواقع HTTPS؟
لأن العميل يرسل طلب CONNECT لإنشاء نفق مشفّر، وقد يطلب البروكسي المصادقة على هذا الطلب نفسه. إن لم يعاود العميل الطلب مع ترويسة المصادقة المناسبة، يظهر 407 يبدو كأنه يخصّ المواقع المشفّرة وحدها. تحقّق من دعم العميل لمصادقة النفق، ومن نظام المصادقة المطلوب من البروكسي.
كيف أتجنب إرسال كلمة المرور بشكل غير آمن إلى البروكسي؟
تجنّب إرسال بيانات Basic عبر اتصال غير مشفّر، لأنها تُرسل مرمّزة بحيث يمكن فكّها بسهولة. فضّل مصادقة Digest أو Negotiate عند دعمها، وتأكد من أن الاتصال إلى البروكسي نفسه محميّ ب ـ TLS. ولا تكتب كلمة المرور في سجلات أو ملفات تكوين يسهل الوصول إليها من أجهزة مشتركة.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…