Nginx 서비스 제어: 일반적인 관리 명령어 실용 가이드

Nginx 서비스 제어는 복잡하지 않지만, 실제 사용자가 연결되어 있을 때 reload, restart, stop, nginx -s quit의 차이는 중요합니다. 가장 안전한 습관은 간단합니다: 먼저 설정을 테스트하고, graceful reload로 충분할 때는 reload를 사용하며, 전체 서비스 사이클이 실제로 필요한 경우에만 restart를 사용하세요.

대부분의 Linux 서버는 현재 systemd를 사용하므로 systemctl이 가장 자주 사용하는 명령어입니다. 오래된 배포판에서는 여전히 service 명령어를 사용할 수 있습니다. Nginx 바이너리는 직접 시그널도 수용하며, 이는 서비스 관리자를 거치지 않고 설정을 리로드하거나 로그를 다시 열어야 할 때 유용합니다.

Nginx 서비스 관리 이해하기

Nginx 서비스 관리 명령어는 일반적으로 systemctl(systemd를 사용하는 시스템, 현대 Linux 배포판에서 일반적) 또는 service(오래된 init 시스템)와 같은 시스템 유틸리티를 사용하여 실행됩니다. 특정 명령어는 운영 체제와 서비스 관리 프레임워크에 따라 약간 다를 수 있습니다.

Nginx 시작하기

Nginx 웹 서버를 실행하려면 start 명령어를 사용합니다. 이 명령어는 Nginx 프로세스를 시작하여 들어오는 연결을 수락할 준비를 합니다.

• systemctl 사용 (현대 시스템에 권장):

  sudo systemctl start nginx
  

• service 사용 (오래된 시스템):

  sudo service nginx start
  

Nginx가 시작되면 설정 파일을 읽고 설정에 지정된 포트(일반적으로 HTTP는 80, HTTPS는 443)에서 수신 대기를 시작합니다.

Nginx 중지하기

Nginx 웹 서버를 정상적으로 종료하려면 stop 명령어를 사용합니다. 이 명령어는 Nginx에 새 연결 수락을 중지하고 기존 연결이 완료된 후 종료하도록 신호를 보냅니다.

• systemctl 사용:

  sudo systemctl stop nginx
  

• service 사용:

  sudo service nginx stop
  

systemd 시스템에서 stop은 서비스 관리자에게 Nginx를 중지하도록 요청합니다. 활성 요청이 완료될 시간이 있는지 여부는 서비스 구성과 신호 동작에 따라 다릅니다. Nginx 수준의 정상 종료가 특별히 필요한 경우 sudo nginx -s quit이 알아야 할 직접 명령어입니다.

Nginx 재시작하기

restart 명령어는 stop과 start의 조합입니다. 전체 서비스 사이클이 필요한 중요한 설정 변경 후에 자주 사용됩니다. 이 명령어는 서비스를 일시적으로 중단시키므로 주의해서 사용하세요.

• systemctl 사용:

  sudo systemctl restart nginx
  

• service 사용:

  sudo service nginx restart
  

이는 특정 유형의 설정 업데이트를 적용하는 일반적인 명령어입니다.

Nginx 리로드하기

reload 명령어는 활성 연결을 끊지 않고 설정 변경을 적용하는 가장 유용한 Nginx 명령어 중 하나입니다. Nginx는 작업자 프로세스를 정상적으로 재시작하여 새 설정을 적용할 수 있도록 합니다. 대부분의 설정 업데이트에 선호되는 방법입니다.

• systemctl 사용:

  sudo systemctl reload nginx
  

• service 사용:

  sudo service nginx reload
  

팁: 가동 중지 시간을 최소화하려면 가능하면 restart 대신 reload를 사용하세요.

새 설정이 유효하지 않아 리로드가 실패하면 일반적으로 이전 작업자 프로세스가 이전 설정으로 계속 실행됩니다. 이것이 일상적인 편집 중에 restart보다 reload가 더 안전한 이유 중 하나입니다. 그래도 항상 먼저 nginx -t를 실행하여 장애 발생 시 동작에 의존하지 않도록 하세요.

Nginx 상태 확인하기

Nginx가 실행 중인지, 실패했는지, 또는 현재 상태를 확인하려면 status 명령어를 사용합니다.

• systemctl 사용:

  sudo systemctl status nginx
  

• service 사용:

  sudo service nginx status
  

이 명령어는 서비스가 활성 상태인지 여부, 프로세스 ID(PID), 최근 로그 항목 등 빠른 진단에 유용한 정보를 제공합니다.

Nginx 설정 테스트하기

설정 변경을 적용하기 전, 특히 restart 또는 reload 후에는 설정 파일에 구문 오류가 있는지 테스트하는 것이 중요합니다. Nginx는 이를 위한 내장 명령어를 제공합니다.

설정 구문 테스트하기

이 명령어는 변경 사항을 실제로 적용하지 않고 전체 Nginx 설정에서 구문 오류를 확인합니다. 발견된 문제를 보고합니다.

nginx -t

예제 출력 (성공):

test is successful
nginx: configuration file /etc/nginx/nginx.conf test is successful

예제 출력 (오류):

nginx: [emerg] unknown directive "server_name " in /etc/nginx/sites-available/default:10
nginx: configuration file /etc/nginx/nginx.conf test failed

경고: 설정 파일을 수정한 후, 그리고 Nginx를 리로드하거나 재시작하기 전에 항상 nginx -t를 실행하세요. 이 간단한 단계는 구문 오류로 인한 예상치 못한 가동 중지를 방지할 수 있습니다.

설정이 사용자 정의 기본 설정 파일을 사용하는 경우 명시적으로 전달하세요:

sudo nginx -t -c /path/to/nginx.conf

포함된 파일을 포함한 전체 로드된 설정을 보려면 다음을 사용하세요:

sudo nginx -T

공유 터미널이나 티켓에서 nginx -T를 사용할 때는 주의하세요. 설정 파일에서 민감한 경로, 업스트림 이름 또는 주석이 출력될 수 있습니다.

부팅 시 Nginx 활성화하기

Nginx를 한 번 시작하는 것과 재부팅 후 활성화하는 것은 다릅니다. systemd 시스템에서 다음을 사용하세요:

sudo systemctl enable nginx

즉시 활성화하고 시작하려면:

sudo systemctl enable --now nginx

부팅 시 자동 시작을 중지하려면:

sudo systemctl disable nginx

이는 패키지 설치 후 유용합니다. 설정 중에 Nginx를 수동으로 시작하고 몇 주 동안 완벽하게 작동하다가 아무도 서비스를 활성화하지 않아 유지 보수 재부팅 후 중단된 서버를 많이 보았습니다.

서비스 작업 후 로그 확인하기

시작 또는 리로드 실패 후 명령 프롬프트를 응시하지 마세요. systemd와 Nginx에 무슨 일이 일어났는지 물어보세요:

sudo journalctl -u nginx -n 100 --no-pager

그리고 Nginx 오류 로그를 확인하세요:

sudo tail -n 100 /var/log/nginx/error.log

무엇을 찾아야 하는지 알면 일반적인 메시지는 충분히 직접적입니다:

• bind() to 0.0.0.0:80 failed: 다른 프로세스가 이미 포트를 사용 중이거나 권한이 잘못되었습니다.
• unknown directive: 오타, 누락된 모듈 또는 잘못된 Nginx 빌드에서 사용된 지시문입니다.
• host not found in upstream: DNS 실패 또는 업스트림 이름이 잘못되었습니다.
• permission denied: Nginx가 파일을 읽거나, 로그를 쓰거나, 인증서 키에 액세스할 수 없습니다.

포트 충돌의 경우 일반적으로 다음이 답을 제공합니다:

sudo ss -ltnp | grep -E ':80|:443'

다른 웹 서버가 동일한 포트에서 수신 중인 경우 어떤 서비스가 소유해야 하는지 결정하세요. 이유를 알지 못하면 프로세스를 그냥 종료하지 마세요.

실제 상황에서 리로드 대 재시작

대부분의 설정 편집 후에는 reload를 사용하세요: 새 서버 블록, 변경된 프록시 헤더, 업데이트된 시간 제한 값, 새 리디렉션, 변경된 로그 형식 또는 조정된 정적 파일 위치. Nginx는 새 설정으로 새 작업자를 시작하고 이전 작업자가 기존 작업을 완료하도록 합니다.

서비스 자체가 깨끗한 시작이 필요할 때 restart를 사용하세요. 예를 들어 변경된 systemd 제한, 서비스가 상속하는 변경된 환경, 바이너리가 변경된 패키지 업그레이드 또는 마스터 프로세스가 비정상적인 상황이 있습니다. 재시작은 트래픽을 일시적으로 중단시킬 수 있으므로 의도적으로 수행하세요.

서비스를 중단하려면 stop을 사용하세요. 당연해 보이지만 유지 보수 중에 중요합니다. 로드 밸런서가 Nginx를 중지한 후에도 서버로 트래픽을 계속 보내면 사용자는 실패를 보게 됩니다. 가능하면 먼저 서버를 로드 밸런서에서 드레인하세요.

수동 로그 로테이션 후 로테이션 프로세스가 Nginx에 신호를 보내지 않는 경우 nginx -s reopen을 사용하세요. 다시 열지 않으면 Nginx는 보이는 로그 파일이 이동한 후에도 이전 파일 핸들에 계속 쓸 수 있습니다.

패키지 이름 및 서비스 이름

대부분의 배포판은 서비스를 nginx라고 부르지만 모든 환경이 동일하지는 않습니다. systemctl status nginx가 유닛이 존재하지 않는다고 말하면 일치하는 유닛을 나열하세요:

systemctl list-unit-files | grep -i nginx

일부 호스트에서는 Nginx가 사용자 정의 패키지, 컨테이너, 제어판 또는 번들 스택에서 설치될 수 있습니다. 이러한 경우 systemd 명령어가 실제로 사용 중인 인스턴스를 제어하지 못할 수 있습니다. 바이너리와 설정 경로를 확인하세요:

which nginx
nginx -V

nginx -V는 빌드 옵션과 모듈 경로를 출력합니다. 또한 설정 지시문이 한 서버에서는 작동하지만 모듈이 없어 다른 서버에서는 실패할 때 유용합니다.

Nginx가 Docker에서 실행되는 경우 호스트의 서비스 명령어는 관련이 없을 수 있습니다. 대신 컨테이너 워크플로를 통해 검사하고 리로드하세요:

docker ps
docker exec <container> nginx -t
docker exec <container> nginx -s reload

프로세스를 소유한 오케스트레이션 도구를 사용하세요. Kubernetes의 경우 일반적으로 ConfigMap 또는 Ingress 리소스를 변경하고 컨트롤러가 리로드하도록 하는 것을 의미하며, 영구적인 수정을 위해 포드에 셸로 접속하지 않습니다.

몇 가지 장애 발생 시 명령어 시퀀스

설정 변경으로 리로드가 중단된 경우:

sudo nginx -t
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log

nginx -t가 표시한 첫 번째 구문 또는 파일 오류를 수정한 후 다시 테스트하세요. 구문 테스트가 이미 작동하지 않을 것이라고 말할 때 "작동하는지 확인"하기 위해 서비스를 재시작하지 마세요.

사이트가 다운되었고 Nginx가 실행 중인지 확실하지 않은 경우:

sudo systemctl status nginx
sudo ss -ltnp | grep -E ':80|:443'
curl -I http://127.0.0.1/

이것은 세 가지 질문을 분리합니다: 서비스가 활성 상태인지, 예상 포트에서 수신 중인 것이 있는지, 로컬 HTTP 요청이 작동하는지. 로컬 curl이 작동하지만 공개 사이트가 실패하면 DNS, 방화벽 규칙, 클라우드 보안 그룹, 로드 밸런서 또는 TLS를 확인하세요.

인증서 갱신 후 HTTPS가 실패한 경우:

sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager

인증서 경로 오류는 일반적으로 구문 테스트 또는 오류 로그에 나타납니다. 인증서 키가 root가 읽을 수 있지만 Nginx 작업자 사용자가 필요한 디렉토리에 액세스할 수 없는 경우 권한 문제도 일반적입니다. 개인 키의 권한에 주의하세요. 오류를 무음화하기 위해 전 세계에서 읽을 수 있도록 만들지 마세요.

로테이션 후 로그 업데이트가 중단된 경우:

sudo nginx -s reopen
sudo ls -l /var/log/nginx/
sudo tail -f /var/log/nginx/access.log

많은 logrotate 패키지가 이미 이 작업을 처리합니다. 이 명령어는 로그를 수동으로 로테이션하거나 사용자 정의 로깅 설정을 실행할 때 여전히 유용합니다.

하지 말아야 할 것

일반 관리 방법으로 Nginx 작업자 프로세스에 대해 kill -9를 실행하지 마세요. 프로세스에 작업을 완료하거나 정리할 기회를 주지 않습니다. 진정으로 멈춘 프로세스를 처리하고 부작용을 이해하지 않는 한 systemctl stop, systemctl restart 또는 Nginx 시그널 명령어를 사용하세요.

sites-available에서 파일을 편집하고 활성화되어 있다고 가정하지 마세요. Debian 스타일 레이아웃에서 사이트는 일반적으로 sites-enabled에 심볼릭 링크가 필요합니다. 다른 배포판에서는 레이아웃이 conf.d를 사용할 수 있습니다. nginx -T는 Nginx가 실제로 로드하는 것을 확인하는 가장 빠른 방법입니다.

sudo를 잊지 마세요. 권한이 없는 사용자로 nginx -t를 실행하면 서비스 자체는 읽을 수 있지만 인증서 키나 포함된 파일을 읽을 수 없어 실패할 수 있습니다. 프로덕션에서 서비스가 실행되는 것과 동일한 방식으로 테스트하세요:

sudo nginx -t

재시작을 반사적으로 사용하지 마세요. 재시작은 필요하지만 reload보다 무겁습니다. 조용한 유지 보수 기간 동안에는 문제가 되지 않을 수 있습니다. 바쁜 판매 이벤트 중에는 문제가 됩니다.

Nginx 프로세스 관리 (고급)

systemctl과 service는 전체 Nginx 서비스를 관리하는 주요 도구이지만, 특정 시그널과 함께 nginx 명령어를 사용하여 Nginx 마스터 프로세스와 직접 상호 작용할 수도 있습니다.

Nginx에 시그널 보내기

Nginx는 작업자 프로세스를 관리하는 마스터 프로세스를 사용합니다. 마스터 프로세스에 시그널을 보내 동작에 영향을 줄 수 있습니다. 가장 일반적인 방법은 마스터 프로세스 PID를 찾아 kill 명령어를 사용하거나, 더 편리하게 nginx -s <signal>을 사용하는 것입니다.

• 설정 리로드: 위의 reload 명령어와 유사합니다.

  sudo nginx -s reload
  

• 정상 종료: stop 명령어와 유사합니다.

  sudo nginx -s quit
  

• 빠른 종료: 현재 요청이 처리될 때까지 기다리지 않고 모든 작업자 프로세스를 즉시 종료합니다.

  sudo nginx -s stop
  

• 로그 파일 다시 열기: 로그 파일을 수동으로 로테이션하거나 로그가 다른 위치에 기록되는 경우 유용합니다.

  sudo nginx -s reopen
  

nginx -s <signal>을 사용하려면 Nginx가 마스터 프로세스 PID 파일의 위치를 알아야 합니다. 기본적으로 이는 종종 /var/run/nginx.pid 또는 /run/nginx.pid입니다. 필요한 경우 -c 옵션을 사용하여 다른 PID 파일 위치를 지정할 수 있지만, 표준 설치에서는 거의 필요하지 않습니다.

안전한 일상 워크플로

일반적인 설정 편집의 경우 다음 워크플로를 사용하세요:

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx

그런 다음 클라이언트에서 사이트를 확인하세요:

curl -I https://example.com/

서비스가 시작되지 않으면 재시작을 반복하지 마세요. 상태 출력과 로그를 읽고, 첫 번째 실제 오류를 수정하고, 다시 테스트한 다음 시작하거나 리로드하세요. Nginx 서비스 제어 명령어는 작지만 올바른 순서로 사용하면 잘못된 설정 편집이 피할 수 있는 가동 중지로 이어지는 것을 방지합니다.