تغيير إعدادات البروكسي في Chrome

أنت تحدّق في متصفح يقول إن البروكسي مضبوط، بينما لا يزال تسجيل الدخول يفشل، ونصف الفريق يريد إلقاء اللوم على Chrome، والنصف الآخر يحرّر طبقة غير صحيحة تمامًا. هذه هي الفوضى المعتادة وراء تغيير إعدادات البروكسي في Chrome، خصوصًا عندما يعتمد التحقق من الإعلانات أو الكشط أو ضمان جودة الحسابات أو أبحاث السوق على وصول المتصفح إلى عنوان IP للخروج الصحيح في كل مرة.

لا يعمل Chrome كتطبيق بروكسي مستقل. فهو يعتمد على مكدس الشبكة في نظام التشغيل، لذا تحدد نقطة التحكم التي تغيّرها ما إذا كنت قد غيّرت مسارًا خاصًا بالمتصفح فقط، أو مسار الجهاز بأكمله، أو سياسة مؤسسية لا يمكنك تجاوزها من واجهة المستخدم. يتعامل نموذج الشبكة في Chromium مع البروكسي بوصفه جزءًا من الشبكات المشتركة للنظام، وهذا التمييز هو ما يوفر ساعات من العمل عندما تبدو النتيجة «مضبوطة» لكن حركة المرور لا تزال تُوجَّه إلى المكان الخطأ (وثائق إعدادات الشبكة في Chrome Enterprise من Google).

كيف يتعامل Chrome مع إعدادات البروكسي من الداخل

يصبح سلوك البروكسي في Chrome مفهومًا عندما تتوقف عن اعتبار مربع حوار المتصفح مصدر الحقيقة. يعتمد مكدس الشبكة في Chromium على إعدادات البروكسي في نظام التشغيل، لذا يرث Chrome عناصر التحكم بالبروكسي وسلوك الشبكة ذي الصلة الذي يتيحه نظام التشغيل بالفعل (وثائق إعدادات الشبكة في Chrome Enterprise من Google). ولهذا السبب، غالبًا ما يغيّر تعديل إعداد في Chrome سلوك حركة المرور خارج Chrome نفسه.

الطبقات التي تتعامل معها

يبدأ المسار عادةً من chrome://settings/system، حيث يحوّلك Chrome إلى لوحة البروكسي الخاصة بالنظام الأساسي. ومن هناك، قد يأتي السلوك من مضيف ومنفذ محددين يدويًا، أو نص PAC، أو الاكتشاف التلقائي، أو علامة بدء تشغيل مثل --proxy-server أو --proxy-auto-detect أو --no-proxy-server أو --proxy-bypass-list (وثائق البروكسي في Chromium، وثائق API البروكسي لإضافات Chrome). عمليًا، تشمل الطبقات التي يجدر التحقق منها نقطة الدخول في المتصفح، ومخزن البروكسي في نظام التشغيل، وأي طبقة بدء تشغيل أو سياسة تتجاوزهما.

قاعدة عملية: إذا قبل المتصفح القيمة لكن حركة المرور لا تزال تخرج من المكان الخطأ، فافترض أنك عدّلت الطبقة غير الصحيحة قبل أن تفترض أن البروكسي نفسه معطّل.

يضيف ChromeOS تعقيدًا آخر، إذ يدعم أوضاع يدوي ونص PAC واكتشاف تلقائي ومباشر على مستوى الملف الشخصي. يهم ذلك الفرق التي تحتاج إلى اختبار محدد النطاق، لأن تغيير إعداد في ملف ChromeOS الشخصي قد يكون أضيق نطاقًا من تغيير نظام التشغيل بأكمله، في حين يمكن لتغيير بروكسي النظام أن يؤثر في أكثر من Chrome. افصل بين هذه الطبقات، وستتضح نقطة الخلل عادةً بسرعة أكبر.

إعداد بروكسي يدوي على Windows وmacOS

يُعد البروكسي اليدوي الخيار المناسب عندما تعرف نقطة النهاية بالفعل ولا تحتاج إلى منطق توجيه. على Windows، ينقلك مسار Chrome «فتح إعدادات البروكسي للكمبيوتر» إلى الإعدادات → الشبكة والإنترنت → البروكسي، حيث تُدخل المضيف والمنفذ وقائمة التجاوز. أما على macOS، فالمسار المكافئ هو إعدادات النظام → الشبكة → الواجهة النشطة → التفاصيل → البروكسيات، حيث توجد الحقول نفسها ضمن عناصر التحكم في النظام الأساسي.

الإعداد على Windows وmacOS دون تخمين

الخطوات مباشرة:

1. افتح إعدادات نظام Chrome. استخدم اختصار المتصفح للوصول إلى لوحة البروكسي في نظام التشغيل بدلًا من البحث في قوائم لا صلة لها.
2. اختر إدخال البروكسي يدويًا. أدخل مضيف البروكسي ومنفذه في حقل البروتوكول الصحيح.
3. أضف قواعد التجاوز عند الحاجة. أخرج الخدمات المحلية أو لوحات الإدارة الداخلية أو أهداف الاختبار من مسار البروكسي عندما يتطلب سير العمل ذلك.
4. احفظ الإعدادات وتحقق منها. تأكد من أن حركة المرور تخرج عبر عنوان IP للخروج المتوقع، لا من أن مربع الحوار قبل القيم فحسب.

يفصل نموذج البروكسي اليدوي في Chrome حركة المرور بحسب المخطط. فهو يستخدم قائمة لحركة مرور HTTP، وأخرى لحركة مرور HTTPS، ومجموعة منفصلة لحركة المرور التي لا تندرج ضمن هاتين الفئتين. وقد يؤدي هذا الفصل إلى إخفاقات فعلية. إذ يمكن لفريق توجيه HTTP إلى بروكسي وترك HTTPS على مسار مختلف دون أن يلاحظ ذلك، إلى أن يفشل طلب أو يبدو أنه صادر من منطقة خاطئة. كما لا يتعامل Chrome مع بيانات الاعتماد المضمّنة في الإعداد بوصفها طريقة مصادقة عادية.

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

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

تهيئة البروكسي التلقائي باستخدام PAC وWPAD

تفشل إدخالات البروكسي الثابتة بمجرد أن يتعين تغيير التوجيه بحسب الوجهة أو الموقع الجغرافي أو حالة الجلسة. تتولى ملفات PAC وWPAD هذه الطبقة. يستخدم PAC، أو التكوين التلقائي للبروكسي، JavaScript لتحديد ما إذا كان ينبغي توجيه URL عبر PROXY أو DIRECT أو SOCKS. أما WPAD فيكتشف موقع PAC تلقائيًا عبر استكشاف الشبكة (وثائق البروكسي في Chromium).

PAC عندما يحتاج التوجيه إلى منطق

يمكن أن يكون ملف PAC بسيطًا إلى حد إرجاع قيمة واحدة لكل URL. يصلح ذلك لمسار اختبار ثابت، لكن القيمة الحقيقية تكمن في التوجيه المشروط، مثل توجيه المضيفين الداخليين مباشرةً، مع تمرير الأهداف الخارجية عبر بروكسي. ومن السهل تفويت سبب الإخفاق: فقد يعيد PAC القيمة DIRECT لمضيف توقعت تمريره عبر البروكسي، لذا اختبر الوجهات الدقيقة التي يعتمد عليها سير عملك.

تجعل مجموعة القواعد البسيطة السلوك واضحًا:

function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, ".internal.example")) return "DIRECT";
  return "PROXY proxy.example.com:8080 DIRECT";
}

هذا النوع من التفرّع هو ما يجعل PAC مناسبًا لمنطق الجلسات الثابتة والتدوير والتوجيه المستند إلى ASN. إذا كنت بحاجة إلى مرجع أوسع للإعداد، فإن دليل إعداد البروكسي التلقائي هذا مفيد لتوحيد عملية النشر على مجموعة من الأجهزة.

WPAD والتنبيه الخاص بأجهزة Mac

WPAD هو مسار الاكتشاف. فهو يستعلم عبر DNS أو DHCP للعثور على عنوان PAC، ويعمل ذلك جيدًا على الشبكات المُدارة التي يُفترض فيها اكتشاف موقع البروكسي بدلًا من تحديده يدويًا. توضح وثائق الشبكة في Chromium سير عمل اكتشاف WPAD، كما تشرح إرشادات Chrome Enterprise من Google كيف يندمج هذا الاكتشاف مع عمليات نشر Chrome المُدارة (وثائق إعدادات الشبكة في Chrome Enterprise من Google).

هناك تنبيه تشغيلي مهم لمجموعات أجهزة Mac. توثّق Chromium أن Chrome على macOS لا يدعم WPAD القائم على DHCP عند اختيار الاكتشاف التلقائي (وثائق API البروكسي لإضافات Chrome). هذا إخفاق في النشر، وليس حالة نظرية نادرة.

استخدم الإعدادات اليدوية عندما تكون نقطة النهاية ثابتة. واستخدم PAC عندما تحتاج قواعد التوجيه إلى منطق. ولا تستخدم WPAD إلا عندما تكون الشبكة مصممة للاكتشاف وبعد اختباره على المنصة نفسها التي تخطط لنشره عليها.

تغيير إعدادات البروكسي في Chrome على Android

لا يوفّر Chrome على Android مربع حوار منفصلًا للوكيل داخل المتصفح. يوجد إعداد الوكيل ضمن ملف تعريف Wi-Fi، لذا تغيّره من خلال الشبكة المتصل بها بدلًا من تغييره من Chrome نفسه. على جهاز استهلاكي، يعني ذلك عادةً الضغط مطولًا على SSID النشط، وفتح تفاصيل الشبكة، وضبط الوكيل ضمن الخيارات المتقدمة.

المسار الذي يعمل فعليًا على Android

ابدأ بشبكة Wi-Fi المتصل بها، ثم افتح إعدادات التعديل أو الإعدادات المتقدمة لذلك الـ SSID. أدخل تفاصيل الوكيل هناك واحفظها، وتذكّر أن الوكيل لا يُطبّق إلا ما دام الجهاز متصلًا بتلك الشبكة. وإذا انتقل الجهاز إلى استخدام شبكة الهاتف المحمول، فسيعود إلى مسار مشغّل الشبكة.

هذا مهم لالتقاط لقطات الشاشة، ومراجعة لوحات المعلومات، وتشغيل اختبارات ضمان الجودة التي يحتاج فيها أحدهم لاحقًا إلى إعادة إنتاج الجلسة نفسها. يدعم Android سلوكيات أخرى للوكيل على الأجهزة المُدارة وإصدارات المطورين، لكن Chrome على الأجهزة الاستهلاكية يعتمد الإعداد على مستوى Wi-Fi. إذا كنت توثّق النتائج لعميل أو لمراجع داخلي، فسجّل إصدار نظام التشغيل وإصدار Chrome وبروتوكول الوكيل وعنوان IP الصادر الذي رُصد أثناء التشغيل.

عادة مفيدة: احرص دائمًا على تأكيد الجلسة في حالة الشبكة نفسها التي استخدمتها أثناء الاختبار. فالوكيل عبر Wi-Fi ومسار بيانات الهاتف المحمول طريقتان مختلفتان للعمل.

إذا كنت توحّد اختبارات ضمان الجودة على أجهزة محمولة متنوعة، فأبقِ دليل إعداد الوكيل هذا على Android في متناولك.

بالنسبة إلى الفرق التي تتحقق من تدفقات العمل على الأجهزة المحمولة، يعمل استخدام الوكيل عبر Wi-Fi على Android للاختبارات المنضبطة، لكن ينبغي أن يتوافق الإعداد مع حالة الاستخدام.

الوكيل في المتصفح مقابل وكيل النظام ومتى تستخدم كلًا منهما

يؤدي اختيار نطاق الوكيل غير المناسب إلى إخفاقات يمكن تجنبها. فالإعداد الذي يديره المتصفح أضيق نطاقًا، والإعداد الذي يديره النظام أوسع نطاقًا، وقد تتجاوز سياسة المؤسسة كليهما.

اختيار النطاق المناسب

يكون التحكم على مستوى المتصفح فقط مفيدًا عندما تحتاج إلى إبقاء الجهاز المضيف دون تغيير وعزل جلسة Chrome واحدة. يناسب ذلك اختبارات ضمان الجودة المؤقتة، أو عمليات التحقق البرمجية، أو المختبرات التي ينبغي فيها توجيه المتصفح وحده عبر وكيل. أما المفاضلة فهي واضحة: كل ما يقع خارج Chrome يواصل استخدام مسار شبكة الجهاز المضيف، لذا قد لا تتبع أدوات الدعم وأدوات الاختبار المحلية والتطبيقات الأخرى مسار المتصفح نفسه.

يُعد التحكم على مستوى النظام الخيار الافتراضي الأكثر أمانًا عندما تحتاج الأدوات الأخرى على الجهاز إلى مسار الخروج نفسه. كما أنه يقلل الاختلافات بين حركة مرور المتصفح وبقية تدفق العمل. أما بالنسبة إلى أساطيل الأجهزة، فالسؤال التشغيلي لا يتعلق بالسهولة بقدر ما يتعلق بالاتساق بين الأجهزة.

تأتي الإعدادات التي تديرها المؤسسة فوق ذلك بوصفها سياسة. فإذا نصّت السياسة المُدارة على شيء، بينما نصّ إعداد المستخدم المحلي على شيء آخر، تكون الغلبة للسياسة. وبهذه الطريقة يحافظ المسؤولون على قابلية التنبؤ بالبيئات المشتركة.

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

في الأعمال التي تعتمد على الموقع الجغرافي، يهم نوع الوكيل أيضًا. تعمل وكلاء الهاتف المحمول 4G عبر شبكات مشغّلي الاتصالات. وتُظهر الوكلاء السكنية عناوين مصدرها شبكات المنازل. أما وكلاء مراكز البيانات فتأتي من نطاقات سحابية أو نطاقات استضافة، ويسهل تصنيفها وحظرها لأن أرقام ASN الخاصة بها معروفة جيدًا. ويعني ASN مالك الشبكة التي تقف وراء نطاق IP، وتستخدمه الفرق لتقدير ما إذا كانت حركة المرور تبدو كاتصال استهلاكي أم حركة مرور بنية تحتية.

استكشاف الأخطاء وإصلاحها عندما يتجاهل Chrome وكيلك

قد يكون إعداد الوكيل صحيحًا ومع ذلك لا يعمل عمليًا. لا يتعامل Chrome مع كل طلب بالطريقة نفسها، وهنا تقع أخطاء كثيرة في الإعدادات. غالبًا ما يتم تجاوز الوجهات المحلية افتراضيًا، كما تخضع حركة مرور localhost أو حركة المرور عبر العنوان الراجع لمعالجة خاصة، ما لم توجّهها عمدًا عبر الوكيل باستخدام -loopback، كما هو موثّق في وثائق الوكيل في Chromium.

نفّذ التصحيح بالترتيب الذي يوفر الوقت

1. تأكد من أن Chrome يستخدم وضع النظام. إذا كانت إحدى خيارات بدء التشغيل أو إحدى الإضافات تتحكم في الوكيل، فلن يكون مربع حوار نظام التشغيل هو الإعداد الفعّال.
2. افحص إعدادات الوكيل في نظام التشغيل. تأكد من أن المتصفح ورث المسار الذي قصدته.
3. عطّل الإضافات المتعارضة. يمكن لإضافة وكيل للمتصفح أن تتجاوز مسار النظام أو تربكه.
4. اختبر مضيفًا ومنفذًا بسيطين. اختصر الإعداد حتى يعمل المسار الأساسي.
5. أضف المصادقة ومنطق التجاوز أخيرًا. تؤدي إضافة طبقات مبكرًا إلى صعوبة تحديد سبب الإخفاق.

قد تؤدي إخفاقات المصادقة المتكررة إلى إبقاء Chrome عالقًا في حالة وكيل معطوب مخزّنة مؤقتًا، لذا قد يكون مسح ذاكرة التخزين المؤقت جزءًا من استعادة العمل، كما ورد في وثائق الوكيل في Chromium. وقد يتسبب التعامل مع المخططات أيضًا في إرباك المستخدمين، خصوصًا عندما تكون الأعراض تحميل المواقع التي تستخدم HTTPS فقط، بينما تنتهي مهلة لوحات معلومات HTTP. ويكون ذلك عادةً نتيجة عدم تطابق في التوجيه، وليس دليلًا على أن الوكيل يعمل على نحو سليم من البداية إلى النهاية.

إذا ظل المتصفح يطلب بيانات الاعتماد، فتعامل مع الأمر أولًا باعتباره مشكلة في التوجيه أو حالة المصادقة، لا مشكلة في كلمة المرور.

يفيد دليل أخطاء الوكيل في Chrome هذا عندما يكون الإخفاق عبارة عن تكرار طلبات تسجيل الدخول، أو الرجوع الصامت إلى DIRECT، أو إعداد مُدار يستعيد قيمته السابقة بعد التعديلات المحلية.

بالنسبة إلى فرق عمليات الإعلانات واستخراج البيانات، يكمن الانضباط في التوثيق. سجّل نظام التشغيل وإصدار Chrome وبروتوكول الوكيل وطريقة المصادقة وقائمة التجاوز وعنوان IP الصادر الذي رُصد في كل عملية تشغيل. يوفّر ذلك سجل تدقيق واضحًا عندما ينجح تدفق العمل على جهاز ويفشل على الجهاز التالي.

التحقق من إعداداتك واختيار نوع الوكيل المناسب

التحقق هو ما يحوّل الوكيل من مجرد «إعداد مُدخل» إلى وكيل «صالح للاستخدام». وأسرع طريقة للتحقق بسيطة: تأكد من أن عنوان IP العام الذي تراه من داخل Chrome يطابق عنوان الخروج المتوقع، ثم تحقق من أن مسار حركة المرور ينتمي إلى فئة المصدر الصحيحة. ينبغي أن تبدو عناوين الخروج المعتمدة على شبكات المشغّلين كأنها من شبكات الهاتف المحمول، وأن تبدو عناوين الخروج السكنية كأنها من اتصالات استهلاكية، بينما ينبغي أن تبدو عناوين الخروج من مراكز البيانات كأنها من نطاقات البنية التحتية.

ما ينبغي التحقق منه قبل الوثوق بالجلسة

• تطابق عنوان IP الصادر. تحقق من أن عنوان IP الظاهر يطابق الموقع الجغرافي ونوع الوكيل اللذين قصدتهما.
• تصنيف المصدر. استخدم ASN وبيانات مشغّلي الاتصالات للتمييز بين نطاقات الهاتف المحمول والنطاقات السكنية ونطاقات مراكز البيانات.
• سلوك بيانات الاعتماد. انتبه إلى تكرار طلبات تسجيل الدخول، إذ يشير ذلك عادةً إلى حلقة مصادقة.
• الانحراف بعد التحديث. أعد الاختبار بعد تحديثات Chrome، لأن تحديث المتصفح قد يغيّر سلوك الوكيل أو الحالة المخزّنة مؤقتًا.
• توثيق الأدلة. احفظ لقطة شاشة أو ملاحظة اتصال لأغراض التدقيق عندما يكون تدفق العمل مهمًا للعملاء أو للمراجعين الداخليين.

في تدفقات العمل مثل إدارة حسابات متعددة على وسائل التواصل الاجتماعي، وأبحاث السوق، والتحقق من الإعلانات، وحماية العلامات التجارية، ومراقبة SEO، واختبارات ضمان الجودة التي تعتمد على الموقع الجغرافي، غالبًا ما يكون العامل الحاسم هو بصمة الاتصال، لا الاتصال وحده. تميل وكلاء الهاتف المحمول 4G إلى إظهار سلوك أقرب إلى سلوك المستخدمين العاديين، لأنها تعمل على شبكات مشغّلي الاتصالات ذات مجموعات العناوين المشتركة، ما يجعل تصنيفها أصعب من تصنيف نطاقات مراكز البيانات. ويمكن لمزوّد فرنسي لخدمات الهاتف المحمول مثل Evoproxy أن يلائم هذا النوع من تدفقات العمل عندما تحتاج إلى عناوين IP فرنسية للهاتف المحمول، والتحكم في التدوير، ومسار متصفح يتوافق مع المهمة بدلًا من أن يعيقها.

إذا كنت تتحقق من حملات موجّهة للجمهور الفرنسي أو مسارات إنشاء الحسابات أو اختبارات ضمان الجودة التي تتطلب نقطة خروج متنقلة واقعية، فاختبر إعدادًا للاتصال عبر شبكة 4G متنقلة باستخدام تسلسل المتصفح نفسه الذي تستخدمه في بيئة الإنتاج. سيمنحك ذلك صورة أوضح بكثير عمّا إذا كان البروكسي وتبديل عناوين IP وسلوك الجلسة ملائمة للغرض.

إذا كان فريقك يحتاج إلى جلسات Chrome تتصرف مثل مستخدمين حقيقيين للأجهزة المحمولة بدلًا من حركة المرور الواضحة القادمة من مراكز البيانات، فابدأ باختبار بروكسي 4G متنقل باستخدام سير العمل المحدد الذي يهمك. توفر Evoproxy اتصالًا متنقلًا في فرنسا مع توجيه ملائم للمتصفحات للتحقق المشروع من الإعلانات وضمان الجودة والبحث وتشغيل حسابات متعددة، ما يتيح لك التحقق من الإعداد قبل الالتزام به. تفضل بزيارة Evoproxy وتحقق مما إذا كان إعداد البروكسي المتنقل لديها يناسب سير عملك المعتمد على Chrome.