خطای 504 زمانی رخ می‌دهد که یک دروازه یا پراکسی، پاسخ لازم را در زمان تعیین‌شده از سرویس پشت خود دریافت نکند. در وردپرس، این مسیر ممکن است از CDN به وب‌سرور و از آنجا به PHP-FPM یا سرویس دیگری برسد. افزایش حافظه یا timeout پیش از تشخیص لایه خطا، معمولاً علت را پنهان می‌کند و ممکن است تعداد پردازش‌های معطل را بیشتر کند.
ابتدا مشخص کنید کدام درخواست شکست می‌خورد
نشانی صفحه، زمان دقیق همراه منطقه زمانی، وضعیت ورود کاربر و عملیاتی را که انجام داده‌اید ثبت کنید. خطا در یک خروجی گزارش با خطا در همه صفحات یکسان نیست. در درخواست خرید یا پرداخت، پیش از تکرار عملیات، وضعیت سفارش را بررسی کنید تا اقدام تکراری ایجاد نشود.
| نشانه | مسیر بررسی |
|---|---|
| فقط یک گزارش یا درون‌ریزی طولانی | پردازش زمان‌بر، query یا سرویس بیرونی |
| خطا در کل سایت و پیشخوان | ظرفیت پردازش، PHP-FPM، دیتابیس یا ارتباط شبکه |
| صفحه دارای نام CDN یا شناسه درخواست | لاگ همان ارائه‌دهنده و ارتباط با origin |
از لاگ‌ها به علت برسید
در هاست اشتراکی، زمان و URL را برای پشتیبانی ارسال کنید و لاگ همان بازه را بخواهید؛ ارسال رمز دیتابیس یا فایل کامل تنظیمات لازم نیست. در سرور مدیریتی، نام سرویس PHP-FPM و مسیر لاگ را از پیکربندی واقعی پیدا کنید. نمونه زیر برای سرویسی با نام php8.3-fpm در Ubuntu است؛ روی سیستم دیگر نام را کپی نکنید.
sudo systemctl status php8.3-fpm --no-pager
sudo journalctl -u php8.3-fpm --since "15 minutes ago" --no-pager
sudo nginx -tپیام upstream timed out را با زمان درخواست تطبیق دهید. تعداد workerهای اشباع، مصرف حافظه، query کند و تماس طولانی با API بیرونی، هرکدام راه‌حل متفاوت دارند. پیش از انتشار لاگ، داده مشتری، توکن و مسیرهای حساس را حذف کنید.
رفع مشکل بر اساس لایه ایجادکننده
- اگر فقط یک افزونه یا عملیات خاص درگیر است، آن را روی کپی آزمایشی بازتولید و تغییر اخیر را بررسی کنید. غیرفعال‌کردن هم‌زمان همه امکانات سایت زنده، تشخیص علت را دشوار می‌کند.
- اگر دیتابیس کند است، query و شاخص مرتبط بررسی شود؛ تعمیر تصادفی همه جدول‌ها درمان عمومی 504 نیست.
- برای خروجی سنگین یا پردازش انبوه، کار را به دسته‌های کوچک یا صف پس‌زمینه منتقل کنید. درخواست وب نباید تا پایان یک کار طولانی معطل بماند.
- اگر CDN درگیر است، سلامت origin، قوانین دسترسی و اتصال شبکه را بررسی کنید. خاموش‌کردن دائمی CDN یا حفاظت شبکه، جایگزین تشخیص نیست.
چه زمانی تغییر timeout منطقی است؟
تنها وقتی زمان طبیعی یک عملیات مشخص را می‌دانید و ظرفیت سرویس کافی است، افزایش محدود timeout را بررسی کنید. در Nginx، proxy_read_timeout برای پراکسی HTTP و fastcgi_read_timeout برای FastCGI است؛ این دو را جابه‌جا به کار نبرید. محدودیت PHP، PHP-FPM و CDN نیز مستقل‌اند. پس از تغییر پیکربندی، ابتدا آزمون syntax و سپس reload کنترل‌شده لازم است.
از کجا بفهمیم مشکل رفع شده است؟
همان URL و همان عملیات را با حجم مشابه دوباره آزمایش کنید؛ درخواست‌های موفق، زمان پاسخ و مصرف منابع باید هم‌زمان بهتر شوند. اگر فقط خطا دیرتر ظاهر می‌شود، علت هنوز رفع نشده است. تغییر را همراه زمان، مقدار قبلی و روش بازگشت ثبت کنید.
مطالعه مرتبط
منابع و مستندات
بازبینی محتوا و منابع: ۲۶ مهر ۱۴۰۵. دستورهای نمونه برای محیط مشخص‌شده‌اند؛ پیش از استفاده روی سرویس عملیاتی، سازگاری محیط و نسخه پشتیبان را بررسی کنید.
