이 글의 목적은 Chrome에서 HSTS(HTTP Strict Transport Security) 정책이 남아 “이 사이트에는 보안 연결이 필요합니다”류 오류로 접속이 막힐 때, 원인을 정확히 구분하고 브라우저 측 HSTS 상태를 초기화하는 실무 절차를 단계별로 정리하는 것이다.
1. Chrome HSTS로 접속이 막히는 대표 증상과 판단 기준
1) 흔한 화면과 메시지 패턴
HSTS가 활성화된 도메인은 브라우저가 “무조건 HTTPS로만 접속”하도록 강제한다. 따라서 인증서가 만료되었거나, 도메인과 인증서 이름이 불일치하거나, 사설 인증서를 신뢰하지 못하는 상황에서 일반적인 경고 우회 버튼이 나타나지 않거나(또는 우회가 차단되거나) 즉시 접속이 실패하는 형태로 나타나는 경우가 많다.
| 증상 | 주소창/오류 화면 힌트 | 가능성이 높은 원인 | 우선 조치 |
|---|---|---|---|
| HTTP로 접속해도 자동으로 HTTPS로 바뀌고 실패한다 | http:// 입력 후 https://로 즉시 전환 | HSTS 캐시(브라우저에 저장된 STS 정책) | chrome://net-internals/#hsts에서 해당 도메인 정책 삭제 |
| 인증서 오류 화면에서 “계속(안전하지 않음)” 같은 우회 버튼이 없다 | HSTS 관련 문구 또는 강제 차단 | HSTS 적용 중 + 인증서 신뢰 불가 | HSTS 삭제 및 인증서/시간/프록시 점검 |
| 예전에는 접속되던 개발/테스트 도메인이 갑자기 막힌다 | 내부망, hosts, 로컬 인증서 환경 | 한 번이라도 STS 헤더를 받아 캐시됨 | HSTS 삭제 + 서버 STS 헤더 정책 정리 |
| 삭제를 해도 계속 막힌다 | 정책 삭제 후에도 동일 | HSTS Preload(브라우저 내장 목록) 또는 서버가 계속 STS 헤더 재전송 | Preload 여부 확인 및 서버 측 STS 설정 수정 |
주의 : HSTS는 보안을 강화하는 표준 메커니즘이다. 업무상 임시 조치로 비활성화하더라도, 운영(외부 공개) 서비스에서는 인증서/리다이렉트/헤더 설정을 정상화하는 방향으로 복구하는 것이 원칙이다.
2. 가장 빠른 해결: Chrome에서 특정 도메인 HSTS 초기화(삭제) 절차
2.1 chrome://net-internals/#hsts로 HSTS 캐시 삭제
Chrome은 도메인별로 HSTS(및 일부 보안 정책 상태)를 내부 페이지에서 조회/삭제할 수 있다. 아래 절차는 “특정 도메인만” 초기화하는 가장 직접적인 방법이다.
| 단계 | 조치 | 입력 예시 | 결과 확인 |
|---|---|---|---|
| 1 | 주소창에 내부 페이지 접속 | chrome://net-internals/#hsts | HSTS/PKP 관련 섹션이 표시된다 |
| 2 | Query HSTS/PKP domain에 도메인 조회 | example.com (프로토콜/경로 없이 도메인만) | Found/Not found 등 상태가 출력된다 |
| 3 | Delete domain security policies에 동일 도메인 입력 후 Delete | example.com | 삭제 후 재조회 시 Not found로 바뀌는지 확인한다 |
| 4 | Chrome 완전 종료 후 재실행 | 모든 창 종료 | 재접속 시 강제 HTTPS/차단이 완화되는지 확인한다 |
2.2 입력 도메인 형식 실수로 실패하는 경우
삭제 입력란에는 “도메인만” 넣는 것이 일반적이다. https://, 포트(:8443), 경로(/login)까지 넣으면 의도대로 매칭되지 않아 삭제가 되지 않는 사례가 있다. 동일 서비스라도 www 하위 도메인과 루트 도메인이 분리되어 저장될 수 있으므로, 필요 시 example.com과 www.example.com을 각각 조회/삭제한다.
2.3 삭제했는데도 계속 막힐 때: Preload(내장 목록) 가능성
일부 대형 도메인은 HSTS Preload 목록으로 브라우저에 “내장”되어 배포된다. 이 경우 로컬 캐시 삭제만으로 강제 HTTPS가 사라지지 않을 수 있다. 이때는 브라우저 측 초기화로 해결하려고 하기보다, 해당 도메인 운영자가 인증서/리다이렉트/헤더 정책을 정상화해야 한다.
주의 : Preload로 내장된 도메인은 사용자 PC에서 임의로 완전히 해제하는 것이 전제부터 어렵다. 이때는 “브라우저 문제가 아니라 서비스 설정 문제”로 분류하고, 인증서 유효성/중간인증서 체인/서버 시간/리버스 프록시 구성부터 점검하는 것이 정상 절차이다.
3. HSTS 삭제 후에도 접속이 안 되면 같이 초기화해야 하는 것들
3.1 사이트 데이터(쿠키/캐시)와 리다이렉트 캐시 정리
HSTS와 별개로, 301/308 영구 리다이렉트 캐시나 서비스워커/캐시 저장소가 남아 HTTPS로 계속 끌고 가는 경우가 있다. 다음 순서로 정리하면 재현되는 실패를 줄일 수 있다.
| 구분 | 메뉴/위치 | 권장 범위 | 비고 |
|---|---|---|---|
| 사이트 데이터 삭제 | 설정 → 개인정보 및 보안 → 인터넷 사용 기록 삭제 | 쿠키 및 기타 사이트 데이터, 캐시된 이미지/파일 | 가능하면 “기간: 전체”가 확실하다 |
| 특정 사이트만 정리 | 설정 → 개인정보 및 보안 → 사이트 설정 → 모든 사이트 데이터 및 권한 보기 | 문제 도메인 검색 후 데이터 삭제 | 업무 영향 최소화에 유리하다 |
| 서비스워커 영향 배제 | 개발자도구(F12) → Application | Service Workers/Storage 확인 | 개발/테스트 환경에서 특히 유의한다 |
3.2 Windows에서 “SSL 상태” 초기화(인증서 세션 캐시 정리)
Windows 환경에서는 인터넷 옵션의 SSL 상태 캐시가 접속/인증서 검증 흐름에 영향을 주는 경우가 있다. 특히 사내 프록시나 SSL 가시화(복호화) 장비 환경에서 재현되는 인증서 경고가 남아 있을 때 보조적으로 시도할 가치가 있다.
경로는 일반적으로 다음과 같다. 제어판(또는 Windows 설정에서 “인터넷 옵션” 검색) → 콘텐츠 탭 → SSL 상태 지우기이다. 조치 후 Chrome을 재시작하고 재접속을 확인한다.
3.3 DNS 캐시 및 소켓 풀 초기화
도메인 인증서 문제가 아니라, DNS가 꼬여 엉뚱한 서버로 가서 인증서 불일치가 발생하는 경우도 있다. 이때는 OS DNS 캐시를 먼저 정리하는 것이 합리적이다.
REM Windows: 관리자 권한 CMD 권장 ipconfig /flushdns REM (선택) 네트워크 스택 초기화가 필요한 경우 netsh winsock resetChrome 자체의 DNS/소켓 캐시를 비우는 방법도 실무에서 자주 사용된다. chrome://net-internals/ 기능이 환경에 따라 제한적으로 보일 수 있으므로, 가능한 범위에서 DNS 캐시 및 소켓 관련 초기화를 수행한 뒤 재시작하여 확인한다.
주의 : netsh winsock reset은 네트워크 구성에 영향을 줄 수 있으므로, 업무용 단말에서는 변경 이력 관리와 재부팅 계획을 포함해 수행하는 것이 안전하다.
4. 근본 원인 해결: 서버가 STS 헤더를 계속 보내는지 점검
4.1 서버가 Strict-Transport-Security를 재전송하면 “삭제해도 다시 걸린다”
브라우저에서 HSTS를 삭제했는데 다음 접속에서 즉시 다시 강제 HTTPS가 걸리면, 서버(또는 CDN/리버스 프록시)가 Strict-Transport-Security 헤더를 지속적으로 내려보내고 있을 가능성이 높다. 이때는 클라이언트 초기화만 반복해도 해결되지 않는다.
4.2 개발/테스트 환경에서 흔한 실수 패턴
| 상황 | 실수 | 결과 | 정리 방향 |
|---|---|---|---|
| 내부 테스트 도메인에 HTTPS를 잠깐 적용 | STS 헤더(max-age)가 큰 값으로 배포됨 | HTTP 테스트가 장기간 불가 | 테스트 종료 시 STS 헤더 제거 또는 max-age 최소화 |
| 리버스 프록시에서 보안 헤더 일괄 삽입 | 운영/개발 구분 없이 STS가 들어감 | 개발 환경에서도 강제 HTTPS | 환경별 헤더 정책 분리 |
| 사설 인증서/사내 CA 사용 | 단말 신뢰 저장소에 CA 미배포 | 인증서 신뢰 실패 + HSTS로 우회 불가 | 사내 CA 배포/체인 정합성 확보 |
4.3 서버 측에서 HSTS를 “해제”하는 표준적 방법
서버가 한 번이라도 HSTS를 배포했다면, 브라우저에 남아있는 기간 동안 강제 HTTPS가 지속된다. 운영 정책상 HSTS를 중단해야 한다면, 일반적으로 Strict-Transport-Security 헤더를 제거하고, 이미 적용된 브라우저 캐시를 정리하기 위한 전환 기간을 고려한다. 일부 구현에서는 max-age=0으로 내려보내어 즉시 만료시키는 전환 방식을 사용한다. 다만 이 방식은 “이미 HSTS를 신뢰하고 있는 상태에서 HTTPS로 정상 접속이 가능해야” 적용 자체가 가능하므로, 인증서가 깨진 상태에서는 먼저 인증서 복구가 선행되어야 한다.
주의 : 운영 서비스에서 HSTS를 끄는 결정은 보안 수준을 낮추는 변경이다. 보안 감사, 고객 영향, 인증서 자동갱신 체계, 프록시 구성까지 포함해 변경관리 절차로 다루는 것이 원칙이다.
5. 실무용 점검 체크리스트
현장에서 “Chrome만 특정 사이트 접속 불가”가 보고되면 아래 체크리스트 순서대로 진행하면 원인 분류와 조치 속도가 올라간다.
| 우선순위 | 점검 항목 | 확인 방법 | 조치 |
|---|---|---|---|
| 1 | 단말 시간/타임존 이상 여부 | Windows 시간 동기화 상태 확인 | 시간 보정 후 재접속 |
| 2 | HSTS 캐시 존재 여부 | chrome://net-internals/#hsts 조회 | Delete domain security policies로 삭제 |
| 3 | 서버 인증서 정상 여부 | 다른 브라우저/다른 네트워크에서 비교 | 인증서 갱신/체인 수정/도메인 일치 확인 |
| 4 | DNS 이상(오염/분기) 여부 | nslookup으로 응답 IP 비교 | ipconfig /flushdns, DNS 서버 점검 |
| 5 | 프록시/보안 장비 SSL 가시화 영향 | 프록시 설정, 보안 에이전트 정책 확인 | 예외 정책 또는 CA 신뢰 배포 |
| 6 | Preload 가능성 | 대형 도메인/브라우저 내장 가능성 검토 | 서비스 측 정상화로 해결 방향 전환 |
FAQ
chrome://net-internals/#hsts에서 삭제했는데도 계속 HTTPS로만 가고 접속이 막힌다. 왜 그런가?
첫째, 서버가 Strict-Transport-Security 헤더를 계속 내려보내고 있어 삭제 후 재접속 시 즉시 다시 저장되는 경우가 있다. 둘째, 해당 도메인이 HSTS Preload 목록으로 브라우저에 내장된 경우 로컬 삭제만으로 강제 HTTPS가 사라지지 않을 수 있다. 셋째, HSTS가 아니라 301/308 영구 리다이렉트 캐시나 서비스워커 저장소가 HTTPS로 고정시키는 경우도 있으므로, 사이트 데이터/캐시 정리를 함께 수행하는 것이 실무적으로 안전하다.
도메인을 입력할 때 https://까지 붙여도 되나?
일반적으로는 도메인만 입력하는 방식이 매칭 성공률이 높다. 프로토콜, 포트, 경로를 포함하면 동일 도메인 상태를 가리키지 못해 삭제가 실패하는 사례가 있다. example.com과 www.example.com처럼 하위 도메인이 분리된 경우 각각 삭제가 필요할 수 있다.
내부 개발 사이트에서 HSTS가 자꾸 걸린다. 재발 방지는 어떻게 하나?
개발/테스트 환경에서 보안 헤더를 일괄 적용하는 프록시/CDN 템플릿을 사용하면 STS가 의도치 않게 배포될 수 있다. 환경별로 헤더 정책을 분리하고, 테스트 도메인에는 장기 max-age를 사용하지 않도록 운영 기준을 정리하는 방식이 일반적이다. 사설 인증서를 쓰는 경우 단말 신뢰 저장소에 사내 CA를 배포하여 인증서 경고 자체가 발생하지 않게 만드는 것이 근본 대책이다.
HSTS를 꺼도 보안상 문제가 없나?
HSTS는 HTTPS 강제를 통해 중간자 공격 위험을 낮추는 보안 장치이다. 운영 서비스에서 임의로 끄는 것은 보안 수준 저하로 분류된다. 다만 인증서 장애 복구 과정에서 “정상 HTTPS가 먼저 복구되어야” 사용자 접근성과 보안이 함께 회복되는 구조이므로, 운영 환경에서는 HSTS 해제보다 인증서/체인/리다이렉트 정상화를 우선해야 한다.