Apigee Edge 문서입니다.
Go to the
Apigee X 문서로 이동합니다. info
증상
클라이언트 애플리케이션에서 API 요청에 대한 제한 시간 오류가 발생하거나 API 요청이 Apigee에서 계속 실행되는 동안 요청이 갑자기 종료됩니다.
API 모니터링 및
NGINX 액세스 로그에서 이러한 API 요청의 상태 코드 499를 확인할 수 있습니다. API 분석에서는 메시지 프로세서에서 반환된 상태 코드를 표시하므로 다른 상태 코드가 표시될 수 있습니다.
오류 메시지
클라이언트 애플리케이션에 다음과 같은 오류가 표시될 수 있습니다.
curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received
클라이언트 제한 시간이 발생하는 원인은 무엇인가요?
Edge 플랫폼의 API 요청의 일반적인 경로는 다음 그림과 같이 클라이언트 > 라우터 > 메시지 프로세서 > 백엔드 서버 입니다.

Apigee Edge 플랫폼 내의 라우터 및 메시지 프로세서는 API 요청이 완료되는 데 너무 오래 걸리지 않도록 적절한 기본 제한 시간 값으로 설정됩니다.
클라이언트 제한 시간
클라이언트 애플리케이션은 필요에 따라 적절한 제한 시간 값으로 구성할 수 있습니다.
웹브라우저 및 모바일 앱과 같은 클라이언트에는 운영체제에서 정의한 제한 시간이 있습니다.
라우터 제한 시간
라우터에 구성된 기본 제한 시간은 57초입니다. 이는 API 요청이 Edge에서 수신된 시간부터 백엔드 응답 및 실행되는 모든 정책을 포함하여 응답이 다시 전송될 때까지 API 프록시가 실행될 수 있는 최대 시간입니다. 기본 제한 시간은 라우터에서 I/O 제한 시간 구성에 설명된 대로 라우터 및 가상 호스트에서 재정의할 수 있습니다.
메시지 프로세서 제한 시간
메시지 프로세서에 구성된 기본 제한 시간은 55초입니다. 이는 백엔드 서버가 요청을 처리하고 메시지 프로세서에 다시 응답하는 데 걸릴 수 있는 최대 시간입니다. 기본 제한 시간은 메시지 프로세서에서 I/O 제한 시간 구성에 설명된 대로 메시지 프로세서 또는 API 프록시 내에서 재정의할 수 있습니다.
API 프록시가 제한 시간 초과되기 전에 클라이언트가 라우터와의 연결을 닫으면
특정 API 요청에 대한 제한 시간 오류가 표시됩니다. 상태 코드 499 Client
Closed Connection은 이러한 요청에 대해 라우터에 로깅되며 API
모니터링 및 NGINX 액세스 로그에서 확인할 수 있습니다.
가능한 원인
Edge에서 499 Client Closed Connection 오류의 일반적인 원인은 다음과 같습니다.
| 원인 | 설명 | 다음에 관한 문제 해결 안내 |
|---|---|---|
| 클라이언트가 연결을 갑자기 닫음 | 이 오류는 최종 사용자가 요청이 완료되기 전에 요청을 취소하여 클라이언트가 연결을 닫을 때 발생합니다. | Public 및 Private Cloud 사용자 |
| 클라이언트 애플리케이션 제한 시간 | 이 오류는 API 프록시가 응답을 처리하고 전송할 시간이 있기 전에 클라이언트 애플리케이션이 제한 시간 초과될 때 발생합니다. 일반적으로 클라이언트 제한 시간이 라우터 제한 시간보다 짧을 때 발생합니다. | Public 및 Private Cloud 사용자 |
일반적인 진단 단계
다음 도구/기법 중 하나를 사용하여 이 오류를 진단합니다.
- API 모니터링
- NGINX 액세스 로그
API 모니터링
API 모니터링을 사용하여 오류를 진단하려면 다음 단계를 따르세요.
- 분석 > API 모니터링 > 조사 페이지로 이동합니다.
4xx오류를 필터링하고 기간을 선택합니다.- 시간 에 대해 상태 코드 를 표시합니다.
- 아래와 같이
499오류가 있는 셀을 선택합니다.
- 아래와 같이 오른쪽 창에
499오류에 대한 정보가 표시됩니다.
- 오른쪽 창에서 로그 보기 를 클릭합니다.

트래픽 로그 창에서 일부
499오류에 대한 다음 세부정보를 기록해 둡니다.- 요청:호출을 만드는 데 사용되는 요청 메서드 및 URI를 제공합니다.
- 응답 시간:요청에 경과된 총 시간을 제공합니다.
API 모니터링 GET 로그 API를 사용하여 모든 로그를 가져올 수도 있습니다. 예를 들어
org,env,timeRange,status에 대한 로그를 쿼리하면 클라이언트가 제한 시간 초과된 트랜잭션의 모든 로그를 다운로드할 수 있습니다.API 모니터링은 HTTP
499오류에 대해 프록시를-로 설정하므로 API (로그 API)를 사용하여 가상 호스트 및 경로의 연결된 프록시를 가져올 수 있습니다.예를 들면 다음과 같습니다.
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
- 추가
499오류의 응답 시간 을 검토하고 모든499오류에서 응답 시간 이 일관적인지 (예: 30초) 확인합니다.
NGINX 액세스 로그
NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 단계를 따르세요.
- Private Cloud 사용자라면 NGINX 액세스 로그를 사용하여 HTTP
499오류에 대한 주요 정보를 확인할 수 있습니다. - NGINX 액세스 로그를 확인합니다.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log - 특정 기간 동안
499오류가 있는지(문제가 과거에 발생한 경우) 또는499로 인해 여전히 실패하는 요청이 있는지 검색합니다. - 일부
499오류에 대한 다음 정보를 기록해 둡니다.- 총 응답 시간
- 요청 URI
- 사용자 에이전트
NGINX 액세스 로그의 샘플 499 오류
2019-08-23T06:50:07+00:00 rrt-03f69eb1091c4a886-c-sy 50.112.119.65:47756 10.10.53.154:8443 10.001 - - 499 - 422 0 GET /v1/products HTTP/1.1 - okhttp/3.9.1 api.acme.org rrt-03f69eb1091c4a886-c-sy-13001-6496714-1 50.112.119.65 - - - - - - - -1 - - dc-1 router-pod-1 rt-214-190301-0020137-latest-7d 36 TLSv1.2 gateway-1 dc-1 acme prod https -
이 예에서는 다음 정보가 표시됩니다.
- 총 응답 시간:
10.001초. 이는 클라이언트가 제한 시간 초과되었음을 나타냅니다. - 요청:
GET /v1/products - 호스트:
api.acme.org - 사용자 에이전트:
okhttp/3.9.1
- 모든
499오류에서 총 응답 시간 및 사용자 에이전트 가 일관적인지 확인합니다.
원인: 클라이언트가 연결을 갑자기 닫음
진단
- 브라우저 또는 모바일 애플리케이션에서 실행되는 단일 페이지 앱에서 API가 호출되면 최종 사용자가 브라우저를 갑자기 닫거나, 동일한 탭에서 다른 웹페이지로 이동하거나, 로드 중지를 클릭하거나 탭하여 페이지 로드를 중지하면 브라우저가 요청을 중단합니다.
- 이 경우 HTTP
499상태의 트랜잭션은 일반적으로 각 요청의 요청 처리 시간 (응답 시간)이 다릅니다. -
일반적인 진단 단계에 설명된 대로 API 모니터링 또는 NGINX 액세스 로그를 사용하여 응답 시간 을 비교하고 각
499오류에 대해 다른지 확인하여 원인을 확인할 수 있습니다.
해상도
- HTTP
499오류가 소량으로 발생하는 경우 이는 정상이며 일반적으로 우려할 만한 원인이 아닙니다. -
동일한 URL 경로에 대해 자주 발생하는 경우 해당 경로와 연결된 특정 프록시 가 매우 느리고 사용자가 기다리지 않기 때문일 수 있습니다.
영향을 받을 수 있는 프록시를 파악한 후 지연 시간 분석 대시보드를 사용하여 프록시 지연 시간의 원인을 추가로 조사합니다.
- 이 경우 일반적인 진단 단계의 단계를 사용하여 영향을 받는 프록시를 확인합니다.
- 지연 시간 분석 대시보드를 사용하여 프록시 지연 시간의 원인을 추가로 조사하고 문제를 해결합니다.
- 특정 프록시에 예상되는 지연 시간인 경우 사용자에게 이 프록시가 응답하는 데 시간이 걸린다고 알려야 할 수 있습니다.
원인: 클라이언트 애플리케이션 제한 시간
이 오류는 여러 시나리오에서 발생할 수 있습니다.
-
정상적인 작동 조건에서 요청이 완료되는 데 특정 시간 (예: 10초)이 걸릴 것으로 예상됩니다. 그러나 클라이언트 애플리케이션은 잘못된
제한 시간 값 (예: 5초)으로 설정되어 API 요청이 완료되기 전에
클라이언트 애플리케이션이 제한 시간 초과되어
499가 발생합니다. 이 경우 클라이언트 제한 시간을 적절한 값으로 설정해야 합니다. - 대상 서버 또는 콜아웃이 예상보다 오래 걸립니다. 이 경우 적절한 구성요소를 수정하고 제한 시간 값을 적절하게 조정해야 합니다.
- 클라이언트가 더 이상 응답이 필요하지 않아 중단되었습니다. 이는 자동 완성 또는 짧은 폴링과 같은 고빈도 API에서 발생할 수 있습니다.
진단
API 모니터링 또는 NGINX 액세스 로그
API 모니터링 또는 NGINX 액세스 로그를 사용하여 오류를 진단합니다.
-
일반적인 진단 단계에 설명된 대로 API 모니터링 로그 또는 NGINX 액세스 로그에서 HTTP
499트랜잭션을 확인합니다. - 모든
499오류에서 응답 시간 이 일관적인지 확인합니다. - 일관적이라면 특정 클라이언트 애플리케이션이 자체적으로 고정된 제한 시간을 구성했을 수 있습니다. API 프록시 또는 대상 서버가 느리게 응답하는 경우 프록시가 제한 시간 초과되기 전에 클라이언트가 제한 시간 초과되어 동일한 URI 경로에 대해 많은 양의 HTTP
499s가 발생합니다. 이 경우 NGINX 액세스 로그에서 특정 클라이언트 애플리케이션을 확인하는 데 도움이 되는 사용자 에이전트 를 확인합니다. - Akamai, F5, AWS ELB 등과 같은 Apigee 앞에 부하 분산기가 있을 수도 있습니다. Apigee가 커스텀 부하 분산기 뒤에서 실행되는 경우 부하 분산기의 요청 제한 시간은 Apigee API 제한 시간보다 크게 구성해야 합니다. 기본적으로 Apiggee 라우터는 57초 후에 제한 시간 초과되므로 부하 분산기에서 60초의 요청 제한 시간을 구성하는 것이 적합합니다.
Trace
Trace를 사용하여 오류를 진단합니다.
문제가 여전히 활성 상태인 경우 (499 오류가 계속 발생함) 다음 단계를 수행합니다.
- Edge UI에서 영향을 받는 API의 trace 세션 을 사용 설정합니다.
- 오류가 발생할 때까지 기다리거나 API 호출이 있는 경우 일부 API 호출을 실행하고 오류를 재현합니다.
- 각 단계에서 경과된 시간을 확인하고 대부분의 시간이 소요되는 단계를 기록해 둡니다.
- 다음 단계 중 하나 직후에 가장 긴 경과 시간이 있는 오류가 관찰되면 백엔드 서버가 느리거나 요청을 처리하는 데 시간이 오래 걸린다는 의미입니다:
- 대상 서버로 전송된 요청
- ServiceCallout 정책
다음은 요청 이 대상 서버로 전송된 후 게이트웨이 제한 시간 을 보여주는 샘플 UI trace입니다.

해상도
- Apigee Edge를 통한 API 요청 흐름에 관련된 다양한 구성요소에 설정해야 하는 제한 시간 값을 이해하려면 I/O 제한 시간 구성 권장사항을 참조하세요.
- 권장사항에 따라 클라이언트 애플리케이션에 적절한 제한 시간 값을 설정해야 합니다.
문제가 계속되면 진단 정보를 수집해야 함으로 이동합니다 .
진단 정보 수집 필요
문제가 계속되면 다음 진단 정보를 수집한 후 Apigee Edge 지원팀에 문의하세요.
Public Cloud 사용자라면 다음 정보를 제공하세요.
- 조직 이름
- 환경 이름
- API 프록시 이름
- 제한 시간 오류를 재현하는 데 사용되는 전체
curl명령어 - 클라이언트 제한 시간 오류가 표시되는 API 요청의 trace 파일
Private Cloud 사용자라면 다음 정보를 제공하세요.
- 실패한 요청에 대해 관찰된 전체 오류 메시지
- 환경 이름
- API 프록시 번들
- 클라이언트 제한 시간 오류가 표시되는 API 요청의 trace 파일
- NGINX 액세스 로그 (
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log) - 메시지 프로세서 시스템 로그 (
/opt/apigee/var/log/edge-message-processor/logs/system.log)