NGINXの設定

サービス固有の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、およびレジストリに対して 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"

でhttps スキーマを指定した場合、external_url.

しかし、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でサポートされているヘッダーを指定することができます。

GitLabtrusted_proxies と NGINXreal_ip モジュールの設定

デフォルトでは、NGINX と GitLab は接続しているクライアントの IP アドレスを記録します。

GitLab がリバースプロキシの後ろにある場合、クライアントのアドレスとしてプロキシの IP アドレスを表示したくないことがあります。

real_ip_trusted_addresses リストにリバースプロキシを追加することで、NGINX に別のアドレスを探させることができます：

# Each address is added to the the NGINX config as 'set_real_ip_from <address>;'
nginx['real_ip_trusted_addresses'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
# other real_ip config options
nginx['real_ip_header'] = 'X-Forwarded-For'
nginx['real_ip_recursive'] = 'on'

オプションの説明

デフォルトでは、Linuxパッケージインストールはreal_ip_trusted_addresses のIPアドレスをGitLab trusted proxiesとして使用し、ユーザーがそれらのIPからサインインしたものとしてリストされないようにします。

ファイルを保存し、変更を有効にするためにGitLab を再設定してください。

PROXYプロトコルの設定

PROXYプロトコルを使ってGitLabの前でHAProxyのようなプロキシを使いたい場合は、この設定を有効にする必要があります。必要に応じてreal_ip_trusted_addresses も忘れずに設定してください：

  1. /etc/gitlab/gitlab.rb を編集します：

    # Enable termination of ProxyProtocol by NGINX
nginx['proxy_protocol'] = true
# Configure trusted upstream proxies. Required if `proxy_protocol` is enabled.
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

  2. ファイルを保存し、変更を有効にするためにGitLab を再設定します。

有効にすると、NGINXはこれらのリスナー上でPROXYプロトコルのトラフィックのみを受け付けるようになります。モニタリングチェックのような他の環境も調整してください。

バンドルされていないウェブサーバの使用

デフォルトでは、LinuxパッケージはNGINXがバンドルされたGitLabをインストールします。Linuxパッケージのインストールでは、gitlab-www 同じ名前のグループに存在するユーザーを通して gitlab-wwwウェブサーバーにアクセスすることができます。gitlab-www 外部のウェブサーバーからGitLabへのアクセスを許可するには、外部のウェブサーバーユーザーをグループに追加する必要が gitlab-wwwあります。

Apacheや既存のNGINXインストールのような別のウェブサーバーを使用するには、以下の手順を実行する必要があります：

  1. バンドルされているNGINXを無効にします。

    /etc/gitlab/gitlab.rb で設定します：

    nginx['enable'] = false

  2. バンドルされていないウェブサーバーのユーザー名を設定します。

    デフォルトでは、Linuxパッケージインストールには外部ウェブサーバユーザのデフォルト設定がないため、設定で指定する必要があります。Debian/Ubuntuの場合、デフォルトのユーザーはApache/NGINXともにwww-data 、RHEL/CentOSの場合、NGINXユーザーはnginx です。

    さもないと、再設定中にLinuxパッケージのインストールに失敗します。

    /etc/gitlab/gitlab.rb 例えば、ウェブサーバーユーザーがwww-data であるとします：

    web_server['external_users'] = ['www-data']

    この設定は配列なので、gitlab-www グループに追加するユーザーを複数指定できます。

    変更を有効にするには、sudo gitlab-ctl reconfigure を実行してください。

    SELinux を使用していて、Web サーバーが制限された SELinux プロファイルで動作している場合は、Web サーバーの制限を緩める必要があるかもしれません。

    ウェブサーバユーザーが外部ウェブサーバが使用するすべてのディレクトリに正しい権限を持っていることを確認してください。そうしないと、failed (XX: Permission denied) while reading upstream エラーが発生します。

  3. バンドルされていないウェブサーバを信頼できるプロキシのリストに追加します。

    通常、Linuxパッケージのインストールでは、バンドルされているNGINXのreal_ip モジュールで設定されたものが、信頼できるプロキシのリストのデフォルトになります。

    バンドルされていないWebサーバーの場合は、リストを直接設定する必要があり、GitLabと同じマシン上にない場合はWebサーバーの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ポートに接続する必要があります。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 を実行してください。

  5. 正しいウェブサーバーの設定をダウンロードしてください。

    GitLabのレシピリポジトリに行き、選択したwebserverディレクトリでLinuxパッケージ設定を探します。GitLabにSSLを使うかどうかに応じて、正しい設定ファイルを選んでください。変更する必要があるのは、YOUR_SERVER_FQDN に自分の FQDN を指定することと、SSL を使う場合は SSL キーが現在置かれている場所を指定することだけです。また、ログファイルの場所を変更する必要があるかもしれません。

NGINXのリッスンアドレスまたはアドレスの設定

デフォルトでは、NGINXはすべてのローカルIPv4アドレスで着信接続を受け入れます。アドレスのリストは/etc/gitlab/gitlab.rb で変更できます。

 # Listen on all IPv4 and IPv6 addresses
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のドキュメントを参照してください。

参照ポリシーヘッダの設定

デフォルトでは、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を再設定し、NGINXをHUPして、更新された設定で優雅にリロードするようにします：

    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

カスタムのNGINX設定をGitLabサーバーブロックに挿入

これらのカスタム設定は、gitlab.rb ファイルで同じ設定が定義されている場合に競合を引き起こす可能性があることに注意してください。

何らかの理由でGitLab用のNGINXserver ブロックにカスタム設定を追加する必要がある場合は、次の設定を使用できます。

# Example: block raw file downloads from a specific repository
nginx['custom_gitlab_server_config'] = "location ^~ /foo-namespace/bar-project/raw/ {\n deny all;\n}\n"

gitlab-ctl reconfigure を実行して NGINX の設定を書き換え、NGINX を再起動します。

これにより、/var/opt/gitlab/nginx/conf/gitlab-http.conf のserver ブロックの最後に定義された文字列が挿入されます。

備考

  • 新しいロケーションを追加する場合、以下の項目を追加する必要があります。

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

    を文字列または NGINX 設定に含める必要があるかもしれません。これらがないと、どのサブロケーションも 404 を返します。GitLab CE Issue #30619 を参照してください。

  • ルートの/ ロケーションや/assets ロケーションはgitlab-http.conf に既に存在するため、追加できません。

NGINX設定へのカスタム設定の挿入

既存のサーバーブロックを含めるなど、NGINX設定にカスタム設定を追加する必要がある場合は、次の設定を使用できます。

# Example: include a directory to scan for additional config files
nginx['custom_nginx_config'] = "include /etc/gitlab/nginx/sites-enabled/*.conf;"

/etc/gitlab/nginx/sites-available ディレクトリにカスタムサーバーブロックを作成する必要があります。これらを有効にするには、/etc/gitlab/nginx/sites-enabled ディレクトリにシンボリックリンクします：

  1. /etc/gitlab/nginx/sites-enabled ディレクトリを作成します。

  2. 以下のコマンドを実行します：

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

生成されたLet’s Encrypt SSL証明書の代替名として、サーバーブロックのドメインを追加できます。

gitlab-ctl reconfigure を実行して NGINX 設定を書き換え、NGINX を再起動します。カスタムサーバーブロックに変更を加えるたびに、NGINXのリロード（gitlab-ctl hup nginx ）またはNGINXの再起動（gitlab-ctl restart nginx ）を行う必要があります。

これにより、/var/opt/gitlab/nginx/conf/nginx.conf のhttp ブロックの最後に定義された文字列が挿入されます。

/etc/gitlab/ ディレクトリ内部のカスタム NGINX 設定は、アップグレード中およびsudo gitlab-ctl backup-etc が手動で実行されたときに/etc/gitlab/config_backup/ にバックアップされます。

カスタムエラーページ

custom_error_pages 、デフォルトのGitLabエラーページのテキストを変更することができます。404や502など、有効なHTTPエラーコードであれば何でも使えます。

例として、以下のようにするとデフォルトの404エラーページを変更できます。

nginx['custom_error_pages'] = {
  '404' => {
    'title' => 'Example title',
    'header' => 'Example header',
    'message' => 'Example message'
  }
}

この結果、404エラーページは以下のようになります。

custom 404 error page

gitlab-ctl reconfigure を実行して NGINX の設定を書き換え、NGINX を再起動します。

既存のPassenger/NGINXインストールを使用する場合

既存の Passenger/NGINX を使って GitLab をホストしたい場合でも、Linux パッケージを使ってアップデートやインストールを行うことができます。

note
NGINX を無効にすると、nginx.conf で手動で追加しない限り、Mattermost など Linux パッケージインストールに含まれる他のサービスにアクセスできなくなります。

設定

まず、組み込みのNGINXとPumaを無効にするために、/etc/gitlab/gitlab.rb ：

# Define the external url
external_url 'http://git.example.com'

# Disable the built-in nginx
nginx['enable'] = false

# Disable the built-in puma
puma['enable'] = false

# Set the internal API URL
gitlab_rails['internal_api_url'] = 'http://git.example.com'

# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['www-data']

変更を有効にするためにsudo gitlab-ctl reconfigure を実行してください。

note
8.16.0より古いバージョンを使用している場合は、再設定を成功させるためにUnicornサービスファイル(/opt/gitlab/service/unicorn)を手動で削除する必要があります。

Vhost (サーバーブロック)

note
GitLab 13.5 では Workhorse ソケットのデフォルトの場所が/var/opt/gitlab/gitlab-workhorse/socket から/var/opt/gitlab/gitlab-workhorse/sockets/socket に変更されました。13.5より古いバージョンからアップグレードする場合は、以下の設定を適宜更新してください。

次に、カスタム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;

  # Ensure Passenger uses the bundled Ruby version
  passenger_ruby /opt/gitlab/embedded/bin/ruby;

  # Correct the $PATH variable to included packaged executables
  passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

  # Make sure Passenger runs as the correct user and group to
  # prevent permission issues
  passenger_user git;
  passenger_group git;

  # Enable Passenger & keep at least one instance running at all times
  passenger_enabled on;
  passenger_min_instances 1;

  location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
    # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
    error_page 418 = @gitlab-workhorse;
    return 418;
  }

  location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
    # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
    error_page 418 = @gitlab-workhorse;
    return 418;
  }

  location ~ ^/api/v3/projects/.*/repository/archive {
    # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
    error_page 418 = @gitlab-workhorse;
    return 418;
  }

  # Build artifacts should be submitted to this location
  location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
      client_max_body_size 0;
      # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
      error_page 418 = @gitlab-workhorse;
      return 418;
  }

  # Build artifacts should be submitted to this location
  location ~ /ci/api/v1/builds/[0-9]+/artifacts {
      client_max_body_size 0;
      # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
      error_page 418 = @gitlab-workhorse;
      return 418;
  }

  # Build artifacts should be submitted to this location
  location ~ /api/v4/jobs/[0-9]+/artifacts {
      client_max_body_size 0;
      # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
      error_page 418 = @gitlab-workhorse;
      return 418;
  }


  # For protocol upgrades from HTTP/1.0 to HTTP/1.1 we need to provide Host header if its missing
  if ($http_host = "") {
  # use one of values defined in 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
    ## Some requests take more than 30 seconds.
    proxy_read_timeout      3600;
    proxy_connect_timeout   300;
    proxy_redirect          off;

    # Do not buffer Git HTTP responses
    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;

    ## The following settings only work with NGINX 1.7.11 or newer
    #
    ## Pass chunked request bodies to gitlab-workhorse as-is
    # proxy_request_buffering off;
    # proxy_http_version 1.1;
  }

  ## Enable gzip compression as per rails guide:
  ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
  ## WARNING: If you are using relative urls remove the block below
  ## See config/application.rb under "Relative url support" for the list of
  ## other files that need to be changed for relative url support
  location ~ ^/(assets)/ {
    root /opt/gitlab/embedded/service/gitlab-rails/public;
    gzip_static on; # to serve pre-gzipped version
    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;

それからsudo service nginx reload を実行してください。

有効化/無効化nginx_status

デフォルトでは、127.0.0.1:8060/nginx_status に NGINX health-check エンドポイントが設定され、NGINX サーバーの状態を監視します。

以下の情報が表示されます。 

Active connections: 1
server accepts handled requests
 18 18 36
Reading: 0 Writing: 1 Waiting: 0
  • アクティブな接続 - 開いている接続の合計です。
  • 3つの数値が表示されます。
    • すべて接続可。
    • 処理されたすべての接続。
    • 処理されたリクエストの総数。
  • 読み込み：NGINXがリクエストヘッダを読み込みます。
  • 書き込み：NGINXはリクエストボディを読み込み、リクエストを処理し、クライアントにレスポンスを書き込みます。
  • 待機：キープアライブ接続。この数は keepalive-timeout に依存します。

設定オプション

/etc/gitlab/gitlab.rb を編集します：

nginx['status'] = {
  "listen_addresses" => ["127.0.0.1"],
  "fqdn" => "dev.example.com",
  "port" => 9999,
  "options" => {
    "access_log" => "on", # Disable logs for stats
    "allow" => "127.0.0.1", # Only allow access from localhost
    "deny" => "all" # Deny access to anyone else
  }
}

このサービスが現在のインフラにとって有用でないと思われる場合は、このサービスを無効にすることができます：

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: Hostヘッダーが多すぎます

nginx['custom_gitlab_server_config'] の設定にproxy_set_header の設定がないことを確認し、代わりにgitlab.rb ファイルの‘proxy_set_headers’設定を使用してください。

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

Linux パッケージ・インストールはデフォルトで TLSv1 プロトコルをサポートしていません。このため、古いJavaベースのIDEクライアントでGitLabインスタンスとやりとりする際に接続のイシューが発生することがあります。このユーザーコメントにあったように、サーバーの暗号をアップグレードすることを強くお勧めします。

このサーバーの変更が不可能な場合は、/etc/gitlab/gitlab.rb の値を変更することで、以前の動作にデフォルトで戻すことができます：

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

秘密鍵と証明書の不一致

NGINXのログにx509 certificate routines:X509_check_private_key:key values mismatch) （Omnibusのデフォルトでは/var/log/gitlab/nginx/current ）が表示される場合、秘密鍵と証明書の不一致が考えられます。

これを修正するには、正しい秘密鍵と証明書を一致させる必要があります。

秘密鍵と証明書が正しいことを確認するには、秘密鍵と証明書のモジュラスが一致していることを確認します：

/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

リクエストエンティティが大きすぎます

NGINX ログにRequest Entity Too Large が表示される場合は、クライアントの最大ボディサイズを増やす必要があります。最大インポートサイズを大きくした場合、このエラーに遭遇する可能性があります。KubernetesベースのGitLabインストールでは、この設定の名前は異なります。

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を再設定し、NGINXを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を再設定し、NGINXを起動して更新された設定でリロードするようにします：

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl hup nginx

502: Bad Gateway SELinux と外部の NGINX を使う場合

SELinux が有効になっている Linux サーバーでは、外部 NGINX を設定した後、GitLab UI にアクセスすると502: Bad Gateway というエラーが表示されることがあります。このエラーはNGINXのログでも確認できます：

connect() to unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket failed (13:Permission denied) while connecting to upstream

次のいずれかのオプションを選択して修正してください：

  • SELinuxポリシーのアップデートが含まれるGitLab 14.3以降にアップデートしてください。

  • 手動でポリシーを取得して更新してください：

     wget https://gitlab.com/gitlab-org/omnibus-gitlab/-/raw/a9d6b020f81d18d778fb502c21b2c8f2265cabb4/files/gitlab-selinux/rhel/7/gitlab-13.5.0-gitlab-shell.pp
 semodule -i gitlab-13.5.0-gitlab-shell.pp

Branch 'branch_name' was not found in this project's repository Web IDEと外部のNGINXを使用している場合

このエラーが発生した場合は、NGINX設定ファイルのproxy_pass に末尾のスラッシュがあるかどうかを確認し、それを削除してください：

  1. NGINX設定ファイルを編集します：

    proxy_pass https://1.2.3.4;

  2. NGINXを再起動します：

    sudo systemctl restart nginx

GitLabはログに502エラーとworker_connections are not enough 。

ログにworker_connections are not enough エラーが表示される場合は、NGINX ワーカーの接続を高い値に設定してください：

  1. /etc/gitlab/gitlab.rb を編集します：

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

  2. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

デフォルト値は10240接続です。