nginx 리다이렉트 설정 변경 후 curl로 검증하는 방법

nginx에서 리다이렉트 규칙을 바꾼 뒤 브라우저에서 새로고침해보면 여전히 이전 주소로 이동하는 것처럼 보이는 경우가 있다. 브라우저가 301 응답을 캐시해뒀기 때문이다. 이럴 때 curl이 정확한 답을 준다.

curl로 리다이렉트 체인 확인하기

# 리다이렉트를 따라가며 각 단계의 헤더를 출력
curl -IL https://example.com

-I는 헤더만 요청(HEAD), -L은 리다이렉트를 따라가는 옵션이다. 출력 예시:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/
...

HTTP/2 200
content-type: text/html
...

301이 어디로 보내는지, 최종 목적지가 200을 반환하는지 한눈에 확인할 수 있다.

nginx 설정 적용 전 문법 검사

nginx 설정을 바꾼 뒤에는 반드시 문법 검사를 먼저 한다. 설정 오류가 있으면 reload 자체가 실패하고 기존 설정이 유지되거나, 최악의 경우 nginx가 내려간다.

# 문법 검사
sudo nginx -t

# 통과하면 무중단 reload
sudo systemctl reload nginx

nginx -t 결과가 syntax is ok이면 안전하게 reload할 수 있다.

흔한 리다이렉트 패턴과 확인 방법

http → https 강제 전환

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

curl -I http://example.com
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/

www 없애기 (non-www로 통일)

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

curl -I https://www.example.com
# HTTP/1.1 301
# Location: https://example.com/

DNS 전파와 캐시를 의심해야 할 때

curl 결과가 예상과 다르면 DNS 캐시도 확인한다.

# 현재 DNS 해석 결과
dig example.com +short

# 특정 DNS 서버로 직접 질의
dig @8.8.8.8 example.com +short

두 결과가 다르면 로컬 DNS 캐시나 ISP 캐시 문제다. 시간이 지나면 해결되지만, 확인 자체는 curl과 dig으로 충분히 할 수 있다.

설정 변경 → nginx -t → reload → curl -IL 순서로 확인하면 브라우저 때문에 헷갈릴 일이 없다.