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

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

<ph type="x-smartling-placeholder"></ph> 현재 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를 사용하는 경우 아래와 같이 트레이스 출력에서 X-Apigee.Message-ID 필드의 값을 확인합니다. 비공개 클라우드 사용자는 이 ID 값을 사용하여 추가 문제 해결을 수행할 수 있습니다(자세한 내용은 뒷부분 참조).
  1. 트레이스 경로에서 애널리틱스 데이터 기록됨 아이콘을 클릭합니다.
  2. 아래로 스크롤하여 X-Apigee.Message-ID라는 필드의 값을 확인합니다.

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

Edge 프라이빗 클라우드 사용자만을 위한 추가 진단 단계

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방향 TCP 핸드셰이크가 성공적으로 완료된 것을 확인할 수 있습니다.
그러면 메시지 프로세서가 패킷 4에서 'Client 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 핸드셰이크 시간 초과는 백엔드 서버로 연결할 수 있습니다 팔로우한 경우 진단 단계를 실행하고 핸드셰이크 오류의 원인이 네트워크 팀과 협력하여 원인을 파악하고 문제를 해결해야 합니다. 방화벽 제한을 설정합니다

방화벽 제한사항은 여러 네트워크 계층에서 적용될 수 있습니다. 모든 네트워크 계층의 제한 사항이 메시지 프로세서 IP에 연결하여 Apigee Edge 간의 트래픽 흐름을 원활하게 합니다. 백엔드 서버가 포함됩니다

방화벽 제한이 없거나 문제가 계속 발생하는 경우 진단 정보를 수집해야 함.

진단 정보 수집 필요

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

퍼블릭 클라우드 사용자인 경우 다음 정보를 제공하세요. <ph type="x-smartling-placeholder">
1. 조직 이름
2. 환경 이름
3. API 프록시 이름
4. curl 명령어를 완료하여 오류 재현
5. 오류를 보여주는 추적 파일
6. 백엔드 서버에서 캡처된 TCP/IP 패킷
프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요. <ph type="x-smartling-placeholder">
1. 전체 오류 메시지 확인됨
2. API 프록시 번들
3. 오류를 보여주는 트레이스 파일
4. 메시지 프로세서 로그 /opt/apigee/var/log/edge-message-processor/logs/system.log
5. 백엔드 서버 또는 메시지 프로세서에서 캡처된 TCP/IP 패킷
이 플레이북의 어떤 섹션을 시도했는지에 관한 세부정보와 이 문제를 신속하게 해결하는 데 도움이 되는 기타 통계