주요 속도 제한 정보
GitHub 는 특정 시간 내에 수행할 수 있는 REST API 요청 수를 제한합니다. 이 제한은 남용 및 서비스 거부 공격을 방지하고 모든 사용자가 API를 계속 사용할 수 있도록 합니다.
검색 끝점과 같은 일부 끝점의 경우 제한이 더 제한적입니다. 이러한 엔드포인트에 대한 자세한 내용은 트래픽률 제한에 대한 REST API 엔드포인트을(를) 참조하세요. GraphQL API에는 별도의 기본 트래픽률 제한도 있습니다. GraphQL API에 대한 속도 제한 및 쿼리 제한을(를) 참조하세요.
일반적으로 아래 설명된 대로 인증 방법에 따라 REST API에 대한 기본 트래픽률 제한을 계산할 수 있습니다.
미인증 사용자에 대한 기본 트래픽률 제한
퍼블릭 데이터만 가져오는 경우 인증되지 않은 요청을 수행할 수 있습니다. 인증되지 않은 요청은 요청을 한 사용자 또는 애플리케이션이 아닌 발신 IP 주소와 연결됩니다.
인증되지 않은 요청에 대한 기본 트래픽률 제한은 시간당 60개입니다.
인증 사용자에 대한 기본 트래픽률 제한
personal access token을(를) 사용하여 API 요청을 수행할 수 있습니다. 또한, 사용자를 대신하여 API 요청을 수행할 수 있는 GitHub App 또는 OAuth app을(를) 승인할 수도 있습니다.
이러한 모든 요청은 시간당 요청 5,000개의 개인 트래픽률 제한에 포함됩니다. GitHub Enterprise Cloud 조직이 소유한 GitHub App이(가) 사용자를 대신하여 요청하는 요청에는 시간당 15,000개의 더 높은 트래픽률 제한이 적용됩니다. 마찬가지로, OAuth app이(가) 소유하거나 승인한 경우, GitHub Enterprise Cloud 조직의 구성원이라면 해당 앱이 대신으로 수행한 요청은 시간당 15,000건까지 처리 가능한 더 높은 요청 제한이 적용됩니다. 그러나 더 높은 제한 앱의 요청은 하한 인증 방법에 사용할 수 있는 나머지 예산을 줄입니다. 예를 들어, 요청 한도가 15,000개인 앱이 사용자를 대신하여 10,000개의 요청을 하면, 앱에 5,000개의 요청이 남아 있더라도 personal access tokens에 대한 5,000개 요청의 할당량이 소진됩니다.
Git LFS 액세스의 기본 속도 제한
Git LFS 콘텐츠를 업로드하거나 다운로드하려면 API 요청이 필요합니다. 이는 인증되지 않은 요청의 경우 분당 300개 요청, 인증된 요청의 경우 분당 3,000개 요청으로 제한되는 별도의 요금 제한 버킷으로 계산됩니다.
Git LFS는 기본적으로 API 요청당 100개의 Git LFS 개체를 처리하는 일괄 처리 API를 사용합니다. 즉, 인증되지 않은 사용자는 분당 30,000개의 Git LFS 개체를 다운로드할 수 있으며 인증된 사용자는 분당 300,000개의 Git LFS 개체를 업로드/다운로드할 수 있습니다.
설치에 대한 GitHub App 기본 속도 제한
설치 액세스 토큰으로 인증하는 GitHub Apps은(는) 설치의 최소 트래픽률 제한인 시간당 5,000개 요청을 사용합니다. GitHub Enterprise Cloud 조직에 설치된 경우 설치의 트래픽률 제한은 시간당 15,000개 요청입니다.
GitHub Enterprise Cloud 조직 외에 설치된 경우 설치의 트래픽률 제한은 사용자 및 리포지토리 수에 따라 조정됩니다. 리포지토리가 20개를 초과하는 설치는 각 리포지토리에 대해 시간당 50개의 요청을 추가로 받습니다. 사용자 수가 20명을 초과하는 조직에 대한 설치의 경우 각 사용자에 대해 시간당 50개의 요청을 추가로 수신할 수 있습니다. 트래픽률 제한은 시간당 12,500개 요청을 초과할 수 없습니다.
GitHub App 사용자 액세스 토큰에 대한 기본 트래픽률 제한은(설치 액세스 토큰과는 달리) 인증된 사용자의 기본 트래픽률 제한에 따라 결정됩니다. 이 트래픽률 제한은 해당 사용자를 대신하여 다른 GitHub App 또는 OAuth app이(가) 수행하는 모든 요청 및 사용자가 personal access token(으)로 수행하는 모든 요청과 합산됩니다. 자세한 내용은 REST API에 대한 트래픽률 제한을(를) 참조하세요.
에 대한 기본 속도 제한 OAuth apps
OAuth app에서 생성된 OAuth 액세스 토큰의 기본 속도 제한은 인증된 사용자에 대한 기본 속도 제한에 의해 결정됩니다. 이 제한 속도는 다른 GitHub App 또는 OAuth app가 해당 사용자를 대신하여 수행하는 모든 요청 및 사용자가 personal access token를 사용하여 수행하는 모든 요청과 결합됩니다. 인증 사용자에 대한 기본 트래픽률 제한을 참조하세요.
OAuth 앱은 클라이언트 ID 및 클라이언트 암호를 사용하여 퍼블릭 데이터를 가져올 수도 있습니다. 예시:
curl -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET -I https://api.github.com/meta
이러한 요청의 경우 트래픽률 제한은 OAuth app당 시간당 5,000개 요청입니다. GitHub Enterprise Cloud 조직이 소유한 앱의 경우 트래픽률 제한은 시간당 15,000개 요청입니다.
참고
클라이언트 쪽 코드나 사용자 디바이스에서 실행되는 코드에 앱의 클라이언트 암호를 포함하지 마세요. 클라이언트 암호를 사용하여 앱에 권한을 부여한 사용자에 대한 OAuth 액세스 토큰을 생성할 수 있으므로 클라이언트 암호는 항상 안전하게 유지되어야 합니다.
GITHUB_TOKEN의 GitHub Actions에서의 기본 속도 제한
기본 제공 GITHUB_TOKEN 을 사용하여 워크플로에서 GitHub Actions 요청을 인증할 수 있습니다.
워크플로에서 인증에 GITHUB_TOKEN 사용을(를) 참조하세요.
GITHUB_TOKEN에 대한 트래픽률 제한은 리포지토리당 시간당 1,000개 요청입니다. GitHub Enterprise Cloud 계정에 속한 리소스에 대한 요청의 경우, 제한은 리포지토리당 시간당 15,000개 요청입니다.
보조 요율 제한에 대한 정보
GitHub은(는) 기본 트래픽률 제한 외에도 남용을 방지하고 모든 사용자가 사용할 수 있는 API를 유지하기 위해 보조 트래픽률 제한을 적용합니다.
다음과 같은 경우 보조 속도 제한에 걸릴 수 있습니다.
- 동시 요청이 너무 많습니다. 동시 요청은 100개 이하로 허용됩니다. 이 제한은 REST API 및 GraphQL API에서 공유됩니다.
- 분당 단일 엔드포인트에 너무 많은 요청을 만듭니다. REST API 엔드포인트에는 분당 900포인트를 초과할 수 없고 GraphQL API 엔드포인트에는 분당 2,000포인트를 초과할 수 없습니다. 포인트에 대한 자세한 내용은 보조 트래픽률 제한에 대한 포인트 계산을 참조하세요.
- 너무 많은 분당 요청을 만듭니다. 실시간 60초당 CPU 시간은 90초를 초과할 수 없습니다. GraphQL API에는 이 CPU 시간이 60초 이하일 수 있습니다. API 요청에 대한 총 응답 시간을 측정하여 CPU 시간을 대략적으로 예측할 수 있습니다.
- 짧은 기간 동안 과도한 컴퓨팅 리소스를 사용하는 요청을 너무 많이 만듭니다.
- 짧은 시간 안에 GitHub에 너무 많은 콘텐츠를 만듭니다. 일반적으로 분당 80개 이하의 콘텐츠 생성 요청과 시간당 500개 이하의 콘텐츠 생성 요청이 허용됩니다. 일부 엔드포인트는 콘텐츠 만들기 제한이 더 낮습니다. 콘텐츠 만들기 제한에는 GitHub 웹 인터페이스뿐만 아니라 REST API 및 GraphQL API를 통해 수행되는 작업이 포함됩니다.
- 짧은 시간 안에 너무 많은 OAuth 액세스 토큰 요청을 만듭니다. GitHub Apps 및 OAuth apps에 대해 시간당 2,000개 이상의 OAuth 액세스 토큰 요청이 허용되지 않습니다.
이러한 보조 요금 제한은 예고 없이 변경될 수 있습니다. 공개되지 않은 이유로 보조 속도 제한이 발생할 수도 있습니다.
보조 트래픽률 제한에 대한 포인트 계산
일부 보조 트래픽률 제한은 요청의 포인트 값에 따라 결정됩니다. GraphQL 요청의 경우 이러한 포인트 값은 기본 트래픽률 제한에 대한 포인트 값 계산과 별개입니다.
| 요청 | 포인트 |
|---|---|
| 변형이 없는 GraphQL 요청 | 1 |
| 변형이 있는 GraphQL 요청 | 5 |
대부분의 REST API GET, HEAD 및 OPTIONS 요청 | 1 |
대부분의 REST API POST, PATCH, PUT 또는 DELETE 요청 | 5 |
일부 REST API 엔드포인트에는 공개적으로 공유되지 않는 다른 포인트 비용이 있습니다.
속도 제한 상태 확인하기
각 응답과 함께 전송되는 헤더를 사용하여 기본 트래픽률 제한의 현재 상태를 확인할 수 있습니다.
| 헤더 이름 | 설명 |
|---|---|
x-ratelimit-limit | 시간당 수행할 수 있는 최대 요청 수 |
x-ratelimit-remaining | 현재 트래픽률 제한 창의 잔여 요청 수 |
x-ratelimit-used | 현재 트래픽률 제한 창에서 수행한 요청 수 |
x-ratelimit-reset | 현재 트래픽률 제한 창이 UTC Epoch 초 단위로 재설정되는 시간 |
x-ratelimit-resource | 요청이 대상으로 삼은 속도 제한 리소스. 다른 리소스에 대한 자세한 내용은 트래픽률 제한에 대한 REST API 엔드포인트을(를) 참조하세요. |
GET /rate_limit 끝점을 호출하여 트래픽률 제한을 확인할 수도 있습니다. 이 끝점을 호출하는 것은 기본 트래픽률 제한에 포함되지 않지만, 보조 트래픽률 제한에는 포함될 수 있습니다.
트래픽률 제한에 대한 REST API 엔드포인트을(를) 참조하세요. 가능하면 API를 호출하는 대신 트래픽률 제한 응답 헤더를 사용하여 트래픽률 제한을 확인하는 것이 좋습니다.
보조 레이트 제한의 상태를 확인할 수 있는 방법은 없습니다.
속도 제한 초과
기본 트래픽률 제한을 초과하면 403 또는 429 응답을 수신하며, x-ratelimit-remaining 헤더가 0이 됩니다.
x-ratelimit-reset 헤더에 지정된 시간이 경과하지 전까지 요청을 다시 시도해서는 안 됩니다.
보조 트래픽률 제한을 초과하는 경우 보조 트래픽률 제한을 초과했음을 나타내는 오류 메시지 및 403 또는 429 응답이 표시됩니다.
retry-after 응답 헤더가 있는 경우 몇 초가 경과할 때까지 요청을 다시 시도하면 안 됩니다.
x-ratelimit-remaining 헤더가 0인 경우 x-ratelimit-reset 헤더로 지정된 시간(UTC epoch 초)까지 요청을 다시 시도해서는 안 됩니다. 그렇지 않은 경우 다시 시도하기 전에 1분 이상 기다립니다. 보조 트래픽 속도 제한 때문에 요청이 지속적으로 실패할 경우, 재시도 간격을 기하급수적으로 늘려가며 대기하고, 일정 횟수 이상 재시도해도 실패하면 오류를 발생시킵니다.
트래픽률이 제한된 동안 요청을 계속하면 통합이 금지될 수 있습니다.
속도 제한 내에 머물기
사용량 제한을 넘지 않도록 모범 사례를 따라야 합니다. REST API 사용에 대한 모범 사례을(를) 참조하세요.
더 높은 트래픽률 제한 가져오기
더 높은 기본 트래픽률 제한을 원하는 경우 미인증 요청이 아닌 인증된 요청을 생성하는 좋습니다. 인증된 요청은 미인증 요청보다 트래픽률 제한이 훨씬 높습니다.
조직에서 자동화를 위해 personal access token을(를) 사용하는 경우, 대신 GitHub App이(가) 잘 작동하는지 고려해 보십시오. 설치 액세스 토큰 사용에 대한 GitHub Apps 속도 제한은 리포지토리 수와 조직 사용자 수로 확장됩니다. GitHub 앱 만들기 정보을(를) 참조하세요.
GitHub Apps 또는 OAuth apps을(를) 사용 중이라면 GitHub Enterprise Cloud으로 업그레이드하는 것을 고려해 보세요. GitHub Apps 또는 OAuth apps 사용하는 GitHub Enterprise Cloud조직에 대해 더 높은 속도 제한이 있습니다.