Прокси для GitHub из Ирана: как разработчику под санкциями сохранить доступ к коду

GitHub заблокировал доступ для пользователей из Ирана в 2019 году по требованию OFAC — американского регулятора, контролирующего соблюдение санкций. С тех пор иранские разработчики сталкиваются с одной и той же картиной: репозитории недоступны, push и pull не проходят, а аккаунт может быть заморожен в любой момент. При этом работа не останавливается — команды продолжают коммитить, деплоить и участвовать в open-source проектах. В этой статье разбираем, что реально работает в 2024–2025 году, какие прокси подходят для GitHub, и как их правильно настроить без потери скорости.

Почему GitHub блокирует Иран: санкции и техническая реализация

В июле 2019 года GitHub начал ограничивать доступ для пользователей из Ирана, Крыма, Кубы, Сирии и Северной Кореи. Причина — требования OFAC (Office of Foreign Assets Control) в рамках санкционного законодательства США. Microsoft, владеющая GitHub с 2018 года, обязана соблюдать эти ограничения как американская компания.

Технически блокировка работает по нескольким уровням:

• Геоблокировка по IP: GitHub определяет страну по IP-адресу и блокирует запросы из иранского диапазона адресов (AS-блоки, принадлежащие иранским провайдерам).
• Заморозка аккаунтов: Аккаунты, зарегистрированные с иранских IP или с указанием Ирана в профиле, могут быть переведены в режим read-only или полностью заморожены.
• Блокировка приватных репозиториев: Публичные репозитории частично доступны для чтения, но приватные — полностью закрыты.
• Ограничения GitHub Actions и Packages: CI/CD пайплайны и реестры пакетов также недоступны из заблокированных регионов.

При этом сам GitHub неоднократно заявлял, что выступает против этих ограничений и лоббирует послабления у регуляторов. В 2019 году компания добилась разрешения предоставлять бесплатный доступ к публичным репозиториям для иранских разработчиков, однако полного снятия блокировки так и не произошло.

⚠️ Важно понимать: Блокировка направлена против организаций и правительственных структур под санкциями, а не против индивидуальных разработчиков. Большинство иранских программистов работают в международных командах и не подпадают под санкции лично — но технически система блокирует всех по IP.

Именно поэтому решение проблемы лежит в плоскости смены IP-адреса — это единственный способ обойти геоблокировку технически. Разберём, какие инструменты для этого подходят.

Что реально работает: прокси, VPN и обходные схемы

Иранские разработчики используют несколько подходов. У каждого есть плюсы и минусы — разберём их честно, без маркетинга.

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

Резидентные прокси используют реальные IP-адреса домашних пользователей из других стран — Германии, Нидерландов, США, Турции. С точки зрения GitHub такой запрос выглядит как обращение от обычного пользователя из разрешённой страны. Это наиболее надёжный вариант для постоянной работы: минимальный риск блокировки самого прокси, высокая стабильность.

Минус — скорость ниже, чем у дата-центровых прокси, и стоимость выше. Для Git-операций (push/pull/clone) это обычно не критично: репозитории весят мегабайты, а не гигабайты.

2. Прокси дата-центров

Прокси из дата-центров работают быстрее и стоят дешевле. Подходят для клонирования больших репозиториев, скачивания артефактов, работы с GitHub API. Однако IP дата-центров легче идентифицировать как прокси — некоторые диапазоны уже внесены в стоп-листы GitHub. Рекомендуем использовать прокси дата-центров из европейских локаций (DE, NL, FR) — они реже попадают под фильтры.

3. VPN

VPN — самый популярный инструмент среди иранских пользователей. Работает на уровне всей операционной системы, не требует настройки в каждом приложении отдельно. Минусы: многие VPN-серверы уже заблокированы GitHub (особенно популярные бесплатные), скорость нестабильна, и при обрыве соединения трафик может утечь через иранский IP.

4. Tor

Tor технически работает, но GitHub активно блокирует выходные узлы Tor. Скорость крайне низкая — клонирование даже небольшого репозитория может занять часы. Для эпизодического доступа к веб-интерфейсу подойдёт, для регулярной разработки — нет.

5. SSH-туннели через сервер в другой стране

Если у вас есть VPS в Европе или США, можно поднять SOCKS5-прокси через SSH-туннель. Это технически надёжно и бесплатно (при наличии сервера), но требует базовых знаний Linux. Подробнее о настройке — в разделе про Git.

Какие типы прокси подходят для GitHub: сравнительная таблица

Разберём все варианты в одной таблице, чтобы было легко выбрать под свою ситуацию:

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

Как настроить прокси в Git, терминале и IDE: пошаговое руководство

Главное преимущество настройки прокси именно в Git (а не на уровне системы или VPN) — вы контролируете, какой трафик идёт через прокси. Локальные запросы остаются прямыми, только GitHub-трафик маршрутизируется через внешний IP.

Настройка HTTPS-прокси в Git (глобально)

Откройте терминал и выполните следующие команды, заменив HOST и PORT на данные вашего прокси:

# Для HTTP/HTTPS прокси:
git config --global http.proxy http://HOST:PORT

# Для SOCKS5 прокси (рекомендуется):
git config --global http.proxy socks5://HOST:PORT

# Если прокси с авторизацией (логин + пароль):
git config --global http.proxy socks5://USERNAME:PASSWORD@HOST:PORT

# Применить только для github.com (не трогать другие репозитории):
git config --global http.https://github.com.proxy socks5://HOST:PORT

Последняя команда — самая полезная: она применяет прокси только для запросов к github.com, не затрагивая GitLab, Bitbucket или внутренние репозитории компании.

Проверка настройки

# Посмотреть текущие настройки прокси в Git:
git config --global --list | grep proxy

# Тест соединения с GitHub через прокси:
git ls-remote https://github.com/github/gitignore HEAD

Если команда ls-remote вернула хэш коммита — прокси работает. Если ошибка Connection refused или Could not resolve host — проверьте правильность HOST и PORT.

Отключение прокси (когда не нужен)

# Удалить глобальный прокси:
git config --global --unset http.proxy

# Удалить прокси только для github.com:
git config --global --unset http.https://github.com.proxy

Настройка в VS Code

VS Code использует системные настройки прокси для встроенного терминала и расширений. Если вы настроили прокси в Git через терминал, встроенный терминал VS Code подхватит эти настройки автоматически. Для HTTP-прокси в самом редакторе (например, для установки расширений) откройте:

File → Preferences → Settings → поиск "proxy" → укажите адрес прокси в поле http.proxy.

Настройка через SSH-туннель (если есть свой VPS)

Если у вас есть VPS в Европе или США, можно поднять локальный SOCKS5-прокси через SSH одной командой:

# Создать SOCKS5-прокси на локальном порту 1080 через SSH:
ssh -D 1080 -C -N user@your-vps-ip

# Затем в Git указать этот локальный прокси:
git config --global http.proxy socks5://127.0.0.1:1080

Флаг -D 1080 открывает SOCKS5-прокси на порту 1080, -C включает сжатие, -N говорит SSH не выполнять команды — только держать туннель.

SSH vs HTTPS: что лучше работает через прокси для GitHub

Это один из самых частых вопросов: какой протокол использовать для работы с GitHub через прокси — SSH (порт 22 или 443) или HTTPS (порт 443)?

HTTPS через прокси

HTTPS-соединения легко проксировать — команды git config http.proxy, которые мы разобрали выше, работают именно для HTTPS. Минус: при каждом push/pull Git запрашивает логин и пароль (или Personal Access Token). Решение — сохранить токен в credential store:

# Включить хранение токена в системном keychain:
git config --global credential.helper store

# После первого успешного push токен сохранится автоматически

SSH через прокси (ProxyCommand)

SSH-соединения нельзя проксировать через стандартный http.proxy в Git — нужна отдельная настройка в ~/.ssh/config. Добавьте следующий блок:

Host github.com
    HostName ssh.github.com
    User git
    Port 443
    ProxyCommand nc -X 5 -x HOST:PORT %h %p

Здесь ssh.github.com:443 — это специальный SSH-эндпоинт GitHub, который работает на порту 443 (HTTPS), что помогает обойти блокировки на порту 22. nc -X 5 использует SOCKS5-прокси.

Проверить SSH-соединение можно командой:

ssh -T [email protected]
# Ожидаемый ответ: Hi username! You've successfully authenticated...

Риски для аккаунта и как их минимизировать

Использование прокси для GitHub — это не только техническая задача, но и вопрос безопасности аккаунта. Неправильная настройка может привлечь внимание к аккаунту или создать новые проблемы.

Риск 1: Постоянная смена IP

Если вы используете ротирующие прокси (IP меняется с каждым запросом или каждые несколько минут), GitHub может зафиксировать подозрительную активность: один аккаунт заходит с десятков разных IP за короткое время. Это триггер для проверки безопасности и потенциальной блокировки.

Решение: Используйте статичные (sticky) прокси с фиксированным IP или сессионные прокси с длительным временем сессии (от 24 часов). Для GitHub не нужна ротация — нужна стабильность.

Риск 2: Использование заблокированных IP дата-центров

Некоторые диапазоны IP популярных хостингов (AWS, DigitalOcean, Vultr) уже внесены в стоп-листы или вызывают повышенное внимание. GitHub не блокирует их напрямую, но может запрашивать дополнительную верификацию.

Решение: Выбирайте европейские дата-центры (DE, NL, CH) — они реже попадают в блок-листы. Перед постоянным использованием проверьте IP через ipinfo.io или scamalytics.com.

Риск 3: Иранские данные в профиле

Если в вашем профиле GitHub указан Иран (в поле Location), аккаунт с большей вероятностью попадёт под ограничения независимо от IP. Это не значит, что нужно скрывать происхождение — но стоит понимать, что это дополнительный фактор.

Риск 4: Работа с организационными репозиториями

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

Что делать, если аккаунт уже заморожен

GitHub предоставляет официальный процесс разморозки аккаунта для частных разработчиков. Напишите на [email protected] с объяснением ситуации. В письме укажите:

• Что вы индивидуальный разработчик, не связанный с санкционными организациями
• Что ваша деятельность — open-source или коммерческая разработка ПО
• Ссылки на ваши публичные репозитории и активность

По опыту сообщества, GitHub восстанавливает доступ для большинства индивидуальных разработчиков в течение 1–4 недель.

Чек-лист: быстрая проверка настройки прокси для GitHub

Используйте этот чек-лист, чтобы убедиться, что всё настроено правильно перед началом работы:

Заключение

Санкционные ограничения GitHub — неприятная реальность для иранских разработчиков, но не тупик. Техническое решение существует и работает: прокси с зарубежным IP в связке с правильной настройкой Git позволяет вести полноценную разработку — пушить коммиты, клонировать репозитории, работать с GitHub Actions и участвовать в open-source проектах.

Ключевые выводы из статьи:

• Для ежедневной работы выбирайте статичные резидентные или дата-центровые прокси из Европы — стабильный IP без ротации.
• Настраивайте прокси в Git config, а не на уровне системы — это даёт точечный контроль без влияния на весь трафик.
• Если аккаунт уже под подозрением — используйте мобильные IP, они практически никогда не попадают под блокировки.
• Если аккаунт заморожен — пишите на [email protected], GitHub восстанавливает доступ для индивидуальных разработчиков.
• Используйте SSH через порт 443 (ssh.github.com) — это обходит большинство блокировок на уровне провайдера.

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