Chrome HTTP 경고: 내 사이트 지금 확인하고 고치는 법

무엇이 바뀌었나

2026년 10월에 나온 Chrome 154는 항상 보안 연결 사용(Always Use Secure Connections) 설정을 모든 사용자에게 기본으로 켭니다. 이 설정이 켜져 있으면 Chrome은 모든 접속을 먼저 HTTPS로 시도합니다. 공개 사이트에 HTTPS로 연결할 수 없으면 페이지를 열기 전에 경고 화면을 띄우고, 방문자가 계속할지 직접 골라야 합니다.

향상된 세이프 브라우징을 켠 사용자에게는 2026년 4월 Chrome 147부터 이미 켜져 있었습니다. 10월부터는 나머지 모든 사용자에게 적용됩니다.

Google 발표에서 누가 영향을 받는지를 가르는 내용은 세 가지입니다.

• 사설 사이트는 제외합니다. 기본 설정에서는 로컬 IP 주소, 점이 없는 단일 이름 호스트(http://intranet), 사내망에 경고하지 않습니다.
• 자주 가는 사이트에는 반복해서 경고하지 않습니다. HTTPS가 없는 사이트를 최근에 방문하지 않았을 때 경고합니다. 그래서 경고를 보는 사람은 처음 오거나 가끔 오는 방문자입니다. 랜딩 페이지, 캠페인 링크, QR 코드가 노리는 바로 그 사람들입니다.
• 넘길 수 있고 끌 수도 있습니다. 그렇다고 문제가 없는 것은 아닙니다. 방문자와 페이지 사이에 경고 화면이 끼면, 대개는 방문자를 잃습니다.

HTTPS 페이지가 http:// 이미지나 스크립트를 불러오는 혼합 콘텐츠(mixed content)와는 별개의 이야기입니다. 그 경우는 브라우저 동작이 따로 있습니다. 혼합 콘텐츠를 보세요.

누가 영향을 받나

누군가 입력하거나 누르거나 스캔해서 결국 평문 HTTP로 열리는 공개 주소라면 모두 해당합니다.

• HTTPS가 아예 없는 사이트
• HTTPS는 있지만 http://가 HTTPS로 리다이렉트되지 않고, 예전 링크·인쇄물·QR 코드·메일 서명을 통해 http://로 들어오는 사이트
• 아무도 신경 쓰지 않던 서브도메인: 지난 캠페인 사이트, 상태 페이지, 예약 시스템, 우리 도메인 이름으로 돌아가는 협력사 화면
• 공인 주소로 자체 웹 화면을 내놓은 장비
• 인증서 만료 등으로 HTTPS가 깨진 사이트. 이 변화와 상관없이 그 자체로 이미 문제이니 먼저 고치세요(인증서 만료).

지금 확인하기

1. http://가 어디로 가는지 보기

curl -sI http://example.com/ | head -5

HTTPS 주소로 리다이렉트되면 정상입니다.

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

여기서 200 OK가 나오면 그 사이트는 평문 HTTP로 페이지를 내보내고 있습니다. Location이 다른 http:// 주소라면 curl -sIL로 끝까지 따라가 최종 주소를 확인하세요. 루트 도메인과 www, 링크에 등장하는 모든 호스트명에 대해 각각 확인합니다.

HTTP 점검은 리다이렉트를 끝까지 따라가고, 최종 페이지가 평문 HTTP면 경고합니다.

2. HTTPS가 실제로 동작하는지 확인

curl -sI https://example.com/ | head -3
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -enddate

맞는 이름의, 만료되지 않은, 브라우저가 신뢰하는 CA의 인증서여야 합니다. SSL 점검은 실제 연결로 인증서를 읽고 체인까지 확인합니다.

3. 잊고 있던 호스트 찾기

가장 흔한 놀라움은 잊고 있던 서브도메인입니다. 우리 이름으로 발급된 공인 인증서는 모두 인증서 투명성(CT) 로그에 남기 때문에, 기억나지 않는 서브도메인도 로그에서 나옵니다. 관리자 페이지 노출 점검은 그 로그에서 서브도메인을 찾아 바깥에서 한 번씩 열어 보고, HTTP로만 열리는 호스트를 표시합니다.

4. 내 브라우저에서 먼저 켜 보기

Google이 사이트 운영자에게 권하는 방법은 지금 바로 이 설정을 켜고 무엇이 막히는지 보는 것입니다. Chrome 설정 → 개인정보 보호 및 보안 → 보안 → “항상 보안 연결 사용”에 있습니다. 켠 다음 방문자처럼 우리 사이트, 링크, QR 코드를 하나씩 열어 보세요.

고치기

인증서 받기

대부분의 호스팅 관리 화면에서 무료 인증서를 몇 번의 클릭으로 발급할 수 있습니다. 직접 운영하는 서버라면 Let’s Encrypt와 certbot을 씁니다.

sudo certbot --nginx -d example.com -d www.example.com

CDN을 쓰면 방문자가 보는 인증서는 보통 CDN이 발급합니다. CDN에서 원 서버로 가는 연결도 HTTPS인지 확인하세요.

HTTP를 HTTPS로 리다이렉트

nginx:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Apache(.htaccess 또는 :80 가상 호스트):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

경로를 유지하는 영구(301) 리다이렉트를 쓰세요. 예전 링크 http://example.com/booking이 홈이 아니라 같은 페이지의 HTTPS 주소로 가야 합니다(301과 302). 프록시나 CDN 뒤에서 리다이렉트가 무한히 돈다면 프록시가 원 서버와 HTTP로 통신하고 있는 것입니다. 리다이렉트 루프를 보세요.

아직 http://로 남은 것 고치기

• 사이트 안의 링크, canonical 태그, 사이트맵
• action이 http:// 주소인 입력 폼
• 메일 템플릿, 서명, 인쇄물, QR 코드. QR 코드는 고칠 수 없으니, 인쇄물이 남아 있는 동안은 리다이렉트를 유지하세요.

그다음 브라우저가 기억하게 하기

모든 곳에서 HTTPS가 동작하면 Strict-Transport-Security 헤더를 보내 브라우저가 아예 HTTP를 시도하지 않게 합니다. 짧은 max-age로 시작해서 모든 서브도메인이 HTTPS로 동작하는 것을 확인한 뒤 늘리세요. includeSubDomains나 preload를 넣기 전에는 HSTS 체크리스트를 먼저 읽으세요.

당장 HTTPS로 옮길 수 없는 호스트라면

HTTPS를 지원하지 않는 오래된 장비나 우리가 손댈 수 없는 외부 시스템도 있습니다. 그럴 때 현실적인 선택지는 셋입니다.

• 앞에 HTTPS를 대신 처리하는 리버스 프록시나 CDN을 둡니다.
• 공개 인터넷에서 내리고, VPN을 통해 사설 IP나 내부 이름으로 접속하게 합니다. 기본 설정에서는 이런 주소에 경고하지 않습니다.
• 아니면 없앱니다.

HTTP로 공개된 채로 두면, 새로 오는 방문자는 모두 경고 화면부터 보게 됩니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

진단