خطای 524 A Timeout Occurred یکی از آن خطاهایی است که وقتی در داشبورد Cloudflare با آن مواجه می‌شوم، به‌جای نگرانی، کنجکاو می‌شوم؛ چون این خطا به من می‌گوید سرور زنده است، اتصال TCP برقرار شده، اما یک جای کار در لایه اپلیکیشن به قدری کند است که پاسخ HTTP به موقع به لبه Cloudflare نمی‌رسد. اولین باری که با این خطا روبه‌رو شدم، در یک فروشگاه ووکامرس بود که در صفحه پرداخت، اسکریپت محاسبه مالیات تا بی‌نهایت معلق می‌ماند و Cloudflare پس از ۱۰۰ ثانیه پرونده را می‌بست.

خطای 524 دقیقاً چیست و چگونه با 522 تفاوت دارد؟

خطای 524 A Timeout Occurred یک کد وضعیت اختصاصی Cloudflare است که در خانواده کدهای 52x قرار می‌گیرد، اما برخلاف 521 و 522 که به فاز CONNECT مربوط می‌شوند، 524 در فاز READ رخ می‌دهد. این تفاوت آن‌قدر مهم است که اگر آن را نادیده بگیرید، تمام تلاش‌های عیب‌یابی شما به بیراهه می‌رود. توضیح دقیق‌تر این است که Cloudflare به عنوان یک Reverse Proxy، ابتدا یک اتصال TCP (Transmission Control Protocol) با سرور مبدأ (origin) برقرار می‌کند. اگر این اتصال در بازه زمانی مشخص برقرار نشود، خطای 522 (Connection Timed Out) رخ می‌دهد.

اما وقتی خطای 524 دریافت می‌کنید، معنایش این است که اتصال TCP با موفقیت برقرار شده، درخواست HTTP ارسال شده، اما سرور مبدأ شما در مدت زمان مشخصی — که به طور پیش‌فرض حدود ۱۰۰ ثانیه است — پاسخ HTTP خود را — یعنی حتی هدرهای اولیه پاسخ — ارسال نکرده است. بنابراین Cloudflare اتصال را می‌بندد و به کاربر پیام 524 را نمایش می‌دهد.

این تمایز را می‌توان با یک مثال ساده روشن کرد: تصور کنید به یک رستوران زنگ می‌زنید. اگر کسی تلفن را جواب ندهد و شما پس از چندین بار زنگ زدن قطع کنید، معادل خطای 522 است. اما اگر کسی تلفن را جواب دهد، ولی وقتی سفارش خود را می‌دهید، آن‌قدر طول بکشد تا آشپز جواب شما را بدهد که شما خودتان قطع کنید، این معادل خطای 524 است. در حالت اول، مشکل در برقراری تماس است؛ در حالت دوم، مشکل در سرعت پاسخ‌دهی است.

از منظر مهندسی، خطای 524 نشان می‌دهد که سرور شما هم زنده است، هم به بسته‌های SYN پاسخ داده، هم اتصال را پذیرفته، اما پردازش درخواست بیش از حد طول کشیده است. این طولانی شدن معمولاً در یکی از این لایه‌ها رخ می‌دهد: لایه PHP (اجرای اسکریپت)، لایه Database (کوئری‌های کند)، لایه Network (فراخوانی سرویس‌های خارجی)، یا لایه System (اشباع منابع سرور). برخلاف خطای خطای 522 Connection Timed Out، در اینجا مسئله فایروال یا DNS نیست؛ مسئله «کندی» است، نه «عدم دسترسی».

نکته مهم دیگر این است که مقدار پیش‌فرض Timeout در Cloudflare برای پلن‌های رایگان، Pro و Business حدود ۱۰۰ ثانیه است، اما در پلن Enterprise قابل تنظیم است. اگر مدتی روی این عدد فکر کنید، متوجه می‌شوید که ۱۰۰ ثانیه برای یک درخواست وب، عملاً یک ابدیت است. هیچ کاربری حاضر نیست بیش از چند ثانیه منتظر بارگذاری یک صفحه بماند. بنابراین خطای 524 معمولاً نشانه یک مشکل جدی در کارایی سرور است، نه یک نوسان موقت.

ریشه‌های اصلی بروز خطای 524 A Timeout Occurred

در طول سال‌ها کار روی پروژه‌های وردپرسی، ووکامرس، و اپلیکیشن‌های مبتنی بر PHP و Python، الگوهای مشخصی از علل بروز این خطا را شناسایی کرده‌ام. مهم است بدانید که خطای 524 تقریباً همیشه ریشه در یک فرآیند طولانی‌مدت دارد که در لایه اپلیکیشن اجرا می‌شود، نه در لایه شبکه. در ادامه شایع‌ترین ریشه‌ها را با جزئیات فنی بررسی می‌کنم.

۱. کوئری‌های کند دیتابیس (Slow Database Queries)

شایع‌ترین و در عین حال مرموزترین علت خطای 524، وجود کوئری‌های SQL است که در بازه‌های طولانی اجرا می‌شوند. این کوئری‌ها ممکن است در طول توسعه و روی یک دیتابیس کوچک در کسری از ثانیه اجرا شوند، اما روی یک دیتابیس واقعی با میلیون‌ها ردیف، ده‌ها ثانیه یا حتی چند دقیقه طول بکشند. به‌ویژه در ووکامرس، جداول wp_postmeta و wp_options می‌توانند به‌شدت حجیم شوند و کوئری‌های بدون ایندکس روی آن‌ها فاجعه‌بار شوند.

برای مثال، یک کوئری SELECT ساده روی جدول wp_postmeta بدون ایندکس مناسب، می‌تواند در چند ثانیه به اتمام برسد، اما همین کوئری در یک حلقه WP_Query روی هزاران محصول، صدها ثانیه طول بکشد. اگر این الگو را در پروژه خود مشاهده می‌کنید، مقاله بهینه‌سازی کوئری‌های وردپرس با کدنویسی راهکارهای عملی برای ایندکس‌گذاری و کش کردن کوئری‌ها ارائه می‌دهد.

۲. اسکریپت‌های PHP با اجرای طولانی

هر اسکریپت PHP که در سرور شما اجرا می‌شود، یک سقف زمانی دارد که با پارامتر max_execution_time در فایل php.ini تعریف می‌شود. مقدار پیش‌فرض این پارامتر معمولاً ۳۰ ثانیه است، اما در برخی هاست‌ها به ۶۰ یا ۱۲۰ ثانیه هم افزایش یافته. اگر یک اسکریپت از این سقف عبور کند، PHP خودش اجرای آن را متوقف می‌کند و خطای Maximum execution time exceeded را در لاگ ثبت می‌کند. اما نکته مهم این است که اگر این توقف به‌درستی مدیریت نشود، سرور ممکن است تا زمانی که خودش Timeout کند، بی‌پاسخ بماند — و اینجاست که Cloudflare خطای 524 را گزارش می‌کند.

نمونه‌های شایع اسکریپت‌های طولانی در وردپرس عبارتند از: فرآیندهای Import محتوا، همگام‌سازی با سرویس‌های خارجی (مانند درگاه‌های پرداخت یا CRM)، تولید Sitemap برای سایت‌های بزرگ، اجرای افزونه‌های بکاپ، و اسکریپت‌های ارسال ایمیل گروهی. اگر با خطای Maximum execution time در PHP مواجه می‌شوید، مقاله چگونه خطای Maximum execution time در PHP را رفع کنیم؟ گام‌به‌گام این موضوع را بررسی کرده است.

۳. فراخوانی سرویس‌های خارجی (External API Calls)

یکی از ریشه‌های پنهان خطای 524، انتظار طولانی برای پاسخ از یک API خارجی است. فرض کنید سایت شما در هر بار بارگذاری صفحه، به یک سرویس خارجی — مثلاً یک API نرخ ارز، یک سرویس احراز هویت، یا یک درگاه پرداخت — درخواست می‌فرستد. اگر آن سرویس خارجی کند پاسخ دهد یا کاملاً از دسترس خارج شود، اسکریپت PHP شما منتظر می‌ماند. اگر این انتظار از سقف Timeout Cloudflare عبور کند، خطای 524 رخ می‌دهد.

نکته فنی مهم: در PHP، توابعی مانند file_get_contents() و curl_exec() هر دو دارای پارامتر Timeout هستند. اگر این پارامترها را تنظیم نکنید، PHP ممکن است تا مقدار پیش‌فرض خود سرور منتظر بماند. همیشه توصیه می‌کنم برای فراخوانی‌های خارجی، یک Timeout صریح تعریف کنید:

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 3);
$response = curl_exec($ch);
curl_close($ch);

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

۴. اشباع منابع سرور (CPU، RAM، I/O)

گاهی اوقات، ریشه خطای 524 نه در یک اسکریپت خاص، بلکه در اشباع شدن منابع سرور است. وقتی CPU به طور مداوم در حد ۱۰۰٪ کار می‌کند، حافظه RAM پر شده است و عملیات I/O دیسک به دلیل Swap شدید کند شده، هر درخواستی که به سرور برسد، بسیار کند پردازش می‌شود. حتی یک اسکریپت بهینه هم در چنین شرایطی ممکن است از سقف Timeout عبور کند.

این وضعیت در هاست اشتراکی و VPSهای کم‌منبع بسیار رایج است. اگر سایت شما در ساعات خاصی از شبانه‌روز (مثلاً هنگام اجرای Cron Jobهای سنگین) با خطای 524 مواجه می‌شود، احتمالاً با اشباع منابع روبه‌رو هستید. برای تشخیص دقیق، از دستوراتی مانند top، htop، iostat و vmstat استفاده کنید.

۵. بارگذاری فایل‌های حجیم یا دانلودهای طولانی

اگر سایت شما فایل‌های حجیم (مثلاً ویدئو، ISO، یا آرشیو) را برای دانلود ارائه می‌دهد و این فایل‌ها از روی سرور مبدأ سرو می‌شوند، ممکن است با خطای 524 روبه‌رو شوید. علت این است که Cloudflare تا زمانی که پاسخ کامل از سرور مبدأ دریافت نکند، اتصال را زنده نگه می‌دارد. اگر دانلود یک فایل ۱۰۰ مگابایتی روی یک اینترنت کند سمت سرور بیش از ۱۰۰ ثانیه طول بکشد، خطای 524 رخ می‌دهد.

راه‌حل توصیه‌شده، انتقال فایل‌های حجیم به سرویس‌های CDN اختصاصی (مانند Cloudflare R2، Amazon S3، یا Bunny CDN) و لینک دادن به آن‌ها است. این کار بار سرور شما را کاهش می‌دهد و مشکل 524 را برای این نوع درخواست‌ها برطرف می‌کند.

۶. حمله DDoS لایه اپلیکیشن (Application Layer)

حملات DDoS (Distributed Denial of Service) در لایه اپلیکیشن — که به آن Layer 7 Attack هم می‌گویند — می‌توانند سرور شما را بدون آنکه پهنای باند را اشباع کنند، از کار بیندازند. در این نوع حملات، مهاجم تعداد زیادی درخواست به یک Endpoint سنگین (مثلاً صفحه جستجو یا افزودن به سبد خرید) می‌فرستد که هرکدام به کوئری‌های دیتابیس و محاسبات سنگین نیاز دارند. سرور شما یکی‌یکی این درخواست‌ها را پردازش می‌کند و به‌سرعت از پا درمی‌آید.

Cloudflare در پلن‌های Pro و بالاتر، قابلیت WAF (Web Application Firewall) و Rate Limiting دارد که می‌تواند این نوع حملات را قبل از رسیدن به سرور شما مسدود کند. اما در پلن رایگان، باید خودتان با ابزارهایی مانند fail2ban یا افزونه‌های امنیتی وردپرس از سرور محافظت کنید. مقاله چگونه سایت را از حملات سایبری محافظت کنیم به طور مفصل این موضوع را بررسی کرده است.

روش‌های عملی تشخیص ریشه خطای 524

عیب‌یابی خطای 524 بدون روش‌مندی، می‌تواند به یک بازی بی‌پایان تبدیل شود. در طول سال‌ها، یک چارچوب تشخیصی را در ذهنم شکل داده‌ام که در اکثر پروژه‌ها جواب می‌دهد. این چارچوب بر پایه جداسازی لایه‌ها بنا شده است: از لبه Cloudflare به سمت هسته سرور.

گام اول: تأیید اینکه خطا از سمت سرور است یا Cloudflare

اولین کاری که باید انجام دهید، این است که بررسی کنید آیا خطای 524 از خود Cloudflare می‌آید یا از سرور شما. اگر صفحه خطا ظاهر و برند Cloudflare را نشان می‌دهد و در پایین آن عبارت «Cloudflare Ray ID» دیده می‌شود، خطا از سمت Cloudflare است. در غیر این صورت، ممکن است خطای 504 (Gateway Timeout) از سمت خود سرور یا پراکسی میانی باشد.

در پنل Cloudflare، بخش Analytics → Traffic را باز کنید. در نمودار Status Codes، خطاهای 524 را فیلتر کنید. اگر تعداد خطاهای 524 در یک بازه زمانی مشخص بالا رفته است، می‌توانید آن بازه را با رویدادهای سرور (مثل اجرای یک Cron Job یا انتشار یک پست سنگین) تطبیق دهید.

گام دوم: بررسی لاگ‌های سرور

لاگ‌های سرور بهترین دوست شما در این مرحله هستند. در Nginx، فایل /var/log/nginx/access.log نشان می‌دهد که کدام درخواست‌ها در بازه خطای 524 دریافت شده‌اند و چه مدت طول کشیده‌اند. پارامتر $request_time یا $upstream_response_time در فرمت لاگ، این مدت زمان را نشان می‌دهد. در Apache، پارامتر %D در فایل access.log مدت زمان پردازش هر درخواست را بر حسب میکروثانیه ثبت می‌کند.

برای مثال، برای یافتن درخواست‌هایی که بیش از ۳۰ ثانیه طول کشیده‌اند در Nginx:

awk '$NF > 30 {print}' /var/log/nginx/access.log | tail -50

اگر در لاگ‌ها مشاهده کردید که یک Endpoint خاص (مثلاً /wp-admin/admin-ajax.php با یک action مشخص) به طور مداوم زمان اجرای بالایی دارد، ریشه خطای 524 را پیدا کرده‌اید. مقاله چگونه خطاهای سرور را در لاگ‌ها بررسی کنیم؟ روش‌های دقیق‌تری برای تحلیل لاگ‌ها ارائه می‌دهد.

گام سوم: فعال‌سازی Slow Query Log در MySQL

اگر شک دارید که کوئری‌های کند دیتابیس باعث خطای 524 می‌شوند، باید Slow Query Log را فعال کنید. این قابلیت MySQL/MariaDB، هر کوئری که بیش از یک آستانه مشخص (مثلاً ۲ ثانیه) اجرا شود را در یک فایل ثبت می‌کند. برای فعال‌سازی، این خطوط را به فایل my.cnf اضافه کنید:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
log_queries_not_using_indexes = 1

پس از ری‌استارت MySQL، فایل slow.log به مرور پر می‌شود. با ابزار mysqldumpslow یا pt-query-digest می‌توانید کندترین کوئری‌ها را استخراج کنید. این کوئری‌ها معمولاً همان‌هایی هستند که به خطای 524 منجر می‌شوند.

گام چهارم: پروفایل کردن PHP با Xdebug یا Blackfire

اگر کوئری‌های دیتابیس سریع هستند اما سایت همچنان با خطای 524 مواجه می‌شود، احتمالاً یک اسکریپت PHP در جایی طولانی اجرا می‌شود. ابزار Xdebug در حالت Profiler می‌تواند تمام توابع اجراشده در یک درخواست و مدت زمان هرکدام را ثبت کند. ابزار Blackfire.io نیز برای این کار بسیار قدرتمند است و در پروژه‌های حرفه‌ای توصیه می‌شود.

نمونه‌ای از فعال‌سازی Xdebug Profiler در فایل php.ini:

xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug
xdebug.profiler_output_name = cachegrind.out.%p

پس از اجرای درخواست، فایل خروجی را می‌توانید در نرم‌افزار KCachegrind یا QCachegrind باز کنید و توابع پرهزینه را شناسایی کنید.

گام پنجم: مانیتورینگ لحظه‌ای منابع

اگر ریشه مشکل، اشباع منابع سرور است، باید در لحظه بروز خطا، وضعیت سرور را ببینید. ابزارهایی مانند Netdata، Prometheus + Grafana، یا سرویس‌های تجاری مانند New Relic و Datadog می‌توانند به شما نشان دهند که در لحظه بروز خطای 524، CPU، RAM، دیسک و شبکه در چه وضعیتی بوده‌اند. اگر خودتان سرور را مدیریت می‌کنید، مقاله مانیتورینگ سرور دقیقاً چگونه انجام می‌شود؟ راهنمای جامعی برای راه‌اندازی این ابزارها ارائه می‌دهد.

راه‌حل‌های اصولی و مرحله‌به‌مرحله رفع خطای 524

پس از تشخیص ریشه، نوبت به راه‌حل می‌رسد. در این بخش، راه‌حل‌ها را از کوتاه‌مدت به بلندمدت و از سطح اپلیکیشن به سطح زیرساخت مرتب کرده‌ام.

راه‌حل اول: کاهش مقدار Timeout در اسکریپت‌های خارجی

همان‌طور که اشاره شد، یکی از ریشه‌های شایع 524، انتظار طولانی برای پاسخ از سرویس‌های خارجی است. اولین قدم، بازبینی تمام فراخوانی‌های curl، file_get_contents، wp_remote_get و wp_remote_post در کد شماست. هر کدام باید یک timeout صریح داشته باشند که از Timeout کلی Cloudflare کمتر باشد. مقدار پیشنهادی من، بین ۵ تا ۱۰ ثانیه است:

$response = wp_remote_get( $url, array(
    'timeout'     => 8,
    'redirection' => 3,
) );

با این تنظیمات، اگر سرویس خارجی پاسخ ندهد، وردپرس در نهایت خطای WP_Error برمی‌گرداند و شما می‌توانید یک پیام جایگزین به کاربر نشان دهید، به جای اینکه کل صفحه معلق بماند.

راه‌حل دوم: انتقال کارهای سنگین به Background

اگر بخشی از فرآیند شما به طور ذاتی طولانی است — مثلاً ارسال ایمیل به ۱۰,۰۰۰ مشترک، تولید گزارش پیچیده، یا همگام‌سازی با یک سیستم خارجی — نباید آن را در چرخه درخواست کاربر اجرا کنید. این کارها باید به پس‌زمینه منتقل شوند. در وردپرس، ابزارهایی مانند Action Scheduler (که توسط ووکامرس هم استفاده می‌شود) و WP Background Processing برای این کار طراحی شده‌اند.

الگوی کلی این است که درخواست کاربر فقط یک Job را در صف قرار می‌دهد و بلافاصله پاسخ می‌گیرد. سپس یک Cron Job یا یک Worker در پس‌زمینه، آن Job را پردازش می‌کند. به این ترتیب، کاربر هرگز منتظر عملیات طولانی نمی‌ماند و خطای 524 رخ نمی‌دهد.

راه‌حل سوم: بهینه‌سازی کوئری‌های دیتابیس

اگر ریشه مشکل، کوئری‌های کند است، باید آن‌ها را بهینه کنید. اولین گام، اضافه کردن Index مناسب روی ستون‌هایی است که در WHERE، JOIN و ORDER BY استفاده می‌شوند. برای مثال، اگر روی جدول wp_postmeta کوئری‌های مکرر روی meta_key می‌زنید، یک ایندکس ترکیبی روی (meta_key, post_id) می‌تواند سرعت را چند برابر کند.

ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_post (meta_key, post_id);

گام دوم، کش کردن نتایج کوئری‌های پرتکرار است. در وردپرس، از Transients API می‌توانید برای این کار استفاده کنید:

$data = get_transient( 'my_expensive_query' );
if ( false === $data ) {
    $data = $wpdb->get_results( $sql );
    set_transient( 'my_expensive_query', $data, HOUR_IN_SECONDS );
}

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

راه‌حل چهارم: افزایش منابع سرور یا ارتقای هاست

اگر پس از بهینه‌سازی‌های بالا، همچنان با خطای 524 مواجه می‌شوید، احتمالاً سرور فعلی ظرفیت کافی ندارد. در این حالت، ارتقا به یک پلن بالاتر یا مهاجرت به یک VPS یا سرور اختصاصی توصیه می‌شود. پیش از این تصمیم، حتماً بررسی کنید که مصرف منابع فعلی شما چقدر است و چه مقدار رشد نیاز دارید. مقاله هاست چیست و چگونه انتخاب درستی داشته باشیم؟ معیارهای دقیقی برای این انتخاب ارائه می‌دهد.

راه‌حل پنجم: تنظیم PHP-FPM و Nginx برای تحمل بار بیشتر

اگر از PHP-FPM و Nginx استفاده می‌کنید، تنظیم دقیق این دو سرویس می‌تواند تأثیر شگرفی داشته باشد. در PHP-FPM، مقدار pm.max_children تعیین می‌کند که حداکثر چند فرآیند همزمان می‌توانند درخواست‌ها را پردازش کنند. اگر این مقدار خیلی کم باشد، درخواست‌ها در صف انتظار می‌مانند و ممکن است به Timeout منجر شوند. اگر خیلی زیاد باشد، سرور با کمبود RAM مواجه می‌شود. مقدار مناسب را با فرمول زیر محاسبه کنید:

pm.max_children = ( Total RAM - RAM for OS & services ) / Average PHP process size

در Nginx، پارامترهای fastcgi_read_timeout و proxy_read_timeout تعیین می‌کنند که Nginx چه مدت منتظر پاسخ از سمت FastCGI (یعنی PHP-FPM) یا پراکسی بماند. اگر این مقادیر کمتر از زمان اجرای اسکریپت شما باشند، Nginx قبل از اتمام کار، اتصال را قطع می‌کند و خطای 504 به Cloudflare برمی‌گرداند که آن هم در نهایت به 524 تبدیل می‌شود. مقدار پیشنهادی من، بین ۶۰ تا ۱۸۰ ثانیه است، بسته به نوع اسکریپت‌های شما.

راه‌حل ششم: استفاده از Cloudflare APO یا Cache Rules

برای سایت‌های وردپرسی و ووکامرسی، قابلیت Cloudflare APO (Automatic Platform Optimization) می‌تواند بار سرور را به‌شدت کاهش دهد. این سرویس، صفحات HTML را در لبه Cloudflare کش می‌کند و تنها برای بازدیدکنندگان وارد‌شده یا صفحات پویا به سرور مبدأ رجوع می‌کند. نتیجه این است که بار سرور شما برای بازدیدکنندگان عادی به‌شدت کاهش می‌یابد و احتمال خطای 524 کم می‌شود.

همچنین می‌توانید با Cache Rules در Cloudflare، تعیین کنید که کدام مسیرها کش شوند و کدام‌ها نه. برای مثال، صفحات /shop/ و /blog/ معمولاً قابل کش هستند، اما /cart/ و /checkout/ باید همیشه پویا بمانند.

راه‌حل هفتم: تنظیم Timeout Cloudflare (در پلن Enterprise)

اگر در پلن Enterprise هستید، می‌توانید مقدار Proxy Read Timeout را در تنظیمات Cloudflare افزایش دهید. مقدار پیش‌فرض ۱۰۰ ثانیه است، اما می‌توان آن را تا ۵,۰۰۰ ثانیه افزایش داد (البته توصیه نمی‌کنم). برای یافتن این تنظیم، به مسیر Support → Contact → Increase Timeout بروید یا از طریق تیکت با پشتیبانی Cloudflare تماس بگیرید.

اشتباهات رایج در مواجهه با خطای 524

در طول سال‌ها، اشتباهات تکراری زیادی را در مواجهه با این خطا دیده‌ام. این اشتباهات می‌توانند مشکل را بدتر کنند یا زمان عیب‌یابی را طولانی‌تر کنند.

اشتباه اول: افزایش کورکورانه max_execution_time

واکنش اولیه بسیاری از توسعه‌دهندگان، افزایش مقدار max_execution_time در PHP است. این کار ممکن است موقتاً خطای 524 را برطرف کند، اما ریشه مشکل — یعنی کندی اسکریپت — را حل نمی‌کند. در عمل، این کار فقط باعث می‌شود که اسکریپت کند شما به جای ۳۰ ثانیه، ۳۰۰ ثانیه اجرا شود و منابع سرور را برای مدت طولانی‌تری اشغال کند. نتیجه این است که سایر درخواست‌ها نیز در صف منتظر می‌مانند و مشکل بدتر می‌شود.

اشتباه دوم: نادیده گرفتن تفاوت 524 و 522 و 504

همان‌طور که پیش‌تر توضیح داده شد، خطای 524 در فاز READ رخ می‌دهد، در حالی که خطای 522 در فاز CONNECT و خطای 504 در لایه Gateway رخ می‌دهد. اگر با خطای 524 مواجه هستید اما راه‌حل‌های خطای 522 (مانند بررسی فایروال و Whitelist کردن IPها) را دنبال می‌کنید، هرگز به نتیجه نمی‌رسید. ابتدا باید نوع دقیق خطا را با بررسی صفحه خطای Cloudflare و کد آن تأیید کنید. مقاله خطای 521 Web Server Is Down و رفع خطای 504 Gateway Timeout تفاوت‌های این کدها را دقیق‌تر بررسی کرده‌اند.

اشتباه سوم: غیرفعال کردن Cloudflare به جای حل مشکل

وقتی خطای 524 ظاهر می‌شود، برخی توسعه‌دهندگان Cloudflare را غیرفعال می‌کنند و سایت را مستقیم به سرور مبدأ وصل می‌کنند. این کار فقط مشکل را پنهان می‌کند؛ چون در آن صورت، کاربران به جای خطای 524، خطای 504 Gateway Timeout یا حتی صفحه سفید می‌بینند. علاوه بر این، تمام مزایای CDN، WAF و کش Cloudflare را از دست می‌دهید. راه درست، حل ریشه‌ای مشکل و سپس بازگرداندن Cloudflare است.

اشتباه چهارم: بی‌توجهی به لاگ‌های PHP-FPM

بسیاری از توسعه‌دهندگان فقط به لاگ‌های Nginx یا Apache نگاه می‌کنند و لاگ‌های PHP-FPM را نادیده می‌گیرند. اما این لاگ‌ها می‌توانند هشدارهای مهمی درباره Slow Log و Timeout در سطح PHP-FPM ارائه دهند. برای فعال‌سازی Slow Log در PHP-FPM، این تنظیمات را به فایل پول www.conf اضافه کنید:

request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log

پس از فعال‌سازی، هر درخواستی که بیش از ۵ ثانیه طول بکشد، در این فایل ثبت می‌شود و می‌توانید پشته فراخوانی (Stack Trace) آن را ببینید.

اشتباه پنجم: استفاده نادرست از Cron Jobهای همزمان

وردپرس از WP-Cron برای اجرای وظایف زمان‌بندی‌شده استفاده می‌کند. اما WP-Cron در واقع با هر بار بازدید کاربر فعال می‌شود و می‌تواند چندین وظیفه را همزمان اجرا کند. اگر چندین Cron Job سنگین در یک بازه زمانی کوتاه تنظیم شده باشند، منابع سرور به‌شدت مصرف می‌شود و خطای 524 ظاهر می‌شود. راه‌حل، جایگزینی WP-Cron با یک Cron Job سیستمی واقعی است که در فواصل مشخص (مثلاً هر دقیقه) یک اسکریپت را اجرا می‌کند:

*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

و در فایل wp-config.php:

define( 'DISABLE_WP_CRON', true );

پرسش‌های پرتکرار درباره خطای 524

خطای 524 از سمت Cloudflare است یا سرور من؟

خطای 524 توسط Cloudflare نمایش داده می‌شود، اما ریشه آن تقریباً همیشه در سرور مبدأ شماست. Cloudflare در این خطا فقط نقش گزارش‌دهنده را دارد: به شما می‌گوید که سرور شما در مدت ۱۰۰ ثانیه به درخواست HTTP پاسخ نداده است. بنابراین، جستجوی راه‌حل باید در سرور مبدأ و اسکریپت‌های آن انجام شود، نه در Cloudflare.

تفاوت خطای 524 با 522 چیست؟

خطای 522 در فاز CONNECT رخ می‌دهد؛ یعنی Cloudflare حتی نتوانسته است اتصال TCP با سرور مبدأ را برقرار کند. خطای 524 در فاز READ رخ می‌دهد؛ یعنی اتصال TCP برقرار شده، درخواست HTTP ارسال شده، اما سرور مبدأ پاسخ HTTP را در موعد مقرر برنگردانده است. به بیان ساده، در 522 سرور «پاسخ نمی‌دهد» و در 524 «دیر پاسخ می‌دهد».

آیا خطای 524 در همه پلن‌های Cloudflare یکسان است؟

خیر. مقدار پیش‌فرض Timeout در پلن‌های Free، Pro و Business حدود ۱۰۰ ثانیه است. در پلن Enterprise، این مقدار قابل تنظیم است و می‌توان آن را تا ۵,۰۰۰ ثانیه افزایش داد. اما به‌طور کلی، افزایش Timeout فقط برای کارهای غیرتعاملی (مانند Webhookهای طولانی) منطقی است، نه برای درخواست‌های کاربر.

چگونه بفهمم کدام Endpoint باعث خطای 524 می‌شود؟

در پنل Cloudflare، بخش Analytics → Traffic را باز کنید. سپس در فیلتر Status Code، مقدار 524 را انتخاب کنید. در نمودارها می‌توانید ببینید که این خطاها روی کدام URLها متمرکز هستند. اگر یک Endpoint خاص بیشترین تعداد خطای 524 را دارد، آن Endpoint نقطه شروع عیب‌یابی است.

آیا افزونه‌های وردپرس می‌توانند باعث خطای 524 شوند؟

بله، و در واقع یکی از شایع‌ترین ریشه‌ها هستند. افزونه‌هایی که در هر بار بارگذاری، کوئری‌های سنگین دیتابیس اجرا می‌کنند یا با سرویس‌های خارجی ارتباط برقرار می‌کنند، می‌توانند سایت را در خطای 524 غرق کنند. برای شناسایی، افزونه‌ها را یک‌به‌یک غیرفعال کنید و بین هر تغییر، سایت را تست کنید. اگر با روش سیستماتیک آشنایی ندارید، مقاله چک‌لیست عیب‌یابی حرفه‌ای خطاهای وردپرس یک راهنمای کامل ارائه می‌دهد.

آیا برای رفع 524 باید Timeout Cloudflare را افزایش دهم؟

خیر، مگر اینکه مجبور باشید. افزایش Timeout Cloudflare فقط رنج کاربر را طولانی‌تر می‌کند و مشکل اصلی را برطرف نمی‌کند. اگر کاربر ۱۰۰ ثانیه منتظر بماند و سپس خطای 524 ببیند، با افزایش به ۲۰۰ ثانیه فقط ۱۰۰ ثانیه دیگر انتظار می‌کشد و باز هم خطا می‌بیند. راه‌حل درست، کاهش زمان اجرای اسکریپت است، نه افزایش سقف انتظار.

آیا افزایش max_execution_time در PHP مشکل 524 را حل می‌کند؟

معمولاً خیر. اگر سقف max_execution_time کمتر از Timeout Cloudflare باشد، PHP اول خطا می‌دهد و Cloudflare به جای 524، خطای 500 می‌بیند. اگر سقف بزرگ‌تر باشد، مشکل به 524 کشیده می‌شود. راه‌حل واقعی، بهینه‌سازی اسکریپت است تا در زمان کوتاه‌تری به اتمام برسد. برای جزئیات بیشتر، مقاله خطای کند شدن شدید سایت وردپرس را ببینید.

آیا خطای 524 می‌تواند به سئو آسیب بزند؟

بله. خزنده‌های موتور جستجو نیز در مواجهه با خطای 524، صفحه را به عنوان «در دسترس نبودن موقت» علامت می‌زنند. اگر این خطاها به طور مکرر رخ دهند، بودجه خزش (Crawl Budget) شما تلف می‌شود و رتبه سایت‌تان کاهش می‌یابد. به‌ویژه اگر صفحه‌ای که با 524 مواجه می‌شود، صفحه اصلی یا صفحه محصول باشد، اثر آن جدی‌تر است.

نگاه مهندسی پیشرفته به Timeout در لایه Origin

از دیدگاه یک مهندس ارشد زیرساخت، خطای 524 یک پنجره به وضعیت درونی سیستم شما باز می‌کند. این خطا به شما می‌گوید که در لایه اپلیکیشن، یک یا چند فرآیند وجود دارند که در زمان منطقی به اتمام نمی‌رسند. برای مهندسانی که در مقیاس بزرگ کار می‌کنند، تحلیل این خطا نباید به «کدام افزونه کند است؟» محدود شود، بلکه باید به سطح معماری سیستم گسترش یابد.

یکی از مفاهیم کلیدی در این سطح، Queueing Theory است. سرور شما یک ظرفیت مشخص برای پردازش همزمان درخواست‌ها دارد (تعداد Workerها در PHP-FPM یا Gunicorn). اگر نرخ ورود درخواست‌ها از نرخ پردازش آن‌ها بیشتر شود، صف انتظار به‌سرعت پر می‌شود و زمان انتظار هر درخواست به‌صورت نمایی رشد می‌کند. نتیجه، خطای 524 است، حتی اگر هر Worker به‌تنهایی سریع باشد. راه‌حل معماری این مسئله، اضافه کردن یک لایه Load Balancer یا Horizontal Scaling است.

مفهوم دیگر، Backpressure است. در سیستم‌های توزیع‌شده، اگر یک سرویس پایین‌دستی (مثلاً دیتابیس یا یک API خارجی) کند شود، این کندی به سرویس‌های بالادستی سرریز می‌کند. برای مهار این سرریز، باید مکانیزم‌های Circuit Breaker و Bulkhead را در معماری خود پیاده کنید. Circuit Breaker، پس از تعداد مشخصی خطای متوالی از یک سرویس، آن را موقتاً قطع می‌کند و به جای انتظار، سریع خطا برمی‌گرداند. Bulkhead، منابع هر بخش را جدا می‌کند تا مشکل یک بخش، کل سیستم را از کار نیندازد.

در محیط‌های Kubernetes، خطای 524 معمولاً به تنظیمات نادرست Readiness Probe و Liveness Probe مربوط می‌شود. اگر Probe شما با Timeout کوتاه تنظیم شده باشد، Pod را در حالت NotReady قرار می‌دهد و ترافیک به آن ارسال نمی‌شود. اگر با تعداد زیادی Pod در حالت NotReady مواجه شوید، Load Balancer ممکن است نتواند ترافیک را توزیع کند و خطای 524 ظاهر شود. توصیه می‌کنم در محیط‌های Kubernetes، مقدار timeoutSeconds و failureThreshold را با دقت تنظیم کنید و حتماً از Readiness Gates استفاده کنید.

در نهایت، برای مهندسانی که با دیتابیس‌های بزرگ کار می‌کنند، مفهوم N+1 Query Problem می‌تواند کلید حل خطای 524 باشد. در این الگوی ضدکارآمد، یک کوئری اصلی اجرا می‌شود و سپس به ازای هر ردیف نتیجه، یک کوئری دیگر اجرا می‌شود. نتیجه، انفجار تعداد کوئری‌ها و افزایش شدید زمان اجرا است. اگر در کد خود از ORMهایی مانند Eloquent یا Django ORM استفاده می‌کنید، حتماً از Eager Loading (متد with() در Laravel یا select_related() در Django) استفاده کنید تا این مشکل حل شود.

نتیجه‌گیری

خطای 524 A Timeout Occurred، برخلاف ظاهر هولناکش، در واقع یک هدیه است: این خطا دقیقاً به شما می‌گوید که سرور زنده است، شبکه سالم است، اما یک اسکریپت یا کوئری در جایی به‌شدت کند اجرا می‌شود. برخلاف خطای 522 که لایه‌های شبکه و فایروال را درگیر می‌کند، 524 شما را مستقیماً به سمت لایه اپلیکیشن هدایت می‌کند.

تجربه من در ده‌ها پروژه نشان داده است که بیش از ۷۰٪ خطاهای 524 با یکی از این سه اقدام حل می‌شود: محدود کردن Timeout فراخوانی‌های خارجی، بهینه‌سازی کوئری‌های دیتابیس، و انتقال کارهای سنگین به پس‌زمینه. برای رفع ریشه‌ای، باید به لایه‌های پایین‌تر معماری نیز نگاه کنید: تنظیمات PHP-FPM، پارامترهای Nginx، و در نهایت ظرفیت زیرساخت. تنها با این نگاه چندلایه است که می‌توانید از بازگشت خطا در ساعات اوج ترافیک جلوگیری کنید.

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