htaccess چیست؟

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

چرا اصلاً چنین فایلی وجود دارد؟

پیکربندی اصلی آپاچی در فایل‌هایی مانند httpd.conf یا apache2.conf نگهداری می‌شود؛ این فایل‌ها فقط در اختیار مدیر سرور هستند و هر تغییر در آن‌ها به ری‌لود سرویس نیاز دارد. روی هاست اشتراکی شما چنین دسترسی‌ای ندارید و اینجاست که .htaccess معنا پیدا می‌کند: فایل را داخل پوشه سایت خود می‌گذارید و آپاچی هنگام پردازش هر درخواست آن را می‌خواند و اعمال می‌کند؛ بدون ری‌استارت و بدون دسترسی root.

آپاچی برای هر درخواست، مسیر را از بالا تا پایین می‌خواند⁦public_html/⁩.htaccess اصلی سایت⁦RewriteEngine On⁩⁦public_html/shop/⁩قوانین این پوشه⁦php_value upload_max_filesize 32M⁩⁦public_html/shop/uploads/⁩محدودتر از همه⁦Options -Indexes⁩قوانین پوشه پایین‌تر، قوانین بالاتر را برای همان مسیر بازنویسی می‌کننددو نکته که همیشه به دردسر تبدیل می‌شوند:۱. اگر مدیر سرور AllowOverride را روی None گذاشته باشد،فایل شما بی‌اثر است و هیچ خطایی هم نمی‌بینید۲. یک خط اشتباه، کل مسیر را با خطای ۵۰۰ از کار می‌اندازد؛پیش از ویرایش نسخه پشتیبان بگیرید

آپاچی برای هر درخواست همه فایل‌های htaccess موجود در مسیر را می‌خواند و قانون پوشه نزدیک‌تر برنده است؛ به همین دلیل تنظیمی که در یک پوشه گذاشته‌اید ممکن است در پوشه دیگر خنثی شود.

همین «خوانده‌شدن در هر درخواست» نقطه ضعف آن هم هست. آپاچی برای هر فایلی که سرو می‌کند، تمام مسیر پوشه‌ها را تا ریشه بالا می‌رود و در هر سطح دنبال .htaccess می‌گردد. به همین دلیل مستندات رسمی آپاچی توصیه می‌کند اگر به پیکربندی اصلی دسترسی دارید، قواعد را همان‌جا و داخل بلوک <Directory> بنویسید.

پیش‌نیاز: دستور AllowOverride

فایل .htaccess تا وقتی مدیر سرور اجازه ندهد کار نمی‌کند. این اجازه با دستور AllowOverride در پیکربندی اصلی داده می‌شود. در آپاچی نسخه ۲.۴ مقدار پیش‌فرض AllowOverride None است، یعنی فایل کاملاً نادیده گرفته می‌شود.

برای فعال کردن کامل آن:

<Directory /var/www/example/public_html>
AllowOverride All
</Directory>

می‌توان اجازه را محدودتر هم داد؛ مثلاً AllowOverride FileInfo Indexes فقط قواعد بازنویسی و ریدایرکت و تنظیمات فهرست پوشه را مجاز می‌کند و اجازه احراز هویت یا تغییر گزینه‌های دیگر را نمی‌دهد. اگر دستوری که نوشته‌اید در دسته مجازشده نباشد، سرور خطا می‌دهد. روی هاست‌های مبتنی بر cPanel معمولاً این اجازه از قبل داده شده است.

کاربردهای رایج

ریدایرکت و بازنویسی آدرس

ساده‌ترین حالت با ماژول mod_alias انجام می‌شود:

Redirect 301 /old-page.html /new-page.html

برای قواعد شرطی‌تر از mod_rewrite استفاده می‌شود. نمونه پرکاربرد، هدایت ترافیک به HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

یک هشدار مهم: اگر سایت پشت یک پروکسی معکوس یا CDN باشد، ممکن است متغیر %{HTTPS} همیشه مقدار off بگیرد و همین قاعده سایت را در حلقه بی‌پایان ریدایرکت بیندازد. در آن حالت باید بر اساس هدر X-Forwarded-Proto شرط بگذارید.

همین ماژول است که ساختار پیوندهای یکتای وردپرس را ممکن می‌کند؛ بلوکی که وردپرس خودش بین دو خط # BEGIN WordPress و # END WordPress می‌نویسد. اگر روی یک هاست وردپرس بعد از تغییر ساختار پیوندها همه صفحات داخلی خطای ۴۰۴ دادند، معمولاً مقصر همین بلوک است که پاک یا بازنویسی شده. کافی است در پیشخوان وردپرس بخش «پیوندهای یکتا» را یک بار ذخیره کنید تا دوباره ساخته شود.

صفحه خطای سفارشی

ErrorDocument 404 /404.html
ErrorDocument 403 /forbidden.html

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

کنترل دسترسی

برای بستن فهرست‌شدن محتوای پوشه‌هایی که فایل ایندکس ندارند:

Options -Indexes

و برای مسدود کردن دسترسی به یک فایل حساس — مثلاً wp-config.php که اطلاعات اتصال به پایگاه داده در آن نگهداری می‌شود — در آپاچی ۲.۴:

<Files "wp-config.php">
Require all denied
</Files>

دقت کنید که دستورهای قدیمی Order allow,deny و Deny from all مربوط به آپاچی ۲.۲ هستند و در نسخه ۲.۴ به ماژول mod_access_compat نیاز دارند. مخلوط کردن این دو نسل دستور در یک فایل، منبع همیشگی رفتارهای غیرمنتظره است.

کش و فشرده‌سازی

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
</IfModule>

قرار دادن قواعد داخل <IfModule> یک عادت خوب است: اگر ماژول روی سرور فعال نباشد، به‌جای خطای ۵۰۰ فقط آن بخش نادیده گرفته می‌شود. فشرده‌سازی خروجی هم در آپاچی با ماژول mod_deflate و از همین فایل کنترل می‌شود؛ جزئیات الگوریتم deflate و فشرده‌سازی gzip را جداگانه توضیح داده‌ایم.

این چند مورد روی هاست اشتراکی تنها راه موجود هستند، ولی اگر روی یک سرور ابری با دسترسی روت کار می‌کنید، بهتر است قواعد ثابت و همیشگی را مستقیماً در پیکربندی اصلی بنویسید و .htaccess را برای تنظیمات موقت یا مخصوص یک پوشه نگه دارید.

هر اشتباه تایپی یعنی خطای ۵۰۰

مهم‌ترین نکته عملی همین است. آپاچی فایل .htaccess را در لحظه درخواست تفسیر می‌کند و اگر یک دستور ناشناخته، یک بلوک بسته‌نشده یا دستوری خارج از محدوده مجاز AllowOverride ببیند، کل آن پوشه را با خطای 500 Internal Server Error پاسخ می‌دهد. نکته‌ای که خیلی‌ها را غافلگیر می‌کند: دستور apachectl configtest فقط پیکربندی اصلی را بررسی می‌کند و اصلاً سراغ فایل‌های .htaccess نمی‌رود، پس سبز بودن خروجی آن هیچ تضمینی نیست.

روش درست کار: قبل از هر تغییر یک نسخه پشتیبان بگیرید. اگر سایت بعد از ویرایش خطای ۵۰۰ داد، فایل را موقتاً تغییر نام دهید تا از مدار خارج شود و ببینید مشکل واقعاً از آن است یا نه:

cp .htaccess .htaccess.bak
mv .htaccess .htaccess.off

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

در Nginx معادلی وجود ندارد

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

در Nginx قواعد را داخل بلوک‌های server و location در فایل‌هایی زیر /etc/nginx/ می‌نویسید و بعد از هر تغییر باید پیکربندی را تست و بارگذاری مجدد کنید:

nginx -t && systemctl reload nginx

پس اگر سایتی را از یک هاست آپاچی به سروری با Nginx منتقل می‌کنید، قواعد .htaccess به‌صورت خودکار منتقل نمی‌شوند و باید دستی معادل‌سازی شوند. روی هاست ویندوز و وب‌سرور IIS هم معادل این فایل web.config با ساختار XML است؛ این و بقیه تفاوت‌های هاست لینوکس و ویندوز را جداگانه بررسی کرده‌ایم. ابزارهای تبدیل خودکار وجود دارند اما خروجی‌شان همیشه باید بازبینی شود. وب‌سرور LiteSpeed اما برای سازگاری با آپاچی، فایل .htaccess را می‌خواند و در بیشتر موارد نیازی به بازنویسی قواعد نیست.

جمع‌بندی

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