리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

리눅스 서버에서 도메인 접속이 안 될 때 nslookup으로 DNS가 정상적으로 IP를 바라보는지 확인하고 ping, nc, curl, ss, systemctl, journalctl로 이어서 점검하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 어떤 사이트나 API 도메인에 접속이 안 될 때 초보 운영자는 보통 서버 장애나 방화벽 문제부터 떠올리기 쉽습니다.

서비스가 죽었나?
포트가 막혔나?
방화벽 문제인가?
서버를 재기동해야 하나?

 

그런데 실제로는 서비스나 방화벽 문제가 아니라, 도메인이 IP로 제대로 변환되지 않는 DNS 문제일 수 있습니다.

브라우저나 curl에서 우리가 입력하는 주소는 대부분 IP가 아니라 도메인입니다.

api.example.com
service.example.com
www.example.com

 

이 도메인이 먼저 IP로 바뀌어야 그다음 포트 확인, HTTP 응답 확인, 서비스 상태 확인으로 넘어갈 수 있습니다.

이때 가장 먼저 가볍게 확인해볼 수 있는 명령어가 nslookup입니다.

nslookup은 도메인이 어떤 IP로 해석되는지 확인하는 명령어입니다.

이번 글에서는 리눅스 서버에서 도메인 접속이 안 될 때 nslookup으로 DNS 응답을 확인하고, 그다음 ping, nc, curl, ss, systemctl, journalctl로 어떻게 이어서 확인하면 좋은지 정리해보겠습니다.

도메인 접속이 안 되면 DNS도 먼저 봐야 합니다

접속 장애를 볼 때 바로 서버나 방화벽으로 뛰어가면 생각보다 멀리 돌아갈 수 있습니다.

도메인 접속은 대략 이런 흐름으로 이어집니다.

도메인 입력
→ DNS가 IP로 변환
→ 해당 IP로 네트워크 연결
→ 서비스 포트 접근
→ HTTP 또는 애플리케이션 응답

 

이 중 맨 앞의 DNS 단계가 실패하면 뒤쪽을 아무리 확인해도 헷갈립니다.

예를 들어 api.example.com이 원래 203.0.113.10을 바라봐야 하는데 다른 IP로 풀리거나, 아예 IP가 나오지 않으면 서비스가 살아 있어도 접속은 실패할 수 있습니다.

그래서 도메인 접속 장애를 볼 때는 아래 흐름이 좋습니다.

도메인 확인
→ nslookup으로 IP 확인
→ ping 또는 nc로 통신 확인
→ curl로 응답 확인
→ 서버 내부 상태 확인

 

도메인이 정상적으로 IP로 해석됐는데도 접속이 안 된다면, 그다음은 포트와 HTTP 응답을 봐야 합니다.

curl과 nc를 언제 어떻게 나눠서 보는지는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/38

리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

 

가상의 운영 상황 예시

예를 들어 애플리케이션 서버에서 외부 API 호출이 실패한다고 가정해보겠습니다.

[상황]
- 애플리케이션 서버에서 api.example.com 호출 실패
- 초보 운영자는 API 서버 장애 또는 방화벽 문제를 의심
- 그런데 실제 원인은 DNS가 잘못된 IP를 응답하는 상황일 수 있음

 

이때 바로 방화벽이나 서비스 재시작으로 가면 위험합니다.

먼저 도메인이 어떤 IP로 풀리는지 봅니다.

 

nslookup api.example.com

 

그다음 포트를 확인합니다.

 

nc -vz -w 3 api.example.com 443

 

HTTP 응답은 curl로 확인합니다.

 

curl -I https://api.example.com

 

이렇게 확인하면 문제가 DNS인지, 포트인지, HTTP 응답인지 조금씩 나눠볼 수 있습니다.

1단계. nslookup 기본 사용법

가장 기본적인 사용법은 도메인만 넣는 방식입니다.

 

nslookup api.example.com

 

예시 출력은 아래처럼 볼 수 있습니다.

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   api.example.com
Address: 203.0.113.10

 

처음 볼 때는 복잡해 보일 수 있지만, 초보 운영자 기준으로는 두 가지만 먼저 보면 됩니다.

Server
→ 어떤 DNS 서버에 물어봤는지

Address
→ 도메인이 어떤 IP로 해석됐는지

 

결국 핵심은 이것입니다.

내가 기대한 IP가 맞는가?

 

운영 문서상 api.example.com이 203.0.113.10을 바라봐야 하는데 전혀 다른 IP가 나온다면 DNS 설정, 내부 DNS, 외부 DNS, LB, CDN, WAF 구성을 확인해야 할 수 있습니다.

2단계. 정상 IP가 나왔을 때도 끝이 아닙니다

nslookup 결과에서 IP가 정상적으로 나왔다고 해서 서비스가 정상이라는 뜻은 아닙니다.

예를 들어 아래처럼 IP가 잘 나올 수 있습니다.

Name:   api.example.com
Address: 203.0.113.10

 

이 결과는 도메인이 IP로 해석되었다는 뜻입니다.

하지만 아직 아래는 확인되지 않았습니다.

- 해당 IP까지 네트워크가 닿는지
- 80 또는 443 포트가 열려 있는지
- HTTP 응답이 정상인지
- 애플리케이션이 정상 동작하는지
- LB, WAF, CDN 뒤쪽 서비스가 정상인지

 

그래서 다음 단계가 필요합니다.

 

ping -c 4 203.0.113.10
nc -vz -w 3 203.0.113.10 443
curl -I https://api.example.com

 

nslookup은 이름표를 확인하는 단계입니다.

이름표가 맞아도 문이 열렸는지, 안쪽에서 응답하는지는 따로 봐야 합니다.

3단계. 잘못된 IP가 나오면 DNS 설정을 의심합니다

운영 문서나 설정상 기대한 IP와 다른 IP가 나오는 경우가 있습니다.

예를 들어 원래는 203.0.113.10이어야 하는데 아래처럼 다른 IP가 나왔다고 해보겠습니다.

Name:   api.example.com
Address: 198.51.100.20

 

이 경우 바로 서비스 재시작으로 가면 안 됩니다.

먼저 아래를 확인해야 합니다.

- DNS 레코드가 최근 변경되었는지
- 내부 DNS와 외부 DNS 응답이 다른지
- CDN, WAF, LB 주소로 바뀐 것이 정상인지
- /etc/hosts에 별도 설정이 있는지
- 서버가 바라보는 DNS 서버가 맞는지
- DNS 캐시 영향이 있는지

 

특히 운영 환경에서는 내부 서버에서 보는 DNS 결과와 사용자 PC에서 보는 DNS 결과가 다를 수 있습니다.

내부 DNS
→ 사내망 또는 내부 서비스 IP 응답

외부 DNS
→ 공인 LB, WAF, CDN IP 응답

 

그래서 “내 PC에서는 되는데 서버에서는 안 돼요” 같은 상황에서는 어디에서 nslookup을 했는지 같이 적어야 합니다.

4단계. NXDOMAIN이 나오면 도메인 자체를 확인합니다

nslookup 결과가 아래처럼 나올 수 있습니다.

** server can't find api.example.com: NXDOMAIN

 

NXDOMAIN은 해당 도메인을 찾을 수 없다는 의미로 볼 수 있습니다.

이때는 서버나 포트보다 도메인 자체를 먼저 확인해야 합니다.

확인할 것은 아래입니다.

- 도메인 오타가 없는지
- 하위 도메인이 실제로 등록되어 있는지
- 내부 DNS에만 등록된 도메인을 외부에서 조회한 것은 아닌지
- 외부 DNS에 등록되어야 하는데 누락된 것은 아닌지
- 최근 DNS 변경 중 삭제되었거나 잘못 수정된 것은 아닌지

 

예를 들어 내부망 전용 도메인은 외부 DNS에서 조회하면 NXDOMAIN이 나올 수 있습니다.

그 경우에는 외부에서 안 나오는 것이 정상일 수도 있습니다.

중요한 것은 NXDOMAIN만 보고 서비스가 죽었다고 판단하지 않는 것입니다.

도메인 등록 여부와 DNS 조회 위치를 먼저 확인해야 합니다.

5단계. timeout이나 no servers could be reached가 나오면 DNS 서버 통신을 봅니다

아래처럼 나오는 경우도 있습니다.

;; connection timed out; no servers could be reached

 

이 경우는 도메인 자체보다 DNS 서버와 통신이 안 되는 상황일 수 있습니다.

확인할 것은 아래입니다.

- /etc/resolv.conf 설정
- DNS 서버 IP가 맞는지
- DNS 서버까지 네트워크가 되는지
- 내부 DNS 장애 여부
- 방화벽이나 보안그룹에서 DNS 53 포트가 막혔는지
- 서버의 네트워크 경로 문제

 

DNS 서버 설정은 아래 파일에서 확인할 수 있습니다.

 

cat /etc/resolv.conf

 

예시는 아래처럼 보일 수 있습니다.

nameserver 192.0.2.53
nameserver 198.51.100.53

 

DNS 서버까지 통신이 되는지 확인하려면 환경에 따라 ping, nc, dig 등을 사용할 수 있습니다.

 

ping -c 4 192.0.2.53
nc -vz -w 3 192.0.2.53 53

 

다만 DNS는 UDP 53도 많이 사용하므로 TCP 포트 확인만으로 전부 판단하면 안 됩니다.

이럴 때는 다음 단계에서 dig로 더 자세히 보는 것이 좋습니다.

 

6단계. /etc/hosts 때문에 결과가 달라질 수 있습니다

리눅스 서버에서는 /etc/hosts 파일 때문에 DNS 결과와 실제 접속 대상이 달라질 수 있습니다.

확인 명령은 아래입니다.

 

cat /etc/hosts

 

예를 들어 아래처럼 설정되어 있다면:

203.0.113.10 api.example.com

 

서버는 DNS 조회보다 /etc/hosts 설정을 먼저 사용할 수 있습니다.

그래서 nslookup 결과와 실제 접속 결과가 달라 보일 수 있습니다.

이럴 때는 아래도 함께 확인하는 것이 좋습니다.

 

getent hosts api.example.com

 

getent hosts는 시스템이 실제로 이름을 어떻게 해석하는지 확인할 때 도움이 됩니다.

정리하면 이렇게 볼 수 있습니다.

nslookup
→ DNS 서버에 물어본 결과

getent hosts
→ 서버의 이름 해석 설정을 반영한 결과

 

그래서 도메인 문제가 애매할 때는 nslookup만 보지 말고 /etc/hosts와 getent hosts도 같이 보면 좋습니다.

7단계. 내부 DNS와 외부 DNS 결과를 비교해야 할 때

운영 환경에서는 내부 DNS와 외부 DNS 결과가 다를 수 있습니다.

예를 들어 내부 서버에서는 내부 IP를 받아야 하고, 외부 사용자는 공인 IP나 WAF 주소를 받아야 하는 구조가 있습니다.

내부 DNS 서버를 지정해서 조회할 수 있습니다.

 

nslookup api.example.com 192.0.2.53

 

공용 DNS를 지정해서 조회할 수도 있습니다.

 

nslookup api.example.com 8.8.8.8

 

결과가 서로 다르면 바로 장애라고 볼 것이 아니라, 의도된 분리인지 확인해야 합니다.

내부 DNS 결과
→ 내부 서비스 IP

외부 DNS 결과
→ WAF, LB, CDN 또는 공인 IP

서버 설정
→ 어떤 DNS 서버를 사용 중인지 확인

 

내부망 서비스인데 외부 DNS에만 물어보고 “안 나옵니다”라고 판단하면 안 됩니다.

반대로 외부 사용자용 도메인을 내부 DNS가 잘못된 IP로 응답하고 있을 수도 있습니다.

DNS는 “어디에서 물어봤는지”가 중요합니다.

8단계. DNS 캐시 때문에 예전 IP가 보일 수 있습니다

DNS 변경 직후에는 서버나 클라이언트, 중간 DNS 캐시에 예전 IP가 남아 있을 수 있습니다.

예를 들어 DNS 레코드를 새 IP로 바꿨는데, 어떤 서버에서는 아직 예전 IP로 보일 수 있습니다.

이때 확인할 것은 아래입니다.

- DNS 변경 시간이 언제인지
- TTL 설정이 얼마나 되는지
- 내부 DNS 캐시가 있는지
- 애플리케이션이나 JVM이 DNS를 캐시하는지
- LB, WAF, CDN 설정 변경이 같이 있었는지

 

초보 운영자는 DNS를 바꾸면 바로 모든 곳에서 바뀐다고 생각하기 쉽습니다.

하지만 실제 운영에서는 캐시 때문에 일정 시간 동안 결과가 섞여 보일 수 있습니다.

그래서 변경 직후에는 여러 위치에서 비교 확인하는 것이 좋습니다.

 

nslookup api.example.com
nslookup api.example.com 8.8.8.8
getent hosts api.example.com

 

 

9단계. nslookup 결과가 정상이어도 실제 접속은 실패할 수 있습니다

nslookup으로 도메인이 기대한 IP로 해석되는 것을 확인했다고 해서 실제 서비스 접속까지 정상이라는 뜻은 아닙니다.

예를 들어 다음과 같이 DNS 응답이 정상일 수 있습니다.

nslookup api.example.com

Name:    api.example.com
Address: 203.0.113.10

 

하지만 실제 접속에는 DNS 외에도 네트워크 연결, TCP 포트, HTTP 응답 등의 단계가 있습니다.

특히 리눅스에서는 /etc/hosts 설정이나 시스템의 이름 해석 방식에 따라 nslookup 결과와 애플리케이션이 사용하는 주소가 달라질 수도 있습니다.

이때는 다음 명령어로 시스템의 이름 해석 결과를 비교할 수 있습니다.

getent hosts api.example.com

 

핵심은 DNS 조회 성공과 서비스 정상 여부를 구분하는 것입니다.

DNS 응답이 정상인데도 접속이 실패한다면 포트 연결과 HTTP 응답을 추가로 확인해야 합니다. 자세한 방법은 36번과 38번 글에서 확인할 수 있습니다.

10단계. 실무 보고 예시

DNS가 정상 IP로 해석되는 경우는 이렇게 정리할 수 있습니다.

nslookup 확인 결과 api.example.com은 203.0.113.10으로 정상 해석됩니다.
서비스 접속 실패 원인 확인을 위해 443 포트 접근과 curl 응답을 추가 확인하겠습니다.

 

잘못된 IP로 해석되는 경우는 이렇게 쓸 수 있습니다.

nslookup 확인 결과 api.example.com이 기대한 IP와 다른 주소로 해석됩니다.
내부 DNS, 외부 DNS, LB 또는 WAF 연결 정보 변경 여부를 확인하겠습니다.

 

NXDOMAIN이 나온 경우는 이렇게 정리합니다.

nslookup 결과 NXDOMAIN이 확인되어 해당 도메인 등록 또는 조회 위치 확인이 필요합니다.
도메인 오타, 내부 DNS 등록 여부, 외부 DNS 공개 여부를 우선 확인하겠습니다.

 

DNS 서버 응답이 없는 경우는 이렇게 쓸 수 있습니다.

nslookup 수행 시 DNS 서버 응답 timeout이 발생했습니다.
대상 도메인 문제보다 DNS 서버 접근 또는 resolver 설정 문제 가능성이 있어 /etc/resolv.conf와 DNS 서버 통신 상태를 확인하겠습니다.

 

도메인 기준과 IP 기준 결과가 다른 경우는 이렇게 정리할 수 있습니다.

도메인 기준 curl은 실패하나 IP 기준 포트 접근은 확인됩니다.
DNS, Host 헤더, LB, WAF 또는 인증서 구성을 추가 확인하겠습니다.

 

이렇게 쓰면 단순히 “DNS 문제 같습니다”보다 훨씬 정확합니다.

정리하면

리눅스 서버에서 도메인 접속이 안 된다면 서버나 방화벽 설정을 변경하기 전에 DNS 조회 결과부터 확인하는 것이 좋습니다.

기본 명령어는 다음과 같습니다.

nslookup api.example.com

결과에 따라 점검 방향이 달라집니다.

조회 결과다음 확인 사항

기대한 IP 응답	포트 연결 및 HTTP 응답 확인
예상과 다른 IP 응답	DNS 레코드, 내부·외부 DNS, LB·WAF 설정 확인
NXDOMAIN	도메인 이름, DNS 레코드, 조회 위치 확인
DNS 조회 timeout	DNS 서버 설정 및 통신 상태 확인

시스템의 실제 이름 해석 결과가 다르게 보인다면 다음 명령어도 함께 확인합니다.

getent hosts api.example.com

운영 환경에서는 어느 서버에서, 어떤 DNS 서버를 통해, 어떤 IP를 응답받았는지 기록하는 것이 중요합니다.

DNS 조회가 정상이어도 서비스까지 정상이라는 뜻은 아니므로, 이후에는 TCP 포트와 HTTP 응답을 구분해서 확인해야 합니다.

함께 읽으면 좋은 글

• 36번 — nc로 TCP 포트 연결 확인하기

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

• 38번 — curl과 nc의 차이 이해하기

리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

• 40번 — dig로 DNS 응답 자세히 확인하기

리눅스 서버 nslookup만 보지 말고 dig로 DNS 응답까지 확인하는 법