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

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

يبدأ إعداد وكيل موثوق في Chrome بـالنطاق والأولوية، وينتهي بالتحقق من النتائج. اختر أضيق إعداد يلائم المهمة، وحدّد الشبكة التي تقف خلف عنوان الوكيل، وتحقّق من IP العام وسلوك DNS بدلاً من الاعتماد على شاشة الإعدادات.

ما طريقة الوكيل في Chrome الأنسب لمهمتك؟

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

الوكيل خادم وسيط يمرّر الطلبات. عندما يتلقى موقع إلكتروني طلباً عبره، يرى الموقع عموماً عنوان IP العام للوكيل بدلاً من العنوان العام لاتصالك.

مقارنة طرق استخدام الوكيل في Chrome

يُعد وكيل النظام خياراً ملائماً عندما يُراد من Windows أو macOS تزويد Chrome بإعدادات التوجيه. أما خيار التشغيل فهو أفضل للاختبار المؤقت، لأنه يحدد الإعداد المقصود بوضوح عند بدء التشغيل.

يتيح ملف PAC اتخاذ قرارات مشروطة من دون التبديل اليدوي. وتسهّل إضافة الإدارة التبديل حسب الملف الشخصي، بينما تمنح سياسة المؤسسة قسم تقنية المعلومات تحكماً مركزياً مفروضاً.

حدّد النطاق قبل اختيار الأسهل

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

أما مهندس بيانات يختبر صفحة أسعار تعتمد على الموقع الجغرافي باستخدام برنامج نصي، فسيستخدم خيار تشغيل مع مجلد منفصل لبيانات المستخدم. وبذلك تبقى بيئة الاختبار منفصلة عن التصفح اليومي.

قاعدة عملية: اختر أضيق نطاق يفي بالغرض. فقد يؤثر التغيير على مستوى النظام في كل تطبيق آخر يتبع إعدادات الوكيل في نظام التشغيل.

ما نوع الوكيل الذي يغيّر نتائجك؟

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

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

أنواع الوكلاء وما تدل عليه

افهم الجلسة إلى جانب العنوان

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

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

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

يجب أيضاً أن يتوافق بروتوكول الاتصال مع الأداة. تتعامل وكلاء HTTP مع طلبات الوكيل للويب؛ أما وكيل SOCKS5 فيمرّر نطاقاً أوسع من أنواع الاتصالات. تحقّق من البروتوكول الذي يدعمه تطبيقك قبل اختيار نقطة نهاية الوكيل.

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

كيفية إعداد وكيل في إعدادات النظام أو عبر خيارات التشغيل

استخدم إعدادات نظام التشغيل لإجراء تغيير على مستوى الجهاز. واستخدم خيارات التشغيل عندما تحتاج إلى جلسة متصفح صريحة ومعزولة للاختبار.

إعداد وكيل نظام التشغيل

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

قد تختلف تسميات القوائم بين إصدارات أنظمة التشغيل. والتمييز المهم هو بين نقطة نهاية تُدخل يدوياً وبرنامج نصي للإعداد التلقائي.

بدء جلسة معزولة في Chrome

1. أغلق Chrome بالكامل. أغلق كل النوافذ وتحقق من العمليات التي تعمل في الخلفية. فقد تقبل عملية متصفح موجودة طلب التشغيل من دون تطبيق العلامات الجديدة.
2. جهّز إدخال التشغيل. عدّل اختصارًا للملف التنفيذي لـ Chrome، أو استخدم الطرفية على macOS أو Linux.
3. حدّد البروكسي. أضف --proxy-server="socks5://myproxy:8080" لاستخدام SOCKS5، مع استبدالها بنقطة الاتصال الفعلية. وبالنسبة إلى بروكسي HTTP، استخدم مخطط HTTP واسم المضيف والمنفذ الخاص به.
4. حدّد الاستثناءات بعناية. أضف --proxy-bypass-list للوجهات التي ينبغي أن تتصل مباشرة، مثل خدمات التطوير المحلية أو النطاقات الداخلية المعتمدة.
5. افصل بيانات المتصفح. أضف --user-data-dir للإشارة إلى مجلد اختبار مخصص، ثم شغّل Chrome وتحقق من المسار.

توثّق وثائق بروكسي Chromium المثال الوارد أعلاه لـ SOCKS5 بوصفه توجيهًا لطلبات URL من نوع HTTP وHTTPS عبر البروكسي على المنفذ 8080. ينقل SOCKS5 الاتصالات من دون تفسير محتوى الويب الخاص بالتطبيق؛ ولا يضمن التشفير بحد ذاته.

يتطلب DNS، وهو النظام الذي يترجم أسماء المضيفين إلى عناوين، تحققًا مستقلًا. فطلب ويب موجّه عبر بروكسي لا يكفي لإثبات أن كل عمليات البحث عن العناوين تمت عن بُعد، لذا لا تعتبر تغيّر IP العام تحققًا كاملًا.

كيفية توجيه حركة المرور بشكل مشروط باستخدام نص PAC

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

يحتوي النص على دالة JavaScript باسم FindProxyForURL. والدالة التوضيحية البسيطة هي function FindProxyForURL(url, host) { if (host === "shop.example.com") return "PROXY proxy.example.net:8080"; return "DIRECT"; }.

يوجّه هذا المثال اسم المضيف المحدد عبر بروكسي، ويُرجع DIRECT، أي من دون بروكسي، للوجهات الأخرى. الأسماء هنا عناصر نائبة وليست إعدادًا لخدمة جاهزة للعمل.

انشر قواعد يسهل فحصها

1. طابق أسماء المضيفين بعناية. استخدم قيمة المضيف لمطابقة الوجهة بدلًا من افتراض أن اسم المضيف وعنوانه بعد حلّه قابلان للتبادل. أدرج المضيفين الداعمين المطلوبين، لا اسم المضيف الرئيسي للصفحة فحسب.
2. انشر الملف على نحو موثوق. استضفه على خادم داخلي أو في موقع HTTPS مستقر يمكن لأجهزة الاختبار الوصول إليه.
3. اختر التهيئة التلقائية. في Windows، استخدم خيار «استخدام نص الإعداد» ضمن بروكسي النظام. وفي macOS، اختر خيار التهيئة التلقائية للبروكسي.
4. اختر سياسة للتعامل مع التعطل. يتيح ترتيب الإرجاع مثل PROXY proxy.example.net:8080; DIRECT الاتصال المباشر احتياطيًا إذا تعذر الوصول إلى البروكسي. استخدمه فقط عندما يكون الاتصال المباشر مقبولًا؛ وإلا فقد يُبطل اختبارًا إقليميًا.
5. أعِد التحميل وافحص. حدّث التهيئة بعد التعديلات، ثم اختبر مضيفًا يُوجّه عمدًا عبر البروكسي وآخر يُوجّه عمدًا مباشرة.

يُعد WPAD، أو الاكتشاف التلقائي لبروكسي الويب، بديلًا يكتشف التهيئة عبر DHCP أو DNS عند تمكين الاكتشاف التلقائي. وعند المفاضلة بين الاكتشاف وعنوان URL محدد لنص، تكتسب هذه التفرقة أهمية عند مراجعة إعداد البروكسي التلقائي.

تميّز وثائق Chrome Proxy API بين pac_script، الذي يستخدم نصًا أو بيانات PAC مضمنة، وfixed_servers، الذي يطبّق قواعد بروكسي صريحة. كما تعرّف وضعي system وdirect.

الرجوع إلى الاتصال المباشر قرار متعلق بالتوافر، وليس خيارًا افتراضيًا محايدًا. لا تدرجه في اختبار يتطلب استخدام البروكسي الإقليمي لكل طلب مطابق.

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

كيفية إدارة عدة بروكسيات باستخدام الإضافات

تسهّل إضافة لإدارة البروكسي تشغيل التوجيه في Chrome لسطح المكتب حسب الملف الشخصي. والمهم هو التمييز بين تهيئة بروكسي محفوظة داخل إضافة وملف شخصي في Chrome، وهو ما يحتفظ بحساب المتصفح وحالة التصفح.

اجعل تعيين الحسابات والمسارات واضحًا

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

عالج تعارضات التحكم قبل تغيير نقاط الاتصال

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

توفّر الإضافة التي تستدعي chrome.proxy كائن ProxyConfig، ويجب أن يعلن ملف البيان الخاص بها عن إذن البروكسي. وفي Chrome لسطح المكتب غير المُدار، يمكن لإضافة نشطة تتحكم في البروكسي أن تتجاوز إعدادات نظام التشغيل.

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

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

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

كيفية اختبار مسار البروكسي خطوة بخطوة

تهيئة البروكسي لا تثبت أن المسار يعمل. تحتاج إلى ملاحظات من جلسة المتصفح التي ستُستخدم في العمل، لا إلى مجرد رسالة اتصال ناجح من مدير البروكسي.

اجمع أدلة من جلسة خاضعة للتحكم

1. افحص الإعداد الفعلي. جرّب chrome://net-internals/#proxy حيثما كان ذلك متاحًا. إذا لم يعد إصدار Chrome لديك يعرض تفاصيل مفيدة هناك، فالتقط سجلًا لشبكة المتصفح وافحص كيفية تحديد الوكيل إلى جانب الإضافة النشطة أو السياسة.
2. تحقق من HTTPS وعنوان IP العام. افتح نقطة نهاية HTTPS معتمدة تعرض العنوان الذي يرسل الطلب. سجّل ما ترصده بدلًا من الاعتماد على اسم المضيف المُعدّ للوكيل.
3. اختبر الاستثناءات. اختبر اسم مضيف مستثنى واسم مضيف يُفترض توجيهه عبر الوكيل. سجّل ما إذا كان كل منهما يستخدم DIRECT أم الوكيل.
4. قارن سلوك DNS. استخدم اسم المضيف نفسه في المسار العادي والمسار عبر الوكيل. اختلاف الإجابات وحده لا يثبت وجود تسرّب؛ فقد تُرجع محللات DNS الإقليمية إجابات مختلفة بصورة مشروعة. افحص الموقع الذي تتم فيه عملية التحليل.
5. اختبر المصادقة. تحقّق من مصادقة الوكيل على نحو منفصل عن صفحة تطبيق تتطلب تسجيل الدخول. فقد تنتج المطالبات المتكررة عن أنظمة بيانات اعتماد مختلفة.
6. اختبر التعامل مع الأعطال. عطّل المسار الأساسي في بيئة مضبوطة، وتحقق مما إذا كان المسار الاحتياطي المُعدّ يعمل، بما في ذلك التحقق من إمكانية الوصول المباشر.

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

نتائج الاختبار وما تعنيه عادةً

استخدم اختبار اكتشاف الوكيل كدليل تكميلي، لا كمعيار القبول الوحيد. لرحلات العملاء عبر الأجهزة المحمولة، اجمع بين فحوصات توجيه المتصفح وإرشادات الاختبار على أجهزة حقيقية لفرق الإصدار من 99tests، لأن اختبار الوكيل على جهاز مكتبي لا يحاكي بيئة هاتف كاملة.

تعامل مع تغييرات المسار غير المفسرة على أنها عيب في الإعداد يستدعي التحقيق. احتفظ بالسجل إلى جانب الإعداد كي يتسنى مقارنة التعديلات اللاحقة بخط أساس معروف بسلامته.

تحقق من مسارك وانتقل إلى الخطوة التالية

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

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

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

لا يكون الوكيل موثوقًا إلا بقدر موثوقية آخر مسار جرى التحقق منه.

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