# Скрапинг данных GitHub за пределами лимита API: Звезды, Зависимости

API GitHub ограничивает неаутентифицированные вызовы до 60 в час и полностью скрывает зависимости и тренды. Вот как добывать важные сигналы через дешевые IP.

GitHub — это кладезь исследований: кривые принятия, динамика конкурентов, графики зависимостей, сигналы найма — и его официальный API предоставит вам часть этого бесплатно. Затем он останавливается. Неаутентифицированные вызовы ограничены 60 в час, а два набора данных, которые больше всего интересуют людей, граф зависимостей и страница трендов, вообще не входят в API. Это руководство охватывает, как **скрапить данные GitHub** за пределами этих ограничений: что дает API, что нужно читать из HTML и почему GitHub — это редкая цель, где дешевые датацентровые и IPv6 прокси являются правильным инструментом.

## Знайте пределы, прежде чем бороться с ними

Начните с API — он структурирован, одобрен и дешев по квоте, если вы аутентифицируетесь. Числа, которые формируют все: неаутентифицированные REST-запросы ограничены 60 в час, считаются по IP; аутентифицированный токен получает 5,000 в час; Search API еще более строгий — 30 запросов в минуту аутентифицированных (10 неаутентифицированных). Ключевой момент в том, что неаутентифицированный потолок считается *по IP* — именно поэтому маршрутизация чтений через множество IP увеличивает ваш запас.

```python
import requests

# Authenticated API call - watch the rate-limit headers
headers = {"Authorization": "Bearer YOUR_GH_TOKEN",
           "Accept": "application/vnd.github+json"}
r = requests.get("https://api.github.com/repos/psf/requests", headers=headers, timeout=15)
repo = r.json()
print(repo["stargazers_count"], repo["forks_count"], repo["open_issues_count"])
print("remaining this hour:", r.headers["X-RateLimit-Remaining"])
```

Используйте API для всего, что он чисто предоставляет, и используйте `git clone` для содержимого файлов — клонирование и обработка репозитория локально быстрее и мягче, чем скрапинг отдельных страниц файлов. Скрапинг HTML предназначен для сигналов, которые API ограничивает до бесполезности или полностью исключает.

## Что нужно читать из HTML

Три ценных набора данных существуют только на отрисованных страницах. **Граф зависимостей** — счетчик "Используется в" GitHub и список репозиториев, которые зависят от пакета — это один из самых сильных показателей принятия, и его нет в API. Страницы **трендов** (`github.com/trending`, фильтруемые по языку и окну) существуют только в HTML. И страницы **тем** выводят репозитории по темам гораздо полезнее, чем позволяет квота поиска. Все три — это простой серверный HTML, так что простое запрос-парсирование работает — браузер не требуется.

```python
import requests
from bs4 import BeautifulSoup

# Scrape the trending page through a datacenter proxy
PROXY = "http://USER-type-datacenter:PASS@datacenterboson.quantumproxies.io:10000"

def trending(language="python", since="daily"):
    url = f"https://github.com/trending/{language}?since={since}"
    r = requests.get(url, proxies={"https": PROXY}, timeout=20,
                     headers={"User-Agent": "Mozilla/5.0"})
    soup = BeautifulSoup(r.text, "html.parser")
    repos = []
    for row in soup.select("article.Box-row"):
        name = row.select_one("h2 a")["href"].strip("/")
        stars = row.select_one("a[href$='/stargazers']")
        repos.append({"repo": name,
                      "stars": stars.get_text(strip=True) if stars else None})
    return repos

print(trending("rust", "weekly")[:5])
```

![Лимиты GitHub REST в виде столбцов: 60 запросов в час без токена с подсчетом по IP против 5 000 с аутентифицированным токеном; карточка выделяет потолок на IP, Search API с лимитом 30 запросов в минуту и объясняет, почему распределение чтения по многим IP умножает запас.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785335184/blog/generated/qp-b9-050-diag1.png)
*Неаутентифицированный потолок считается по IP — именно это делает распределение чтений по пулу эффективным.*

## GitHub — это цель для датацентровых (и, возможно, IPv6) прокси

Вот часть, которую люди переусложняют. Публичные страницы GitHub серверно-отрисованы, снисходительны и не содержат агрессивных JavaScript вызовов — так что вам не нужны премиум жилые IP для их чтения. Это классический случай для [датацентровых прокси](https://quantumproxies.io/datacenter-proxies): дешевые, быстрые и обильные, распределенные широко, чтобы ни один IP не приближался к неаутентифицированному лимиту или не вызывал вторичного ограничения скорости. Использование жилых здесь — это платить роскошные цены за работу, которую идеально выполняет экономичный IP. Наше руководство по [когда датацентровые прокси — правильный выбор](https://quantumproxies.io/blog/datacenter-proxies-when-to-use) объясняет именно такую снисходительную, высокопроизводительную цель.

Есть еще более дешевый вариант, который стоит протестировать: IPv6. Когда цель отвечает через IPv6, [пулы IPv6 прокси](https://quantumproxies.io/ipv6-proxies) предоставляют огромное, недорогое адресное пространство — идеально для распределения чтений, ограниченных по IP, через тысячи выходов. GitHub внедряет поддержку IPv6, так что это одна из немногих крупных целей, где это стоит проверить, а не предполагать. Протестируйте это, прежде чем принимать решение: пропустите цель через наш [бесплатный проверщик совместимости IPv6](https://quantumproxies.io/ipv6-compatibility-checker) и прочитайте экономику в нашем [полном руководстве по прокси IPv6](https://quantumproxies.io/blog/ipv6-proxies-complete-guide).

[Получите быстрые датацентровые прокси для GitHub](https://quantumproxies.io/datacenter-proxies)

## Учитывайте вторичное ограничение скорости

Потолки по часам — не единственные ограничения, с которыми вы столкнетесь. GitHub также запускает обнаружение злоупотреблений, которое реагирует на резкий, высококонкурентный или подозрительно регулярный трафик — так что даже если вы находитесь под числовым лимитом, интенсивные запросы с одного IP могут привести к временному блокированию. Защиты те же, что делают вас вежливым клиентом: ограничьте конкурентность, добавьте немного случайности между запросами, уважайте любой заголовок `Retry-After`, который сервер вам передает, и распределяйте нагрузку, чтобы ни один выход не имел беглого паттерна. Это настоящая причина, почему широкий пул важен — это не только арифметика 60 в час, это то, что ни один индивидуальный IP не должен выглядеть как сбой скрипта. Отступите при первом 403 или замедлении, а не повторяйте сразу в более длительный бан.

## Преобразование данных репозитория в информацию о разработке

Суть всего этого — аналитический слой. Отслеживайте скорость звезд и количество зависимостей библиотеки конкурента с течением времени, и вы наблюдаете принятие в реальном времени. Сравнивайте страницы трендов по языкам неделю за неделей, чтобы заметить растущие инструменты до того, как они станут очевидными. Извлекайте списки участников, чтобы оценить размер команды и сигналы найма. Комбинируйте разбивки по языкам по теме, чтобы картировать всю экосистему. Снимайте снимки репозиториев по расписанию, сохраняйте каждую запись с временной меткой, и дельты становятся продуктом — динамика, а не одно число. Однократное чтение 40,000 звезд — это тривиальность; тот же репозиторий, добавляющий 2,000 звезд в неделю, пока его количество зависимостей растет, — это настоящий сигнал принятия, на который вы можете действовать до того, как его заметит более широкий рынок.

```python
import requests
from bs4 import BeautifulSoup

# The 'Used by' dependents count - a top adoption signal, HTML-only
def used_by(owner, repo):
    url = f"https://github.com/{owner}/{repo}/network/dependents"
    proxy = "http://USER-type-datacenter:PASS@datacenterboson.quantumproxies.io:10000"
    r = requests.get(url, proxies={"https": proxy}, timeout=20,
                     headers={"User-Agent": "Mozilla/5.0"})
    soup = BeautifulSoup(r.text, "html.parser")
    tab = soup.select_one("a.btn-link.selected")
    return tab.get_text(strip=True) if tab else None

print(used_by("pallets", "flask"))   # e.g. '1.4m Repositories'
```

Одна привычка держит затраты в разумных пределах при большом объеме: запрашивайте только то, что вам нужно. Страницы репозиториев легковесны, но если вы расширяетесь до тысяч репозиториев, блокируйте активы и повторно используйте соединения — наши заметки о [сокращении затрат на пропускную способность прокси](https://quantumproxies.io/blog/reduce-proxy-bandwidth-costs-scraping) применимы даже к дешевой цели, потому что выигрыш накапливается.

![Три типа прокси на шкале стоимости для скрапинга GitHub: жилые наверху как избыточные, датацентровые как правильный инструмент, IPv6 самые дешевые после проверки; карточка подводит итог: датацентровые дешевы, быстры и доступны в изобилии, IPv6 дает огромное адресное пространство, жилые нужны для более сложных сайтов.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785335184/blog/generated/qp-b9-050-diag2.png)
*Для снисходительной публичной цели датацентровые и IPv6 IP выигрывают по стоимости; жилые — это излишество, которое вы сохраняете для более сложных сайтов.*

## Часто задаваемые вопросы

### Каков лимит скорости API GitHub?

Неаутентифицированные REST-запросы ограничены 60 в час, считаются по IP-адресу. Аутентифицированный токен повышает это до 5,000 в час. Search API отдельный и более строгий — 30 запросов в минуту аутентифицированных, 10 неаутентифицированных. Поскольку неаутентифицированный лимит действует на IP, распределение чтений через пул прокси — это эффективный способ масштабирования сбора.

### Могу ли я скрапить данные GitHub, которые API не предоставляет?

Да. Граф зависимостей ("Используется в"), страницы трендов, списки тем и временные шкалы звезд — это только HTML или сильно ограниченные по квоте через API. Это простые серверно-отрисованные страницы, так что запрос-парсирование с BeautifulSoup работает без браузера. Маршрутизируйте через датацентровые прокси и распределяйте чтения, чтобы оставаться ниже вторичных ограничений скорости.

### Нужны ли мне жилые прокси для GitHub?

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

### Должен ли я использовать git clone или скрапить страницы файлов?

Клонируйте для содержимого файлов. Запуск `git clone` и обработка репозитория локально быстрее, мягче для GitHub и полностью избегает ограничений скорости на файл. Оставьте HTML-скрапинг и API для метаданных и сигналов — звезд, зависимостей, трендов, участников — которые вы не можете получить из самих проверенных файлов.

GitHub вознаграждает многослойный подход: API, где он щедр, git clone для файлов и HTML-скрапинг для сигналов принятия, которые он скрывает — все распределено по дешевым IP, чтобы ни один адрес не достигал стены 60 в час. Тестируйте на IPv6, полагайтесь на датацентровые пулы, и вся платформа становится живым набором данных экосистемы разработчиков.

[Попробуйте IPv6 прокси для высокообъемных чтений GitHub](https://quantumproxies.io/ipv6-proxies)