재시작 대신 다시 로드하기
다시 로드는 NGINX가 설정을 다시 읽도록 합니다. 새 워커 프로세스를 시작하고 기존 프로세스는 처리 중인 요청을 마칠 수 있게 하므로 방문자는 보통 아무 변화도 느끼지 못합니다. 새 설정을 적용할 수 없으면 NGINX는 기존 설정으로 계속 실행됩니다. 재시작은 먼저 서비스를 중지하므로 연결이 끊기며, 설정이 잘못되면 서비스가 다시 시작되지 않을 수도 있습니다.
변경할 파일 백업하기
편집 전에 파일 옆에 날짜가 포함된 이름으로 복사본을 만드세요. conf.d/*.conf 또는 sites-enabled/*처럼 NGINX가 와일드카드로 읽어 들이는 디렉터리에 복사본을 두지 마세요. 복사본도 함께 로드됩니다. Debian과 Ubuntu에서는 sites-available의 파일을 편집하세요. sites-enabled의 항목은 보통 해당 파일을 가리키는 링크일 뿐입니다.
sudo cp -a /etc/nginx/sites-available/example.conf /root/example.conf.$(date +%Y%m%d-%H%M%S)검사한 다음 다시 로드하기
nginx -t는 구문과 인증서처럼 설정에서 참조하는 파일을 검사합니다. nginx -T를 사용하면 포함된 파일까지 반영한 전체 설정을 볼 수 있습니다. 검사에 통과한 경우에만 다시 로드하세요. 명령을 &&로 연결하면 이 조건을 지킬 수 있습니다. 검사만으로는 설정이 의도한 대로 작동하는지 알 수 없으므로 이후에 웹사이트를 열어 확인하세요.
sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | less
curl -I https://example.com/문제가 발생했을 때
백업 복사본을 복원하고 다시 검사한 뒤 다시 로드하세요. 서비스가 중지되었다면 오류 로그와 journal에서 원인을 확인할 수 있습니다. 이미 사용 중인 포트, 누락된 인증서, 중복된 서버 이름에 관한 메시지를 찾아보세요.
sudo cp -a /root/example.conf.20261031-120000 /etc/nginx/sites-available/example.conf
sudo nginx -t && sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log다시 로드로 처리되지 않는 부분
WebSockets 같은 장기 연결은 종료될 때까지 기존 워커에 남으므로 기존 워커가 한동안 계속 실행되며 추가 메모리를 사용할 수 있습니다. 패키지 업그레이드가 서비스를 자동으로 재시작할 수도 있습니다. 큰 변경 사항은 인증서와 리디렉션을 포함해 먼저 테스트 서버에서 검사하세요.
CH-J Server Manager의 NGINX Manager
NGINX Manager는 Linux 서버의 관리 대상 NGINX 디렉터리에 있는 설정 파일을 파일당 최대 512 KiB까지 편집합니다. 저장할 때 애플리케이션은 .chj-backup- 접미사가 붙은 백업을 만들고 nginx -t를 실행하며, 검사에 성공한 경우에만 변경을 유지합니다. 다시 로드하려면 사용자의 명시적인 확인이 필요하며 시작 전에 검사를 한 번 더 실행합니다. sites-enabled의 활성화용 심볼릭 링크는 교체되지 않습니다. sites-available의 해당 파일을 편집하세요.