503 서비스를 사용할 수 없음 - 403 오류 발생 시 프록시 터널 생성 실패

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동
정보

증상

클라이언트 애플리케이션은 HTTP 상태 코드 503 Service Unavailable와 함께 오류 코드 protocol.http.ProxyTunnelCreationFailed를 API 호출에 대한 응답으로 가져옵니다.

오류 메시지

클라이언트 애플리케이션은 다음 응답 코드를 가져옵니다.

HTTP/1.1 503 Service Unavailable

또한 다음과 같은 오류 메시지가 표시될 수 있습니다.

{
   "fault":{
      "faultstring":"Proxy refused to create tunnel with response status 403",
      "detail":{
         "errorcode":"protocol.http.ProxyTunnelCreationFailed"
      }
   }
}

정방향 프록시 및 터널링

Apigee Edge를 사용하면 전달 프록시 구성에 설명된 대로 API 프록시가 프록시 서버를 통해 백엔드 서버와 통신할 수 있습니다. 프록시 서버는 사용된 프록시 유형 ( HTTPClient.proxy.type 속성으로 표시)에 따라 백엔드 서버에 대한 보안(HTTPS) 또는 비보안 (HTTP) 연결을 열고 데이터를 양방향으로 전송합니다. 이를 터널링이라고 합니다.

기본적으로 Apigee Edge는 모든 트래픽에 터널링을 사용합니다. 터널링을 사용 중지하려면 속성 HTTPClient.use.tunnelingfalse로 설정해야 합니다.

오류 코드: 프로토콜.http.ProxyTunnelCreationFailed

방화벽, ACL (액세스 제어 목록) 제한사항, DNS 문제, 백엔드 서버 사용 불가, 시간 초과 등의 문제로 프록시 서버가 Apigee Edge와 백엔드 서버 간에 터널을 만들 수 없는 경우 Apigee Edge는 오류 코드 protocol.http.ProxyTunnelCreationFailed를 반환합니다.

Apigee Edge 응답의 faultstring에 있는 상태 코드는 일반적으로 이 오류를 일으킨 높은 수준의 원인을 나타냅니다.

오류 문자열 템플릿:

Proxy refused to create tunnel with response status STATUS_CODE

결함 문자열에서 관찰된 일부 상태 코드의 가능한 원인:

다음 표에서는 faultstring에 표시된 상태 코드에 따라 가능한 원인을 설명합니다.

결함 스트링 설명
프록시가 응답 상태가 403인 터널 생성을 거부했습니다.

403 - Forbidden

이 문제는 백엔드 서버에서 터널 생성을 방지하도록 구성된 방화벽 또는 ACL 제한사항으로 인해 발생할 수 있습니다.

프록시가 응답 상태가 503인 터널 생성을 거부했습니다.

503 - Service Unavailable

이는 DNS 문제, 방화벽 제한, 터널 생성을 방해하는 백엔드 서버의 비가용성으로 인해 발생할 수 있습니다.

프록시에서 응답 상태가 504인 터널 생성을 거부했습니다.

504 - Gateway Timeout

터널 생성 중에 시간 초과가 발생하면 이 문제가 발생할 수 있습니다.

faultstring에서 관찰된 상태 코드에 따라 적절한 기법을 사용하여 문제를 해결해야 합니다. 이 플레이북에서는 faultstring에서 오류 코드 protocol.http.ProxyTunnelCreationFailed상태 코드 403 이 관찰되면 문제를 해결하는 방법을 설명합니다.

가능한 원인

프록시 서버에 의해 Apigee Edge와 백엔드 서버 사이에 터널이 생성되지 않도록 하는 방화벽 또는 ACL (액세스 제어 목록) 제한이 백엔드 서버에 구성된 경우 이 오류 (상태 코드 403)가 발생합니다.

원인 설명 다음에 관한 문제 해결 안내
프록시가 응답 상태가 403인 터널 생성을 거부함 프록시 서버는 Host 헤더의 백엔드 서버 호스트 이름 대신 프록시 서버 호스트 이름을 수신하므로 터널 생성을 거부합니다. Edge Private Cloud 사용자만

일반적인 진단 단계

다음 도구/기술 중 하나를 사용하여 이 오류를 진단하세요.

추적 도구

Trace 도구를 사용하여 오류를 진단하려면 다음 단계를 따르세요.

  1. 트레이스 세션을 사용 설정하고 다음 중 하나를 사용합니다.
    • 오류가 발생할 때까지 기다립니다.
    • 문제를 재현할 수 있는 경우 Proxy refused to create tunnel with response status 403를 사용하여 문제를 재현하는 API를 503 Service Unavailable 호출합니다.
  2. Show all FlowInfos(모든 FlowInfos 표시)가 사용 설정되어 있는지 확인합니다.

  3. 실패한 요청 중 하나를 선택하고 트레이스를 검사합니다.
  4. trace의 여러 단계를 살펴보고 오류가 발생한 위치를 찾습니다.
  5. 일반적으로 아래와 같이 타겟 요청 흐름 시작 단계 후에 오류가 표시됩니다.

    다음 정보를 참고하세요.

    오류: Proxy refused to create tunnel with response status 403

  6. 추적에서 AX (애널리틱스 데이터 기록됨) 단계로 이동하여 클릭합니다.
  7. 단계 세부정보 응답 헤더 섹션까지 아래로 스크롤하고 아래와 같이 X-Apigee-fault-codeX-Apigee-fault-source의 값을 결정합니다.

    ( 더 큰 이미지 보기)

    ( 더 큰 이미지 보기)

  8. X-Apigee-fault-codeX-Apigee-fault-source의 값이 각각 protocol.http.ProxyTunnelCreationFailedtarget 로 표시됩니다. 이는 예상 호스트 헤더가 수신되지 않아 프록시 터널 생성이 실패했기 때문에 이 오류가 발생했음을 나타냅니다.

    응답 헤더
    X-Apigee-fault-code protocol.http.ProxyTunnelCreationFailed
    X-Apigee-fault-source target

NGINX

NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.

  1. Private Cloud 사용자는 NGINX 액세스 로그를 사용하여 HTTP 503 Service Unavailable 오류에 대한 주요 정보를 확인할 수 있습니다.
  2. NGINX 액세스 로그를 확인합니다.

    /opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log

    여기서 ORG, ORG, PORT#는 실제 값으로 대체됩니다.

  3. 특정 기간 (과거에 문제가 발생한 경우) 동안 오류 코드 protocol.http.ProxyTunnelCreationFailed와 함께 503 오류가 있는지 또는 503와 함께 여전히 실패하는 요청이 있는지 검색합니다.
  4. X-Apigee-fault-code 값과 일치하는 X-Apigee-fault-code 가 포함된 503 오류가 있는 경우 X-Apigee-fault-code 의 값을 결정합니다.

    NGINX 액세스 로그의 샘플 503 오류:

    NGINX 액세스 로그의 위 샘플 항목에는 X- Apigee-fault-codeX-Apigee-fault-source에 대한 값이 있습니다.

    응답 헤더
    X-Apigee-fault-code protocol.http.ProxyTunnelCreationFailed
    X-Apigee-fault-source target

원인: 프록시가 응답 상태가 403인 터널 생성을 거부했습니다.

진단

  1. 일반적인 진단 단계에 설명된 대로 Trace 도구 또는 NGINX 액세스 로그를 사용하여 503 Service Unavailable오류 코드오류 소스를 확인합니다.
  2. 오류 메시지를 검토하고 터널 생성 실패에 대해 faultstring에 표시된 상태 코드를 확인합니다.
  3. 이 시나리오에서 상태 코드는 금지됨을 의미하는 403입니다.
  4. 이는 터널을 만들 수 있는 권한이나 권한이 충분하지 않음을 의미합니다. 이 문제는 일반적으로 터널 생성을 방지하는 방화벽 또는 ACL (액세스 제어 목록) 제한이 있는 경우에 발생할 수 있습니다.
  5. 터널 생성을 막을 수 있는 백엔드 서버에 구성된 방화벽 또는 ACL 제한사항을 검토합니다.
  6. 방화벽 또는 ACL 제한사항의 유형에 따라 문제를 적절하게 해결해야 합니다.
  7. 방화벽 제한사항의 예시를 통해 이 문제를 해결하는 방법을 살펴보겠습니다.

    시나리오: 백엔드 서버의 방화벽 제한이 호스트 헤더에 항상 백엔드 서버 호스트 이름을 포함해야 한다고 예상함

    다음 방법 중 하나를 사용하여 Apigee Edge에서 전달한 호스트 헤더를 확인할 수 있습니다.

    Trace

    Trace를 사용하여 호스트 헤더를 확인하려면 다음 단계를 따르세요.

    1. 일반적인 진단 단계에 설명된 대로 트레이스를 사용하여 faultstringProxy refused to create tunnel with response status 403가 포함되어 있는지 확인합니다.
    2. Target Request Flow Started(대상 요청 흐름 시작) 단계로 이동하여 요청 헤더를 검토합니다.
    3. 요청 헤더 섹션의 호스트 헤더에 지정된 호스트 이름의 값을 확인합니다.
    4. 호스트 헤더에 프록시 호스트 이름이 포함되어 있으면 이로 인해 이 오류가 발생한 것입니다.
    5. 이는 방화벽이 호스트 헤더백엔드 서버 이름이 포함된 경우에만 요청을 수락하도록 백엔드 서버에서 구성되어 있기 때문입니다.
    6. 따라서 프록시 서버가 백엔드 서버로 터널을 만들려고 하면 오류가 발생하고 실패합니다.

      Proxy refused to create tunnel with response status 403.

      프록시 호스트 이름이 있는 호스트 헤더를 보여주는 샘플 trace

      ( 더 큰 이미지 보기)

      위에 표시된 샘플 트레이스에서는 호스트 헤더에 프록시 호스트의 이름(www.proxyserver.com. )이 포함되어 있음을 보여줍니다. 호스트 헤더에는 백엔드 서버 호스트 이름만 포함되어야 하는 백엔드 서버에 구성된 방화벽 제한사항이 백엔드 서버에 있으므로 Proxy refused to create tunnel with response status 403 오류가 발생합니다.

    tcpdump

    tcpdump를 사용하여 호스트 헤더 확인

    1. 다음 명령어를 사용하여 프록시 서버에서 Apigee Edge의 메시지 프로세서 구성요소에서 전송되는 요청에 대해 tcpdump를 캡처합니다.

      tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
      

      tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump를 참조하세요.

    2. Wireshark 도구 또는 유사한 도구를 사용하여 tcpdump 데이터를 분석합니다.
    3. 다음은 Wireshark를 사용한 tcpdump의 샘플 분석입니다.

      ( 더 큰 이미지 보기)

    4. 패킷 번호 13, 14, 15는 메시지 프로세서가 3방향 TCP 핸드셰이크 프로세스를 통해 프록시 서버에 연결을 설정하고 있음을 나타냅니다.
    5. 패킷 16에서 메시지 프로세서가 프록시 호스트인 httpbin.org (위의 예에 표시됨)에 연결되었습니다.
    6. 패킷 16을 선택하고 패킷의 내용, 특히 메시지 프로세서에 의해 프록시 서버로 전달되는 호스트 헤더를 자세히 검토합니다.

    7. 위 샘플은 프록시 서버의 호스트 이름인 호스트 헤더 httpin.org를 보여줍니다. 따라서 프록시 서버가 위의 호스트 헤더 httpin.org를 전달하여 백엔드 서버로 터널을 만들려고 하면 Proxy refused to create tunnel with response status 403 오류가 표시되며 실패합니다.

해상도

시나리오: 프록시 서버의 방화벽 제한에서 호스트 헤더에 항상 백엔드 서버 호스트 이름이 포함되어야 함

백엔드 서버의 방화벽이 호스트 헤더에는 항상 backend 서버 호스트 이름이 포함되어야 하며 메시지 프로세서가 backend 호스트 이름을 전송할 것으로 예상하도록 구성되어 이 오류가 발생한 것이 확인되면 다음 단계를 수행하여 문제를 해결합니다.

  1. 다음 예와 같이 TargetEndpoint에서 속성 use.proxy.host.header.with.target.uri 를 true로 설정합니다.

    샘플 TargetEndpoint 구성:

    <TargetEndpoint name="default">
      <HTTPTargetConnection>
        <URL>https://mocktarget.apigee.net/json</URL>
        <Properties>
          <Property name="use.proxy.host.header.with.target.uri">true</Property>
        </Properties>
      </HTTPTargetConnection>
    </TargetEndpoint>
    
  2. 전달 프록시와 관련된 다른 속성이 메시지 프로세서에 다음과 같이 구성되어 있는지 확인합니다.

    1. 각 메시지 프로세서에서 /opt/apigee/customer/application/message-processor.properties 파일을 검토합니다.
    2. 사용 사례 또는 요구사항에 따라 다음 속성을 설정해야 합니다.

      속성의 샘플 값:

      conf_http_HTTPClient.use.proxy=true
      conf/http.properties+HTTPClient.proxy.type=HTTP
      conf/http.properties+HTTPClient.proxy.host=PROXY_SERVER_HOST_NAME
      conf/http.properties+HTTPClient.proxy.port=PORT_#
      conf/http.properties+HTTPClient.proxy.user=USERNAME
      conf/http.properties+HTTPClient.proxy.password=PASSWORD
      

진단 정보 수집 필요

위의 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집한 다음 Apigee Edge 지원팀에 문의하세요.

Private Cloud 사용자인 경우 다음 정보를 제공하세요.

  • 실패한 요청에 대해 발견된 전체 오류 메시지
  • 환경 이름
  • API 프록시 번들
  • API 요청에 대한 추적 파일
  • NGINX 액세스 로그

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    여기서 ORG, ENV, PORT#는 실제 값으로 대체됩니다.

  • 메시지 프로세서 시스템 로그

    /opt/apigee/var/log/edge-message-processor/logs/system.log
    

참조