SSL 인증서기술 정보 확인 2026-10-24수정 2026-10-24

HTTPS 연결 오류 해결, 프로토콜·혼합 콘텐츠 점검

인증서가 정상인데도 HTTPS 접속이 안 되는 경우가 있습니다. 이때 화면에는 사이트에 연결할 수 없음, SSL 프로토콜 오류, 리디렉션 횟수 초과 같은 메시지가 뜨고, 인증서 자체의 날짜나 도메인 문제와는 원인이 다릅니다. 인증서 오류는 SSL 인증서 오류 해결 글에서 따로 다루고, 이 글은 연결 자체가 막히거나 경고가 반복되는 문제를 정리합니다.

원인은 크게 네 가지입니다. 443 포트에 닿지 못하는 문제, 서버의 SSL 설정 문제, 페이지 안의 혼합 콘텐츠, 리디렉션 설정 충돌입니다. 아래 순서대로 보면 대부분 범위를 좁힐 수 있습니다.

오류 유형별 빠른 판단

연결 거부, 포트와 서비스 확인

HTTPS는 기본적으로 443 포트를 씁니다. 서버 밖에서 이 포트에 닿는지 먼저 확인합니다.

curl -vI https://example.com/

연결 자체가 거부되면 서버 안에서 웹 서버가 443을 듣고 있는지 확인합니다.

sudo ss -tlnp | grep ':443'

아무것도 나오지 않으면 웹 서버에 SSL 설정이 없거나 서비스가 꺼진 것입니다. 나오는데도 밖에서 접속이 안 된다면 서버 방화벽, 클라우드의 보안그룹(네트워크 접근 규칙), 호스팅 업체의 포트 차단을 의심합니다. 방화벽 설정은 서버 방화벽 설정을 참고하세요.

ERR_SSL_PROTOCOL_ERROR 점검

이 오류는 브라우저와 서버가 TLS 연결을 맺는 도중 합의에 실패했을 때 흔히 나옵니다. 자주 만나는 원인은 다음과 같습니다.

• nginx에서 listen 443;만 쓰고 ssl 옵션을 빠뜨려 443 포트가 일반 HTTP로 응답한다.
• Apache에서 가상 호스트에 SSLEngine on이 없다.
• 서버가 오래된 프로토콜만 허용하거나, 반대로 아주 오래된 클라이언트가 최신 프로토콜을 지원하지 않는다.
• 앞단에 CDN이나 프록시가 있는데, 뒤쪽 서버와의 SSL 사용 방식이 서로 맞지 않는다.

nginx 문서 기준으로 ssl_protocols의 기본값은 TLSv1.2 TLSv1.3이고, Apache의 SSLProtocol 기본값은 all -SSLv3입니다(확인 시점 2026년 10월 24일). 이 기본값을 건드리지 않았다면 프로토콜 문제보다 ssl 키워드나 SSLEngine 누락일 가능성이 높습니다.

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

설정을 고쳤다면 반영 전에 문법 검사(nginx -t 또는 apachectl configtest)를 먼저 하고 reload합니다.

혼합 콘텐츠 해결

혼합 콘텐츠는 https로 열린 페이지가 이미지, 스크립트, 스타일시트를 http 주소로 부르는 상태입니다. MDN 문서에 따르면 스크립트·스타일시트·iframe·글꼴·fetch 요청 같은 차단 대상은 브라우저가 막고, 이미지·오디오·비디오 같은 항목은 자동으로 https로 올립니다. 단, 주소가 IP로 되어 있으면 자동 상향도 되지 않고 차단됩니다.

해결 순서는 다음과 같습니다.

1. 브라우저 개발자 도구의 콘솔에서 Mixed Content 경고를 확인한다.
2. 코드, 테마, 데이터베이스에 남은 http:// 주소를 https://나 상대 경로로 바꾼다. 워드프레스는 주소 설정과 본문에 박힌 이미지 주소를 함께 봐야 합니다.
3. 제3자 리소스는 https 버전이 실제로 존재하는지 확인한다.
4. 남은 요청을 임시로 올리고 싶으면 CSP 헤더를 사용한다.

Header always set Content-Security-Policy "upgrade-insecure-requests"

MDN은 이 CSP 지시어가 차단 대상 요청까지 https로 올려 준다고 설명합니다. 다만 CSP 전체 설정은 영향 범위가 넓으니 Content-Security-Policy 적용 가이드를 보고 단계적으로 적용하세요.

리디렉션 반복 해결

HTTP를 HTTPS로 보내는 규칙이 여러 곳에 중복되면 브라우저가 “리디렉션이 너무 많음” 또는 “redirect loop” 오류를 냅니다. MDN은 서버가 반복을 감지하면 500 오류를 낼 수 있고, 여러 서버에 걸쳐 있으면 브라우저가 감지한다고 설명합니다.

흔한 충돌은 다음과 같습니다.

• 웹 서버 설정, .htaccess, 워드프레스 플러그인이 각각 https 리디렉션을 건다.
• CDN은 사용자와 https로 통신하고 원본 서버와는 http로 통신하는데, 원본 서버가 http 요청을 다시 https로 보낸다.
• 워드프레스의 사이트 주소는 http인데 서버는 https로 보낸다.

해결의 원칙은 리디렉션을 한 곳에 모으는 것입니다. 웹 서버 설정에서 한 번만 처리하는 방식이 가장 단순합니다. 영구 이동이므로 301이나 308을 쓰면 되며, MDN에 따르면 영구 리디렉션은 검색 엔진과 크롤러가 원래 주소를 새 주소로 갱신하도록 알려 줍니다.

HSTS를 켠 사이트에서는 문제가 더 고착됩니다. MDN은 HSTS가 브라우저에 기억되고 해제도 느리다고 설명하므로, 작동 확인 전에 긴 max-age로 켜지 말고 HSTS 설정 방법의 단계적 적용을 따르세요.

마무리 점검

• 443 포트가 열려 있고 웹 서버가 ssl 설정으로 듣는지 확인한다.
• 개발자 도구 콘솔에 혼합 콘텐츠 경고가 없는지 확인한다.
• curl -I http://example.com/으로 리디렉션이 한 번만 일어나는지 확인한다.
• 앞단 CDN이 있다면 원본 서버와의 연결 방식이 설정과 맞는지 확인한다.

외부 공개 검사로는 서버 내부의 설정 파일이나 방화벽 규칙을 확인할 수 없습니다. 위 점검 중 서버 안에서 해야 하는 항목은 직접 확인해야 합니다.