رفع خطاهای Nginx با ثبت پیام دقیق، زمان و آدرس مشکل‌دار شروع می‌شود. خطای مرورگر، خرابی سرویس و خطای برنامهٔ پشت پراکسی یکسان نیستند. پیش از تغییر تنظیمات، مشخص کنید مشکل روی همهٔ درخواست‌ها رخ می‌دهد یا فقط یک مسیر، دامنه یا عملیات خاص.
شروع رفع خطاهای Nginx با وضعیت سرویس
روی سرور دارای systemd، این فرمان‌ها وضعیت سرویس و پیام‌های اخیر آن را نشان می‌دهند:
systemctl status nginx --no-pager
sudo journalctl -u nginx -n 60 --no-pager
sudo nginx -tفعال بودن سرویس به‌تنهایی سلامت سایت را ثابت نمی‌کند. همچنین وضعیت inactive الزاماً به معنی خرابی نیست؛ ممکن است سرویس عمداً متوقف شده باشد. قبل از start یا restart، علت توقف و احتمال تداخل با وب‌سرور دیگر را بررسی کنید.
لاگ مربوط به همان درخواست را بخوانید
در بسیاری از نصب‌ها لاگ خطا در مسیر زیر است، اما error_log می‌تواند در سطح سایت مسیر دیگری داشته باشد. به جای چاپ فایل چندگیگابایتی، انتهای مرتبط را بخوانید:
sudo tail -n 80 /var/log/nginx/error.logزمان، نام فایل و شمارهٔ خط را با رخداد تطبیق دهید. خالی بودن این فایل ثابت نمی‌کند که خطایی وجود ندارد؛ ممکن است مسیر، سطح ثبت یا مقصد لاگ متفاوت باشد. access log نیز برای دیدن کد پاسخ و درخواست مفید است. پیش از اشتراک گزارش، اطلاعات شخصی و توکن‌ها را حذف کنید.
خطای نحوی و محل درست دستور
طبق ساختار پیکربندی Nginx، دستورها context مشخص دارند. پیام directive is not allowed here معمولاً نیاز به بررسی محل قرارگیری دستور دارد. برای خطای تعداد آرگومان یا نشانهٔ پایان، همان خط و خطوط قبل از آن را ببینید.
فرمان nginx -t را پس از اصلاح اجرا کنید. گزینهٔ -T علاوه بر آزمون، تنظیمات را چاپ می‌کند و ممکن است دادهٔ حساس نشان دهد؛ خروجی کامل آن را عمومی منتشر نکنید.
خطای 403 و 404
برای 403، اجازهٔ خواندن فایل و عبور از پوشه‌های والد، تنظیم index و قواعد deny را بررسی کنید. دادن مجوز 777 به همهٔ فایل‌ها راه‌حل عمومی نیست. مالک و گروه باید با روش اجرای سرویس و سیاست دسترسی سازگار باشند.
در 404، ابتدا وجود مسیر، root یا alias و انتخاب server_name را ببینید. در برنامه‌های دارای مسیریابی، ممکن است درخواست باید به برنامه برسد. تنظیم try_files یک سایت ایستا را بدون تطبیق روی وردپرس یا برنامهٔ دیگری کپی نکنید.
خطای 502 و 504 در پراکسی
502 اغلب به پاسخ نامعتبر یا مشکل ارتباط با upstream مربوط است. لاگ را برای نشانه‌هایی مانند connection refused، سوکت اشتباه یا بسته شدن اتصال بخوانید. وضعیت PHP-FPM یا سرویس برنامه، آدرس و پورت مقصد و مجوز سوکت را جدا بررسی کنید.
504 معمولاً نشان‌دهندهٔ تمام شدن مهلت ارتباط یا پاسخ است. کندی برنامه، دیتابیس و اشباع منابع را بررسی کنید. بالا بردن همیشگی timeout علت را برطرف نمی‌کند و ممکن است مصرف منابع را بیشتر کند.
در مستندات proxy_read_timeout، مهلت خواندن میان دو عملیات متوالی تعریف شده است؛ آن را با حداکثر زمان کل درخواست یکی ندانید. برای FastCGI نیز تنظیمات متناسب با همان ماژول را بررسی کنید.
شبکه و فایروال
sudo ss -ltnp
sudo ufw status verboseبررسی کنید سرویس روی IP و پورت مورد انتظار گوش می‌دهد. فایروال شبکه یا میزبان و DNS را هم ببینید. وجود یک پروفایل در UFW به معنی صحت DNS یا گوش دادن سرویس نیست. برای رفع خطا، فایروال را کامل خاموش نکنید و مجوز SSH را حفظ کنید.
اعمال تغییر و تأیید نتیجه
تغییر کوچک و قابل توضیح انجام دهید. پس از موفقیت sudo nginx -t، برای تغییر تنظیمات معمولاً reload کافی است:
sudo systemctl reload nginxreload با restart یکسان نیست. درخواست مشکل‌دار را دوباره اجرا کنید و کد پاسخ و لاگ تازه را ببینید. رفع یک پیام قدیمی در لاگ، بدون آزمون درخواست، به معنی حل کامل مشکل نیست.
مطالعهٔ مرتبط
بازبینی فنی: ۱۴ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
