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

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

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보

증상

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

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 연결을 지원하도록 올바르게 구성되지 않았습니다.	에지 퍼블릭 및 프라이빗 클라우드 사용자
백엔드 서버에서 EOFException 발생	백엔드 서버에서 EOF를 갑자기 전송할 수 있습니다.	Edge 프라이빗 클라우드 사용자만 해당
연결 유지 제한 시간이 잘못 구성됨	연결 유지 제한 시간이 Apigee 및 백엔드 서버에 잘못 구성되어 있습니다.	에지 퍼블릭 및 프라이빗 클라우드 사용자

일반적인 진단 단계

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

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

API 모니터링

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

API 모니터링을 사용하여 다음을 조사할 수 있습니다. 502 오류를 수정합니다. 문제 조사. 이는 다음과 같은 의미입니다.

조사 대시보드로 이동합니다.
드롭다운 메뉴에서 Status Code 를 선택하고 적절한 시간이 기간 선택: 502 오류 발생 시
502 오류가 많이 표시되면 매트릭스에서 상자를 클릭합니다.
오른쪽에서 502 오류의 로그 보기를 클릭합니다. 다음과 같이 표시됩니다.

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

결함 소스: target
오류 코드: messaging.adaptors.http.UnexpectedEOFAtTarget

이는 예기치 않은 EOF로 인해 타겟으로 인해 502 오류가 발생했음을 나타냅니다.

또한 자세히 알아보려면 502 오류의 Request Message ID를 기록해 두세요. 조사했습니다.

추적 도구

Trace 도구를 사용하여 오류를 진단하는 방법은 다음과 같습니다.

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

X-Apigee.fault-source 및 X-Apigee.fault-code의 값이 값이 표시되면 502 오류가 대상 서버에서 가져옵니다.

응답 헤더 값

X-Apigee.fault-source target

X-Apigee.fault-코드 messaging.adaptors.http.flow.UnexpectedEOFAtTarget

또한 502 오류의 X-Apigee.Message-ID를 기록해 둡니다. 추가 조사를 요청할 수 있습니다.

응답 헤더	값
X-Apigee.fault-source	`target`
X-Apigee.fault-코드	`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-코드 messaging.adaptors.http.flow.UnexpectedEOFAtTarget

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

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

또한 추가 조사를 위해 502 오류의 메시지 ID를 기록해 두세요.

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

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

진단

API 모니터링, Trace 도구를 사용합니다. NGINX 액세스 로그로 메시지 ID 확인 오류 코드, 502 오류의 오류 소스입니다.
UI에서 영향을 받는 API의 trace를 사용 설정합니다.
실패한 API 요청의 trace에 다음이 표시되는 경우 <ph type="x-smartling-placeholder">
1. 502 Bad Gateway 오류는 대상 흐름 요청이 시작되는 즉시 표시됩니다.
2. error.class에는 messaging.adaptors.http.UnexpectedEOF.가 표시됩니다.
  이 문제는 잘못된 대상 서버가 원인일 가능성이 매우 높습니다. 구성할 수 있습니다

Edge 관리 API 호출을 사용하여 대상 서버 정의를 가져옵니다. <ph type="x-smartling-placeholder">

퍼블릭 클라우드 사용자인 경우 다음 API를 사용합니다. <ph type="x-smartling-placeholder">

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

</ph>

Private Cloud 사용자인 경우 다음 API를 사용합니다. <ph type="x-smartling-placeholder">

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

</ph>

잘못된 TargetServer 정의 샘플:

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

그림으로 표시된 TargetServer 정의는 일반적인 구성 오류가 있을 수 있으며 이는 다음과 같습니다.

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

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

해상도

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

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

백엔드 서비스에 단방향 SSL 통신이 필요한 경우 다음을 충족해야 합니다. <ph type="x-smartling-placeholder">

SSLInfo를 포함하여 TargetServer 정의에서 TLS/SSL을 사용 설정해야 합니다. 속성(enabled 플래그가 true로 설정된 경우)

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

Edge에서 대상 서버의 인증서의 유효성을 검사하려면 아래와 같이 truststore (대상 서버의 인증서 포함)를 포함합니다.

<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 통신이 필요한 경우 다음을 충족해야 합니다. <ph type="x-smartling-placeholder">

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

<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 모니터링, Trace 도구를 사용합니다. NGINX 액세스 로그로 메시지 ID 확인 오류 코드, 502 오류의 오류 소스입니다.

메시지 프로세서 로그 확인 (/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 출력을 수집합니다. <ph type="x-smartling-placeholder">
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
```
  참고: Message에서 이 명령어를 실행하는 경우 프로세서: 백엔드 서버의 IP 주소/호스트 이름을 사용합니다. 또한 백엔드 서버에 대한 tcpdump 권한 백엔드 서버에서 명령어를 실행하는 경우 다음을 사용합니다. 위의 tcpdump 명령어에서 메시지 프로세서의 IP 주소입니다.
  
  일반적으로 이 오류는 다음과 같이 백엔드 서버가 다시 응답하기 때문에 발생합니다. [FIN,ACK]는 메시지 프로세서가 백엔드 서버로 요청을 보내는 즉시 시작됩니다.
다음 tcpdump 예를 살펴보세요.

502 Bad Gateway Error (UnexpectedEOFAtTarget)의 샘플 tcpdump 발생
TCPDump 출력에 다음 이벤트 시퀀스가 표시됩니다. <ph type="x-smartling-placeholder">
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이 메시지 프로세서에 의해 클라이언트로 반환됩니다.

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

진단

퍼블릭 클라우드 사용자인 경우: <ph type="x-smartling-placeholder">
1. API 모니터링 또는 Trace 도구 사용( 일반적인 진단 단계 참조) 다음 두 가지 항목이 모두 있는지 확인하세요. 설정: <ph type="x-smartling-placeholder">
  - 오류 코드: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
  - 오류 소스: target
2. 자세한 내용을 보려면 tcpdump 사용으로 이동하세요.
Private Cloud 사용자인 경우: <ph type="x-smartling-placeholder">
1. Trace 도구를 사용하거나 NGINX 액세스 로그: 메시지 ID 확인 오류 코드, 502 오류의 오류 소스입니다.
2. 메시지 프로세서 로그에서 메시지 ID 검색
  (/opt/apigee/var/log/edge-message-processor/logs/system.log).
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바이트의 페이로드를 백엔드 서버로 전송합니다. 그러나 0바이트를 수신함 예기치 않은 EOF가 발생했을 때 복구합니다.
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 프록시에서 기본값을 재정의했을 수도 있습니다. 다음에서 특정 TargetEndpoint 정의를 확인하여 이를 확인할 수 있습니다. 실패 API 프록시로 인해 502 오류가 발생합니다.

샘플 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 프록시에서 연결 유지 제한 시간 속성에 적절한 값을 구성하거나 메시지 프로세서에서 연결 유지 제한 시간 속성이 여기에서 설명한 단계를 사용하여 <ph type="x-smartling-placeholder"></ph> 메시지 프로세서에서 연결 유지 제한 시간 구성

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

권장사항

다운스트림 구성요소의 연결 유지 제한 시간은 항상 더 작은 것이 좋습니다. 더 높은 임곗값을 설정하여 이러한 종류의 경합 상태를 피하고 오류 502개 각 다운스트림 홉은 각 업스트림 홉보다 낮아야 합니다. Apigee 다음 가이드라인을 따르는 것이 좋습니다.

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

진단 정보 수집 필요

위의 안내를 따른 후에도 문제가 지속되면 다음을 수집합니다. Apigee Edge 지원팀에 문의하세요.

퍼블릭 클라우드 사용자인 경우 다음 정보를 입력합니다.

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

Private Cloud 사용자인 경우 다음 정보를 입력합니다.

실패한 요청에 대해 발견된 전체 오류 메시지
관찰 중인 조직, 환경 이름, API 프록시 이름 오류 502개
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 발생함