도메인은 어떻게 VPS를 찾아가는가: DNS, HTTPS, 리버스 프록시 입문

VPS 로컬에서 curl http://127.0.0.1:3000을 실행하여 HTML을 받아보는 것은 애플리케이션이 서버 내부에서 정상 실행되고 있음을 입증합니다. 그러나 일반 사용자가 https://example.com을 통해 접속할 수 있게 하려면 도메인, DNS, 네트워크 포트, 리버스 프록시, HTTPS 암호화를 하나의 체인으로 연결해야 합니다.

이 용어들은 같은 글에 자주 등장하지만 각자 해결하는 영역이 다릅니다.

1. 1회의 웹 요청이 흐르는 완전한 경로

사용자가 브라우저에 도메인 입력
  ↓ DNS 조회
서버의 IP 주소 획득
  ↓ TCP 443 + TLS 핸드셰이크
VPS의 리버스 프록시로 연결
  ↓ 127.0.0.1:3000으로 내부 전달
백엔드 앱이 응답 반환

각 구성 요소의 역할과 비유:

DNS는 웹페이지를 저장하거나 전송하는 메커니즘이 아니며, TLS 인증서가 도메인을 서버로 '가리키게' 만드는 것도 아닙니다. 각 계층을 독립적으로 구성하고 검증해야 합니다.

2. 대표적인 DNS 레코드 종류

예를 들어 www.example.com을 공인 IPv4를 가진 VPS로 연결하려면 보통 A 레코드를 추가합니다.

DNS 변경 사항은 전 세계 모든 사용자에게 즉시 반영되지 않습니다. 재귀 해석기와 클라이언트는 설정된 TTL(Time to Live) 값에 따라 레코드를 캐시합니다. 서버 이전 시에는 사전에 TTL을 줄여두는 것이 중요합니다.

3. 리버스 프록시가 필요한 이유

하나의 VPS에서 여러 웹 서비스를 동시에 구동하는 일은 흔합니다:

blog.example.com  → 127.0.0.1:3000
api.example.com   → 127.0.0.1:4000

Nginx나 Caddy 같은 리버스 프록시는 공인 80/443 포트에서 요청을 수신하고, 요청된 도메인명(Host 헤더)에 따라 적절한 내부 백엔드 앱으로 분배합니다. 또한 TLS 암호화 종단, 접근 로그 기록, 데이터 압축, 속도 제한을 일괄 처리합니다.

이 구조 덕분에 백엔드 앱들이 개별적으로 공인 포트를 열 필요가 없습니다. 문제 해결도 계층별로 명확해집니다:

• 로컬호스트에서 백엔드 앱 동작을 먼저 검증;
• 리버스 프록시의 중계 설정을 검증;
• 마지막으로 DNS 해석 및 외부 HTTPS 연결을 검증.

4. HTTPS가 보호하는 것

HTTPS는 HTTP 통신을 TLS로 암호화한 프로토콜입니다. 정상 작동 시 다음을 보장합니다:

1. 인증성: 클라이언트가 인증서를 통해 대상 도메인의 정당성을 확인; 2. 기밀성: 전송 데이터가 암호화되어 제3자의 도청을 방지; 3. 무결성: 전송 중 데이터 위변조를 즉시 감지.

HTTPS는 웹사이트 운영자의 신용도를 보증하는 것이 아니며, 취약한 웹 코드를 안전하게 고쳐주는 것도 아닙니다. 보호하는 것은 '통신 경로의 안전성'입니다.

Let's Encrypt 같은 공인 인증기관은 ACME 프로토콜을 통해 인증서 발급과 자동 갱신을 수행합니다. 도메인 소유권 검증 방식:

• HTTP-01: 웹 서버의 특정 경로에 챌린지 파일을 올려 검증 (공인 80 포트 개방 필요);
• DNS-01: DNS에 TXT 레코드를 동적으로 등록해 검증 (80/443 포트 개방 불필요);
• TLS-ALPN-01: 443 포트의 특수 TLS 핸드셰이크로 검증.

일반적인 웹 환경에서는 HTTP-01이 널리 쓰이지만, 사용하는 ACME 클라이언트가 어떤 방식을 채택했는지 확인해야 합니다.

5. 초보자를 위한 웹 서버 배포 순서

1. VPS 내부에서 애플리케이션을 구동하고 로컬 주소(127.0.0.1 등)만 수신하도록 설정; 2. 로컬 루프백 요청으로 응답을 확인 (curl -I http://127.0.0.1:3000); 3. 공식 저장소에서 리버스 프록시를 설치하고 설정; 4. 리버스 프록시 설정 문법을 검사한 뒤 실행 또는 리로드; 5. DNS에 올바른 레코드를 등록하고 공용 DNS에서 해석을 확인; 6. 방화벽에서 필수 포트(HTTP-01 챌린지 시 80 포트 필수)를 허용; 7. 검증된 ACME 클라이언트로 TLS 인증서를 발급; 8. 외부 기기에서 HTTPS로 접속하여 인증서 유효성, HTTP 상태 코드, 페이지를 확인; 9. 인증서 자동 갱신 타이머가 정상 동작하는지 점검.

6. 계층별 문제 해결 가이드

도메인이 이전 서버 IP로 연결됨

권한 있는 DNS 레코드, TTL 설정, 로컬 DNS 캐시를 점검하세요. 요청이 새 VPS에 도달하지 않은 상태에서 웹 데몬을 재설치하지 마세요.

IPv4는 정상인데 일부 기기에서 접속 실패

잘못된 AAAA 레코드가 등록되어 있는지 확인하세요. IPv6 지원 기기는 IPv6를 우선 시도하므로 서버 측 IPv6 설정이 불완전하면 타임아웃이 발생합니다.

리버스 프록시가 502 Bad Gateway를 반환

프록시는 요청을 받았으나 백엔드 앱과 통신할 수 없는 상태입니다. 앱 프로세스 생존 여부, 바인드 주소, 포트 번호, 로컬 응답을 확인하세요.

ACME 인증서 발급 실패

에러 로그를 확인하세요. HTTP-01은 80 포트 도달성, DNS-01은 TXT 레코드 반영과 API 권한, TLS-ALPN-01은 443 포트를 점검하고 서버 시스템 시간 동기화(NTP)를 확인하세요.

HTTPS는 되는데 앱 포트도 외부에 직접 열려 있음

앱이 0.0.0.0에서 리슨하고 방화벽이 해당 포트를 열어두지 않았는지 점검하세요. 리버스 프록시 전용 백엔드는 127.0.0.1에 바인드하는 것이 기본입니다.

7. 요약

도메인, DNS, HTTPS, 리버스 프록시는 상호 배타적인 선택지가 아니라 단일 요청 처리 체인을 구성하는 분업 관계입니다. DNS가 IP를 안내하고, 네트워크가 443 포트로 패킷을 배달하며, TLS가 암호화 통로를 열고, 리버스 프록시가 내부 애플리케이션으로 중계합니다.

이 체인을 따라 안쪽에서 바깥쪽으로 순차 검증하는 것이 가장 확실한 운영 방식입니다.

자주 묻는 질문 (FAQ)

도메인 없이 IP 주소만으로 HTTPS를 쓸 수 있나요?

기술적으로 IP 인증서가 존재하지만, 일반적인 개인 사이트는 도메인 기반 인증서를 사용합니다. 도메인을 사용해야 서버 이전 시 IP 변경의 영향을 받지 않습니다.

Cloudflare 같은 DNS 프록시(CDN)를 켜면 무엇이 달라지나요?

클라이언트는 CDN 에지 노드에 먼저 접속하고 에지가 오리진 서버로 전달합니다. 캐시, SSL 설정, 클라이언트 실제 IP 전달, 방화벽 규칙에 계층이 하나 추가됩니다.

인증서는 한 번 발급받으면 끝인가요?

아닙니다. 무료 단기 인증서는 자동 갱신 작업에 의존합니다. 갱신 타이머 동작과 만료일을 정기적으로 모니터링해야 합니다.

참고 자료

• IANA: Domain Name Services
• IANA: Protocol Registries
• Let’s Encrypt 공식 문서
• Let’s Encrypt: Challenge Types
• Nginx Documentation: Beginner’s Guide
• Caddy Documentation: Automatic HTTPS