Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

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

Apigee Edge 문서입니다.
Go to the Apigee X 문서로 이동합니다. info

증상

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

오류 메시지

클라이언트 애플리케이션에 다음 응답 코드가 수신됩니다.

HTTP/1.1 502 Bad Gateway

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

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

가능한 원인

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

원인	설명	문제 해결 단계를 수행할 수 있는 사용자
TLS/SSL 핸드셰이크 제한 시간	메시지 프로세서와 백엔드 서버 간의 TLS/SSL 핸드셰이크 중에 제한 시간이 발생합니다.	Edge Private 및 Public Cloud 사용자

원인: TLS/SSL 핸드셰이크 제한 시간

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

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

진단

이 섹션에서는 TLS/SSL 핸드셰이크 제한 시간을 올바르게 진단하는 방법을 설명합니다. Edge Private Cloud 및 Public Cloud의 안내가 나와 있습니다.

Trace 세션 출력 조사

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

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

TLS/SSL 핸드셰이크 제한 시간이 오류의 원인인지 확인하려면 Public Cloud 또는 Private Cloud를 사용하는지에 따라 다음 섹션의 단계를 따르세요.

Edge Private Cloud 사용자 전용 추가 진단 단계

Apigee Edge Private Cloud를 사용하는 경우 다음 단계를 수행하여 핸드셰이크 오류의 원인을 확인할 수 있습니다. 이 단계에서는 메시지 프로세서 로그 파일에서 관련 정보를 검사합니다. Edge Public Cloud를 사용하는 경우 이 섹션을 건너뛰고 Private 및 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 Private 및 Public Cloud 사용자를 위한 추가 진단 단계

문제를 더 정확하게 파악하려면 tcpdump 도구를 사용하여 TCP/IP 패킷을 분석하여 TLS/SSL 핸드셰이크 중에 제한 시간이 발생했는지 확인할 수 있습니다.

Private Cloud 사용자는 백엔드 서버 또는 메시지 프로세서에서 TCP/IP 패킷을 캡처할 수 있습니다. 패킷이 백엔드 서버에서 복호화되므로 백엔드 서버에서 캡처하는 것이 좋습니다.
Public Cloud 사용자는 메시지 프로세서에 액세스할 수 없지만 백엔드 서버에서 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 모니터링을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오 를 단계별로 살펴보세요. 예를 들어 messaging.adaptors.http.BadGateway 오류 수가 특정 기준을 초과할 때 알림을 받도록 알림을 설정할 수 있습니다.

해상도

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

방화벽 제한은 여러 네트워크 계층에서 적용될 수 있습니다. Apigee Edge와 백엔드 서버 간의 원활한 트래픽 흐름을 보장하려면 메시지 프로세서 IP와 관련된 모든 네트워크 계층의 제한을 삭제하는 것이 중요합니다.

방화벽 제한이 없거나 문제가 계속되면 진단 정보 수집 필요로 이동합니다.

진단 정보 수집 필요

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

Public Cloud 사용자인 경우 다음 정보를 제공합니다.
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 패킷
이 플레이북에서 시도한 섹션에 대한 세부정보 및 이 문제의 해결을 신속하게 처리하는 데 도움이 되는 기타 통찰력