In this Article
العمل مع GitHub من داخل شبكة شركة هو عادة مشكلة إعدادات تتوزع على خمس أدوات لا تتشارك الإعدادات فيما بينها. قد ينجح استنساخ المستودع (clone) ويفشل npm install، أو ينجح npm ويعجز Docker عن السحب، أو يعمل كل شيء في سطر الأوامر بينما تعجز بيئة التطوير المتكاملة عن الوصول إلى أي شيء.
يوضح هذا الدليل أين تقرأ كل أداة إعدادات البروكسي الخاصة بها، ولماذا يتصرف SSH بشكل مختلف عن HTTPS، وكيفية قراءة أنواع الأخطاء الأربعة التي ستواجهها فعلا، والحلين المختصرين اللذين يستحقان الرفض.
الحقائق الأساسية
- لكل أداة إعدادات بروكسي خاصة بها. تقرأ Git وnpm وpip وDocker والصدفة (shell) جميعها إعدادات مختلفة، لذلك يؤدي إصلاح أداة واحدة إلى ترك البقية معطلة.
- يفشل SSH عادة حيث ينجح HTTPS، لأن معظم بروكسيات الشركات تمرر فقط طلبات HTTP CONNECT عبر المنافذ القياسية.
- تشير أخطاء الشهادات دائما تقريبا إلى فحص TLS، والحل هو الوثوق بمرجع الشهادات (CA) الخاص بالشركة بدلا من تعطيل التحقق.
- لا تعطل التحقق من الشهادة أبدا لجعل عملية الـ clone تعمل. فهذا يحول مشكلة إعدادات ظاهرة إلى مشكلة أمنية خفية.
- تتسرب بيانات الاعتماد الموضوعة داخل رابط URL الخاص بالبروكسي إلى السجلات وسجل أوامر الصدفة، لذا استخدم مخزن بيانات الاعتماد الخاص بالأداة بدلا من ذلك.
أين تقرأ كل أداة إعدادات البروكسي؟
كل أداة على حدة، وهذا هو أصل معظم الالتباس. نسمي هذا نموذج سلسلة الأدوات ذا الأجزاء الأربعة.
| الأداة | أين تبحث | الثغرة الشائعة |
|---|---|---|
| 1. Git | إعداداتها الخاصة، ثم متغيرات البيئة | تعمل الروابط البعيدة (remotes) عبر HTTPS بينما لا تعمل عبر SSH |
| 2. مديرو الحزم | ملفات الإعداد الخاصة بها، ثم متغيرات البيئة | تحتاج كل واحدة منها إلى إعداد منفصل؛ وقد تختلف السجلات (registries) عن GitHub |
| 3. Docker | إعدادات العملية الخلفية (daemon)، وليس الصدفة فقط | لا تصل متغيرات الصدفة إلى العملية الخلفية التي تسحب الصور |
| 4. بيئات التطوير المتكاملة (IDE) والمحررات | إعداداتها الخاصة، وأحيانا مخزن النظام | تعمل الطرفية (terminal) بينما لا تعمل الميزات المدمجة |
وبالتالي فإن إعداد بروكسي github العامل يعني خمسة إعدادات، لا إعدادا واحدا. الترتيب العملي هو ضبط متغيرات البيئة للصدفة أولا، ثم إعداد git، ثم كل مدير حزم على حدة، ثم العملية الخلفية لـ Docker، مع تضمين قائمة استثناء البروكسي (no-proxy) للمضيفين الداخليين منذ البداية. إغفال هذه الخطوة الأخيرة هو ما يجعل الخدمات الداخلية غير قابلة للوصول بعد إعداد ناجح في ظاهره.
لماذا يفشل SSH بينما ينجح HTTPS؟
لأنهما بروتوكولان مختلفان على منفذين مختلفين، ومعظم بروكسيات الشركات تمرر فقط طلبات HTTP CONNECT إلى مجموعة صغيرة من المنافذ.
يعد Git عبر HTTPS طلب ويب عاديا يتعامل معه البروكسي بشكل أصيل. أما Git عبر SSH فيستخدم المنفذ 22، وهو عادة غير مسموح به عبر البروكسي على الإطلاق. والنتيجة أن استنساخ المستودع ينجح عبر رابط بعيد HTTPS وينتهي بانتهاء المهلة (timeout) عبر رابط بعيد SSH، ونادرا ما توضح رسالة الخطأ السبب.
هناك ثلاثة حلول عملية، مرتبة حسب الأفضلية: تحويل الرابط البعيد إلى HTTPS باستخدام رمز token، أو استخدام SSH عبر منفذ HTTPS حيثما يدعم GitHub ذلك، أو مطالبة فريق الشبكة بالسماح بـ SSH إلى مضيفين محددين. الحل الأول يعمل في كل مكان وهو ما تستقر عليه معظم الفرق.
كيف تقرأ الأخطاء؟
| الخطأ | استخدم هذا الحل عندما | تجنب عندما |
|---|---|---|
| فشل التحقق من الشهادة | أضف مرجع الشهادات (CA) الخاص بالشركة إلى مخزن الثقة الخاص بالأداة | لا تعطل التحقق أبدا، فهذا يخفي خطرا حقيقيا |
| انتهت مهلة الاتصال على رابط بعيد SSH | حول إلى HTTPS أو SSH عبر منفذ HTTPS | إعادة المحاولة؛ فالمنفذ محظور لا بطيء |
| مطلوب مصادقة البروكسي | أعد بيانات الاعتماد في مخزن الأداة | وضعها داخل رابط URL، فهذا يتسرب إلى السجلات |
| يعمل في الطرفية، ويفشل في Docker | أعد إعداد العملية الخلفية لـ Docker، ثم أعد تشغيلها | إضافة المزيد من متغيرات الصدفة، فالعملية الخلفية لا تقرأها أبدا |
| تعذر الوصول إلى المضيفين الداخليين بعد الإعداد | أضفهم إلى قائمة استثناء البروكسي (no-proxy) | إزالة إعداد البروكسي بالكامل |
الصف الأول هو الذي يستحق التشدد بشأنه. يعني فحص TLS أن جهازا وسيطا (middlebox) ينهي اتصالاتك ويعيد توقيعها، والاستجابة الصحيحة هي الوثوق بمرجع الشهادات الخاص بالمؤسسة عن قصد. تعطيل التحقق يجعل الخطأ يختفي ويجعل كل اعتراض مستقبلي غير مرئي.
متى يكون البروكسي الخارجي هو الأداة المناسبة؟
نادرا ما يكون كذلك لهذه المشكلة، ومن المهم التوضيح بشأن ذلك.
بروكسي الشركة هو بنية تحتية تديرها مؤسستك، وحل مشكلة الوصول إلى GitHub خلفه هو الإعداد، لا بروكسي ثانٍ. تجاوز ضابط شبكة وضعه صاحب العمل عن قصد هو مسألة سياسات قبل أن يكون مسألة تقنية.
الموضع الذي ينطبق فيه البروكسي التجاري حقا هو عمل مختلف يصادف أنه يتضمن GitHub: جمع بيانات مستودعات عامة على نطاق واسع، أو التحقق من كيفية ظهور صفحة عامة من دولة أخرى، أو تشغيل فحوصات آلية من مناطق متعددة. بالنسبة لجمع بيانات المستودعات تحديدا، فإن GitHub API مع رمز token هو الإجابة الصحيحة أولا، وهو سخي بما يكفي لجعل التجريف (scraping) نادرا ما يكون مبررا.
عندما يحتاج الجمع بالفعل إلى مخارج (exits) موزعة، تغطي بروكسيات DataImpulse السكنية 195 دولة مقابل 1 دولار لكل GB. ذو صلة: بروكسيات تجريف الويب، شرح خطأ 403 Forbidden.
الأسئلة الشائعة
كيف أعد git لاستخدام بروكسي؟
اضبط البروكسي في إعدادات git الخاصة أو في متغيرات البيئة القياسية، وأضف المضيفين الداخليين إلى قائمة استثناء البروكسي (no-proxy) في الوقت نفسه. تقرأ Git إعداداتها الخاصة بشكل منفصل عن npm وpip وDocker، لذا تحتاج كل أداة إلى إعداد فردي.
لماذا يفشل git clone عبر SSH خلف بروكسي؟
لأن SSH يستخدم المنفذ 22 ومعظم بروكسيات الشركات تمرر فقط طلبات HTTP CONNECT إلى منافذ الويب القياسية. تعمل الروابط البعيدة عبر HTTPS لأنها طلبات ويب عادية. تحويل الرابط البعيد إلى HTTPS باستخدام رمز token هو الحل الذي يعمل في أكبر عدد من البيئات.
ما الذي يسبب أخطاء الشهادات خلف بروكسي الشركة؟
فحص TLS: يقوم جهاز وسيط (middlebox) بإنهاء اتصالاتك وإعادة توقيعها بمرجع الشهادات الخاص بالمؤسسة. الحل هو إضافة مرجع الشهادات هذا إلى مخزن الثقة الخاص بكل أداة. تعطيل التحقق من الشهادة يزيل الخطأ ويزيل قدرتك على اكتشاف الاعتراض الحقيقي.
لماذا يفشل Docker بينما تعمل الطرفية لدي؟
لأن العملية الخلفية لـ Docker هي التي تسحب الصور، لا الصدفة الخاصة بك، وهي تقرأ إعداداتها الخاصة بدلا من متغيرات البيئة لديك. أعد إعداد بروكسي العملية الخلفية وأعد تشغيلها.
هل يجب أن أستخدم بروكسي تجاريا للوصول إلى GitHub في العمل؟
لا. بروكسي الشركة بنية تحتية تديرها مؤسستك عن قصد، والحل هو الإعداد. تنطبق البروكسيات التجارية على أعمال مختلفة، مثل جمع بيانات عامة من مناطق عديدة، وحتى هناك يكون GitHub API مع رمز token عادة هو الطريق الأفضل.
عندما يكون العمل هو الجمع، لا الاتصال
التحقق من كيفية ظهور الصفحات العامة من مناطق أخرى، أو جمع بيانات عامة على نطاق واسع، هو مشكلة مختلفة عن إعداد شبكة الشركة. تغطي بروكسيات DataImpulse السكنية 195 دولة مقابل 1 دولار لكل GB. أنشئ حسابا عندما تكون هذه هي المهمة.
ذو صلة: بروكسيات تجريف الويب · خطأ 403 Forbidden عند التجريف · ما هو بروكسي الويب.
آخر تحديث: 17 سبتمبر 2026.