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

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

Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요. info

증상

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

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 Public 및 Private Cloud 사용자
백엔드 서버의 EOFException	백엔드 서버가 갑자기 EOF를 전송할 수 있습니다.	Edge Private Cloud 사용자만 해당
잘못 구성된 연결 유지 제한 시간	Apigee 및 백엔드 서버에 연결 유지 제한 시간이 잘못 구성되었습니다.	Edge Public 및 Private Cloud 사용자

일반적인 진단 단계

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

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

API 모니터링

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

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

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

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

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

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

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

추적 도구

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

트레이스 세션을 사용 설정하고 API 호출을 통해 문제를 재현합니다 502 Bad Gateway.
실패한 요청 중 하나를 선택하고 트레이스를 검사합니다.
트레이스의 다양한 단계를 탐색하고 장애가 발생한 위치를 찾습니다.
아래와 같이 요청이 타겟 서버로 전송된 후 실패가 표시됩니다.
트레이스의 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
특정 기간 동안(문제가 과거에 발생한 경우) 또는 502로 인해 여전히 실패하는 요청에 대해 특정 API 프록시의 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 모니터링, 추적 도구 또는 NGINX 액세스 로그를 사용하여 502 오류의 메시지 ID, 오류 코드, 오류 소스를 확인합니다.
영향을 받는 API의 UI에서 트레이스를 사용 설정합니다.
실패한 API 요청의 트레이스에 다음이 표시되면 다음 단계를 따르세요.
1. 502 Bad Gateway 오류는 타겟 흐름 요청이 시작되자마자 표시됩니다.
2. error.class에 messaging.adaptors.http.UnexpectedEOF.이 표시됩니다.
  이 경우 잘못된 타겟 서버 구성으로 인해 문제가 발생했을 가능성이 매우 높습니다.

Edge 관리 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 모니터링, 추적 도구 또는 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 오류가 발생한 것으로 확인되었습니다. 마찬가지로 메시지 프로세서의 연결 유지 제한 시간이 백엔드 서버의 연결 유지 제한 시간보다 높게 구성된 경우에도 이 문제가 발생할 수 있습니다.

진단

퍼블릭 클라우드 사용자인 경우:
1. API 모니터링 또는 추적 도구 (일반 진단 단계에 설명됨)를 사용하여 다음 설정을 모두 확인합니다.
  - 결함 코드: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
  - 결함 소스: target
2. 추가 조사를 위해 tcpdump 사용으로 이동하세요.
Private Cloud 사용자인 경우:
1. 추적 도구 또는 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 프록시에서 기본값을 재정의했을 수도 있습니다. 502 오류를 발생시키는 실패한 API 프록시에서 특정 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 프록시 또는 메시지 프로세서에서 연결 유지 시간 제한 속성의 적절한 값을 구성합니다.

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

권장사항

이러한 경합 상태와 502 오류를 방지하려면 다운스트림 구성요소의 연결 유지 제한 시간 임곗값이 업스트림 서버에 구성된 값보다 항상 작아야 합니다. 각 다운스트림 홉은 각 업스트림 홉보다 낮아야 합니다. Apigee Edge에서는 다음 가이드라인을 사용하는 것이 좋습니다.

클라이언트 연결 유지 제한 시간은 Edge 라우터 연결 유지 제한 시간보다 짧아야 합니다.
Edge 라우터 활성 상태 유지 시간 제한은 메시지 프로세서 활성 상태 유지 시간 제한보다 작아야 합니다.
메시지 프로세서 연결 유지 시간 제한은 타겟 서버 연결 유지 시간 제한보다 작아야 합니다.
Apigee 앞이나 뒤에 다른 홉이 있는 경우 동일한 규칙을 적용해야 합니다. 항상 다운스트림 클라이언트가 업스트림과의 연결을 닫도록 해야 합니다.

진단 정보 수집 필요

위 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집한 후 Apigee Edge 지원팀에 연락합니다.

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

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

프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요.

실패한 요청에 대해 확인된 전체 오류 메시지
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