Ресурсы для разработчиков все менее доступны в России. Что делать разработчикам? Почему VPN — не решение? Разбор #8

В рубрике «Разбор Теплицы» мы в режиме реального времени разбираемся в определенной проблеме, новостях интернет-цензуры и рассказываем:

• что происходит;
• как это устроено;
• как с этим можно бороться

Есть мысли по поводу темы? Поделитесь с нами!

Заполните небольшую форму и расскажите, что вы думаете про устройство новых ограничений и как можно минимизировать ущерб для них операторам VPN и обычным пользователям.

Кратко

В России с начала 2026 года накапливаются сбои и ограничения, которые затрагивают инфраструктуру разработки: GitHub, системные репозитории Linux, отдельные репозитории экосистемы Rust и Debian, а теперь и PyPI. Об этом писали Meduza, РБК и Anti-Malware.

В мае 2026 года проект OONI зафиксировал ухудшение доступности GitHub из России. По данным OONI, на которые ссылалась «Вёрстка», доля аномальных измерений теста Web Connectivity по GitHub на российских сетях выросла примерно с фоновых ≤4% до 10% 5 мая, а 6–7 мая доходила примерно до 16%. Это агрегированная доля проблемных измерений в выборке OONI Probe, а не доля «отключённых» пользователей. О перебоях и жалобах рассказывали также «Медуза» и The Insider, а о симптомах вроде нестабильного открытия страниц, сбоев git clone и проблем с raw-файлами писал Skillbox Media.

Роскомнадзор официально заявил, что не ограничивает доступ к GitHub. Домен GitHub действительно не заблокирован целиком, однако в реестре запрещенной информации, как отмечают «Вёрстка» и The Moscow Times, находятся более 130 отдельных страниц сервиса. Причем число таких записей в 2026 году заметно выросло.

1 июня 2026 года издание «Код Дурова» сообщило, что из России уже вторые сутки сложно попасть на PyPI — официальный репозиторий Python-пакетов. По данным издания, соединение с pypi.org обрывается на этапе TLS, что напоминает поведение других ресурсов, которые ранее уже блокировались или фильтровались на уровне сети.

Роскомнадзор в ответ заявил, что доступ к PyPI не ограничивает. На этом фоне отрасль все активнее обсуждает переход к зеркалам, self-hosted Git-платформам и резервным каналам доставки зависимостей, потому что проблема уже выглядит не как единичный сбой, а как новая норма для разработчиков в России.

Git — это система, с помощью которой программисты работают с исходным кодом программ. А PyPI — это каталог готовых Python-пакетов, то есть библиотек и модулей, которые программисты подключают в свои проекты.

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

Хронология ограничений в 2026 году

Период	Что произошло
Февраль 2026	Недоступность git.kernel.org и смежных Linux-ресурсов; жалобы разработчиков Astra Linux, РЕД ОС, Alt Linux. Связывают с фильтрацией на фоне замедления Telegram.
Апрель 2026	В сводках о затронутых ресурсах фигурируют репозитории Debian и Rust.
5–7 мая 2026	OONI фиксирует рост доли аномальных измерений GitHub из России: с ≤4% до 10% (5 мая) и до ~16% (6–7 мая). РКН блокировку отрицает.
Май 2026	Депутат Госдумы Антон Горелкин, который известен своими инициативами, связанными с цензурой в интернете, призывает переносить проекты с GitHub на альтернативные площадки.
Конец мая 2026	Сообщения о неполадках с DeepSeek с тем же TLS-паттерном.
1 июня 2026	«Код Дурова»: вторые сутки проблемы с доступом к PyPI, обрыв на этапе TLS.

Чем дальше, тем плотнее события идут друг за другом — и тем сложнее объяснять их единичными «техническими работами».

Что происходит

История с GitHub не возникла на пустом месте. Еще в феврале 2026 года пользователи и разработчики российских Linux-дистрибутивов жаловались на недоступность git.kernel.org и связанных с ним ресурсов: об этом писали Meduza, Xakep и Anti-Malware. Тогда же сообщалось о проблемах с репозиториями Debian, Rust, а также проектами вроде Yocto, Zephyr, Buildroot и Artix Linux.

Эти ограничения ударили не только по энтузиастам open source. Из-за перебоев пострадали команды, которые используют Linux-репозитории в корпоративной разработке, сборке собственных дистрибутивов и обновлении инфраструктуры. В публикациях Meduza, CNews и The Code прямо упоминалось, что сложности затронули в том числе разработчиков российских ОС: Astra Linux, «РЕД ОС» и Alt Linux.

В мае появились проблемы с GitHub. Измерения OONI и многочисленные жалобы пользователей показывают, что доступ из России стал заметно менее стабильным. Объяснения регулятора и площадки разные: Роскомнадзор утверждает, что ничего не блокирует, GitHub связывает проблемы с техническими работами по расширению инфраструктуры.

К концу мая проблема стала шире: пользователи сообщили о неполадках с DeepSeek, а затем с PyPI. В обоих случаях наблюдался обрыв соединения на этапе TLS. Это важно, потому что именно такой паттерн часто описывают как признак фильтрации или блокировки на сетевом уровне.

Что показывают данные OONI

Ниже — график OONI Explorer по тесту Web Connectivity для github.com из России за период с 1 апреля по 1 июня 2026 года. Каждый столбец — измерения за сутки: зеленое — «хорошо», желтое — «аномалия» (вероятные признаки вмешательства), серое — «отказ», красное — «подтверждённый» (доказанная блокировка с блок-страницей).

Тест подключения к сети, github.com (Россия). Источник: OONI Explorer, данные за 1 апреля — 1 июня 2026.

Что видно на графике

Почти все дни апреля и большей части мая — практически полностью зеленые: в обычном режиме доступ к GitHub из России в основном работает. Резкое исключение — 5–7 мая: именно в эти дни заметно вырастает доля желтых сегментов («аномалия»). 5 мая аномальные измерения поднимаются примерно до 15 из ~159 за сутки (около 10%), а 6 мая достигают пика — порядка 24 из ~148 (примерно 16%). После 7 мая всплеск спадает, хотя единичные желтые сегменты встречаются и в последующие дни.

Чего на графике нет

Красные сегменты («подтвержденный») отсутствуют во все дни. Это ключевая деталь: OONI ни разу не зафиксировал автоматически подтвержденную блокировку — то есть блок-страницу. Данные говорят именно об аномалиях — вероятном, но не доказанном вмешательстве, что согласуется с осторожными формулировками СМИ и с отрицанием блокировки со стороны Роскомнадзора.

Как читать график

Общее число измерений в сутки колеблется (примерно от 50 до 250), поэтому показательна не абсолютная высота желтого столбца, а его доля от всех измерений дня на уровне российских сетей. Сам OONI подчеркивает: рост доли аномалий указывает на вероятную, но не гарантированную блокировку — возможны ложноположительные срабатывания.

Сигнал усиливается, когда ошибки однотипны (например, обрыв на этапе TLS-хендшейка) и устойчивы во времени в пределах одной автономной системы (ASN). Можно обратить внимание, что количество измерений постепенно снижается, это может говорить как о нормальной ситуации (уменьшение числа проверок), так и работу «белых списков», при котором отправка отчетов OONI невозможна.

Как воспроизвести эту проверку самостоятельно

График интерактивный и обновляется, поэтому актуальную версию и разбивку по операторам (ASN) можно открыть по прямой ссылке с уже подставленными параметрами: OONI Explorer — GitHub, RU, Web Connectivity. Общая страница по стране со сводными графиками — OONI Explorer: Internet Censorship in Russia.

Вы сами можете поучаствовать в тестировании. Самый простой путь — поставить приложение OONI Probe (Android, iOS) и регулярно запускать тесты с того устройства и сети, где вы обычно выходите в интернет. В OONI просят учитывать риски и не тестировать чувствительные сайты без понимания последствий. Лучше перед тестированием прочитать их раздел о безопасности.

Как происходят сбои

Непонятно. Пока нет публичных доказательств одной-единственной причины, которая объясняла бы все сбои сразу. Но из уже известных кейсов, описанных Netopia и Anti-Malware, складывается несколько рабочих гипотез.

Гипотеза 1. Побочные эффекты блокировок и замедлений, нацеленных на другие сервисы

В феврале 2026 года ряд СМИ связывали недоступность Linux-ресурсов с новыми алгоритмами Роскомнадзора, применявшимися в рамках борьбы с Telegram. Об этом писали Meduza, Xakep и The Code. Если фильтрация строится по IP-адресам, CDN-подсетям, TLS-параметрам или иным косвенным признакам, под удар могут попадать и вполне нейтральные сервисы для разработчиков.

Гипотеза 2. Рост числа точечных блокировок страниц и ресурсов внутри крупных платформ

Домен GitHub целиком в реестр запрещённых сайтов не внесён, но отдельные URL и страницы блокируются, причём таких записей становится больше. На это обращали внимание «Вёрстка» и The Moscow Times. Так возникает ситуация, в которой сервис вроде бы «не запрещён», однако его доступность для пользователей в России всё равно постепенно ухудшается.

Гипотзеа 3. Техническая уязвимость современной разработки к любым сбоям на транспортном и прикладном уровне

GitHub, PyPI, Docker Hub, системные Git-репозитории, CI/CD-пайплайны и менеджеры пакетов — это не независимые инструменты, а единая цепочка поставки кода и зависимостей. Об этом писали SecurityLab и та же Netopia. Даже если основной сайт открывается, сбой на уровне git clone, загрузки release-файлов, контейнерных образов или Python-пакетов уже делает рабочий процесс нестабильным.

Кто что говорит

Позиция регулятора остается прежней: Роскомнадзор заявляет, что не ограничивает доступ к GitHub и по PyPI. Формально это позволяет властям говорить не о блокировке, а о внешних или технических проблемах.

Часть отраслевых и медийных объяснений указывает на сетевые побочные эффекты. В публикации «Кода Дурова» приводилась оценка, согласно которой GitHub и PyPI могли задеть по касательной из-за блокировок подсетей CDN вроде Fastly: pypi.org резолвится на Fastly, а многие диапазоны Fastly на тот момент были заблокированы. Это не окончательное доказательство, но версия хорошо согласуется с известными историями, когда ограничения по инфраструктурному признаку затрагивали сразу несколько внешне не связанных сервисов.

Самое заметное политическое заявление — от первого зампреда комитета Госдумы по информационной политике, информационным технологиям и связи Антона Горелкина, известного своими цензурными инициативами. Он призвал российских разработчиков переносить проекты с GitHub на альтернативные площадки, включая российские, и предупредил, что сервис может стать недоступным полностью. При этом депутат отдельно подчеркивал, что не считает GitHub «вредительской платформой» и признаёт его ценность для IT-отрасли, как отмечал Skillbox Media.

Со стороны профессионального сообщества реакция более прагматична. Эксперты рекомендуют не ждать официального признания блокировки, а строить отказоустойчивость заранее: зеркалировать репозитории, разворачивать self-hosted GitLab или Forgejo (альтернатива GitHub/GitLab), поддерживать локальные кэши пакетов и не держать единственную точку доступа к исходному коду за пределами страны. Такие рекомендации есть, в частности, у Netopia и в материале Kaspersky Daily о выводах из истории с Docker Hub.

Почему это важно

Для современной разработки GitHub и PyPI — это не просто «сайты». GitHub остается крупнейшей платформой совместной разработки, а PyPI — базовой инфраструктурой поставки пакетов для Python, который используется в аналитике, DevOps, backend-разработке, кибербезопасности и автоматизации. Поэтому даже частичная деградация доступа быстро превращается в проблему для бизнеса, образования, НКО и независимых технических команд.

Особенно уязвимы небольшие команды. Крупная компания еще может содержать собственные решения, а у маленьких студий, независимых разработчиков или общественных организаций такой резервной инфраструктуры часто нет. В результате именно они первыми сталкиваются с сорванными релизами, невозможностью обновить зависимости и дополнительными расходами на обходные решения.

Для экосистемы open source проблема еще шире. Ограничение доступа к глобальным репозиториям ослабляет участие российских разработчиков в международных проектах, затрудняет публикацию кода и снижает совместимость локальной разработки с мировыми практиками. В конечном счете, отрыв российских разработчиков от международных ресурсов приведет к неминуемой деградации отрасли.

Международный контекст

Россия — не первый случай, когда доступ к глобальной инфраструктуре разработки становится точкой давления или попадает под санкционные и регуляторные ограничения. Несколько сопоставимых сюжетов помогают увидеть в происходящем закономерность, а не разовую аварию.

• Санкционные geo-ограничения со стороны самих платформ. В 2024 году Docker Hub временно закрывал доступ с российских IP, а GitHub ранее ограничивал отдельные аккаунты под санкциями. Здесь источник ограничения — зарубежный сервис, а не местный регулятор.
• Полные блокировки на уровне страны. В Иране доступ к GitHub, GitLab и многим пакетным реестрам годами осложнен комбинацией внешних санкций и внутренней фильтрации. Разработчики массово опираются на зеркала и прокси.
• «Великий файрвол». В Китае нестабильный доступ к GitHub и медленные пакетные реестры давно превратили локальные зеркала (например, корпоративные и университетские npm/PyPI-mirror) в стандарт инженерной гигиены.

Общий вывод из этих кейсов: там, где доступ к глобальной dev-инфраструктуре становится непредсказуемым, выживает не тот, кто быстрее «обходит» очередную блокировку, а тот, кто заранее построил несколько независимых источников кода, пакетов и образов. Именно к этой логике и движется российская отрасль.

Какие сервисы уже затронуты

Ниже — краткая карта сервисов, которые уже сталкивались с похожими проблемами.

Сервис	Тип проблемы	Что известно
GitHub	Нестабильный доступ, частичные блокировки страниц	В мае 2026 OONI зафиксировал рост аномальных подключений; РКН блокировку отрицает.
PyPI	Проблемы с доступом, обрыв TLS	О проблемах сообщило «Код Дурова» (1 июня 2026); РКН отрицал блокировку.
git.kernel.org	Недоступность для российских пользователей	Проблемы фиксировались в феврале 2026 на фоне сетевых ограничений (Meduza, Xakep, Anti-Malware).
Debian	Блокировка или недоступность репозитория	РБК и Anti-Malware приводили Debian как один из затронутых кейсов.
Rust-репозиторий	Блокировка или недоступность	Упоминался как пример ложных срабатываний и ограничений (РБК, Anti-Malware).
Yocto / Zephyr / Buildroot / Artix	Частичная недоступность	Фигурировали в сообщениях о февральских сетевых сбоях (Habr, Xakep).
Docker Hub	Geo-IP-ограничение со стороны сервиса	В 2024 доступ из РФ закрывался по санкциям; позднее ограничение сняли (masterhost, Habr, CNews). Источник — платформа, а не РКН.

Речь уже не об одном домене и не об одном инциденте. Причины проблем разные, и их важно не смешивать: часть ограничений исходит от российских регуляторных механизмов (фильтрация на ТСПУ, записи в реестре), а часть — от самих зарубежных платформ, выполняющих санкционные требования (geo-IP-ограничения). Симптомы у пользователя могут выглядеть похоже, но реагировать на них нужно по-разному.

Как реагирует отрасль

Резервирование

Главная реакция отрасли — резервирование. Разработчики и компании переносят критичные проекты на self-hosted решения, поднимают зеркала Git-репозиториев и кэширующие прокси для пакетов, чтобы не зависеть от одной внешней точки доступа. Такую стратегию описывают Netopia и Kaspersky Daily.

Альтернативные платформы

Вторая реакция — диверсификация платформ. Наряду с GitHub рассматриваются GitLab CE, Gitea, Forgejo, а в российском контуре чаще обсуждаются GitVerse, GitFlic, РТК-Феникс и другие локальные альтернативы. Однако даже их сторонники признают, что у GitHub пока нет полноценной замены.

Чтобы вам было проще сравнивать варианты, ниже — таблица основных платформ с параметрами, которые важны именно для небольших команд и НКО.

Платформа	Размещение	Открытый код	CI/CD	Заметки для распределенных команд
GitHub	Облако (вне РФ)	Нет (сервис)	GitHub Actions	Максимальная интеграция и сетевой эффект, но единственная внешняя точка — главный риск.
GitLab CE	Self-hosted	Да	Встроенный	Полноценный self-hosted-контур; зеркалирование между серверами есть в платных тарифах.
Forgejo	Self-hosted	Да	Forgejo Actions	Легкий, активно развивается; хорош для небольшой команды на своём VPS.
Gitea	Self-hosted / облако	Да	Gitea Actions	Минимальные требования к серверу; простой бэкап.
GitVerse / GitFlic / РТК-Феникс	РФ	Частично / нет	Есть	Локальная юрисдикция: плюс по доступности внутри РФ, но минус для проектов с международными участниками и чувствительными данными.

Архитектура устойчивости

Третья реакция — переход от «обхода блокировок по факту» к архитектуре устойчивости. Речь идет уже не только о VPN или прокси, а о построении процессов, в которых код, зависимости и контейнеры доступны из нескольких независимых источников. Для многих команд это означает дополнительные расходы и усложнение DevOps-процессов, но альтернатива — работать в режиме постоянных аварий.

Что могут делать разработчики

Надежного универсального решения здесь нет, но базовый набор мер уже понятен.

• Зеркалировать критичные Git-репозитории и не хранить единственную копию рабочего кода на GitHub, как рекомендуют Netopia и отраслевые публикации о миграции.
• Развернуть self-hosted Git-платформу для внутренних проектов и резервного доступа — например GitLab CE, Forgejo или Gitea.
• Поднять локальный кэш или приватное зеркало зависимостей для Python, Node.js и контейнерных образов, если проект зависит от внешних реестров. На важность этого подхода указывает и опыт с Docker Hub.
• Разделять публичный контур и критическую инфраструктуру: открытые зеркала могут оставаться на GitHub, а рабочая сборка и деплой — жить в собственном контуре.
• Документировать инциденты доступа и проверять, где именно рвётся соединение — на DNS, TCP, TLS или HTTP, потому что это помогает отличить санкционное ограничение платформы от сетевой фильтрации внутри России.

Мини-инструкция: где именно рвется соединение

Прежде чем менять инфраструктуру, полезно понять, на каком уровне возникает сбой. Базовая последовательность (подставьте нужный хост вместо github.com):

1) DNS — резолвится ли имя:

nslookup github.com   # или: dig github.com

2) TCP — открывается ли 443-й порт:

curl -v --connect-timeout 10 https://github.com

3) TLS — на каком этапе обрывается рукопожатие и доходит ли ответ сервера (должен быть установлен openssl):

openssl s_client -connect github.com:443 -servername github.com

4) Маршрут — где теряются пакеты:

traceroute github.com   # в Windows: tracert; удобнее mtr github.com

Как читать результат:

• Если имя не резолвится или резолвится в подозрительный IP — это похоже на DNS-вмешательство.
• Если TCP-соединение устанавливается, а openssl s_client обрывается сразу после Client Hello (RST / «connection reset»), причём именно при передаче реального SNI — это классический признак DPI-фильтрации по имени хоста.
• Если же сервер вообще не отдаёт сертификат с российского IP, но работает со сменой IP — это больше похоже на geo-ограничение со стороны платформы.

Вы можете прислать нам результаты выполнения команд для анализа.

Важно: команды выше — диагностические и безопасные. Они не «обходят» ограничения, а лишь показывают, где рвется соединение, чтобы выбрать правильную стратегию. Сохраненные логи curl -v могут содержать заголовки и детали сертификатов — не публикуйте их целиком.

Мини-инструкция: зеркала и кэши зависимостей

Идея простая: между вашим pip / git / docker и внешним реестром ставится локальный кэш или зеркало, которое продолжает работать, даже когда внешний ресурс недоступен. Расскажем коротко несколько проверенных решений, только чтобы задать направление:

• Python (PyPI). Кэширующий прокси devpi или лёгкий proxpi для команды; полное зеркало — bandersnatch. Обзор всех подходов — в официальном гайде PyPA «Package index mirrors and caches».
• Git. Держите репозиторий в нескольких местах через дополнительный push-URL, чтобы один git push отправлял код и на GitHub, и на резервную площадку (синтаксис — в документации git remote):
• Контейнеры (Docker Hub и пр.). Поднимите registry как pull-through кэш — см. рецепт «registry as a pull-through cache» в документации Distribution. Универсальный вариант управления собственными репозиториями пакетов на несколько экосистем сразу (RPM, Debian, Python, контейнеры) — Pulp.

Все перечисленные инструменты — официальные или широко используемые в индустрии. Конкретную конфигурацию стоит подбирать под размер команды: для двух-трех человек хватает кэширующего прокси, для организации с CI/CD имеет смысл полноценное зеркало и реестр образов.

Что это значит для НКО и гражданских IT-проектов

У некоммерческих, правозащитных и медиапроектов ситуация острее, чем у бизнеса: бюджет ограничен, а зависимость от цифровой инфраструктуры не меньше. Потеря доступа к репозиториям, пакетам и образам может означать не неудобство, а риск остановки сервисов и внутренних инструментов. Несколько практических советов:

• Не завязывайте единственную точку доступа на одну юрисдикцию. Держите рабочую копию кода минимум в двух независимых местах, желательно в разных странах, чтобы блокировка или санкции на одной стороне не останавливали работу.
• Разделяйте публичный и чувствительный контур. Открытые материалы и зеркала могут жить на публичных платформах, а внутренние инструменты, данные и сборка — в закрытом self-hosted контуре с ограниченным кругом доступа.
• Учитывайте разный правовой статус участников. Если в команде есть люди внутри и вне России с разными рисками, доступы стоит выстраивать по принципу минимально необходимого: не у всех должен быть полный доступ ко всей инфраструктуре, а критичные действия лучше дублировать между несколькими доверенными людьми.
• Заранее опишите аварийный сценарий. Простой документ «что делаем, если завтра пропал доступ к GitHub/PyPI»: где резервные зеркала, кто их обновляет, как переключить CI. Это дешевле, чем разбираться в момент аварии.
• Закладывайте устойчивость в бюджет грантов. Небольшой VPS под зеркало и кэш стоит недорого, но именно он часто оказывается тем, на чём экономят — до первого серьёзного сбоя.

Почему VPN — не решение, а временный мост

VPN и прокси кажутся очевидным ответом, но как основа рабочего процесса они плохо подходят, и вот почему.

• Нестабильность и непредсказуемость. Каналы обхода сами становятся объектом ограничений; то, что работало вчера, может не работать сегодня, и сборка ломается в самый неподходящий момент.
• Плохая совместимость с автоматизацией. CI/CD-раннеры, пакетные менеджеры и контейнерные сборки обычно не рассчитаны на работу через нестабильный VPN: таймауты, частичные загрузки и битые кэши приводят к трудноуловимым ошибкам.
• Юридические и организационные риски. Для организации завязывать критичные процессы на инструменты обхода — отдельный риск.

VPN все же оправдан:

• как временный мост, чтобы разово стянуть зависимости и тут же положить их в локальное зеркало;
• для ручной работы человека с интерфейсом (не для автоматики);
• как запасной канал на время настройки нормальной отказоустойчивой архитектуры.

То есть VPN помогает выиграть время, но не заменяет другие решения.

Что делать тем, кто не пишет код

Казалось бы, при чем тут непрограммисты. Но наша работа часто зависит от софта, который под капотом тянет пакеты с PyPI или образы с Docker Hub, даже если сами сотрудники об этом не думают. Несколько простых шагов (выберите те, что применимы для вас):

• Спросите своих разработчиков, есть ли у проекта резервные зеркала и что произойдет с сайтом или инструментом, если завтра пропадёт доступ к внешним ресурсам.
• Сохраняйте рабочие версии. Если пользуетесь готовым инструментом, держите офлайн-копию установщика или образа, который точно работает — обновиться можно потом, а вот восстановить «с нуля» во время блокировки тяжело.
• Не переустанавливайте «на всякий случай». Во время сбоев переустановка софта, который тянет компоненты из недоступного реестра, может оставить вас без рабочего инструмента вовсе.
• Закладывайте устойчивость в планирование. Полезно заранее знать, какие сервисы критичны, и иметь запасной вариант на случай недоступности. Ну и делайте резервные копии, конечно.

Что дальше

Судя по динамике 2026 года, проблема не выглядит временной. Сначала под удар попали Linux-репозитории, затем GitHub, затем PyPI, и уже этого достаточно, чтобы говорить о системном ухудшении доступности зарубежной инфраструктуры разработки в России. Это подтверждают публикации Meduza, Anti-Malware и «Кода Дурова».

Даже если часть этих инцидентов объясняется не прямой блокировкой, а побочными эффектами сетевой фильтрации, для пользователя результат один и тот же: инструменты разработки становятся менее предсказуемыми и менее надёжными. А значит, отрасль будет и дальше двигаться к зеркалам, self-hosted-решениям и фрагментации экосистемы — не потому, что так удобнее, а потому, что иначе уже нельзя строить устойчивые процессы.

Источники

GitHub

• «В России начали ограничивать доступ к GitHub». «Вёрстка»
• «В России начали ограничивать доступ к GitHub». The Insider
• «GitHub стал плохо открываться в России. Роскомнадзор утверждает, что не блокирует его». Meduza
• «Блокировка GitHub в России: что известно». Skillbox Media
• «GitHub не ограничивается, заявили в Роскомнадзоре». «Ведомости»
• «Роскомнадзор заявил, что не блокирует GitHub». «Газета.Ru»
• «В России начали блокировать одну из крупнейших платформ для программистов». The Moscow Times
• «Горелкин призвал российских разработчиков переносить проекты из GitHub». «Ведомости»
• «Депутат Горелкин призвал разработчиков переходить на российские Git-платформы». Anti-Malware
• «Ухудшение доступности зарубежных сервисов и риски для разработки». SecurityLab
• «Доступность GitHub в России: что делать командам и как готовить запасной репозиторий». Netopia

PyPI и DeepSeek

• «Сайт китайского ИИ-сервиса перестал открываться без использования VPN». «Код Дурова»
• «В России зафиксированы проблемы с доступом к PyPI». «Код Дурова»
• «Роскомнадзор не ограничивал доступ к Python». «Осторожно, новости»
• «Роскомнадзор: доступ к Python Package Index не ограничивается». Хабр

Linux-репозитории и более ранние ограничения

• «Разработчики российских ОС не могут получить обновления с серверов Linux — всё из-за Роскомнадзора». Meduza
• «Россияне внезапно остались без обновлений Linux и Windows. Зацепило даже отечественные Astra Linux, «Альт» и «Ред ОС»». CNews
• «Хотели замедлить Telegram, а уронили Linux: как «чёрные ящики» РКН мешают работать айтишникам». Xakep
• «Блокировка обновлений Linux и Windows в России». The Code
• «Сводка о недоступности репозиториев Debian и Rust для российских пользователей». Anti-Malware
• «Российские разработчики столкнулись с ограничениями доступа к репозиториям». РБК

Docker Hub

• «Docker Hub стал недоступен для пользователей из России». masterhost
• «Уроки истории с Docker Hub: как снизить зависимость от внешних реестров». Kaspersky Daily

Данные мониторинга

• «OONI Explorer: Internet Censorship in Russia». OONI
• «OONI Explorer — Web Connectivity, github.com, Россия (апрель–июнь 2026)». OONI

Материал обновляется!

Кстати, рассылку сложнее заблокировать. Так что каждую неделю мы рассказываем о самом важном в области технологий и безопасности: как уберечь свои данные, финансы и себя в условиях блокировок, шатдаунов и финансовых ограничений. Подпишитесь!