도메인 연결 안됨, 순서대로 볼 3가지
만든 적 없는 이름은 조용히 실패합니다.
제 도메인의 www로 들어가면 브라우저가 ERR_NAME_NOT_RESOLVED만 내요.
얼마나 기다려야 하는지도 재봤는데 뭘 바꿨느냐에 따라 5분, 30분, 48시간으로 갈렸습니다.
제 도메인은 www를 안 만들어 뒀어요. 주소를 하나로 정하려고 일부러 그렇게 뒀는데, 그 주소로 들어오면 이렇게 됩니다.
https://www.lessduck.com/ -> 실패: page.goto: net::ERR_NAME_NOT_RESOLVED at https://www.lessduck.com/
https://lessduck.com/ -> HTTP 200
www를 안 붙이면 열리고 붙이면 안 열려요. 사이트는 멀쩡히 돌고 있는데 이름 하나가 비어 있는 겁니다. 만든 적 없는 이름은 아무 경고도 없이 이렇게 실패해요.
저는 일부러 비워 뒀지만, 모르고 비어 있어도 결과는 똑같습니다. 없는 이름은 그냥 없다고만 나오지, 뭘 빠뜨렸는지까지는 안 나와요.
브라우저 문구부터 읽어요
터미널을 열기 전에 브라우저가 뭐라고 하는지부터 봅니다. 다만 큰 글씨 제목만으로는 부족해요. “사이트에 연결할 수 없음”은 크롬이 여러 원인에 두루 쓰는 제목이라, 연결이 거부됐을 때도 똑같이 나옵니다.
갈라 주는 건 그 아래 작게 적힌 영문 코드예요.
ERR_NAME_NOT_RESOLVED·DNS_PROBE_FINISHED_NXDOMAIN→ 주소를 IP로 바꾸는 단계에서 막혔어요. 아래 1번과 2번입니다ERR_CONNECTION_REFUSED·ERR_CONNECTION_TIMED_OUT→ 주소는 찾았는데 그 서버가 응답을 안 해요. 도메인이 아니라 호스팅 쪽입니다- 연결이 비공개로 설정되지 않았다는 인증서 경고 → 목적지까지 갔어요. 인증서 문제입니다
- 404나 엉뚱한 페이지 → 도메인은 완전히 정상이고 연결된 곳이 틀렸어요
아래 셋은 도메인 문제가 아니에요. 여기서 갈라 놓으면 DNS 설정을 몇 시간씩 헤집는 일이 없습니다.
하나. 그 이름이 아예 없는 경우
이름을 못 찾는다고 하면 확인은 한 줄입니다. 맥은 터미널, 윈도우는 명령 프롬프트에서요.
nslookup www.내도메인.com
제 것으로 돌리면 이렇게 나옵니다.
** server can't find www.lessduck.com: NXDOMAIN
NXDOMAIN. 그런 이름이 없다는 뜻이에요. 정상이면 이렇게 나옵니다.
Non-authoritative answer:
Name: lessduck.com
Address: 172.67.182.134
Name: lessduck.com
Address: 104.21.43.168
Address 줄이 나오면 이름은 살아 있는 겁니다.
여기서 걸리기 쉬운 게 www 유무예요.
도메인을 연결할 때 보통 루트(내도메인.com) 하나만 등록합니다. 그럼 www.내도메인.com은 별개의 이름이라 안 만들어져요. 둘은 자동으로 이어지지 않고, 어느 쪽도 경고를 내지 않습니다. 그런데 아직 www를 붙여 치는 사람이 있어요. 명함에 적거나 카톡으로 보낸 주소에 www가 붙어 있으면, 만든 사람 화면에서는 멀쩡한 사이트가 받는 사람에게는 안 열립니다.
짚어 둘 게 하나 있어요. 둘 다 살려야 하는 건 아닙니다. 저는 주소를 하나로 정하는 쪽이 관리하기 낫다고 봐서 www를 안 만들었어요.
갈리는 건 안 쓰기로 한 쪽이 어떻게 실패하느냐입니다. 아무것도 안 해두면 그 주소로 온 사람은 위처럼 연결 자체가 안 돼요. 그래서 고치는 방향은 www를 본 주소로 승격시키는 게 아니라, www로 온 사람을 루트로 보내는 쪽입니다.
다만 이 자리는 제가 안 걸어 봤어요. www 레코드를 만들어 루트와 같은 곳을 가리키게 하는 것과, 접속을 루트 주소로 되돌리는 리다이렉트는 서로 다른 설정이고 거는 자리도 서비스마다 다릅니다. 어느 쪽이면 충분한지는 확인 못 했습니다.
둘. 레코드를 다른 곳에 넣은 경우
이름이 없다고 나오는데 “분명히 레코드를 넣었다”면, 대개 넣은 장소가 틀린 것이에요.
도메인을 산 곳과 DNS를 관리하는 곳이 다를 수 있거든요. 등록기관에서 도메인을 사고 네임서버만 다른 곳으로 바꾸는 게 흔한 구성인데, 이러면 원래 산 곳의 DNS 관리 화면은 아무 효력이 없어집니다. 거기 레코드를 아무리 정성껏 넣어도 세상은 그걸 안 봐요.
지금 이 도메인의 주인이 어디인지는 한 줄로 나옵니다.
nslookup -type=NS 내도메인.com
lessduck.com nameserver = bowen.ns.cloudflare.com.
lessduck.com nameserver = elinore.ns.cloudflare.com.
여기 찍힌 이름이 곧 레코드를 넣어야 할 곳이에요. cloudflare.com이라고 나오면 Cloudflare에서 넣어야 하고, 등록기관 이름이 나오면 거기서 넣어야 합니다.
에러도 경고도 없이 조용히 실패하는 자리라 오래 붙잡게 돼요. 넣은 레코드가 세상에 안 보인다는 걸 알려주는 신호가 어디에도 없거든요.
덧붙이면 이 구성은 제가 안 써봤습니다. 위 조회로 판별하는 방법만 적고, 각 서비스 화면이 어떻게 생겼는지는 단정하지 않을게요.
셋. 얼마나 기다려야 하는가
“기다리면 된다”는 말이 맞을 때도 있어요. 문제는 얼마나냐입니다. 흔히 최대 48시간이라고 하는데, 재보니 뭘 바꿨느냐에 따라 완전히 다릅니다.
먼저 IP를 정하는 레코드예요. 10초 간격으로 네 번 조회했습니다.
A(104.21.43.168) TTL: 187초
A(104.21.43.168) TTL: 177초
A(104.21.43.168) TTL: 167초
A(104.21.43.168) TTL: 157초
정확히 10씩 줄어듭니다.
이게 TTL이에요. 이 답을 몇 초 동안 재사용해도 되는지를 적어 둔 유효기간이고, 지금 남은 시간이 초 단위로 카운트다운됩니다. 이 도메인은 300초로 설정돼 있어요. 그러니까 IP를 바꾸면 최대 5분이면 새 값이 돌아갑니다.
다른 도메인들도 짧았어요.
naver.com 167초
daum.net 204초
github.com 37초
vercel.com 1227초
그런데 상위 기관에 “이 도메인은 누가 관리하나”를 물으면 값이 다릅니다.
lessduck.com. 172800 IN NS elinore.ns.cloudflare.com.
lessduck.com. 172800 IN NS bowen.ns.cloudflare.com.
172800초. 48시간이에요. 최대 48시간이라는 말의 출처가 여기였습니다.
여기까지가 이미 있는 이름의 값을 바꿀 때 얘기예요. 없던 이름을 새로 만들 때는 시계가 하나 더 있습니다.
리졸버는 “있다”만 캐시하는 게 아니라 “없다”도 캐시해요. www가 없는 걸 확인하는 순간 그 답이 저장됩니다. 이건 A레코드 TTL이 아니라 SOA라는 레코드가 정해요.
lessduck.com. 219 IN SOA bowen.ns.cloudflare.com. dns.cloudflare.com. 2412149415 10000 2400 604800 1800
맨 뒤 1800이 그 값입니다. 30분. 앞의 219는 지금 남은 시간이고요.
확인은 이 한 줄로 합니다.
dig +noall +authority www.내도메인.com A
| 무엇을 했나 | 기다리는 시간 | 예 |
|---|---|---|
| 있는 레코드의 값을 바꿈 | 그 레코드의 TTL (여기선 300초) | 배포처를 옮김 |
| 없던 이름을 새로 만듦 | SOA 맨 뒤 값 (여기선 1800초) | www 추가 |
| 네임서버 자체를 바꿈 | 최대 48시간 | DNS 관리를 다른 곳으로 옮김 |
그래서 www를 방금 추가했다면 5분이 아니라 30분까지 봐야 해요. 특히 없는 걸 먼저 확인한 뒤에 추가했다면, 그 확인 때문에 “없음”이 이미 캐시에 박혀 있습니다. 반대로 네임서버를 방금 바꿨다면 몇 시간 안 됐다고 조급해할 일이 아니고요.
함정 하나: 넣은 대로 안 보일 수 있어요
루트 도메인(내도메인.com)에 CNAME을 넣었는데 조회하면 안 나오는 경우가 있어요.
dig +short CNAME 내도메인.com
빈손으로 나옵니다. 그런데 같은 이름을 A로 물으면 주소는 멀쩡히 나와요.
이건 레코드가 안 들어간 게 아니라, 서비스가 CNAME을 A레코드로 바꿔서 응답하기 때문이에요. 루트 도메인에는 원래 CNAME을 쓸 수 없다는 규칙(RFC 1034)이 있어서 Cloudflare 같은 곳이 대신 처리해 줍니다.
덧붙이면 밖에서 조회하는 것만으로는 원래 A레코드였는지 CNAME이 변환된 건지 구분되지 않아요. 둘 다 똑같이 A로 나옵니다.
그러니 관리 화면에 CNAME이라고 적혀 있는데 조회에서 안 보인다고 다시 넣지 마세요. 확인은 CNAME이 아니라 주소가 나오느냐로 합니다.
이 글의 한계
두 가지를 적어 둘게요.
하나. 국내 등록기관 관리 화면은 못 봤습니다. 계정이 없어서 항목 이름이 뭐라고 적혀 있는지 확인하지 못했어요. 위에 적은 건 어느 서비스에서든 통하는 조회 방법이고, 화면 안내는 각 서비스 문서를 보셔야 합니다.
둘. 172800초는 상위 기관이 응답에 적어 보낸 값이지, 제가 네임서버를 바꿔 놓고 48시간을 실제로 재본 값이 아니에요. 그리고 위 출력은 맥에서 받은 것이라 윈도우 명령 프롬프트는 문구가 조금 다를 수 있습니다.
다시, 순서대로
순서는 셋입니다. 브라우저 문구로 도메인 문제인지부터 가르고, nslookup으로 이름이 있는지와 주인이 누구인지를 보고, 마지막에 뭘 바꿨는지로 기다릴 시간을 정해요.
주소가 열리는데 페이지가 옛날 것이면 도메인이 아니라 배포 쪽이에요. 그건 빌드 로그에서 볼 자리가 따로 있습니다.
도메인 연결하는 순서는 따로 적어 뒀어요. 거기에 안 열려도 기다리면 된다고 썼는데, 이번에 재보니 그 말은 절반만 맞았습니다. 같은 “기다리기”가 5분짜리와 30분짜리와 48시간짜리로 갈라져 있었어요.
www를 열지 말지는 정하기 나름이에요. 저는 안 열어 두는 쪽으로 정했고요. 다만 정해서 안 여는 것과 모르고 비어 있는 것은 다릅니다. 공개 전 점검 목록에 한 줄 넣으세요. www 붙여서도 한 번.
여기 말고 다른 데서 막혔다면
증상만 고르면 지금 뭘 하면 되는지 짚어줘요.
참고 자료
읽으면서 떠오른 사람에게 공유해 주세요
레스덕
· 운영자현직 개발자가 AI·바이브코딩·개발자 커리어를 직접 겪고 판단한 개인 기록입니다. 공식 자료를 간략히 요약하고, 그 위에 저의 경험·판단을 덧붙입니다. 전문 자문이 아니므로, 중요한 결정 전에는 최신 원문과 전문가 상담을 함께 확인해 주세요.
최종 수정 2026.08.16 · 문의 lessduck2@gmail.com