다음을 통해 공유

Application Gateway의 HTTP 응답 코드

  • 아티클

이 문서에는 Azure Application Gateway가 특정 HTTP 응답 코드를 반환하는 이유가 나와 있습니다. 일반적인 원인과 문제 해결 단계가 제공되어 오류 HTTP 응답 코드의 근본 원인을 파악하는 데 도움이 됩니다. HTTP 응답 코드는 백 엔드 대상에 대한 연결이 시작되었는지 여부에 관계없이 클라이언트 요청에 반환될 수 있습니다.

3XX 응답 코드(리디렉션)

클라이언트 요청이 리디렉션이 구성된 애플리케이션 게이트웨이 규칙과 일치하면 300-399 응답이 표시됩니다. 리디렉션은 규칙 그대로 또는 경로 맵 규칙을 통해 구성할 수 있습니다. 리디렉션에 대한 자세한 내용은 Application Gateway 리디렉션 개요를 참조하세요.

301 영구 리디렉션

리디렉션 규칙이 Permanent 값으로 지정되면 HTTP 301 응답이 표시됩니다.

302 있음

리디렉션 규칙이 Found 값으로 지정되면 HTTP 302 응답이 표시됩니다.

303 기타 참조

리디렉션 규칙이 See Other 값으로 지정되면 HTTP 302 응답이 표시됩니다.

307 임시 리디렉션

리디렉션 규칙이 Temporary 값으로 지정되면 HTTP 307 응답이 표시됩니다.

4XX 응답 코드(클라이언트 오류)

400-499 응답 코드는 클라이언트에서 시작된 문제를 나타냅니다. 이러한 문제는 클라이언트 시작 요청부터 일치하지 않는 호스트 이름, 요청 시간 제한, 인증되지 않은 요청, 악의적인 요청 등에 이르기까지 다양할 수 있습니다.

Application Gateway는 4xx/5xx 상태 코드의 배포를 캡처하는 메트릭을 수집하며, 응답 코드를 사용하여 URI 클라이언트 IP 주소와 같은 정보를 캡처하는 로깅 메커니즘을 갖추고 있습니다. 메트릭 및 로깅을 통해 추가 문제를 해결할 수 있습니다. 클라이언트는 또한 클라이언트 디바이스와 Application Gateway 간에 다른 프록시로부터 4xx 응답을 수신할 수 있습니다. 예로 CDN과 기타 인증 공급자를 들 수 있습니다. 자세한 내용은 다음 문서를 참조하세요.

Application Gateway V2 SKU에서 지원하는 메트릭진단 로그

400 - 잘못된 요청

HTTP 400 응답 코드는 다음과 같은 경우에 일반적으로 관찰됩니다.

  • 비 HTTP/HTTPS 트래픽은 HTTP 또는 HTTPS 수신기를 사용하여 애플리케이션 게이트웨이로 시작됩니다.
  • HTTP 트래픽은 리디렉션이 구성되지 않은 상태에서 HTTPS를 사용하여 수신기로 시작됩니다.
  • 상호 인증이 구성되고 제대로 협상할 수 없습니다.
  • 요청이 RFC를 준수하지 않습니다.

요청이 RFC를 준수하지 않는 몇 가지 일반적인 이유는 다음과 같습니다.

범주 예제
잘못된 요청 줄 호스트 콜론을 두 개 포함하는 호스트(example.com:8090:8080)
호스트 헤더 누락 요청에 호스트 헤더가 없음
형식이 잘못되었거나 불법적인 문자가 있음 예약된 문자는 &,!.입니다. 해결 방법은 백분율로 코딩하는 것입니다. 예: %&
잘못된 HTTP 버전 Get /content.css HTTP/0.3
헤더 필드 이름과 URI에 ASCII가 아닌 문자가 포함됨 GET /«úü¡»¿.doc HTTP/1.1
POST 요청에 콘텐츠 길이 헤더 누락 자체 설명
잘못된 HTTP 메서드 GET123 /index.html HTTP/1.1
중복 헤더 권한 부여:<base64로 인코딩된 콘텐츠>, 권한 부여: <base64로 인코딩된 콘텐츠>
잘못된 Content-Length 값 Content-Length: abc,Content-Length: -10

상호 인증이 구성된 경우 다음과 같은 여러 시나리오에서 HTTP 400 응답이 클라이언트에 반환될 수 있습니다.

  • 클라이언트 인증서는 표시되지 않지만 상호 인증을 사용할 수 있습니다.
  • DN 유효성 검사가 사용하도록 설정되고 클라이언트 인증서의 DN이 지정된 인증서 체인의 DN과 일치하지 않습니다.
  • 클라이언트 인증서 체인은 정의된 SSL 정책에 구성된 인증서 체인과 일치하지 않습니다.
  • 클라이언트 인증서가 만료되었습니다.
  • OCSP 클라이언트 해지 검사가 사용하도록 설정되고 인증서가 해지됩니다.
  • OCSP 클라이언트 해지 검사가 사용하도록 설정되었으나 연결할 수 없습니다.
  • OCSP 클라이언트 해지 검사가 사용하도록 설정되었으나 인증서에 OCSP 응답자가 제공되지 않습니다.

상호 인증 문제 해결에 대한 자세한 내용은 오류 코드 문제 해결을 참조하세요.

401 - 권한 없음

클라이언트가 리소스에 액세스할 권한이 없는 경우 HTTP 401 권한 없음 응답이 클라이언트에 반환됩니다. 401을 반환하는 데에는 몇 가지 이유가 있습니다. 잠재적 수정 사항이 포함된 몇 가지 이유는 다음과 같습니다.

  • 클라이언트에 액세스 권한이 있는 경우 오래된 브라우저 캐시가 있을 수 있습니다. 브라우저 캐시를 지우고 애플리케이션에 다시 액세스해 보세요.

백 엔드 풀이 NTLM 인증으로 구성된 경우 HTTP 401 권한 없음 응답을 AppGW 프로브 요청에 반환할 수 있습니다. 이 시나리오에서는 백 엔드가 정상으로 표시됩니다. 이 문제를 해결하는 몇 가지 방법은 다음과 같습니다.

  • 백 엔드 풀에서 익명 액세스를 허용합니다.
  • NTLM이 필요하지 않은 다른 "가짜" 사이트로 요청을 보내도록 프로브를 구성합니다.
  • 애플리케이션 게이트웨이 뒤의 실제 사이트가 활성 상태인지 여부는 알려주지 않으므로 권장되지 않습니다.
  • 401 응답을 프로브에 유효한 것으로 허용하도록 애플리케이션 게이트웨이를 구성합니다(프로브 일치 조건).

403 - 사용 권한 없음

고객이 WAF sku를 사용하고 WAF가 방지 모드로 구성된 경우 HTTP 403 사용할 수 없음이 표시됩니다. 사용되는 WAF 규칙 집합 또는 사용자 지정 거부 WAF 규칙이 인바운드 요청의 특성과 일치하는 경우 클라이언트에 403 사용 권한 없음 응답이 표시됩니다.

클라이언트가 403 응답을 수신하는 다른 이유는 다음과 같습니다.

  • App Service를 백 엔드로 사용 중이며 Application Gateway에서만 액세스를 허용하도록 구성되어 있습니다. 이 경우 App Services에서 403 오류를 반환할 수 있습니다. 이 오류는 일반적으로 Application Gateway의 IP 주소를 가리키는 대신 App Services를 직접 가리키는 리디렉션/href 링크로 인해 발생합니다.
  • 스토리지 블로그에 액세스하고 Application Gateway 및 스토리지 엔드포인트가 다른 영역에 있는 경우 Application Gateway의 공용 IP 주소가 허용 목록에 없으면 403 오류가 반환됩니다. 인터넷 IP 범위의 액세스 허가를 참조하세요.

404 - 페이지를 찾을 수 없음

요청이 다음과 같은 애플리케이션 게이트웨이로 전송되는 경우 HTTP 404 응답이 반환될 수 있습니다.

408 - 요청 시간 초과

애플리케이션 게이트웨이의 프런트 엔드 수신기에 대한 클라이언트 요청이 60초 이내에 다시 응답하지 않는 경우 HTTP 408 응답을 관찰할 수 있습니다. 이 오류는 온-프레미스 네트워크와 Azure 간에 트래픽 정체가 발생하거나, 가상 어플라이언스가 트래픽을 검사하거나, 클라이언트 자체에서 과부하가 발생하는 경우 관찰될 수 있습니다.

413 – 요청 엔터티가 너무 큼

Application Gateway에서 Azure 웹 애플리케이션 방화벽을 사용하고 클라이언트 요청 크기가 최대 요청 본문 크기 제한을 초과하는 경우 HTTP 413 응답을 관찰할 수 있습니다. 최대 요청 본문 크기 필드는 파일 업로드를 제외한 전체 요청 크기 제한을 제어합니다. 요청 본문 크기의 기본값은 128KB입니다. 자세한 내용은 웹 애플리케이션 방화벽 요청 크기 제한을 참조하세요.

499 – 클라이언트가 연결을 닫음

서버가 응답을 완료하기 전에 v2 sku를 사용하여 애플리케이션 게이트웨이로 전송되는 클라이언트 요청이 닫힌 경우 HTTP 499 응답이 표시됩니다. 이 오류는 2개의 시나리오에서 관찰될 수 있습니다. 첫 번째 시나리오는 큰 응답이 클라이언트에 반환되고, 서버가 큰 응답 전송을 완료하기 전에 클라이언트가 애플리케이션을 닫거나 새로 고칠 수 있는 경우입니다. 두 번째 시나리오는 클라이언트 쪽 시간 제한이 낮고 서버에서 응답을 수신할 수 있을 만큼 오래 기다리지 않는 경우입니다. 이 경우 클라이언트에서 시간 제한을 늘리는 것이 좋습니다. v1 sku를 사용하는 애플리케이션 게이트웨이에서는 서버가 응답을 완료하기 전에 클라이언트가 연결을 닫는 경우 HTTP 0 응답 코드가 발생할 수 있습니다.

5XX 응답 코드(서버 오류)

500-599 응답 코드는 요청을 수행하는 동안 애플리케이션 게이트웨이 또는 백 엔드 서버에서 문제가 발생했음을 나타냅니다.

500 – 내부 서버 오류

Azure Application Gateway는 500 응답 코드를 표시해서는 안 됩니다. 이 코드는 서비스에 대한 내부 오류이므로 이 코드를 볼 경우 지원 요청을 엽니다. 지원 사례를 여는 방법에 대한 자세한 내용은 Azure 지원 요청 만들기를 참조하세요.

502 - 잘못된 게이트웨이

HTTP 502 오류에는 다음과 같은 몇 가지 근본 원인이 있을 수 있습니다.

502 오류가 발생하는 시나리오 및 문제 해결 방법에 대한 자세한 내용은 잘못된 게이트웨이 오류 문제 해결을 참조하세요.

504 – 게이트웨이 시간 초과

백 엔드 응답 시간이 백 엔드 설정에 구성된 시간 제한 값을 초과하면 Azure Application Gateway v2 SKU에서 HTTP 504 오류를 보냈습니다.

IIS

백엔드 서버가 IIS인 경우, 시간 제한 값을 설정하려면 웹 사이트에 대한 기본 제한을 참조하십시오. 자세한 내용은 connectionTimeout 특성을 참조하세요. IIS의 연결 시간 제한이 백엔드 설정에서 설정된 시간 제한과 일치하거나 초과하지 않는지 확인하십시오.

nginx

백 엔드 서버가 nginx 또는 nginx 수신 컨트롤러이고 업스트림 서버가 있는 경우, nginx:proxy_read_timeout 값이 백 엔드 설정에 지정된 시간 제한과 일치하거나 이를 초과하지 않는지 확인합니다.

다음 단계

이 문서의 정보가 문제를 해결하는 데 도움이 되지 않는 경우 지원 티켓을 제출합니다.