Назад к блогу

Прокси для GitHub и npm: как получить доступ к репозиториям и пакетам из стран, где GitHub заблокирован или работает медленно

Если GitHub заблокирован или работает медленно — прокси решает проблему за 10 минут. Рассказываем, как настроить доступ к репозиториям и npm-пакетам без VPN.

📅4 апреля 2026 г.

GitHub заблокирован, работает с задержкой в 10–30 секунд или npm install зависает на полпути — знакомая ситуация для разработчиков из России, Ирана, Китая и ряда других стран. Решение есть, и оно проще, чем кажется: правильно настроенный прокси даёт стабильный доступ к репозиториям, пакетам и API GitHub без VPN и без лишних плясок с бубном.

Почему GitHub и npm блокируют или замедляют

Прежде чем настраивать прокси, важно понять, с чем именно вы столкнулись. Проблемы с доступом к GitHub и npm бывают трёх типов, и каждый требует своего подхода.

Полная блокировка на уровне государства

Ряд стран — Китай, Иран, Северная Корея, а с 2022 года периодически и Россия — блокирует GitHub на уровне DNS или по IP. Это означает, что запросы к github.com либо не проходят вообще, либо возвращают ошибку соединения. npm-реестр (registry.npmjs.org) при этом может работать нормально — или тоже быть заблокирован.

Корпоративные фаерволы и ограничения сети

Даже без государственной блокировки корпоративные сети часто ограничивают доступ к внешним репозиториям. Это стандартная практика в банках, государственных структурах и крупных предприятиях: IT-отдел закрывает исходящие соединения на порты 443 или блокирует конкретные домены. Разработчик в такой сети не может сделать git clone или npm install без обходного пути.

Медленная скорость из-за географии

Технически GitHub доступен, но клонирование репозитория на 500 МБ занимает 40 минут, а установка зависимостей через npm — вечность. Это проблема маршрутизации: пакеты идут через перегруженные узлы или длинные маршруты. Прокси-сервер, расположенный в США или Европе, сокращает путь и даёт реальный прирост скорости в 3–10 раз.

Важно понимать:

Прокси решает все три проблемы: обходит блокировку, туннелирует трафик через разрешённые порты и улучшает скорость за счёт географически близкого выходного узла. При этом прокси работает на уровне конкретного приложения — Git, npm, браузера — не затрагивая остальной трафик на машине.

Прокси vs VPN: что выбрать для работы с кодом

Многие разработчики по привычке тянутся к VPN. Это понятно — VPN прост в настройке и работает сразу для всей системы. Но для работы с GitHub и npm прокси зачастую удобнее. Разберём разницу.

Критерий Прокси VPN
Охват трафика Только конкретное приложение (Git, npm) Весь трафик системы
Настройка в CI/CD Через переменные окружения, просто Требует установки клиента, сложно
Работа в Docker Передаётся через ENV, без проблем Требует привилегированного режима
Скорость Высокая (нет шифрования всего трафика) Ниже из-за шифрования
Конфликты с корпоративной сетью Минимальные Частые (блокируется IT-отделом)
Использование на сервере Нативно через env-переменные Нужна установка демона

Вывод простой: если ваша задача — дать команде доступ к GitHub и npm, прокси настраивается один раз в конфиге и работает без вмешательства в системные настройки каждой машины. Особенно это важно для CI/CD-пайплайнов, где VPN физически сложно поднять.

Какой тип прокси подходит для GitHub и npm

Не все прокси одинаково хорошо работают с Git и npm. Выбор зависит от вашей задачи: обойти блокировку, ускорить загрузку или работать из корпоративной сети.

HTTP/HTTPS прокси

Самый простой вариант. Git и npm нативно поддерживают HTTP-прокси через стандартные переменные окружения. Подходит для большинства задач: клонирование репозиториев, установка пакетов, работа с GitHub API. Если ваш прокси-провайдер выдаёт HTTP-адрес — начинайте с него.

SOCKS5 прокси

Более гибкий протокол, работает на уровне TCP. Поддерживает любые типы трафика, включая SSH-соединения с GitHub (порт 22). Если вы используете Git через SSH, а не HTTPS — SOCKS5 предпочтительнее. Git поддерживает SOCKS5 через параметр socks5:// в конфиге.

Резидентные прокси

Резидентные прокси используют IP-адреса реальных домашних пользователей. Для GitHub это особенно актуально, если вы работаете из страны с жёсткой блокировкой: такие IP крайне редко попадают в чёрные списки и выглядят как обычный пользовательский трафик. Подходят для ситуаций, когда дата-центровые 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 (self-hosted). Но зеркала часто отстают по версиям пакетов, поэтому прокси надёжнее:

# Переключить реестр на зеркало (только для ускорения, не для блокировок)
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 прокси настраивается через переменные окружения в workflow-файле. Добавьте секреты в настройках репозитория (Settings → Secrets), затем используйте их в workflow:

# .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: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Configure npm proxy
        run: |
          npm config set proxy ${{ secrets.PROXY_URL }}
          npm config set https-proxy ${{ secrets.PROXY_URL }}
      
      - name: Install dependencies
        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('Install') {
            steps {
                sh 'npm config set proxy $HTTP_PROXY'
                sh 'npm config set https-proxy $HTTPS_PROXY'
                sh 'npm ci'
            }
        }
        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }
    }
}

Частые ошибки и как их исправить

Даже при правильной настройке прокси что-то может пойти не так. Собрали самые распространённые ошибки и способы их решения.

Ошибка: ECONNREFUSED или Connection refused

Прокси не отвечает. Причины: неверный адрес или порт, прокси-сервер недоступен, истёк срок действия учётных данных.

Решение: Проверьте доступность прокси командой:

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

Ошибка: SSL certificate problem / 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 нет

Clone (чтение) и 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 proxy настроен: 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 registry через прокси ==="
curl -s -o /dev/null -w "%{http_code}" --proxy "$PROXY" https://registry.npmjs.org && echo " OK" || echo " FAIL"

echo "=== 4. Текущие настройки Git proxy ==="
git config --global --list | grep proxy || echo "Git proxy не настроен"

echo "=== 5. Текущие настройки npm proxy ==="
npm config get proxy
npm config get https-proxy

Заключение

Настройка прокси для GitHub и npm — это не сложная задача, если знать правильный порядок действий. Подведём итог:

  • Для ускорения медленного GitHub — подойдут прокси дата-центров в США или Европе: они быстрые, стабильные и недорогие.
  • Для обхода блокировок — резидентные прокси с IP реальных пользователей обеспечивают максимальную надёжность.
  • Для Git через HTTPS — настройте http.proxy в git config.
  • Для Git через SSH — используйте ProxyCommand в ~/.ssh/config.
  • Для npm/yarn/pnpm — настройте proxy через config или переменные окружения.
  • Для CI/CD — передавайте данные прокси через секреты, не хардкодьте в коде.

Один раз потратив 10–15 минут на настройку, вы получаете стабильный доступ к GitHub и npm без зависимости от состояния интернет-канала или политики блокировок. Команда перестаёт терять время на ожидание медленных загрузок, CI/CD-пайплайны проходят без ошибок сети, а разработчики в разных странах работают в одинаковых условиях.

Если вы ищете стабильный прокси для работы с GitHub и npm из стран с ограниченным доступом, рекомендуем рассмотреть прокси дата-центров — они обеспечивают высокую скорость и стабильность соединения, что критично при клонировании репозиториев и установке зависимостей. Для регионов с жёсткими блокировками лучше подойдут резидентные прокси — их IP практически не попадают под ограничения.