دسته بندی:

رفع خطای Apache is functioning normally در Directadmin

رفع خطای Apache is functioning normally در Directadmin

حدود ۸ دقیقه مطالعه

پیغام Apache is functioning normally یعنی وب‌سرور آپاچی کاملاً سالم است و درخواست شما را پاسخ داده، اما آن را به سایت شما تحویل نداده است؛ درخواست به‌جای ویرچوال‌هاست دامنه، روی ویرچوال‌هاست پیش‌فرض سرور (معمولاً مسیر /var/www/html) فرود آمده است. در دایرکت ادمین این اتفاق تقریباً همیشه یکی از این پنج ریشه را دارد: رکورد DNS به IP دیگری اشاره می‌کند، IP دامنه در پنل با IP پاسخ‌دهنده یکی نیست، فایل‌های کانفیگ آپاچی هنوز برای آن دامنه بازنویسی نشده‌اند، ویرچوال‌هاست پورت ۴۴۳ برای دامنه ساخته نشده، یا اکانت تازه ساخته شده و هنوز فایل واقعی سایت داخل public_html قرار نگرفته است.

این صفحه دقیقاً از کجا می‌آید

آپاچی برای هر دامنه یک بلوک VirtualHost با یک ServerName و یک DocumentRoot دارد. وقتی درخواستی می‌رسد، آپاچی روی IP و پورت مقصد دنبال ویرچوال‌هاست منطبق می‌گردد. اگر هیچ بلوکی با آن ترکیب هم‌خوانی نداشته باشد، آپاچی درخواست را به اولین ویرچوال‌هاست همان IP و همان پورت (یعنی ویرچوال‌هاست پیش‌فرض سرور) می‌سپارد و همان صفحه ساده تحویل داده می‌شود. پس این پیغام یک «خطا» نیست؛ یک نشانه است که مسیریابی درخواست به مقصد اشتباه رسیده. همین صفحه به‌عنوان فایل جای‌گزین (placeholder) روی دامنه‌های تازه‌ساخته هم قرار می‌گیرد، بنابراین دیدن آن روی یک اکانت نو الزاماً به معنی خرابی نیست.

به عبارت «همان پورت» دقت کنید، چون کلید بخشی از موارد گیج‌کننده همین است: پورت ۸۰ و پورت ۴۴۳ دو مجموعه جدا از ویرچوال‌هاست‌ها هستند و ممکن است دامنه روی یکی تعریف شده باشد و روی دیگری نه.

پیش از آنکه سراغ ترمینال بروید، ارزش دارد ببینید دنیای بیرون سایت شما را چطور می‌بیند؛ ابزار چکاپ رایگان سایت بدون نیاز به دسترسی هاست یا سرور، وضعیت DNS و وب‌سرور دامنه را از بیرون بررسی می‌کند و همین دو مورد دقیقاً نقطه شروع عیب‌یابی این پیغام هستند.

پنج علت اصلی و نحوه تفکیک آن‌ها

  • DNS به سرور شما اشاره نمی‌کند. رکورد A دامنه هنوز IP سرور قبلی یا IP پارک‌شده ثبت‌کننده را نگه داشته است. بسیار شایع‌تر از چیزی است که تصور می‌شود.
  • IP دامنه در دایرکت ادمین با IP پاسخ‌دهنده متفاوت است. روی سرورهای چند IP، اگر دامنه به IP دیگری در پنل متصل باشد، درخواستی که به IP اصلی می‌رسد هیچ ویرچوال‌هاست منطبقی پیدا نمی‌کند. وضعیت مشابهی در سی‌پنل هم دیده می‌شود که در مشکل عدم نمایش دامنه در سی پنل بررسی شده است.
  • کانفیگ آپاچی برای دامنه ساخته نشده است. اگر صف وظایف دایرکت ادمین گیر کرده باشد یا مهاجرت دستی انجام شده باشد، فایل ویرچوال‌هاست کاربر تولید نمی‌شود.
  • ویرچوال‌هاست SSL وجود ندارد. سایت روی http درست بالا می‌آید ولی روی https همان صفحه پیش‌فرض را نشان می‌دهد. نشانه‌ای بسیار گویاست و در بخش جداگانه پایین به آن می‌پردازیم.
  • سایت هنوز آپلود نشده است. فایل index.html پیش‌فرض هنوز سر جایش است، یا فایل‌ها به‌جای public_html در یک پوشه اشتباه ریخته‌اند.

گام‌های زیر روی خود سرور اجرا می‌شوند و به دسترسی مدیریتی نیاز دارند؛ اگر چنین دسترسی ندارید، همین فهرست را برای پشتیبانی سرویس‌دهنده بفرستید تا موارد را بررسی کند.

تشخیص گام‌به‌گام

ترتیب زیر را رعایت کنید؛ هر گام یکی از احتمال‌های بالا را حذف می‌کند.

۱) ببینید دامنه به کجا اشاره می‌کند. از سیستم خودتان اجرا کنید:

dig +short example.com A

خروجی را با IP سرور مقایسه کنید. اگر یکی نبود، مشکل در DNS است نه در آپاچی و هیچ دستوری روی سرور آن را حل نمی‌کند. توجه کنید که پس از تغییر رکورد، انتشار آن به اندازه TTL تنظیم‌شده زمان می‌برد و این تأخیر یک باگ نیست؛ اگر رکوردها را جای درستی مدیریت می‌کنید، سرویس مدیریت رکوردهای DNS کار پیگیری همین تغییرات را ساده‌تر می‌کند.

۲) آپاچی را از IP سرور مستقیم صدا بزنید. این کار DNS را کنار می‌گذارد و فقط مسیریابی داخلی را می‌سنجد:

curl -I -H "Host: example.com" http://SERVER_IP/

اگر با این دستور سایت درست پاسخ داد، سرور سالم است و ایراد از DNS بود. اگر باز هم همان صفحه پیش‌فرض آمد، ادامه دهید. برای آزمودن https این ترفند جواب نمی‌دهد، چون در TLS نام دامنه از طریق SNI و پیش از هدرها فرستاده می‌شود؛ آنجا باید از این شکل استفاده کنید:

curl -I --resolve example.com:443:SERVER_IP https://example.com/

۳) فهرست ویرچوال‌هاست‌های شناخته‌شده آپاچی را بگیرید:

httpd -S

در خروجی دنبال نام دامنه و IP کنار آن بگردید و حتماً هر دو بخش *:80 و *:443 را جداگانه نگاه کنید. اگر دامنه اصلاً در فهرست نیست، کانفیگ آن ساخته نشده. اگر هست ولی روی IP دیگری نشسته، مشکل تخصیص IP است. اگر دستور httpd اصلاً پیدا نشد، یعنی سرور شما در حالت فقط nginx یا LiteSpeed اجرا می‌شود و باید سراغ بخش مربوط در ادامه همین مطلب بروید.

۴) فایل کانفیگ تولیدشده کاربر را ببینید:

grep -E "ServerName|DocumentRoot" /usr/local/directadmin/data/users/USERNAME/httpd.conf
DocumentRoot باید به /home/USERNAME/domains/example.com/public_html اشاره کند. این فایل به‌صورت خودکار تولید می‌شود؛ ویرایش دستی آن با اولین بازنویسی از بین می‌رود.


5) لاگ‌ها را بخوانید. لاگ عمومی آپاچی نشان می‌دهد هنگام بارگذاری کانفیگ خطایی رخ داده یا نه:


tail -n 50 /var/log/httpd/error_log

و لاگ اختصاصی خود دامنه نشان می‌دهد آیا درخواست‌ها اصلاً به ویرچوال‌هاست دامنه می‌رسند یا نه. اگر این فایل هنگام باز کردن سایت هیچ سطر تازه‌ای نمی‌گیرد، عملاً تأیید شده که درخواست جای دیگری فرود می‌آید:

tail -f /var/log/httpd/domains/example.com.log

وقتی فقط روی HTTPS این صفحه را می‌بینید

این حالت امروز شایع‌ترین شکل ماجراست، چون تقریباً همه بازدیدها به https هدایت می‌شوند. اگر http://example.com سالم بالا می‌آید ولی https://example.com صفحه پیش‌فرض یا هشدار گواهی نامعتبر می‌دهد، یعنی برای دامنه ویرچوال‌هاست پورت ۴۴۳ ساخته نشده و آپاچی درخواست را به ویرچوال‌هاست پیش‌فرض همان پورت سپرده است. در دایرکت ادمین بلوک SSL فقط زمانی تولید می‌شود که SSL آن دامنه فعال باشد؛ وضعیت را از فایل تنظیمات خود دامنه بخوانید:

grep -E "^ssl=" /usr/local/directadmin/data/users/USERNAME/domains/example.com.conf

اگر مقدار آن ON نیست، از پنل کاربر بخش SSL Certificates را باز کنید، گواهی رایگان Let’s Encrypt را برای دامنه و زیردامنه www صادر کنید و بعد کانفیگ‌ها را بازنویسی کنید. اگر مقدار درست است ولی باز هم بلوک ۴۴۳ در خروجی httpd -S دیده نمی‌شود، گواهی احتمالاً منقضی یا ناقص است و آپاچی از بارگذاری آن بلوک صرف‌نظر کرده؛ لاگ خطا در همین حالت دقیقاً می‌گوید کدام فایل گواهی مشکل دارد.

رفع مشکل در دایرکت ادمین

همه دستورهای این بخش با کاربر root اجرا می‌شوند و فرض را بر این می‌گذارند که دایرکت ادمین روی سرور نصب و لایسنس آن فعال است؛ اگر هنوز چنین نیست، تهیه لایسنس دایرکت ادمین گام اول است و نصب و کانفیگ اولیه پنل هم روی همین سرویس ارائه می‌شود.

اگر گام ۳ یا ۴ نشان داد که کانفیگ ساخته نشده یا ناقص است، ابتدا از خود پنل بخواهید کانفیگ‌ها را از نو بسازد. کوتاه‌ترین شکل امروزی این دستور است:

da build rewrite_confs

اجرای مستقیم اسکریپت CustomBuild هم همچنان همان کار را می‌کند و در راهنماهای قدیمی‌تر بیشتر با این شکل روبه‌رو می‌شوید (همین اسکریپت مسیر افزودن قابلیت زیپ و آنزیپ به دایرکت‌ادمین هم هست):

cd /usr/local/directadmin/custombuild && ./build rewrite_confs

راه سبک‌تر و بدون بازسازی کامل، انداختن وظیفه در صف داخلی دایرکت ادمین است؛ سرویس dataskq که این صف را می‌خواند به‌صورت زمان‌بندی‌شده اجرا می‌شود و وظیفه را در نوبت بعدی خود انجام می‌دهد:

echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

سپس وب‌سرور را دوباره راه‌اندازی کنید. روی توزیع‌های امروزی دستور درست این است و شکل قدیمی service httpd restart فقط یک لایه سازگاری روی همین دستور است:

systemctl restart httpd

اگر ریشه مشکل تخصیص IP بود، آن را از رابط گرافیکی اصلاح کنید نه با ویرایش فایل: در سطح Admin بخش مدیریت IP، IP درست را به اکانت کاربر بدهید، سپس دوباره rewrite_confs را اجرا کنید تا ویرچوال‌هاست با IP تازه بازنویسی شود. اگر هم فقط فایل جای‌گزین را می‌بینید، کافی است index.html پیش‌فرض را از public_html حذف و فایل‌های واقعی سایت را جایگزین کنید.

اگر nginx یا LiteSpeed روی سرور دارید

راهنماهای قدیمی توصیه می‌کنند برای رفع این خطا danginx را غیرفعال کنید. این توصیه امروز بی‌ربط است: danginx هیچ‌گاه بخشی از دایرکت ادمین یا CustomBuild نبود، بلکه افزونه‌ای جانبی و ساخت شخص ثالث بود که در دوران CustomBuild نسخه ۱ برای نشاندن nginx جلوی آپاچی به کار می‌رفت؛ روی سروری که امروز با نصب استاندارد دایرکت ادمین بالا آمده، چنین چیزی اصلاً روی سیستم نیست که بخواهید غیرفعالش کنید. همان کار حالا با حالت‌های داخلی خود CustomBuild انجام می‌شود. دایرکت ادمین چند حالت وب‌سرور دارد: آپاچی تنها، nginx تنها، ترکیب nginx به‌عنوان پروکسی جلوی آپاچی (nginx_apache)، و همچنین LiteSpeed و OpenLiteSpeed. اگر حالت ترکیبی فعال باشد، ممکن است آپاچی درست تنظیم شده باشد ولی لایه جلویی درخواست را به مقصد اشتباه بفرستد. حالت فعلی سرور را با این دستور ببینید:

grep -E "^webserver=" /usr/local/directadmin/custombuild/options.conf

هر حالتی که فعال باشد، پس از بازنویسی کانفیگ‌ها باید سرویس همان لایه جلویی را هم دوباره راه‌اندازی کنید، نه فقط آپاچی را؛ برای nginx دستور systemctl restart nginx است و برای LiteSpeed نام سرویس به نسخه نصب‌شده بستگی دارد، پس آن را با systemctl list-units --type=service پیدا کنید و همان نام را به‌کار ببرید.

پیشگیری

چند عادت ساده جلوی تکرار این ماجرا را می‌گیرد. اول، پیش از انتقال سایت، TTL رکورد A را موقتاً پایین بیاورید تا تغییر IP سریع‌تر منتشر شود و پنجره‌ای که کاربران صفحه پیش‌فرض می‌بینند کوتاه شود. دوم، بعد از هر تغییر IP یا افزودن دامنه، یک بار httpd -S بگیرید و مطمئن شوید دامنه با IP درست و روی هر دو پورت ۸۰ و ۴۴۳ ثبت شده است. سوم، صدور گواهی SSL را به بعد از انتقال موکول نکنید؛ همان لحظه‌ای که دامنه به سرور تازه اشاره کرد، گواهی را بگیرید. و چهارم، تغییرات دستی را در فایل‌های تولیدشده ننویسید؛ دایرکت ادمین برای تنظیمات اختصاصی هر دامنه فایل جداگانه‌ای در مسیر /usr/local/directadmin/data/users/USERNAME/domains/example.com.cust_httpd نگه می‌دارد که در بازنویسی‌ها حفظ می‌شود.

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

جمع‌بندی

دیدن Apache is functioning normally خبر بدی نیست: وب‌سرور بالا است و فقط درخواست به ویرچوال‌هاست اشتباه رسیده. مسیر منطقی این است که اول با dig مقصد DNS را بسنجید، بعد با curl سرور را مستقیم آزمایش کنید و حتماً http و https را جدا بیازمایید، سپس با httpd -S ببینید آپاچی دامنه را روی هر دو پورت می‌شناسد یا نه، و در پایان با da build rewrite_confs کانفیگ‌ها را از نو بسازید و سرویس را ری‌استارت کنید. با همین چند گام تقریباً همه نمونه‌های این خطا در دایرکت ادمین حل می‌شود.

آموزش‌های مرتبط

خدمات مرتبط آنلاین سرور