Maven Central ограничивает пропускную способность: что важно знать в 2025 году

Команда Spring АйО подготовила статью про Rate Limit в Maven Central — один из тех инфраструктурных проектов, без которых современная JVM-экосистема уже немыслима. Здесь живёт подавляющее большинство библиотек и инструментов для Java, Kotlin, Scala и Android. После закрытия JCenter в 2021 году он окончательно стал де-факто центральным публичным репозиторием, куда в итоге попадает практически каждая новая библиотека.

В 2024 году объём скачиваний из Maven Central вырос на десятки процентов, достигнув астрономических масштабов. При этом финансирование и поддержку инфраструктуры обеспечивает компания Sonatype, которая отвечает за проверку и публикацию артефактов, стабильность, безопасность и доступность сервиса для всего мира.

Проблема: «трагедия общин» в действии

По данным Sonatype, 83 % трафика формирует всего 1 % IP-адресов, и чаще всего это крупнейшие компании и их CI/CD-системы. Во многих случаях они не используют кеширование или делают слишком много уникальных запросов — например, при сборках в контейнерах, которые скачивают зависимости заново каждый раз.

Эта ситуация наглядно иллюстрирует «трагедию общин»: небольшой процент участников чрезмерно использует общий ресурс, что создаёт нагрузку на инфраструктуру и в перспективе способно снизить качество сервиса для всех.

Решение: rate limits и троттлинг

Чтобы сохранить устойчивость работы Maven Central, Sonatype внедрила ограничения пропускной способности для самых ресурсоёмких пользователей.
Это включает:

• Замедление отдачи (throttling) при большом числе запросов.

• HTTP 429 Too Many Requests при явном превышении порогов.

• Организационные лимиты — поведенческий анализ трафика позволяет применять ограничения к целой организации, даже если запросы распределены по множеству IP.

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

Как избежать проблем

Sonatype и сообщество рекомендуют несколько простых шагов:

• Используйте кеширующие прокси-репозитории (Nexus Repository, Artifactory, JFrog, Gradle Enterprise).

<mirrors>     <mirror>         <id>internal-nexus</id>         <mirrorOf>*</mirrorOf>         <url>https://nexus.company.com/repository/maven-all/</url>     </mirror> </mirrors>

Это снизит обращения в Maven Central в десятки раз.

• Кэшируйте зависимости в CI/CD: в GitHub Actions — через actions/cache для .m2/repository, в других системах — аналогичные механизмы.

GitHub Actions (Maven):

- name: Cache Maven packages   uses: actions/cache@v4   with:     path: ~/.m2/repository     key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}     restore-keys: |       ${{ runner.os }}-maven-

GitHub Actions (Gradle):

- name: Cache Gradle packages   uses: actions/cache@v4   with:     path: |       ~/.gradle/caches       ~/.gradle/wrapper     key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}     restore-keys: |       ${{ runner.os }}-gradle-

• Минимизируйте запросы к SNAPSHOT-ам и не скачивайте лишние версии.

<repositories>     <repository>         <id>snapshots</id>         <url>https://oss.sonatype.org/content/repositories/snapshots</url>         <snapshots>             <updatePolicy>daily</updatePolicy>         </snapshots>     </repository> </repositories>

Вместо always используйте daily или interval:X.

• Не удаляйте локальный кеш без необходимости.

Даже в CI не всегда нужно «чистое окружение» — для безопасности сборок лучше использовать проверку зависимостей (OWASP Dependency-Check, Maven Enforcer), а не удаление кеша.

Эти меры не только уберегут от замедлений, но и значительно ускорят сборки.

Если вы уже попали под ограничения

Признаки — резкое падение скорости скачивания и ошибки HTTP 429 Too Many Requests в логах сборки.
В таком случае Sonatype советует:

• Проверить настройки кеша и оптимизировать запросы.

• Связаться с ними через mavencentral@sonatype.com — в некоторых случаях они предлагают выделенные каналы или зеркала для крупных организаций.

Итог: ограничения в Maven Central — это не попытка «закрутить гайки», а способ сохранить ресурс, который обслуживает миллионы разработчиков по всему миру. Если вы используете кеширование и best practices, эти меры останутся для вас незаметными. А вот тем, кто без нужды гоняет сотни гигабайт зависимостей через CI, стоит срочно пересмотреть подход.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано