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

502 잘못된 게이트웨이 예기치 않은 EOF

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

증상

클라이언트 애플리케이션은 API 호출에 대한 응답으로 Bad Gateway 메시지와 함께 HTTP 상태 코드 502를 가져옵니다.

HTTP 상태 코드 502는 클라이언트가 실제로 요청을 처리해야 하는 백엔드 서버로부터 유효한 응답을 받지 못하고 있음을 의미합니다.

오류 메시지

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

가능한 원인

502 Bad Gateway Error의 일반적인 원인 중 하나는 다음과 같은 이유로 발생할 수 있는 Unexpected EOF 오류입니다.

원인	세부정보	다음에 주어진 걸음 수
잘못 구성된 대상 서버	TLS/SSL 연결을 지원하도록 대상 서버가 올바르게 구성되지 않았습니다.	Edge 퍼블릭 및 프라이빗 클라우드 사용자
백엔드 서버에서 EOFException 발생	백엔드 서버에서 갑자기 EOF를 전송할 수 있습니다.	Edge Private Cloud 사용자만
연결 유지 제한 시간이 잘못 구성됨	Apigee 및 백엔드 서버에서 연결 유지 제한 시간이 잘못 구성되었습니다.	Edge 퍼블릭 및 프라이빗 클라우드 사용자

일반적인 진단 단계

오류를 진단하려면 다음 방법 중 하나를 사용하면 됩니다.

API 모니터링
추적 도구
NGINX 액세스 로그

API 모니터링

API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.

문제 조사에 설명된 단계에 따라 API Monitoring을 사용하여 502 오류를 조사할 수 있습니다. 이는 다음과 같은 의미입니다.

조사 대시보드로 이동합니다.
드롭다운 메뉴에서 상태 코드 를 선택하고 502 오류가 발생했을 때 올바른 기간이 선택되었는지 확인합니다.
많은 수의 502 오류가 표시되면 매트릭스의 상자를 클릭합니다.
오른쪽에서 다음과 비슷한 502 오류에 대해 로그 보기를 클릭합니다.

여기에서 다음과 같은 정보를 확인할 수 있습니다.

결함 소스: target
오류 코드는 messaging.adaptors.http.UnexpectedEOFAtTarget입니다.

예상치 못한 EOF로 인해 타겟에서 502 오류가 발생했음을 나타냅니다.

또한 추가 조사를 위해 502 오류의 Request Message ID를 기록해 둡니다.

추적 도구

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

트레이스 세션을 사용 설정하고 API를 호출하여 502 Bad Gateway 문제를 재현합니다.
실패한 요청 중 하나를 선택하고 트레이스를 검사합니다.
trace의 다양한 단계를 살펴보고 실패가 발생한 위치를 찾습니다.
아래와 같이 요청이 대상 서버로 전송된 후 실패가 표시됩니다.
trace의 AX (애널리틱스 데이터 기록) 단계에서 X-Apigee.fault-source 및 X-Apigee.fault-code의 값을 결정합니다.

X-Apigee.fault-source 및 X-Apigee.fault-code의 값이 다음 표에 표시된 값과 일치하면 502 오류가 대상 서버에서 발생한 것임을 확인할 수 있습니다.

응답 헤더 값

X-Apigee.fault-source target

X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget

또한 추가 조사를 위해 502 오류의 X-Apigee.Message-ID를 기록해 둡니다.

응답 헤더	값
X-Apigee.fault-source	`target`
X-Apigee.fault-code	`messaging.adaptors.http.flow.UnexpectedEOFAtTarget`

NGINX 액세스 로그

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

NGINX 액세스 로그를 참조하여 502 상태 코드의 원인을 확인할 수도 있습니다. 이 방법은 과거에 문제가 발생한 적이 있거나 문제가 간헐적으로 발생하고 UI에서 트레이스를 캡처할 수 없는 경우에 특히 유용합니다. NGINX 액세스 로그에서 이 정보를 확인하려면 다음 단계를 따르세요.

NGINX 액세스 로그를 확인합니다.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
특정 기간(과거에 문제가 발생한 경우) 동안 특정 API 프록시에 발생한 502 오류를 검색하거나 502와 함께 여전히 실패하는 요청이 있는지 검색합니다.
502 오류가 있으면 Unexpected EOF을 전송하는 타겟으로 인해 오류가 발생했는지 확인합니다. X-Apigee.fault-source 및 X- Apigee.fault-code의 값이 아래 표에 표시된 값과 일치하면 대상의 연결이 예기치 않게 닫혀 502 오류가 발생합니다.

응답 헤더 값

X-Apigee.fault-source target

X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget

다음은 대상 서버로 인해 발생한 502 오류를 보여주는 샘플 항목입니다.

응답 헤더	값
X-Apigee.fault-source	`target`
X-Apigee.fault-code	`messaging.adaptors.http.flow.UnexpectedEOFAtTarget`

또한 추가 조사를 위해 502 오류의 메시지 ID를 기록해 둡니다.

원인: 대상 서버가 잘못 구성됨

TLS/SSL 연결을 지원하도록 대상 서버가 올바르게 구성되지 않았습니다.

진단

API Monitoring, Trace 도구 또는 NGINX 액세스 로그를 사용하여 502 오류의 메시지 ID, 오류 코드, 오류 소스를 확인합니다.
UI에서 영향을 받은 API에 트레이스를 사용 설정합니다.
실패한 API 요청의 트레이스에 다음이 표시되는 경우:
1. 502 Bad Gateway 오류는 대상 흐름 요청이 시작되는 즉시 표시됩니다.
2. error.class는 messaging.adaptors.http.UnexpectedEOF.를 표시합니다.
  그렇다면 이 문제는 잘못된 대상 서버 구성으로 인해 발생할 가능성이 매우 높습니다.

에지 관리 API 호출을 사용하여 대상 서버 정의를 가져옵니다.

퍼블릭 클라우드 사용자인 경우 다음 API를 사용합니다.

curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

Private Cloud 사용자인 경우 다음 API를 사용합니다.

curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

잘못된 TargetServer 정의 샘플:

<TargetServer  name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

그림으로 표시된 TargetServer 정의는 다음과 같이 설명된 일반적인 구성 오류 중 하나의 예입니다.

대상 서버 mocktarget.apigee.net가 포트 443에서 보안 (HTTPS) 연결을 수락하도록 구성되어 있다고 가정해 보겠습니다. 그러나 대상 서버 정의를 살펴보면 이 정의가 보안 연결을 위한 것임을 나타내는 다른 속성/플래그는 없습니다. 이렇게 하면 Edge가 특정 대상 서버로 이동하는 API 요청을 HTTP (비보안) 요청으로 처리합니다. 따라서 Edge는 이 대상 서버에서 SSL 핸드셰이크 프로세스를 시작하지 않습니다.

대상 서버가 443에서 HTTPS (SSL) 요청만 수락하도록 구성되어 있으므로 Edge의 요청을 거부하거나 연결을 종료합니다. 따라서 메시지 프로세서에 UnexpectedEOFAtTarget 오류가 발생합니다. 메시지 프로세서는 클라이언트에 대한 응답으로 502 Bad Gateway를 전송합니다.

해상도

대상 서버가 요구사항에 따라 올바르게 구성되었는지 항상 확인합니다.

위에 설명된 예시에서 보안 (HTTPS/SSL) 대상 서버에 요청하려면 enabled 플래그가 true로 설정된 SSLInfo 속성을 포함해야 합니다. 대상 엔드포인트 정의 자체에 대상 서버의 SSLInfo 속성을 추가할 수 있지만 대상 서버 정의의 일부로 SSLInfo 속성을 추가하여 혼동을 피하는 것이 좋습니다.

백엔드 서비스에 단방향 SSL 통신이 필요한 경우 다음을 충족해야 합니다.

아래와 같이 enabled 플래그가 true로 설정된 SSLInfo 속성을 포함하여 TargetServer 정의에 TLS/SSL을 사용 설정해야 합니다.

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>

Edge에서 대상 서버 인증서의 유효성을 검사하려면 아래와 같이 대상 서버의 인증서가 포함된 트러스트 저장소도 포함해야 합니다.

<TargetServer  name="mocktarget">
    <Host>mocktarget.apigee.net</Host>
    <Port>443</Port>
    <IsEnabled>true</IsEnabled>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <Protocols/>
        <TrustStore>mocktarget-truststore</TrustStore>
    </SSLInfo>
</TargetServer>

백엔드 서비스에 양방향 SSL 통신이 필요한 경우 다음을 충족해야 합니다.

아래와 같이 ClientAuthEnabled, Keystore, KeyAlias, Truststore 플래그가 적절하게 설정된 SSLInfo 속성이 있어야 합니다.

<TargetServer  name="mocktarget">
     <IsEnabled>true</IsEnabled>
     <Host>www.example.com</Host>
     <Port>443</Port>
     <SSLInfo>
         <Ciphers/>
         <ClientAuthEnabled>true</ClientAuthEnabled>
         <Enabled>true</Enabled>
         <IgnoreValidationErrors>false</IgnoreValidationErrors>
         <KeyAlias>keystore-alias</KeyAlias>
         <KeyStore>keystore-name</KeyStore>
         <Protocols/>
         <TrustStore>truststore-name</TrustStore>
     </SSLInfo>
  </TargetServer >

참조

백엔드 서버 간 부하 분산

원인: 백엔드 서버에서 EOFException 발생

백엔드 서버에서 갑자기 EOF (파일 끝)를 전송할 수 있습니다.

진단

API Monitoring, Trace 도구 또는 NGINX 액세스 로그를 사용하여 502 오류의 메시지 ID, 오류 코드, 오류 소스를 확인합니다.
메시지 프로세서 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log)를 검색하여 특정 API에 eof unexpected가 있는지 또는 API 요청에 고유한 messageid가 있는지 검색하면 검색할 수 있습니다.
메시지 프로세서 로그의 예외 스택 트레이스 샘플
```
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
java.io.EOFException: eof unexpected
at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
```
위의 예시에서는 메시지 프로세서가 백엔드 서버의 응답을 읽으려고 시도하는 동안 java.io.EOFException: eof unexpected 오류가 발생한 것을 확인할 수 있습니다. 이 예외는 파일 끝 (EOF) 또는 예기치 않게 스트림 끝에 도달했음을 나타냅니다.

즉, 메시지 프로세서가 API 요청을 백엔드 서버로 전송하고 응답을 대기 중이거나 읽고 있었습니다. 그러나 메시지 프로세서가 응답을 받거나 전체 응답을 읽기 전에 백엔드 서버가 갑자기 연결을 종료했습니다.
백엔드 서버 로그를 확인하고 백엔드 서버에서 갑자기 연결을 종료하게 만들 수 있는 오류나 정보가 있는지 확인합니다. 오류/정보를 발견하면 해결 방법으로 이동하여 백엔드 서버에서 문제를 적절하게 해결합니다.
백엔드 서버에서 오류나 정보가 발견되지 않으면 메시지 프로세서의 tcpdump 출력을 수집합니다.
1. 백엔드 서버 호스트에 단일 IP 주소가 있는 경우 다음 명령어를 사용합니다.
```
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
```
2. 백엔드 서버 호스트에 여러 IP 주소가 있는 경우 다음 명령어를 사용합니다.
```
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
```
  참고: 메시지 프로세서에서 이 명령어를 실행하는 경우 백엔드 서버의 IP 주소와 호스트 이름을 사용합니다. 백엔드 서버에서 tcpdump를 사용할 수도 있습니다. 백엔드 서버에서 명령어를 실행하는 경우에는 위의 tcpdump 명령어에 메시지 프로세서의 IP 주소를 사용합니다.
  
  일반적으로 이 오류는 메시지 프로세서가 백엔드 서버로 요청을 전송하는 즉시 백엔드 서버가 [FIN,ACK]로 다시 응답하기 때문에 발생합니다.
다음 tcpdump 예를 살펴보세요.

502 Bad Gateway Error (UnexpectedEOFAtTarget)이 발생했을 때 가져온 샘플 tcpdump
TCPDump 출력에서 다음과 같은 순서의 이벤트를 확인할 수 있습니다.
1. 985 패킷에서 메시지 프로세서는 API 요청을 백엔드 서버로 보냅니다.
2. 986 패킷에서 백엔드 서버는 즉시 [FIN,ACK]로 응답합니다.
3. 987 패킷에서 메시지 프로세서는 백엔드 서버에 대해 [FIN,ACK]로 응답합니다.
4. 결국 연결은 양쪽에서 [ACK] 및 [RST]로 닫힙니다.
5. 백엔드 서버가 [FIN,ACK]를 전송하므로 메시지 프로세서에 예외 java.io.EOFException: eof unexpected 예외가 발생합니다.
이 오류는 백엔드 서버에 네트워크 문제가 있는 경우에 발생할 수 있습니다. 네트워크 운영팀에 연락하여 이 문제를 자세히 조사하세요.

해상도

백엔드 서버에서 문제를 적절하게 수정합니다.

문제가 지속되고 502 Bad Gateway Error 문제 해결에 도움이 필요하거나 Edge 내의 문제로 의심되는 경우 Apigee Edge 지원팀에 문의하세요.

원인: 연결 유지 제한 시간이 잘못 구성되었습니다.

이것이 502 오류의 원인인지 진단하기 전에 다음 개념을 읽어보세요.

Apigee의 영구 연결

Apigee는 대상 백엔드 서버와 통신할 때 기본적으로 (HTTP/1.1 표준에 따라) 영구 연결을 사용합니다. 영구 연결을 사용하면 이미 설정된 TCP 및 TLS/SSL 연결 (해당하는 경우)을 다시 사용할 수 있어 성능이 향상되어 지연 시간 오버헤드가 줄어듭니다. 연결을 유지해야 하는 기간은 속성 연결 유지 제한 시간 (keepalive.timeout.millis)을 통해 제어됩니다.

백엔드 서버와 Apigee 메시지 프로세서 모두 연결 유지 제한 시간을 사용하여 서로 열려 있는 연결을 유지합니다. 연결 유지 제한 시간 내에 수신된 데이터가 없으면 백엔드 서버 또는 메시지 프로세서와의 연결을 종료할 수 있습니다.

Apigee의 메시지 프로세서에 배포된 API 프록시는 재정의하지 않는 한 기본적으로 연결 유지 제한 시간을 60s로 설정합니다. 60s에 대한 데이터가 수신되지 않으면 Apigee가 백엔드 서버와의 연결을 종료합니다. 또한 백엔드 서버는 연결 유지 제한 시간을 유지하며, 이 제한 시간이 만료되면 백엔드 서버가 메시지 프로세서와의 연결을 종료합니다.

잘못된 연결 유지 제한 시간 구성의 영향

Apigee 또는 백엔드 서버가 잘못된 연결 유지 제한 시간으로 구성된 경우 경합 상태가 발생하여 백엔드 서버가 리소스 요청에 대한 응답으로 예기치 않은 End Of File (FIN)를 전송하게 됩니다.

예를 들어 API 프록시 또는 메시지 프로세서 내에서 연결 유지 제한 시간이 업스트림 백엔드 서버의 제한 시간보다 크거나 같은 값으로 구성된 경우 다음과 같은 경합 상태가 발생할 수 있습니다. 즉, 메시지 프로세서가 백엔드 서버 연결 유지 제한 시간의 임계값에 매우 가까워질 때까지 데이터를 수신하지 않으면 요청이 통과되고 기존 연결을 사용하여 백엔드 서버로 전송됩니다. 이로 인해 아래 설명과 같이 예상치 못한 EOF 오류로 인해 502 Bad Gateway가 발생할 수 있습니다.

메시지 프로세서와 백엔드 서버에 설정된 연결 유지 제한 시간이 60초이고, 특정 메시지 프로세서가 이전 요청을 처리한 후 59초가 지나기 전에는 새로운 요청이 발생하지 않았다고 가정해 보겠습니다.
메시지 프로세서는 계속해서 기존 연결을 사용하여 59초에 수신된 요청을 처리하고 (연결 유지 제한 시간이 아직 경과되지 않았으므로) 요청을 백엔드 서버로 전송합니다.
하지만 요청이 백엔드 서버에 도착하기 전에 백엔드 서버에서 연결 유지 제한 시간 임계값을 초과했습니다.
메시지 프로세서의 리소스 요청이 진행 중이지만 백엔드 서버가 FIN 패킷을 메시지 프로세서에 전송하여 연결을 종료하려고 합니다.
메시지 프로세서가 데이터가 수신되기를 기다리는 동안 예기치 않은 FIN를 수신하고 연결이 종료됩니다.
그 결과 Unexpected EOF가 발생하고 이후 메시지 프로세서에서 502가 클라이언트에 반환됩니다.

이 경우 메시지 프로세서와 백엔드 서버 모두에서 동일한 연결 유지 제한 시간 값 60초가 구성되었기 때문에 502 오류가 발생했습니다. 마찬가지로, 메시지 프로세서의 연결 유지 제한 시간 값이 백엔드 서버보다 높게 구성된 경우에도 이 문제가 발생할 수 있습니다.

진단

Public Cloud 사용자인 경우:
1. 일반적인 진단 단계에 설명된 대로 API Monitoring 또는 Trace 도구를 사용하여 다음 설정이 모두 있는지 확인합니다.
  - 오류 코드: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
  - 결함 소스: target
2. 자세한 내용은 tcpdump 사용을 참고하세요.
Private Cloud 사용자인 경우:
1. Trace 도구 또는 NGINX 액세스 로그를 사용하여 502 오류의 메시지 ID, 오류 코드, 오류 소스를 확인합니다.
2. 메시지 프로세서 로그
  (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.
3. 아래와 같이 java.io.EOFEXception: eof unexpected가 표시됩니다.
```
2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
        java.io.EOFException: eof unexpected
        at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
        at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
        at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
        at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
        at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
```
4. java.io.EOFException: eof unexpected 오류는 메시지 프로세서가 백엔드 서버의 응답을 읽기 위해 대기하는 동안 EOF을 수신했음을 나타냅니다.
5. 위의 오류 메시지에서 useCount=7 속성은 메시지 프로세서가 이 연결을 약 7번 재사용했음을 나타내고 bytesWritten=159 속성은 메시지 프로세서가 159바이트의 요청 페이로드를 백엔드 서버로 전송했음을 나타냅니다. 하지만 예기치 않은 EOF가 발생했을 때 0바이트를 다시 수신했습니다.
6. 이는 메시지 프로세서가 동일한 연결을 여러 번 재사용했으며, 이 경우 데이터를 전송했지만 얼마 지나지 않아 데이터를 수신하기 전에 EOF을 수신했음을 나타냅니다. 즉, 백엔드 서버의 연결 유지 제한 시간이 API 프록시의 제한 시간보다 짧거나 같을 가능성이 높습니다.
  
  아래에 설명된 대로 tcpdump를 사용하여 더 자세히 조사할 수 있습니다.

tcpdump 사용

다음 명령어를 사용하여 백엔드 서버에서 tcpdump을 캡처합니다.
```
tcpdump -i any -s 0 host MP_IP_Address -w File_Name
```
캡처된 tcpdump를 분석합니다.
다음은 tcpdump 출력 샘플입니다.

위의 tcpdump 샘플에서는 다음을 확인할 수 있습니다.
1. 5992, 패킷에서 백엔드 서버가 GET 요청을 수신했습니다.
2. 6064 패킷에서 200 OK.로 응답합니다.
3. 6084 패킷에서 백엔드 서버가 다른 GET 요청을 수신했습니다.
4. 6154 패킷에서는 200 OK로 응답합니다.
5. 6228 패킷에서 백엔드 서버가 세 번째 GET 요청을 수신했습니다.
6. 이번에는 백엔드 서버가 연결 종료를 시작하는 FIN, ACK를 메시지 프로세서(패킷 6285)에 반환합니다.
이 예에서는 동일한 연결이 두 번 성공적으로 재사용되었지만, 세 번째 요청에서는 메시지 프로세서가 백엔드 서버의 데이터를 기다리는 동안 백엔드 서버가 연결 종료를 시작합니다. 따라서 백엔드 서버의 연결 유지 제한 시간이 API 프록시에 설정된 값보다 짧거나 같을 가능성이 큽니다. 이를 검증하려면 Apigee와 백엔드 서버의 연결 유지 제한 시간 비교를 참조하세요.

Apigee 및 백엔드 서버의 연결 유지 제한 시간 비교

기본적으로 Apigee는 연결 유지 제한 시간 속성에 60초 값을 사용합니다.
하지만 API 프록시에서 기본값을 재정의했을 수도 있습니다. 실패한 API 프록시에서 502 오류를 발생시키는 특정 TargetEndpoint 정의를 확인하여 이를 확인할 수 있습니다.

샘플 TargetEndpoint 구성:
```
<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>https://mocktarget.apigee.net/json</URL>
    <Properties>
      <Property name="keepalive.timeout.millis">30000</Property>
    </Properties>
  </HTTPTargetConnection>
</TargetEndpoint>
```
위의 예에서 연결 유지 제한 시간 속성은 30초 (30000밀리초) 값으로 재정의됩니다.
그런 다음 백엔드 서버에 구성된 연결 유지 제한 시간 속성을 확인합니다. 백엔드 서버가 25 seconds 값으로 구성되었다고 가정해 보겠습니다.
Apigee의 연결 유지 제한 시간 속성 값이 위 예시와 같이 백엔드 서버의 연결 유지 제한 시간 속성 값보다 크다고 확인되면 502 오류가 발생한 것입니다.

해상도

Apigee (API 프록시 및 메시지 프로세서 구성요소)의 연결 유지 제한 시간 속성이 백엔드 서버의 값보다 항상 더 낮아야 합니다.

백엔드 서버에 설정된 연결 유지 제한 시간 값을 결정합니다.
메시지 프로세서에서 연결 유지 제한 시간 구성에 설명된 단계에 따라 API 프록시 또는 메시지 프로세서의 연결 유지 제한 시간 속성이 백엔드 서버에 설정된 값보다 낮도록 API 프록시 또는 메시지 프로세서의 연결 유지 제한 시간 속성에 적절한 값을 구성합니다.

문제가 계속되면 진단 정보를 수집해야 함으로 이동합니다.

권장사항

다운스트림 구성요소의 경우 이러한 종류의 경합 상태 및 502 오류를 방지하기 위해 항상 업스트림 서버에 구성된 연결 유지 제한 시간 임곗값을 낮게 설정하는 것이 좋습니다. 각 다운스트림 홉은 각 업스트림 홉보다 낮아야 합니다. Apigee Edge에서는 다음 가이드라인을 따르는 것이 좋습니다.

클라이언트 연결 유지 제한 시간은 에지 라우터 연결 유지 제한 시간보다 짧아야 합니다.
에지 라우터의 연결 유지 제한 시간은 메시지 프로세서의 연결 유지 제한 시간보다 짧아야 합니다.
메시지 프로세서 연결 유지 제한 시간은 대상 서버의 연결 유지 제한 시간보다 짧아야 합니다.
Apigee 앞이나 뒤에 다른 홉이 있는 경우 같은 규칙을 적용해야 합니다. 항상 업스트림과의 연결을 닫는 것을 다운스트림 클라이언트의 책임으로 두어야 합니다.

진단 정보 수집 필요

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

Public Cloud 사용자인 경우 다음 정보를 제공합니다.

조직 이름
환경 이름
API 프록시 이름
curl 명령어를 완료하여 502 오류를 재현합니다.
502 Bad Gateway - Unexpected EOF 오류가 있는 요청이 포함된 추적 파일
현재 502 오류가 발생하지 않는 경우 이전에 502 오류가 발생했을 때의 시간대 정보를 제공합니다.

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

실패한 요청에 대해 발견된 전체 오류 메시지
502 오류가 관찰된 조직, 환경 이름, API 프록시 이름
API 프록시 번들
502 Bad Gateway - Unexpected EOF 오류가 있는 요청이 포함된 추적 파일
NGINX 액세스 로그
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
메시지 프로세서 로그
/opt/apigee/var/log/edge-message-processor/logs/system.log
502 오류가 발생한 시간대 정보가 포함된 기간
오류 발생 시 메시지 프로세서나 백엔드 서버 또는 둘 다에 수집된 Tcpdumps