다음을 통해 공유


Application Gateway의 잘못된 게이트웨이 오류 문제 해결

Azure Application Gateway를 사용할 때 받은 잘못된 게이트웨이(502) 오류 문제 해결 방법을 알아봅니다.

참고

Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Az로 마이그레이션을 참조하세요.

개요

애플리케이션 게이트웨이를 구성한 후에 표시될 수 있는 오류 중 하나는 서버 오류: 502 - 웹 서버가 게이트웨이 또는 프록시 서버 역할을 하는 동안 잘못된 응답을 받았습니다입니다. 이 오류는 다음과 같은 주요 이유로 인해 발생할 수 있습니다.

네트워크 보안 그룹, 사용자 정의 경로 또는 사용자 지정 DNS 문제

원인

NSG, UDR 또는 사용자 지정 DNS로 인해 백 엔드에 대한 액세스가 차단된 경우, 애플리케이션 게이트웨이 인스턴스는 백 엔드 풀에 연결할 수 없습니다. 이 문제로 인해 프로브 오류가 발생하여 502 오류가 발생합니다.

NSG/UDR은 애플리케이션 게이트웨이 서브넷이나 애플리케이션 VM이 배포된 서브넷에 있을 수 있습니다.

마찬가지로 VNet에 사용자 지정 DNS가 있으면 문제가 발생할 수도 있습니다. 백 엔드 풀 구성원에 사용되는 FQDN은 사용자가 VNet에 대해 구성된 DNS 서버에 의해 올바르게 확인되지 않을 수 있습니다.

해결 방법

다음 단계를 통해 NSG, UDR 및 DNS 구성을 확인합니다.

  1. 애플리케이션 게이트웨이 서브넷과 연결된 NSG를 확인합니다. 백 엔드와의 통신이 차단되지 않는지 확인합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.

  2. 애플리케이션 게이트웨이 서브넷과 연결된 UDR을 확인합니다. UDR이 백 엔드 서브넷에서 트래픽을 보내지 않는지 확인합니다. 예를 들어 ExpressRoute/VPN을 통해 애플리케이션 게이트웨이 서브넷에 보급되는 네트워크 가상 어플라이언스 경로 또는 기본 경로에 대한 라우팅을 확인합니다.

    $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
    Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
    
  3. 백 엔드 VM과의 유효한 NSG 및 경로를 확인합니다.

    Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
    Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
    
  4. VNet에 사용자 지정 DNS의 존재 여부를 확인합니다. 출력에서 VNet 속성의 세부 정보를 확인하여 DNS를 확인할 수 있습니다.

    Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
    DhcpOptions            : {
                               "DnsServers": [
                                 "x.x.x.x"
                               ]
                             }
    
  5. 있는 경우, DNS 서버가 백 엔드 풀 멤버의 FQDN을 올바르게 확인할 수 있는지 확인합니다.

기본 상태 검색의 문제

원인

502 오류는 종종 기본 상태 프로브가 백 엔드 VM에 연결할 수 없다는 지표일 수도 있습니다.

애플리케이션 게이트웨이 인스턴스를 프로비전할 경우 BackendHttpSetting의 속성을 사용하여 각 BackendAddressPool에 대한 기본 상태 프로브를 자동으로 구성합니다. 이 프로브를 설정하기 위해 사용자 입력이 필요하지 않습니다. 특히 부하 분산 규칙을 구성하는 경우 BackendHttpSetting과 BackendAddressPool 간에 연결이 생성됩니다. 기본 프로브가 이 연결 각각에 대해 구성되고 애플리케이션 게이트웨이가 BackendHttpSetting 요소에 지정된 포트에서 BackendAddressPool의 각 인스턴스에 대한 정기 상태 검사 연결을 시작합니다.

다음 표에는 기본 상태 프로브로 연결된 값을 나열합니다.

프로브 속성 설명
프로브 URL http://127.0.0.1/ URL 경로
간격 30 프로브 간격(초)
시간 제한 30 프로브 시간 제한(초)
비정상 임계값 3 프로브 재시도 횟수. 연속된 프로브 실패 횟수가 비정상 임계값에 도달하면 백 엔드 서버가 다운된 것으로 표시됩니다.

해결 방법

  • 요청의 호스트 값은 127.0.0.1로 설정됩니다. 기본 사이트를 구성하고 127.0.0.1에서 수신 대기 중인지를 확인합니다.
  • 요청의 프로토콜은 BackendHttpSetting 프로토콜에 의해 결정됩니다.
  • URI 경로가 .로 설정됩니다 /.
  • BackendHttpSetting이 포트 80이 아닌 다른 포트를 지정하는 경우 기본 사이트는 해당 포트에서 수신하도록 구성되어야 합니다.
  • protocol://127.0.0.1:port 호출은 HTTP 결과 코드 200을 반환해야 합니다. 이 코드는 30초의 제한 시간 내에 반환되어야 합니다.
  • 구성된 포트가 열려 있고 방화벽 규칙 또는 Azure 네트워크 보안 그룹이 없는지를 확인합니다. 여기서 구성된 포트에서 들어오거나 나가는 트래픽을 차단합니다.
  • Azure 클래식 VM 또는 클라우드 서비스를 FQDN 또는 공용 IP와 사용하는 경우 해당 엔드포인트가 열려 있는지 확인합니다.
  • VM이 Azure Resource Manager를 통해 구성되고 애플리케이션 게이트웨이가 배포된 VNet의 외부에 있는 경우 원하는 포트에 대한 액세스를 허용하도록 네트워크 보안 그룹을 구성해야 합니다.

자세한 내용은 Application Gateway 인프라 구성을 참조하세요.

사용자 지정 상태 검색의 문제

원인

사용자 지정 상태 프로브를 사용하면 기본 검사 동작에 추가적인 유연성을 제공할 수 있습니다. 사용자 지정 프로브를 사용하는 경우 프로브 간격, URL, 테스트할 경로, 백 엔드 풀 인스턴스를 비정상으로 표시하기 전에 허용할 실패 응답 횟수를 구성할 수 있습니다.

다음과 같은 추가 속성이 추가됩니다.

프로브 속성 설명
이름 프로브 이름입니다. 이 이름은 백 엔드 HTTP 설정에서 프로브를 참조하는 데 사용됩니다.
프로토콜 프로브를 보내는 데 사용하는 프로토콜입니다. 프로브는 백 엔드 HTTP 설정에 정의된 프로토콜을 사용합니다.
호스트 프로브에 보낼 호스트 이름입니다. 다중 사이트를 애플리케이션 게이트웨이에 구성하는 경우에만 적용할 수 있습니다. VM 호스트 이름과 다릅니다.
경로 프로브의 상대 경로입니다. 올바른 경로는 '/'부터 시작합니다. 프로브는 <protocol>://<host>:<port><path>로 전송됩니다.
간격 프로브 간격(초). 연속된 두 프로브 사이의 시간 간격입니다.
시간 제한 프로브 시간 제한(초) 이 시간 제한 기간 내에 올바른 응답을 받지 못하면 프로브가 실패로 표시됩니다.
비정상 임계값 프로브 재시도 횟수. 연속된 프로브 실패 횟수가 비정상 임계값에 도달하면 백 엔드 서버가 다운된 것으로 표시됩니다.

해결 방법

위의 표와 같이 사용자 지정 상태 프로브를 올바르게 구성했는지 확인합니다. 앞의 문제 해결 단계 외에도 다음 사항을 확인합니다.

  • 프로브가 가이드를 기준으로 올바르게 지정되어 있는지 확인합니다.
  • 애플리케이션 게이트웨이가 단일 사이트에 대해 구성된 경우, 사용자 지정 프로브에서 달리 구성되지 않은 경우 기본적으로 호스트 이름을 127.0.0.1로 지정해야 합니다.
  • http://<host>:<port><path>에 대한 호출은 HTTP 결과 코드 200을 반환해야 합니다.
  • Interval, Timeout, UnhealthyThreshold가 허용 범위 내에 있는지 확인합니다.
  • HTTPS 프로브를 사용하는 경우 백 엔드 서버 자체에서 대체(fallback) 인증서를 구성하여 백 엔드 서버에 SNI가 필요하지 않도록 합니다.

요청 시간 초과

원인

사용자 요청이 수신되면 애플리케이션 게이트웨이가 요청에 구성된 규칙을 적용하고 백 엔드 풀 인스턴스를 라우팅합니다. 백 엔드 인스턴스의 응답에 대해 구성 가능한 시간 간격을 기다립니다. 기본적으로 이 간격은 20초입니다. Application Gateway v1에서 애플리케이션 게이트웨이가 이 간격에서 백 엔드 애플리케이션의 응답을 수신하지 않으면 사용자 요청에 502 오류가 표시됩니다. Application Gateway v2에서 애플리케이션 게이트웨이가 이 간격으로 백 엔드 애플리케이션으로부터 응답을 받지 못하면 두 번째 백 엔드 풀 멤버에 대해 요청이 시도됩니다. 두 번째 요청이 실패하면 사용자 요청에 504 오류가 발생합니다.

해결 방법

Application Gateway를 사용하면 다른 풀에 적용할 수 있는 BackendHttpSetting을 통해 이 설정을 구성할 수 있습니다. 다른 백 엔드 풀에서는 다른 BackendHttpSetting 및 다른 요청 시간 초과를 구성할 수 있습니다.

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

비어 있는 BackendAddressPool

원인

애플리케이션 게이트웨이에 백 엔드 주소 풀에 구성된 VM 또는 가상 머신 확장 집합이 없는 경우 고객 요청을 라우팅할 수 없고 잘못된 게이트웨이 오류를 보냅니다.

해결 방법

백 엔드 주소 풀이 비어 있지 않은지 확인합니다. PowerShell, CLI 또는 포털을 통해 수행할 수 있습니다.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

앞의 cmdlet에서 출력은 비어 있지 않은 백 엔드 주소 풀을 포함해야 합니다. 다음은 백 엔드 VM에 대한 FQDN 또는 IP 주소로 구성된 두 개의 풀을 반환하는 예제입니다. BackendAddressPool의 상태를 프로비전하는 작업은 '성공'해야 합니다.

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

BackendAddressPool의 비정상 인스턴스

원인

BackendAddressPool의 모든 인스턴스가 정상이 아닌 경우 어플리케이션 게이트웨이에는 사용자 요청을 라우팅할 백 엔드가 없습니다. 백 엔드 인스턴스가 정상이지만 필요한 애플리케이션이 배포되지 않은 경우일 수도 있습니다.

해결 방법

인스턴스가 정상이고 애플리케이션이 올바르게 구성되어 있는지 확인합니다. 백 엔드 인스턴스가 동일한 VNet의 다른 VM에서 ping에 응답할 수 있는지를 확인합니다. 퍼블릭 엔드포인트로 구성된 경우 웹 애플리케이션에 대한 브라우저 요청을 서비스할 수 있는지를 확인합니다.

업스트림 SSL 인증서가 일치하지 않음

원인

백 엔드 서버에 설치된 TLS 인증서가 호스트 요청 헤더에서 받은 호스트 이름과 일치하지 않습니다.

엔드투엔드 TLS를 사용하도록 설정하고 적절한 "백 엔드 HTTP 설정"을 편집하고 "백 엔드 프로토콜" 설정의 구성을 HTTPS로 변경하여 구현되는 구성에서 백 엔드 서버에 설치된 TLS 인증서의 DNS 이름이 HTTP 호스트 헤더 요청의 백 엔드로 들어오는 호스트 이름과 일치하는지 확인해야 합니다.

미리 알림으로, "백 엔드 HTTP 설정"에서 HTTP가 아닌 프로토콜 HTTPS 옵션을 사용하도록 설정하는 효과는 Application Gateway 인스턴스와 백 엔드 서버 간에 발생하는 통신의 두 번째 부분이 TLS로 암호화된다는 것입니다.

기본적으로 Application Gateway가 클라이언트에서 수신하는 것과 동일한 HTTP 호스트 헤더를 백 엔드로 보내기 때문에 백 엔드 서버에 설치된 TLS 인증서가 HTTP 호스트 헤더에서 해당 백 엔드 서버에서 받은 호스트 이름과 일치하는 DNS 이름으로 발급되었는지 확인해야 합니다. 달리 지정하지 않은 경우 이 호스트 이름은 클라이언트에서 수신한 호스트 이름과 동일합니다.

예를 들면 다음과 같습니다.

도메인 www.contoso.com에 대한 https 요청을 제공하는 Application Gateway가 있다고 상상해 보세요. Azure DNS 공용 영역에 도메인 contoso.com을 위임하고, 그 영역에서 www.contoso.com 요청을 처리할 특정 Application Gateway의 공용 IP를 가리키는 DNS 레코드를 가질 수 있습니다.

해당 Application Gateway에는 호스트 www.contoso.com에 대한 수신기가 있어야 하며, 이 수신기는 프로토콜 HTTPS를 강제로 사용하여 엔드투엔드 TLS를 보장하는 규칙을 갖춘 백엔드 HTTP 설정을 포함해야 합니다. IIS를 웹 서버로 실행하는 VM이 두 개 있는 백 엔드 풀을 동일한 규칙으로 구성했을 수 있습니다.

규칙의 "지원되는 HTTP 설정"에서 HTTPS를 사용하도록 설정하면 Application Gateway 인스턴스와 백 엔드의 서버 간에 TLS를 사용하는 통신의 두 번째 부분이 됩니다.

백 엔드 서버에 DNS 이름 www.contoso.com 또는 *.contoso.com 대해 발급된 TLS 인증서가 없는 경우 서버 오류: 502 - 웹 서버가 게이트웨이 또는 프록시 서버 역할을 하는 동안 잘못된 응답을 수신 했습니다. 업스트림 SSL 인증서(백 엔드 서버에 설치된 인증서)가 호스트 헤더의 호스트 이름과 일치하지 않기 때문입니다. 따라서 TLS 협상이 실패합니다.

www.contoso.com --> APP GW 프런트 엔드 IP --> HTTP가 아닌 프로토콜 HTTPS를 사용하도록 "백 엔드 HTTP 설정"을 구성하는 규칙이 있는 수신기 -> 백 엔드 풀 --> 웹 서버(TLS 인증서가 설치되어 www.contoso.com있어야 함)

해결 방법

백 엔드 서버에 설치된 TLS 인증서의 DNS 이름이 HTTP 백 엔드 설정에 구성된 호스트 이름과 일치해야 합니다. 그렇지 않으면 Application Gateway 인스턴스와 백 엔드 간에 발생하는 엔드투엔드 통신의 두 번째 부분인 "업스트림 SSL 인증서가 일치하지 않음"으로 실패하고 서버 오류를 다시 throw합니다. 502 - 웹 서버가 게이트웨이 또는 프록시 서버 역할을 하는 동안 잘못된 응답을 받았습니다.

다음 단계

앞의 단계에서 문제가 해결되지 않으면 지원 티켓을 엽니다.