رفع خطای 403: چهار منشأ که باید بشناسید

سرور 403 Forbidden برمی‌گرداند، ولی شما مطمئنید فایل روی هاست هست و مسیر را درست زده‌اید. لاگ دسترسی هم فقط کد 403 را نشان می‌دهد و هیچ سرنخی از دلیل نمی‌دهد. این وضعیت آزاردهنده است چون برخلاف خطای 500 که تقریباً همیشه یعنی خطای کد، خطای 403 می‌تواند از چهار جای کاملاً متفاوت بیاید و هرکدام راه‌حل جداگانه‌ای دارد. تا وقتی منشأ را تشخیص نداده‌اید، هر تغییری در فایل‌ها فقط حدس‌وگمان است.

اولین کاری که باید بکنید این است که بفهمید 403 از سمت وب‌سرور می‌آید یا از سمت برنامه. اگر پاسخ HTML پیش‌فرض Apache یا Nginx را می‌بینید، مشکل در لایه وب‌سرور است. اگر صفحه سفارشی خودتان با کد 403 برمی‌گردد، احتمالاً برنامه (PHP، وردپرس، فریم‌ورک) دارد این کد را تولید می‌کند و باید در کد یا پلاگین‌ها دنبالش بگردید.

منشأ اول: مجوز فایل و پوشه در لینوکس

رایج‌ترین دلیل 403 در هاست اشتراکی، مجوز اشتباه روی فایل یا پوشه است. وب‌سرور با کاربری مثل www-data یا nobody اجرا می‌شود و اگر آن کاربر اجازه خواندن فایل را نداشته باشد، پاسخ 403 می‌گیرید. با یک دستور ساده می‌توانید وضعیت را ببینید:

ls -la /home/user/public_html/index.php
find /home/user/public_html -type d -not -perm 755
find /home/user/public_html -type f -not -perm 644

خروجی دستور اول ستون مجوز را نشان می‌دهد؛ چیزی مثل -rw------- یعنی فقط مالک می‌تواند بخواند و وب‌سرور دسترسی ندارد. قاعده استاندارد این است: پوشه‌ها 755 و فایل‌ها 644. برای اصلاح:

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

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

منشأ دوم: نبود Index در پوشه

وقتی آدرس یک پوشه را باز می‌کنید و داخلش فایل index.php یا index.html نیست، وب‌سرور دو انتخاب دارد: نمایش لیست فایل‌ها یا برگرداندن 403. اکثر هاست‌ها به‌دلایل امنیتی گزینه دوم را انتخاب می‌کنند. پس اگر آدرس example.com/blog/ را می‌زنید و 403 می‌گیرید، اول ببینید آیا اصلاً فایلی به نام index داخل آن پوشه هست:

ls -la /home/user/public_html/blog/

اگر خالی بود یا فقط فایل‌های جانبی داشت، مشکل همین است. یا باید فایل index بسازید، یا در .htaccess مسیر را به فایل دیگری هدایت کنید:

DirectoryIndex index.php index.html home.php

نکته‌ای که کمتر دیده می‌شود: گاهی فایل index هست ولی نامش با حروف بزرگ شروع می‌شود، مثل Index.php. روی سرورهای لینوکسی نام فایل حساس به بزرگی و کوچکی حروف است و وب‌سرور آن را پیدا نمی‌کند. این مورد روی ویندوز هرگز پیش نمی‌آید و به همین دلیل وقتی سایت را از یک هاست ویندوزی منتقل می‌کنید، ناگهان با 403 روبه‌رو می‌شوید.

منشأ سوم: قواعد htaccess و محدودیت IP

فایل .htaccess می‌تواند به‌صراحت دسترسی را رد کند. دو الگوی رایج:

# Apache 2.4
Require all denied

# Apache 2.2 (قدیمی)
Order deny,allow
Deny from all

اگر این خطوط در فایل باشند، همه درخواست‌ها 403 می‌گیرند. حالت ظریف‌ترش وقتی است که یک قاعده IP-based دارید و IP شما عوض شده:

Require ip 185.55.10.20
Require ip 91.98.0.0/16

اینجا فقط IPهای فهرست‌شده اجازه ورود دارند و بقیه 403 می‌گیرند. اگر IP شما تغییر کرده، خودتان هم قفل می‌شوید. برای تست، فایل .htaccess را موقتاً به .htaccess.bak تغییر نام دهید و صفحه را دوباره باز کنید. اگر مشکل حل شد، مقصر همین فایل بوده و باید خط به خط بررسی‌اش کنید. یادتان باشد بعد از تست، فایل را برگردانید.

یک نکته عملی: اگر IP شما پویا است و مدام عوض می‌شود، محدودسازی بر اساس IP برای پنل مدیریت انتخاب بدی است. جایگزین بهتر، احراز هویت دو مرحله‌ای روی خود پنل است تا وابسته به IP نباشید.

منشأ چهارم: ModSecurity و فایروال لایه وب

این مورد بیشتر از همه گیج‌کننده است، چون فایل‌ها و مجوزها همه سالم‌اند و .htaccess هم مشکلی ندارد، ولی درخواست شما قبل از رسیدن به سایت مسدود می‌شود. ModSecurity یک فایروال لایه وب است که درخواست‌ها را بر اساس قواعد امنیتی بررسی می‌کند و اگر الگویی مشکوک تشخیص دهد، با کد 403 پاسخ می‌دهد.

نشانه‌اش این است: یک فرم خاص کار نمی‌کند، یا آدرس‌هایی که پارامتر خاصی دارند 403 می‌گیرند، ولی بقیه سایت سالم است. مثلاً ارسال یک کوئری با کلمه union select در پارامتر، یا آپلود فایلی که پسوندش در فهرست سیاه است. برای دیدن دلیل دقیق، باید لاگ ModSecurity را ببینید:

tail -f /var/log/modsec_audit.log
grep "403" /var/log/apache2/error.log | tail -20

در لاگ دنبال شناسه قاعده بگردید؛ چیزی مثل [id "942100"] که به SQL Injection اشاره دارد. اگر مطمئنید درخواست شما سالم است، می‌توانید آن قاعده خاص را غیرفعال کنید، ولی این کار را فقط برای قاعده مشخص انجام دهید، نه کل ModSecurity. خاموش کردن کامل فایروال، سایت را در برابر حملات واقعی بی‌دفاع می‌گذارد.

چطور سریع تشخیص دهیم کدام منشأ است

ترتیب بررسی را عوض نکنید. اول با curl هدرهای پاسخ را ببینید:

curl -I https://example.com/blog/

اگر هدر Server: Apache یا Server: nginx بود و صفحه پیش‌فرض 403 برگشت، مشکل در لایه وب‌سرور است. اگر هدرهای اختصاصی برنامه (مثل X-Powered-By: PHP) را دیدید، مشکل در کد است. بعد به ترتیب مجوز فایل، وجود index، قواعد htaccess و در آخر ModSecurity را بررسی کنید. این ترتیب از ساده به پیچیده است و معمولاً در دو مرحله اول حل می‌شود.

اگر روی هاست لینوکس کار می‌کنید و به لاگ ModSecurity دسترسی ندارید، از پشتیبانی بخواهید شناسه قاعده را برایتان استخراج کند؛ این اطلاعات معمولاً در سطح کاربر نمایش داده نمی‌شود. برای بررسی مسائل شبکه‌ای و DNS هم می‌توانید از ابزار بررسی DNS و شبکه استفاده کنید تا مطمئن شوید درخواست به سرور درست می‌رسد.

یک نکته که در عمل زیاد به آن برمی‌خورم: اگر سایت را تازه از سرور دیگری منتقل کرده‌اید و 403 می‌گیرید، احتمال زیادی دارد که فایل .htaccess قدیمی با تنظیمات سرور قبلی روی سرور جدید مشکل ایجاد کند. قبل از هر کار دیگری، این فایل را موقتاً غیرفعال کنید. همچنین اگر از سیستم‌های مدیریت محتوا استفاده می‌کنید، پوشه wp-admin یا معادلش را بررسی کنید، چون بعضی افزونه‌های امنیتی خودشان قاعده‌ای اضافه می‌کنند که بعد از به‌روزرسانی، دسترسی مدیر را می‌بندد.

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

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

تفاوت خطای 403 و 401 چیست؟

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

آیا خطای 403 می‌تواند از سمت CDN باشد؟

بله. بعضی CDNها بر اساس قواعد امنیتی خودشان درخواست‌ها را مسدود می‌کنند و کد 403 برمی‌گردانند. برای تشخیص، هدرهای پاسخ را با curl -I بررسی کنید؛ اگر نام سرور CDN را دیدید نه وب‌سرور اصلی، باید قواعد آن سرویس را بررسی کنید.

چرا فقط من 403 می‌گیرم و بقیه کاربران مشکل ندارند؟

احتمالاً محدودیت بر اساس IP اعمال شده یا حساب کاربری شما در فهرست مسدودشده‌ها قرار گرفته است. با یک اتصال اینترنت دیگر یا VPN تست کنید. اگر مشکل حل شد، مقصر قاعده IP-based در .htaccess یا فایروال سرور است.

آیا تغییر مجوز فایل به 777 مشکل را حل می‌کند؟

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

قدم بعدی این است که همین حالا با curl -I هدرهای پاسخ را بگیرید و مشخص کنید 403 از کدام لایه می‌آید. تا وقتی این را ندانید، هر تغییری در فایل‌ها فقط زمان تلف کردن است.