کد 499 Client Closed Request یک وضعیت غیر استاندارد رایج در لاگ Nginx است: طرف درخواست‌کننده پیش از تکمیل پاسخ اتصال را بسته است. این طرف ممکن است مرورگر، CDN یا load balancer باشد. بنابراین 499 نه لزوماً پاسخ قابل مشاهده کاربر است و نه ثابت می‌کند که سرور سالم و تقصیر فقط با اینترنت کاربر است.
چه چیزی باعث بسته‌شدن اتصال می‌شود؟
کاربر ممکن است صفحه را ترک یا بارگذاری را متوقف کند. در مقابل، کندی PHP، کوئری دیتابیس، API خارجی یا صف پردازش می‌تواند باعث شود پراکسی زودتر به timeout برسد و اتصال را ببندد. در این حالت Nginx مبدأ ممکن است 499 ثبت کند، در حالی که کاربر در لایه بیرونی خطای دیگری ببیند. چند 499 پراکنده با موج مداوم روی درخواست‌های پرداخت، اهمیت یکسانی ندارند.
از لاگ مرتبط شروع کنید
زمان دقیق، مسیر درخواست، روش HTTP، شناسه درخواست و مدت پردازش را کنار هم بگذارید. در log format مناسب، متغیر $request_time به تحلیل مدت درخواست کمک می‌کند. زمان اتصال و پاسخ upstream را نیز در صورت ثبت در لاگ مقایسه کنید. لاگ CDN، پراکسی، Nginx، PHP-FPM و برنامه را با منطقه زمانی یکسان تطبیق دهید.
اگر خطاها نزدیک یک زمان ثابت، مثلاً حدود محدودیت timeout یک پراکسی، جمع می‌شوند، زنجیره timeout را بررسی کنید. این نشانه علت را محدود می‌کند، اما به‌تنهایی اثبات نمی‌کند کدام پردازش کند بوده است. داده شخصی، کوکی و query string حساس را قبل از اشتراک گزارش پالایش کنید.
مسیر عیب‌یابی مرحله‌ای
- ببینید 499 روی تمام سایت است یا فقط یک API و صفحه سنگین.
- در همان زمان CPU، RAM، دیسک، صف PHP-FPM و slow query دیتابیس را بررسی کنید.
- مدت درخواست‌های خارجی، cron و jobهای پس‌زمینه را اندازه بگیرید.
- timeout مرورگر یا client، CDN، load balancer، Nginx و برنامه را جدا ثبت کنید.
- پس از رفع گلوگاه، تعداد و نسبت 499 و تجربه واقعی کاربر را دوباره مقایسه کنید.
چرا افزایش timeout همیشه راه‌حل نیست؟
زیادکردن بی‌حساب زمان انتظار، پردازش‌های اشغال‌شده و صف طولانی را بیشتر می‌کند. ابتدا کوئری و درخواست خارجی کند را اصلاح کنید، کار طولانی را در صورت امکان به صف منتقل کنید و برای APIها timeout و مدیریت خطای مشخص داشته باشید. تغییر proxy_read_timeout برای reverse proxy و fastcgi_read_timeout برای FastCGI سناریوهای متفاوتی دارند؛ تنظیم یکی روی مسیر دیگر اثری ندارد.
تغییر پیکربندی باید با پشتیبان، آزمون syntax و برنامه بازگشت انجام شود. در هاست اشتراکی، جزئیات زمان و URL را به پشتیبانی بدهید؛ دسترسی لازم برای تغییر تنظیمات سراسری معمولاً در اختیار کاربر نیست.
نکته مهم برای پرداخت و عملیات تغییردهنده داده
قطع اتصال کاربر الزاماً یعنی عملیات سمت سرور انجام نشده نیست. تکرار خودکار درخواست پرداخت یا ایجاد سفارش می‌تواند عملیات را دوباره اجرا کند، مگر برنامه از کنترل تکرار و شناسه idempotency مناسب استفاده کند. ابتدا وضعیت تراکنش یا سفارش را بررسی کنید. هدف عیب‌یابی فقط حذف عدد 499 از لاگ نیست؛ باید نتیجه عملیات و پاسخ کاربر قابل اعتماد باشد.
منابع و دامنه راهنما
این راهنما بر پایه مستندات رسمی زیر بازبینی شده است. نام گزینه‌ها و امکانات ممکن است با نسخه نرم‌افزار یا سطح دسترسی سرویس شما تفاوت داشته باشد.
