چرا خطای 408 Request Timeout رخ می‌دهد؟ راهنمای کامل عیب‌یابی و رفع

خطای 408 Request Timeout یکی از کدهای وضعیت HTTP است که وقتی رخ می‌دهد، نشان می‌دهد سرور به انتظار دریافت کامل درخواست از سمت کلاینت ماند و در نهایت، پیش از رسیدن کامل درخواست، اتصال را بست. این خطا با بسیاری از خطاهای دیگر متفاوت است: سرور شما سالم است، اپلیکیشن شما هم سالم است، اما کلاینت نتوانسته در بازه زمانی مشخص، درخواست را کامل ارسال کند. به همین دلیل، تشخیص ریشه این خطا بدون درک دقیق چرخه درخواست HTTP، معمولاً به حدس تبدیل می‌شود. در این مقاله، همان مسیری را طی می‌کنم که در پروژه‌های واقعی سرور و وردپرس برای ردیابی این خطا استفاده کرده‌ام — لایه‌به‌لایه، با تمرکز بر یافتن ریشه و نه صرفاً پاک کردن علائم.

408 Request Timeout دقیقاً چه معنایی دارد؟

در استاندارد HTTP Status Codes، کد 408 در دسته 4xx (خطای کلاینت) قرار می‌گیرد و به‌طور رسمی به این معناست: «سرور در بازه زمانی مشخص، منتظر دریافت کامل درخواست از سمت کلاینت ماند و چون کلاینت در این بازه، درخواست را کامل ارسال نکرد، سرور اتصال را بست». این پیام، به‌طور پیش‌فرض به سه نکته اشاره دارد: اول، سرور سالم است و به درخواست پاسخ داده. دوم، درخواست کلاینت کامل دریافت نشده. سوم، این مشکل در لایه شبکه یا کلاینت است، نه در لایه اپلیکیشن سرور.

نکته مهمی که اکثر توسعه‌دهنده‌ها از آن بی‌خبرند این است که 408 در معماری مدرن، معمولاً توسط وب‌سرور یا لایه میانی (CDN، WAF، لودبالانسر) برگردانده می‌شود، نه توسط PHP یا اپلیکیشن شما. این یعنی اگر 408 می‌بینید، احتمالاً کد اپلیکیشن شما حتی اجرا نشده است. وب‌سرور در بازه مشخصی منتظر دریافت کامل بدنه درخواست می‌ماند؛ اگر کلاینت در این بازه، درخواست را کامل نفرستد، وب‌سرور با 408 پاسخ می‌دهد و اتصال را می‌بندد. اگر با معماری کلی سرور آشنایی ندارید، ابتدا سرور چیست و چگونه کار می‌کند را بخوانید تا تصویر کلی در ذهن شما شکل بگیرد.

408 به کلاینت می‌گوید «منتظرت ماندم اما نیامدی». راه‌حل، تسریع ارسال درخواست از سمت کلاینت است، نه تغییر اپلیکیشن.

سه لایه‌ای که باید تفکیک شوند

در تجربه من، خطای 408 همیشه در یکی از این سه لایه ریشه دارد. تفکیک لایه پیش از هر اقدام، نیمی از راه را رفته‌اید:

• لایه کلاینت و شبکه: اتصال اینترنت کند، پکت‌لاس بالا، پروکسی ناپایدار، یا فایروال روی مسیر، باعث می‌شود درخواست به‌موقع ارسال نشود.
• لایه وب‌سرور: پارامترهای timeout در Nginx یا Apache بسیار سخت‌گیرانه تنظیم شده‌اند و درخواست‌های عادی هم رد می‌شوند.
• لایه میان‌راهی: CDN، WAF، لودبالانسر یا پروکسی معکوس، با timeout خودش، درخواست را قطع می‌کند.

جدول زیر نگاشت سریع سیمپتوم به لایه خطا را نشان می‌دهد:

تفاوت بنیادین 408 با 504، 502 و 503

یکی از پرتکرارترین اشتباهات در عیب‌یابی، قاطی کردن کدهای timeout با همدیگر است. تفاوت بین این کدها در یک نگاه، می‌تواند ساعات عیب‌یابی را ذخیره کند. جدول زیر این تفاوت‌ها را نشان می‌دهد:

این تفکیک در عیب‌یابی حیاتی است. اگر سرور 504 برگرداند، مشکل در لایه سرور بالادستی است: PHP کند اجرا می‌شود یا API خارجی پاسخ نمی‌دهد. اگر 408 برگرداند، مشکل در لایه کلاینت یا شبکه است: درخواست به‌موقع ارسال نشده. راهنمای رفع 504 در رفع خطای 504 Gateway Timeout، 502 در رفع خطای 502 Bad Gateway و 503 در خطای 503 Service Unavailable آورده شده است.

در عیب‌یابی timeoutها، اولین سوال این نیست «چه چیزی کند است؟» اولین سوال این است «چه کسی منتظر چه کسی مانده؟» پاسخ این سوال، کد 4xx یا 5xx را مشخص می‌کند.

چرخه درخواست HTTP و نقش timeout

برای فهم دقیق 408، باید بدانید درخواست HTTP چه مراحلی را طی می‌کند و در کدام مرحله، timeout رخ می‌دهد. این چرخه در چهار مرحله خلاصه می‌شود: اول، برقراری اتصال TCP (که خودش timeout دارد). دوم، ارسال هدرهای HTTP. سوم، ارسال بدنه درخواست (برای POST، PUT و PATCH). چهارم، دریافت پاسخ از سرور.

سه پارامتر timeout که در این چرخه نقش دارند:

• timeout برقراری اتصال: حداکثر زمان انتظار برای برقراری اتصال TCP.
• timeout دریافت هدر و بدنه: حداکثر زمان انتظار برای دریافت کامل هدر و بدنه درخواست.
• timeout پاسخ: حداکثر زمان انتظار برای دریافت پاسخ از سرور.

خطای 408 در دو مرحله اول و دوم رخ می‌دهد: زمانی که کلاینت نتوانسته اتصال را برقرار کند، یا هدر و بدنه درخواست را در بازه مشخص ارسال کند. مرحله سوم (دریافت پاسخ) با کد 504 یا 408 (در برخی پیاده‌سازی‌ها) مرتبط است. اگر خطای timeout از سمت کلاینت است، باید در لایه شبکه و پروکسی جست‌وجو کنید؛ اگر از سمت سرور است، در لایه timeoutهای سرور.

مبانی چرخه HTTP و ساختار درخواست‌ها، پایه‌ای است که هر توسعه‌دهنده وب و مدیر سرور باید بداند. برای درک عمیق‌تر سرور و معماری آن، سرور وردپرس چه مشخصاتی باید داشته باشد و برای مبانی امنیت وب، امنیت وب چیست راهنمای دقیقی است.

پارامترهای timeout در Nginx و Apache

در لایه وب‌سرور، پارامترهای timeout تعیین می‌کنند که سرور چه مدت منتظر دریافت درخواست از کلاینت بماند. اگر این پارامترها سخت‌گیرانه تنظیم شده باشند، درخواست‌های عادی هم ممکن است 408 بگیرند. این سناریو در پیکربندی‌های سفارشی شایع است.

سه پارامتر کلیدی در Nginx:

1. client_body_timeout: حداکثر زمان بین دو عملیات خواندن متوالی از بدنه درخواست. مقدار پیش‌فرض ۶۰ ثانیه است. اگر کلاینت با شبکه کند، بین دو packet بیش از این مقدار فاصله بیفتد، Nginx اتصال را می‌بندد و 408 برمی‌گرداند.
2. client_header_timeout: حداکثر زمان برای دریافت کامل هدر درخواست از کلاینت. مقدار پیش‌فرض ۶۰ ثانیه است.
3. keepalive_timeout: حداکثر زمان نگه‌داشتن اتصال keep-alive فعال. اگر این پارامتر خیلی پایین باشد، کلاینت مجبور است اتصال را مداوم بازسازی کند و در شرایط خاص ممکن است 408 بگیرد.

در Apache نیز پارامترهای مشابه وجود دارد. سه پارامتر کلیدی:

• Timeout: حداکثر زمان برای دریافت کل درخواست، از باز شدن اتصال تا دریافت بدنه. مقدار پیش‌فرض در Apache 2.4، ۶۰ ثانیه است.
• RequestReadTimeout: کنترل دقیق‌تر روی زمان خواندن هدر و بدنه.
• KeepAliveTimeout: معادل keepalive_timeout در Nginx.

روش تشخیص: در Nginx، فایل‌های پیکربندی را باز کنید و برای کلمات client_body_timeout، client_header_timeout و keepalive_timeout جست‌وجو کنید. اگر مقدارشان زیر ۳۰ ثانیه باشد، احتمال 408 بالا می‌رود. برای عیب‌یابی عمیق‌تر لاگ‌ها، بررسی خطاهای سرور در لاگ‌ها راهنمای دقیقی است. برای دستورات ضروری مدیریت سرور، دستورات ضروری CLI نقطه شروع مناسبی است.

در Nginx، client_body_timeout میان دو پکت متوالی حساب می‌شود، نه کل زمان انتقال. اگر شبکه بین packetها تعلل کند، حتی با کل زمان کم، ممکن است 408 بگیرید.

timeout در PHP و وردپرس

در لایه PHP و وردپرس، پارامتر timeout مسئول محدودسازی زمان اجرای اسکریپت است، نه دریافت درخواست. به همین دلیل، خطای 408 به‌طور مستقیم از PHP نمی‌آید و اگر وب‌سرور شما در طبقه بالای PHP قرار داشته باشد، خطای PHP با کد 500 یا 504 بروز می‌کند. اما در پیاده‌سازی‌های سفارشی، PHP می‌تواند با تنظیم پارامتر timeout در پاسخ، رفتار غیر استاندارد ایجاد کند.

سه پارامتر PHP که در این لایه اثر دارند:

1. max_execution_time: حداکثر زمان اجرای اسکریپت PHP. این پارامتر روی پردازش اثر دارد، نه دریافت درخواست. اگر PHP کندتر از این مقدار باشد، خطای «Maximum execution time exceeded» می‌بینید که یک خطای 500 است، نه 408. راهنمای رفع این خطا در رفع خطای Maximum execution time در PHP آمده است.
2. max_input_time: حداکثر زمان برای پارس داده‌های ورودی (POST، PUT). اگر این مقدار پایین باشد و کلاینت کند آپلود کند، ممکن است خطا بگیرید. مقدار پیش‌فرض معمولاً ۶۰ ثانیه است.
3. default_socket_timeout: timeout پیش‌فرض برای درخواست‌های HTTP خروجی. اگر کد شما به یک API خارجی وصل شود و آن API کند پاسخ دهد، این پارامتر تعیین‌کننده است.

در وردپرس، پارامتر WP_HTTP_BLOCK_EXTERNAL و ثابت‌های مشابه در wp-config.php روی رفتار درخواست‌های خروجی اثر دارند. اگر بخشی از کد شما از wp_remote_get() یا wp_remote_post() استفاده می‌کند و آن درخواست به‌دلیل کندی سرور مقصد، timeout می‌خورد، می‌توانید مقدار http_request_timeout را از طریق فیلتر http_request_args تنظیم کنید.

نکته دقیق: در وردپرس، اگر از wp_remote_get() استفاده می‌کنید و سرور مقصد کند پاسخ می‌دهد، ممکن است در برخی پیاده‌سازی‌ها خطای 408 ببینید. این خطا از سمت سرور مقصد می‌آید نه سرور شما. برای عیب‌یابی، از لاگ درخواست‌های خروجی و ابزارهای تست مانند دستورات CLI استفاده کنید.

عوامل سمت کلاینت: شبکه، فایروال و پروکسی

لایه‌ای که کم‌ترین توجه را دریافت می‌کند اما در 408 نقش اصلی دارد: لایه کلاینت. اگر کلاینت نتواند در بازه مشخص، درخواست را کامل ارسال کند، سرور 408 برمی‌گرداند — حتی اگر سرور و اپلیکیشن بی‌عیب باشند. در تجربه من، اکثر 408ها در پروژه‌های واقعی، در همین لایه ریشه دارند.

سه سناریوی دقیق در این لایه:

• اتصال اینترنت کند یا ناپایدار: اگر کاربر با شبکه‌ای با پکت‌لاس بالا یا سرعت پایین وصل شود، ارسال درخواست طول می‌کشد و ممکن است 408 بگیرد.
• پروکسی ناپایدار روی مسیر: اگر کاربر از طریق یک پروکسی به سایت وصل شود و آن پروکسی، درخواست را با تاخیر رد کند، سرور 408 برمی‌گرداند. این سناریو در کاربران با VPN و فیلترشکن شایع است.
• فایروال شرکتی یا سازمانی: بعضی فایروال‌های سازمانی، درخواست‌های خروجی را با تأخیر ارسال می‌کنند یا بدنه را به‌دلیل سیاست‌های امنیتی، بازرسی می‌کنند که باعث تأخیر می‌شود.

روش تشخیص قطعی: در فهرست کاربرانی که 408 می‌گیرند، بررسی کنید که آیا آن‌ها از یک ISP یا VPN خاص استفاده می‌کنند. اگر بله، ریشه در لایه کلاینت است. برای درک مبانی شبکه و اتصال، سرور چیست و چگونه کار می‌کند نقطه شروع مناسبی است.

408 در CDN و WAF

در معماری‌های مدرن، درخواست‌ها ابتدا از CDN و WAF عبور می‌کنند. اگر این لایه‌ها، درخواست را در بازه زمانی مشخصی از کلاینت دریافت نکنند، ممکن است 408 برگردانند حتی اگر وب‌سرور اصلی شما سالم باشد. سه سناریوی دقیق:

• CDN با timeout کوتاه: بعضی CDNها timeout پیش‌فرض کوتاهی دارند (مثلاً ۳۰ ثانیه) که برای شبکه‌های کند، کافی نیست.
• WAF با بازرسی بدنه: بعضی WAFها، بدنه درخواست را برای تحلیل امنیتی، مرحله‌به‌مرحله دریافت می‌کنند. اگر کلاینت کند بفرستد، WAF ممکن است در میانه قطع کند و 408 برگرداند.
• لودبالانسر با timeout تهاجمی: در معماری‌های چندسروره، لودبالانسر با timeout تهاجمی می‌تواند درخواست‌های طولانی را قبل از رسیدن کامل، قطع کند.

روش تشخیص: با ابزارهای CDN ببینید که آیا درخواست به سرور اصلی رسیده یا نه. اگر درخواست به سرور نرسیده اما 408 گرفته، ریشه در CDN یا WAF است. توضیح معماری CDN و WAF را در CDN چیست و چگونه کار می‌کند و فایروال ابری در مقابل فایروال سنتی آورده‌ام.

آپلودهای سنگین و بدنه‌های بزرگ

یکی از شایع‌ترین سناریوهای 408 در پروژه‌های وردپرسی و فروشگاهی، آپلود فایل‌های بزرگ است. وقتی کاربر یک فایل ۵۰ مگابایتی آپلود می‌کند، فرآیند ارسال بدنه درخواست ممکن است طولانی‌تر از timeout وب‌سرور شود. در نتیجه، سرور اتصال را می‌بندد و کاربر پیام 408 یا «Upload Failed» می‌بیند.

سه پارامتر که در این لایه اثر دارند:

1. client_max_body_size در Nginx: حداکثر حجم بدنه درخواست. اگر این مقدار کم باشد، درخواست‌های بزرگ با 413 رد می‌شوند نه 408. اما اگر مقدار زیاد و timeout کم باشد، 408 رخ می‌دهد.
2. upload_max_filesize و post_max_size در PHP: حداکثر حجم فایل آپلود. اگر این‌ها کم باشند، درخواست قطع می‌شود. مقدار امن برای فروشگاه‌های وردپرسی: حداقل ۶۴ مگابایت.
3. client_body_timeout: زمان بین دو پکت متوالی بدنه. برای آپلودهای بزرگ، مقدار باید بالاتر از پیش‌فرض باشد.

راه‌حل عملی: افزایش client_max_body_size به مقداری متناسب با نیاز، و افزایش client_body_timeout به ۳۰۰ ثانیه یا بیشتر. راهنمای رفع خطای آپلود در وردپرس در رفع خطای آپلود فایل در وردپرس آمده است.

هر ثانیه انتظار سرور برای دریافت بدنه درخواست، یک فرصت برای رخ دادن 408 است. برای آپلودهای بزرگ، timeout را سخاوتمندانه تنظیم کنید.

Keep-Alive و مدیریت اتصال پایدار

پروتکل HTTP از دو حالت اتصال پشتیبانی می‌کند: اتصال کوتاه‌مدت (Connection: close) که در آن هر درخواست، یک اتصال TCP جدید می‌سازد، و اتصال پایدار (Keep-Alive) که در آن، یک اتصال TCP برای چندین درخواست استفاده می‌شود. مدیریت نادرست Keep-Alive می‌تواند به 408 منجر شود.

سه سناریوی دقیق در این لایه:

• keepalive_timeout پایین در سرور: اگر مقدار پایین باشد، اتصال سریع بسته می‌شود. اگر کلاینت بخواهد درخواست جدیدی روی همان اتصال بفرستد، ممکن است 408 بگیرد.
• keepalive_timeout پایین در کلاینت: بعضی کلاینت‌ها timeout کوتاهی برای keep-alive دارند. نتیجه: اتصال در میانه فرآیند بسته می‌شود.
• تداخل با CDN: اگر CDN و سرور timeout متفاوتی برای keep-alive داشته باشند، اتصال‌ها در مرز بین دو لایه می‌توانند ناپایدار شوند.

راه‌حل: مقادیر keep-alive را در همه لایه‌ها هماهنگ کنید. مقدار پیشنهادی: ۶۵ تا ۷۵ ثانیه در سرور و CDN. این کار باعث می‌شود اتصال‌ها پایدار بمانند و احتمال 408 کاهش یابد.

دلایل شایع بروز 408

بعد از آشنایی با لایه‌ها، فهرست سریع دلایل شایع 408 در پروژه‌های واقعی را مرور کنیم:

1. اتصال اینترنت کند کاربر: شایع‌ترین دلیل 408 در سایت‌های عمومی.
2. timeout کوتاه در وب‌سرور: پیکربندی تهاجمی Nginx یا Apache که درخواست‌های عادی را هم رد می‌کند.
3. آپلود فایل بزرگ: وقتی حجم فایل بالاتر از ظرفیت timeout سرور است.
4. پروکسی ناپایدار: در کاربران با VPN یا فایروال سازمانی.
5. CDN با timeout تهاجمی: بعد از افزودن CDN، بعضی درخواست‌ها 408 می‌گیرند.
6. WAF با بازرسی بدنه: درخواست‌های بزرگ یا پیچیده ممکن است در میانه قطع شوند.
7. تداخل keep-alive: وقتی timeout در لایه‌های مختلف هماهنگ نیست.
8. لودبالانسر با timeout کوتاه: در معماری‌های چندسروره.
9. مشکل شبکه ISP کاربر: در بعضی ISPها، مسیر شبکه ناپایدار است و پکت‌ها با تأخیر می‌رسند.
10. فایروال سرور با سیاست تهاجمی: بعضی فایروال‌ها، درخواست‌های خاص را بلاک می‌کنند و در برخی پیاده‌سازی‌ها 408 برمی‌گردانند.

مبانی امنیت و مدیریت سرور برای رفع این لایه‌ها در امنیت سرور چه اصولی دارد و افزایش امنیت سرور آمده است.

پروتکل عیب‌یابی گام‌به‌گام

حالا ترتیب عملی عیب‌یابی، از سریع‌ترین به دقیق‌ترین:

1. بازتولید و ثبت دقیق: با curl -v -X POST https://example.com/path --data-binary @largefile درخواست را بزنید و همه هدرها را ثبت کنید. این اولین قدم برای تشخیص لایه است.
2. بررسی وب‌سرور: در پیکربندی Nginx یا Apache، پارامترهای client_body_timeout، client_header_timeout و Timeout را ببینید و در صورت نیاز افزایش دهید.
3. بررسی لاگ وب‌سرور: در /var/log/nginx/error.log یا /var/log/apache2/error.log، آخرین درخواست‌ها و خطاهای مرتبط را ببینید.
4. بررسی PHP: پارامترهای max_input_time و default_socket_timeout را در php.ini بررسی کنید.
5. تست با متد ساده: با curl -X GET به همان مسیر درخواست بزنید. اگر پاسخ موفق بود، ریشه در لایه بدنه درخواست (آپلود یا POST بزرگ) است.
6. بررسی CDN و WAF: اگر از CDN استفاده می‌کنید، لاگ آن را بررسی کنید که آیا درخواست به سرور اصلی رسیده یا بلاک شده.
7. تست از شبکه‌های مختلف: از دو ISP مختلف تست کنید. اگر فقط از یک ISP خطا رخ دهد، ریشه در لایه شبکه است.
8. بررسی فایروال: در سرور، iptables یا ufw را بررسی کنید و مطمئن شوید سیاست‌های تهاجمی روی بسته‌های ورودی اعمال نمی‌شود.
9. بررسی لودبالانسر: اگر از لودبالانسر استفاده می‌کنید، پارامتر timeout آن را بررسی کنید.
10. بررسی کلاینت: اگر مشکل از سمت کاربران خاص است، ISP آن‌ها و وضعیت شبکه‌شان را بررسی کنید.

برای خطاهای مرتبط با سرور، خطای 500 Internal Server Error، خطای SSL سرور و خطای DNS سرور مسیرهای مکمل عیب‌یابی هستند. برای مبانی خطاهای HTTP، امنیت وب چیست راهنمای دقیقی است.

در عیب‌یابی 408، اولین کار این نیست که timeout را زیاد کنم. اولین کار این است که بفهمم آیا مشکل از سمت کلاینت است یا از سمت سرور. اگر از سمت کلاینت باشد، افزایش timeout فقط علائم را می‌پوشاند.

اشتباهات پرهزینه در تشخیص

در پرونده‌های پشتیبانی که بازبینی کرده‌ام، این پنج اشتباه بیشتر از بقیه تکرار می‌شود:

• افزایش کورکورانه timeout بدون تشخیص لایه: اگر مشکل از سمت کلاینت باشد، افزایش timeout سرور فقط زمان انتظار را بیشتر می‌کند و کاربر همچنان خطا می‌بیند.
• اشتباه گرفتن 408 با 504: 408 در لایه کلاینت-سرور است، 504 در لایه سرور-بالادستی. اگر این دو را قاطی کنید، در لایه اشتباه وقت تلف می‌کنید.
• نادیده گرفتن CDN: اگر CDN با timeout تهاجمی داشته باشید، تنظیمات سرور اصلی اثری ندارد.
• عیب‌یابی روی سرور تولید: تغییر پارامترهای timeout روی سرور تولید، ریسک بالایی دارد. همیشه اول روی staging تست کنید.
• بی‌توجهی به keep-alive: در معماری‌های مدرن، تداخل keep-alive بین لایه‌ها می‌تواند باعث 408 شود. تنظیمات را در همه لایه‌ها هماهنگ کنید.

پرسش‌های پرتکرار درباره خطای 408 Request Timeout

408 Request Timeout با 504 Gateway Timeout چه تفاوتی دارد؟ 408 به‌معنای «سرور منتظر دریافت درخواست از کلاینت ماند و کلاینت به‌موقع نفرستاد» است — یعنی مشکل در سمت کلاینت یا شبکه. اما 504 به‌معنای «سرور میانی منتظر پاسخ از سرور بالادستی ماند و پاسخ نگرفت» است — یعنی مشکل در سمت سرور بالادستی. تفکیک این دو، اولین قدم در عیب‌یابی درست است.

چرا خطای 408 فقط برای بعضی کاربران رخ می‌دهد؟ این نشانه مشکل در لایه کلاینت یا شبکه است. کاربرانی که 408 می‌گیرند، احتمالاً از ISP ناپایدار، VPN یا فایروال سازمانی استفاده می‌کنند. IP و ISP کاربران را در لاگ سرور بررسی کنید تا الگو را ببینید.

آیا افزایش timeout سرور می‌تواند 408 را رفع کند؟ اگر ریشه در timeout کوتاه سرور باشد، بله. اما اگر ریشه در شبکه کاربر باشد، افزایش timeout فقط زمان انتظار را بیشتر می‌کند و مشکل را حل نمی‌کند. ابتدا لایه را تشخیص دهید.

چرا بعد از افزودن CDN، خطای 408 ظاهر شد؟ بعضی CDNها timeout پیش‌فرض کوتاهی دارند (مثلاً ۳۰ ثانیه) که برای شبکه‌های کند کافی نیست. تنظیمات CDN را بررسی کنید و timeout را افزایش دهید.

آیا آپلود فایل بزرگ می‌تواند 408 ایجاد کند؟ بله. اگر فایل بزرگ باشد و شبکه کند، بدنه درخواست طول می‌کشد تا ارسال شود و سرور ممکن است قبل از کامل شدن، اتصال را ببندد. پارامترهای client_body_timeout در Nginx و upload_max_filesize در PHP را بررسی کنید.

چرا فقط درخواست‌های POST 408 می‌گیرند ولی GET سالم است؟ درخواست‌های POST بدنه دارند که باید ارسال شود؛ اگر شبکه کند یا بدنه بزرگ باشد، این ارسال طول می‌کشد و در بازه timeout سرور جا نمی‌شود. درخواست‌های GET بدنه ندارند و سریع‌تر ارسال می‌شوند.

چطور بفهمم 408 از کدام لایه است؟ با curl -v درخواست را بزنید و پاسخ را ببینید. اگر هدر Server نشانه‌های Nginx یا Apache داشت، لایه وب‌سرور است. اگر نشانه‌های CDN داشت، لایه CDN است. اگر هیچ‌کدام، لایه لودبالانسر یا فایروال است.

آیا 408 می‌تواند از سمت دیتابیس رخ دهد؟ خیر، 408 یک کد HTTP است که فقط در لایه وب و انتقال معنا دارد. اگر دیتابیس مشکل داشته باشد، معمولاً خطای 500 یا 504 می‌بینید.

چرا بعد از مهاجرت به سرور جدید، 408 افزایش یافت؟ احتمالاً timeout سرور جدید سخت‌گیرانه‌تر تنظیم شده یا مسیر شبکه متفاوت است. پیکربندی Nginx یا Apache را با سرور قبلی مقایسه کنید.

آیا کاهش حجم بدنه درخواست می‌تواند به رفع 408 کمک کند؟ بله. اگر بدنه درخواست کوچک‌تر باشد، سریع‌تر ارسال می‌شود و احتمال جا شدن در بازه timeout بالا می‌رود. بهینه‌سازی تصاویر و فایل‌ها نمونه‌ای از این کار است.

آیا 408 می‌تواند از سمت کاربر مهمان رخ دهد ولی کاربر لاگین‌شده سالم باشد؟ معمولاً نه، چون 408 یک خطای لایه انتقال است و به وضعیت کاربر بستگی ندارد. اما اگر کاربران لاگین‌شده از شبکه سازمانی با پروکسی استفاده کنند و مهمان‌ها از شبکه شخصی، تفاوت رفتار ممکن است دیده شود.

چطور از بروز 408 در آینده پیشگیری کنم؟ سه اصل: (۱) پارامترهای timeout سرور را با واقعیت شبکه کاربران هماهنگ کنید، نه با پیش‌فرض؛ (۲) در معماری چندلایه (CDN + سرور + لودبالانسر)، timeout‌ها را در همه لایه‌ها هماهنگ کنید؛ (۳) لاگ دقیق درخواست‌های رد‌شده داشته باشید تا ترند را ببینید.

آنچه از این مسیر با ما می‌ماند

خطای 408 Request Timeout در ظاهر یک پیام ساده است؛ در عمل، یک چالش درباره «زمان» که در یکی از چند لایه ممکن است شکل گرفته باشد. سه اصل که از این مسیر با من می‌ماند:

1. اول لایه را تشخیص بده، بعد راه‌حل را انتخاب کن: 408 فقط در لایه کلاینت-سرور رخ می‌دهد، نه در لایه سرور-بالادستی. اگر این را با 504 قاطی کنید، در لایه اشتباه وقت تلف می‌کنید.
2. در معماری چندلایه، timeout‌ها را هماهنگ نگه دار: اگر CDN، لودبالانسر و وب‌سرور timeoutهای متفاوتی داشته باشند، درخواست در مرز بین لایه‌ها ممکن است قطع شود. یک عدد واحد برای همه لایه‌ها انتخاب کنید و آن را مستند کنید.
3. پایش دقیق کاربران با 408: یک لاگ یا گزارش داشته باشید که IP و ISP کاربرانی که 408 می‌گیرند را نشان دهد. اگر الگوی مشخصی دیده شد — مثلاً یک ISP خاص — ریشه را سریع‌تر پیدا می‌کنید. اصول ثبت لاگ سرور را در بررسی خطاهای سرور در لاگ‌ها آورده‌ام.

اگر در پروژه‌ای با مشکل 408 دست‌وپنجه نرم کرده‌اید، برای من جالب است بدانم کدام لایه بیشترین وقت شما را گرفت: شبکه کاربر، پیکربندی وب‌سرور، CDN یا لایه بدنه درخواست. تجربه‌تان را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر نشانه‌ای کشف کرده‌اید که در این فهرست نبوده. همین نشانه‌ها، دقیق‌ترین راهنمای نفر بعدی‌اند. ⏱️