عادةً ما يبدو إعداد البروكسي الأول جيدًا إلى أن يبدأ المتصفح بالتصرف بشكل مختلف عن جهاز الاختبار. تظهر حلقة تسجيل دخول، أو تُحمَّل صفحة من دون المحتوى المتوقع، أو يتضح أن المتصفح متصل بالإنترنت بينما لا يزال التطبيق المجاور له عاجزًا عن الوصول إلى الشبكة. عندها لا تعود إعدادات البروكسي في المتصفح مجرد حقلي مضيف ومنفذ، بل تصبح قرارًا بشأن التوجيه يؤثر في كيفية خروج كل طلب من الجهاز.
ما الذي تتحكم فيه إعدادات البروكسي في المتصفح فعلًا
يغيّر البروكسي في المتصفح المسار الذي يسلكه الطلب، لا العنوان الذي يتصل به فحسب. تعمل المتصفحات الحديثة عمومًا بثلاثة أوضاع، الاتصال المباشر أو التهيئة اليدوية للبروكسي أو التهيئة التلقائية عبر PAC أو WPAD، ويغيّر كل وضع كيفية توجيه حركة المرور على مستوى الطلب، لا وفق مفهوم مبهم مثل «تشغيل المتصفح أو إيقافه». PAC، اختصارًا لـ التهيئة التلقائية للبروكسي، هو ملف JavaScript صغير يخبر المتصفح ما إذا كان ينبغي توجيه عنوان URL معيّن مباشرةً أو عبر بروكسي واحد أو عبر مسار احتياطي. صممت Netscape تنسيق PAC لأول مرة عام 1996 لمتصفح Navigator 2.0، ولا تزال فكرة التوجيه بحسب الوجهة هذه جوهر توجيه البروكسي في المتصفحات حتى اليوم تاريخ التهيئة التلقائية للبروكسي وأساسيات PAC.
قاعدة عملية: إذا كان المتصفح يصل إلى الويب لكن الجلسة لا تزال غير صحيحة، فقد يكون البروكسي يعمل تمامًا وفقًا للتهيئة، بينما تظل قواعد التوجيه غير مناسبة لتلك الوجهة.
الطبقة أهم من الحقل الذي عدّلته
أشيع خطأ في الإعداد هو تعديل الطبقة الخاطئة. غالبًا ما ترث المتصفحات المعتمدة على Chromium تهيئة البروكسي في نظام التشغيل، بينما يحتفظ Firefox بعناصر تحكم خاصة به على مستوى المتصفح. ولدى Windows أيضًا مسار منفصل تستخدمه خدمات الخلفية، لذا قد يحمّل المتصفح المواقع بينما تظل خدمات التحديث وأدوات سطر الأوامر والتطبيقات الأخرى عاجزة عن الاتصال.
لهذا، ليس السؤال الأول «ما مضيف البروكسي الذي أدخلته؟» بل «ما حركة المرور التي تحاول توجيهها؟» إذا كنت تحتاج فقط إلى توجيه حركة مرور المتصفح عبر بروكسي، فغيّر إعدادات طبقة المتصفح. أما إذا كنت تريد أن يتبع الجهاز بأكمله المسار نفسه، فلن يحقق ذلك حقل المتصفح وحده.
أنواع البروكسيات وبروتوكولاتها التي ستصادفها
يختلط الأمر في سوق البروكسيات لأن الناس يخلطون بين نوع البروكسي وبروتوكول البروكسي. فهما خياران مختلفان. تصف بروكسيات الهاتف المحمول والسكنية ومراكز البيانات مصدر حركة المرور الظاهر، بينما يصف HTTP وSOCKS5 طريقة ترحيل المتصفح لحركة المرور هذه.
بروكسيات الهاتف المحمول والسكنية ومراكز البيانات ليست قابلة للاستبدال
تستخدم بروكسيات الهاتف المحمول شبكات شركات الاتصالات، وتظهر البروكسيات السكنية على أنها اتصالات إنترنت للمستهلكين، بينما تأتي بروكسيات مراكز البيانات من بنية الاستضافة التحتية. عمليًا، عادةً ما تكون بروكسيات الهاتف المحمول الأصعب في الاكتشاف، لأنها تعمل ضمن توجيه حقيقي لشركات الاتصالات، وغالبًا خلف ترجمة عناوين الشبكة على مستوى شركة الاتصالات، حيث يتشارك العديد من المشتركين نقطة خروج واحدة. وهذا يجعل الحظر البسيط أكثر خطورة على الجهة المستهدفة، إذ قد يؤدي حظر نطاق واحد إلى استهداف مستخدمين شرعيين إلى جانب الأنشطة المؤتمتة.
يسهل تحديد بصمة بروكسيات مراكز البيانات لأنها تعمل ضمن بيئات استضافة واضحة. وتقع البروكسيات السكنية بين النوعين؛ إذ تتميز ببصمة أقرب إلى الشبكات المنزلية مقارنةً بحركة مرور مراكز البيانات، لكنّها لا توفر تمويهًا على مستوى شركات الاتصالات مثل بروكسيات الهاتف المحمول. ولهذا تختار الفرق العاملة في التحقق من الإعلانات أو أبحاث السوق أو إدارة الحسابات فئة البروكسي استنادًا إلى مدى حساسية الموقع المستهدف لمصدر الشبكة.
يحل HTTP وSOCKS5 مشكلتين مختلفتين
تشيع بروكسيات HTTP لحركة مرور المتصفح وحدها وعمليات التحقق الجغرافي المباشرة. أما SOCKS5 فهو أعمّ استخدامًا، ويصبح مهمًا عندما يكون سلوك DNS مهمًا أو عندما تحتاج إلى ترحيل أنقى لحركة مرور غير HTTP. تميّز وثائق متصفح Mozilla بين بروكسيات HTTP وSOCKS، وتدعم الإصدار 4 أو 5 من SOCKS، وتشير إلى أن القيمة الافتراضية لـ proxyDNS هي true في SOCKS5 وfalse في SOCKS4 واجهة API لإعدادات البروكسي في Mozilla.
| البُعد | بروكسي HTTP | بروكسي SOCKS5 |
|---|---|---|
| نموذج التوجيه | طلبات الويب الموجّهة إلى المتصفح | ترحيل اتصال أعمّ استخدامًا |
| سلوك DNS | يُحل عادةً خارج طبقة البروكسي | يمكن إرسال حل أسماء المضيفين عبر البروكسي عند تفعيل ذلك |
| الأنسب لـ | عمليات التحقق الجغرافي البسيطة عبر المتصفح والجلسات الأساسية الموثّقة | الاختبارات الحساسة لـ DNS والتحقق من الجلسات الثابتة واحتياجات توجيه حركة مرور غير HTTP |
| المخاطر التشغيلية | أسهل في الإعداد، وأسهل في سوء التهيئة جزئيًا | عناصر أكثر، لكن مع تحكم أكبر في التوجيه |
إذا بدت الصفحة صحيحة لكن الجلسة لا تزال تتصرف على نحو خاطئ، فتحقق من DNS قبل إلقاء اللوم على البروكسي نفسه.
تهيئة إعدادات البروكسي في متصفحات سطح المكتب
غالبًا ما تعتمد Chrome وEdge على Windows على لوحة البروكسي في نظام التشغيل، لذا تكون في كثير من الأحيان بصدد تهيئة الجهاز لا نافذة المتصفح. أما Firefox فيختلف عن ذلك، إذ يحتفظ بإعدادات الشبكة الخاصة به داخل المتصفح. ويتبع Safari على macOS لوحة بروكسي النظام أيضًا، ما يعني أن سلوك المتصفح يرث التهيئة من إعدادات النظام.
في المتصفحات المعتمدة على Chromium، ابدأ من الإعدادات > الشبكة والإنترنت > البروكسي على Windows، ثم أدخل قيم HTTP وHTTPS وFTP والقيم الاحتياطية عند الحاجة. يدعم نموذج البروكسي في Chrome صراحةً قواعد منفصلة لـ HTTP وHTTPS وFTP والقواعد الاحتياطية، وقد يؤدي تهيئة بروتوكول واحد فقط إلى تجاوز بعض الطلبات للبروكسي تمامًا قواعد البروكسي وأوضاعه في Chrome. أكثر الأخطاء شيوعًا هنا هو إدخال ` URL كامل في حقل لا يتوقع سوى اسم مضيف ومنفذ. ومن الأخطاء الأخرى افتراض أن بروتوكولًا واحدًا يغطي كل شيء.
توجد إعدادات Firefox في التفضيلات > الإعدادات > عام > إعدادات الشبكة > إعدادات الاتصال. يمكنك هناك ضبط الوضع اليدوي، واختيار ما إذا كان بروكسي واحد سيتولى أيضًا اتصالات HTTPS، وتحديد قائمة التجاوز لا يوجد بروكسي لـ. ويتعرف Firefox أيضًا على الرمز الخاص <local> لأسماء المضيفين التي لا تحتوي على نقاط، وهو مفيد عندما ينبغي استثناء الأسماء الداخلية من استخدام البروكسي. يفيد الدليل الداخلي لإعداد Chrome إذا كنت تريد شرحًا تفصيليًا خاصًا بالمتصفح، وينطبق المنطق نفسه عند المقارنة بين المسارات على مستوى المتصفح والمسارات على مستوى النظام: شرح إعداد البروكسي في Chrome.
يعيدك Safari إلى التفضيلات > متقدم > البروكسيات > تغيير الإعدادات، لأن macOS يتولى طبقة الشبكة خارج المتصفح نفسه. ويهم هذا التمييز عندما يقول أحد أعضاء الفريق «Safari يعمل» لكن بقية الجهاز لا تعمل، أو العكس. فقد يكون المتصفح سليمًا بينما النظام ككل ليس كذلك.
التعامل مع المصادقة والتوجيه المعتمد على PAC
تُعد المصادقة نقطة ضعف في كثير من إعدادات البروكسي في المتصفح. تقبل بعض البرامج بيانات الاعتماد المضمّنة بصيغة username:password@host:port، لكن هذا الخيار غير مناسب للبيئات المشتركة، إذ تمر السلسلة كاملةً عبر طبقة أخرى ويصعب إدارتها بطريقة منظمة. عمليًا، الخيار الأكثر أمانًا هو ترك المتصفح يطلب بيانات الاعتماد، أو معالجة المصادقة من خلال إعداد يعتمد على PAC، بحيث يحل المتصفح التوجيه بشكل منفصل عن طلب تسجيل الدخول.
ملفات PAC مخصصة للتوجيه المشروط، لا لمجرد التسهيل
يُعد ملف PAC الخيار المناسب عندما يعتمد التوجيه على الوجهة. إذ يمكنه توجيه مضيف إلى الاتصال المباشر، وآخر عبر وكيل أساسي، وثالث عبر وكيل احتياطي. تدعم بنية الوكيل في Chrome كلاً من auto_detect، الذي يحصل على نص PAC عبر WPAD، وpac_script، الذي يحمّل ملف PAC من URL أو من محتوى مُقدَّم. وتشير وثائق Chromium أيضًا إلى أن المنفذ 80 هو المنفذ الافتراضي للمعرّف PROXY واجهة برمجة تطبيقات الوكيل في Chrome.
يحتوي ملف PAC على منطق للتوجيه، وليس مجرد عنوان وكيل واحد.
إذا كنت تدير مجموعة من الأجهزة، يمنحك PAC طريقة سهلة للصيانة للفصل بين الوجهات الداخلية والخارجية من دون تعديل كل محطة عمل يدويًا. يمكن لـ WPAD توزيع مواقع ملفات PAC عبر DHCP أو DNS، لكنه واسع الانتشار وليس معيارًا رسميًا للإنترنت، لذا تظل الضوابط الأمنية الصريحة مهمة. للاطلاع على نظرة عامة أوسع حول الإعداد، يجدر إبقاء دليل إعداد الوكيل التلقائي في متناولك: دليل إعداد الوكيل التلقائي.
تهيئة متصفحات الأجهزة المحمولة عبر إعدادات النظام
لا توفر متصفحات الأجهزة المحمولة عادةً لوحة وكيل متقدمة داخل التطبيق. فهي ترث الإعدادات من نظام التشغيل، ما يعني أنك تهيئ ملف تعريف شبكة الهاتف، لا مجرد علامة تبويب في المتصفح. هذا هو التصور المناسب عند اختبار تدفقات الاستخدام المصممة للأجهزة المحمولة أولًا، خصوصًا عندما يهتم الهدف بأصل الشبكة وسلوك الجهاز معًا.
في iOS، المسار هو إعدادات Wi-Fi > وكيل HTTP > يدوي. أدخل الخادم والمنفذ وتفاصيل المصادقة هناك، ولا يسري التغيير إلا على شبكة Wi-Fi تلك. إذا اتصلت بمعرّف SSID مختلف، فلن ينتقل الإعداد معك بالضرورة. وهذا يفاجئ بعض المستخدمين لأن المتصفح يبدو كما هو، بينما تغيّر المسار من دونه.
في Android، المسار هو إعدادات Wi-Fi > تعديل الشبكة > الوكيل > يدوي. وينطبق القيد نفسه المرتبط بالشبكة، كما قد تتجاوز بعض التطبيقات الوكيل المُهيأ لحركة مرور معينة. لهذا السبب، غالبًا ما يتطلب اختبار متصفحات الأجهزة المحمولة نقطة اتصال وكيل للأجهزة المحمولة أو تطبيق وكيل على الجهاز، بدلًا من تعديل المتصفح كما تفعل على سطح المكتب.
أنت تهيئ مسار النظام، لا اختصارًا يقتصر على المتصفح.
إذا كنت تقارن بين التوجيه عبر الأجهزة المحمولة ومراكز البيانات لأغراض ضمان الجودة أو تدفقات العمل على الشبكات الاجتماعية أو الفحوصات المعتمدة على الموقع الجغرافي، فهنا يصبح الفرق عمليًا. فالمتصفح على جهاز محمول يستخدم شبكة مدعومة من شركة اتصالات يتصرف كمتصفح على جهاز محمول، بينما يظل متصفح سطح المكتب الذي يستخدم إعدادًا محليًا متصفحًا لسطح المكتب، حتى لو استخدم وكيلًا.
اختبار الاتصالات وتشخيص حالات الإخفاق الجزئي
ينجح اختبار الوكيل عندما يتمكن المتصفح من جلب صفحة. لكنه لا ينجح على النحو المطلوب إلا عندما يجلب المتصفح الصفحة الصحيحة من المكان الصحيح وبسلوك الجلسة الصحيح. وهذا الفرق مهم، لأن الوكيل قد يكون قابلًا للوصول بينما تظل تجربة التصفح غير سليمة.
ابدأ بأربعة فحوصات. أولًا، تأكد من أن المتصفح يستخدم الوضع المقصود في لوحة الإعدادات. ثانيًا، افتح نقطة نهاية اختبار HTTPS للتأكد من أن التعامل مع TLS ليس مصدر المشكلة. ثالثًا، تحقّق من IP الصادر والموقع الجغرافي الظاهرين عبر خدمة بحث خارجية. رابعًا، افتح اسم مضيف يفترض أن يتجاوز الوكيل، مثل هدف اختبار داخلي أو محلي، وتأكد من أن قائمة التجاوز تعمل.
الإخفاقات الواضحة يسهل اكتشافها، أما الخفية فلا. فحلقات إعادة التوجيه، وتكرار تسجيل الدخول، والصفحات الفارغة، واختفاء المحتوى الذي يتطلب اشتراكًا، والحظر المرتبط بوجهة معينة، غالبًا ما تشير إلى سلوك DNS أو ملفات تعريف الارتباط أو بصمة المتصفح أو سياسة الجهة المستهدفة، لا إلى تعطل الوكيل. لذلك من المفيد مقارنة الطلبات المباشرة بالطلبات الموجّهة عبر الوكيل، واختبار أكثر من وجهة، واستخدام ملف تعريف متصفح نظيف عندما لا تتطابق النتائج.
كما تختلف أخطاء المصادقة والنقل. يشير HTTP 407 إلى مصادقة الوكيل، ويشير 403 إلى رفض الوجهة، بينما تعني استجابات 5xx عادةً وجود خلل في المُرحِّل أو المسار إلى الخادم الأصلي. إذا اكتفيت بالتحقق من اتصال المتصفح، فستغفل هذه الفروق.
إن عبارة «الوكيل يعمل» لا تعني نتيجة ثنائية؛ فملفات تعريف الارتباط والإعدادات المحلية وDNS وسمعة IP وبصمة المتصفح، كلها قد تغيّر النتيجة بصورة مستقلة عن الاتصال الأساسي.
للحصول على مرجع منظّم لاستكشاف الأخطاء وإصلاحها، تُعد قائمة التحقق هذه لاكتشاف الوكيل مرجعًا مساعدًا مفيدًا: اختبار اكتشاف الوكيل.
اختيار المنافذ الشخصية مقابل المشتركة والخطوات التالية
في تدفقات العمل المشروعة مثل إدارة حسابات متعددة على وسائل التواصل الاجتماعي وأبحاث السوق والتحقق من الإعلانات ومراقبة الأسعار وتحسين محركات البحث وحماية العلامة التجارية واختبار ضمان الجودة والخصوصية، ينحصر الاختيار عادةً بين البصمة النظيفة والتكلفة الأقل. تناسب المنافذ الشخصية الأعمال التي تتطلب إعدادًا ثابتًا ومخصصًا. أما المنافذ المشتركة فتناسب الاختبارات القصيرة والمهام محدودة الميزانية وتدفقات العمل التي تكون فيها أهمية التدوير أكبر من أهمية الاستمرارية.
المقايضة بسيطة. توفر الأجهزة المحمولة الشخصية عناوين IP فريدة وهوية أكثر نظافة لأعمال الإنتاج التي لا تحتمل التغيير المتكرر. أما المنافذ المشتركة فهي أسهل للاستخدام في التحقق والتشغيل لفترات قصيرة، خصوصًا عند الرغبة في التدوير المجدول أو التبديل عند الطلب. ولا تهم فترات التدوير وحدود حركة المرور بقدر أهمية بقاء المسار مقنعًا للهدف الذي تختبره.
اختر المنافذ الشخصية عندما تكون سلامة الحساب مهمة، واختر المنافذ المشتركة عندما يكون الحجم والتكلفة أهم.
إذا كنت تعمل على أتمتة متوافقة أو ضمان جودة حساس للموقع الجغرافي أو التحقق من الإعلانات، وتحتاج إلى بصمة للأجهزة المحمولة تناسب المهمة، فعادةً ما تكون بروكسيات 4G للأجهزة المحمولة هي الخطوة التالية للاختبار. توفر Evoproxy إمكانية الوصول إلى بروكسيات الأجهزة المحمولة بما يلائم تدفقات العمل المعتمدة على المتصفح، لتتمكن من التحقق من أن إعدادك يعمل على النحو الصحيح قبل توسيع نطاقه ليشمل الحسابات أو الحملات.
إذا كنت تريد تحسين توجيه المتصفح واستقرار الجلسات والاختبارات الخاصة بمواقع جغرافية محددة من دون التخمين بشأن طبقة الشبكة، فألقِ نظرة على Evoproxy. إنه خيار عملي لتدفقات عمل بروكسيات الأجهزة المحمولة التي تحتاج فيها إعدادات وكيل المتصفح والمصادقة وسلوك الوجهة إلى التوافق بسلاسة.
