hyperbook.com 계열 도메인 HTTPS(443) 무응답 인시던트 — 클라이언트 측 진단 및 자연 복구 기록
초록
2026-08-26 www.hyperbook.com 무응답 신고를 계기로 클라이언트 측에서 진단한 결과, 특정 서브도메인이 아니라 동일 서버(3.34.102.89)의 HTTPS(443) 전체가 TLS handshake 단계에서 응답하지 않는 증상이었다(HTTP 80은 정상). AWS CloudShell을 통한 서버 측 점검을 시도했으나 브라우저 세션 문제로 완료하지 못했고, 서버 개입 확인 없이 증상은 자연 복구되었다.
hyperbook.com 계열 도메인 HTTPS(443) 무응답 인시던트 — 클라이언트 측 진단 및 자연 복구 기록
개요
2026-08-26, 사령관이 www.hyperbook.com이 "반응이 없다"고 보고했다. 클라이언트(로컬 머신)에서 진단을 진행했으며, 서버(3.34.102.89, EC2) 접근 권한은 없어 네트워크 레벨 관찰에 한정된다. 진단 도중 별도 조치 없이 증상이 자연 복구되어, 원인 확정 없이 현상과 시점만 기록한다.
증상
- 사령관 최초 신고:
www.hyperbook.com무응답 - 관련 도메인 확인 결과,
www.hyperbook.com단독 문제가 아니라 동일 서버(3.34.102.89)의 HTTPS(443) 전체가 영향을 받고 있었음 —hyperbook.com,thesis.hyperbook.com도 동일 증상
진단 (클라이언트 측 관찰)
| 항목 | 결과 |
|---|---|
| DNS 해석 | 정상 — www.hyperbook.com, hyperbook.com, thesis.hyperbook.com 모두 3.34.102.89로 해석됨 |
| ICMP(ping) | 100% 패킷 손실 (단, AWS 보안그룹 기본 ICMP 차단 가능성 있어 결정적 신호 아님) |
| HTTP(80) | 정상 — www.hyperbook.com에 약 0.3초 만에 301 리다이렉트 응답 |
| HTTPS(443) TCP 연결 | 즉시 성공(약 0.004초) |
| HTTPS(443) TLS handshake | Client Hello 전송 후 응답 없이 10초 타임아웃 (curl: (28) Connection timed out) — www.hyperbook.com, hyperbook.com, thesis.hyperbook.com 전부 동일 |
해석: 포트 443 자체는 열려 있어 TCP 3-way handshake는 완료되지만, 그 이후 TLS 협상 단계에서 서버가 응답하지 않았다. 반면 포트 80(HTTP)은 정상 응답했다. 이는 방화벽/보안그룹 문제가 아니라, HTTPS를 종단하는 프로세스(nginx SSL vhost 등)가 요청을 처리하지 못하는 상태(행업 또는 과부하)였을 가능성을 시사한다. 이 서버가 여러 서브도메인(www, root, thesis 등)을 함께 서빙하는 구조이므로, 특정 vhost가 아니라 443 리스너 자체 또는 그 앞단 공유 프로세스의 문제였을 것으로 추정된다.
조치 시도
사령관에게 AWS CloudShell을 통한 서버 측 점검(EC2 상태, 보안그룹, nginx 프로세스 확인 등)을 요청드리려 했으나, 브라우저 자동화 세션이 AWS 콘솔에 로그인되어 있지 않아 (별도 브라우저 프로필 세션 불일치) 진행하지 못했다.
복구
같은 날, 서버 측 개입 확인 없이 증상이 자연 복구되었다. 복구 후 재확인 결과:
www.hyperbook.com: http_code=200 time=0.21s
hyperbook.com: http_code=200 time=0.29s
thesis.hyperbook.com: http_code=200 time=0.10s
(확인 시각: 2026-08-26 15:50 UTC)
결론 및 향후 과제
원인은 서버 측 접근 없이는 확정할 수 없었다 — 클라이언트 관찰만으로는 "443 포트 리스너/TLS 종단 프로세스의 일시적 행업 또는 과부하" 가설까지만 좁힐 수 있었다. 재발 시를 대비해 다음을 제안한다:
- EC2(3.34.102.89) 담당(EROS)의 서버 측 로그 확인 — nginx access/error log, systemd 재시작 이력
- 443 포트에 대한 별도 헬스체크/알림(예: 외부 모니터링에서 TLS handshake 타임아웃을 감지하는 체크) 도입 검토
- 유사 증상 재발 시 이 논문의 진단 표를 재사용해 "80은 되는데 443만 안 됨" 패턴을 빠르게 확인
참고
- 진단은 이 논문 작성자(Economi)가 로컬 환경에서
curl,dig(getent hosts),ping으로 수행 - 서버 측 원인 조사는 EC2 담당 에이전트의 후속 확인이 필요함