WIUNIX ACADEMY
عیب‌یابی خطاهای 502 و 504 در Nginx
صفحهٔ 2 از 3؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من5 مقدار قابل‌تغییر
قدم بعدی
عبارت دقیق خطا را در لاگ بخوانید
در /var/log/nginx/error.log فقط همان بازه و همان سرور را بررسی کنید. Connection refused ابتدا به نبود شنونده، آدرس اشتباه یا چرخهٔ اجرای برنامه اشاره می‌کند. عبارت while connecting یعنی اتصال هنوز کامل نشده؛ while reading response header یعنی پس از اتصال منتظر هدر بوده‌اید.
بسته‌شدن زودهنگام اتصال می‌تواند از crash یا اشتباه پروتکل باشد. یک خط قدیمی یا خطای دامنهٔ دیگر را به این درخواست نسبت ندهید. در نصب سفارشی، مسیر واقعی لاگ را در تنظیمات ابتدای آموزش وارد کنید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo tail -n 120 -- '/var/log/nginx/error.log'خطای هم‌زمان با درخواست پیدا شده و مرحله‌ای که ارتباط در آن شکست خورده روشن است.
اگر لاگ کافی نیست، زمان‌های لازم را اضافه کنید
اگر لاگ فعلی زمان اتصال و پاسخ را دارد، همان را استفاده کنید. در غیر این صورت، قطعهٔ بعدی را فقط برای بررسی کوتاه‌مدت اضافه کنید: تعریف قالب در بخش http و خط access_log در server یا location هدف قرار می‌گیرد. این قطعه جایگزین کل تنظیمات Nginx نیست.
قالب نمونه عمداً URL، پارامترها، کوکی، اطلاعات ورود و IP کاربر را ذخیره نمی‌کند. نسخهٔ قبل، مدت نگهداری و چرخش لاگ را مشخص کنید و فقط محل درست را ویرایش کنید.
محتوای فایل؛ این پنل را در ترمینال اجرا نکنید
# http context
log_format academy_phase escape=json
'{"id":"$request_id","status":$status,'
'"upstream":"$upstream_addr","upstream_status":"$upstream_status",'
'"connect":"$upstream_connect_time","header":"$upstream_header_time",'
'"response":"$upstream_response_time","total":"$request_time"}';
# affected server/location context only
access_log /var/log/nginx/academy-phase.log academy_phase;قدم بعدی
تنظیم تغییرکرده را قبل از reload بررسی کنید
این گام فقط زمانی لازم است که برای همین بررسی تنظیم لاگ را تغییر داده‌اید. ابتدا اعتبارسنجی بومی Nginx باید موفق شود؛ سپس reload انجام می‌شود. اگر خطای نحوی دارید، همان تغییر را اصلاح یا نسخهٔ قبل را برگردانید؛ restart کورکورانه کمکی نمی‌کند.
پس از reload، همان درخواست عمومی و خصوصی را تکرار کنید. موفقیت بررسی نحو، سالم‌بودن مسیر شبکه یا برنامه را ثابت نمی‌کند.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo nginx -t && sudo systemctl reload nginxاعتبارسنجی و reload موفق‌اند و نتیجهٔ درخواست تازه را می‌توان با لاگ تازه مقایسه کرد.
زمان هر تلاش را جدا تفسیر کنید
اگر Nginx چند بک‌اند یا چند تلاش داشته باشد، فیلدهای upstream ممکن است چند مقدار با جداکنندهٔ ویرگول یا دونقطه داشته باشند. آن‌ها را یک عدد واحد فرض نکنید؛ خط تیره هم لزوماً صفر نیست.
اتصال سریع همراه تأخیر زیاد هدر، انتظار پس از اتصال را نشان می‌دهد؛ اما به‌تنهایی مشخص نمی‌کند کدام کوئری یا سرویس جانبی کند است. شواهد worker، دیتابیس و trace همان درخواست را کنار هم بگذارید. سریع‌بودن health check، سلامت عملیات سنگین کاربر را ثابت نمی‌کند.
مهلت‌ها را متناسب با عملیات تنظیم کنید
مهلت اتصال با مهلت خواندن پاسخ یکسان نیست. proxy_read_timeout فاصلهٔ بین دو خواندن پیاپی را محدود می‌کند، نه کل مدت تراکنش؛ برنامه‌ای که گاهی داده می‌فرستد می‌تواند بسیار طولانی‌تر اجرا شود.
مهلت کلاینت، لبه، Nginx و برنامه را با نیاز واقعی هماهنگ کنید. افزایش همهٔ آن‌ها ممکن است اتصال‌های اشغال‌شده را بیشتر و ازدحام را بدتر کند. کار طولانی را در صورت تناسب به job غیرهم‌زمان بسپارید؛ تکرار درخواست نوشتنی هم بدون طراحی جلوگیری از اجرای دوباره، راه‌حل امنی نیست.
فقط تغییر تشخیصی را کنار بگذارید
درخواست‌های خواندنی چیزی را تغییر نمی‌دهند و بازگردانی لازم ندارند. اگر قالب زمان‌بندی اضافه کردید، فقط همان تعریف و اتصال لاگ موقت را در روند ویرایش قبلی حذف کنید؛ بعد از اعتبارسنجی reload کنید. لاگ اصلی و شواهد رخداد را نگه دارید.
برداشتن لاگ موقت، بک‌اند را تعمیر نمی‌کند. پس از رفع علت اصلی، مسیر عمومی، مسیر خصوصی و عملیات واقعی برنامه را در بازهٔ توافق‌شده بررسی کنید.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo nginx -t && sudo systemctl reload nginxلاگ عادی برقرار است، ابزار موقت کنار گذاشته شده و عملیات مورد نظر پس از رفع علت اصلی پاسخ درست می‌دهد.