목차
499
499로 이어지는 클라이언트의 적극적인 행동의 예
499를 유발하는 클라이언트 수동적 동작의 예
서버 측 문제로 인해 499가 발생할 수 있습니까?
504 nginx의 결정 관련 시간 초과 구성
服务端耗时过长导致的499
通过proxy_ignore_client_abort配置解决499问题?
싱글 업스트림이 가끔 피크가 아닌 기간에 응답이 느리고 시간이 초과되는 이유
운영 및 유지보수 엔진스 부적절한 nginx 구성으로 인해 발생하는 499 및 장애 조치 메커니즘 오류 문제를 해결하는 방법

부적절한 nginx 구성으로 인해 발생하는 499 및 장애 조치 메커니즘 오류 문제를 해결하는 방법

Jun 02, 2023 pm 07:54 PM
nginx failover

    499

    499의 의미와 가능한 이유는 실제로 HTTP 프로토콜의 표준 상태 코드가 아니라 nginx의 사용자 정의 상태 코드입니다. 공식 nginx 문서에는 이 상태 코드에 대한 명확한 설명이 없습니다. 좀 더 전문적으로 느껴지는 블로그 게시물의 설명을 인용해 보겠습니다.

    HTTP 오류 499는 단순히 서버를 통해 요청을 처리하는 중에 클라이언트가 종료되었음을 의미합니다. 499 오류 코드는 서버에 문제가 발생했음을 더 잘 보여줍니다. 그러므로 걱정하지 마세요. HTTP 응답 코드 499는 전혀 귀하의 잘못이 아닙니다.

    일반적으로 499는 HTTP가 처리 프로세스를 종료하는 동안 클라이언트가 적극적으로 처리 프로세스를 종료한다는 의미입니다. 요청이 아직 처리 중입니다. 해당 네트워크 연결이 끊어졌습니다. 499는 일반적으로 클라이언트 측에서 일부 문제가 발생했으며 서버와 관련이 없음을 의미합니다.
    다음은 nginx 소스 코드의 주석입니다.

    /*
    * HTTP does not define the code for the case when a client closed
    * the connection while we are processing its request so we introduce
    * own code to log such situation when a client has closed the connection
    * before we even try to send the HTTP header to it
    */
    #define NGX_HTTP_CLIENT_CLOSED_REQUEST     499
    로그인 후 복사

    클라이언트 연결이 끊어졌을 때 nginx가 요청 처리를 완료하지 못한 시나리오를 기록하기 위해 nginx가 사용자 정의 코드 499를 도입했음을 의미합니다.
    수년 전 499 시나리오를 처음 접했을 때, 저도 인터넷에서 정보 검색을 하다가 비슷한 답변을 봤던 기억이 나네요. 그래서 499는 서버와는 거의 관련이 없고, 모두 서버에 의해 발생해야 한다고 생각했습니다. 고객.

    499로 이어지는 클라이언트의 적극적인 행동의 예

    한 번 검색 Lenovo 인터페이스를 접했는데, 그 499 비율은 다른 API보다 수십 배 높았습니다. - Yiqi Juechen, 이 API만 보면 기본적으로 경보 상태에 머물렀습니다. 위에서 우리는 이상 현상에 대한 구체적인 이유도 추적했으며 마침내 클라이언트 파트너와 협력하여 결론에 도달했습니다. Lenovo 인터페이스를 검색할 때 499 비율이 높은 것은 다음과 같은 이유로 정상입니다.

    • 이 API의 호출 시나리오는 사용자가 검색창에서 검색하는 경우입니다. 검색어를 입력할 때마다 사용자가 문자를 입력할 때마다 최신 입력으로 API가 즉시 호출되고 반환된 연관 결과는 다음과 같습니다. 사용자에게 표시함으로써 거의 실시간 검색 연관 기능을 달성합니다.

    • 사용자가 새 문자를 입력할 때마다 최신 API 호출 요청이 발생하므로 이전 호출 요청이 아직 진행 중이더라도 클라이언트는 실제 효과가 없는 이러한 이전 요청을 직접 종료해야 한다는 점이 반영됩니다. nginx에서 로그에는 클라이언트의 연결이 끊어졌음을 나타내는 499가 표시됩니다.

    그래서 Lenovo API 검색은 일반 API의 499라는 높은 비율과 다르지만 클라이언트가 적극적으로 연결을 끊을 책임이 있지만 잘못한 것은 없으며 문제가 없습니다. 서버. .

    499를 유발하는 클라이언트 수동적 동작의 예

    이전에 499를 유발한다고 생각되었던 클라이언트 동작의 또 다른 예는 푸시 피크 기간 동안 일부 사용자가 푸시를 통해 앱을 연 후 즉시 앱을 종료할 수 있습니다. 압력이 상대적으로 높으므로 피크 기간보다 응답 자체가 느려질 수 있습니다. 이때 일부 API 요청이 계속 진행 중일 수 있습니다. 이때 사용자는 앱을 종료하고 해당 연결을 무력화합니다. OS에 의해 자연스럽게 연결이 끊어지고 재활용되므로 499가 발생했습니다. 이 시나리오에서는 서버 측에 문제가 없습니다.

    서버 측 문제로 인해 499가 발생할 수 있습니까?

    위의 두 가지 예에서 얼핏 보면 499는 능동적이든 수동적이든 클라이언트 측에서 발생합니다. 499 서버가 책임을 져서는 안 된다는 블로거의 인식이 깊어지는 것은 바로 이 두 가지 예입니다.
    서버 측 오류로 인해 발생할 수 있는 nginx 오류 코드를 요약하면 주요 시나리오는 다음과 같아야 합니다.

    • 500: 내부 오류. 일반적으로 요청 매개변수는 업스트림 처리 스레드 실행 코드 오류를 직접 발생시키며, 비즈니스 코드 또는 프레임워크가 직접 반환됩니다. 내부 오류

    • 502: 일반적으로 업스트림 서버가 직접 중단되어 연결할 수 없습니다. nginx는 업스트림에 액세스할 수 없어 잘못된 게이트웨이로 돌아갑니다.

    • 503: 업스트림 로드가 너무 높습니다. 중단되지 않고 바로 Service Unavailable

    • 으로 돌아갑니다.

      504: 업스트림이 요청을 처리하는 데 너무 오래 걸립니다. nginx는 업스트림이 돌아올 때까지 기다렸다가 시간 초과되어 게이트웨이 시간 초과

    로 돌아갑니다. 따라서 코드 실행인지 여부입니다. 오류, 서비스 중단, 서비스 사용량이 너무 많거나 요청 처리에 너무 오랜 시간이 걸려 반환된 5XX가 499를 전혀 트리거하지 않습니다.
    일반적인 경우는 사실이지만 이번에 새로 나온 Pingfeng 499는 일반적인 상황이 아닙니다. 인터넷에서 정보를 검색할 때 일부 사람들은 서버 처리 시간이 너무 오래 걸려서 nginx 499가 발생하는 것일 수 있다고 제안했습니다. 그러나 위의 설명에 따르면 이 상황은 시나리오 4에 속해서는 안 됩니다. 업스트림이 요청을 처리하는 데 너무 오래 걸리므로 nginx가 504를 반환합니다.
    그러면 서버 측 처리에 너무 오랜 시간이 걸려 클라이언트가 적극적으로 499 연결을 끊거나 nginx가 게이트웨이 시간 초과 504를 반환하게 될 수 있는 것 같습니다. 그러면 이러한 차이를 초래하는 핵심 요소는 무엇입니까?
    간단히 말하면 클라이언트 연결이 먼저 끊어지고 nginx에 의해 감지되면 499가 됩니다. 업스트림이 너무 오래 걸리고 시간 초과가 nginx에 의해 먼저 결정되면 504가 됩니다. 따라서 핵심은 nginx의 시간 설정입니다. 업스트림 시간 초과. 여기를 클릭하여 서둘러주세요. nginx의 시간 초과 관련 구성을 살펴보니 관련 시간 초과 기간이 명시적으로 구성되어 있지 않습니다.-!

    504 nginx의 결정 관련 시간 초과 구성

    api와 nginx는 uwsgi 프로토콜을 통해 통신하므로 주요 시간 초과 구성 매개 변수는 다음과 같습니다.

    Syntax:	uwsgi_connect_timeout time;
    Default:	
    uwsgi_connect_timeout 60s;
    Context:	http, server, location
    Defines a timeout for establishing a connection with a uwsgi server. It should be noted that this timeout cannot usually exceed 75 seconds.
    Syntax:	uwsgi_send_timeout time;
    Default:	
    uwsgi_send_timeout 60s;
    Context:	http, server, location
    Sets a timeout for transmitting a request to the uwsgi server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the uwsgi server does not receive anything within this time, the connection is closed.
    Syntax:	uwsgi_read_timeout time;
    Default:	
    uwsgi_read_timeout 60s;
    Context:	http, server, location
    Defines a timeout for reading a response from the uwsgi server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the uwsgi server does not transmit anything within this time, the connection is closed.
    로그인 후 복사

    在未明确指定的情况下其超时时间均默认为60s,简单来说(实际情况更复杂一些但这里不进一步探讨)只有在upstream处理请求耗时超过60s的情况下nginx才能判定其Gateway Timeout 并按照504处理,然而客户端设置的HTTP请求超时时间其实只有15s--这其中还包括外网数据传输的时间,于是问题来了:每一个服务端处理耗时超过15s的请求,nginx由于还没达到60s的超时阈值不会判定504,而客户端则会由于超过本地的15s超时时间直接断开连接,nginx于是就会记录为499。
    通过回查nginx log,非高峰期的499告警时段确实是存在单台upstream 请求处理缓慢,耗时过长,于是可能导致:

    • 用户在需要block等待请求的页面等待虽然不到15s但是已经不耐烦了,直接采取切页面或者杀死app重启的方式结束当前请求。

    • 用户耐心等待了15s、或者非阻塞的后台HTTP请求超过了15s超过超时阈值主动断开连接结束了当前请求。

    服务端耗时过长导致的499

    上面已经知道近期新出现的单台upstream 偶发499是由于响应缓慢引起的,既然是由于客户端超时时间(15s)远小于nginx upstream超时时间(60s)引起的,这应该属于一个明显的配置不当,会导致三个明显的问题:

    • 将用户由于各种原因(如杀app)很快主动断开连接导致的499与客户端达到超时时间(这里是15s)导致的499混在了一起,无法区分客户端责任与服务端责任导致499问题。

    • 对于nginx判定为499的请求,由于认为是客户端主动断开,不会被认为是服务端导致的unsuccessful attempt而被计入用于failover判定的max_fails计数中,所以即便一个upstream大量触发了499,nginx都不会将其从可用upstream中摘除,相当于摘除不可用节点的功能失效,而由于负载过高导致499的upstream收到的请求依然不断增加最终可能导致更大的问题。

    • 对于判定为499的请求,也是由于不会被认为是unsuccessful attempt,所以uwsgi_next_upstream这一配置也不会work,于是当第一个处理请求的upstream耗时过长超时后,nginx不会尝试将其请求转发为下一个upstream尝试处理后返回,只能直接失败。

    那是不是把客户端超时时间调大?或者把nginx upstream超时时间调小解决呢?
    调大客户端超时时间当然是不合理的,任何用户请求15s还未收到响应肯定是有问题的,所以正确的做法应该是调小upstream的超时时间,一般来说服务端对于客户端请求处理时间应该都是在数十、数百ms之间,超过1s就已经属于超长请求了,所以不但默认的60s不行,客户端设置的15s也不能用于upstream的超时判定。
    最终经过综合考虑服务端各api的耗时情况,先敲定了一个upstream 5s的超时时间配置--由于之前没有经验首次修改步子不迈太大,观察一段时间后继续调整,这样做已经足以很大程度解决以上的3个问题:

    • 将用户由于各种原因(如杀app)很快主动断开连接导致的499与nginx达到upstream超时时间时主动结束的504区分开了。

    • 504会被纳入max_fails计算,触发nginx摘除失败节点逻辑,在单台机器故障响应缓慢时可以被识别出来暂时摘除出可用节点列表,防止其负载进一步加大并保证后续请求均被正常可用节点处理返回。

    • 当nginx等待upstream处理达到5s触发超时时,其会按照uwsgi_next_upstream配置尝试将请求(默认仅限幂等的GET请求)转交给下一个upstream尝试处理后返回,这样在单一upstream由于异常负载较高超时时,其他正常的upstream可以作为backup兜底处理其超时请求,这里客户端原本等待15s超时的请求一般在5~10s内可以兜底返回。

    通过proxy_ignore_client_abort配置解决499问题?

    在网上查找资料时还有网友提出解除nginx 499问题的一个思路是设置proxy_ignore_client_abort参数,该参数默认为off,将其设置为on 后,对于客户端主动断开请求的情况,nginx会ignore而以upstream实际返回的状态为准,nginx官方文档说明如下:

    Syntax:	proxy_ignore_client_abort on | off;
    Default:	
    proxy_ignore_client_abort off;
    Context:	http, server, location
    Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.
    로그인 후 복사

    但是在客户端主动断开连接时,设置这个参数的意义除了使nginx log中记录的状态码完全按照upstream返回确定,而非表示客户端断连的499之外,对于实际问题解决完全没有任何帮助,感觉颇有把头埋进沙子的鸵鸟风格,不知道这个参数设置到底会有什么实用的场景。

    싱글 업스트림이 가끔 피크가 아닌 기간에 응답이 느리고 시간이 초과되는 이유

    이 문제는 최근에야 나타났습니다. 위에서 언급한 nginx 불일치 문제를 해결한 후 이 문제를 해결하려고 했습니다. 현상의 관점에서 볼 때 업스트림 CPU 급증을 유발하는 것은 특정 특정 요청이어야 하며, 느린 응답은 후속 요청 처리에 추가로 영향을 미쳐 결국 모든 요청이 느리게 응답하고 클라이언트 499를 트리거하게 됩니다.
    nginx 불일치 문제가 해결된 후 단일 업스트림의 느린 시간 초과가 다시 발생하면 nginx는 상황이 더 악화되는 것을 방지하기 위해 장애 조치를 통해 업스트림 문제를 신속하게 제거하고 첫 번째 액세스 문제 업스트림 시간 초과에 대한 GET 요청도 처리를 위해 사용 가능한 다른 업스트림으로 전달한 다음 반환하면 이러한 예외의 영향이 크게 줄어듭니다.
    마지막으로 구성을 수정한 후 단일 업스트림에서 간헐적으로 발생하는 예외로 인해 며칠에 한 번씩 일부 POST API에 대해 소수의 504 임계값 경보가 트리거됩니다.

    위 내용은 부적절한 nginx 구성으로 인해 발생하는 499 및 장애 조치 메커니즘 오류 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

    본 웹사이트의 성명
    본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

    핫 AI 도구

    Undresser.AI Undress

    Undresser.AI Undress

    사실적인 누드 사진을 만들기 위한 AI 기반 앱

    AI Clothes Remover

    AI Clothes Remover

    사진에서 옷을 제거하는 온라인 AI 도구입니다.

    Undress AI Tool

    Undress AI Tool

    무료로 이미지를 벗다

    Clothoff.io

    Clothoff.io

    AI 옷 제거제

    AI Hentai Generator

    AI Hentai Generator

    AI Hentai를 무료로 생성하십시오.

    뜨거운 도구

    메모장++7.3.1

    메모장++7.3.1

    사용하기 쉬운 무료 코드 편집기

    SublimeText3 중국어 버전

    SublimeText3 중국어 버전

    중국어 버전, 사용하기 매우 쉽습니다.

    스튜디오 13.0.1 보내기

    스튜디오 13.0.1 보내기

    강력한 PHP 통합 개발 환경

    드림위버 CS6

    드림위버 CS6

    시각적 웹 개발 도구

    SublimeText3 Mac 버전

    SublimeText3 Mac 버전

    신 수준의 코드 편집 소프트웨어(SublimeText3)

    Tomcat 서버에 대한 외부 네트워크 액세스를 허용하는 방법 Tomcat 서버에 대한 외부 네트워크 액세스를 허용하는 방법 Apr 21, 2024 am 07:22 AM

    Tomcat 서버가 외부 네트워크에 액세스하도록 허용하려면 다음을 수행해야 합니다. 외부 연결을 허용하도록 Tomcat 구성 파일을 수정합니다. Tomcat 서버 포트에 대한 액세스를 허용하는 방화벽 규칙을 추가합니다. Tomcat 서버 공용 IP에 대한 도메인 이름을 가리키는 DNS 레코드를 만듭니다. 선택 사항: 역방향 프록시를 사용하여 보안 및 성능을 향상합니다. 선택 사항: 보안 강화를 위해 HTTPS를 설정합니다.

    nginx 시작 및 중지 명령은 무엇입니까? nginx 시작 및 중지 명령은 무엇입니까? Apr 02, 2024 pm 08:45 PM

    Nginx의 시작 및 중지 명령은 각각 nginx 및 nginx -s quit입니다. start 명령은 서버를 직접 시작하는 반면 stop 명령은 서버를 정상적으로 종료하여 모든 현재 요청이 처리되도록 합니다. 사용 가능한 기타 정지 신호에는 정지 및 재장전이 포함됩니다.

    thinkphp를 실행하는 방법 thinkphp를 실행하는 방법 Apr 09, 2024 pm 05:39 PM

    ThinkPHP Framework를 로컬에서 실행하는 단계: ThinkPHP Framework를 로컬 디렉터리에 다운로드하고 압축을 풉니다. ThinkPHP 루트 디렉터리를 가리키는 가상 호스트(선택 사항)를 만듭니다. 데이터베이스 연결 매개변수를 구성합니다. 웹 서버를 시작합니다. ThinkPHP 애플리케이션을 초기화합니다. ThinkPHP 애플리케이션 URL에 접속하여 실행하세요.

    nginx에 오신 것을 환영합니다! 어떻게 해결하나요? nginx에 오신 것을 환영합니다! 어떻게 해결하나요? Apr 17, 2024 am 05:12 AM

    "Welcome to nginx!" 오류를 해결하려면 가상 호스트 구성을 확인하고, 가상 호스트를 활성화하고, Nginx를 다시 로드하고, 가상 호스트 구성 파일을 찾을 수 없으면 기본 페이지를 만들고, Nginx를 다시 로드해야 합니다. 그러면 오류 메시지가 나타납니다. 사라지고 웹사이트는 정상적으로 표시됩니다.

    phpmyadmin을 등록하는 방법 phpmyadmin을 등록하는 방법 Apr 07, 2024 pm 02:45 PM

    phpMyAdmin을 등록하려면 먼저 MySQL 사용자를 생성하고 권한을 부여한 다음 phpMyAdmin을 다운로드, 설치 및 구성하고 마지막으로 phpMyAdmin에 로그인하여 데이터베이스를 관리해야 합니다.

    nodejs 프로젝트를 서버에 배포하는 방법 nodejs 프로젝트를 서버에 배포하는 방법 Apr 21, 2024 am 04:40 AM

    Node.js 프로젝트의 서버 배포 단계: 배포 환경 준비: 서버 액세스 권한 획득, Node.js 설치, Git 저장소 설정. 애플리케이션 빌드: npm run build를 사용하여 배포 가능한 코드와 종속성을 생성합니다. Git 또는 파일 전송 프로토콜을 통해 서버에 코드를 업로드합니다. 종속성 설치: SSH를 서버에 연결하고 npm install을 사용하여 애플리케이션 종속성을 설치합니다. 애플리케이션 시작: node index.js와 같은 명령을 사용하여 애플리케이션을 시작하거나 pm2와 같은 프로세스 관리자를 사용합니다. 역방향 프록시 구성(선택 사항): Nginx 또는 Apache와 같은 역방향 프록시를 사용하여 트래픽을 애플리케이션으로 라우팅합니다.

    웹사이트에 접속할 때 nginx 문제를 해결하는 방법 웹사이트에 접속할 때 nginx 문제를 해결하는 방법 Apr 02, 2024 pm 08:39 PM

    웹사이트에 접속할 때 nginx가 나타날 수 있습니다. 서버 유지 관리, 바쁜 서버, 브라우저 캐시, DNS 문제, 방화벽 차단, 웹사이트 구성 오류, 네트워크 연결 문제 또는 웹사이트 다운이 원인일 수 있습니다. 다음 해결 방법을 시도해 보십시오. 유지 관리가 끝날 때까지 기다리기, 사용량이 적은 시간에 방문하기, 브라우저 캐시 지우기, DNS 캐시 플러시하기, 방화벽 또는 바이러스 백신 소프트웨어 비활성화하기, 사이트 관리자에게 문의하기, 네트워크 연결 확인하기, 검색 엔진 사용하기 또는 사이트의 다른 사본을 찾으려면 웹 아카이브를 방문하세요. 문제가 지속되면 사이트 관리자에게 문의하세요.

    도커 컨테이너 간 통신 방법 도커 컨테이너 간 통신 방법 Apr 07, 2024 pm 06:24 PM

    Docker 환경에는 공유 네트워크, Docker Compose, 네트워크 프록시, 공유 볼륨 및 메시지 큐의 5가지 컨테이너 통신 방법이 있습니다. 격리 및 보안 요구 사항에 따라 Docker Compose를 활용하여 연결을 단순화하거나 네트워크 프록시를 사용하여 격리를 높이는 등 가장 적절한 통신 방법을 선택하세요.

    See all articles