ورود ثبت نام

ارور 504 gateway timeout: تشخیص، رفع و پیشگیری گام‌به‌گام

تیم فرتاک سرور
1405/8/6 3 بازدید آموزش
ارور 504 gateway timeout: تشخیص، رفع و پیشگیری گام‌به‌گام

ارور 504 gateway timeout: تشخیص، رفع و پیشگیری گام‌به‌گام

وقتی با پیام «ارور 504 gateway timeout» مواجه می‌شوید، یعنی یک نقطه میانی (پراکسی، دروازه یا تعادل‌کننده بار) نتوانسته در بازه زمانی مشخص از سرور پس‌زمینه پاسخ دریافت کند. این راهنمای کاربردی چگونگی شناسایی منشأ مشکل، انجام اقدامات فوری و پیاده‌سازی راهکارهای پایدار برای جلوگیری از بازگشت خطا را به‌صورت مرحله‌به‌مرحله توضیح می‌دهد.

مفهوم کلی و سناریوهای معمول ارور 504 gateway timeout

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

سناریوهای متداول

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

ارور 504 gateway timeout: چک‌لیست گام‌به‌گام برای علت‌یابی

برای عیب‌یابی منظم، این چک‌لیست را دنبال کنید تا سریع‌تر محل شکست را شناسایی و رفع کنید. در هر مرحله، هدف تعیین کنید که آیا مشکل در نقطه میانی است یا در سرور بک‌اند یا شبکه بین آن‌ها.

  1. تعیین دامنه تاثیر: آیا خطا برای همه کاربران رخ می‌دهد یا گروهی مشخص؟ بررسی کنید از چند شبکه (شرکت میزبان، موبایل، VPN) و چند مرورگر درخواست ارسال شود تا الگوی خطا مشخص شود.
  2. بررسی لاگ‌ها همزمان: لاگ‌های نقطه میانی (پراکسی/تعادل‌کننده)، لاگ سرور اپلیکیشن و لاگ سرویس‌های وابسته را با هم مقایسه کنید تا زمان‌های درخواست (request_time) و زمان پاسخ upstream مشخص شود.
  3. پایش منابع سرور: مصرف CPU، حافظه، صف‌های پردازش، اتصالات هم‌زمان و نرخ خروجی I/O دیسک را کنترل کنید. شاخص‌های پُربسامد نشان‌دهنده مشکل مقیاس‌پذیری هستند.
  4. تست اتصال شبکه: از ابزارهای traceroute و mtr برای دنبال کردن مسیر بین نودها استفاده کنید و تاخیر یا افت بسته‌ها را مشخص کنید.
  5. اندازه‌گیری زمان اجرای عملیات: برای endpointهایی که بار محاسباتی یا دسترسی به منابع خارجی دارند، زمان واقعی اجرای عملیات را اندازه‌گیری کنید تا ببینید آیا نیاز به async/queue دارد یا خیر.
  6. بررسی تنظیمات timeout: timeout در پراکسی/تعادل‌کننده، کلاینت و سرور را بازبینی کنید و آن‌ها را با زمان‌های واقعی مقایسه کنید.
  7. آزمون وابستگی‌ها: بررسی کنید آیا سرویس‌های خارجی یا دیتابیس‌ها در همان بازه دچار خطا هستند؛ گاهی API خارجی دیر پاسخ می‌دهد و باعث 504 می‌شود.

نمونه لاگ و نحوه خواندن آن

504  -  - [12/Oct/2025:10:15:32 +0000] "GET /api/report HTTP/1.1" 504 0 "-" "HealthChecker/1.0"
upstream_response_time: 30.120
request_time: 30.125

در مثال بالا، upstream_response_time نشان می‌دهد سرور بک‌اند حدود 30 ثانیه برای پاسخ صرف کرده است؛ این مقدار از timeout تعیین‌شده در نقطه میانی بیشتر بوده و باعث ارور 504 شده است.

دستورات و تست‌های عملی برای عیب‌یابی سریع

در ادامه چند فرمان و تست کاربردی که می‌توانید از کلاینت و از روی نودهای داخلی اجرا کنید تا سرعت عیب‌یابی افزایش یابد:

  • تست اولیه از کلاینت:
    curl -I --max-time 15 https://service-host.local/path
    اگر اتصال قطع شود یا 504 دریافت کنید، باید تنظیمات timeout و مسیر شبکه بررسی شود.
  • تست از نود پراکسی به بک‌اند:
    curl -v --connect-timeout 5 --max-time 60 http://internal-backend:8080/health
    این فرمان نشان می‌دهد آیا نقطه میانی می‌تواند به بک‌اند متصل شده و چقدر زمان می‌برد.
  • ردیابی مسیر شبکه:
    traceroute internal-backend
    کندی یا از دست رفتن بسته‌ها در میان مسیر را نشان می‌دهد.
  • پایش زمان پاسخ واقعی: با اجرای آزمون‌های بار سبک (مثلاً 10-50 درخواست همزمان) زمان P95 و P99 را برای endpointهای حیاتی اندازه‌گیری کنید.

پیکربندی نمونه برای افزایش timeout و نکات ایمن

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

# تنظیمات پراکسی (نمونه)
proxy_connect_timeout 10s;
proxy_read_timeout 90s;
proxy_send_timeout 90s;

نکات ایمنی و عملی:

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

راهکارهای کوتاه‌مدت و بلندمدت برای کاهش وقوع ارور 504 gateway timeout

اقدامات فوری (کوتاه‌مدت)

  • راه‌اندازی مجدد کنترل‌شده سرویس‌های مشکوک یا نودهای پراکسی در ساعات کم‌تری مصرفی.
  • افزایش موقت timeout در نقطه میانی تا زمان پایدارسازی بک‌اند.
  • فعال‌سازی حالت read-only یا پاسخ سبک برای endpointهای غیرضروری تا منابع آزاد شوند.

اقدامات پایدار (بلندمدت)

  • پیاده‌سازی کش لایه‌ای (در لایه CDN یا اپلیکیشن) برای کاهش تعداد درخواست‌های پردازشی به بک‌اند.
  • استفاده از صف‌بندی و پردازش ناهمزمان برای کارهای سنگین که نیاز به پاسخ فوری ندارند.
  • افزایش مقیاس (افقی یا عمودی) بر اساس الگوهای بار واقعی و تست بار منظم.
  • بهینه‌سازی پرس‌وجوها و کاهش زمان اجرای عملیات در دیتابیس و سرویس‌ها.
  • تعریف SLO/SLI مرتبط با زمان پاسخ و نرخ خطا (مثلاً P95 < 300ms برای endpoint حیاتی).

تجربه کاربر و طراحی پیام خطا هنگام ارور 504 gateway timeout

وقتی «ارور 504 gateway timeout» رخ می‌دهد، نمایش پیام مناسب به کاربر اهمیت زیادی دارد. پیام باید ساده، غیرتهدیدکننده و شامل اقدامات پیشنهادی باشد تا تجربه کاربری حفظ شود و از اطلاعات فنی حساس پرهیز شود.

نمونه پیام کاربرپسند

«در دریافت پاسخ اختلال رخ داده است. لطفاً چند دقیقه بعد تلاش کنید یا صفحه را بازنشانی کنید. اگر مشکل ادامه داشت، با پشتیبانی تماس بگیرید.»

پایش، هشداردهی و کتابچه عملیات (Runbook)

سامانه هشدار باید بین افزایش موقتی خطا و خطای پایدار تمایز قائل شود تا عملیات پاسخ‌دهی مؤثر باشد. نمونه قوانین و پارامترها:

  • آلارم وقتی نرخ خطاهای 5xx در 5 دقیقه به بیش از 1% برسد.
  • هشدار سطح بالا وقتی P99 زمان پاسخ برای endpoint حیاتی از 3 ثانیه فراتر رود.
  • آزمون‌های سلامت زمان‌بندی‌شده هر دقیقه برای endpointهای کلیدی و ثبت نتایج برای تحلیل روند.

نمونه Runbook برای پاسخ به ارور 504

  1. بررسی داشبوردهای مانیتورینگ برای یافتن افزایش نرخ 504 و شاخص‌های مرتبط.
  2. مشاهده لاگ‌های نقطه میانی برای upstream_response_time و request_time.
  3. اجرای دستورات تست اتصال و زمان پاسخ از نودهای مختلف.
  4. در صورت نیاز، افزایش موقت timeout و اطلاع به تیم توسعه برای رفع ریشه‌ای.
  5. در صورت تشخیص مشکل شبکه، اطلاع به تیم زیرساخت برای بررسی روتینگ و لینک‌ها.

پرسش‌های متداول (FAQ)

آیا ری‌فرش صفحه می‌تواند ارور 504 gateway timeout را رفع کند؟

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

تفاوت ارور 504 با ارورهای دیگر 5xx چیست؟

504 مخصوص زمان‌تمامی انتظار برای پاسخ است. ارورها دیگر 5xx ممکن است نشان‌دهنده پاسخ نامعتبر یا عدم دسترسی به سرویس باشند؛ بنابراین استراتژی عیب‌یابی برای هر کدام متفاوت است.

چه زمانی باید با تیم شبکه یا پشتیبانی تماس بگیرم؟

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

منابع و مراجع

برای تعریف رسمی وضعیت HTTP 504 و شرح استاندارد می‌توانید به این مرجع معتبر مراجعه کنید: توضیحات وضعیت 504.

جمع‌بندی: کاهش و مدیریت ارور 504 gateway timeout

در جمع‌بندی، «ارور 504 gateway timeout» نشانه ناتوانی نقطه میانی در دریافت پاسخ از سرور بک‌اند در بازه زمانی مشخص است. برای رفع سریع ابتدا چک‌لیست علت‌یابی (بررسی دامنه تاثیر، لاگ‌ها، مانیتورینگ و شبکه) را اجرا کنید. اقدامات کوتاه‌مدت مانند افزایش محدود timeout یا راه‌اندازی مجدد کنترل‌شده ممکن است مشکل را موقتاً کاهش دهد، اما راه‌حل‌های پایدار شامل کش‌گذاری مناسب، صف‌بندی کارهای طولانی، بهینه‌سازی عملکرد بک‌اند و مانیتورینگ هوشمند است. اجرای این رویکردها باعث کاهش نرخ وقوع ارور 504 gateway timeout و بهبود تجربه کاربری خواهد شد.

برچسب‌ها: 378