Japan Server Error Fix Lab

홈 / Cloudflare / Cloudflare

Cloudflare SSL 525 handshake failed

Cloudflare와 원본 서버 사이의 TLS 연결이 실패할 때 발생하는 대표적인 SSL 오류입니다.

high5258 분 읽기
첫 확인 명령
curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
먼저 볼 증거

Cloudflare 525 대응은 먼저 발생 시각, 요청 URL, 사용자, 최근 변경, 첫 로그 라인을 확인합니다.

검색 쿼리
Cloudflare 525Cloudflare error 525Cloudflare SSL 525 handshake failed

이런 상황에서 발생합니다

Cloudflare 프록시를 켠 뒤 사이트에는 525가 보이지만, 원본 서버 자체는 살아 있는 상황에서 자주 발생합니다. DNS가 틀렸다기보다 Cloudflare가 원본 서버와 TLS를 맺는 단계에서 인증서, SNI, TLS 버전, 가상호스트 설정이 맞지 않는 경우가 많습니다.

증상 체크

  • 브라우저에 Error 525가 표시됩니다.
  • Cloudflare 이벤트 로그에 SSL handshake failed가 남습니다.
  • 원본 IP로 직접 접근하면 인증서 경고 또는 다른 TLS 오류가 나옵니다.
  • DNS only로 바꾸면 페이지가 열리거나 오류 코드가 달라질 수 있습니다.
  • 같은 서버의 다른 도메인은 정상인데 특정 호스트명만 실패할 수 있습니다.

가능성이 높은 원인

  • 원본 인증서가 만료되었거나 호스트명과 일치하지 않습니다.
  • Cloudflare SSL 모드가 Full strict인데 중간 인증서 체인이 빠져 있습니다.
  • Nginx 또는 Apache가 SNI에 맞는 인증서를 반환하지 않습니다.
  • 원본 서버가 TLS 1.2 이상 또는 Cloudflare가 허용하는 cipher를 지원하지 않습니다.
  • 가상호스트의 server_name, ServerName, ssl_certificate 경로가 실제 도메인과 맞지 않습니다.
  • ALB나 리버스 프록시 뒤에서 다시 TLS를 종료하면서 인증서가 엇갈립니다.

1분 먼저 확인

  1. Cloudflare SSL 모드를 Full strict에서 Full로 잠깐 낮춰 증상 변화를 확인합니다.
  2. 원본 IP에 SNI를 포함해 curl과 openssl을 실행합니다.
  3. Nginx 또는 Apache의 가상호스트가 어떤 인증서를 반환하는지 봅니다.
  4. 원본 서버의 TLS 버전과 cipher 설정을 확인합니다.

먼저 볼 증거

Cloudflare 525 대응은 먼저 발생 시각, 요청 URL, 사용자, 최근 변경, 첫 로그 라인을 확인합니다.

출력 예시

정상 출력

curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
# no matching 525 entries during the checked window

실패 출력

curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
# 525 appears with timestamp, request path, user, and upstream layer

출력별 판단

  • 로그에 같은 시각의 에러가 없습니다.
    브라우저, CDN, 프록시, DNS 캐시처럼 서버 밖 레이어부터 분리합니다.
  • 로그에 같은 시각과 같은 경로의 에러가 있습니다.
    그 로그가 나온 서비스, 업스트림, 권한, 데이터 상태를 우선 확인합니다.
  • 정상 사용자와 실패 사용자의 출력이 다릅니다.
    권한, 세션, 네트워크 위치, 캐시 차이를 비교합니다.

하지 말아야 할 조치

  • 빈 화면이나 코드만 보고 여러 설정을 동시에 바꾸지 마세요.
  • 원인 레이어를 확인하기 전에 전체 캐시 삭제, 전체 권한 부여, 보안 해제를 먼저 하지 마세요.

검증 상태

운영자용 초안: 기본 출력 예시와 분기 조치를 포함했습니다. 실제 incident 출력과 공식 문서 링크는 업데이트 큐에서 계속 보강합니다.

먼저 실행할 명령어

curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
openssl s_client -connect ORIGIN_IP:443 -servername example.com -showcerts
nginx -T | grep -n "server_name\|ssl_certificate"
apachectl -S
nmap --script ssl-enum-ciphers -p 443 example.com

해결 순서

  1. 원본 서버 인증서의 만료일과 호스트명 일치 여부를 확인합니다.
  2. Cloudflare SSL 모드가 Flexible, Full, Full strict 중 무엇인지 확인합니다.
  3. SNI 포함 openssl 테스트로 실제 반환 인증서를 봅니다.
  4. Nginx/Apache 가상호스트 설정을 도메인 기준으로 다시 봅니다.
  5. 수정 후 Cloudflare 캐시를 비우고 같은 명령어로 재검증합니다.

원인별 조치

  • 원본 인증서를 갱신하고 full chain 파일을 사용합니다.
  • Nginx의 server_name과 ssl_certificate, Apache의 ServerName과 SSLCertificateFile을 실제 도메인 기준으로 맞춥니다.
  • Cloudflare Origin Certificate를 쓰는 경우 프록시를 끈 직접 접속에서는 신뢰되지 않을 수 있음을 분리해서 판단합니다.
  • TLS 1.2 이상을 허용하고 오래된 cipher 설정을 제거합니다.
  • ALB 뒤에 있다면 ALB listener 인증서와 백엔드 인증서 정책을 같이 봅니다.

검증 메타

  • operator-draft
  • official-reference-linked
  • 2026-07-23

업데이트 큐

  • 갱신 주기
    weekly-source-review
  • 다음 보강
    Add one official-source check and one real output example for Cloudflare 525.

환경별 확인 포인트

  • Xserver, ConoHa, CPI 같은 일본 호스팅은 관리 화면에서 SSL 반영 완료 상태를 먼저 확인합니다.
  • AWS ALB 뒤라면 listener 인증서, target group health, 백엔드 포트를 함께 봅니다.
  • Cloudflare proxy를 끄고 DNS only로 바꿨을 때 결과를 별도로 기록합니다.
  • Let’s Encrypt 갱신 직후라면 웹서버 reload가 되었는지 확인합니다.
  • 서버에 여러 도메인이 묶여 있으면 SNI 기준으로 인증서가 바뀌는지 반드시 봅니다.

다시 발생하지 않게 하기

  • 인증서 만료 30일 전 알림을 설정합니다.
  • 배포 후 curl과 openssl 확인을 체크리스트에 넣습니다.
  • Cloudflare SSL 모드와 원본 인증서 정책을 문서화합니다.
  • Nginx/Apache 가상호스트 변경 시 테스트 도메인에서 먼저 확인합니다.
  • DNS, 프록시, 인증서 변경은 같은 날 한꺼번에 하지 않도록 나눕니다.