520 Web Server Is Returning an Unknown Error (Cloudflare) 해결

Problem

Cloudflare가 Error 520: Web server is returning an unknown error를 반환합니다. 521(거부)이나 522(타임아웃)와 달리, 오리진 연결은 성공했고 오리진이 무언가를 돌려보냈습니다. 문제는 그 무언가가 유효한 HTTP가 아니었다는 점입니다 — status line 없음, 헤더 누락, 중간 reset, 또는 봉투 없는 빈 body. 520은 오리진이 응답했지만 그 응답이 다른 어떤 5xx 범주에도 맞지 않을 때 Cloudflare가 떨어지는 폴백 오류입니다.

Symptoms

• Cloudflare 브랜드 오류 페이지에 Error 520이 표시됩니다.
• 대개 간헐적입니다 — 대부분의 요청은 성공하고 일부만 520 — 매 요청 실패하는 하드 다운이 아닙니다.
• Cloudflare를 잠시 끄고(DNS 레코드를 DNS-only / grey cloud) 오리진에 직접 접속하면 보통 정상입니다. 오리진은 살아 있고 Cloudflare가 그 응답을 거부하는 것이기 때문입니다.
• 오리진 로그에는 해당 요청이 200으로 처리된 것으로 남을 수 있는데, 정작 방문자는 520을 받습니다 — 앱이 넘긴 뒤 응답이 망가졌다는 신호입니다.

Top 3 Causes

1. 오리진이 keep-alive 연결을 너무 일찍 닫음 - Cloudflare는 오리진과의 TCP 연결을 풀링해 재사용합니다. 오리진의 keepalive 타임아웃이 엣지보다 짧으면, Cloudflare가 오리진이 이미 닫은 연결로 요청을 보내 응답 대신 reset을 받습니다. 간헐적 520의 가장 흔한 원인입니다 — 재사용된 연결이 마침 방금 만료됐을 때만 실패하기 때문입니다.
2. 응답이 깨졌거나 지나치게 큼 - status line 없는 빈 body, 헤더 누락, 또는 너무 큰 응답 헤더(과도한 Set-Cookie 증식이 흔한 원인 — Cloudflare는 헤더 크기에 상한이 있습니다). 크래시하거나 메모리 부족(OOM)에 걸린 워커가 프로세스가 죽기 직전 반쯤 쓰다 만 쓰레기 응답을 flush할 수도 있습니다.
3. Cloudflare와 앱 사이의 프록시/핸들러가 봉투를 깨뜨림 - 리버스 프록시, PHP-FPM, 또는 응답 도중 연결을 reset하거나 비-HTTP 페이로드를 반환하는 애플리케이션 서버가 520을 만듭니다. 오리진의 HTTP/2 설정 오류가 반복적 유발 요인이며, 깔끔한 오류 페이지 대신 연결을 끊어버리는 WAF·보안 플러그인도 마찬가지입니다.

Diagnose with DechoNet

• HTTP Check를 도메인에 실행하면 Cloudflare가 반환하는 상태와 실제 응답 헤더를 보여줘, 520이 일관적인지 간헐적인지 확인할 수 있습니다.
• SSL Check로 Cloudflare가 Full/Full(Strict) 모드일 때 오리진 TLS가 깔끔히 종료되는지 확인합니다 — 핸드셰이크가 반쯤 완료됐다 reset되면 TLS 오류가 아니라 520으로 나타날 수 있습니다.

Resolution Checklist

• Cloudflare를 우회해 오리진에 직접 재현합니다: curl -v --resolve YOUR_DOMAIN:443:ORIGIN_IP https://YOUR_DOMAIN/. 여기서 응답이 깔끔하면 오리진은 정상이고 Cloudflare가 보는 응답 봉투가 원인 — 계속 진행합니다. 여기서 깨지면 오리진 앱으로 원인이 좁혀집니다.
• 오리진의 keep-alive 타임아웃을 Cloudflare보다 높입니다. Nginx는 keepalive_timeout을 최소 75초(엣지보다 높게)로 설정하고 keepalive_requests가 재사용을 막지 않는지 확인하세요. Apache는 KeepAliveTimeout을 점검합니다. 이것만으로 대부분의 간헐적 520이 해결됩니다.
• 응답 헤더를 줄입니다. Set-Cookie 증식과 요청마다 헤더를 붙이는 앱을 감사하세요 — 누적 헤더 초과는 전형적 520 유발 요인입니다. 쿠키를 정리하고 디버그 헤더를 제거합니다.
• 520 발생 시점 전후로 오리진의 OOM kill과 워커 크래시를 확인합니다(dmesg | grep -i oom, 그리고 앱 서버 오류 로그). 응답 도중 죽는 워커는 Cloudflare가 520으로 보고하는 바로 그 쓰레기 응답을 내보냅니다.
• 오리진에서 HTTP/2를 쓴다면 Cloudflare–오리진 구간을 잠시 HTTP/1.1로 강제해 HTTP/2 프레이밍 버그를 배제한 뒤 재테스트합니다.
• 변경마다 HTTP Check를 다시 돌리고, 한 번의 on/off 수정이 아니라 520 비율이 떨어지는지 지켜보세요 — 간헐적 원인은 하나씩 제거할수록 점진적으로 사라집니다.

When to Escalate

• 오리진에 직접 접속하면 깔끔한 응답이 오는데 Cloudflare는 여전히 520을 반환한다면, 헤더의 cf-ray가 포함된 요청을 캡처해 Cloudflare 티켓을 여세요 — 그 cf-ray로 엣지가 오리진에서 무엇을 받았는지 추적할 수 있습니다.
• 부하가 걸릴 때만 520이 치솟는다면 원인은 거의 항상 오리진 용량입니다: 워커 크래시, 연결 한도, 메모리 고갈. 오리진을 확장하거나 누수를 고치세요 — 바쁠 때 죽는 서버를 Cloudflare 설정으로 덮을 수는 없습니다.