라이트세일에서 Reverse Proxy 서버를 구성할 때 가장 헷갈리는 부분 중 하나가 바로 DNS 설정 위치입니다. 특히 LiteSpeed CDN을 적용한 뒤에는 라이트세일에서 서브도메인을 추가했는데도 DNS가 적용되지 않는 상황이 자주 발생합니다.
이 문제는 대부분:
- QUIC.cloud CDN 사용 중
- 네임서버 변경 상태
- DNS 관리 위치 변경
상황에서 발생합니다.
즉, 기존에는 라이트세일 DNS 설정에서 관리하던 도메인이 LiteSpeed CDN 적용 이후 QUIC.cloud DNS로 넘어간 상태인데, 이를 모르고 계속 라이트세일에서 DNS를 수정하는 경우가 많습니다.
이번 글에서는 Reverse Proxy용 서브도메인이 왜 적용되지 않았는지 원인부터 설명하고, QUIC.cloud DNS Zones에서 직접 proxy 서브도메인을 추가하는 과정까지 이미지 순서대로 정리해보겠습니다.
QUIC.cloud DNS 구조는 QUIC.cloud 공식 사이트 에서도 확인할 수 있습니다.
목차
왜 라이트세일 DNS 설정에서 적용되지 않았는가?
Reverse Proxy를 구성할 때는 보통:
proxy.domain.com같은 서브도메인을 생성하게 됩니다.
문제는 LiteSpeed CDN을 적용하면서 네임서버가 QUIC.cloud로 변경된 상태에서는 DNS 권한 자체가 QUIC.cloud로 이동한다는 점입니다.
즉:
라이트세일 DNS 수정 → 실제 적용 안 됨상태가 됩니다.
이 상황에서 가장 흔하게 나타나는 증상이:
- dig 결과 변경 안 됨
- proxy 서브도메인 연결 실패
- SSL 발급 실패
- Reverse Proxy 연결 실패
특히 리버스 프록시 서버는 DNS 흐름이 매우 중요하기 때문에 DNS 적용 위치가 잘못되면 구조 자체가 동작하지 않을 수 있습니다.
QUIC.cloud DNS Zones 메뉴부터 확인

QUIC.cloud에 로그인하면 상단 메뉴에 DNS Zones 항목이 보입니다. LiteSpeed CDN을 사용하는 상태에서는 실제 DNS 관리가 여기서 이루어지기 때문에 Reverse Proxy용 서브도메인 역시 이 메뉴에서 추가해야 합니다.
기존처럼 라이트세일 DNS만 수정하면 적용되지 않는 이유도 여기에 있습니다.
특히 네임서버가 QUIC.cloud로 변경된 상태에서는:
도메인 권한 → QUIC.cloud DNS형태로 바뀌게 됩니다. 즉 DNS Zones가 현재 실제 DNS 관리 위치라고 보면 됩니다.
Reverse Proxy 적용할 도메인 선택

DNS Zones 메뉴로 들어가면 현재 CDN이 연결된 도메인 목록이 표시됩니다. 여기서 Reverse Proxy를 적용할 도메인을 선택해야 실제 DNS 레코드를 수정할 수 있습니다.
특히 여러 사이트를 동시에 운영하는 경우에는 다른 도메인을 수정하지 않도록 현재 작업 중인 도메인을 정확하게 확인하는 것이 중요합니다.
이 단계가 중요한 이유는 이후:
- proxy 서브도메인 추가
- CDN 예외 처리
- A 레코드 수정
작업이 모두 현재 선택된 도메인 기준으로 진행되기 때문입니다.
proxy 서브도메인 추가 과정

도메인을 선택한 뒤에는 Reverse Proxy 서버용 서브도메인을 추가해야 합니다.
일반적으로:
proxy.domain.com형태를 많이 사용합니다.
중요한 부분은 Host 입력 시:
proxy만 입력해야 한다는 점입니다.
전체 주소를 입력하는 것이 아니라 서브도메인 앞부분만 입력하는 방식입니다.
그리고 Value에는 Reverse Proxy 서버 IP를 입력하게 됩니다.
TTL은 일반적으로:
5 min정도로 설정하는 경우가 많습니다.
CDN Enabled가 * 에 적용되면 안 되는 이유
이 과정에서 가장 많이 놓치는 부분이 바로:
*와일드카드 레코드입니다.
만약:
* → CDN Enabled상태라면 모든 서브도메인에도 CDN이 적용됩니다.
문제는 Reverse Proxy용 proxy 서브도메인은 CDN을 거치면 안 되는 경우가 많다는 점입니다.
이유는:
- IP 헤더 변경
- 요청 헤더 변경
- 원본 클라이언트 IP 손실
- 프록시 구조 꼬임
문제가 발생할 수 있기 때문입니다.
즉:
사용자
→ QUIC CDN
→ Reverse Proxy
→ 원본 서버구조가 되면서 예상하지 못한 캐시 흐름이 만들어질 수 있습니다.
특히 OpenLiteSpeed와 Nginx Reverse Proxy를 같이 사용하는 경우에는 요청 헤더 흐름이 꼬이는 상황이 발생하기도 합니다.
CDN Enabled는 @ 로 이동하는 방식 사용
일반적으로는:
* → CDN Enabled 제거
@ → CDN Enabled 적용방식으로 정리하는 경우가 많습니다.
즉 메인 도메인만 CDN을 사용하고:
proxy.domain.com같은 프록시용 서브도메인은 CDN을 통과하지 않도록 분리하는 방식입니다. 이 구조를 사용하면 Reverse Proxy 서버가 직접 요청을 처리하게 됩니다.
dig 명령으로 DNS 적용 여부 확인

설정이 끝났다면 실제 DNS가 적용됐는지 확인해야 합니다.
라이트세일 SSH 터미널에서:
dig proxy.greenblog.co.kr명령을 입력하면 됩니다.
이후 ANSWER SECTION 부분에:
proxy.greenblog.co.kr → 프록시 서버 IP형태로 표시되면 정상적으로 DNS가 연결된 상태입니다.
만약 이전 IP가 계속 나온다면:
- DNS 전파 대기
- 잘못된 DNS 관리 위치
- CDN 캐시
- 네임서버 미변경
문제를 먼저 확인하는 경우가 많습니다.
Reverse Proxy DNS가 꼬이면 생기는 문제
DNS 설정이 잘못되면 Reverse Proxy 자체가 동작하지 않을 수 있습니다.
특히:
- SSL 발급 실패
- proxy 연결 실패
- 502 Bad Gateway
- TTFB 증가
- 원본 서버 직접 노출
문제가 이어질 수 있습니다.
실제로는 Nginx 설정 문제가 아니라 DNS 설정 흐름 문제였던 경우도 많습니다.
특히 QUIC.cloud CDN 환경에서는:
DNS 관리 위치 변경부분을 먼저 확인하는 것이 중요합니다.
QUIC.cloud DNS 설정 후 달라지는 점
proxy 서브도메인이 정상 연결되면:
사용자
→ Reverse Proxy
→ OpenLiteSpeed 원본 서버흐름이 안정적으로 작동하게 됩니다.
특히:
- Reverse Proxy 연결 안정화
- SSL 발급 정상화
- 프록시 캐시 적용
- TTFB 감소
- 원본 서버 보호
부분에서 차이가 나타나는 경우가 많습니다.
핵심은:
- QUIC.cloud DNS Zones 사용
- proxy 서브도메인 직접 추가
- CDN Enabled 위치 수정
- dig 명령으로 적용 확인
LiteSpeed CDN 환경에서 Reverse Proxy를 구성하는 경우에는 DNS 설정 관리 위치부터 먼저 확인하는 것이 중요합니다.
▶ 라이트세일 Nginx 리버스 프록시 설정 방법 (별도 인스턴스 구성)





