NGINX 설정

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

서비스별 NGINX 설정

사용자는 gitlab.rb를 통해 서로 다른 서비스에 대해 NGINX 설정을 다르게 구성할 수 있습니다. GitLab Rails 애플리케이션의 설정은 nginx['<some setting>'] 키를 사용하여 구성할 수 있습니다. pages_nginx, mattermost_nginx, registry_nginx와 같은 다른 서비스에 대한 유사한 키가 있습니다. nginx에 대한 모든 구성은 이러한 <service_nginx> 설정에도 사용할 수 있으며 GitLab NGINX와 동일한 기본값을 공유합니다.

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
note
NGINX 구성을 수정하는 것은 잘못된 또는 호환되지 않는 구성으로 인해 서비스의 이용 불가능성을 야기할 수 있으므로 주의해야 합니다.

HTTPS 사용

기본적으로 Linux 패키지 설치는 HTTPS를 사용하지 않습니다. gitlab.example.com에 대해 HTTPS를 활성화하려는 경우 다음을 수행할 수 있습니다:

note
만일 GitLab 호스트 이름의 SSL을 종료시키기 위해 프록시, 로드 밸런서 또는 다른 외부 장치를 사용한다면 외부, 프록시 및 로드 밸런서 SSL 종료 구성을 참조하십시오.

기본 프록시 헤더 변경

기본적으로 external_url을 지정할 때, Linux 패키지 설치는 대부분 환경에서 적절하다고 가정되는 몇 가지 NGINX 프록시 헤더를 설정합니다.

예를 들어, Linux 패키지 설치는 다음과 같이 설정합니다: 

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

만일 external_url에서 https 스키마를 지정한 경우입니다.

그러나 리버스 프록시 뒤에 GitLab이 있는 등 보다 복잡한 설정이 있는 경우, The change you wanted was rejected 또는 Can't verify CSRF token authenticity Completed 422 Unprocessable와 같은 오류가 발생하지 않도록 프록시 헤더를 조정해야 합니다.

예를 들어, 기본 헤더를 재정의하여 다음과 같이 /etc/gitlab/gitlab.rb에 지정할 수 있습니다: 

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

파일을 저장하고 변경 사항을 적용하려면 GitLab 다시 구성을 수행하십시오.

이렇게 하면 필요한 NGINX에서 지원하는 모든 헤더를 지정할 수 있습니다.

GitLab trusted_proxies 및 NGINX real_ip 모듈 구성

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

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

NGINX가 다른 주소를 사용하도록 지정하도록 하려면 역방향 프록시에 대한 real_ip_trusted_addresses 디렉터리에 리버스 프록시를 추가할 수 있습니다: 

# 각 주소는 NGINX 구성에 'set_real_ip_from <address>;'로 추가됩니다.
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'

옵션에 대한 설명:

기본적으로 Linux 패키지 설치는 real_ip_trusted_addresses의 IP 주소를 GitLab 신뢰된 프록시로 사용하여 해당 IP에서 로그인한 사용자를 유지합니다.

파일을 저장하고 변경 사항을 적용하려면 GitLab 다시 구성을 수행하십시오.

PROXY 프로토콜 구성

PROXY 프로토콜을 사용하여 GitLab 앞에서 HAProxy와 같은 프록시를 사용하려는 경우, 이 설정을 활성화해야 합니다. 또한 필요한 대로 real_ip_trusted_addresses도 설정해야 합니다.

  1. /etc/gitlab/gitlab.rb 편집히기: 

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

  2. 파일을 저장하고 변경 사항을 적용하려면 GitLab 다시 구성을 수행하십시오.

활성화한 경우, NGINX는 이러한 리스너에 대해서만 PROXY 프로토콜 트래픽을 수락합니다. 모니터링 체크 등 다른 환경도 조정해야 합니다.

번들되지 않은 웹 서버 사용

기본적으로 Linux 패키지는 번들된 NGINX로 GitLab을 설치합니다. Linux 패키지 설치를 통해 gitlab-www 사용자를 통해 웹 서버에 액세스할 수 있으며, 해당 사용자는 동일한 그룹에 속합니다. GitLab에 대한 외부 웹 서버 액세스를 허용하려면 다음 단계를 수행해야 합니다:

  1. 번들된 NGINX 비활성화

    /etc/gitlab/gitlab.rb에서 다음과 같이 설정합니다: 

    nginx['enable'] = false

  2. 번들되지 않은 웹 서버 사용자 이름 설정

    Linux 패키지 설치는 Apache/NGINX의 경우 기본 설정이 없으므로 구성에서 지정해야 합니다. Debian/Ubuntu의 경우 Apache/NGINX에 대한 기본 사용자는 모두 www-data이며, RHEL/CentOS의 경우 NGINX 사용자는 nginx입니다.

    예를 들어, 웹 서버 사용자가 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 오류가 발생할 수 있습니다.

  3. 번들되지 않은 웹 서버를 신뢰할 수 있는 프록시 디렉터리에 추가

    일반적으로 Linux 패키지 설치는 번들된 NGINX의 real_ip 모듈에 구성된 것을 기본으로 할 것입니다.

    번들되지 않은 웹 서버의 경우 직접 디렉터리을 구성해야 하며, 웹 서버가 GitLab이 설치된 기기와 다른 위치에 있다면 IP 주소를 디렉터리에 포함해야 합니다. 그렇지 않으면 사용자는 웹 서버의 IP 주소에서 로그인한 것으로 표시됩니다. 

    gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]

  4. (선택 사항) Apache를 사용하는 경우 올바른 GitLab Workhorse 설정으로 설정

    Apache는 UNIX 소켓에 연결할 수 없으므로 TCP 포트에 연결해야 합니다. 기본적으로 8181 포트를 사용하여 GitLab Workhorse를 TCP로 수신하도록 하려면 /etc/gitlab/gitlab.rb를 다음과 같이 편집합니다: 

    gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"

    변경 사항이 적용되도록 하려면 sudo gitlab-ctl reconfigure를 실행하십시오.

  5. 올바른 웹 서버 구성 다운로드

    GitLab 리포지터리로 이동하여 필요한 구성을 다운로드합니다. SSL로 GitLab을 제공하는지 여부에 따라 올바른 구성 파일을 선택하십시오. 다음을 변경할 수도 있습니다:

    • YOUR_SERVER_FQDN 값을 FQDN으로 설정합니다.
    • SSL을 사용하는 경우 SSL 키의 위치입니다.
    • 로그 파일의 위치입니다.

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'] = ['*', '[::]']

NGINX 수신 대기 포트 설정

기본적으로 NGINX는 external_url에 지정된 포트에서 수신하거나 암시적으로 올바른 포트를 사용합니다 (HTTP의 경우 80, HTTPS의 경우 443). 만약 리버스 프록시 뒤에서 GitLab을 실행 중이라면 수신 포트를 다른 값으로 재정의할 수 있습니다. 예를 들어 8081포트를 사용하려면: 

nginx['listen_port'] = 8081

NGINX 로그의 상세 수준

기본적으로 NGINX는 error 상세 수준에서 로그를 남깁니다. 다른 수준으로 로그를 남기려면 로그 수준을 변경하세요. 예를 들어 debug 로깅을 활성화하려면: 

nginx['error_log_level'] = "debug"

유효한 값은 NGINX 문서에서 확인할 수 있습니다.

Referrer-Policy 헤더 설정

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

이로써 클라이언트는 동일 출처 요청 시 전체 URL을 리퍼러로 보내지만, 교차 출처 요청 시에는 출처만 보냅니다.

이 헤더를 다른 값으로 설정하려면: 

nginx['referrer_policy'] = 'same-origin'

또는 이 헤더를 비활성화하여 클라이언트가 기본 설정을 사용하도록 할 수도 있습니다: 

nginx['referrer_policy'] = false

이것을 origin 또는 no-referrer로 설정하는 것은 전체 리퍼러 URL이 필요한 GitLab의 일부 기능을 망가뜨릴 수 있음에 유의하세요.

Gzip 압축 비활성화

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

nginx['gzip_enabled'] = false
note
gzip 설정은 주된 GitLab 애플리케이션에 대해서만 작동하며, 다른 서비스에 대해서는 작동하지 않습니다.

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

request_buffering_off_path_regex를 변경하여 특정 위치에서 요청 버퍼링을 선택적으로 비활성화할 수 있습니다.

  1. /etc/gitlab/gitlab.rb 파일 편집: 

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

  2. GitLab을 재구성하고 HUP NGINX를 재구성하여 업데이트된 구성을 즉시 로드하도록 만듭니다: 

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl hup nginx

robots.txt 구성

인스턴스의 robots.txt를 구성하려면 사용자 정의 NGINX 구성을 추가하여 사용자 정의 robots.txt 파일을 지정하세요.

  1. /etc/gitlab/gitlab.rb 파일 편집: 

    nginx['custom_gitlab_server_config'] = "\nlocation =/robots.txt { alias /path/to/custom/robots.txt; }\n"

  2. GitLab을 재구성합니다: 

    sudo gitlab-ctl reconfigure

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

이러한 사용자 정의 설정은 리버스 프록시에 정의된 동일한 설정과 충돌을 일으킬 수 있으므로 주의하시기 바랍니다.

어떤 이유로든지 GitLab의 NGINX server 블록에 사용자 정의 설정을 추가해야 하는 경우, 다음 설정을 사용할 수 있습니다. 

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

NGINX 구성을 다시 작성하고 NGINX를 다시 시작하기 위해 gitlab-ctl reconfigure를 실행하세요.

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

참고

  • 새로운 위치를 추가하는 경우 다음이 필요할 수 있습니다 

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

    이러한 사항이 없으면 하위 위치가 404를 반환합니다. GitLab CE 이슈 #30619을 참조하세요.

  • / 위치나 /assets 위치를 추가할 수 없습니다. 해당 위치는 이미 gitlab-http.conf에 존재하기 때문입니다.

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

기존 서버 블록을 포함하여 NGINX 구성에 사용자 정의 설정을 추가해야 하는 경우, 예를 들어, 생성된 파일에 도메인을 추가할 수 있습니다 대체 이름 Let’s Encrypt SSL 인증서.

NGINX 구성을 다시 작성하고 NGINX를 다시 시작하기 위해 gitlab-ctl reconfigure를 실행하세요. 사용자 정의 서버 블록에 변경 사항을 가할 때마다 NGINX를 리로드(gitlab-ctl hup nginx)하거나 재시작(gitlab-ctl restart nginx)해야 합니다.

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

/etc/gitlab/ 디렉터리 내의 사용자 정의 NGINX 설정은 업그레이드 시 백업되어 /etc/gitlab/config_backup/에 저장되며 매뉴얼으로 sudo gitlab-ctl backup-etc를 실행할 때도 저장됩니다.

사용자 정의 오류 페이지

custom_error_pages를 사용하여 기본 GitLab 오류 페이지의 텍스트를 수정할 수 있습니다. 이는 유효한 HTTP 오류 코드(예: 404, 502)에 사용할 수 있습니다.

예를 들어, 다음은 기본 404 오류 페이지를 수정하는 것입니다. 

nginx['custom_error_pages'] = {
  '404' => {
    'title' => '예제 제목',
    'header' => '예제 헤더',
    'message' => '예제 메시지'
  }
}

이렇게 하면 아래와 같이 404 오류 페이지가 수정됩니다.

custom 404 error page

NGINX 구성을 다시 작성하고 NGINX를 다시 시작하기 위해 gitlab-ctl reconfigure를 실행하세요.

기존 Passenger/NGINX 설치 사용

일부 경우에는 기존의 Passenger/NGINX 설치를 사용하여 GitLab을 호스트하고 싶을 수 있지만 리눅스 패키지를 사용하여 업데이트 및 설치하는 편리함을 유지하고 싶을 수 있습니다.

note
NGINX를 비활성화하는 경우, Mattermost와 같은 리눅스 패키지 설치에 포함된 다른 서비스에 액세스할 수 없게 됩니다. 이를 해결하려면 nginx.conf에 매뉴얼으로 추가해야 합니다.

구성

먼저, 내장된 NGINX와 Puma를 비활성화하도록 /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']

변경 사항이 적용되려면 sudo gitlab-ctl reconfigure를 실행해야합니다.

Vhost (서버 블록)

사용자 정의 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 활성화 & 항상 최소한 하나의 인스턴스가 실행되도록 함
  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;
  }
  
  # Build artifacts는 다음 위치에 제출되어야 함
  location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
      client_max_body_size 0;
      # 'Error' 418는 @gitlab-workhorse 블록을 재사용하기 위한 해킹임
      error_page 418 = @gitlab-workhorse;
      return 418;
  }
  
  # Build artifacts는 다음 위치에 제출되어야 함
  location ~ /ci/api/v1/builds/[0-9]+/artifacts {
      client_max_body_size 0;
      # 'Error' 418는 @gitlab-workhorse 블록을 재사용하기 위한 해킹임
      error_page 418 = @gitlab-workhorse;
      return 418;
  }
  
  # Build artifacts는 다음 위치에 제출되어야 함
  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;
  }
  
  ## gzip 압축 활성화(Rails 가이드 참조):
  ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
  ## 경고: 상대적 URL을 사용하는 경우 아래 블록 제거
  ## 상대적 URL 사용 방법은 config/application.rb의 "상대적 URL 지원" 참조
  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 금지 상태가 발생하는 경우, /etc/nginx/nginx.conf에서 패신저를 활성화하지 않았을 수 있습니다. 간단히 다음을 주석 처리 해제하세요: 

# include /etc/nginx/passenger.conf;

그런 다음 sudo service nginx reload를 실행하세요.

nginx_status 활성화/비활성화

기본적으로 NGINX 상태 확인 엔드포인트가 127.0.0.1:8060/nginx_status에 구성되어 NGINX 서버 상태를 모니터링합니다.

다음 정보가 표시됩니다 

Active connections: 1
server accepts handled requests
 18 18 36
Reading: 0 Writing: 1 Waiting: 0
  • Active connections – 총 오픈 연결
  • 3개의 숫자가 표시됨
    • 수락된 모든 연결
    • 처리된 모든 연결
    • 처리된 전체 요청 수
  • Reading: NGINX가 요청 헤더를 읽음
  • Writing: NGINX가 요청 바디를 읽거나 요청을 처리하거나 클라이언트에 응답을 작성함
  • Waiting: Keep-alive 연결. 이 숫자는 keepalive-timeout에 따라 다름

구성 옵션

/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['status'] = {
  'enable' => false
}

변경 사항이 적용되려면 sudo gitlab-ctl reconfigure를 실행해야합니다.

주의

사용자 업로드가 접근 가능하도록 하려면 NGINX 사용자(보통 www-data)를 gitlab-www 그룹에 추가해야 합니다. 다음 명령을 사용하여 작업할 수 있습니다: 

sudo usermod -aG gitlab-www www-data

템플릿

푸마(Puma) 대신 패신저(Passenger) 구성 및 HTTPS가 없는 것을 제외하면 이러한 파일들은 대부분 다음과 동일합니다:

새 구성을 로드하기 위해 NGINX를 다시 시작하는 것을 잊지 마세요(Debian 기반 시스템에서 sudo service nginx restart).

문제 해결

400 Bad Request: too many Host headers

nginx['custom_gitlab_server_config'] 설정에 proxy_set_header 구성이 없도록 하고 대신 gitlab.rb 파일에서 ['proxy_set_headers'](ssl/index.md#configure-a-reverse-proxy-or-load-balancer-ssl-termination) 구성을 사용하는지 확인하세요.

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Linux 패키지 설치는 기본적으로 TLSv1 프로토콜을 지원하지 않습니다. 이는 GitLab 인스턴스와 상호 작용할 때 일부 오래된 Java 기반 IDE 클라이언트에서 연결 문제를 일으킬 수 있습니다. 서버에서 암호를 업그레이드하는 것을 강력히 권장하며, 이에 대한 자세한 내용은 이 사용자 코멘트에서 확인할 수 있습니다.

또는 이 서버 변경이 불가능한 경우, /etc/gitlab/gitlab.rb의 값 변경을 통해 이전 동작으로 되돌릴 수 있습니다: 

nginx['ssl_protocols'] = "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"

개인 키 및 인증서 간 불일치

NGINX 로그(/var/log/gitlab/nginx/current, Omnibus의 기본 설정)에서 x509 certificate routines:X509_check_private_key:key values mismatch)이(가) 보인다면, 개인 키와 인증서 간에 불일치가 있습니다.

이를 수정하기 위해 올바른 개인 키를 해당 인증서와 일치시켜야 합니다.

정확한 키와 인증서를 보유하고 있는지 확인하려면, 개인 키의 모듈러스와 인증서의 모듈러스가 일치하는지 확인할 수 있습니다: 

/opt/gitlab/embedded/bin/openssl rsa -in /etc/gitlab/ssl/gitlab.example.com.key -noout -modulus | /opt/gitlab/embedded/bin/openssl sha256

/opt/gitlab/embedded/bin/openssl x509 -in /etc/gitlab/ssl/gitlab.example.com.crt -noout -modulus| /opt/gitlab/embedded/bin/openssl sha256

일치하는 것을 확인한 후, NGINX를 다시 구성 및 로드해야 합니다: 

sudo gitlab-ctl reconfigure
sudo gitlab-ctl hup nginx

Request Entity Too Large

NGINX 로그에서 Request Entity Too Large를 보인다면, Client Max Body Size를 증가해야 합니다. 최대 가져오기 크기를 증가했을 경우 이 오류가 발생할 수 있습니다. 기반의 경우, 이 설정이 다르게 명명됩니다.

client_max_body_size를 증가시키려면 /etc/gitlab/gitlab.rb에서 값을 설정해야 합니다: 

nginx['client_max_body_size'] = '250m'

sudo gitlab-ctl reconfigure를 실행하고 sudo gitlab-ctl hup nginx를 실행하여 NGINX가 업데이트된 구성을 로드하도록 해야 합니다.

client_max_body_size를 증가시키려면:

  1. 선호하는 값을 /etc/gitlab/gitlab.rb에 편집합니다: 

    nginx['client_max_body_size'] = '250m'

  2. GitLab을 다시 구성하고, HUP하여 업데이트된 구성을 부드럽게 다시로드합니다: 

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl hup nginx

보안 스캔이 “NGINX HTTP Server Detection” 경고를 보여줍니다

일부 보안 스캐너는 Server: nginx http 헤더를 보면 문제를 감지합니다. 이 경고를 가진 대부분의 스캐너는 Low나 Info 심각도로 알립니다. Nessus를 참조하세요.

우리는 이 경고를 무시할 것을 권장합니다. 헤더를 제거하는 것의 이점은 적고, 여기에 대한 지원용도로 NGINX 프로젝트를 지원하는데 도움이 됩니다. hide_server_tokens를 사용하여 헤더를 끄는 방법을 제공합니다:

  1. /etc/gitlab/gitlab.rb를 편집하고 값을 설정합니다: 

    nginx['hide_server_tokens'] = 'on'

  2. GitLab을 다시 구성하고 hup하여 업데이트된 구성을 부드럽게 다시로드합니다: 

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl hup nginx

Web IDE 및 외부 NGINX를 사용했을 때 Branch 'branch_name' was not found in this project's repository

이 오류가 발생하면 proxy_pass에 끝에 슬래시가 있는지 NGINX 구성 파일을 확인하고 제거하세요.

GitLab이 502 오류를 표시하며 로그에 worker_connections are not enough가 출력됩니다

로그에서 worker_connections are not enough 오류가 발생하면, NGINX worker 연결을 더 높은 값으로 구성해야 합니다:

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

    gitlab['nginx']['worker_connections'] = 10240

  2. GitLab을 다시 구성합니다: 

    sudo gitlab-ctl reconfigure

기본값은 10240 연결입니다.