이 페이지는 Cloud Translation API를 통해 번역되었습니다.

502 잘못된 게이트웨이 시간 초과 오류

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

증상

클라이언트 애플리케이션에 502 Bad Gateway 오류가 수신됩니다. 메시지 프로세서는 백엔드 서버로부터 응답을 수신하지 못하면 클라이언트 애플리케이션에 이 오류를 반환합니다.

오류 메시지

클라이언트 애플리케이션은 다음과 같은 응답 코드를 수신합니다.

HTTP/1.1 502 Bad Gateway

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

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

가능한 원인

이 문제의 가능한 원인은 다음 표에 나와 있습니다.

원인	설명	문제 해결 단계는
TLS/SSL 핸드셰이크 제한 시간	메시지 프로세서와 백엔드 서버 간의 TLS/SSL 핸드셰이크가 진행되는 동안 시간 초과가 발생합니다.	에지 프라이빗 및 퍼블릭 클라우드 사용자

원인: TLS/SSL 핸드셰이크 시간 초과

Apigee Edge에서는 백엔드 서버에 대한 TLS/SSL 연결을 설정하여 에지 메시지 프로세서와 백엔드 서버 간의 TLS 통신을 사용 설정할 수 있습니다.

TLS/SSL 핸드셰이크에는 여러 단계가 포함됩니다. 이 오류는 일반적으로 메시지 프로세서와 백엔드 서버 간의 TLS/SSL 핸드셰이크가 타임아웃될 때 발생합니다.

진단

이 섹션에서는 TLS/SSL 핸드셰이크 시간 제한을 올바르게 진단하는 방법을 설명합니다. Edge 프라이빗 클라우드 및 퍼블릭 클라우드에 대한 안내가 나열됩니다.

Trace 세션 출력 조사

다음 단계에서는 Apigee Edge Trace 도구를 사용하여 문제를 예비 진단하는 방법을 설명합니다.

Edge UI에서 영향을 받은 API 프록시에 추적 세션을 사용 설정합니다.
실패한 API 요청에 대한 추적에 다음과 같이 표시되면 TLS/SSL 핸드셰이크 시간 제한 오류가 발생했을 가능성이 높습니다. 이 오류는 백엔드 서버 방화벽이 Apigee의 트래픽을 차단했기 때문일 수 있습니다.
1. 메시지 프로세서에 설정된 기본 제한 시간인 55초 후에 502 Bad Gateway 오류가 발생하는지 확인합니다. 55초 후에 오류가 발생한다면 시간 초과로 인해 문제가 발생했을 수 있습니다.
2. 오류에 오류가 표시되는지 확인합니다. messaging.adaptors.http.BadGateway. 다시 말하지만, 이 오류는 일반적으로 시간 초과가 발생했음을 나타냅니다.
3. Edge Private Cloud를 사용하는 경우 아래와 같이 트레이스 출력에서 X-Apigee.Message-ID 필드 값을 기록해 둡니다. Private Cloud 사용자는 이 ID 값을 사용하여 이후에 설명된 대로 추가적인 문제 해결을 수행할 수 있습니다.
  1. trace 경로에서 Analytics Data Recorded 아이콘을 클릭합니다.
  2. 아래로 스크롤하여 X-Apigee.Message-ID라는 필드의 값을 기록합니다.

TLS/SSL 핸드셰이크 시간 초과가 오류의 원인인지 확인하려면 퍼블릭 클라우드를 사용 중인지 아니면 프라이빗 클라우드를 사용 중인지에 따라 다음 섹션의 단계를 따르세요.

Edge Private Cloud 사용자만을 위한 추가 진단 단계

Apigee Edge 프라이빗 클라우드를 사용하는 경우 다음 단계를 수행하여 핸드셰이크 오류의 원인을 확인할 수 있습니다. 이 단계에서는 메시지 프로세서 로그 파일에서 관련 정보를 검사합니다. Edge Public Cloud를 사용 중인 경우 이 섹션을 건너뛰고 프라이빗 및 퍼블릭 클라우드 사용자를 위한 추가 진단 단계로 이동할 수 있습니다.

telnet 명령어를 사용하여 각 메시지 프로세서에서 특정 백엔드 서버에 직접 연결할 수 있는지 확인합니다.
1. 백엔드 서버가 단일 IP 주소로 확인되면 다음 명령어를 사용합니다.
```
telnet BackendServer-IPaddress 443
```
2. 백엔드 서버가 여러 IP 주소로 확인되면 아래와 같이 telnet 명령어에 백엔드 서버의 호스트 이름을 사용합니다.
```
telnet BackendServer-HostName 443
```
오류 없이 백엔드 서버에 연결할 수 있다면 다음 단계로 이동합니다.

telnet 명령어가 실패하면 네트워크팀과 협력하여 메시지 프로세서와 백엔드 서버 간의 연결을 확인해야 합니다.
메시지 프로세서 로그 파일에서 핸드셰이크 실패의 증거를 확인합니다. 파일을 엽니다.

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

고유한 메시지 ID (추적 파일에서 찾은 X-Apigee.Message-ID 값)를 검색합니다. 아래와 같이 메시지 ID와 연결된 핸드셰이크 오류 메시지가 표시되는지 확인합니다.
```
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout
```

메시지 프로세서의 로그 파일에 이 오류가 표시되면 추가 조사를 계속 진행합니다. Edge Private 및 Public Cloud 사용자를 위한 추가 진단 단계를 참고하세요.

로그 파일에 핸드셰이크 메시지가 표시되지 않으면 진단 정보를 수집해야 함으로 이동합니다.

Edge 프라이빗 클라우드 및 퍼블릭 클라우드 사용자를 위한 추가 진단 단계

문제를 더 자세히 파악하기 위해 tcpdump 도구를 사용하여 TCP/IP 패킷을 분석하여 TLS/SSL 핸드셰이크 중에 시간 초과가 발생했는지 확인할 수 있습니다.

프라이빗 클라우드 사용자는 백엔드 서버 또는 메시지 프로세서에서 TCP/IP 패킷을 캡처할 수 있습니다. 백엔드 서버에서 패킷이 복호화되므로 백엔드 서버에서 캡처하는 것이 좋습니다.
퍼블릭 클라우드 사용자는 메시지 프로세서에 액세스할 수 없습니다. 하지만 백엔드 서버에서 TCP/IP 패킷을 캡처하면 문제를 파악하는 데 도움이 될 수 있습니다.
TCP/IP 패킷을 캡처할 위치를 결정한 후 다음 tcpdump 명령어를 사용하여 TCP/IP 패킷을 캡처합니다.
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
- 백엔드 서버에서 TCP/IP 패킷을 가져오는 경우 tcpdump 명령어에 메시지 프로세서의 공개 IP 주소를 사용합니다. 명령어를 사용하여 백엔드 서버 트래픽을 검사하는 방법은 tcpdump를 참조하세요.
- 메시지 프로세서에서 TCP/IP 패킷을 가져오는 경우 tcpdump 명령어에 백엔드 서버의 공개 IP 주소를 사용합니다. 메시지 프로세서 트래픽을 검사하는 명령어를 사용하는 데 대한 도움말은 tcpdump를 참조하세요.
- 백엔드 서버/메시지 프로세서에 IP 주소가 여러 개 있으면 tcpdump 명령어를 다시 사용해야 합니다. 이 도구에 대한 자세한 내용과 이 명령어의 다른 변형은 tcpdump를 참조하세요.
Wireshark 도구 또는 유사한 도구를 사용하여 TCP/IP 패킷을 분석합니다. 다음 스크린샷은 Wireshark의 TCP/IP 패킷을 보여줍니다.
Wireshark 출력에서 3방향 TCP 핸드셰이크가 처음 3개의 패킷에서 성공적으로 완료됩니다.
그런 다음 메시지 프로세서는 패킷 4에서 'Client Hello' 메시지를 전송합니다.
백엔드 서버에서 응답이 없으므로 메시지 프로세서는 사전 정의된 시간 간격을 기다린 후 패킷 5, 6, 7에서 'Client Hello' 메시지를 여러 번 재전송합니다.
3회 다시 시도한 후에도 메시지 프로세서가 확인을 받지 못하면 백엔드 서버로 FIN, ACK 메시지를 전송하여 연결을 종료 중임을 알립니다.
Wireshark 세션 예에서 알 수 있듯이 백엔드 연결은 성공했지만 (1단계) 백엔드 서버가 응답하지 않아 SSL 핸드셰이크가 타임아웃되었습니다.

이 플레이북의 문제 해결 단계를 수행한 후 시간 초과로 인해 TLS/SSL 핸드셰이크 오류가 발생한 것으로 확인되면 해결 방법 섹션으로 이동합니다.

API 모니터링을 사용하여 문제 식별

API 모니터링을 사용하면 문제 영역을 빠르게 격리하여 오류, 성능, 지연 시간 문제를 진단하고 개발자 앱, API 프록시, 백엔드 대상, API 플랫폼 등의 소스를 진단할 수 있습니다.

API Monitoring을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 단계별로 살펴보세요. 예를 들어 messaging.adaptors.http.BadGateway 오류의 수가 특정 기준점을 초과하면 알림을 받도록 알림을 설정할 수 있습니다.

해상도

일반적으로 SSL 핸드셰이크 시간 초과는 Apigee Edge의 트래픽을 차단하는 백엔드 서버의 방화벽 제한으로 인해 발생합니다. 진단 단계에 따라 핸드셰이크 오류의 원인이 시간 초과로 확인되었으면 네트워크팀에 문의하여 원인을 파악하고 방화벽 제한을 해결해야 합니다.

방화벽 제한은 다른 네트워크 계층에 적용될 수 있습니다. Apigee Edge 및 백엔드 서버 간의 원활한 트래픽 흐름을 위해 메시지 프로세서 IP와 관련된 모든 네트워크 계층의 제한사항을 삭제해야 합니다.

방화벽 제한이 없거나 문제가 계속 발생하면 진단 정보를 수집해야 함으로 이동합니다.

진단 정보 수집 필수

위 지침을 따른 후에도 문제가 지속되면 다음 진단 정보를 수집하세요. 문의하고 Apigee Edge 지원팀에 공유하세요.

퍼블릭 클라우드 사용자인 경우 다음 정보를 제공하세요.
1. 조직 이름
2. 환경 이름
3. API 프록시 이름
4. curl 명령어를 완료하여 오류를 재현하세요.
5. 오류를 보여주는 추적 파일
6. 백엔드 서버에서 캡처된 TCP/IP 패킷
Private Cloud 사용자인 경우 다음 정보를 제공하세요.
1. 완료 오류 메시지 관찰됨
2. API 프록시 번들
3. 오류를 보여주는 추적 파일
4. 메시지 프로세서 로그 /opt/apigee/var/log/edge-message-processor/logs/system.log
5. 백엔드 서버 또는 메시지 프로세서에서 캡처된 TCP/IP 패킷입니다.
이 플레이북에서 시도해 본 섹션 및 이 문제를 빠르게 해결하는 데 도움이 되는 기타 정보에 관한 세부정보입니다.