GitLab Nginx Reverse Proxy¶

앞단 Nginx가 gitlab.example.com 요청을 받아
내부 네트워크의 GitLab 으로 전달하는 구성을 정의함.

주의: Reverse Proxy 설정은 사전 준비할 수 있으나, 실제 Nginx reload/적용 시점은 GitLab의 내부 listen 포트(8081) 반영 후로 잡는 것을 권장함. 초기 설치 시 Omnibus 기본 Nginx가 80/443을 사용하려고 할 수 있기 때문임.

1. 개요¶

다음 구조를 기준으로 설정함.

구조: Client → Nginx (443, SSL 종단) → GitLab (127.0.0.1:8081 또는 192.168.0.100:8081)
외부 URL: https://gitlab.example.com
외부 노출: 별도 Reverse Proxy(Nginx) 또는 Gateway(Nginx) 사용
운영 원칙: GitLab은 외부 인터넷에 직접 노출하지 않으며, Reverse Proxy를 통해서만 접근함
GitLab 내부 포트: 8081 (Reverse Proxy(Nginx)와 통신용, Loopback 또는 내부 네트워크 전용)
GitLab SSH 포트: 2222

1.1. 운영 정책¶

GitLab은 외부에 직접 노출하지 않음
GitLab Web Service 는 내부 포트(8081)만 사용
GitLab SSH Port 는 2222 포트로 분리 운영
TLS 종료는 Reverse Proxy(Nginx)에서 수행

2. Upgrade 헤더용 map¶

WebSocket 지원을 위해 http 블록 또는 공통 include에 추가함.

ex) /etc/nginx/nginx.conf

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

3. HTTP → HTTPS 리다이렉트¶

server {
    listen 80;
    listen [::]:80;
    server_name gitlab.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

4. HTTPS Reverse Proxy¶

GitLab 배치 방식에 따라 proxy_pass 대상이 달라짐.

단일 서버 구성 (Nginx와 GitLab이 같은 서버)
- Reverse Proxy(Nginx) 와 GitLab을 동일 서버에서 운영하는 구조
분리 구성 (Nginx: 192.168.0.154, GitLab: 192.168.0.100)
- Gateway(Nginx) 와 GitLab을 서로 다른 서버에 분리하여 운영하는 구조
- GitLab Web Service를 반드시 내부 포트(8081)로만 전달함. ex) proxy_pass http://192.168.0.100:8081;

⚠️ 아래 예시에서는 구성에 맞는 proxy_pass 한 줄만 선택하여 사용함. ⚠️ 두 설정을 동시에 활성화하지 않도록 주의함.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name gitlab.example.com;

    ssl_certificate     /etc/letsencrypt/live/gitlab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/gitlab.example.com/privkey.pem;
    include             /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam         /etc/letsencrypt/ssl-dhparams.pem;

    client_max_body_size 0;

    proxy_connect_timeout 300s;
    proxy_send_timeout    3600s;
    proxy_read_timeout    3600s;
    send_timeout          3600s;

    location / {
        # 단일 서버 구성 (Nginx와 GitLab이 같은 서버)
        # proxy_pass http://127.0.0.1:8081;

        # 분리 구성 (Nginx: `192.168.0.154`, GitLab: `192.168.0.100`)
        # proxy_pass http://192.168.0.100:8081;

        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_request_buffering off;

        proxy_set_header Host              $host;
        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_set_header X-Forwarded-Ssl   on;
        proxy_set_header X-Forwarded-Port  443;
        proxy_set_header X-Forwarded-Host  $host;

        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

5. 선택 보안 정책¶

사내망 또는 VPN 전용 GitLab로 운영하는 경우, 앞단 Nginx 에서 접근 IP를 제한할 수 있음. 앞단 Nginx에서 1차 접근 제어를 수행하기 위한 설정임.

예:

server {
    ...
    allow 192.168.0.0/24; # 사내 네트워크 대역만 접근 허용함
    allow 127.0.0.1; # 로컬 서버에서의 점검 및 내부 접근을 허용함
    deny all; # 위에서 허용한 대역 외의 모든 접근을 차단함
    ...
}

외부 고정 IP 또는 VPN 고정 IP로 운영 접근이 필요한 경우 allow에 명시적으로 추가함. 예: 개발자의 집 IP가 59.9.192.208일 때 allow 59.9.192.208; 추가

즉, Nginx 레벨에서 먼저 접근 가능한 대상을 제한하고, 세부 포트 허용 정책은 방화벽 문서 기준으로 별도 적용함. 본 설정은 Nginx 레벨의 1차 접근 제어이며, 최종 허용 정책은 firewalld 정책과 함께 일관되게 유지함

6. 적용¶

sudo nginx -t
sudo systemctl restart nginx

7. 동작 확인¶

curl -I http://gitlab.example.com
curl -I https://gitlab.example.com

확인 항목:

HTTP 요청이 HTTPS로 리다이렉트됨
HTTPS 응답이 정상 반환됨 (200)
301, 302 응답 시 리다이렉트 루프 여부를 반드시 확인함
GitLab 로그인 페이지가 정상 노출됨
Redirect Loop가 발생하지 않음