Error 1013 SNI 불일치 해결

Problem

Cloudflare가 Error 1013: HTTP hostname and TLS SNI hostname mismatch를 반환합니다. Cloudflare 엣지로의 연결은 됐고 — TLS는 완료됐고 — 그런데 그 연결 안에서 요청이 자기모순입니다: 클라이언트가 TLS 핸드셰이크에서 SNI로 알린 호스트명이 HTTP Host 헤더에 넣은 호스트명과 다릅니다. Cloudflare는 둘 다 이용해 “어느 사이트를 요청하는지” 판단하는데, 둘이 서로 모순되면 추측하기를 거부합니다.

Symptoms

• Cloudflare 브랜드 오류 페이지에 Error 1013이 보입니다.
• 정상 브라우저에서는 사이트가 잘 뜨는데, 스크립트·커스텀 클라이언트·수동 옵션을 준 curl에서는 1013이 납니다.
• 특정 네트워크에서만 나옵니다 — 한 사무실, 한 VPN, 보안 소프트웨어가 깔린 한 대 — 나머지는 다 정상입니다.
• 프록시, TLS 검사 장비, 또는 Host 헤더를 직접 설정하는 코드를 추가한 직후 시작됐습니다.

이 오류가 실제로 뜻하는 것

Cloudflare로 가는 모든 HTTPS 요청은 대상 호스트명을 두 번, 서로 다른 두 계층에서 실어 나릅니다. 먼저 TLS 핸드셰이크 때 클라이언트가 SNI(Server Name Indication)를 보냅니다 — “나는 example.com으로 TLS를 하고 싶다”고 알리는 암호화 안 된 필드라, 엣지가 어느 인증서를 제시할지 압니다. 그다음 이제 암호화된 HTTP 요청 안에서 Host 헤더를 보냅니다 — “example.com의 페이지를 요청한다”. 정상 요청에서는 둘이 동일합니다. 같은 사이트를 가리키니까요.

Error 1013은 둘이 동일하지 않았다는 뜻입니다. SNI는 한 호스트명을, Host 헤더는 다른 호스트명을 말했습니다. Cloudflare는 이를 깨졌거나 변조된 요청으로 보고 멈춥니다. 둘 사이의 불일치는 잘못 설정된 클라이언트이거나, 중간의 무언가가 연결을 재작성했다는 신호이기 때문입니다. 이건 인증서 문제가 아니고 오리진 문제도 아닙니다 — 오리진엔 아예 연락도 안 갔습니다. 요청 자체 안의 모순이고, 그 모순은 서버가 아니라 Cloudflare의 클라이언트 쪽에서 만들어집니다.

Top 3 Causes

1. SNI와 Host를 다른 값으로 설정하는 커스텀 클라이언트·스크립트. TLS는 IP나 어떤 호스트명으로 연결하면서 Host 헤더는 진짜 도메인으로 덮어씁니다 — curl --resolve, 하드코딩된 IP + 수동 Host:, TLS 서버명과 Host를 독립적으로 설정하는 HTTP 라이브러리. TLS 계층은 한 이름을, HTTP 계층은 다른 이름을 알립니다. 브라우저는 절대 이러지 않아서 “크롬에서는 되는데 내 코드에서는 안 되는” 것입니다.
2. 사용자와 Cloudflare 사이의 TLS 검사 미들박스. 회사 프록시, SSL 검사를 하는 보안 장비, 백신 “HTTPS 검사”가 TLS를 재종단하고 바깥쪽 연결을 다시 만듭니다. 자기 SNI를 보내면서 원래 Host 헤더를 전달하면(또는 반대), Cloudflare가 불일치를 봅니다. 징후: 내 사이트가 아니라 특정 네트워크·제품과 연동됩니다.
3. 옛 연동·고정 설정에서 온 낡거나 틀린 SNI. CDN 앞단에 또 CDN, API 게이트웨이, SNI 값이 하드코딩된 클라이언트가 TLS는 한 이름으로 하고 요청은 다른 이름을 대상으로 합니다. 도메인 개명이나 마이그레이션에서 한 계층만 갱신하고 다른 쪽은 안 했을 때 흔합니다.

Diagnose with DechoNet

• SSL Check는 TLS 핸드셰이크와 Cloudflare가 당신 호스트명에 제시하는 인증서를 점검합니다. 엣지가 의도한 이름에 맞는 인증서를 서빙하는지 확인할 수 있어 — 문제가 인증서 커버리지 공백이 아니라 클라이언트/Host 불일치임을 증명하는 기준선입니다.
• HTTP Check는 밖에서 정상적으로 SNI와 Host를 일치시켜 사이트를 가져옵니다. DechoNet 점검은 성공하는데 1013이 당신의 클라이언트·네트워크에서만 난다면, 결함이 도메인이나 Cloudflare 설정이 아니라 그 클라이언트나 경로상의 미들박스에 있다고 좁혀진 것입니다.

Resolution Checklist

• 깨끗한 네트워크의 일반 브라우저에서 재현하세요. 거기서 뜨면 결함은 Cloudflare 설정이 아니라 클라이언트·미들박스 쪽입니다.
• 커스텀 클라이언트·스크립트에서 TLS 서버명(SNI)과 Host 헤더가 같은 호스트명을 담게 하세요. SNI와 안 맞는 하드코딩 IP, 흘러든 --resolve, 수동 Host: 덮어쓰기를 제거하세요.
• 한 네트워크에서만 난다면 그 사용자들과 인터넷 사이의 프록시, SSL 검사 장비, 백신 HTTPS 검사를 확인하고 — 그 미들박스에서 고치거나 도메인을 예외 처리하세요.
• Cloudflare 앞단의 CDN·게이트웨이 체인이라면, 그 계층이 상류로 보내는 SNI가 전달하는 Host와 맞는지 확인하고 낡은 쪽을 갱신하세요.
• SSL Check로 Cloudflare가 의도한 호스트명에 올바른 인증서를 제시하는지 확인한 뒤, SNI와 Host를 일치시켜 요청을 재시험하세요.

When to Escalate

• 클라이언트에서 SNI와 Host가 확실히 일치하는데도 1013이 계속 나면, 실제 TLS ClientHello(SNI)와 HTTP Host 헤더를 와이어에서 캡처하세요 — 미들박스가 둘 중 하나를 보이지 않게 재작성하고 있을 수 있고, 패킷 캡처가 어느 쪽인지 증명합니다.
• 불일치가 당신이 통제 못 하는 관리형 프록시·회사 네트워크 안에서 발생한다면, 그 장비 소유자에게 에스컬레이션하세요. SNI/Host 재작성은 거기의 설정이고, 당신의 도메인이나 Cloudflare 존을 아무리 바꿔도 하류에서 생긴 모순은 고칠 수 없습니다.