فایل htaccess چیست؟ مدیریت امن، ریدایرکت و رفع خطا

یک خط اشتباه در .htaccess می‌تواند در چند ثانیه تمام سایت را با خطای ۵۰۰ از دسترس خارج کند؛ همان خط اگر درست و در جای مناسب نوشته شود، ریدایرکت‌ها، URLهای وردپرس، هدرها و دسترسی به فایل‌های حساس را منظم می‌کند. مسئله «کپی‌کردن چند کد آماده» نیست؛ باید بدانید سرور چیست، هر Rule در کدام لایه اجرا می‌شود و مسیر برگشت کجاست.

این راهنما برای مدیر سایت، توسعه‌دهنده و تیم فنی ایرانی نوشته شده است؛ به‌ویژه زمانی که سایت روی cPanel یا DirectAdmin، Apache یا LiteSpeed و احتمالاً پشت CDN قرار دارد. اگر به تنظیمات اصلی Apache دسترسی دارید، خود Apache توصیه می‌کند Ruleها را به تنظیمات اصلی منتقل کنید؛ .htaccess بیشتر برای میزبانی اشتراکی و تغییرات سطح Directory مناسب است.

خلاصه تصمیم: چه زمانی از .htaccess استفاده کنیم؟

فایل htaccess چیست و چگونه کار می‌کند؟

.htaccess فایل پیکربندی توزیع‌شده Apache است. Directiveهای آن بر Directory محل فایل و زیرشاخه‌هایش اثر می‌گذارند. امکان استفاده از هر Directive را تنظیم‌های AllowOverride یا AllowOverrideList تعیین می‌کنند؛ بنابراین ممکن است کدی روی یک هاست کار کند و روی هاست دیگر با خطای ۵۰۰ رد شود.

Apache در راهنمای رسمی .htaccess توضیح می‌دهد که وقتی دسترسی به پیکربندی اصلی دارید، تنظیمات اصلی انتخاب بهتری است. فعال‌بودن Override باعث می‌شود سرور در مسیر Directoryها دنبال فایل بگردد و آن را برای Requestها پردازش کند. پس ده‌ها فایل پراکنده و Rewrite پیچیده، هزینه و ابهام عیب‌یابی را بالا می‌برد.

.htaccess روی Apache، LiteSpeed و NGINX

• Apache: بستر اصلی این فایل است؛ اما Module و AllowOverride باید اجازه Directive را بدهند.
• LiteSpeed/OpenLiteSpeed: بسیاری از Ruleهای Apache را می‌پذیرد، ولی سازگاری صددرصدی را فرض نکنید و مستندات شرکت هاست را بررسی کنید.
• NGINX: فایل را نادیده می‌گیرد. Rule باید در Server block یا پنل میزبان تعریف شود.
• CDN: ممکن است Redirect، HTTPS، Cache یا Header را پیش از رسیدن Request به Origin اجرا کند. یک کنترل را بی‌دلیل در دو لایه تکرار نکنید.

htaccess وردپرس کجاست؟

در نصب معمول WordPress، فایل در Document Root و کنار wp-config.php و wp-admin قرار دارد. چون نام آن با نقطه شروع می‌شود، در File Manager باید گزینه Show Hidden Files یا Show Dotfiles را فعال کنید. مسیر واقعی ممکن است public_html، زیردامنه یا پوشه نصب جدا باشد؛ از روی URL حدس نزنید.

WordPress از این فایل برای Permalinkهای زیبا استفاده می‌کند. الگوی پایه در مستند رسمی WordPress برای Apache آمده است. افزونه‌ها نیز ممکن است Blockهای مدیریت‌شده بسازند.

قانون مهم BEGIN و END WordPress

Rule سفارشی را داخل بخش زیر نگذارید، مگر مستندات سازنده صریحاً همین را خواسته باشد:

# BEGIN WordPress
# Rules managed by WordPress
# END WordPress

WordPress یا یک افزونه می‌تواند محتوای داخل Block مدیریت‌شده را بازنویسی کند. Redirectهای Canonical و کنترل‌های سفارشی معمولاً پیش از Block وردپرس قرار می‌گیرند؛ Ruleهای وابسته به Application باید با ترتیب واقعی Rewriteها آزمایش شوند.

پیش از ویرایش: پنج پاسخ اجباری

1. وب‌سرور چیست؟ Apache، LiteSpeed یا NGINX را از پنل، پاسخ هاست یا Headerهای قابل‌اعتماد مشخص کنید.
2. لایه مالک کدام است؟ Redirect و HTTPS در CDN، پنل هاست، VirtualHost، Plugin یا .htaccess؟
3. راه دسترسی خارج از WordPress چیست؟ File Manager، SFTP یا SSH باید قبل از تغییر در دسترس باشد؛ اگر wp-admin قطع شد، بتوانید Rollback کنید.
4. نسخه سالم دارید؟ فایل را با زمان و Ticket ذخیره کنید؛ مثلاً .htaccess.pre-2026-08-06، ولی Backup حساس را در مسیر قابل دانلود عمومی رها نکنید.
5. تست و مالک تصمیم کیست؟ Success criteria، مسیرهای حیاتی، زمان تغییر و مسئول بازگشت را بنویسید.

Backup فقط کپی فایل نیست. برای تغییر پرریسک، Restore را روی Staging تمرین کنید و از فرایند به‌روزرسانی امن WordPress و Rollback استفاده کنید.

Workflow امن تغییر htaccess

برای فروشگاه ایرانی، حداقل صفحه اصلی، صفحه محصول، سبد، Checkout، Return و Callback درگاه، REST API، wp-login.php و یک فایل CSS/JS را تست کنید. Ruleی که صفحه اصلی را سالم نگه دارد ولی Callback بانک را ۴۰۳ کند، تغییر موفقی نیست.

ترتیب Ruleها چرا مهم است؟

Apache Ruleها را به ترتیب اجرا می‌کند و Flagهایی مثل L اجرای مجموعه فعلی را متوقف می‌کنند. در Context فایل .htaccess، الگوی RewriteRule معمولاً بدون Slash ابتدایی نوشته می‌شود. Redirect عمومی اگر بالاتر از Exception خاص قرار گیرد، ممکن است مسیر ACME، Webhook، API یا فایل واقعی را نیز ببلعد.

یک ترتیب عملی برای Root وردپرس

1. توضیح، Ticket و تاریخ تغییر
2. Exceptionهای ضروری و دقیق
3. Canonical host/HTTPS در صورت مالک‌بودن Origin
4. Redirectهای قدیمی به جدید، از خاص به عمومی
5. Header و کنترل فایل‌ها
6. Blockهای مدیریت‌شده Cache/امنیت
7. Block مدیریت‌شده WordPress

این ترتیب نسخه جهانی نیست؛ رفتار Moduleها، Hosting و Pluginها را در Staging بسنجید. اصل ثابت این است که Rule باید Owner، هدف، Scope و تست داشته باشد.

ریدایرکت ۳۰۱ و ۳۰۲ در htaccess

برای انتقال دائمی URL، Redirect سمت سرور با Status ۳۰۱ یا ۳۰۸ مناسب است. برای وضعیت موقت، ۳۰۲ یا ۳۰۷ به کار می‌رود. راهنمای رسمی Google درباره Redirect نیز Redirect دائمی سمت سرور را سیگنال مقصد Canonical می‌داند؛ بنابراین مقصد باید معادل و نهایی باشد، نه صفحه اصلی نامرتبط.

ریدایرکت ساده یک مسیر

# Permanent: old article to its direct equivalent
Redirect 301 /old-guide/ https://example.com/new-guide/

برای Mapping ساده، mod_alias خواناتر از Rewrite پیچیده است. پس از انتشار، خود URL قدیمی را با Follow redirect و بدون Follow آزمایش کنید: باید یک Hop مستقیم به مقصد ۲۰۰ داشته باشد، نه زنجیره ۳۰۱→۳۰۱→۲۰۰.

Redirect پیچیده با mod_rewrite

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^old-category/([0-9]+)/?$ /archive/$1/ [R=301,L,NE]
</IfModule>

قبل از Rule گروهی، نمونه‌های دارای Query string، حروف فارسی Percent-encoded، Slash انتهایی و URLهای ناموجود را تست کنید. یک Regex بیش‌ازحد عمومی می‌تواند هزاران URL را اشتباه منتقل کند.

HTTP به HTTPS و خطر Loop پشت CDN

کد زیر فقط یک نمونه برای Origin مستقیم Apache است:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L,NE]
</IfModule>

پشت CDN یا Load balancer ممکن است اتصال کاربر HTTPS باشد ولی اتصال Proxy به Origin با HTTP برسد؛ در این حالت بررسی ساده %{HTTPS} می‌تواند Loop بسازد. راه درست، اعمال Redirect در Edge یا پیکربندی آگاه از Proxy توسط مدیر سرور است. Headerهایی مثل X-Forwarded-Proto را بدون تعریف Trusted proxy مبنای امنیت قرار ندهید.

محافظت از فایل‌های حساس با Apache ۲.۴

متن قدیمی بسیاری از سایت‌ها از Order allow,deny و Deny from all مربوط به Apache ۲.۲ استفاده می‌کند. در Apache ۲.۴ از Require استفاده کنید؛ وجود Module و AllowOverride را با هاست تطبیق دهید.

<FilesMatch "^(wp-config\.php|\.env|composer\.(json|lock)|debug\.log)$">
    Require all denied
</FilesMatch>

Options -Indexes

این Rule دسترسی HTTP مستقیم را محدود می‌کند؛ اما Permission نادرست، Backup عمومی یا Account آلوده را درمان نمی‌کند. فایل‌های Secret بهتر است بیرون Document Root باشند و Permission کمینه داشته باشند. راهنمای Hardening رسمی WordPress نیز امنیت را کاهش ریسک چندلایه می‌داند، نه یک راه‌حل جادویی.

جلوگیری از اجرای PHP در Uploads

در سایتی که Uploadها نباید PHP اجرا کنند، می‌توان در wp-content/uploads/.htaccess یک کنترل محدود قرار داد:

<FilesMatch "\.(php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

اما این کنترل باید در معماری واقعی تست شود. Handlerهای PHP-FPM، NGINX جلویی، Pluginهای خاص و Storage خارجی می‌توانند رفتار متفاوتی داشته باشند. این Rule مانع آپلود اولیه یا Persistenceهای دیگر نیست؛ در رخداد واقعی از Runbook تشخیص و پاک‌سازی بدافزار WordPress استفاده کنید.

آیا با htaccess می‌توان SQL Injection و XSS را متوقف کرد؟

نه به‌تنهایی. Regexهای کپی‌شده برای Query string معمولاً False positive می‌سازند، Payloadهای Encodingشده را از دست می‌دهند و تیم را به حس امنیت کاذب می‌رسانند. دفاع اصلی SQL Injection، Query پارامتری و کنترل دسترسی است؛ دفاع XSS نیز Encoding متناسب با Context، Safe sink و در صورت نیاز CSP دارد. جزئیات را در راهنمای جلوگیری از SQL Injection و XSS بخوانید.

برای فیلتر Request، Rate limit، Bot management و Ruleهای OWASP CRS، معماری فایروال سایت و WAF مناسب‌تر است. .htaccess می‌تواند یک Control محدود در Origin باشد، اما نه مرکز عملیات دفاعی.

هدرهای امنیتی: کم، دقیق و در یک لایه

هدرها را می‌توان با mod_headers افزود، ولی ابتدا بررسی کنید CDN، پنل یا Application آن‌ها را قبلاً تنظیم نکرده باشد. Header تکراری یا سیاست متناقض می‌تواند رفتار مرورگر را مبهم کند.

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

• CSP: سیاست آماده را کپی نکنید. ابتدا Asset، Inline script، Analytics و درگاه‌ها را Inventory کنید و با Content-Security-Policy-Report-Only مشاهده کنید.
• HSTS: فقط وقتی همه مسیرها و Subdomainهای مشمول واقعاً HTTPS هستند فعال کنید. includeSubDomains و Preload تصمیم بازگشت‌پذیر چندثانیه‌ای نیستند.
• X-XSS-Protection: Header قدیمی و اتکاپذیر نیست؛ در راهنمای جدید روی CSP، Encoding و کد امن تمرکز کنید.
• CORS: Access-Control-Allow-Origin: * را راه‌حل خطای Browser ندانید؛ Origin، Credential و API contract باید مشخص باشد.

پروژه Secure Headers در OWASP مرجع مناسبی برای بررسی سیاست‌های جاری است. Headerها را با Browser DevTools یا درخواست مستقیم روی پاسخ موفق و خطا بسنجید؛ always برای برخی Headerها کمک می‌کند پاسخ‌های خطا نیز سیاست را داشته باشند.

محدودیت IP برای wp-admin؛ چرا همیشه خوب نیست؟

<RequireAny>
    Require ip 203.0.113.10
    Require ip 2001:db8:1234::/48
</RequireAny>

این Syntax نمونه Apache ۲.۴ است، اما تصمیم اجرایی به شبکه بستگی دارد. IP کاربران اینترنت ثابت و موبایل ایران ممکن است تغییر کند؛ IPv6 را نباید فراموش کرد؛ و پشت CDN، Apache ممکن است IP Proxy را ببیند. تنظیم اشتباه می‌تواند تیم، Cron، REST API، Ajax یا پشتیبانی را قفل کند.

برای پنل‌های حساس، VPN یا Zero Trust access، MFA، Session امن و Rate limit معمولاً قابل‌اداره‌ترند. IP allowlist را فقط با مسیر Break-glass، بیش از یک مدیر و تست از شبکه دوم اجرا کنید.

کش مرورگر با htaccess

کش بلندمدت برای Asset نسخه‌دار مناسب است، نه HTML شخصی، Cart، Checkout یا پاسخ API. قبل از افزودن Rule بررسی کنید WP Rocket، LiteSpeed Cache، CDN یا هاست چه Headerهایی می‌فرستد.

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/avif "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|webp|avif|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>

فقط وقتی از Cache بلندمدت استفاده کنید که URL Asset با تغییر محتوا عوض شود؛ مثلاً Filename hash یا Version معتبر داشته باشد. در غیر این صورت کاربر نسخه قدیمی CSS/JS را می‌بیند. برای کاربران ایران، CDN می‌تواند Latency و مصرف Origin را کاهش دهد، اما Ruleها باید با راهنمای انتخاب و تنظیم CDN در ایران هماهنگ باشند.

Gzip و Brotli؛ فشرده‌سازی را دوبار فعال نکنید

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css
    AddOutputFilterByType DEFLATE application/javascript application/json application/xml
</IfModule>

ابتدا با Response header و ابزار شبکه ببینید Content-Encoding در Edge یا Origin فعال است یا نه. Brotli معمولاً در CDN یا Module جدا مدیریت می‌شود. فایل‌های از قبل فشرده مثل JPEG، WebP، AVIF، MP4 و ZIP را دوباره فشرده نکنید. هدف، کاهش Byte با هزینه CPU قابل‌قبول است؛ نه صرفاً روشن‌بودن یک Toggle.

خطای ۵۰۰ بعد از تغییر htaccess؛ Runbook بازیابی

ترتیب بازیابی در cPanel یا DirectAdmin

1. از wp-admin خارج نشوید، اما به آن وابسته نمانید؛ File Manager یا SFTP را باز کنید.
2. فایل جدید را با نسخه سالم جایگزین کنید یا فقط Block تغییر را Comment کنید.
3. صفحه اصلی، Login، API و Checkout را با Cache bypass آزمایش کنید.
4. Error log Apache/LiteSpeed و Log برنامه را در بازه دقیق تغییر بررسی کنید.
5. اگر Permalinkها ۴۰۴ هستند، Block رسمی WordPress را بازیابی کنید؛ فایل خالی ممکن است Home را بالا بیاورد ولی مسیر نوشته‌ها را خراب نگه دارد.
6. پس از بازگشت سرویس، Cache هر لایه را آگاهانه Purge و Incident/Change را ثبت کنید.

برای کشف سریع قطعی، Status code و Latency چند مسیر را بیرون از سرور پایش کنید. راهنمای مانیتورینگ Uptime و عملکرد و مقاله Observability با Metric، Log و Trace چارچوب سنجش را کامل می‌کنند.

چگونه Rule را تست کنیم؟

برای هر تغییر، ماتریس Positive و Negative داشته باشید. فقط «بازشدن Home» کافی نیست.

در Shell می‌توانید Header و Hop را با curl -I و curl -IL ببینید. در محیط بدون Shell، Network panel مرورگر و ابزار پنل هاست کمک می‌کند. برای HTTPS و CDN، آزمون را هم از داخل ایران و هم از یک نقطه بیرونی انجام دهید؛ نتیجه شبکه شخصی را معادل سلامت جهانی نگیرید.

اشتباهات رایج در مدیریت htaccess

• کپی ده‌ها «کد امنیتی» بدون دانستن Module، Version و Scope
• استفاده از Syntax قدیمی Apache ۲.۲ روی Apache ۲.۴
• ویرایش داخل Block مدیریت‌شده WordPress یا Cache plugin
• ساخت Redirect عمومی پیش از Exceptionهای Callback و API
• Redirect تمام 404ها به Home و تولید Soft ۴۰۴
• فعال‌کردن HTTPS هم‌زمان در CDN، پنل، Plugin و Origin
• Cache یک‌ساله برای HTML، Checkout یا Asset بدون Version
• اعمال CSP/HSTS سخت‌گیرانه بدون Report-only و Inventory
• IP allowlist بدون IPv6، Proxy awareness و Break-glass
• تغییر چند هدف در یک Diff و ناتوانی در یافتن Rule خراب
• نگهداری Backup فایل حساس در مسیر عمومی
• تست‌نکردن Error response، REST، Cron و درگاه پرداخت

قالب Change Record برای htaccess

Change ID:
هدف کسب‌وکار:
مسئله و Baseline:
وب‌سرور و لایه مالک:
فایل/Directory:
Rule قبلی:
Rule جدید:
URLها و Endpointهای تست:
معیار موفقیت:
معیار Rollback:
نسخه Backup:
مالک اجرا:
زمان شروع/پایان:
نتیجه و شواهد:

این رکورد برای تیم کوچک هم ارزش دارد. سه ماه بعد می‌دانید هر Rule چرا وجود دارد و حذف آن چه ریسکی دارد. Comment کنار Rule باید «دلیل» را توضیح دهد، نه Syntax واضح را.

برنامه ۳۰ روزه سامان‌دهی htaccess

روز ۱ تا ۳: Inventory و Baseline

• تشخیص Web server، CDN، Plugin cache و محل همه فایل‌های .htaccess
• خروجی‌گرفتن از Ruleها و مشخص‌کردن Blockهای مدیریت‌شده
• ثبت Redirect chain، Header، 4xx/5xx و مسیرهای حیاتی

روز ۴ تا ۱۰: حذف ریسک فوری

• اصلاح Syntax منسوخ، Secretهای قابل‌دسترسی و Directory listing
• حذف Redirect loop، Soft ۴۰۴ و Ruleهای IP شکسته
• تمرین Rollback در Staging و ساخت دسترسی Break-glass

روز ۱۱ تا ۲۰: Consolidation و تست

• انتخاب یک Owner برای HTTPS، Header، Cache و Redirect
• انتقال Ruleهای سرور تحت مدیریت از .htaccess به VirtualHost در صورت دسترسی
• ساخت ماتریس Regression برای WordPress، WooCommerce و درگاه

روز ۲۱ تا ۳۰: مانیتورینگ و Governance

• Alert روی 5xx، Loop، افزایش ۴۰۳ و افت Conversion
• ثبت Change template و Review اجباری برای Ruleهای عمومی
• بازبینی فصلی Redirectها، Headerها و Ruleهای بدون Owner

پرسش‌های متداول فایل htaccess

۱. اگر فایل htaccess را حذف کنیم چه می‌شود؟

بسته به سایت، Home ممکن است باز شود اما Permalink نوشته‌ها، Redirectها، Cache یا کنترل دسترسی از کار بیفتد. حذف دائمی راه‌حل نیست؛ فایل را Rename کنید، نسخه سالم را برگردانید و از الگوی رسمی WordPress متناسب با نصب معمولی یا Multisite استفاده کنید.

۲. چرا تغییر htaccess هیچ اثری ندارد؟

ممکن است سرور NGINX باشد، AllowOverride None فعال باشد، Directive مجاز نباشد، فایل را در Directory اشتباه ویرایش کرده باشید یا CDN پاسخ Cacheشده بدهد. نوع سرور، Error log، مسیر Document Root و Header پاسخ را بررسی کنید.

۳. آیا htaccess سرعت سایت را زیاد می‌کند؟

می‌تواند Cache و Compression را تنظیم کند، اما خودش هزینه پردازش دارد و Ruleهای پیچیده ممکن است کندی بسازند. اگر به تنظیمات اصلی Apache یا CDN دسترسی دارید، همان لایه معمولاً کنترل بهتری می‌دهد. اثر را با Byte، TTFB، CPU و Cache hit بسنجید.

۴. بهترین کد امنیتی htaccess برای WordPress چیست؟

کد جهانی وجود ندارد. حداقل‌ها به Web server، Handler، Plugin، CDN و مسیرهای کسب‌وکار بستگی دارد. کنترل فایل حساس، Directory listing و Upload execution می‌توانند مفید باشند، اما Update، MFA، WAF، Backup، Logging و کد امن همچنان لازم‌اند.

۵. برای ویرایش htaccess از افزونه استفاده کنیم یا File Manager؟

مهم‌تر از ابزار، مسیر Rollback مستقل است. افزونه کار را ساده می‌کند اما اگر Rule سایت را قطع کند، شاید wp-admin هم در دسترس نباشد. File Manager یا SFTP، Backup، Diff، Staging و Change record را قبل از انتشار آماده کنید.

جمع‌بندی

.htaccess ابزار قدرتمند مدیریت رفتار Apache در سطح Directory است، نه جعبه جادویی امنیت و سرعت. قبل از هر Rule، Web server و لایه مالک را مشخص کنید؛ تغییر را کوچک نگه دارید؛ Block وردپرس را مدیریت‌شده بدانید؛ Syntax Apache ۲.۴، Proxy و CDN را لحاظ کنید؛ و با Test matrix و Rollback منتشر کنید.

اگر Ruleهای فعلی شما ترکیبی از Redirect، Header، Cache، WordPress و کنترل امنیتی بدون Owner است، پیش از افزودن کد تازه یک Audit انجام دهید. برای طراحی معماری، پاک‌سازی Ruleها و ساخت Runbook می‌توانید از مشاوره فنی و امنیتی مایندیو کمک بگیرید.

بازبینی فنی منابع: ۶ اوت ۲۰۲۶. رفتار دقیق Directiveها به نسخه Apache، Moduleها، AllowOverride و تنظیمات میزبان وابسته است.