사이트가 안 열릴 때: DNS부터 HTTPS까지 좁혀가기

STEP 01먼저 “안 열린다”를 한 요청으로 기록하기

브라우저 오류 화면만으로는 수정할 위치를 정하기 어렵습니다. 정확한 URL, 발생 시각, 사용한 네트워크, 오류 문구부터 적습니다. 홈은 열리는데 특정 글만 안 열리는 경우와 도메인 자체가 해석되지 않는 경우를 섞지 않는 것이 출발점입니다.

아래 예시의 example.com을 자신의 도메인으로 바꿉니다. 첫 요청은 리디렉션을 자동으로 따라가지 않습니다. 301·302라면 Location이 의도한 주소인지 먼저 보고, 그 주소를 별도로 검사합니다.

site_domain=example.com
curl -sS --connect-timeout 3 --max-time 10   -D - -o /dev/null   -w '
http=%{http_code} ip=%{remote_ip} tls=%{ssl_verify_result}
'   "https://${site_domain}/"
printf 'curl_exit=%s
' "$?"

HTTP 000은 서버가 보낸 상태 코드가 아니라 HTTP 응답을 얻지 못했다는 표시입니다. curl의 오류 문구와 종료 코드를 함께 읽습니다. 반대로 HTTP 404나 500을 받아도 이 명령의 curl 종료 코드는 0일 수 있습니다. 전송 성공과 서비스 성공은 다른 판단입니다.

STEP 02DNS 담당자와 서버 주소를 대조하기

도메인을 구매한 곳, DNS 레코드를 편집하는 곳, 웹 서버가 있는 곳은 다를 수 있습니다. 등록 업체 화면에서 바꾼 값이 현재 위임된 DNS 영역의 값인지부터 확인합니다. NS는 담당 네임서버, A는 IPv4 주소, AAAA는 IPv6 주소를 확인하는 출발점입니다.

dig +short NS "$site_domain"
dig +short A "$site_domain"
dig +short AAAA "$site_domain"

자기 리졸버에서 조회한 값과 호스팅 관리 화면의 할당 주소를 나란히 놓고 비교합니다. CDN이나 프록시를 사용한다면 공개 주소가 원본 IP와 다를 수 있으므로 그 구조부터 확인해야 합니다. 무조건 원본 IP로 덮어쓰면 기존 서비스를 우회할 수 있습니다.

펀치블로그의 실제 기록에서는 AAAA 첫 묶음이 406:에서 2406:으로 수정됐습니다. 두 주소 모두 문법 검사에 통과하므로 “올바른 IPv6 형식”이라는 결과만으로 발견할 수 없었습니다. 변경 기록과 전체 주소 비교가 이 판단의 근거입니다. 이것이 과거의 모든 접속 문제를 설명한다는 뜻은 아닙니다.

STEP 03IPv4와 IPv6 요청을 따로 보내기

curl -4 -sS --connect-timeout 3 --max-time 10   -o /dev/null -w 'IPv4 http=%{http_code} ip=%{remote_ip}
'   "https://${site_domain}/"
curl -6 -sS --connect-timeout 3 --max-time 10   -o /dev/null -w 'IPv6 http=%{http_code} ip=%{remote_ip}
'   "https://${site_domain}/"

한쪽만 실패하면 DNS 레코드 외에도 해당 주소로의 라우팅, 방화벽, 웹 서버의 수신 설정을 확인할 후보로 둡니다. 검사하는 컴퓨터가 IPv6를 사용할 수 없는 경우도 있으므로, curl -6 실패를 곧바로 서버 고장으로 결론내리지 않습니다. 다른 IPv6 사용 가능 환경에서 재확인한 결과를 구분해 남깁니다.

STEP 04원본은 도메인을 유지한 채 검사하기

공개 DNS 경로와 원본 서버를 나눠 볼 때 HTTPS URL을 IP 주소로 바꾸면 인증서의 이름 검증 조건도 달라집니다. curl --resolve는 URL의 도메인을 유지하면서 특정 호스트·포트의 연결 주소를 지정합니다. 서버의 실제 IPv4를 확인한 다음에만 아래 예시의 문서용 주소를 바꾸어 실행합니다.

# 192.0.2.10은 예시 주소입니다. 자신의 원본 IPv4로 바꿉니다.
origin_ipv4=192.0.2.10
curl -sS --connect-timeout 3 --max-time 10   --resolve "${site_domain}:443:${origin_ipv4}"   -D - -o /dev/null "https://${site_domain}/"

인증서 오류가 나면 검증을 끄고 완료 처리하지 않습니다. URL의 이름, 인증서 적용 대상, 체인, 만료일을 살펴봅니다. 원본이 CDN에서 오는 요청만 허용하도록 구성됐다면 외부 직접 검사 실패는 의도된 결과일 수 있습니다. Host 헤더만 바꾸는 검사와의 차이는 별도 실험에서 확인했습니다.

STEP 05200 다음에는 본문과 없는 주소도 확인하기

서버가 받은 검색 조건이 원래 입력과 다르다면 DNS 설정을 바꾸기 전에 원본 문자열과 쿼리의 +·빈값·중복 키를 직접 비교할 수 있습니다. 이 도구는 브라우저의 문자열 처리만 보여 주며 실제 서버 요청을 보내지 않습니다.

상태 코드 200만 나오면 다른 가상 호스트의 기본 페이지가 응답해도 성공처럼 보입니다. 홈을 GET으로 받아 사이트 이름이나 배포한 문장이 실제로 있는지 확인합니다. 본문이 필요하므로 HEAD 요청만으로 끝내지 않습니다. 자동 점검기가 HEAD를 사용하는 경우에는 GET 결과와 차이가 있는지도 기록합니다.

curl -sS --connect-timeout 3 --max-time 10 "https://${site_domain}/"

이어서 기존 글 하나와 존재하지 않는 테스트 경로 하나를 검사합니다. 작은 정적 블로그라면 없는 글은 보통 404가 기대값입니다. 모든 주소를 홈으로 넘기는 설정은 잘못된 주소도 200으로 만들 수 있습니다. 다만 클라이언트 라우팅을 쓰는 앱은 요구사항이 다르므로 정적 사이트의 404 실험을 그대로 적용하기 전에 서비스 구조를 확인합니다.

STEP 06변경 완료를 기록하고 다음 문제로 넘어가기

진단이 끝나면 “DNS 수정 완료”보다 아래 네 항목을 남기는 편이 다음 문제를 찾기 쉽습니다. 수정 전후 값은 별도로 보관하고, 재검사 시각을 과거 장애 시각과 섞지 않습니다.

• 어느 DNS 영역에서 어떤 레코드 값을 바꿨는가.
• 조회된 A·AAAA와 접속한 IP가 의도한 경로인가.
• 사용 중인 각 주소 체계에서 TLS 검증과 GET 요청이 성공했는가.
• 홈·대표 글·없는 경로가 각각 기대한 본문과 상태를 반환하는가.

펀치블로그의 2026-10-15 후속 확인에서는 IPv4·IPv6의 홈과 개인정보처리방침, 네 GET 요청이 모두 200이었습니다. 이는 그 시점의 해당 경로 관찰입니다. 장기간 가용성이나 검색엔진 접근, 광고 심사 결과를 증명하는 자료는 아닙니다. 연결은 맞지만 배포한 파일이 보이지 않는다면 다음 정적 사이트 배포 가이드로 이어갑니다.

curl 종료 코드와 HTTP 상태를 구분하는 표, 제한 시간을 둔 최종 GET 검사 예시는 도메인 연결 기록의 독자용 확인 절차에 추가했습니다. 200과 함께 최종 URL·기대한 본문까지 확인하고, 9월의 DNS 관찰값을 현재 설정으로 복사하지 않습니다.