- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Chrome에서 HSTS(HTTP Strict Transport Security) 정책이 저장되어 특정 사이트에 “접속이 거부됨”, “이 사이트는 HSTS를 사용함”, “안전하지 않음(인증서 오류)인데도 예외 진행 불가” 같은 상황이 발생할 때, 원인을 정확히 구분하고 가장 확실한 초기화·삭제 절차를 단계별로 제공하는 것이다.
1. HSTS 때문에 “예외로 이동”이 막히는 이유를 먼저 이해해야 한다
1-1. HSTS의 동작 방식 요약
HSTS는 웹서버가 브라우저에게 “이 도메인은 앞으로 일정 기간 동안 반드시 HTTPS로만 접속하라”라고 지시하는 보안 정책이다.
브라우저는 해당 도메인의 HSTS 정책을 로컬에 저장하고, 이후 사용자가 주소창에 http://로 입력하더라도 자동으로 https://로 강제 전환한다.
또한 HSTS가 적용된 도메인에서는 인증서 오류(만료, 도메인 불일치, 자체서명 등)가 발생해도 사용자가 경고를 무시하고 진행하는 우회 경로가 차단되는 경우가 많다.
1-2. 현장에서 가장 많이 겪는 증상 패턴
| 증상 | 주소창/화면에서 흔히 보이는 문구 | 가능성이 높은 원인 | 우선 적용할 해결 방향 |
|---|---|---|---|
| HTTPS로 자동 전환되어 접속이 실패하다 | http로 입력해도 https로 바뀌다 | 해당 도메인의 HSTS 캐시가 저장되다 | chrome://net-internals/#hsts에서 도메인 정책 삭제를 시도하다 |
| 인증서 경고에서 “계속(안전하지 않음)” 버튼이 안 보이다 | “이 사이트는 HSTS를 사용하므로…” | HSTS가 예외 진행을 차단하다 | HSTS 삭제 또는 서버 인증서 정상화로 해결하다 |
| 삭제했는데도 계속 강제 HTTPS로 돌아가다 | 삭제 후에도 재발하다 | 서버가 다시 HSTS 헤더를 내려주다, includeSubDomains 영향이 있다 | 서버의 Strict-Transport-Security 헤더 점검 및 max-age 조정이 필요하다 |
| 특정 유명 도메인은 삭제가 안 되는 것처럼 보이다 | 삭제해도 다시 적용되다 | 브라우저에 내장된 프리로드(HSTS Preload) 목록에 포함되다 | 클라이언트에서 완전 해제가 어렵고 도메인/서버 측 조치가 필요하다 |
| localhost나 사내 개발 도메인에서 특히 자주 막히다 | localhost 접속 거부, 개발서버 인증서 오류 | 개발용 인증서 품질 부족 + HSTS 저장이 결합되다 | 해당 호스트 HSTS 삭제 + 개발 인증서 체계 개선이 필요하다 |
주의 : HSTS는 중간자 공격을 줄이기 위한 보안 기능이다. 운영 서비스에서 임의로 해제하는 방식은 보안 정책을 약화시키므로, 문제를 “우회”하기 전에 인증서 발급·체인을 정상화하는 것이 원칙이다.
2. 가장 빠른 해결: Chrome 내부 페이지에서 도메인 HSTS 정책 삭제하기
2-1. chrome://net-internals/#hsts로 삭제하는 표준 절차
이 방법은 “브라우저에 저장된 도메인 보안 정책(동적 HSTS)”을 직접 지우는 방식이다.
| 단계 | 작업 | 체크 포인트 |
|---|---|---|
| 1 | Chrome 주소창에 chrome://net-internals/#hsts를 입력하다 | HSTS/PKP 관련 메뉴가 표시되다 |
| 2 | Query HSTS/PKP domain에 대상 도메인을 입력하고 Query를 누르다 | Found로 표시되면 로컬에 정책이 저장되었다는 의미이다 |
| 3 | Delete domain security policies에 동일 도메인을 입력하고 Delete를 누르다 | 삭제 직후에는 별도 팝업 없이 반영되다 |
| 4 | 같은 도메인을 다시 Query로 조회하다 | Not found로 바뀌면 삭제가 성공이다 |
| 5 | Chrome을 완전히 종료 후 재실행하고 재접속을 시도하다 | 백그라운드 프로세스까지 종료해야 재발 확인이 정확하다 |
주의 : “도메인” 입력은 프로토콜(https://)을 붙이지 않고 호스트명만 입력해야 하다. 예시는 example.com 또는 sub.example.com 형태로 입력해야 하다.
2-2. 입력 도메인 범위 실수로 실패하는 경우를 정리하다
삭제가 “안 된 것처럼” 보이는 대부분의 원인은 도메인 범위 입력 실수이거나, 실제로는 다른 호스트에 HSTS가 걸린 상황이다.
| 상황 | 잘못된 입력 | 올바른 입력 | 설명 |
|---|---|---|---|
| www만 막히다 | example.com만 삭제하다 | www.example.com도 별도로 삭제하다 | 호스트 단위로 저장되기 때문에 www는 별도 항목이 되다 |
| 서브도메인이 막히다 | example.com만 삭제하다 | sub.example.com을 직접 삭제하다 | includeSubDomains로 상위 정책이 영향을 주는 경우도 있어 둘 다 점검이 필요하다 |
| 포트가 다른 개발 서버이다 | localhost:8443처럼 입력하다 | localhost만 입력하다 | HSTS는 포트가 아니라 호스트명 기준으로 적용되다 |
| IP로 접속하다 | https://10.0.0.5처럼 처리하다 | 10.0.0.5를 호스트로 조회·삭제하다 | 일부 환경에서는 IP에 대한 처리 동작이 기대와 다를 수 있어 파일 기반 초기화가 더 확실하다 |
3. 삭제했는데도 재발하는 원인을 “클라이언트”와 “서버”로 나눠서 진단하다
3-1. 서버가 계속 HSTS 헤더를 내려주면 다시 저장되다
브라우저에서 삭제하더라도 서버가 Strict-Transport-Security 헤더를 다시 보내면, 해당 도메인에 HSTS가 재저장되다.
특히 max-age가 길거나 includeSubDomains가 켜져 있으면, 서브도메인까지 광범위하게 막히는 상황이 생기다.
주의 : 실무에서 “임시로 HSTS를 꺼야 하는 상황”은 보통 개발·전환·장애 대응 구간이다. 이때 서버에서 무작정 HSTS를 켜두면 복구 시간이 길어지다. 운영 정책 변경은 반드시 보안·인프라 승인 절차를 따르는 것이 바람직하다.
3-2. HSTS Preload 목록에 들어간 도메인은 브라우저에 내장되다
일부 도메인은 브라우저 자체에 내장된 프리로드 목록에 의해 HSTS가 강제되다.
이 경우 사용자가 로컬에서 삭제해도 다시 적용되는 것처럼 보일 수 있으며, 도메인 소유자 측에서 프리로드 해제 절차를 진행해야 정상적으로 완화되다.
현장 대응 관점에서는 “테스트용으로 유명 도메인 또는 프리로드 가능성이 높은 도메인 구조를 그대로 쓰는 것”을 피하는 것이 효율적이다.
4. 내부 페이지 접근이 어렵거나, IP/특정 케이스에서 실패할 때: 프로필 파일 기반 초기화
4-1. 파일 기반 초기화가 필요한 대표 상황
다음 조건에서는 net-internals 삭제가 실패하거나 적용이 불명확할 수 있어, 프로필 파일을 백업 후 초기화하는 방식이 더 확실하다.
- 정책 삭제를 했는데도 Query가 계속 Found로 남는 경우가 반복되다
- IP 주소로 접속하는 개발/장비 관리 UI에서 HSTS가 꼬이는 경우가 있다
- 브라우저 내부 페이지 접근이 조직 정책으로 제한되는 환경이 있다
- 동일 사용자 프로필에서 여러 도메인이 한꺼번에 꼬여 신속한 일괄 초기화가 필요하다
4-2. 핵심 원리: TransportSecurity 계열 파일을 제거하면 로컬 HSTS 저장소가 초기화되다
Chrome/Chromium 계열은 프로필 경로 어딘가에 HSTS 정보를 저장하는 파일을 두고 관리하다.
일반적으로 파일명에 TransportSecurity가 포함되며, 버전이나 구조에 따라 프로필 루트 또는 Network 하위 폴더에 존재할 수 있다.
주의 : 아래 절차는 “특정 도메인만”이 아니라 “프로필에 저장된 HSTS 관련 정보 전반”을 초기화할 수 있다. 운영 환경에서 무분별하게 적용하면 다른 사이트에서도 보안 정책이 다시 학습될 때까지 동작이 달라질 수 있다.
4-3. Windows에서 안전하게 초기화하는 절차
아래 절차는 파일을 삭제하기 전에 백업(이름 변경)하는 방식으로 안내하다.
1) Chrome 완전 종료를 확인하다. - 작업 관리자에서 chrome.exe 프로세스가 남아 있으면 모두 종료하다. 2) 사용자 프로필 경로로 이동하다. - 일반적으로 다음 경로를 사용하다. C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\ 3) 사용 중인 프로필 폴더를 확인하다. - Default 또는 Profile 1, Profile 2 형태로 존재하다. 4) 아래 파일/폴더를 탐색하다. - (예시) Default\TransportSecurity - (예시) Default\Network\TransportSecurity 5) 발견한 TransportSecurity 파일을 백업 이름으로 변경하다. - TransportSecurity.bak 처럼 변경하다. - 파일이 2곳에 있으면 둘 다 동일하게 백업하다. 6) Chrome 재실행 후 문제 도메인 접속을 재시도하다.4-4. macOS와 Linux에서의 경로 개념
macOS와 Linux도 동일하게 “프로필 경로에서 TransportSecurity 파일을 찾아 백업 이름 변경”이라는 원칙을 적용하다.
환경별 기본 경로 예시는 다음과 같이 정리하다.
| OS | 대표 프로필 경로 예시 | 설명 |
|---|---|---|
| macOS | ~/Library/Application Support/Google/Chrome/ | 프로필 폴더(Default 등) 하위에서 TransportSecurity를 찾다 |
| Linux | ~/.config/google-chrome/ | 배포판/브라우저 패키지에 따라 chromium 폴더일 수도 있다 |
5. 로컬 개발·사내 장비 UI에서 특히 많이 막히는 케이스를 정리하다
5-1. localhost가 HSTS로 막히는 전형적 흐름
개발 중 임시로 HSTS 헤더를 응답하거나, 리버스 프록시/보안 게이트웨이 환경에서 HSTS가 삽입되면 localhost도 HSTS가 저장될 수 있다.
이후 자체서명 인증서 또는 SAN 구성이 부족한 인증서를 사용하면 예외 진행이 차단되어 개발이 중단되다.
5-2. 재발 방지를 위한 운영 팁
- 개발 서버는 가능하면 신뢰 가능한 로컬 CA를 만들어 개발 PC에 루트 인증서를 배포하고, 서버 인증서의 SAN을 정확히 구성하다
- 개발 도메인은 운영 도메인과 분리하고, 프리로드 가능성이 높은 도메인 구조를 그대로 재사용하지 않다
- 테스트 구간에서는 Strict-Transport-Security 헤더를 의도적으로 넣는지 여부를 릴리스 체크리스트에 포함하다
주의 : 인증서 오류를 강제로 우회하는 습관은 보안 사고로 이어질 수 있다. 개발 편의 때문에 운영과 같은 도메인에 자체서명 인증서를 섞어 쓰는 구성은 피하는 것이 안전하다.
6. “쿠키/캐시 삭제”로는 해결되지 않는 이유와, 혼동되는 설정을 구분하다
6-1. 사이트 데이터 삭제와 HSTS는 별개로 동작하다
Chrome 설정에서 “인터넷 사용 기록 삭제”, “쿠키 및 기타 사이트 데이터 삭제”를 수행해도 HSTS 정책이 반드시 함께 지워지는 것은 아니다.
따라서 HSTS로 예외 진행이 막힌 상황에서는 net-internals 삭제 또는 TransportSecurity 파일 초기화가 직접적인 해결책이 되다.
6-2. HTTP→HTTPS 리다이렉트와 HSTS를 혼동하지 않다
서버 리다이렉트(301/302)만으로도 사용자는 “자동으로 https로 바뀐다”라고 느낄 수 있다.
그러나 서버 리다이렉트는 브라우저가 경고 페이지에서 예외로 진행할 여지가 남는 경우가 많고, HSTS는 그 예외를 차단하는 점이 핵심 차이이다.
7. 실무용 빠른 체크리스트를 제공하다
| 체크 순서 | 질문 | 예 | 아니오 |
|---|---|---|---|
| 1 | 경고 화면에 HSTS 관련 문구가 명확히 보이다 | 2번으로 진행하다 | 인증서/네트워크 일반 장애 진단을 우선하다 |
| 2 | chrome://net-internals/#hsts에 접근 가능하다 | 도메인 Query 후 Delete를 수행하다 | 4번 파일 기반 초기화를 고려하다 |
| 3 | 삭제 후 Query가 Not found로 바뀌다 | Chrome 완전 종료 후 재접속하다 | 도메인 입력 범위(www/서브도메인) 재점검하다 |
| 4 | 재접속 시 다시 HSTS가 생기다 | 서버가 HSTS 헤더를 재전송하는지 점검하다 | 일시적 캐시 꼬임 가능성이 있어 프로필 정리로 마무리하다 |
| 5 | 해당 도메인이 프리로드로 의심되다 | 클라이언트만으로 완전 해제가 어려움을 전제하고 도메인/서버 조치를 검토하다 | 일반 HSTS 캐시로 보고 절차를 반복 검증하다 |
FAQ
chrome://net-internals/#hsts에서 삭제했는데도 계속 막히는 이유는 무엇인가?
가장 흔한 원인은 서버가 다시 Strict-Transport-Security 헤더를 내려주어 브라우저가 즉시 재학습하는 상황이다. 두 번째 원인은 www와 apex 도메인, 또는 서브도메인을 혼동하여 실제로 막힌 호스트를 삭제하지 않은 상황이다. 세 번째 원인은 프리로드 목록에 포함된 도메인으로, 클라이언트에서 체감상 지워지지 않는 것처럼 보이는 상황이다.
http://로 강제로 접속하고 싶은데 가능할까?
HSTS가 저장된 도메인은 브라우저가 의도적으로 HTTPS로 강제 전환하도록 설계되다. 따라서 근본적으로는 서버 측에서 HTTPS를 정상 제공하거나, 테스트 목적이라면 해당 도메인에 대한 HSTS 저장을 제거하고 서버가 HSTS 헤더를 다시 보내지 않도록 관리해야 하다.
특정 PC에서만 문제이고 다른 PC에서는 정상인 이유는 무엇인가?
HSTS는 브라우저 로컬 저장소에 기록되기 때문에 사용자 프로필 상태에 따라 달라지다. 한 PC는 과거에 HSTS 헤더를 받아 저장한 적이 있고 다른 PC는 없는 경우가 대표적이다. 또한 한 PC는 자체서명 인증서를 신뢰하도록 루트 인증서를 설치했지만 다른 PC는 설치하지 않은 경우도 차이를 만들다.
엣지(Edge)나 브레이브(Brave)도 동일한 방식으로 해결할 수 있나?
Chromium 기반 브라우저는 유사한 내부 페이지와 유사한 저장 방식을 사용하다. 예를 들어 Edge는 edge://net-internals/#hsts 형태를 사용하다. 다만 조직 정책과 버전 차이로 메뉴 구성은 달라질 수 있으므로, 원리는 동일하되 실제 경로와 UI는 해당 브라우저 기준으로 확인해야 하다.