일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- Elasticsearch
- kotlin coroutine
- AWS EKS
- 티스토리챌린지
- golang
- Java
- CKA
- Pinpoint
- aws
- mysql 튜닝
- 정보처리기사 실기
- 기록으로 실력을 쌓자
- 정보처리기사실기 기출문제
- kotlin
- minikube
- 정보처리기사 실기 기출문제
- PETERICA
- Kubernetes
- 공부
- 코틀린 코루틴의 정석
- AI
- CloudWatch
- Linux
- 오블완
- Spring
- kotlin querydsl
- APM
- CKA 기출문제
- docker
- IntelliJ
- Today
- Total
피터의 개발이야기
[Nginx] NGINX 기설 설정 파일의 구조와 사용법 본문
ㅁ 들어가며
보안점검을 받으면서 Nginx의 설정파일을 많이 공부하게 되었다. 설정 파일의 구조와 그 의미를 이해해야지 보안조치사항에 대응을 할 수 있다. 이번 글에서는 nginx의 config를 구성하는 방법을 정리하였다.
ㅁ NGINX 설정 파일 위치
ㅇ 기본적으로 /etc/nginx/nginx.conf에 위치하지만, OS 및 설치 방식에 따라 다를 수 있다.
ㅇ 개별적인 서버 블록 설정은 /etc/nginx/conf.d/*.conf 또는 /etc/nginx/sites-available/에 있을 수 있다.
ㅁ NGINX 설정 파일 기본 구조
user nginx; # 실행 사용자 지정
worker_processes auto; # 사용 가능한 CPU 코어 수에 맞게 설정
events {
worker_connections 1024; # 하나의 워커 프로세스가 처리할 수 있는 최대 연결 수
}
http {
include mime.types; # MIME 타입 포함
default_type application/octet-stream;
sendfile on; # sendfile 기능 활성화 (파일 전송 최적화)
keepalive_timeout 65; # keep-alive 유지 시간 설정
server {
listen 80; # HTTP 80 포트에서 요청 수락
server_name example.com; # 서버 도메인 지정
location / {
root /usr/share/nginx/html; # 문서 루트 설정
index index.html index.htm;
}
location /api/ {
proxy_pass http://backend:5000; # 백엔드 서버로 프록시 요청 전달
}
error_page 404 /404.html; # 404 오류 시 사용자 지정 페이지 제공
}
}
ㅁ 주요 설정 항목
worker_processes
ㅇ 워커 프로세스 개수 설정)
ㅇ worker_processes auto; → CPU 코어 수에 맞게 자동 설정한다.
events 블록
ㅇ NGINX가 클라이언트 요청을 어떻게 처리할지 결정하는 부분
ㅇ worker_connections 값은 한 워커 프로세스가 동시에 처리할 수 있는 최대 연결 수 (기본값: 1024)
http 블록
ㅇ HTTP 관련 전역 설정
ㅇ MIME 타입, 기본 파일 형식, 캐시 및 압축 설정 가능하다.
server 블록
ㅇ 각 서버에 대한 개별 설정을 정의 (가상 호스트 개념)
ㅇ listen 80; → HTTP 포트 80에서 수신
ㅇ server_name example.com; → 해당 도메인에서 요청 처리
location 블록
ㅇ 요청 경로에 따른 처리 방식 지정
ㅇ /api/ 요청을 백엔드 서버(http://backend:5000)로 프록시하는 예제
ㅇ root 지정을 통해 정적 파일 제공 가능
proxy_pass (프록시 설정)
ㅇ 백엔드 서비스와 연동할 때 사용한다.
location /api/ {
proxy_pass http://127.0.0.1:5000;
}
ㅇ /api/ 요청이 로컬의 5000 포트에서 실행 중인 애플리케이션으로 전달됨
error_page (커스텀 에러 페이지)
특정 오류 코드에 대한 사용자 지정 페이지 설정
error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}
ㅁ SSL 인증서 설정
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
root /var/www/html;
index index.html;
}
}
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri; # HTTP -> HTTPS 리디렉션
}
ㅇ 443포트에 ssl 설정을 listen하는 가상 호스트를 설정하였다.
ㅇ ssl pem키를 설정하여 https를 활성화 한다.
ㅁ Gzip 압축 활성화
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
ㅁ IP 접근 차단 설정 방법
server {
listen 80 default_server;# 모든 HTTP 요청에 대해 이 서버 블록이 기본으로 사용
server_name _; # 모든 호스트 이름에 매치
return 444; # Nginx에서 정의한 특별한 상태 코드로, 응답 없이 연결을 종료
}
server {
listen 443 ssl default_server; # 모든 HTTPS 요청에 대해 이 서버 블록이 기본으로 사용
server_name _; # 모든 호스트 이름에 매치
ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;
return 444; Nginx에서 정의한 특별한 상태 코드로, 응답 없이 연결을 종료
}
ㅇ listen 80 default_server와 listen 443 ssl default_server: 모든 HTTP 및 HTTPS 요청에 대해 이 서버 블록이 기본으로 사용
ㅇ server_name _: 모든 호스트 이름에 매치
ㅇ return 444: Nginx에서 정의한 특별한 상태 코드로, 응답 없이 연결을 종료
ㅇ 필요성
- 보안 취약점 노출
- 의도하지 않은 웹사이트 노출
ㅁ 캐시 설정 (정적 파일)
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg)$ {
expires 30d; # 30일
access_log off;
}
ㅇ 정적 파일에 대해 캐싱처리가 가능하다.
ㅇ 이미지, CSS, JS 파일을 30일 동안 캐싱하여 성능 최적화한다.
ㅁ NGINX 설정 테스트 및 적용
ㅇ 문법적 오류를 모르면 다시 로그를 확인하고 해당 부분을 수정해야했다.
ㅇ 재시작 전에 미리 체크하면 나중에 작동하지 않아 로그를 확인하는 수고를 덜할 수 있다.
nginx -t
ㅇ 설정파일 문법을 검사한다.
ㅇ "syntax is ok" 메시지가 나오면 성공이다.
systemctl restart nginx # NGINX 재시작
systemctl reload nginx # 설정 파일만 다시 로드 (끊김 없이 반영)
ㅇ NGINX 재시작 방법이다.
tail -f /var/log/nginx/access.log # 접근 로그
tail -f /var/log/nginx/error.log # 오류 로그
ㅇ 엑세스와 에러 로그의 위치를 확인해야한다.
ㅁ 마무리
niginx의 설정방법에 대해서 정리하면서 보안조치 사항의 의미를 이해하는데 도움이 되었다. 보안의 목적은 취약점 노출을 최소화하기 위해 default 설정들에 대한 여지를 두지 않도록 설정하는데 있었다. 다 적지는 못했지만, 불필요한 post, option의 유입을 막는 것도 그 예이다. 설정하고, 설정을 테스트하고 재시작하는 방법도 작업의 속도를 높이는 방법 중이 하나였다.
ㅁ 함께 보면 좋은 사이트
ㄴ 3-4. server 블록: 여러 가상호스트 설정 방법을 정리
ㄴ 3-5. location 블록: 가상 호스트의 여러 api 중 의 여러 댑스 처리방법 정리, location / location ~* ^/(.*)/test/
'DevOps > nginx' 카테고리의 다른 글
[Nginx] NGINX의 End of Life (EOL) 정책 정리 (0) | 2025.03.06 |
---|---|
[Nginx] Nginx의 허용IP와 Proxy_pass 설정 (0) | 2024.10.26 |
[Nginx] Nginx에서 특정 URL만 허용하는 방법 (0) | 2024.09.03 |
Docker로 Nginx 웹서버 구동해보기 | Docker 파일복사(로컬 - 컨테이너) | Docker 컨테이너 unzip 설치하기 (1) | 2023.12.07 |