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

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

Apigee Edge 문서입니다.
Apigee X 문서로 이동 정보

증상

클라이언트 애플리케이션에 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 프라이빗 클라우드 및 퍼블릭 클라우드 안내가 나와 있습니다.

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를 사용하는 경우 아래와 같이 trace 출력의 X-Apigee.Message-ID 필드 값을 기록해 둡니다. 비공개 Cloud 사용자는 이 ID 값을 사용하여 추가 문제 해결을 진행할 수 있습니다(나중에 설명).
  1. trace 경로에서 애널리틱스 데이터 기록됨 아이콘을 클릭합니다.
  2. 아래로 스크롤하여 X-Apigee.Message-ID라는 필드의 값을 확인합니다.

TLS/SSL 핸드셰이크 시간 초과가 오류의 원인인지 확인하려면 공개 클라우드 또는 프라이빗 클라우드 중 어느 쪽을 사용 중이신지에 따라 다음 섹션의 단계를 따르세요.

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

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

문제를 더 정확하게 파악하려면 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개 패킷에서 3방향 TCP 핸드셰이크가 성공적으로 완료된 것을 확인할 수 있습니다.
그런 다음 메시지 프로세서는 패킷 #4에서 "클라이언트 Hello" 메시지를 보냅니다.
백엔드 서버의 확인이 없으므로 메시지 프로세서는 사전 정의된 시간 간격을 기다린 후 패킷 5, 6, 7에서 '클라이언트 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 패킷
프라이빗 클라우드 사용자인 경우 다음 정보를 제공합니다.
1. 전체 오류 메시지 확인됨
2. API 프록시 번들
3. 오류를 보여주는 트레이스 파일
4. 메시지 프로세서 로그 /opt/apigee/var/log/edge-message-processor/logs/system.log
5. 백엔드 서버 또는 메시지 프로세서에서 캡처된 TCP/IP 패킷
이 플레이북의 어떤 섹션을 시도했는지에 관한 세부정보와 이 문제를 빠르게 해결하는 데 도움이 되는 다른 유용한 정보를 확인하세요.