NGINX 설정

Tier: Free, Premium, Ultimate Offering: Self-managed

이 페이지는 GitLab 설치를 위한 NGINX를 구성하는 관리자를 위한 구성 정보를 제공합니다.

성능 및 보안을 최적화하기 위한 필수 지침을 포함하며, 번들로 제공되는 NGINX (Linux 패키지), Helm 차트 또는 사용자 지정 설정에 따라 다릅니다.

서비스별 NGINX 설정

다양한 서비스에 대한 NGINX 설정을 구성하려면 gitlab.rb 파일을 편집하세요.

잘못되거나 호환되지 않는 구성이
서비스를 사용할 수 없게 만들 수 있습니다.

nginx['<setting>'] 키를 사용하여 GitLab Rails 애플리케이션의 설정을 구성하세요.
GitLab은 pages_nginx, mattermost_nginx, registry_nginx와 같은 다른 서비스에 대해 유사한 키를 제공합니다.
nginx에 대한 구성이 이러한 <service_nginx> 설정에 대해서도 제공되며,
GitLab NGINX와 동일한 기본 값을 공유합니다.

Mattermost와 같은 격리된 서비스를 운영하기 위해 NGINX를 사용하려면 nginx['enable'] = false 대신 gitlab_rails['enable'] = false를 사용하세요.
자세한 내용은 자체 서버에서 GitLab Mattermost 실행을 참조하세요.

gitlab.rb 파일을 수정할 때, 각 서비스에 대해 NGINX 설정을 별도로 구성하세요.

nginx['foo']를 사용하여 지정된 설정은 서비스별 NGINX 구성(예: registry_nginx['foo'] 또는
mattermost_nginx['foo'])에 복제되지 않습니다.

예를 들어, GitLab, Mattermost 및 Registry에 대한 HTTP에서 HTTPS로의
리디렉션을 구성하려면 다음 설정을 gitlab.rb에 추가하세요:

nginx['redirect_http_to_https'] = true  
registry_nginx['redirect_http_to_https'] = true  
mattermost_nginx['redirect_http_to_https'] = true  

HTTPS 활성화

기본적으로 Linux 패키지 설치는 HTTPS를 사용하지 않습니다.
gitlab.example.com에 대한 HTTPS를 활성화하려면:

프록시, 로드 밸런서 또는 GitLab 호스트 이름에 대한 SSL을 종료하는 다른 외부 장치를 사용하는 경우,
외부, 프록시 및 로드 밸런서 SSL 종료를 참조하세요.

기본 프록시 헤더 변경

기본적으로 external_url을 지정하면, Linux 패키지 설치는 대부분의 환경에 적합한 NGINX 프록시 헤더를 설정합니다.

예를 들어, external_url에 https 스키마를 지정하면, Linux 패키지 설치는 다음을 설정합니다:

"X-Forwarded-Proto" => "https",  
"X-Forwarded-Ssl" => "on"  

GitLab 인스턴스가 리버스 프록시 뒤와 같은 더 복잡한 설정에 있는 경우,
다음의 변경 사항이 거부되었습니다 또는 CSRF 토큰 유효성을 확인할 수 없습니다 완료 422 처리할 수 없는 형식과 같은 오류를 피하기 위해
프록시 헤더를 조정해야 할 수 있습니다.

기본 헤더를 오버라이드하려면:

/etc/gitlab/gitlab.rb를 편집하세요:

nginx['proxy_set_headers'] = {  
  "X-Forwarded-Proto" => "http",  
  "CUSTOM_HEADER" => "VALUE"  
}  

파일을 저장하고 GitLab 재구성하여
변경 사항이 적용되도록 하세요.

NGINX에서 지원하는 모든 헤더를 지정할 수 있습니다.

GitLab 신뢰할 수 있는 프록시 및 NGINX `real_ip` 모듈 구성

기본적으로 NGINX와 GitLab은 연결된 클라이언트의 IP 주소를 로그에 기록합니다.

GitLab이 리버스 프록시 뒤에 있는 경우, 프록시의 IP 주소가 클라이언트 주소로 표시되지 않도록 할 수 있습니다.

NGINX가 다른 주소를 사용하도록 구성하려면 리버스 프록시를 real_ip_trusted_addresses 목록에 추가하세요:

# 각 주소는 'set_real_ip_from <address>;'로 NGINX 구성에 추가됩니다.
nginx['real_ip_trusted_addresses'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
# 기타 real_ip 구성 옵션
nginx['real_ip_header'] = 'X-Forwarded-For'
nginx['real_ip_recursive'] = 'on'

이 옵션에 대한 설명은 NGINX realip 모듈 문서를 참조하세요.

기본적으로 Linux 패키지 설치는 real_ip_trusted_addresses의 IP 주소를 GitLab 신뢰할 수 있는 프록시로 사용합니다.

신뢰할 수 있는 프록시 구성은 해당 IP 주소에서 사용자가 로그인한 것으로 나열되는 것을 방지합니다.

파일을 저장하고 GitLab 재구성하여 변경 사항이 적용되도록 합니다.

PROXY 프로토콜 구성

HAProxy와 같은 프록시를 GitLab의 앞에 두고 PROXY 프로토콜을 사용하려면:

/etc/gitlab/gitlab.rb를 편집합니다:

# NGINX에 의한 ProxyProtocol 종료를 활성화합니다.
nginx['proxy_protocol'] = true
# 신뢰할 수 있는 상류 프록시를 구성합니다. `proxy_protocol`이 활성화된 경우 필요합니다.
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

파일을 저장하고 GitLab 재구성하여 변경 사항이 적용되도록 합니다.

이 설정을 활성화하면 NGINX는 이러한 리스너에서만 PROXY 프로토콜 트래픽을 수락합니다.

모니터링 확인과 같은 다른 환경을 조정하세요.

번들되지 않은 웹 서버 사용

기본적으로 Linux 패키지는 GitLab을 번들된 NGINX와 함께 설치합니다.

Linux 패키지 설치는 gitlab-www 사용자로 웹 서버 접근을 허용하며, 해당 사용자는 같은 이름의 그룹에 속합니다. 외부 웹 서버가 GitLab에 접근할 수 있도록 하려면 외부 웹 서버 사용자를 gitlab-www 그룹에 추가하세요.

Apache 또는 기존 NGINX 설치와 같은 다른 웹 서버를 사용하려면:

번들된 NGINX를 비활성화합니다:

/etc/gitlab/gitlab.rb에서 다음을 설정합니다:
```
nginx['enable'] = false
```
번들되지 않은 웹 서버 사용자의 사용자 이름을 설정합니다:

Linux 패키지 설치는 외부 웹 서버 사용자에 대한 기본 설정이 없습니다.

구성에서 반드시 지정해야 합니다. 예를 들어:
- Debian/Ubuntu: 기본 사용자는 Apache와 NGINX 모두에 대해 www-data입니다.
- RHEL/CentOS: NGINX 사용자는 nginx입니다.
계속하기 전에 Apache 또는 NGINX를 설치하여 웹 서버 사용자가 생성되도록 하세요.

그렇지 않으면 재구성 중에 Linux 패키지 설치가 실패합니다.

웹 서버 사용자가 www-data인 경우, /etc/gitlab/gitlab.rb에서 다음을 설정합니다:
```
web_server['external_users'] = ['www-data']
```
이 설정은 배열이므로 gitlab-www 그룹에 추가할 여러 사용자를 지정할 수 있습니다.

변경 사항을 적용하기 위해 sudo gitlab-ctl reconfigure를 실행합니다.

SELinux를 사용하고 웹 서버가 제한된 SELinux 프로필에서 실행되는 경우, 웹 서버의 제한을 완화해야 할 수도 있습니다.

외부 웹 서버가 사용하는 모든 디렉터리에서 웹 서버 사용자에게 올바른 권한이 있는지 확인하세요.

그렇지 않으면 failed (XX: Permission denied) while reading upstream 오류가 발생할 수 있습니다.
번들되지 않은 웹 서버를 신뢰할 수 있는 프록시 목록에 추가합니다:

Linux 패키지 설치는 일반적으로 신뢰할 수 있는 프록시 목록을 번들된 NGINX의 real_ip 모듈 구성으로 기본 설정합니다.

번들되지 않은 웹 서버의 경우 목록을 직접 구성합니다. GitLab과 동일한 머신에 있지 않은 경우 웹 서버의 IP 주소를 포함합니다.

그렇지 않으면 사용자가 웹 서버의 IP 주소에서 로그인한 것으로 표시됩니다.
```
gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
```
선택 사항. Apache를 사용하는 경우 GitLab Workhorse 설정을 설정합니다:

Apache는 UNIX 소켓에 연결할 수 없으며 TCP 포트에 연결해야 합니다. GitLab Workhorse가 TCP(기본적으로 포트 8181)에서 수신 대기하도록 하려면 /etc/gitlab/gitlab.rb를 편집합니다:
```
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
```
변경 사항을 적용하기 위해 sudo gitlab-ctl reconfigure를 실행합니다.
올바른 웹 서버 구성을 다운로드합니다:

GitLab 리포지토리로 이동하여 필요한 구성을 다운로드합니다.

GitLab을 SSL유무에 따라 서비스하기 위한 올바른 구성 파일을 선택합니다.

다음을 변경해야 할 수도 있습니다:
- YOUR_SERVER_FQDN의 값을 FQDN으로 변경합니다.
- SSL을 사용하는 경우 SSL 키의 위치.
- 로그 파일의 위치.

NGINX 구성 옵션

GitLab은 특정 요구 사항에 맞게 NGINX 동작을 사용자 정의할 수 있는 다양한 구성 옵션을 제공합니다.

이 참조 항목을 사용하여 NGINX 설정을 미세 조정하고 GitLab 성능과 보안을 최적화합니다.

NGINX 수신 주소 설정

기본적으로 NGINX는 모든 로컬 IPv4 주소에서 들어오는 연결을 수락합니다.

주소 목록을 변경하려면:

/etc/gitlab/gitlab.rb를 수정합니다:

# 모든 IPv4 및 IPv6 주소에서 수신
nginx['listen_addresses'] = ["0.0.0.0", "[::]"]
registry_nginx['listen_addresses'] = ['*', '[::]']
mattermost_nginx['listen_addresses'] = ['*', '[::]']
pages_nginx['listen_addresses'] = ['*', '[::]']

파일을 저장하고 GitLab 재구성하기 변경 사항이 적용되도록 합니다.

NGINX 수신 포트 설정

기본적으로 NGINX는 external_url에 지정된 포트에서 수신하거나 표준 포트(HTTP의 경우 80, HTTPS의 경우 443)를 사용합니다. GitLab을 리버스 프록시 뒤에서 실행하는 경우 수신 포트를 재정의할 수 있습니다.

수신 포트를 변경하려면:

/etc/gitlab/gitlab.rb를 수정합니다. 예를 들어, 포트 8081을 사용하려면:
```
nginx['listen_port'] = 8081
```
파일을 저장하고 GitLab 재구성하기 변경 사항이 적용되도록 합니다.

NGINX 로그의 상세 수준 변경

기본적으로 NGINX는 error 상세 수준으로 로그를 기록합니다.

로그 수준을 변경하려면:

/etc/gitlab/gitlab.rb를 수정합니다:
```
nginx['error_log_level'] = "debug"
```
파일을 저장하고 GitLab 재구성하기 변경 사항이 적용되도록 합니다.

유효한 로그 수준 값에 대한 내용은 NGINX 문서를 참조하세요.

Referrer-Policy 헤더 설정

기본적으로 GitLab은 모든 응답에서 Referrer-Policy 헤더를 strict-origin-when-cross-origin으로 설정합니다.

이 설정은 클라이언트가:

동일 출처 요청에 대해 전체 URL을 참조로 보냅니다.
교차 출처 요청에 대해 오직 출처만 보냅니다.

이 헤더를 변경하려면:

/etc/gitlab/gitlab.rb를 수정합니다:
```
nginx['referrer_policy'] = 'same-origin'
```
이 헤더를 비활성화하고 클라이언트의 기본 설정을 사용하려면:
```
nginx['referrer_policy'] = false
```
파일을 저장하고 GitLab 재구성하기 변경 사항이 적용되도록 합니다.

경고: 이 설정을 origin 또는 no-referrer로 설정하면 전체 참조 URL이 필요한 GitLab 기능이 중단됩니다.

자세한 내용은 Referrer Policy 사양을 참조하세요.

Gzip 압축 비활성화

기본적으로 GitLab은 10240 바이트 이상의 텍스트 데이터에 대해 Gzip 압축을 활성화합니다. Gzip 압축을 비활성화하려면:

/etc/gitlab/gitlab.rb를 수정합니다:
```
nginx['gzip_enabled'] = false
```
파일을 저장하고 GitLab 재구성하기 변경 사항이 적용되도록 합니다.

참고: gzip 설정은 메인 GitLab 애플리케이션에만 적용되며, 다른 서비스에는 적용되지 않습니다.

프록시 요청 버퍼링 비활성화

특정 위치에 대한 요청 버퍼링을 비활성화하려면:

/etc/gitlab/gitlab.rb를 수정합니다:

nginx['request_buffering_off_path_regex'] = "/api/v\\d/jobs/\\d+/artifacts$|/import/gitlab_project$|\\.git/git-receive-pack$|\\.git/ssh-receive-pack$|\\.git/ssh-upload-pack$|\\.git/gitlab-lfs/objects|\\.git/info/lfs/objects/batch$"

파일을 저장하고 GitLab 재구성 이 변경 사항을 적용하도록 합니다.
NGINX 구성을 우아하게 다시 로드합니다:
```
sudo gitlab-ctl hup nginx
```

hup 명령어에 대한 자세한 내용은 NGINX 문서를 참조하세요.

`robots.txt` 구성

인스턴스에 대한 사용자 정의 robots.txt 파일을 구성하려면:

사용자 정의 robots.txt 파일을 생성하고 경로를 확인합니다.
/etc/gitlab/gitlab.rb를 수정합니다:
```
nginx['custom_gitlab_server_config'] = "\nlocation =/robots.txt { alias /path/to/custom/robots.txt; }\n"
```
/path/to/custom/robots.txt를 사용자 정의 robots.txt 파일의 실제 경로로 바꿉니다.
파일을 저장하고 GitLab 재구성 이 변경 사항을 적용하도록 합니다.

이 구성은 사용자 정의 robots.txt 파일을 제공하기 위해 사용자 정의 NGINX 설정을 추가합니다.

GitLab 서버 블록에 사용자 정의 NGINX 설정 삽입

GitLab에 대해 NGINX server 블록에 사용자 정의 설정을 추가하려면:

/etc/gitlab/gitlab.rb를 수정합니다:

# 예: 특정 리포지토리의 원시 파일 다운로드 차단
nginx['custom_gitlab_server_config'] = "location ^~ /foo-namespace/bar-project/raw/ {\n deny all;\n}\n"

파일을 저장하고 GitLab 재구성 이 변경 사항을 적용하도록 합니다.

이 설정은 /var/opt/gitlab/nginx/conf/gitlab-http.conf의 server 블록 끝에 정의된 문자열을 삽입합니다.

경고: 사용자 정의 설정은 gitlab.rb 파일의 다른 곳에서 정의된 설정과 충돌할 수 있습니다.

노트

새 위치를 추가하는 경우 다음을 포함해야 할 수 있습니다:
```
proxy_cache off;
proxy_http_version 1.1;
proxy_pass http://gitlab-workhorse;
```
이러한 없이는 하위 위치가 404 오류를 반환할 수 있습니다.
루트 / 위치나 /assets 위치는 이미 gitlab-http.conf에 존재하므로 추가할 수 없습니다.

NGINX 구성에 사용자 정의 설정 삽입

NGINX 구성에 사용자 정의 설정을 추가하려면:

/etc/gitlab/gitlab.rb를 수정합니다:

# 예: 추가 구성 파일을 검색하기 위한 디렉토리 포함
nginx['custom_nginx_config'] = "include /etc/gitlab/nginx/sites-enabled/*.conf;"

파일을 저장하고 GitLab 재구성 이 변경 사항을 적용하도록 합니다.

이 설정은 /var/opt/gitlab/nginx/conf/nginx.conf의 http 블록 끝에 정의된 문자열을 삽입합니다.

예를 들어, 사용자 정의 서버 블록을 생성하고 활성화하려면:

/etc/gitlab/nginx/sites-available 디렉토리에 사용자 정의 서버 블록을 생성합니다.
/etc/gitlab/nginx/sites-enabled 디렉토리를 존재하지 않는 경우 생성합니다.

사용자 정의 서버 블록을 활성화하려면 심볼릭 링크를 만듭니다:

sudo ln -s /etc/gitlab/nginx/sites-available/example.conf /etc/gitlab/nginx/sites-enabled/example.conf

NGINX 구성을 다시 로드합니다:
```
sudo gitlab-ctl hup nginx
```
또는 NGINX를 다시 시작할 수 있습니다:
```
sudo gitlab-ctl restart nginx
```

서버 블록에 대한 도메인을 대체 이름으로 추가하여 생성된 Let’s Encrypt SSL 인증서에 사용할 수 있습니다.

/etc/gitlab/ 디렉토리 내의 사용자 정의 NGINX 설정은 업그레이드 시 /etc/gitlab/config_backup/로 백업됩니다. sudo gitlab-ctl backup-etc를 수동으로 실행할 때도 마찬가지입니다.

사용자 정의 오류 페이지 구성

기본 GitLab 오류 페이지의 텍스트를 수정하려면:

/etc/gitlab/gitlab.rb 파일을 수정합니다:
```
nginx['custom_error_pages'] = {
 '404' => {
   'title' => '예시 제목',
   'header' => '예시 헤더',
   'message' => '예시 메시지'
 }
}
```
이 예시는 기본 404 오류 페이지를 수정합니다. 이 형식을 사용하여 404 또는 502와 같은 유효한 HTTP 오류 코드를 위한 설정을 할 수 있습니다.
파일을 저장하고 GitLab 재구성하기 변경 내용이 적용되도록 합니다.

404 오류 페이지의 결과는 다음과 같습니다:

기존 Passenger 및 NGINX 설치 사용

기존 Passenger 및 NGINX 설치로 GitLab을 호스팅할 수 있으며, 여전히 업데이트 및 설치를 위해 Linux 패키지를 사용할 수 있습니다.

NGINX를 비활성화하면 nginx.conf에 수동으로 추가하지 않는 한, Mattermost와 같은 Linux 패키지 설치에 포함된 다른 서비스에 접근할 수 없습니다.

구성

기존 Passenger 및 NGINX 설치로 GitLab을 설정하려면:

/etc/gitlab/gitlab.rb 파일을 수정합니다:

# 외부 URL 정의
external_url 'http://git.example.com'

# 내장된 NGINX 비활성화
nginx['enable'] = false

# 내장된 Puma 비활성화
puma['enable'] = false

# 내부 API URL 설정
gitlab_rails['internal_api_url'] = 'http://git.example.com'

# 웹 서버 프로세스 사용자 정의 (ubuntu/nginx)
web_server['external_users'] = ['www-data']

파일을 저장하고 GitLab 재구성하기 변경 내용이 적용되도록 합니다.

가상 호스트(서버 블록) 구성

사용자 정의 Passenger/NGINX 설치에서:

다음 내용을 포함하는 새 사이트 구성 파일을 만듭니다:

upstream gitlab-workhorse {
 server unix://var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}

server {
 listen *:80;
 server_name git.example.com;
 server_tokens off;
 root /opt/gitlab/embedded/service/gitlab-rails/public;

 client_max_body_size 250m;

 access_log  /var/log/gitlab/nginx/gitlab_access.log;
 error_log   /var/log/gitlab/nginx/gitlab_error.log;

 # 확인: Passenger가 번들된 Ruby 버전을 사용하도록 합니다
 passenger_ruby /opt/gitlab/embedded/bin/ruby;

 # 포함된 패키지 실행 파일을 위해 $PATH 변수 수정
 passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

 # 권한 문제를 방지하기 위해 Passenger가 올바른 사용자 및 그룹으로 실행되도록 합니다
 passenger_user git;
 passenger_group git;

 # Passenger 활성화 및 항상 최소 1개의 인스턴스를 실행하도록 합니다
 passenger_enabled on;
 passenger_min_instances 1;

 location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
   # 'Error' 418은 @gitlab-workhorse 블록을 재사용하기 위한 해킹입니다
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
   # 'Error' 418은 @gitlab-workhorse 블록을 재사용하기 위한 해킹입니다
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/api/v3/projects/.*/repository/archive {
   # 'Error' 418은 @gitlab-workhorse 블록을 재사용하기 위한 해킹입니다
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 # 빌드 아티팩트는 이 위치에 제출되어야 합니다
 location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
     client_max_body_size 0;
     # 'Error' 418은 @gitlab-workhorse 블록을 재사용하기 위한 해킹입니다
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # 빌드 아티팩트는 이 위치에 제출되어야 합니다
 location ~ /ci/api/v1/builds/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418은 @gitlab-workhorse 블록을 재사용하기 위한 해킹입니다
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # 빌드 아티팩트는 이 위치에 제출되어야 합니다
 location ~ /api/v4/jobs/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418은 @gitlab-workhorse 블록을 재사용하기 위한 해킹입니다
     error_page 418 = @gitlab-workhorse;
     return 418;
 }


 # HTTP/1.0에서 HTTP/1.1로의 프로토콜 업그레이드 시 Host 헤더가 없으면 제공해야 합니다
 if ($http_host = "") {
 # server_name에서 정의된 값 중 하나를 사용합니다
   set $http_host_with_default "git.example.com";
 }

 if ($http_host != "") {
   set $http_host_with_default $http_host;
 }

 location @gitlab-workhorse {

   ## https://github.com/gitlabhq/gitlabhq/issues/694
   ## 일부 요청은 30초 이상 걸립니다.
   proxy_read_timeout      3600;
   proxy_connect_timeout   300;
   proxy_redirect          off;

   # Git HTTP 응답을 버퍼링 하지 않습니다
   proxy_buffering off;

   proxy_set_header    Host                $http_host_with_default;
   proxy_set_header    X-Real-IP           $remote_addr;
   proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
   proxy_set_header    X-Forwarded-Proto   $scheme;

   proxy_http_version 1.1;
   proxy_pass http://gitlab-workhorse;

   ## 다음 설정은 NGINX 1.7.11 이상에서만 작동합니다
   #
   ## 청크된 요청 본문을 gitlab-workhorse에 있는 그대로 전달합니다
   # proxy_request_buffering off;
   # proxy_http_version 1.1;
 }

 ## Rails 가이드에 따른 gzip 압축 활성화:
 ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
 ## 경고: 상대 URL을 사용하는 경우 아래 블록을 제거하십시오
 ## 상대 URL 지원을 위한 목록은 config/application.rb의 "Relative url support"에서 확인하십시오
 location ~ ^/(assets)/ {
   root /opt/gitlab/embedded/service/gitlab-rails/public;
   gzip_static on; # 사전 압축된 버전을 제공하기 위해
   expires max;
   add_header Cache-Control public;
 }

 error_page 502 /502.html;
}

git.example.com을 서버 URL로 교체합니다.

403 Forbidden 오류가 발생하면 /etc/nginx/nginx.conf에서 Passenger가 활성화되어 있는지 확인하십시오:

다음 줄의 주석을 제거합니다:
```
# include /etc/nginx/passenger.conf;
```
NGINX 구성을 다시 로드합니다:
```
sudo service nginx reload
```

NGINX 상태 모니터링 구성

기본적으로 GitLab은 NGINX 서버 상태를 모니터링하기 위해 127.0.0.1:8060/nginx_status에 NGINX 헬스 체크 엔드포인트를 구성합니다.

이 엔드포인트는 다음 정보를 표시합니다:

활성 연결: 1
서버 수락 처리 요청
18 18 36
읽기: 0 쓰기: 1 대기: 0

활성 연결: 총 열린 연결.
세 개의 숫자 표시:
- 모든 수락된 연결.
- 모든 처리된 연결.
- 총 처리된 요청 수.
읽기: NGINX가 요청 헤더를 읽고 있습니다.
쓰기: NGINX가 요청 본문을 읽고, 요청을 처리하거나 클라이언트에 응답을 작성합니다.
대기: Keep-alive 연결. 이 숫자는 keepalive_timeout 지시문에 따라 달라집니다.

NGINX 상태 옵션 구성

NGINX 상태 옵션을 구성하려면:

/etc/gitlab/gitlab.rb 파일을 편집합니다:

nginx['status'] = {
 "listen_addresses" => ["127.0.0.1"],
 "fqdn" => "dev.example.com",
 "port" => 9999,
 "options" => {
   "access_log" => "on", # 통계를 위한 로그 비활성화
   "allow" => "127.0.0.1", # 로컬호스트에서만 접근 허용
   "deny" => "all" # 다른 모든 접근 거부
 }
}

NGINX 상태 엔드포인트를 비활성화하려면:

nginx['status'] = {
 'enable' => false
}

파일을 저장하고 GitLab 재구성하여 변경 사항이 적용되도록 합니다.

업로드를 위한 사용자 권한 구성

사용자 업로드가 접근 가능하도록 하려면 NGINX 사용자(보통 www-data)를 gitlab-www 그룹에 추가합니다:

sudo usermod -aG gitlab-www www-data

템플릿

구성 파일은 번들 GitLab NGINX 구성과 유사하나 다음과 같은 차이가 있습니다:

Puma 대신 Passenger 구성이 사용됩니다.
HTTPS는 기본적으로 비활성화되어 있지만, 활성화할 수 있습니다.

NGINX 구성을 변경한 후:

Debian 기반 시스템의 경우 NGINX를 재시작합니다:
```
sudo service nginx restart
```
기타 시스템의 경우, NGINX를 재시작하기 위한 올바른 명령을 운영 체제 문서에서 참조하세요.

NGINX 설정

서비스별 NGINX 설정

HTTPS 활성화

기본 프록시 헤더 변경

GitLab 신뢰할 수 있는 프록시 및 NGINX `real_ip` 모듈 구성

PROXY 프로토콜 구성

번들되지 않은 웹 서버 사용

NGINX 구성 옵션

NGINX 수신 주소 설정

NGINX 수신 포트 설정

NGINX 로그의 상세 수준 변경

Referrer-Policy 헤더 설정

Gzip 압축 비활성화

프록시 요청 버퍼링 비활성화

`robots.txt` 구성

GitLab 서버 블록에 사용자 정의 NGINX 설정 삽입

노트

NGINX 구성에 사용자 정의 설정 삽입

사용자 정의 오류 페이지 구성

기존 Passenger 및 NGINX 설치 사용

구성

가상 호스트(서버 블록) 구성

NGINX 상태 모니터링 구성

NGINX 상태 옵션 구성

업로드를 위한 사용자 권한 구성

템플릿

도움말

기능 사용 가능성과 제품 평가판

도움받기

NGINX 설정

서비스별 NGINX 설정

HTTPS 활성화

기본 프록시 헤더 변경

GitLab 신뢰할 수 있는 프록시 및 NGINX real_ip 모듈 구성

PROXY 프로토콜 구성

번들되지 않은 웹 서버 사용

NGINX 구성 옵션

NGINX 수신 주소 설정

NGINX 수신 포트 설정

NGINX 로그의 상세 수준 변경

Referrer-Policy 헤더 설정

Gzip 압축 비활성화

프록시 요청 버퍼링 비활성화

robots.txt 구성

GitLab 서버 블록에 사용자 정의 NGINX 설정 삽입

노트

NGINX 구성에 사용자 정의 설정 삽입

사용자 정의 오류 페이지 구성

기존 Passenger 및 NGINX 설치 사용

구성

가상 호스트(서버 블록) 구성

NGINX 상태 모니터링 구성

NGINX 상태 옵션 구성

업로드를 위한 사용자 권한 구성

템플릿

도움말

기능 사용 가능성과 제품 평가판

도움받기

GitLab 신뢰할 수 있는 프록시 및 NGINX `real_ip` 모듈 구성

`robots.txt` 구성