16강 / 20강

nginx — 손님을 맞이하는 앞단

리버스 프록시, 그리고 502 의 정체

쇼핑몰은 127.0.0.1:8000 에서 돌고 있습니다. 그런데 손님은 shop.example.com 으로 들어와요. 게다가 127.0.0.1 은 이 컴퓨터 자신이라는 뜻이라 바깥에서 닿지도 않습니다.

왜 일부러 바깥에서 못 닿게 해 놨을까요? 앱을 인터넷에 직접 노출하지 않기 위해서입니다. 대신 nginx 를 앞에 세워 손님을 맞게 합니다.

🌍손님shop.example.com

→

🏠nginx80번 포트에서 대기

→

🧪gunicorn127.0.0.1:8000

→

🐍app.pyFlask 가 판단

고등학생손님을 맞이하는 앞단

앱이 8000번 포트에서 돕니다. 그런데 손님은 80/443 으로 오죠.

앱을 직접 인터넷에 노출하지 않는다

왜 안 되나

이유	설명
HTTPS	앱이 인증서를 다루면 복잡하다
정적 파일	앱이 보내면 느리다
여러 앱	포트 하나에 여러 앱을 못 붙인다
공격	앱은 느린 연결에 약하다
80/443	root 권한이 필요 — 앱은 root 면 안 된다

마지막이 결정적이다 — 14강의 root 로 실행 금지

왜 80/443 에 root 가 필요한가

1024 미만 포트는 특권 포트입니다. 아무나 못 열게 돼 있어요.

포트	필요 권한
1~1023	root
1024+	누구나

그래서 nginx 가 root 로 80 을 열고 앱은 8000 에서 논다

비유 — 호텔 프런트

프런트 (nginx)	객실 (앱)
손님을 맞이한다	실제 서비스
어느 방인지 안내	—
수상한 사람 차단	—

손님이 객실로 직접 들어오지 않는다

고등학생리버스 프록시 — 서버를 대신하는 대리인

note 의 이 개념에서 "리버스" 가 무슨 뜻일까요?

종류	누구를 대신하나
정방향 프록시	클라이언트를 대신 — 내가 숨는다
리버스 프록시	서버를 대신 — 서버가 숨는다

누구 편에 서 있느냐가 이름을 가른다

비유 — 대리인

상황	대리인
내가 익명으로 사고 싶다	정방향 — 구매 대행
연예인이 직접 안 만난다	리버스 — 매니저

매니저가 앞에 서면 본인은 안 보인다

nginx 가 대신 해 주는 것

일	설명
HTTPS 처리	암호를 풀어 평문으로 앱에
정적 파일	이미지·CSS 를 직접 보낸다
부하 분산	앱이 여러 대면 나눠 준다
버퍼링	느린 손님을 앞에서 받아 준다

마지막이 의외로 중요하다 — 앱의 일꾼을 아끼는 일

버퍼링이 왜 중요한가

앱의 워커는 몇 개 밖에 없습니다. 느린 손님이 워커를 붙잡고 있으면?

구조	결과
앱이 직접 받는다	느린 손님 100명 → 워커 고갈 ⚠
nginx 가 받는다	다 모아서 한 번에 앱에 ✔

nginx 는 연결 수만 개를 가볍게 다룬다 — 앱은 못 한다

nginx 가 앞에 서면 좋은 점

정적 파일훨씬 빠름CSS·이미지는 앱까지 안 가도 됨

HTTPS암호화 담당앱은 신경 쓸 필요 없음

여러 사이트한 서버에 여럿주소로 구분해 각각 다른 앱으로

과부하 방어완충느린 손님을 앞에서 받아 줌

앱 보호직접 노출 안 됨127.0.0.1 은 바깥에서 못 닿음

설정 파일 읽기

쇼핑몰의 nginx 설정 — 한 줄씩 읽어 봅시다

bash 내 가상 Ubuntu 서버에서 실행

cat /etc/nginx/sites-available/shop

listen 80어느 문에서 기다릴까80 = 웹의 기본 포트

server_name어느 주소로 온 손님?한 서버에 여러 사이트를 둘 때 구분

location /static/이 주소로 오면파일을 직접 준다 (앱을 안 거침)

location /나머지 전부뒤의 앱으로 넘긴다

proxy_pass어디로 넘길까127.0.0.1:8000 ← 우리 앱

X-Forwarded-For원래 손님 IP없으면 앱은 모든 손님을 nginx로 착각

sites-available 과 sites-enabled

Ubuntu 의 nginx 에는 폴더가 둘 있습니다. 왜 나눠 놨을까요?

sites-enabled 안의 것은 파일이 아니라 <b>링크</b>입니다

bash 내 가상 Ubuntu 서버에서 실행

ls -l /etc/nginx/sites-available/
ls -l /etc/nginx/sites-enabled/

고등학생설정을 '보관' 과 '사용' 으로 나누기

note 가 소개하는 sites-available / sites-enabled 구조입니다.

폴더	뜻
sites-available	보관 — 모든 설정
sites-enabled	사용 — 링크만 걸린 것

쓰려면 링크를 걸고, 끄려면 링크만 지운다

왜 이렇게 하나

방식	끌 때
파일 하나에 전부	주석 처리 — 지저분하다
파일을 지운다	되돌릴 수 없다 ⚠
링크를 지운다	원본은 남는다 ✔

되돌릴 수 있게 구조로 만들어 둔 것

비유 — 옷장과 옷걸이

곳	비유
available	옷장 — 가진 옷 전부
enabled	오늘 꺼내 놓은 옷

안 입는다고 버리지 않죠. 넣어 둡니다.

버리는 것과 안 쓰는 것은 다르다

같은 구조가 여러 곳에 있습니다

프로그램	구조
nginx	sites-available/enabled
apache	mods-available/enabled
systemd	enable = 링크를 건다

15강의 systemctl enable 도 사실 링크를 거는 일이다

그래서 enable 과 start 가 다른 겁니다. 링크는 다음 부팅에 읽히니까요.

🎮 요청 라우팅 실험실

설정을 바꿔 가며 어떤 요청이 어디로 가는지 확인해 보세요. 502·404·200이 각각 언제 나오는지 알 수 있습니다.

설정을 고치는 올바른 순서

이 순서를 지키지 않으면 사이트가 통째로 죽습니다. 외워 두세요.

① cp … .bak백업부터

② sudo nano …고치기

③ sudo nginx -t문법 검사 ← 가장 중요

④ systemctl reload nginx끊김 없이 적용

③ 문법 검사 — 통과해야만 다음으로 갑니다

bash 내 가상 Ubuntu 서버에서 실행

sudo nginx -t

고등학생reload 와 restart 의 차이

note 의 이 구분이 운영 중에 결정적입니다.

	reload	restart
하는 일	설정만 다시 읽는다	껐다 켠다
기존 연결	유지 ✔	끊긴다 ⚠
다운타임	없다	짧게 있다

가능하면 reload 를 쓴다 — 손님이 안 끊긴다

nginx 의 reload 는 우아합니다

새 설정으로 새 워커를 띄운다
새 요청은 새 워커로
기존 요청은 옛 워커가 끝까지
다 끝나면 옛 워커 종료

아무도 끊기지 않는다 — 무중단 재시작

비유 — 근무 교대

방식	손님
restart	가게 문을 닫고 교대 — 손님이 나간다
reload	새 직원이 오고 맡던 손님만 마무리

인수인계가 되면 중단이 없다

reload 로 안 되는 것

변경	필요
설정 내용	reload ✔
인증서 갱신	reload ✔
nginx 자체 업그레이드	restart
실행 사용자 변경	restart

프로세스 자체가 바뀌어야 하면 restart 다

반드시 순서를 지킵니다

nginx -t              # ① 문법 검사
systemctl reload nginx # ② 적용

6강의 "고치기 전에 백업 · 적용 전에 검사" 가 여기서

-t 없이 reload 하면 설정이 틀렸을 때 nginx 가 안 뜹니다.

502 Bad Gateway — 가장 자주 보게 될 오류

실제로 만들어 봅시다. nginx 는 살아 있는데 뒤의 앱이 죽으면 무슨 일이 생길까요?

nginx 는 멀쩡한데 뒤가 죽었습니다 → 502

bash 내 가상 Ubuntu 서버에서 실행

sudo systemctl stop shop
curl http://localhost/

이 화면을 보는 순간 범인은 nginx 가 아닙니다. "대신 전해 주려고 갔더니 뒤에 아무도 없더라"는 뜻이에요.

502 Bad Gateway뒤의 앱이 죽음→ systemctl status shop 을 보세요

504 Gateway Timeout뒤가 너무 느림→ 앱이 멈춰 있거나 DB가 느림

404 Not Found그런 주소 없음→ 앱의 라우트 문제

연결 거부nginx 자체가 죽음→ systemctl status nginx

앱을 살리면 바로 정상으로 돌아옵니다

bash 내 가상 Ubuntu 서버에서 실행

sudo systemctl start shop
curl -s http://localhost/

🤔 확인 문제

502 Bad Gateway 가 떴을 때 가장 먼저 확인할 것은?

해설 502 는 nginx 는 살아 있는데 넘겨줄 곳이 대답을 안 한다는 뜻입니다. systemctl status shop 과 journalctl -u shop 이 다음 순서입니다.

🤔 확인 문제

nginx 설정을 고친 뒤 sudo nginx -t 를 먼저 하는 이유는?

해설 -t 는 test 입니다. 통과하면 안심하고 reload 할 수 있어요. 이 한 단계를 건너뛰어 사이트를 죽이는 일이 정말 자주 일어납니다.

🤔 확인 문제

sites-enabled 폴더에 설정 파일이 아니라 심볼릭 링크를 두는 이유로 가장 알맞은 것은?