Azure Front Door 일반적인 문제 해결
이 문서에서는 Azure Front Door 구성에서 발생할 수 있는 몇 가지 일반적인 라우팅 문제를 해결하는 방법을 설명합니다.
기타 디버깅 HTTP 헤더
추가 디버깅 HTTP 응답 헤더를 반환하도록 Azure Front Door를 요청할 수 있습니다. 자세한 내용은 선택적 응답 헤더를 참조하세요.
몇 초 후에 Azure Front Door에서 503 또는 504 응답
증상
- Azure Front Door를 거치지 않고 백 엔드로 전송되는 일반 요청이 성공합니다. Azure Front Door를 통과하면 503 또는 504 오류 응답이 발생합니다.
- Azure Front Door의 실패 알림은 일반적으로 약 30초 후에 표시됩니다.
- 일시적인 503 오류는 “ErrorInfo: OriginInvalidResponse”와 함께 표시됩니다.
원인
이 문제의 원인은 다음 세 가지 중 하나일 수 있습니다.
- 원본이 Azure Front Door에서 요청을 받기 위해 구성된 시간 제한보다 오래 걸리고 있습니다. 기본 제한 시간은 30초입니다.
- Azure Front Door에서 요청에 대한 응답을 보내는 데 걸리는 시간이 시간 제한 값보다 오래 걸립니다.
- 클라이언트가 Accept-Encoding 헤더를 사용하여 바이트 범위 요청을 보냈습니다. 즉, 압축이 사용하도록 설정되었습니다.
문제 해결 단계
Azure Front Door를 거치지 않고 원본에 직접 요청을 보냅니다. 원본이 일반적으로 응답하는 데 걸리는 시간을 확인합니다.
Azure Front Door를 통해 요청을 보내고 503 응답을 가져오는지 확인합니다. 그러지 않은 경우에는 시간 제한 문제가 아닐 수 있습니다. 문제를 추가로 해결하려면 지원 요청을 작성합니다.
Azure Front Door를 통과하는 요청으로 인해 503 오류 응답 코드가 발생하는 경우 Azure Front Door에 대한 원본 응답 시간 제한을 구성합니다. 기본 제한 시간을 최대 4분(240초)까지 늘릴 수 있습니다. 설정을 구성하려면 Front Door 프로필의 개요 페이지로 이동합니다. 원본 응답 시간 제한을 선택하고, 16~240초의 값을 입력합니다.
참고 항목
원본 응답 시간 제한을 구성하는 기능은 Azure Front Door 표준/프리미엄에서만 사용할 수 있습니다.
시간 제한을 늘려도 문제가 해결되지 않는 경우 Fiddler 또는 브라우저의 개발자 도구 같은 도구를 사용해 클라이언트에서 Accept-Encoding 헤더로 바이트 범위 요청을 보내는지 확인합니다. 이 옵션을 사용하면 원본이 다른 콘텐츠 길이로 응답하게 됩니다.
클라이언트가 Accept-Encoding 헤더를 사용하여 바이트 범위 요청을 보내는 경우 두 가지 옵션이 있습니다. 첫 번째 옵션은 원본 또는 Azure Front Door에서 압축을 사용하지 않도록 설정하는 것입니다. 두 번째 옵션은 바이트 범위 요청에 대한 요청에서 Accept-Encoding을 제거하는 규칙 집합 규칙을 만드는 것입니다.
Azure Front Door에서 HTTPS에 한해 503 응답
증상
- 모든 503 응답은 Azure Front Door HTTPS 지원 엔드포인트에 대해서만 반환됩니다.
- Azure Front Door를 거치지 않고 백 엔드로 전송되는 일반 요청이 성공합니다. Azure Front Door를 통해 전송하면 503 오류 응답이 발생합니다.
- 일시적인 503 오류는 “ErrorInfo: OriginInvalidResponse”와 함께 표시됩니다.
원인
이 문제의 원인은 다음의 세 가지 중 하나일 수 있습니다.
- 백 엔드 풀은 IP 주소입니다.
- 백 엔드 서버는 Azure Front Door 백 엔드 풀의 FQDN(정규화된 도메인 이름)과 일치하지 않는 인증서를 반환합니다.
- 백 엔드 풀은 Azure Web Apps 서버입니다.
문제 해결 단계
백 엔드 풀은 IP 주소입니다.
EnforceCertificateNameCheck을(를) 사용하지 않도록 설정해야 합니다.Azure Front Door에는
EnforceCertificateNameCheck라는 스위치가 있습니다. 기본적으로 이 설정은 활성화되어 있습니다. 사용하도록 설정되면 Azure Front Door는 백 엔드 풀 호스트 이름 FQDN이 백 엔드 서버 인증서의 CN(인증서 이름) 또는 SAN(주체 대체 이름) 확장의 항목 중 하나와 일치하는지 확인합니다.Azure Portal에서
EnforceCertificateNameCheck를 사용하지 않도록 설정하는 방법:포털에서 토글 단추를 사용하여 Azure Front Door(클래식) 디자인 창에서 이 설정을 켜거나 끕니다.
Azure Front Door 표준 및 프리미엄 계층의 경우 원본 그룹에 원본을 추가하거나 경로를 구성할 때 원본 설정에서 이 설정을 찾을 수 있습니다.
백 엔드 서버는 Azure Front Door 백 엔드 풀의 FQDN과 일치하지 않는 인증서를 반환합니다. 이 문제를 해결하려면 다음 두 가지 옵션이 있습니다.
- 반환된 인증서는 FQDN과 일치해야 합니다.
EnforceCertificateNameCheck을(를) 사용하지 않도록 설정해야 합니다.
백 엔드 풀은 Azure Web Apps 서버입니다.
- Azure 웹앱이 SNI(서버 이름 표시) 기반이 아닌 IP 기반 SSL로 구성되어 있는지 확인합니다. 웹앱이 IP 기반으로 구성된 경우 SNI로 변경해야 합니다.
- 인증서 오류로 인해 백 엔드가 비정상이면 503 오류 메시지가 반환됩니다. 포트 80 및 443에서 백 엔드의 상태를 확인할 수 있습니다. 443만 비정상이면 SSL에 문제가 있을 수 있습니다. 백 엔드가 FQDN을 사용하도록 구성되었으므로 SNI를 보내고 있습니다.
OPENSSL을 사용하여 반환되는 인증서를 확인합니다. 이 검사를 수행하려면
-servername를 사용하여 백 엔드에 연결합니다. 백 엔드 풀의 FQDN과 일치해야 하는 SNI를 반환해야 합니다.openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com
사용자 지정 도메인에 전송된 요청이 400 상태 코드를 반환합니다.
증상
- Azure Front Door 인스턴스를 만들었습니다. 도메인 또는 프런트 엔드 호스트에 대한 요청은 HTTP 400 상태 코드를 반환합니다.
- 구성한 프런트 엔드 호스트에 대한 사용자 지정 도메인에 대한 DNS(도메인 이름 서버) 매핑을 만들었습니다. 사용자 지정 도메인 호스트 이름에 요청을 보내면 HTTP 400 상태 코드가 반환됩니다. 구성된 백 엔드로 라우팅하는 것은 아닙니다.
원인
프런트 엔드 호스트로 추가된 사용자 지정 도메인에 대한 라우팅 규칙을 구성하지 않은 경우 이 문제가 발생합니다. 해당 프런트 엔드 호스트에 대해 라우팅 규칙을 명시적으로 추가해야 합니다. Azure Front Door 하위 도메인(*.azurefd.net) 아래의 프런트 엔드 호스트에 대해 라우팅 규칙이 이미 구성된 경우에도 규칙을 만들어야 합니다.
문제 해결 단계
사용자 지정 도메인에 대한 라우팅 규칙을 추가하여 선택한 원본 그룹으로 트래픽을 보냅니다.
Azure Front Door가 HTTP를 HTTPS로 리디렉션하지 않습니다.
증상
Azure Front Door에는 HTTP를 HTTPS로 리디렉션하는 라우팅 규칙이 있지만 도메인에 액세스하는 것은 HTTP를 프로토콜로 계속 유지합니다.
원인
이 동작은 Azure Front Door에 대해 라우팅 규칙을 올바르게 구성하지 않은 경우에 발생할 수 있습니다. 현재 구성이 구체적이지 않아 충돌하는 규칙이 있을 수 있습니다.
문제 해결 단계
프런트 엔드 호스트 이름에 대한 요청은 411 상태 코드를 반환합니다.
증상
Azure Front Door 표준/프리미엄 인스턴스를 만들고 다음을 구성했습니다.
- 프런트 엔드 호스트.
- 원본이 하나 이상 포함된 원본 그룹.
- 프런트 엔드 호스트를 원본 그룹에 연결하는 라우팅 규칙.
HTTP 411 상태 코드가 반환된 것으로 보아 구성된 프런트 엔드 호스트로 요청을 보낼 때 콘텐츠가 보이지 않는 것 같습니다.
요청에 대한 응답에는 설명문을 포함하는 HTML 오류 페이지가 응답 본문에 포함될 수도 있습니다. 예를 들어, “HTTP 오류 411. 요청은 청크 분할되거나 콘텐츠 길이를 포함해야 합니다.”입니다.
원인
이 증상에는 몇 가지 잠재적 원인이 있습니다. 전반적인 이유는 HTTP 요청이 완전히 RFC 규격이 아니라는 것입니다.
규정 비준수의 예로는 Content-Length 또는 Transfer-Encoding 헤더 없이 전송된 POST 요청이 있습니다. 예를 들어, curl -X POST https://example-front-door.domain.com을 사용합니다. 이 요청은 RFC 7230에 명시된 요구 사항을 충족하지 않습니다. Azure Front Door는 HTTP 411 응답을 사용하여 차단합니다. 이러한 요청은 기록되지 않습니다.
이 동작은 Azure Front Door의 WAF(웹 애플리케이션 방화벽) 기능과는 별개입니다. 현재 이 동작을 사용하지 않도록 설정하는 방법은 없습니다. WAF 기능이 사용되지 않는 경우에도 모든 HTTP 요청은 요구 사항을 충족해야 합니다.
문제 해결 단계
- 요청이 필요한 RFC에 설정된 요구 사항을 준수하는지 확인합니다.
- 요청에 대한 응답으로 반환되는 HTML 메시지 본문을 기록해 둡다. 메시지 본문은 요청이 정확히 어떻게 규격을 준수하지 않았는지 설명하는 경우가 많습니다.
내 원본은 IP 주소로 구성됩니다.
증상
원본은 IP 주소로 구성됩니다. 원본은 정상이지만 Azure Front Door의 요청을 거부합니다.
원인
Azure Front Door는 SSL 핸드셰이크 중에 원본 호스트 이름을 SNI 헤더로 사용합니다. 원본이 IP 주소로 구성되므로 오류가 다음 이유 중 하나일 수 있습니다.
- 인증서 이름 검사를 사용하지 않도록 설정하면 문제의 원인이 원본 인증서 논리에 있는 것일 수 있습니다. 이 논리는 인증서와 일치하는 유효한 호스트 헤더가 없는 요청을 거부할 수 있습니다.
문제 해결 단계
IP 주소에서 원본 인증서와 일치하는 유효한 인증서가 발급되는 FQDN으로 원본을 변경합니다.
Azure Front Door의 429개 응답
증상
- 응답 429: 요청이 너무 많은 오류를 표시하는 요청의 백분율입니다.
원인
- Azure Front Door에는 기본 플랫폼 속도 제한이 있습니다. 트래픽이 제한을 초과하는 경우 AFD는 트래픽을 제한하는 속도를 시작하고 429개의 응답을 반환합니다.
문제 해결 단계
- 합법적인 트래픽에 대해 429s가 표시되기 시작하고 할당량이 더 많이 필요한 경우 Azure 지원 요청을 만듭니다.
다음 단계
- Front Door를 만드는 방법을 알아봅니다.
- Front Door 표준/프리미엄을 만드는 방법을 알아봅니다.