TL;DR
- Mã lỗi 499 có nghĩa là khách hàng đã đóng kết nối trước khi NGINX có thể trả về phản hồi; đây là một mã ghi log cụ thể của NGINX, không phải là trạng thái tiêu chuẩn HTTP của IETF.
- Các nguyên nhân phổ biến bao gồm điều hướng của trình duyệt, người dùng thiếu kiên nhẫn, hết thời gian của khách hàng, hết thời gian của bộ cân bằng tải, yêu cầu của crawler bị hủy và các ứng dụng phía trên chậm.
- Sửa lỗi 499 bằng cách tương quan các ID yêu cầu giữa các ghi log của khách hàng, proxy, bộ cân bằng tải và ứng dụng, sau đó điều chỉnh ngân sách thời gian và giảm độ trễ của máy chủ.
- Đừng che giấu triệu chứng bằng cách kéo dài thời gian hết hạn hoặc
proxy_ignore_client_abortcho đến khi bạn biết được cái nào đã đóng kết nối và liệu công việc tiếp tục có an toàn hay không.
Mã lỗi 499 có ý nghĩa gì?
Mã lỗi 499 có nghĩa là khách hàng đã đóng kết nối trong khi NGINX vẫn đang xử lý yêu cầu. NGINX định nghĩa NGX_HTTP_CLIENT_CLOSED_REQUEST là 499 trong mã nguồn của nó.
“Khách hàng” từ góc độ của NGINX có thể là một trình duyệt, ứng dụng di động, crawler, CDN, proxy ngược hoặc bộ cân bằng tải. Một mã 499 trong nhật ký nguồn do đó không chứng minh rằng người dùng cuối đã cố tình hủy yêu cầu.
Tại sao lỗi 499 xảy ra?
Lỗi 499 xảy ra khi thời gian hết hạn hoặc hủy bỏ phía dưới xảy ra trước khi công việc phía trên hoàn tất.
| Nguyên nhân | Bằng chứng | Phản ứng chính xác |
|---|---|---|
| Người dùng đã điều hướng ra ngoài | Thời gian yêu cầu ngắn, hủy bỏ trình duyệt | Thường không cần sửa chữa |
| Thời gian chờ của khách hàng quá ngắn | Cắt đứt nhất quán ở thời gian chờ của khách hàng | Giảm độ trễ hoặc điều chỉnh ngân sách của khách hàng |
| Thời gian chờ của bộ cân bằng tải | Cắt đứt phù hợp với cài đặt LB | Đồng bộ hóa thời gian chờ theo từng bước |
| Ứng dụng / cơ sở dữ liệu chậm | Thời gian phản hồi upstream cao | Tạo hồ sơ và tối ưu hóa nút thắt cổ chai |
| Nguồn gốc bị quá tải | Xếp hàng, CPU, bộ nhớ, hoặc bão hòa kết nối | Thêm dung lượng hoặc giới hạn đồng thời |
| Crawler hủy bỏ các yêu cầu | Nhật ký của khách hàng cho thấy hủy bỏ / thử lại | Sửa chữa chính sách thử lại và thời gian chờ |
Cách chẩn đoán lỗi mã 499
Bước 1: Bảo vệ một định danh yêu cầu
Tạo hoặc chuyển tiếp một ID yêu cầu qua edge, proxy ngược, và ứng dụng. Ghi lại nó với đường dẫn, phương thức, trạng thái thấy được của khách hàng, thời gian yêu cầu, thời gian upstream, và địa chỉ upstream. Không bao giờ ghi lại tiêu đề xác thực hoặc các tham số truy vấn nhạy cảm.
Bước 2: Xác định khách hàng ngay lập tức
Lập bản đồ địa chỉ và tiêu đề lân cận của NGINX với bước bên dưới thực tế. Nếu một CDN hoặc bộ cân bằng tải kết nối với NGINX, thời gian hết hạn của nó - không phải thời gian hết hạn của trình duyệt - có thể đã đóng socket.
Bước 3: So sánh ngân sách thời gian chờ
Viết chuỗi thời gian chờ theo thứ tự:
người dùng cuối → CDN → bộ cân bằng tải → NGINX → ứng dụng → cơ sở dữ liệu/API
Bước bên ngoài phải cho phép đủ thời gian cho công việc bên trong cộng với chi phí mạng và xếp hàng. Giá trị thời gian chờ giống nhau ở mọi bước tạo ra các cuộc đua thay vì an toàn.
Bước 4: Phân tách hủy bỏ của khách hàng khỏi độ chậm của máy chủ
So sánh tổng thời gian yêu cầu với thời gian phản hồi upstream. Một cụm mã 499 trên một điểm đầu cuối chậm chỉ ra công việc ứng dụng; các mã 499 ngắn rải rác có thể là điều hướng thông thường hoặc các yêu cầu bị hủy bỏ.
Bước 5: Tái sản xuất với một khách hàng có giới hạn
Sử dụng một điểm cuối thử nghiệm được ủy quyền và một thời gian hết hạn đã biết:
curl --verbose --max-time 5 https://example.com/approved-slow-test
Tương quan dấu thời gian của khách hàng và ID yêu cầu với các ghi log của NGINX và ứng dụng. Không thử nghiệm tải một dịch vụ sản xuất mà không có sự cho phép.
Cách tránh lỗi 499
Phương pháp 1: Giảm độ trễ của ứng dụng
Tạo hồ sơ các truy vấn cơ sở dữ liệu, cuộc gọi API bên ngoài, tranh chấp khóa, khởi động lạnh, và độ trễ hàng đợi. Lưu trữ các kết quả an toàn, phân trang công việc lớn, chuyển các công việc dài sang mô hình tác vụ không đồng bộ, và trả về một ID tác vụ thay vì giữ một yêu cầu mở vô thời hạn.
Phương pháp 2: Đồng bộ hóa chính sách thời gian chờ
Đặt một ngân sách được ghi chép cho mỗi bước. Khách hàng nên chờ đủ lâu cho mức độ dịch vụ dự kiến; các thành phần upstream nên thất bại với các lỗi rõ ràng, có thể quan sát trước khi một trung gian ở dưới im lặng từ bỏ.
Phương pháp 3: Làm cho các lần thử lại an toàn
Chỉ thử lại các hoạt động hoặc yêu cầu idempotent được bảo vệ bởi một khóa idempotency. Thêm thời gian chờ tăng dần có giới hạn với jitter. Việc thử lại một POST hết thời gian một cách mù quáng có thể nhân bản các giao dịch, tin nhắn, hoặc ghi lại ngay cả khi khách hàng đã thấy mã 499.
Phương pháp 4: Giới hạn công việc của proxy và crawler
Đối với việc thu thập có ủy quyền thông qua các proxy Nstdata, sử dụng thời gian hết hạn kết nối và phản hồi hữu hạn, giới hạn đồng thời, xác thực nội dung phản hồi, và chỉ thử lại các lỗi tạm thời đã phân loại. Một tuyến proxy mới không thể sửa chữa một ứng dụng chậm hoặc một chuỗi thời gian chờ được sắp xếp không đúng.
Các tài liệu tham khảo hữu ích bao gồm xử lý thời gian chờ proxy, các quy tắc tốt nhất trong web-scraping, và thuật toán giảm tốc độ.
Có Nên Sử Dụng proxy_ignore_client_abort?
proxy_ignore_client_abort không phải là một giải pháp chung cho lỗi 499. Việc tiếp tục công việc upstream sau khi client downstream ngắt kết nối có thể phù hợp cho một nhiệm vụ được thiết kế cẩn thận với sự bất đồng bộ hoặc tính idempotent, nhưng nó cũng có thể lãng phí năng lực và thực hiện các hành động mà không có client nào nhận được kết quả.
Trước tiên, xác định xem việc hủy bỏ có nên được truyền đi hay không. Đối với các đọc dữ liệu tốn kém, việc hủy bỏ thường tiết kiệm tài nguyên. Đối với một giao dịch, hãy sử dụng tính idempotency ở mức ứng dụng và thiết kế trạng thái công việc thay vì dựa vào một chỉ thị proxy để xác định ngữ nghĩa kinh doanh.
Kết Luận Cuối Cùng
Mã lỗi 499 là một tín hiệu hủy bỏ, không phải là nguyên nhân gốc. Tìm điểm nhảy đã đóng kết nối, liên quan đến thời gian trên toàn bộ đường truyền yêu cầu, giảm độ trễ upstream và thiết kế một hệ thống thời gian chờ có chủ đích. Xem thời gian chờ dài hơn như một quyết định ngân sách, không phải là một phương thuốc tự động.
Đối với các khối lượng công việc web công khai tự động, hãy đo lường lỗi theo mục tiêu, phiên, giai đoạn thời gian chờ và đầu ra được chấp nhận. Nstdata Proxy Manager là tùy chọn liên quan khi các bể proxy, chính sách định tuyến và nhật ký hoạt động cần kiểm soát tập trung.
Trải Nghiệm Nstdata — Bắt Đầu Thử Nghiệm Miễn Phí Ngày Hôm Nay
Câu Hỏi Thường Gặp
Q: 499 có phải là mã trạng thái HTTP chính thức không?
Không. Đó là một mã cụ thể của NGINX được sử dụng trong nhật ký khi client đóng yêu cầu trước khi một phản hồi được gửi.
Q: Lỗi 499 do máy chủ hay client gây ra?
Client ngay lập tức đóng kết nối, nhưng độ trễ của máy chủ, timeout của proxy, hoặc chính sách của bộ cân bằng tải có thể đã kích hoạt quyết định đó.
Q: Tôi có nên tăng proxy_read_timeout để sửa lỗi 499 không?
Chỉ sau khi xác nhận rằng NGINX là điểm nhảy có ngân sách quá ngắn. Tăng một thời gian chờ không liên quan có thể che giấu độ trễ và tiêu tốn nhiều tài nguyên hơn.
Q: Liệu các lần thử lại có khắc phục lỗi 499 được không?
Các lần thử lại chỉ hữu ích cho những lỗi tạm thời được phân loại và các thao tác an toàn. Sử dụng các kiểm soát idempotency và giảm tốc độ có giới hạn.
Q: Tại sao số lượng lỗi 499 tăng lên trong các đợt tăng lưu lượng?
Việc xếp hàng và độ trễ upstream thường tăng lên trong các đợt tăng, khiến client hoặc trung gian đạt được ngân sách thời gian chờ của họ trước tiên.
