العودة إلى المدونة

بروكسي لـ GitHub و npm: كيفية الوصول إلى المستودعات والحزم من الدول التي تم حظر GitHub فيها أو تعمل ببطء

إذا كان GitHub محجوبًا أو يعمل ببطء - فإن البروكسي يحل المشكلة في 10 دقائق. نشرح كيفية إعداد الوصول إلى المستودعات وحزم npm بدون VPN.

📅١٦ شوال ١٤٤٧ هـ
```html

تم حجب GitHub، أو يعمل بتأخير من 10 إلى 30 ثانية، أو تتوقف عملية npm install في منتصف الطريق - هذه حالة مألوفة للمطورين من روسيا وإيران والصين وعدد من الدول الأخرى. هناك حل، وهو أسهل مما يبدو: البروكسي المُعد بشكل صحيح يوفر وصولاً ثابتًا إلى المستودعات والحزم وواجهة برمجة التطبيقات لـ GitHub بدون VPN وبدون الحاجة إلى خطوات إضافية.

لماذا يتم حجب GitHub و npm أو إبطاءهما

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

حجب كامل على مستوى الدولة

عدد من الدول - الصين وإيران وكوريا الشمالية، ومنذ عام 2022 روسيا بشكل دوري - تحجب GitHub على مستوى DNS أو عبر IP. هذا يعني أن الطلبات إلى github.com إما لا تمر على الإطلاق، أو تعيد خطأ في الاتصال. يمكن أن يعمل سجل npm (registry.npmjs.org) بشكل طبيعي - أو يكون محجوبًا أيضًا.

جدران الحماية المؤسسية وقيود الشبكة

حتى بدون حجب حكومي، غالبًا ما تقيد الشبكات المؤسسية الوصول إلى المستودعات الخارجية. هذه ممارسة قياسية في البنوك والهيئات الحكومية والشركات الكبرى: يقوم قسم تكنولوجيا المعلومات بإغلاق الاتصالات الصادرة على المنافذ 443 أو يحجب مجالات معينة. لا يمكن للمطور في شبكة كهذه إجراء git clone أو npm install بدون مسار بديل.

سرعة بطيئة بسبب الجغرافيا

تقنيًا، GitHub متاح، ولكن استنساخ مستودع بحجم 500 ميغابايت يستغرق 40 دقيقة، وتثبيت الاعتماديات عبر npm - يستغرق وقتًا طويلاً. هذه مشكلة توجيه: الحزم تمر عبر نقاط مزدحمة أو مسارات طويلة. يقلل خادم البروكسي الموجود في الولايات المتحدة أو أوروبا من المسافة ويعطي زيادة حقيقية في السرعة من 3 إلى 10 مرات.

من المهم أن نفهم:

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

بروكسي مقابل VPN: ماذا تختار للعمل مع الكود

العديد من المطورين يميلون بشكل طبيعي إلى استخدام VPN. هذا مفهوم - VPN سهل الإعداد ويعمل على الفور لكل النظام. لكن للعمل مع GitHub و npm، غالبًا ما يكون البروكسي أكثر ملاءمة. دعونا نوضح الفرق.

المعيار بروكسي VPN
نطاق الحركة تطبيق معين فقط (Git و npm) كل حركة النظام
الإعداد في CI/CD من خلال متغيرات البيئة، بسيطة تتطلب تثبيت عميل، صعبة
العمل في Docker يتم تمريره عبر ENV، بدون مشاكل تتطلب وضعًا مميزًا
السرعة عالية (لا يوجد تشفير لكل الحركة) أقل بسبب التشفير
الصراعات مع الشبكة المؤسسية حد أدنى متكررة (تحجبها قسم تكنولوجيا المعلومات)
الاستخدام على الخادم محليًا عبر متغيرات env تتطلب تثبيت خادم

الاستنتاج بسيط: إذا كانت مهمتك هي منح الفريق الوصول إلى GitHub و npm، يتم إعداد البروكسي مرة واحدة في التكوين ويعمل بدون تدخل في إعدادات النظام لكل جهاز. هذا مهم بشكل خاص لخطوط أنابيب CI/CD، حيث من الصعب فعليًا إعداد VPN.

ما هو نوع البروكسي المناسب لـ GitHub و npm

ليست كل البروكسيات تعمل بشكل جيد مع Git و npm. يعتمد الاختيار على مهمتك: تجاوز الحجب، تسريع التحميل، أو العمل من شبكة مؤسسية.

بروكسي HTTP/HTTPS

الخيار الأكثر بساطة. يدعم Git و npm بروكسي HTTP بشكل محلي من خلال متغيرات البيئة القياسية. مناسب لمعظم المهام: استنساخ المستودعات، تثبيت الحزم، العمل مع واجهة برمجة التطبيقات لـ GitHub. إذا كان مزود البروكسي الخاص بك يوفر عنوان HTTP - ابدأ به.

بروكسي SOCKS5

بروتوكول أكثر مرونة، يعمل على مستوى TCP. يدعم أي نوع من الحركة، بما في ذلك اتصالات SSH مع GitHub (المنفذ 22). إذا كنت تستخدم Git عبر SSH، وليس HTTPS - فإن SOCKS5 هو الخيار المفضل. يدعم Git SOCKS5 من خلال المعلمة socks5:// في التكوين.

بروكسي سكنية

البروكسي السكنية تستخدم عناوين IP لمستخدمين حقيقيين. هذا مهم بشكل خاص لـ GitHub إذا كنت تعمل من دولة بها حجب صارم: هذه العناوين نادرًا ما تُدرج في القوائم السوداء وتبدو كحركة مستخدم عادية. مناسبة للحالات التي تم حجب عناوين IP الخاصة بمراكز البيانات على مستوى المزود.

بروكسي مراكز البيانات

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

نوع البروكسي السرعة تجاوز الحجب أفضل ما يناسب
بروكسي HTTP لمراكز البيانات ⭐⭐⭐⭐⭐ متوسط تسريع التحميل، npm install
بروكسي SOCKS5 لمراكز البيانات ⭐⭐⭐⭐⭐ متوسط Git عبر SSH، إعداد مرن
سكنية ⭐⭐⭐ مرتفع حجب صارم (إيران، الصين)
محمول ⭐⭐⭐ مرتفع جدًا تجاوز أقصى، حالات نادرة

إعداد البروكسي لـ Git: تعليمات خطوة بخطوة

يدعم Git البروكسي من خلال التكوين المدمج ومن خلال متغيرات البيئة. سنوضح كلا الطريقتين - اختر ما هو أكثر ملاءمة لعملية عملك.

الطريقة 1: عبر git config (موصى بها)

هذا إعداد دائم ينطبق على جميع عمليات Git على الجهاز. افتح الطرفية وقم بتنفيذ:

# لبروكسي HTTP/HTTPS
git config --global http.proxy http://username:password@proxy-host:port
git config --global https.proxy http://username:password@proxy-host:port

# لبروكسي SOCKS5
git config --global http.proxy socks5://username:password@proxy-host:port
git config --global https.proxy socks5://username:password@proxy-host:port

# تحقق من أن الإعدادات تم تطبيقها
git config --global --list | grep proxy

استبدل username:password@proxy-host:port ببيانات البروكسي الخاصة بك. إذا كان البروكسي بدون مصادقة - قم بإزالة username:password@.

الطريقة 2: عبر متغيرات البيئة

مريحة للاستخدام المؤقت أو في السكربتات. يقوم Git تلقائيًا بالتقاط المتغيرات القياسية HTTP_PROXY و HTTPS_PROXY:

# Linux / macOS - أضف إلى ~/.bashrc أو ~/.zshrc
export HTTP_PROXY="http://username:password@proxy-host:port"
export HTTPS_PROXY="http://username:password@proxy-host:port"
export NO_PROXY="localhost,127.0.0.1,::1"

# Windows (PowerShell)
$env:HTTP_PROXY="http://username:password@proxy-host:port"
$env:HTTPS_PROXY="http://username:password@proxy-host:port"

# تطبيق بدون إعادة تشغيل الطرفية (Linux/macOS)
source ~/.bashrc

إعداد البروكسي فقط لـ GitHub

إذا كنت ترغب في توجيه الطلبات عبر البروكسي فقط إلى GitHub، وليس إلى جميع المستودعات، استخدم إعداد القسم:

# بروكسي فقط لـ github.com
git config --global http.https://github.com.proxy http://username:password@proxy-host:port

# تحقق من الاستنساخ عبر البروكسي
git clone https://github.com/username/repo.git

Git عبر SSH عبر SOCKS5

إذا كنت تعمل مع GitHub عبر SSH (وليس HTTPS)، فإن الإعداد مختلف قليلاً. تحتاج إلى تعديل ملف ~/.ssh/config:

# ~/.ssh/config

Host github.com
    HostName github.com
    User git
    # على Linux/macOS استخدم nc (netcat)
    ProxyCommand nc -X 5 -x proxy-host:port %h %p
    
    # أو عبر connect-proxy (يجب تثبيته)
    # ProxyCommand connect -S proxy-host:port %h %p
    
    # على Windows عبر Git Bash
    # ProxyCommand connect -S proxy-host:port %h %p

بعد ذلك، ستذهب الأوامر git clone [email protected]:user/repo.git و git push تلقائيًا عبر بروكسي SOCKS5.

كيفية إعادة تعيين إعدادات البروكسي

# إزالة البروكسي من التكوين العالمي
git config --global --unset http.proxy
git config --global --unset https.proxy

إعداد البروكسي لـ npm و yarn و pnpm

كل مدير حزم له طريقة خاصة لإعداد البروكسي. دعونا نوضح الثلاثة - npm و yarn و pnpm - مع الأوامر المحددة.

npm

يدعم npm البروكسي من خلال إعدادات التكوين المدمجة:

# إعداد البروكسي لـ npm
npm config set proxy http://username:password@proxy-host:port
npm config set https-proxy http://username:password@proxy-host:port

# تحقق من الإعدادات
npm config get proxy
npm config get https-proxy

# اختبار: تثبيت حزمة عبر البروكسي
npm install lodash

# إعادة تعيين البروكسي
npm config delete proxy
npm config delete https-proxy

يتم حفظ الإعدادات في ملف ~/.npmrc. يمكنك تحريره مباشرة:

# ~/.npmrc
proxy=http://username:password@proxy-host:port
https-proxy=http://username:password@proxy-host:port
strict-ssl=false

المعلمة strict-ssl=false

إذا كان البروكسي يعترض حركة SSL (على سبيل المثال، البروكسي المؤسسي)، قد يشتكي npm من الشهادة. تعطل المعلمة strict-ssl=false التحقق. استخدمها فقط في الشبكة المؤسسية حيث تثق بالبروكسي - في الشبكات العامة، هذا غير آمن.

Yarn (v1 Classic)

# Yarn Classic (v1)
yarn config set proxy http://username:password@proxy-host:port
yarn config set https-proxy http://username:password@proxy-host:port

# تحقق
yarn config get proxy

# إعادة تعيين
yarn config delete proxy
yarn config delete https-proxy

Yarn Berry (v2+)

# يستخدم Yarn Berry متغيرات البيئة
# أضف إلى .yarnrc.yml في جذر المشروع:
httpProxy: "http://username:password@proxy-host:port"
httpsProxy: "http://username:password@proxy-host:port"

# أو عبر متغيرات البيئة
export HTTP_PROXY="http://username:password@proxy-host:port"
export HTTPS_PROXY="http://username:password@proxy-host:port"

pnpm

# يستخدم pnpm نفس .npmrc مثل npm
# يتم تطبيق الإعدادات تلقائيًا إذا تم إعداد npm بالفعل

# أو بوضوح عبر pnpm config
pnpm config set proxy http://username:password@proxy-host:port
pnpm config set https-proxy http://username:password@proxy-host:port

بديل: مرايا سجل npm

إذا كان سجل npm بطيئًا، ولكن GitHub متاح - يمكنك التبديل إلى مرآة. الخيارات الشائعة: Taobao (لـ الصين)، Verdaccio (مستضاف ذاتيًا). لكن المرايا غالبًا ما تتأخر في إصدارات الحزم، لذا فإن البروكسي أكثر موثوقية:

# تحويل السجل إلى مرآة (فقط للتسريع، وليس للحجب)
npm config set registry https://registry.npmmirror.com

# استعادة السجل الرسمي
npm config set registry https://registry.npmjs.org

البروكسي في CI/CD: GitHub Actions و Docker و Jenkins

إعداد البروكسي على الجهاز المحلي هو نصف المهمة. تبدأ المعاناة الحقيقية عندما تحتاج إلى ضمان الوصول إلى GitHub و npm في خط أنابيب CI/CD يعمل في شبكة معزولة. دعونا نوضح ثلاث سيناريوهات شائعة.

GitHub Actions

في GitHub Actions، يتم إعداد البروكسي عبر متغيرات البيئة في ملف العمل. أضف الأسرار في إعدادات المستودع (الإعدادات → الأسرار)، ثم استخدمها في ملف العمل:

# .github/workflows/build.yml
name: Build

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    
    env:
      HTTP_PROXY: ${{ secrets.PROXY_URL }}
      HTTPS_PROXY: ${{ secrets.PROXY_URL }}
      NO_PROXY: "localhost,127.0.0.1"
    
    steps:
      - uses: actions/checkout@v3
      
      - name: إعداد Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: تكوين بروكسي npm
        run: |
          npm config set proxy ${{ secrets.PROXY_URL }}
          npm config set https-proxy ${{ secrets.PROXY_URL }}
      
      - name: تثبيت الاعتماديات
        run: npm ci

Docker

في Docker، يحتاج البروكسي على مستويين: عند بناء الصورة (في docker build) وداخل الحاوية. هذه إعدادات مختلفة:

# تمرير البروكسي عند البناء عبر --build-arg
docker build \
  --build-arg HTTP_PROXY=http://user:pass@proxy-host:port \
  --build-arg HTTPS_PROXY=http://user:pass@proxy-host:port \
  -t myapp .

# في Dockerfile استخدم ARG للبروكسي
# Dockerfile
ARG HTTP_PROXY
ARG HTTPS_PROXY
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY

RUN npm ci

# بعد تثبيت الاعتماديات - إعادة تعيين البروكسي (لا تحتفظ به في الصورة!)
ENV HTTP_PROXY=""
ENV HTTPS_PROXY=""

إعداد البروكسي العالمي لخادم Docker (لـ docker pull):

# /etc/docker/daemon.json
{
  "proxies": {
    "http-proxy": "http://user:pass@proxy-host:port",
    "https-proxy": "http://user:pass@proxy-host:port",
    "no-proxy": "localhost,127.0.0.1"
  }
}

# أعد تشغيل Docker بعد التغييرات
sudo systemctl restart docker

Jenkins

في Jenkins، يتم إعداد البروكسي على مستوى العميل عبر متغيرات البيئة في Jenkinsfile أو بشكل عالمي في إعدادات النظام:

// Jenkinsfile
pipeline {
    agent any
    
    environment {
        HTTP_PROXY  = credentials('proxy-url')
        HTTPS_PROXY = credentials('proxy-url')
        NO_PROXY    = 'localhost,127.0.0.1'
    }
    
    stages {
        stage('تثبيت') {
            steps {
                sh 'npm config set proxy $HTTP_PROXY'
                sh 'npm config set https-proxy $HTTPS_PROXY'
                sh 'npm ci'
            }
        }
        stage('بناء') {
            steps {
                sh 'npm run build'
            }
        }
    }
}

الأخطاء الشائعة وكيفية إصلاحها

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

خطأ: ECONNREFUSED أو Connection refused

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

الحل: تحقق من توفر البروكسي باستخدام الأمر:

curl -v --proxy http://user:pass@proxy-host:port https://github.com

خطأ: مشكلة في شهادة SSL / UNABLE_TO_VERIFY_LEAF_SIGNATURE

البروكسي يعترض حركة SSL ويضع شهادته الخاصة، التي لا يثق بها Git أو npm.

الحل لـ Git:

git config --global http.sslVerify false
# أو إضافة الشهادة الجذرية للبروكسي:
git config --global http.sslCAInfo /path/to/proxy-ca.crt

خطأ: npm ERR! code ENOTFOUND

لا يمكن لـ npm حل اسم DNS للسجل. تم إعداد البروكسي، لكن طلبات DNS لا تمر عبره.

الحل: استخدم SOCKS5 بدلاً من بروكسي HTTP - فإنه ينقل طلبات DNS:

npm config set proxy socks5://user:pass@proxy-host:port
npm config set https-proxy socks5://user:pass@proxy-host:port

خطأ: 407 Proxy Authentication Required

يتطلب البروكسي مصادقة، لكن بيانات الاعتماد لم تُرسل أو أُرسلت بشكل غير صحيح.

# تأكد من أن اسم المستخدم وكلمة المرور في URL مشفرة بشكل صحيح
# إذا كانت هناك رموز خاصة في كلمة المرور (@، :، #) - قم بتشفيرها:
# @ → %40، : → %3A، # → %23

# مثال: كلمة المرور "p@ss:word" → "p%40ss%3Aword"
npm config set proxy http://user:p%40ss%3Aword@proxy-host:port

يعمل git clone، لكن git push لا يعمل

قد تستخدم عملية الاستنساخ (القراءة) وpush (الكتابة) بروتوكولات مختلفة. تأكد من أن البروكسي مُعد لكل من HTTP و HTTPS. إذا كنت تستخدم SSH لـ push - تحتاج إلى إعداد منفصل في ~/.ssh/config كما هو موضح أعلاه.

قائمة التحقق: التأكد من أن كل شيء يعمل

بعد إعداد البروكسي، تحقق من هذه القائمة للتأكد من أن كل شيء يعمل بشكل صحيح.

✅ قائمة التحقق لإعداد البروكسي لـ GitHub و npm

  • البروكسي متاح: curl -v --proxy PROXY_URL https://github.com يعيد 200
  • تم إعداد Git config: git config --global --list | grep proxy يظهر بروكسي الخاص بك
  • اختبار الاستنساخ: git clone https://github.com/torvalds/linux.git --depth=1 يعمل
  • تم إعداد بروكسي npm: npm config get proxy يظهر بروكسي الخاص بك
  • اختبار npm install: npm install lodash يكتمل بنجاح
  • إذا كنت تستخدم SSH: ssh -T [email protected] يعيد تحية
  • CI/CD: تمت إضافة متغيرات البيئة إلى الأسرار، يمر خط الأنابيب
  • Docker: docker build مع --build-arg يكتمل بدون أخطاء في الشبكة
  • السرعة: الاستنساخ أسرع بشكل ملحوظ من دون البروكسي
  • بيانات اعتماد البروكسي لا تُخزن بشكل واضح في الكود (فقط في الأسرار)

تشخيص سريع بأمر واحد

إذا كان هناك شيء لا يعمل ولم يكن من الواضح أين المشكلة - قم بتشغيل هذا السكربت للتشخيص:

#!/bin/bash
# تشخيص البروكسي لـ GitHub/npm

PROXY="http://user:pass@proxy-host:port"

echo "=== 1. الوصول المباشر إلى GitHub ==="
curl -s -o /dev/null -w "%{http_code}" https://github.com && echo " OK" || echo " FAIL"

echo "=== 2. الوصول عبر البروكسي ==="
curl -s -o /dev/null -w "%{http_code}" --proxy "$PROXY" https://github.com && echo " OK" || echo " FAIL"

echo "=== 3. الوصول إلى سجل npm عبر البروكسي ==="
curl -s -o /dev/null -w "%{http_code}" --proxy "$PROXY" https://registry.npmjs.org && echo " OK" || echo " FAIL"

echo "=== 4. الإعدادات الحالية لبروكسي Git ==="
git config --global --list | grep proxy || echo "بروكسي Git غير مُعد"

echo "=== 5. الإعدادات الحالية لبروكسي npm ==="
npm config get proxy
npm config get https-proxy

الخاتمة

إعداد البروكسي لـ GitHub و npm ليست مهمة صعبة إذا كنت تعرف الترتيب الصحيح للإجراءات. دعونا نلخص:

  • لتسريع GitHub البطيء - تناسب بروكسي مراكز البيانات في الولايات المتحدة أو أوروبا: فهي سريعة وثابتة وغير مكلفة.
  • لتجاوز الحجب - البروكسي السكنية مع عناوين IP لمستخدمين حقيقيين توفر أقصى موثوقية.
  • لـ Git عبر HTTPS - قم بإعداد http.proxy في تكوين git.
  • لـ Git عبر SSH - استخدم ProxyCommand في ~/.ssh/config.
  • لـ npm/yarn/pnpm - قم بإعداد البروكسي عبر التكوين أو متغيرات البيئة.
  • لـ CI/CD - مرر بيانات البروكسي عبر الأسرار، لا تكتبها في الكود.

بعد قضاء 10-15 دقيقة في الإعداد مرة واحدة، ستحصل على وصول ثابت إلى GitHub و npm دون الاعتماد على حالة قناة الإنترنت أو سياسة الحجب. يتوقف الفريق عن إضاعة الوقت في انتظار التحميلات البطيئة، وتنجح خطوط أنابيب CI/CD بدون أخطاء في الشبكة، ويعمل المطورون في دول مختلفة في ظروف متساوية.

إذا كنت تبحث عن بروكسي ثابت للعمل مع GitHub و npm من دول ذات وصول محدود، نوصي بالنظر في بروكسي مراكز البيانات - فهي توفر سرعة عالية وثبات في الاتصال، وهو أمر حاسم عند استنساخ المستودعات وتثبيت الاعتماديات. بالنسبة للمناطق ذات الحجب الصارم، فإن البروكسي السكنية هي الخيار الأفضل - حيث أن عناوين IP الخاصة بها نادرًا ما تتعرض للحجب.

```