Nginx 설정 파일을 도메인별로 분리하기 시작한 이유

처음엔 /etc/nginx/nginx.conf에 server {} 블록을 계속 추가했다. 도메인이 2~3개일 때는 그래도 괜찮았다. 그런데 서비스가 늘어나면서 파일이 300줄을 넘어가기 시작했고, 한 도메인 설정을 고치다가 괄호를 하나 빠뜨려서 nginx -t에서 에러가 나는 일이 반복됐다.

sites-available / sites-enabled 구조

Debian/Ubuntu 기반이라면 Nginx 패키지가 기본으로 이 구조를 지원한다.

/etc/nginx/
  nginx.conf                # 메인 설정, includes를 통해 사이트 파일 로드
  sites-available/          # 실제 설정 파일이 여기 있음
    example.com
    api.example.com
    blog.example.com
  sites-enabled/            # sites-available의 심볼릭 링크
    example.com -> ../sites-available/example.com
    api.example.com -> ../sites-available/api.example.com

nginx.conf에는 다음 줄이 있어서 sites-enabled/의 파일들을 자동으로 읽는다.

include /etc/nginx/sites-enabled/*;

새 도메인 추가하고 활성화하는 흐름

# 1. sites-available에 파일 생성
sudo vim /etc/nginx/sites-available/blog.example.com

# 2. sites-enabled에 링크 추가
sudo ln -s /etc/nginx/sites-available/blog.example.com \
           /etc/nginx/sites-enabled/

# 3. 설정 문법 검사
sudo nginx -t

# 4. 문제 없으면 리로드
sudo systemctl reload nginx

비활성화할 때는 sites-enabled에서 링크만 지우고 리로드하면 된다. sites-available의 원본 파일은 그대로 남아 있어서 나중에 다시 켜기 쉽다.

sudo rm /etc/nginx/sites-enabled/blog.example.com
sudo systemctl reload nginx

설정 파일 예시

# /etc/nginx/sites-available/blog.example.com
server {
    listen 80;
    server_name blog.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name blog.example.com;

    ssl_certificate /etc/letsencrypt/live/blog.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

분리하고 나서 달라진 점

설정 파일이 도메인 단위로 나뉘어 있으면, 특정 도메인의 설정을 고칠 때 다른 도메인에 영향을 줄 걱정이 없다. nginx -t가 실패해도 어느 파일에서 에러가 났는지 바로 보인다. 새 도메인을 추가하거나 제거할 때도 링크 하나만 건드리면 된다.

하나의 큰 파일을 관리하는 것보다 작은 파일 여러 개를 관리하는 게 오류가 났을 때 범위를 좁히기 훨씬 쉽다.