ساختار پوشه هاست: کار هر پوشه و کدام‌ها را دست نزنید

راهنمای دقیق ساختار پوشه هاست لینوکس: کارکرد public_html، mail، logs و پوشه‌هایی که دستکاری‌شان سایت را از کار می‌اندازد.

۶ دقیقه به‌روزرسانی ۴ مهر ۱۴۰۵

وارد File Manager می‌شوید و کنار public_html چند پوشه دیگر می‌بینید که هیچ‌وقت نساخته‌اید: mail، logs، tmp، etc، ssl. یکی از آن‌ها را پاک می‌کنید چون به نظرتان اضافه است، و نیم ساعت بعد سایت بالا نمی‌آید یا ایمیل‌های ارسالی برنمی‌گردند. این مقاله دقیقاً برای همان لحظه است: چه چیزی داخل هر پوشه است، کدام‌ها را کاربر می‌تواند تغییر دهد، و کدام‌ها را باید دست‌نخورده بگذارید.

ساختار پوشه هاست از نگاه کاربر، نه از نگاه سرور

وقتی با FTP یا SSH وارد حساب می‌شوید، در پوشه‌ای به نام خودتان فرود می‌آیید. مسیر واقعی‌اش چیزی شبیه این است:

/home/USERNAME/

این پوشه ریشه حساب شماست و در cPanel با نام Home Directory شناخته می‌شود. هر چیزی زیر آن، متعلق به همان حساب است و روی حساب‌های دیگر سرور اثری ندارد. اما همه پوشه‌های زیر آن هم‌سطح نیستند. سه دسته داریم: پوشه‌هایی که وب‌سرور مستقیم به آن‌ها سرویس می‌دهد، پوشه‌هایی که سرویس‌های دیگر (Mail، DNS، Cron) از آن‌ها استفاده می‌کنند، و پوشه‌هایی که فقط موتور میزبانی به آن‌ها دست می‌زند.

public_html دقیقاً چه چیزی را سرو می‌کند

دامنه اصلی حساب به public_html نگاشت شده است. یعنی درخواست https://example.com/wp-login.php به فایل /home/USER/public_html/wp-login.php می‌رسد. اگر دامنه اضافه (Addon Domain) بسازید، cPanel به‌طور پیش‌فرض پوشه‌ای هم‌نام دامنه می‌سازد و آن را به‌عنوان Document Root ثبت می‌کند؛ مثلاً public_html/shop. این نگاشت در فایل پیکربندی وب‌سرور نوشته می‌شود، نه در خود پوشه، پس جابه‌جا کردن پوشه بدون تغییر Document Root سایت را به ۴۰۴ می‌برد.

یک نکته که خیلی‌ها نمی‌دانند: اگر فایل index.php و index.html هر دو وجود داشته باشند، ترتیب اولویت وب‌سرور تعیین می‌کند کدام اجرا شود و این ترتیب در Apache و LiteSpeed یکسان نیست. اگر بعد از آپلود نسخه HTML قدیمی سایت، نسخه جدید PHP نمایش داده نمی‌شود، اول همین را چک کنید.

پوشه‌هایی که نباید دستکاری شوند

این‌ها را نه پاک کنید، نه تغییر نام دهید، نه مجوزشان را عوض کنید:

پوشهکارشاگر خرابش کنید
mailصندوق پستی، فیلترها و پیکربندی Maildirایمیل‌های موجود ناپدید می‌شوند یا ارسال قطع می‌شود
etcپیکربندی دامنه‌ها، Cron، SSL و فایل‌های کاربردامنه از حساب جدا می‌شود، Cronها می‌ریزند
logsلاگ دسترسی و خطای وب‌سرورخطایابی کور می‌شود؛ معمولاً خودش بازسازی می‌شود
sslکلید و زنجیره گواهی دامنه‌هاHTTPS می‌شکند و مرورگر هشدار می‌دهد
tmpفایل‌های موقت PHP و آپلودهای نیمه‌کارهخطای آپلود و sessionهای عجیب
.trashسطل بازیافت File Managerفضا آزاد می‌شود ولی بازگردانی ممکن نیست

پوشه logs بیشترین قربانی را دارد، چون حجمش بالا می‌رود و اولین چیزی است که کاربر برای آزاد کردن فضا حذف می‌کند. حذف فایل‌های داخلش بی‌خطر است؛ حذف خود پوشه نه. اگر وب‌سرور نتواند لاگ بنویسد، بسته به پیکربندی ممکن است درخواست‌ها را با خطای ۵۰۰ رد کند.

پوشه‌های مخفی را با ls -la ببینید

File Manager به‌طور پیش‌فرض فایل‌های نقطه‌دار را نشان نمی‌دهد. با SSH این‌ها را ببینید:

ls -la ~/
du -sh ~/* ~/.[!.]* 2>/dev/null | sort -h

خروجی دستور دوم معمولاً غافلگیرکننده است: پوشه‌ای مثل .cagefs یا .wp-cli یا کش Composer می‌تواند چند صد مگابایت باشد. عدد دقیق مصرف را از داخل cPanel و بخش Disk Usage هم می‌بینید، ولی آن گزارش تا ۲۴ ساعت کش می‌شود؛ برای عدد لحظه‌ای به du اعتماد کنید.

مجوز فایل و مالکیت: خطای 500 از همین‌جا می‌آید

قاعده‌ای که در عمل جواب می‌دهد: پوشه‌ها 755، فایل‌ها 644. فایل‌های پیکربندی حساس مثل wp-config.php را 600 بگذارید. با این دستور یک‌جا اصلاح کنید:

find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;

مالکیت را دست نزنید. روی هاست اشتراکی، فایل‌ها باید به مالک حساب باشند؛ اگر با chown آن‌ها را به کاربر دیگری بدهید، PHP دیگر اجازه نوشتن ندارد و وردپرس هنگام آپلود یا به‌روزرسانی، پیام «Could not create directory» می‌دهد. این‌جا اشتباه می‌کنند: کاربر برای رفع خطای دسترسی، کل پوشه را 777 می‌کند. سایت بالا می‌آید، ولی از همان لحظه هر اسکریپتی روی سرور می‌تواند فایل‌های شما را بازنویسی کند و معمولاً چند هفته بعد با یک شل آپلودشده در public_html/uploads مواجه می‌شوید.

ساختار پوشه هاست و مصرف inode

هر فایل و هر پوشه یک inode مصرف می‌کند. ساختار پوشه‌ای که مرتب نیست، سریع‌تر از حجم دیسک شما را به سقف می‌رساند. یک نصب وردپرس با افزونه‌های متوسط معمولاً بین ۱۵٬۰۰۰ تا ۴۰٬۰۰۰ inode می‌گیرد؛ اگر کش صفحه یا نسخه‌های پشتیبان را داخل public_html نگه دارید، این عدد چند برابر می‌شود. برای شمارش دقیق و فهمیدن اینکه کدام پوشه مسئول است، محدودیت inode در هاست: چه چیزی آن را مصرف می‌کند و چطور بشماریم را ببینید. راه‌حل عملی ساده است: پوشه‌های کش، لاگ و بکاپ را بیرون از public_html ببرید.

کدام پوشه‌ها باید بیرون از public_html باشند

  • نسخه‌های پشتیبان و فایل‌های .sql یا .tar.gz
  • پوشه کش افزونه‌ها و wp-content/cache اگر افزونه اجازه جابه‌جایی بدهد
  • فایل‌های پیکربندی حاوی رمز دیتابیس
  • پروژه‌های در حال توسعه که هنوز آماده انتشار نیستند

هر فایلی داخل public_html از اینترنت قابل درخواست است، حتی اگر جایی به آن لینک نداده باشید. یک backup.sql در ریشه سایت، با یک جست‌وجوی ساده گوگل پیدا می‌شود.

دامنه اضافه، ساب‌دامنه و پوشه‌شان

ساب‌دامنه‌ها به‌طور پیش‌فرض زیر public_html ساخته می‌شوند، مثل public_html/blog برای blog.example.com. این یعنی یک آسیب‌پذیری در سایت بلاگ می‌تواند به فایل‌های سایت اصلی هم برسد، چون هر دو زیر یک Document Root ریشه‌ای هستند. اگر امنیت برایتان مهم است، ساب‌دامنه را بیرون از public_html بسازید، مثلاً /home/USER/blog، و Document Root را دستی به آن اشاره دهید.

هزینه‌اش را هم بگویم: بعضی افزونه‌ها و ابزارهای مدیریت فایل، مسیرهای نسبی را نسبت به public_html فرض می‌کنند و با ساختار غیراستاندارد به هم می‌ریزند. اگر سایت ساده‌ای دارید و مدیر فنی اختصاصی ندارید، همان ساختار پیش‌فرض cPanel کم‌دردسرتر است. برای پروژه‌هایی که چند سایت با نیازهای امنیتی متفاوت دارند، جدا کردن مسیرها ارزشش را دارد.

وقتی سایت را از هاست اشتراکی به یک سرور اختصاصی منتقل می‌کنید، همین ساختار عوض می‌شود: به‌جای /home/USER با /var/www و VirtualHostهای مستقل طرفید. قبل از مهاجرت، فهرست پوشه‌ها و مسیر Document Root هر دامنه را یادداشت کنید؛ بعد از انتقال، تنها چیزی که معمولاً جا می‌ماند، فایل‌های خارج از public_html است.

پرسش‌های پرتکرار

آیا می‌توانم نام public_html را عوض کنم؟

نه، نه از File Manager و نه از FTP. نام این پوشه در پیکربندی وب‌سرور به‌عنوان Document Root دامنه اصلی ثبت شده است. اگر تغییرش دهید، سایت با خطای ۴۰۴ یا صفحه پیش‌فرض هاست بالا می‌آید. اگر واقعاً به مسیر دیگری نیاز دارید، باید Document Root را از داخل cPanel یا از پشتیبانی بخواهید تا تغییر کند.

پوشه .htaccess کجاست و چرا دیده نمی‌شود؟

در ریشه public_html قرار دارد و چون با نقطه شروع می‌شود، File Manager آن را مخفی نشان می‌دهد. در تنظیمات File Manager گزینه Show Hidden Files را فعال کنید یا با ls -la ببینیدش. این فایل قواعد بازنویسی URL، ریدایرکت و محدودیت دسترسی را نگه می‌دارد؛ یک کاراکتر اشتباه در آن کل سایت را به خطای ۵۰۰ می‌برد.

چرا پوشه mail حجم زیادی گرفته؟

چون ایمیل‌های خوانده‌نشده و پیوست‌ها روی همان حساب ذخیره می‌شوند، نه در فضای جدا. اگر صندوق POP3 دارید و ایمیل‌ها را دانلود نمی‌کنید، این پوشه رشد می‌کند تا سهمیه دیسک را پر کند. با du -sh ~/mail/* ببینید کدام دامنه مسئول است و از داخل cPanel صندوق را خالی یا سهمیه‌اش را محدود کنید.

فایل‌های کش و session در tmp چه زمانی پاک می‌شوند؟

روی بیشتر هاست‌های اشتراکی، پوشه tmp به‌صورت دوره‌ای و خودکار پاک‌سازی می‌شود؛ معمولاً هر چند ساعت تا یک روز. پس هیچ داده‌ای که به آن نیاز دارید را آنجا نگه ندارید. اگر sessionهای PHP را در tmp می‌نویسید و کاربران بی‌دلیل لاگ‌اوت می‌شوند، مسیر session را به پوشه‌ای پایدارتر منتقل کنید.

قبل از هر تغییری در ساختار پوشه‌ها، یک نسخه پشتیبان کامل بگیرید و مسیر Document Root هر دامنه را یادداشت کنید. اگر مطمئن نیستید یک پوشه چه کاری انجام می‌دهد، دست به آن نزنید؛ حذفش هیچ‌وقت فوری نیست، ولی بازگرداندنش همیشه هست.

آیا این مطلب برایتان مفید بود؟