사용자 및 IP 속도 제한

요약

속도 제한은 웹 애플리케이션의 보안과 내구성을 향상시키는 데 사용되는 일반적인 기술입니다. 다음 제한은 기본적으로 비활성화됩니다: 기본적으로 모든 Git 작업은 먼저 인증 없이 시도됩니다. API 요청에 대한 속도 제한은 프론트엔드에서 만들어진 요청에는 영향을 미치지 않습니다.

속도 제한은 웹 애플리케이션의 보안과 내구성을 향상시키는 데 사용되는 일반적인 기술입니다. 자세한 내용은 속도 제한을 참조하세요.

다음 제한은 기본적으로 비활성화됩니다:

인증되지 않은 API 요청(IP당).
인증되지 않은 웹 요청(IP당).
인증된 API 요청(사용자당).
인증된 웹 요청(사용자당).

Note

기본적으로 모든 Git 작업은 먼저 인증 없이 시도됩니다. 이 때문에 HTTP Git 작업이 인증되지 않은 요청에 대해 구성된 속도 제한을 트리거할 수 있습니다.

API 요청에 대한 속도 제한은 프론트엔드에서 만들어진 요청에는 영향을 미치지 않습니다. 이러한 요청은 항상 웹 트래픽으로 계산됩니다.

사전 요구 사항#

관리자 액세스 권한이 있어야 합니다.

인증되지 않은 API 요청 속도 제한 활성화#

인증되지 않은 API 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증되지 않은 API 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. IP당 속도 제한 기간당 최대 인증되지 않은 API 요청 수 값을 업데이트합니다. 기본값은 3600입니다.
- 선택 사항. 인증되지 않은 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

인증되지 않은 웹 요청 속도 제한 활성화#

인증되지 않은 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증되지 않은 웹 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. IP당 속도 제한 기간당 최대 인증되지 않은 웹 요청 수 값을 업데이트합니다. 기본값은 3600입니다.
- 선택 사항. 인증되지 않은 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

인증된 API 요청 속도 제한 활성화#

인증된 API 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증된 API 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. 사용자당 속도 제한 기간당 최대 인증된 API 요청 수 값을 업데이트합니다. 기본값은 7200입니다.
- 선택 사항. 인증된 API 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

인증된 웹 요청 속도 제한 활성화#

인증된 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증된 웹 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. 사용자당 속도 제한 기간당 최대 인증된 웹 요청 수 값을 업데이트합니다. 기본값은 7200입니다.
- 선택 사항. 인증된 웹 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

사용자 정의 속도 제한 응답 사용#

속도 제한을 초과한 요청은 429 응답 코드와 기본적으로 Retry later인 일반 텍스트 본문을 반환합니다.

사용자 정의 응답을 사용하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
속도 제한에 도달한 클라이언트에 보낼 일반 텍스트 응답 텍스트 상자에 일반 텍스트 응답 메시지를 추가합니다.

분당 `project/:id/jobs`에 대한 최대 인증된 요청#

히스토리

GitLab 16.5에서 도입되었습니다.

타임아웃을 줄이기 위해 project/:id/jobs 엔드포인트에는 인증된 사용자당 기본 속도 제한인 600개 호출이 있습니다.

최대 요청 수를 수정하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
분당 project/:id/jobs에 대한 최대 인증된 요청 값을 업데이트합니다.

응답 헤더#

응답 헤더에는 모든 요청에 대한 속도 제한 정보가 포함됩니다. 이 헤더를 사용하여 사용량을 사전에 모니터링하고 요청 패턴을 조정하여 스로틀링을 방지합니다.

다중 속도 제한 시스템#

속도 제한은 두 개의 독립적인 시스템을 통해 적용됩니다:

Rack::Attack 미들웨어 속도 제한: HTTP 계층에서 적용됩니다. 예로는 사용자당 인증된 API 요청, IP당 인증되지 않은 웹 요청이 있습니다. 이 제한은 응답 헤더에 반영됩니다.
애플리케이션 속도 제한: 애플리케이션 수준에서 적용됩니다. 예로는 사용자당 이슈 생성, 사용자당 프로젝트 내보내기가 있습니다. 이 제한은 응답 헤더에 포함되지 않습니다.

단일 요청이 두 유형의 속도 제한 모두에 동시에 포함될 수 있습니다. 응답 헤더는 가장 제한적인 Rack::Attack 속도 제한 상태만 표시합니다.

Note

애플리케이션 속도 제한은 응답 헤더에 포함되지 않습니다.

예시#

API를 통해 이슈를 만드는 요청은 다음에 포함됩니다:

인증된 API 요청 속도 제한(Rack::Attack). 응답 헤더에 포함됩니다.
이슈 생성 속도 제한(애플리케이션 수준). 응답 헤더에 포함되지 않습니다.

이슈 생성 제한을 초과하면 이전 응답 헤더에서 충분한 인증된 API 요청이 남아 있다고 표시되더라도 429 응답이 발생합니다.

모든 요청에 반환되는 헤더#

다음 헤더는 클라이언트가 속도 제한 상태를 추적하는 데 도움이 되도록 모든 응답에 포함됩니다:

헤더	예시	설명
`RateLimit-Limit`	`60`	클라이언트의 분당 요청 할당량. 관리자 영역에 설정된 속도 제한 기간이 1분과 다른 경우 이 헤더의 값은 가장 가까운 60분 기간에 맞게 조정됩니다.
`RateLimit-Name`	`throttle_authenticated_api`	요청에 적용된 스로틀 이름.
`RateLimit-Observed`	`67`	시간 창에서 클라이언트와 연결된 요청 수.
`RateLimit-Remaining`	`33`	시간 창의 남은 할당량. `RateLimit-Limit` - `RateLimit-Observed`의 결과.
`RateLimit-Reset`	`1609844400`	요청 할당량이 재설정되는 Unix time 형식의 시간.

스로틀된 요청에 대한 추가 헤더#

클라이언트가 속도 제한을 초과(HTTP 상태 429)하면 다음 추가 헤더가 포함됩니다:

헤더	예시	설명
`RateLimit-ResetTime`	`Tue, 05 Jan 2021 11:00:00 GMT`	요청 할당량이 재설정되는 RFC2616 형식의 날짜 및 시간.
`Retry-After`	`30`	할당량이 재설정될 때까지의 남은 기간(초). 이는 표준 HTTP 헤더입니다.

HTTP 헤더를 사용하여 속도 제한 우회#

조직의 필요에 따라 속도 제한을 활성화하되 일부 요청은 속도 제한기를 우회하도록 할 수 있습니다.

이를 위해 사용자 정의 헤더로 속도 제한기를 우회해야 하는 요청을 표시할 수 있습니다. 이는 GitLab 앞에 있는 로드 밸런서 또는 역방향 프록시에서 수행해야 합니다. 예를 들어:

우회 헤더의 이름을 선택합니다. 예를 들어 Gitlab-Bypass-Rate-Limiting.
GitLab 속도 제한을 우회해야 하는 요청에 Gitlab-Bypass-Rate-Limiting: 1을 설정하도록 로드 밸런서를 구성합니다.
다음 중 하나를 위해 로드 밸런서를 구성합니다:
- Gitlab-Bypass-Rate-Limiting을 지웁니다.
- 속도 제한의 영향을 받아야 하는 모든 요청에 Gitlab-Bypass-Rate-Limiting을 1 이외의 값으로 설정합니다.
환경 변수 GITLAB_THROTTLE_BYPASS_HEADER를 설정합니다.
- Linux 패키지 설치의 경우 gitlab_rails['env']에서 'GITLAB_THROTTLE_BYPASS_HEADER' => 'Gitlab-Bypass-Rate-Limiting'을 설정합니다.
- 소스에서 컴파일한 설치의 경우 /etc/default/gitlab에서 export GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limiting을 설정합니다.

로드 밸런서가 모든 수신 트래픽에서 우회 헤더를 지우거나 덮어써야 한다는 것이 중요합니다. 그렇지 않으면 사용자가 해당 헤더를 설정하여 GitLab 속도 제한기를 우회하지 않도록 신뢰해야 합니다.

우회는 헤더가 1로 설정된 경우에만 작동합니다.

우회 헤더로 인해 속도 제한기를 우회한 요청은 production_json.log에서 "throttle_safelist":"throttle_bypass_header"로 표시됩니다.

우회 메커니즘을 비활성화하려면 환경 변수 GITLAB_THROTTLE_BYPASS_HEADER가 설정 해제되거나 비어 있는지 확인합니다.

특정 사용자가 인증된 요청 속도 제한을 우회하도록 허용#

이전에 설명한 우회 헤더와 유사하게 특정 사용자 집합이 속도 제한기를 우회하도록 허용할 수 있습니다. 이는 인증된 요청에만 적용됩니다. 인증되지 않은 요청에서는 정의상 GitLab이 사용자가 누구인지 알 수 없습니다.

허용 목록은 GITLAB_THROTTLE_USER_ALLOWLIST 환경 변수의 쉼표로 구분된 사용자 ID 목록으로 구성됩니다. 사용자 1, 53, 217이 인증된 요청 속도 제한기를 우회하도록 하려면 허용 목록 구성이 1,53,217이 됩니다.

Linux 패키지 설치의 경우 gitlab_rails['env']에서 'GITLAB_THROTTLE_USER_ALLOWLIST' => '1,53,217'을 설정합니다.
소스에서 컴파일한 설치의 경우 /etc/default/gitlab에서 export GITLAB_THROTTLE_USER_ALLOWLIST=1,53,217을 설정합니다.

사용자 허용 목록으로 인해 속도 제한기를 우회한 요청은 production_json.log에서 "throttle_safelist":"throttle_user_allowlist"로 표시됩니다.

애플리케이션 시작 시 허용 목록이 auth.log에 기록됩니다.

적용하기 전에 스로틀 설정 시험 사용#

GITLAB_THROTTLE_DRY_RUN 환경 변수를 쉼표로 구분된 스로틀 이름 목록으로 설정하여 스로틀 설정을 시험할 수 있습니다.

가능한 이름은 다음과 같습니다:

throttle_unauthenticated
- GitLab 14.3에서 더 이상 사용되지 않음으로 표시되었습니다. 대신 throttle_unauthenticated_api 또는 throttle_unauthenticated_web을 사용합니다. throttle_unauthenticated는 여전히 지원되며 두 가지 모두 선택합니다.
throttle_unauthenticated_api
throttle_unauthenticated_web
throttle_authenticated_api
throttle_authenticated_web
throttle_unauthenticated_protected_paths
throttle_authenticated_protected_paths_api
throttle_authenticated_protected_paths_web
throttle_unauthenticated_packages_api
throttle_authenticated_packages_api
throttle_authenticated_git_lfs
throttle_unauthenticated_files_api
throttle_authenticated_files_api
throttle_unauthenticated_deprecated_api
throttle_authenticated_deprecated_api
throttle_unauthenticated_git_http
throttle_authenticated_git_http

예를 들어 보호되지 않은 경로에 대한 모든 인증된 요청에 대해 스로틀을 시험하려면 GITLAB_THROTTLE_DRY_RUN='throttle_authenticated_web,throttle_authenticated_api'를 설정합니다.

모든 스로틀에 대해 dry run 모드를 활성화하려면 변수를 *로 설정할 수 있습니다.

스로틀을 dry run 모드로 설정하면 제한에 도달했을 때 auth.log에 메시지가 기록되면서 요청이 계속됩니다. 로그 메시지에는 env 필드가 track으로 설정됩니다. matched 필드에는 적중한 스로틀의 이름이 포함됩니다.

설정에서 속도 제한을 활성화하기 전에 환경 변수를 설정하는 것이 중요합니다. 관리자 영역의 설정은 즉시 적용되는 반면, 환경 변수를 설정하려면 모든 Puma 프로세스를 재시작해야 합니다.

문제 해결#

실수로 관리자를 잠근 후 스로틀 비활성화#

많은 사용자가 동일한 프록시 또는 네트워크 게이트웨이를 통해 GitLab에 연결하는 경우 속도 제한이 너무 낮으면 GitLab이 스로틀을 트리거한 요청과 동일한 IP를 사용하는 것으로 보기 때문에 해당 제한으로 관리자도 잠길 수 있습니다.

관리자는 Rails 콘솔을 사용하여 GITLAB_THROTTLE_DRY_RUN 변수에 나열된 것과 동일한 제한을 비활성화할 수 있습니다. 예를 들어:

Gitlab::CurrentSettings.update!(throttle_authenticated_web_enabled: false)

이 예시에서 throttle_authenticated_web 매개변수는 _enabled 이름 접미사를 가집니다.

제한에 대한 숫자 값을 설정하려면 _enabled 이름 접미사를 _period_in_seconds 및 _requests_per_period 접미사로 교체합니다.

사용자 및 IP 속도 제한

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-05-22

요약

속도 제한은 웹 애플리케이션의 보안과 내구성을 향상시키는 데 사용되는 일반적인 기술입니다. 자세한 내용은 속도 제한을 참조하세요.

다음 제한은 기본적으로 비활성화됩니다:

인증되지 않은 API 요청(IP당).
인증되지 않은 웹 요청(IP당).
인증된 API 요청(사용자당).
인증된 웹 요청(사용자당).

Note

API 요청에 대한 속도 제한은 프론트엔드에서 만들어진 요청에는 영향을 미치지 않습니다. 이러한 요청은 항상 웹 트래픽으로 계산됩니다.

사전 요구 사항#

관리자 액세스 권한이 있어야 합니다.

인증되지 않은 API 요청 속도 제한 활성화#

인증되지 않은 API 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증되지 않은 API 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. IP당 속도 제한 기간당 최대 인증되지 않은 API 요청 수 값을 업데이트합니다. 기본값은 3600입니다.
- 선택 사항. 인증되지 않은 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

인증되지 않은 웹 요청 속도 제한 활성화#

인증되지 않은 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증되지 않은 웹 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. IP당 속도 제한 기간당 최대 인증되지 않은 웹 요청 수 값을 업데이트합니다. 기본값은 3600입니다.
- 선택 사항. 인증되지 않은 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

인증된 API 요청 속도 제한 활성화#

인증된 API 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증된 API 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. 사용자당 속도 제한 기간당 최대 인증된 API 요청 수 값을 업데이트합니다. 기본값은 7200입니다.
- 선택 사항. 인증된 API 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

인증된 웹 요청 속도 제한 활성화#

인증된 요청 속도 제한을 활성화하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
인증된 웹 요청 속도 제한 활성화를 선택합니다.
- 선택 사항. 사용자당 속도 제한 기간당 최대 인증된 웹 요청 수 값을 업데이트합니다. 기본값은 7200입니다.
- 선택 사항. 인증된 웹 속도 제한 기간(초) 값을 업데이트합니다. 기본값은 3600입니다.

사용자 정의 속도 제한 응답 사용#

속도 제한을 초과한 요청은 429 응답 코드와 기본적으로 Retry later인 일반 텍스트 본문을 반환합니다.

사용자 정의 응답을 사용하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
속도 제한에 도달한 클라이언트에 보낼 일반 텍스트 응답 텍스트 상자에 일반 텍스트 응답 메시지를 추가합니다.

분당 `project/:id/jobs`에 대한 최대 인증된 요청#

히스토리

GitLab 16.5에서 도입되었습니다.

타임아웃을 줄이기 위해 project/:id/jobs 엔드포인트에는 인증된 사용자당 기본 속도 제한인 600개 호출이 있습니다.

최대 요청 수를 수정하려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
사용자 및 IP 속도 제한을 확장합니다.
분당 project/:id/jobs에 대한 최대 인증된 요청 값을 업데이트합니다.

응답 헤더#

다중 속도 제한 시스템#

속도 제한은 두 개의 독립적인 시스템을 통해 적용됩니다:

Rack::Attack 미들웨어 속도 제한: HTTP 계층에서 적용됩니다. 예로는 사용자당 인증된 API 요청, IP당 인증되지 않은 웹 요청이 있습니다. 이 제한은 응답 헤더에 반영됩니다.
애플리케이션 속도 제한: 애플리케이션 수준에서 적용됩니다. 예로는 사용자당 이슈 생성, 사용자당 프로젝트 내보내기가 있습니다. 이 제한은 응답 헤더에 포함되지 않습니다.

단일 요청이 두 유형의 속도 제한 모두에 동시에 포함될 수 있습니다. 응답 헤더는 가장 제한적인 Rack::Attack 속도 제한 상태만 표시합니다.

Note

애플리케이션 속도 제한은 응답 헤더에 포함되지 않습니다.

예시#

API를 통해 이슈를 만드는 요청은 다음에 포함됩니다:

인증된 API 요청 속도 제한(Rack::Attack). 응답 헤더에 포함됩니다.
이슈 생성 속도 제한(애플리케이션 수준). 응답 헤더에 포함되지 않습니다.

이슈 생성 제한을 초과하면 이전 응답 헤더에서 충분한 인증된 API 요청이 남아 있다고 표시되더라도 429 응답이 발생합니다.

모든 요청에 반환되는 헤더#

다음 헤더는 클라이언트가 속도 제한 상태를 추적하는 데 도움이 되도록 모든 응답에 포함됩니다:

헤더	예시	설명
`RateLimit-Limit`	`60`	클라이언트의 분당 요청 할당량. 관리자 영역에 설정된 속도 제한 기간이 1분과 다른 경우 이 헤더의 값은 가장 가까운 60분 기간에 맞게 조정됩니다.
`RateLimit-Name`	`throttle_authenticated_api`	요청에 적용된 스로틀 이름.
`RateLimit-Observed`	`67`	시간 창에서 클라이언트와 연결된 요청 수.
`RateLimit-Remaining`	`33`	시간 창의 남은 할당량. `RateLimit-Limit` - `RateLimit-Observed`의 결과.
`RateLimit-Reset`	`1609844400`	요청 할당량이 재설정되는 Unix time 형식의 시간.

스로틀된 요청에 대한 추가 헤더#

클라이언트가 속도 제한을 초과(HTTP 상태 429)하면 다음 추가 헤더가 포함됩니다:

헤더	예시	설명
`RateLimit-ResetTime`	`Tue, 05 Jan 2021 11:00:00 GMT`	요청 할당량이 재설정되는 RFC2616 형식의 날짜 및 시간.
`Retry-After`	`30`	할당량이 재설정될 때까지의 남은 기간(초). 이는 표준 HTTP 헤더입니다.

HTTP 헤더를 사용하여 속도 제한 우회#

조직의 필요에 따라 속도 제한을 활성화하되 일부 요청은 속도 제한기를 우회하도록 할 수 있습니다.

우회 헤더의 이름을 선택합니다. 예를 들어 Gitlab-Bypass-Rate-Limiting.
GitLab 속도 제한을 우회해야 하는 요청에 Gitlab-Bypass-Rate-Limiting: 1을 설정하도록 로드 밸런서를 구성합니다.
다음 중 하나를 위해 로드 밸런서를 구성합니다:
- Gitlab-Bypass-Rate-Limiting을 지웁니다.
- 속도 제한의 영향을 받아야 하는 모든 요청에 Gitlab-Bypass-Rate-Limiting을 1 이외의 값으로 설정합니다.
환경 변수 GITLAB_THROTTLE_BYPASS_HEADER를 설정합니다.
- Linux 패키지 설치의 경우 gitlab_rails['env']에서 'GITLAB_THROTTLE_BYPASS_HEADER' => 'Gitlab-Bypass-Rate-Limiting'을 설정합니다.
- 소스에서 컴파일한 설치의 경우 /etc/default/gitlab에서 export GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limiting을 설정합니다.

우회는 헤더가 1로 설정된 경우에만 작동합니다.

우회 헤더로 인해 속도 제한기를 우회한 요청은 production_json.log에서 "throttle_safelist":"throttle_bypass_header"로 표시됩니다.

우회 메커니즘을 비활성화하려면 환경 변수 GITLAB_THROTTLE_BYPASS_HEADER가 설정 해제되거나 비어 있는지 확인합니다.

특정 사용자가 인증된 요청 속도 제한을 우회하도록 허용#

Linux 패키지 설치의 경우 gitlab_rails['env']에서 'GITLAB_THROTTLE_USER_ALLOWLIST' => '1,53,217'을 설정합니다.
소스에서 컴파일한 설치의 경우 /etc/default/gitlab에서 export GITLAB_THROTTLE_USER_ALLOWLIST=1,53,217을 설정합니다.

사용자 허용 목록으로 인해 속도 제한기를 우회한 요청은 production_json.log에서 "throttle_safelist":"throttle_user_allowlist"로 표시됩니다.

애플리케이션 시작 시 허용 목록이 auth.log에 기록됩니다.

적용하기 전에 스로틀 설정 시험 사용#

GITLAB_THROTTLE_DRY_RUN 환경 변수를 쉼표로 구분된 스로틀 이름 목록으로 설정하여 스로틀 설정을 시험할 수 있습니다.

가능한 이름은 다음과 같습니다:

throttle_unauthenticated
- GitLab 14.3에서 더 이상 사용되지 않음으로 표시되었습니다. 대신 throttle_unauthenticated_api 또는 throttle_unauthenticated_web을 사용합니다. throttle_unauthenticated는 여전히 지원되며 두 가지 모두 선택합니다.
throttle_unauthenticated_api
throttle_unauthenticated_web
throttle_authenticated_api
throttle_authenticated_web
throttle_unauthenticated_protected_paths
throttle_authenticated_protected_paths_api
throttle_authenticated_protected_paths_web
throttle_unauthenticated_packages_api
throttle_authenticated_packages_api
throttle_authenticated_git_lfs
throttle_unauthenticated_files_api
throttle_authenticated_files_api
throttle_unauthenticated_deprecated_api
throttle_authenticated_deprecated_api
throttle_unauthenticated_git_http
throttle_authenticated_git_http

모든 스로틀에 대해 dry run 모드를 활성화하려면 변수를 *로 설정할 수 있습니다.

문제 해결#

실수로 관리자를 잠근 후 스로틀 비활성화#

관리자는 Rails 콘솔을 사용하여 GITLAB_THROTTLE_DRY_RUN 변수에 나열된 것과 동일한 제한을 비활성화할 수 있습니다. 예를 들어:

Gitlab::CurrentSettings.update!(throttle_authenticated_web_enabled: false)

이 예시에서 throttle_authenticated_web 매개변수는 _enabled 이름 접미사를 가집니다.

제한에 대한 숫자 값을 설정하려면 _enabled 이름 접미사를 _period_in_seconds 및 _requests_per_period 접미사로 교체합니다.

사용자 및 IP 속도 제한

사전 요구 사항#

인증되지 않은 API 요청 속도 제한 활성화#

인증되지 않은 웹 요청 속도 제한 활성화#

인증된 API 요청 속도 제한 활성화#

인증된 웹 요청 속도 제한 활성화#

사용자 정의 속도 제한 응답 사용#

분당 project/:id/jobs에 대한 최대 인증된 요청#

응답 헤더#

다중 속도 제한 시스템#

예시#

모든 요청에 반환되는 헤더#

스로틀된 요청에 대한 추가 헤더#

HTTP 헤더를 사용하여 속도 제한 우회#

특정 사용자가 인증된 요청 속도 제한을 우회하도록 허용#

적용하기 전에 스로틀 설정 시험 사용#

문제 해결#

실수로 관리자를 잠근 후 스로틀 비활성화#

사전 요구 사항#

인증되지 않은 API 요청 속도 제한 활성화#

인증되지 않은 웹 요청 속도 제한 활성화#

인증된 API 요청 속도 제한 활성화#

인증된 웹 요청 속도 제한 활성화#

사용자 정의 속도 제한 응답 사용#

분당 project/:id/jobs에 대한 최대 인증된 요청#

응답 헤더#

다중 속도 제한 시스템#

예시#

모든 요청에 반환되는 헤더#

스로틀된 요청에 대한 추가 헤더#

HTTP 헤더를 사용하여 속도 제한 우회#

특정 사용자가 인증된 요청 속도 제한을 우회하도록 허용#

적용하기 전에 스로틀 설정 시험 사용#

문제 해결#

실수로 관리자를 잠근 후 스로틀 비활성화#

분당 `project/:id/jobs`에 대한 최대 인증된 요청#

분당 `project/:id/jobs`에 대한 최대 인증된 요청#