base
이 글은 내부망 환경을 전제로 합니다. 외부 DNS에는 등록되어 있지 않지만, 내부 IP로만 접근 가능한 테스트 또는 사내 시스템을 다루는 상황입니다.
브라우저나 curl로 http://account.hanpy-bank.com에 접속할 때, 가장 먼저 수행되는 작업은 DNS 조회입니다. 도메인 이름을 실제 접속할 IP 주소로 변환하는 과정입니다. 하지만 서버를 띄웠지만 아래와 같이 접속이 안되는 경우도 있습니다.
dig account.hanpy-bank.com 결과 없음이때 사용하는 것이 /etc/hosts입니다. /etc/hosts는 로컬 시스템에서만 적용되는 정적 호스트 매핑 테이블로, 운영체제는 DNS 서버에 질의하기 전에 이 파일을 우선적으로 참조합니다.
예를 들어 아래와 같이 추가하여 테스트해 봅시다.
10.92.11.72 account.hanpy-bank.com
접속 흐름은 다음과 같이 바뀝니다.
account.hanpy-bank.com 접속 시도/etc/hosts를 먼저 확인10.92.11.72로 즉시 매핑이로써, DNS 레코드가 존재하지 않는 내부망 환경에서도 도메인 기반 접근이 가능해집니다. /etc/hosts가 DNS보다 먼저 적용되는 이유는, 운영체제의 이름 해석 우선순위가 로컬 파일을 최상위로 두도록 설계(/etc/nsswitch.conf)되어 있기 때문입니다.
문제 없습니다. 오히려 아주 일반적인 구성입니다.
10.92.11.72 account.hanpy-bank.com
10.92.11.72 admin.hanpy-bank.com
10.92.11.72 api.hanpy-bank.com
네트워크 관점에서는 모두 같은 서버로 접속되지만, 서버는 요청에 포함된 Host 정보를 기준으로 도메인을 구분합니다. 브라우저는 요청 시 다음 헤더를 함께 보냅니다.
Host: account.hanpy-bank.com
웹 서버(Nginx, Apache)는 이 값을 보고 각 도메인에 대응하는 Virtual Host(Server Block)로 요청을 분기합니다.
Nginx에서는 server_name으로 도메인을 구분합니다.
server {
server_name account.hanpy-bank.com;
...
}
server {
server_name admin.hanpy-bank.com;
...
}
같은 IP와 포트를 사용하더라도, server_name이 다르면 서로 다른 서비스처럼 동작합니다.
/etc/hosts는 내부망 환경에서 DNS 레코드가 존재하지 않거나 별도의 DNS 구성이 어려운 경우에 사용하는 로컬 기반의 임시 이름 해석 수단입니다. 하나의 IP 주소에 여러 도메인을 매핑하더라도 네트워크 레벨에서는 문제가 없으며, 실제 서비스 구분은 HTTP 요청에 포함된 Host 헤더를 기준으로 웹 서버에서 처리됩니다.
또한 HTTPS 환경에서는 TLS 핸드셰이크 단계에서 전달되는 SNI(Server Name Indication) 정보를 통해 도메인별 인증서를 선택할 수 있습니다. 이러한 구조 덕분에 하나의 IP로 여러 도메인과 인증서를 운영하는 것이 가능하며, 이는 테스트 환경이나 사내 내부 시스템에서 매우 일반적으로 사용되는 방식입니다.