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 практически не попадают под ограничения.