사이트가 열리지 않을 때

사이트가 열리지 않을 때 가장 먼저 할 일은 도메인이 살아 있는지 확인하는 것입니다. 대시보드 도메인 목록에서 해당 도메인의 상태 라벨과 만료일을 보고, 이어서 dig A example.co.kr +short 한 줄로 이름이 IP를 돌려주는지 확인하면 원인이 네 갈래 중 어디인지 거의 갈립니다. 이름이 아예 안 풀리면 도메인이나 DNS 쪽이고, IP는 나오는데 연결이 안 되면 서버 쪽, 연결은 되는데 경고가 뜨면 인증서 쪽입니다.

아래 순서는 앞 단계가 통과해야 다음 단계가 의미 있게 배치되어 있습니다. 중간을 건너뛰면 엉뚱한 곳을 고치게 되므로 순서대로 진행하세요.

먼저 원인을 네 갈래로 나눕니다

가장 빠른 한 줄

dig A example.co.kr +short

대시보드

https://app.leto.kr 도메인 목록의 상태와 만료일

위임 확인

WHOIS 조회의 네임서버 항목

서버 분리

curl 의 --resolve 로 IP 직접 지정

순서대로 확인하기

1. 도메인 상태와 만료일을 봅니다

   https://app.leto.kr 에 로그인해 도메인 목록을 엽니다. 목록의 상태 컬럼에 활성, 이전 처리 중, 삭제 대기, 정지됨, 삭제됨, 확인 필요 같은 라벨이 표시되고 만료일 컬럼과 남은 일수도 같이 보입니다. 상태가 활성이 아니면 DNS나 서버를 보기 전에 그 문제를 먼저 풀어야 합니다.

   만료가 원인이면 상세 화면의 연장하기 버튼이나 비로그인 연장으로 즉시 갱신합니다. 만료일이 이미 지났다면 유예와 복구 기간에서 현재 어느 단계인지 확인하세요. 상태가 정지됨 또는 확인 필요 라면 도메인이 정지되었을 때로 갑니다.

2. 네임서버 위임이 정상인지 봅니다

   도메인 상태가 정상인데도 이름이 안 풀리면 위임부터 확인합니다.

   # 레지스트리에 등록된 네임서버
   dig NS example.co.kr +short
   
   # 루트부터 따라 내려가며 실제 위임 경로 확인
   dig NS example.co.kr +trace | tail -15
   

   WHOIS 조회에서도 등록된 네임서버를 볼 수 있습니다. 값이 비어 있거나 예상과 다르면 네임서버 설정이 원인입니다. 고치는 방법은 네임서버 변경하기에 있습니다.

3. A 레코드를 권한 서버와 공개 리졸버 양쪽에서 확인합니다

   권한 네임서버가 답하는 값과 공개 리졸버가 답하는 값을 비교하면 "아직 안 퍼진 것"과 "애초에 없는 것"을 구분할 수 있습니다.

   # 권한 네임서버에 직접 질의
   dig @ns1.example-dns.com A example.co.kr +noall +answer
   
   # 공개 리졸버가 지금 답하는 값
   dig @1.1.1.1 A example.co.kr +short
   dig @8.8.8.8 A example.co.kr +short
   

   권한 서버에 값이 없다면 레코드를 넣지 않았거나 지운 것입니다. 권한 서버에는 있고 공개 리졸버에만 없다면 전파 중이므로 DNS 변경이 반영되지 않을 때를 보세요. www 만 안 열리는 경우도 흔하므로 www.example.co.kr 도 따로 질의합니다.

4. 서버 IP로 직접 요청해 봅니다

   이름이 정상적으로 IP를 돌려주면 이제 서버 차례입니다. DNS를 건너뛰고 IP를 직접 지정해서 응답이 오는지 봅니다.

   # 지금 연결되는 IP와 응답 코드
   curl -sS -o /dev/null -w 'code=%{http_code} ip=%{remote_ip}\n' https://example.co.kr
   
   # DNS 를 무시하고 특정 서버 IP 로 직접 요청
   curl -sS -o /dev/null -w 'code=%{http_code}\n' \
     --resolve example.co.kr:443:203.0.113.10 https://example.co.kr
   
   # 포트가 열려 있는지만 확인
   nc -vz 203.0.113.10 443
   nc -vz 203.0.113.10 80
   

   IP로 직접 요청했을 때 응답이 오면 DNS나 앞단 설정 문제이고, 그때도 응답이 없으면 서버나 방화벽 문제입니다. 호스팅 상품이라면 대시보드의 호스팅 관리에서 상태가 활성인지, 디스크 사용량이 한도에 닿지 않았는지 확인하세요.

5. 인증서를 확인합니다

   연결은 되는데 브라우저가 경고 화면을 띄우면 인증서 문제입니다.

   openssl s_client -connect example.co.kr:443 -servername example.co.kr </dev/null 2>/dev/null \
     | openssl x509 -noout -subject -dates -ext subjectAltName
   

   notAfter 날짜가 지났거나 subjectAltName 목록에 실제 접속 이름이 없으면 그것이 원인입니다. 오류 종류별 대처는 SSL 인증서 오류가 뜰 때에 정리했습니다.

나만 안 되는가, 모두 안 되는가

여기서 갈라야 고칠 대상이 정해집니다. 모두 안 되는 상황에서 내 PC 캐시를 비우는 것은 시간 낭비이고, 반대로 나만 안 되는데 서버를 재시작하면 멀쩡한 서비스를 흔들게 됩니다.

• 휴대폰에서 와이파이를 끄고 모바일 데이터로 같은 주소를 열어 본다
• dig @1.1.1.1 과 dig @8.8.8.8 결과가 사내 리졸버 결과와 같은지 비교한다
• 다른 지역, 다른 회선에 있는 동료에게 접속을 부탁한다
• 시크릿 창과 다른 브라우저로 열어 본다
• 사내 보안 장비나 프록시의 차단 목록을 확인한다

나만 안 되는 경우라면 캐시를 비웁니다. 리졸버와 OS, 브라우저가 각각 따로 캐시를 들고 있으므로 순서대로 비워야 합니다.

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Windows (명령 프롬프트, 관리자)
ipconfig /flushdns

# Linux (systemd-resolved)
sudo resolvectl flush-caches

브라우저는 자체 DNS 캐시와 HSTS 목록을 따로 들고 있습니다. 크롬에서는 주소창에 chrome://net-internals/#dns 를 열어 캐시를 비우고, 과거에 HTTPS로 접속한 적이 있는 도메인이 HSTS 때문에 계속 HTTPS로 강제 전환된다면 chrome://net-internals/#hsts 에서 해당 도메인을 삭제합니다.

증상별로 가장 흔한 원인

장애 원인이 레토 측 서비스로 의심되면 공지사항에 점검이나 장애 안내가 올라와 있는지도 함께 확인하세요.

그래도 해결되지 않으면

위 단계를 모두 지나도 원인이 잡히지 않으면 다음 내용을 정리해서 문의로 보내 주세요. 같은 확인을 반복하지 않아도 되므로 처리가 빨라집니다.

• 도메인 이름과 대시보드에 보이는 상태 라벨, 만료일
• 언제부터 안 되는지, 그 직전에 무엇을 바꿨는지
• dig NS 와 dig A 의 실제 출력 (권한 서버와 공개 리졸버 양쪽)
• curl 요청의 응답 코드와 접속된 IP
• 브라우저에 뜨는 오류 코드 전문과 화면 캡처
• 나만 안 되는지 모두 안 되는지 확인한 결과