다음을 통해 공유


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

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

참고 항목

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

개요

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

솔루션

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

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

요청 시간 초과

원인

사용자 요청이 수신되면 애플리케이션 게이트웨이가 요청에 구성된 규칙을 적용하고 백 엔드 풀 인스턴스를 라우팅합니다. 백 엔드 인스턴스의 응답에 대해 구성 가능한 시간 간격을 기다립니다. 기본적으로 이 간격은 20초입니다. Application Gateway v1에서 애플리케이션 게이트웨이가 이 간격에서 백 엔드 애플리케이션의 응답을 수신하지 않으면 사용자 요청에 502 오류가 표시됩니다. Application Gateway v2에서 Application Gateway가 이 간격 동안 백 엔드 애플리케이션의 응답을 수신하지 않으면 두 번째 백 엔드 풀 멤버에 대해 요청이 시도됩니다. 두 번째 요청이 실패하면 사용자 요청에 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 인증서의 CNAME이 HTTP 호스트 헤더 요청의 백 엔드로 들어오는 호스트 이름과 일치하는지 확인해야 합니다.

즉, "백 엔드 HTTP 설정"에서 HTTP가 아닌 프로토콜 HTTPS 옵션을 사용하면 Application Gateway 인스턴스와 백 엔드 서버 간에 발생하는 통신의 두 번째 부분이 TLS로 암호화됩니다.

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

예시:

www.contoso.com 도메인에서 https 요청을 처리하는 Application Gateway가 있다고 가정해 보세요. contoso.com 도메인을 Azure DNS 공용 영역에 위임하고, 요청을 처리할 특정 Application Gateway의 공용 IP로 www.contoso.com을 가리키는 DNS를 포함할 수 있습니다.

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

알고 있는 바와 같이 규칙의 "백업 HTTP 설정"에서 HTTPS를 사용하면 Application Gateway 인스턴스와 백엔드 서버 간에 발생하는 통신의 두 번째 부분이 TLS를 사용하게 됩니다.

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

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

솔루션

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

다음 단계

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