리눅스 서버에서 도메인 접속이 안 될 때는 먼저 nslookup으로 DNS가 IP로 풀리는지 확인할 수 있습니다.
nslookup api.example.com그런데 nslookup 결과만으로는 조금 아쉬울 때가 있습니다.
예를 들면 이런 상황입니다.
도메인이 어떤 레코드로 응답하는지 보고 싶을 때
DNS 응답 시간이 궁금할 때
어떤 DNS 서버에 질의했는지 확인하고 싶을 때
A, CNAME, MX, NS 레코드를 나눠서 보고 싶을 때
TTL 값 때문에 DNS 캐시가 남아 있는지 보고 싶을 때이럴 때 사용하는 명령어가 dig입니다.
dig는 DNS 응답을 조금 더 자세히 보여주는 도구입니다.
처음 보면 출력이 길어서 어렵게 느껴질 수 있습니다. 하지만 초보 운영자 기준으로는 몇 군데만 보면 충분합니다.
이 글에서는 nslookup보다 조금 더 자세히 DNS 응답을 확인해야 할 때 dig를 어떻게 보면 좋은지 정리해보겠습니다.
nslookup과 dig는 무엇이 다를까?
둘 다 DNS 확인에 사용할 수 있습니다.
다만 느낌이 조금 다릅니다.
nslookup
→ 도메인이 IP로 풀리는지 가볍게 확인
dig
→ DNS 응답 내용을 조금 더 자세히 확인nslookup은 빠르게 보기 좋습니다.
nslookup api.example.com반면 dig는 응답 구조를 더 자세히 보여줍니다.
dig api.example.comdig에서는 아래 정보를 더 보기 좋습니다.
- 어떤 DNS 레코드를 조회했는지
- 어떤 IP로 응답했는지
- CNAME이 있는지
- TTL 값이 얼마인지
- 어떤 DNS 서버에 질의했는지
- DNS 응답 시간이 어느 정도인지
- 응답 상태가 NOERROR인지 NXDOMAIN인지처음부터 dig만 쓸 필요는 없습니다.
가볍게는 nslookup, 조금 더 자세히 봐야 할 때는 dig로 넘어가면 됩니다.
도메인 접속이 안 될 때 nslookup으로 먼저 확인하는 흐름은 아래 글에서 정리했습니다.
https://opsnote.tistory.com/39
리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법
리눅스 서버에서 어떤 사이트나 API 도메인에 접속이 안 될 때 초보 운영자는 보통 서버 장애나 방화벽 문제부터 떠올리기 쉽습니다.서비스가 죽었나?포트가 막혔나?방화벽 문제인가?서버를 재
opsnote.tistory.com
가상의 운영 상황 예시
예를 들어 애플리케이션 서버에서 외부 API 호출이 실패했다고 가정해보겠습니다.
[상황]
- 애플리케이션 서버에서 api.example.com 호출 실패
- nslookup 결과 IP는 나오지만 기대한 IP인지 애매함
- 최근 DNS 변경이 있었음
- 내부 DNS와 외부 DNS 결과가 같은지도 확인 필요이때 바로 방화벽이나 서비스를 재시작하면 순서가 꼬일 수 있습니다.
먼저 DNS 응답을 자세히 봅니다.
dig api.example.com짧게 IP만 보고 싶다면 이렇게 봅니다.
dig api.example.com +short공용 DNS에 직접 물어보고 싶다면 DNS 서버를 지정합니다.
dig @8.8.8.8 api.example.com내부 DNS 서버가 따로 있다면 내부 DNS에도 물어봅니다.
dig @192.0.2.53 api.example.com이렇게 비교하면 문제가 DNS 레코드인지, 내부 DNS인지, 외부 DNS인지, 캐시 영향인지 조금 더 좁혀볼 수 있습니다.
1단계. dig 기본 사용법
가장 기본적인 사용법은 아래입니다.
dig api.example.com출력은 대략 이런 식으로 나옵니다.
;; QUESTION SECTION:
;api.example.com. IN A
;; ANSWER SECTION:
api.example.com. 300 IN A 203.0.113.10
;; Query time: 12 msec
;; SERVER: 192.0.2.53#53처음 보면 줄이 많아 보입니다.
하지만 초보 운영자는 우선 아래 부분만 보면 됩니다.
QUESTION SECTION
ANSWER SECTION
status
TTL
Query time
SERVER하나씩 나눠서 보면 생각보다 어렵지 않습니다.
2단계. QUESTION SECTION은 무엇을 물어봤는지 보여줍니다
QUESTION SECTION은 내가 DNS에 무엇을 물어봤는지 보여줍니다.
;; QUESTION SECTION:
;api.example.com. IN A이 줄은 이렇게 볼 수 있습니다.
api.example.com 도메인의
A 레코드를 물어봤다A 레코드는 도메인이 어떤 IPv4 주소를 바라보는지 확인할 때 사용합니다.
즉, 아래 명령어는:
dig api.example.com기본적으로 api.example.com의 A 레코드를 조회하는 것과 비슷합니다.
여기서 바로 중요한 점이 있습니다.
질문이 잘못되면 답도 엉뚱하게 보입니다.
도메인 오타가 있거나, A 레코드를 봐야 하는데 CNAME이나 MX를 보고 있다면 해석이 달라질 수 있습니다.
3단계. ANSWER SECTION은 실제 DNS 응답입니다
가장 중요한 부분은 ANSWER SECTION입니다.
;; ANSWER SECTION:
api.example.com. 300 IN A 203.0.113.10여기서 초보 운영자가 먼저 볼 것은 두 가지입니다.
어떤 IP로 응답했는지
TTL 값이 얼마인지예시에서는 203.0.113.10이 응답으로 나왔습니다.
Address = 203.0.113.10이 IP가 내가 기대한 IP인지 확인해야 합니다.
예를 들어 운영 문서상 api.example.com이 203.0.113.10을 바라봐야 한다면 정상일 수 있습니다.
하지만 전혀 다른 IP가 나온다면 아래를 확인해야 합니다.
- DNS 레코드가 잘못되었는지
- 최근 DNS 변경이 있었는지
- 내부 DNS와 외부 DNS 응답이 다른지
- LB, WAF, CDN 주소로 변경된 것이 정상인지
- DNS 캐시 때문에 예전 IP가 남아 있는지DNS 응답이 정상처럼 보여도 여기서 끝내면 안 됩니다.
DNS는 이름을 IP로 바꿔주는 단계일 뿐이고, 서비스 포트와 HTTP 응답은 따로 확인해야 합니다.
4단계. TTL은 DNS 캐시 시간으로 보면 됩니다
ANSWER SECTION 중간에 숫자가 하나 보입니다.
api.example.com. 300 IN A 203.0.113.10여기서 300이 TTL입니다.
TTL은 DNS 응답을 얼마나 오래 캐시할 수 있는지를 의미합니다. 단위는 초입니다.
300초
→ 5분
3600초
→ 1시간처음에는 TTL을 지나치기 쉽습니다.
하지만 DNS 변경 직후에는 TTL이 꽤 중요합니다.
예를 들어 도메인을 예전 IP에서 새 IP로 바꿨는데, 일부 서버에서는 아직 예전 IP를 보고 있을 수 있습니다.
이럴 때는 아래 가능성을 봐야 합니다.
- DNS TTL이 아직 남아 있음
- 내부 DNS 캐시가 남아 있음
- 클라이언트 또는 서버 캐시가 남아 있음
- 애플리케이션이 DNS 결과를 캐시하고 있음
- LB, WAF, CDN 설정 반영 시간이 남아 있음초보 운영자라면 이렇게 기억하면 됩니다.
TTL은 DNS 응답이 캐시에 남아 있을 수 있는 시간입니다.DNS를 바꿨다고 모든 서버가 즉시 새 IP를 보는 것은 아닙니다.
5단계. status: NOERROR와 NXDOMAIN을 구분합니다
dig 출력 상단에는 응답 상태가 보입니다.
예를 들어 정상 응답이면 이런 식으로 나올 수 있습니다.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345status: NOERROR는 DNS 질의 자체가 정상 처리되었다는 뜻으로 보면 됩니다.
하지만 NOERROR라고 해서 서비스가 정상이라는 뜻은 아닙니다.
DNS 응답이 정상이라는 뜻입니다.
도메인이 없거나 찾을 수 없으면 아래처럼 나올 수 있습니다.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345NXDOMAIN은 해당 도메인을 찾을 수 없다는 의미입니다.
이때는 서버나 포트보다 도메인 자체를 먼저 봐야 합니다.
- 도메인 오타가 없는지
- DNS 레코드가 등록되어 있는지
- 내부 DNS에만 등록된 도메인을 외부 DNS에 물어본 것은 아닌지
- 최근 DNS 변경 중 레코드가 빠진 것은 아닌지예를 들어 내부망 전용 도메인을 공용 DNS에 물어보면 NXDOMAIN이 나올 수 있습니다.
dig @8.8.8.8 internal-api.example.com이 경우에는 내부 DNS에 물어봐야 할 수 있습니다.
dig @192.0.2.53 internal-api.example.com여기서 바로 “서비스가 죽었다”고 결론 내리면 안 됩니다.
도메인이 어디에 등록되어 있어야 하는지부터 확인해야 합니다.
6단계. Query time은 DNS 응답 시간입니다
dig 출력 하단에는 Query time이 나옵니다.
;; Query time: 12 msec이 값은 DNS 서버가 응답하는 데 걸린 시간입니다.
보통 짧게 나오면 큰 문제는 없어 보일 수 있습니다.
하지만 응답 시간이 지나치게 길거나 timeout이 발생하면 DNS 서버 응답 지연을 의심할 수 있습니다.
예를 들어 이런 경우입니다.
;; connection timed out; no servers could be reached이 메시지가 보이면 도메인 자체보다 DNS 서버와의 통신 문제일 수 있습니다.
이때는 아래를 확인합니다.
- /etc/resolv.conf 설정
- DNS 서버 IP가 맞는지
- DNS 서버까지 네트워크가 되는지
- DNS 53 포트 접근이 가능한지
- 내부 DNS 장애가 있는지DNS 서버 설정은 아래처럼 확인할 수 있습니다.
cat /etc/resolv.confDNS 서버까지 TCP 53 포트 접근을 가볍게 볼 수도 있습니다.
nc -vz -w 3 192.0.2.53 53다만 DNS는 UDP 53도 많이 사용하므로, TCP 포트 확인만으로 전부 판단하면 안 됩니다.
7단계. SERVER는 어떤 DNS 서버에 물어봤는지 보여줍니다
dig 출력 하단에는 어떤 DNS 서버에 질의했는지도 나옵니다.
;; SERVER: 192.0.2.53#53이 줄은 192.0.2.53 DNS 서버에 물어봤다는 뜻입니다.
운영 서버에서는 내부 DNS를 사용할 수도 있고, 공용 DNS를 사용할 수도 있습니다.
내 PC에서는 정상인데 서버에서는 다르게 풀린다면, 서로 다른 DNS 서버를 바라보고 있을 수 있습니다.
이럴 때는 /etc/resolv.conf도 같이 확인합니다.
cat /etc/resolv.conf예를 들어 내부 DNS를 사용 중이라면 이런 식으로 보일 수 있습니다.
nameserver 192.0.2.53
nameserver 198.51.100.53DNS 문제는 “도메인이 무엇인가”만큼이나 “어디에 물어봤는가”가 중요합니다.
8단계. 특정 DNS 서버에 직접 물어볼 수 있습니다
dig의 장점 중 하나는 특정 DNS 서버를 지정해서 질의할 수 있다는 점입니다.
공용 DNS에 직접 물어보려면 아래처럼 확인합니다.
dig @8.8.8.8 api.example.com다른 공용 DNS에 물어볼 수도 있습니다.
dig @1.1.1.1 api.example.com내부 DNS가 있다면 내부 DNS에도 직접 물어봅니다.
dig @192.0.2.53 api.example.com짧게 IP만 비교하고 싶다면 +short를 같이 씁니다.
dig @192.0.2.53 api.example.com +short
dig @8.8.8.8 api.example.com +short결과가 다르면 바로 장애라고 단정하지 말고, 의도된 구조인지 확인해야 합니다.
내부 DNS
→ 내부 서비스 IP 응답
외부 DNS
→ LB, WAF, CDN 또는 공인 IP 응답내부 서비스 도메인은 내부 DNS에서만 풀리는 것이 정상일 수 있습니다.
반대로 외부 사용자용 도메인이 내부 DNS에서 잘못된 IP로 풀리고 있을 수도 있습니다.
그래서 DNS 비교 결과는 확인 위치와 함께 봐야 합니다.
9단계. A 레코드 확인하기
A 레코드는 도메인이 어떤 IPv4 주소를 바라보는지 확인할 때 사용합니다.
dig api.example.com A짧게 보려면 아래처럼 확인합니다.
dig api.example.com A +short예시 결과입니다.
203.0.113.10A 레코드는 웹, API, 서버 접속 문제에서 가장 자주 봅니다.
도메인이 기대한 IP를 바라보는지 확인할 때 기본으로 보면 됩니다.
10단계. CNAME 레코드 확인하기
도메인이 바로 IP를 바라보지 않고 다른 도메인을 가리키는 경우도 있습니다.
이때는 CNAME 레코드를 봅니다.
dig api.example.com CNAME예시입니다.
api.example.com. 300 IN CNAME lb.example.com.전체 조회에서 CNAME과 A 레코드가 함께 보일 수도 있습니다.
api.example.com. 300 IN CNAME lb.example.com.
lb.example.com. 300 IN A 203.0.113.10이 경우 api.example.com은 직접 IP를 바라보는 것이 아니라 lb.example.com을 거쳐 IP로 풀립니다.
도메인 접속 문제를 볼 때 CNAME 구조를 놓치면 엉뚱한 곳을 볼 수 있습니다.
예를 들어 실제 트래픽은 LB나 WAF 쪽으로 가는데, 서버 IP만 보고 판단하면 흐름이 어긋날 수 있습니다.
11단계. MX와 NS 레코드도 기본은 알아두면 좋습니다
메일 관련 DNS를 확인할 때는 MX 레코드를 봅니다.
dig example.com MXMX는 해당 도메인의 메일 서버 정보를 확인할 때 사용합니다.
웹 접속 장애에서는 보통 A, CNAME을 먼저 봅니다.
하지만 도메인 위임이나 DNS 권한 서버를 확인해야 할 때는 NS 레코드도 볼 수 있습니다.
dig example.com NSNS 레코드는 해당 도메인의 네임서버 정보를 보여줍니다.
초보 운영자라면 처음부터 모든 레코드를 외울 필요는 없습니다.
웹 접속 장애 기준으로는 우선 아래 정도만 알아도 충분합니다.
A
→ 도메인이 바라보는 IPv4 주소
CNAME
→ 다른 도메인으로 연결되는 별칭
MX
→ 메일 서버 정보
NS
→ 네임서버 정보12단계. +short로 IP만 깔끔하게 보기
dig 출력이 길게 느껴질 때는 +short 옵션을 사용할 수 있습니다.
dig api.example.com +short결과는 간단히 IP만 나옵니다.
203.0.113.10CNAME이 있으면 이렇게 보일 수 있습니다.
lb.example.com.
203.0.113.10운영 중 빠르게 비교할 때는 +short가 편합니다.
예를 들어 내부 DNS와 외부 DNS를 비교할 때도 유용합니다.
dig @192.0.2.53 api.example.com +short
dig @8.8.8.8 api.example.com +short단, +short만 보면 TTL, SERVER, Query time 같은 정보는 보이지 않습니다.
빠르게 IP만 볼 때는 좋지만, 원인을 자세히 좁혀야 할 때는 전체 출력도 같이 봐야 합니다.
13단계. /etc/hosts 때문에 dig 결과와 실제 접속이 다를 수 있습니다
여기서 초보자가 꽤 자주 헷갈리는 부분이 있습니다.
dig는 DNS 서버에 물어본 결과를 보여줍니다.
하지만 실제 시스템의 이름 해석은 /etc/hosts 영향을 받을 수 있습니다.
예를 들어 /etc/hosts에 아래처럼 설정되어 있다면:
203.0.113.10 api.example.com서버의 실제 접속은 DNS 결과와 다르게 보일 수 있습니다.
확인은 아래처럼 합니다.
cat /etc/hosts시스템이 실제로 이름을 어떻게 해석하는지 보려면 getent hosts도 같이 확인합니다.
getent hosts api.example.com정리하면 이렇게 볼 수 있습니다.
dig
→ DNS 서버에 직접 물어본 결과
getent hosts
→ 서버의 이름 해석 설정을 반영한 결과그래서 도메인 문제가 애매할 때는 dig만 보지 말고 /etc/hosts와 getent hosts도 같이 봐야 합니다.
14단계. DNS가 정상이어도 포트와 응답은 따로 확인합니다
dig 결과가 정상이라고 해서 서비스가 정상이라는 뜻은 아닙니다.
예를 들어 아래처럼 정상 IP가 나올 수 있습니다.
dig api.example.com +short203.0.113.10이 결과는 DNS가 IP를 응답했다는 뜻입니다.
하지만 아직 아래는 확인되지 않았습니다.
- 해당 IP까지 네트워크가 닿는지
- 443 포트가 열려 있는지
- HTTP 응답이 정상인지
- 서비스가 active 상태인지
- 애플리케이션 로그에 에러가 없는지따라서 DNS 확인 후에는 통신과 서비스 확인으로 이어가야 합니다.
ping -c 4 203.0.113.10
nc -vz -w 3 203.0.113.10 443
curl -I https://api.example.com
traceroute -n 203.0.113.10서버 내부에서는 포트와 서비스 상태를 봅니다.
ss -lntp | grep ':443'
systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager접속 확인에서 curl과 nc가 무엇을 다르게 보는지는 아래 글에서 정리했습니다.
https://opsnote.tistory.com/38
리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법
리눅스 서버에서 접속 문제가 생기면 curl과 nc 명령어를 자주 사용합니다. curl -I http://example.comnc -vz -w 3 example.com 80 처음 보면 둘 다 “접속 확인 명령어”처럼 보입니다.하지만 실제 운영에서는
opsnote.tistory.com
네트워크 경로 확인은 아래 글과 이어서 보면 좋습니다.
https://opsnote.tistory.com/37
리눅스 서버 접속 안 될 때 traceroute로 어느 구간에서 막히는지 확인하는 법
리눅스 서버에 접속이 안 되는 문제가 생기면 초보 운영자는 방화벽부터 의심하기 쉽습니다.서버 접속이 안 됩니다.API 호출이 안 됩니다.방화벽 문제 아닌가요?보안그룹 열어야 하는 거 아닌가
opsnote.tistory.com
15단계. 도메인 접속 장애 확인 흐름
도메인 접속 장애라면 아래 순서가 무난합니다.
1. 도메인 오타 확인
2. nslookup으로 가볍게 DNS 확인
3. dig로 DNS 응답 상세 확인
4. 기대한 IP와 비교
5. 내부 DNS와 외부 DNS 결과 비교
6. /etc/hosts와 getent hosts 확인
7. ping으로 ICMP 응답 확인
8. nc로 TCP 포트 접근 확인
9. curl로 HTTP 응답 확인
10. traceroute로 경로 확인
11. 서버 내부 ss로 LISTEN 확인
12. systemctl status로 서비스 상태 확인
13. journalctl로 로그 확인명령어로 보면 아래처럼 정리할 수 있습니다.
nslookup api.example.com
dig api.example.com
dig api.example.com +short
dig @8.8.8.8 api.example.com +short
getent hosts api.example.com
cat /etc/hosts
ping -c 4 203.0.113.10
nc -vz -w 3 203.0.113.10 443
curl -I https://api.example.com
traceroute -n 203.0.113.10
ss -lntp | grep ':443'
systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager길어 보이지만 흐름은 단순합니다.
도메인이 어디를 바라보는지 보고, 그다음 포트와 실제 응답을 확인하는 것입니다.
포트 확인은 아래 글과 연결해서 보면 좋습니다.
https://opsnote.tistory.com/36
리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법
리눅스 서버에서 특정 서비스 접속이 안 되는 상황을 만나면 초보 운영자는 방화벽부터 의심하기 쉽습니다.서버는 살아 있는데 웹 접속이 안 돼요.DB 서버 포트가 막힌 것 같아요.방화벽 문제 아
opsnote.tistory.com
서버 상태 확인 흐름은 아래 글도 도움이 됩니다.
https://opsnote.tistory.com/19
리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트
리눅스 서버가 느려졌거나 서비스가 이상할 때, 가장 먼저 떠오르는 조치가 재기동일 때가 있습니다. 서버를 재기동하면 일단 문제가 해결되는 것처럼 보일 수 있습니다. 하지만 운영 서버에서
opsnote.tistory.com
16단계. 실무 보고 예시
dig로 정상 IP가 확인된 경우는 이렇게 정리할 수 있습니다.
dig 조회 결과 api.example.com 도메인은 203.0.113.10으로 해석됩니다.
DNS 응답은 확인되었으므로, 포트 연결 및 HTTP 응답 상태를 추가 확인하겠습니다.NXDOMAIN이 나온 경우는 이렇게 쓸 수 있습니다.
dig 조회 결과 대상 도메인에 대해 NXDOMAIN 응답이 확인되었습니다.
도메인 오타, DNS 레코드 등록 여부, 내부 DNS와 외부 DNS 조회 위치를 확인하겠습니다.내부 DNS와 외부 DNS 응답이 다르면 이렇게 정리할 수 있습니다.
내부 DNS와 외부 DNS 질의 결과가 서로 다르게 확인됩니다.
의도된 내부/외부 분리 구성인지, DNS 레코드 반영 상태인지 추가 확인하겠습니다.TTL 때문에 캐시 영향이 의심되면 이렇게 쓸 수 있습니다.
dig 응답 기준 TTL 값이 남아 있어 일부 구간에서 기존 DNS 응답이 캐시되어 있을 가능성이 있습니다.
DNS 변경 시각과 TTL, 내부 DNS 캐시 여부를 함께 확인하겠습니다.DNS 서버 응답 지연이 보이면 이렇게 정리합니다.
dig 조회 시 DNS Query time이 지연되거나 timeout이 발생합니다.
도메인 레코드 문제뿐 아니라 DNS 서버 접근 상태와 resolver 설정을 추가 확인하겠습니다.DNS는 정상인데 접속은 안 되는 상황은 이렇게 쓸 수 있습니다.
DNS 조회 결과는 정상이나 curl 기준 서비스 응답이 확인되지 않습니다.
포트 접근, 서비스 상태, 애플리케이션 로그를 이어서 확인하겠습니다.이렇게 쓰면 단순히 “DNS 됩니다”, “DNS 안 됩니다”보다 훨씬 정확합니다.
정리하면
dig는 리눅스 서버에서 DNS 응답을 자세히 확인할 때 유용한 명령어입니다.
기본 사용법은 아래입니다.
dig api.example.com짧게 IP만 보고 싶다면 아래처럼 확인합니다.
dig api.example.com +short특정 DNS 서버에 직접 물어보고 싶다면 이렇게 봅니다.
dig @8.8.8.8 api.example.comCNAME을 확인하려면 아래처럼 볼 수 있습니다.
dig api.example.com CNAME도메인 접속 문제를 확인할 때는 nslookup과 dig의 역할을 나눠서 보는 것이 좋습니다.
nslookup은 도메인이 어떤 IP를 바라보는지 빠르게 확인할 때 유용하고, dig는 DNS 응답 정보와 TTL, 레코드 흐름을 조금 더 자세히 볼 때 도움이 됩니다.
다만 DNS 응답이 정상이라고 해서 서비스가 정상이라는 뜻은 아닙니다.
도메인이 맞는 IP를 바라보고 있어도 포트가 닫혀 있거나, HTTP 응답이 비정상일 수 있습니다.
접속 장애를 ping, nc, curl, DNS 순서로 정리해서 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/71
리눅스 서버 접속 장애 확인 순서 총정리
리눅스 서버를 운영하다 보면 가장 자주 듣는 말 중 하나가 있습니다.접속이 안 됩니다.사이트가 안 열립니다.서버가 죽은 것 같습니다.도메인이 안 됩니다.포트가 막힌 것 같습니다. 처음 들으
opsnote.tistory.com
nslookup으로 도메인 IP를 먼저 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.
https://opsnote.tistory.com/39
리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법
리눅스 서버에서 어떤 사이트나 API 도메인에 접속이 안 될 때 초보 운영자는 보통 서버 장애나 방화벽 문제부터 떠올리기 쉽습니다.서비스가 죽었나?포트가 막혔나?방화벽 문제인가?서버를 재
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법 (0) | 2026.06.19 |
|---|---|
| 리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법 (0) | 2026.06.18 |
| 리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법 (0) | 2026.06.16 |
| 리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법 (1) | 2026.06.15 |
| 리눅스 서버 접속 안 될 때 traceroute로 어느 구간에서 막히는지 확인하는 법 (0) | 2026.06.14 |