برای رفع خطای 403 در وردپرس، اول مشخص کنید کدام لایه دسترسی را رد کرده است: CDN یا فایروال، وب‌سرور، مجوز فایل یا خود برنامه. زمان و URL خطا را با لاگ همان لایه تطبیق دهید؛ سپس فقط قانون یا دسترسی نادرست را اصلاح کنید. تغییر عمومی مجوزها یا خاموش کردن حفاظت سایت، علت را روشن نمی‌کند.
این راهنما برای مدیر سایتی است که صفحه عمومی، پیشخوان، تصویر یا ذخیره یک فرم با Forbidden روبه‌رو می‌شود. مسیر بررسی از ثبت شواهد شروع می‌شود و به راه‌حل متناسب با هاست اشتراکی یا VPS می‌رسد. نتیجه مطلوب این است که درخواست مجاز باز شود و مسیرهای خصوصی همچنان محافظت شوند.
خطای 403 چیست و چه زمانی باید باقی بماند؟
طبق تعریف 403 در MDN، سرور درخواست را فهمیده ولی انجام آن را نمی‌پذیرد. این پیام با 404، یعنی پیدا نشدن منبع، و 401، یعنی نیاز به احراز هویت معتبر، یکسان نیست. تکرار همان درخواست بدون تغییر، معمولاً همان پاسخ را می‌دهد؛ بنابراین رفرش مداوم جای عیب‌یابی را نمی‌گیرد.
همه پاسخ‌های 403 اشکال نیستند. بسته بودن فهرست یک پوشه، رد دسترسی به فایل تنظیمات یا مسدود شدن درخواست واقعاً نامجاز می‌تواند رفتار درست باشد. ابتدا مشخص کنید چه کسی، به کدام منبع و برای چه عملی باید دسترسی داشته باشد. مجوز دیدن یک صفحه، الزاماً مجوز ویرایش نوشته یا فراخوانی یک API نیست.
۱. درخواست واقعی را ثبت کنید و دامنه مشکل را بفهمید
نشانی کامل، روش درخواست، زمان همراه منطقه زمانی، وضعیت ورود و آخرین تغییر را یادداشت کنید. آیا کل سایت مسدود است یا فقط wp-admin، تصویرها یا ذخیره نوشته؟ صفحه عمومی و یک فایل موجود را جدا باز کنید. مقایسه پنجره خصوصی و یک اتصال مجاز دیگر می‌تواند نشان دهد مشکل به نشست یا IP خاص محدود است.
برای یک صفحه عمومی می‌توانید هدر پاسخ را با فرمان زیر ببینید. دامنه و مسیر نمونه را با مقصد خود جایگزین کنید:
curl -sS -D - -o /dev/null https://example.com/sample-page/در PowerShell ویندوز از curl.exe استفاده کنید و /dev/null را با NUL جایگزین کنید.
این فرمان GET می‌فرستد؛ پاسخ آن وضعیت درخواست POST ذخیره فرم را ثابت نمی‌کند. اگر خطا هنگام ذخیره است، در Network مرورگر همان درخواست ناموفق را پیدا کنید و وضعیت، URL و شناسه پاسخ را ثبت کنید. برای بازتولید پرداخت یا عملیات تغییردهنده، از محیط و داده آزمایشی استفاده کنید تا نتیجه تکراری ایجاد نشود.
| نشانه | آزمون کم‌خطر | قدم بعدی |
|---|---|---|
| فقط یک IP یا اتصال خطا می‌گیرد | تطبیق زمان و شناسه درخواست با رخداد امنیتی | بررسی قانون مسدودکننده و هدف آن |
| پس از انتقال هاست، همه صفحات 403 دارند | بررسی DocumentRoot، مالک و مسیر والد در لاگ | اصلاح مسیر یا دسترسی لازم همان سرویس |
| صفحه اصلی 403 است، ولی فایل مشخص باز می‌شود | کنترل وجود index و تنظیم صفحه ورودی | اصلاح ورودی سایت بدون فعال کردن فهرست پوشه |
| فقط ذخیره نوشته یا فرم رد می‌شود | بررسی روش درخواست و Rule ID فایروال | اصلاح استثنای محدود برای درخواست سالم |
| فقط فایل‌های تصویری باز نمی‌شوند | بررسی مسیر، مالکیت و قواعد hotlink | اصلاح دسترسی فایل یا شرط همان مسیر |
۲. بین خطای CDN و خطای مبدأ تمایز بگذارید
نام سرویس روی صفحه، Ray ID یا هدرهای پاسخ برای شروع مفیدند، اما به‌تنهایی همه علت‌ها را ثابت نمی‌کنند. Cloudflare می‌تواند پاسخ 403 مبدأ را منتقل کند یا خودش به‌دلیل یک کنترل امنیتی درخواست را رد کند. در برخی حالت‌ها حتی صفحه ساده بدون نشان تجاری هم ممکن است از لبه شبکه تولید شود؛ گزارش رخداد و لاگ مبدأ را کنار هم ببینید.
در پنل امنیتی، زمان، مسیر، IP و شناسه درخواست را جست‌وجو کنید. اگر رخداد مسدودسازی وجود دارد، نام قابلیت و قانون مطابق را ثبت کنید. اگر درخواست به مبدأ رسیده و آنجا 403 شده، بررسی را در وب‌سرور ادامه دهید. راهنمای رسمی Error 403 در Cloudflare علت‌های مبدأ و لبه را تفکیک می‌کند.
وجود خطای 1020 نیز باید با رخداد خودش بررسی شود؛ آن را اسم عمومی تمام مسدودسازی‌های WAF ندانید. در مستندات Error 1020، پیدا کردن رخداد با Ray ID یا IP و توجه به منطقه زمانی توضیح داده شده است. گزارش خالی نیز به‌تنهایی اثبات نمی‌کند همه کنترل‌های شبکه بی‌تقصیرند.
۳. اگر قانون امنیتی درخواست سالم را گرفته، همان شرط را اصلاح کنید
نمونه فرضی: صفحه ویرایش باز می‌شود، ولی ذخیره متنی که یک قطعه کد دارد با 403 شکست می‌خورد. اگر زمان و مسیر با یک Rule ID مشخص تطبیق دارد، مدیر فنی می‌تواند مثبت کاذب را بررسی کند. خاموش کردن کلی WAF یا مستثنا کردن همه درخواست‌های wp-admin، دامنه تغییر را بیش از نیاز گسترش می‌دهد.
ابتدا سالم بودن درخواست و مجاز بودن کاربر را تأیید کنید. سپس استثنا را به قانون، مسیر، روش درخواست یا شرط ضروری محدود کنید و اثر آن را ثبت کنید؛ راهنمای استثناهای WAF مرجع این تنظیم است. در هاست اشتراکی ممکن است رخداد ModSecurity فقط برای میزبان قابل مشاهده باشد. URL، ساعت و شناسه را در تیکت بفرستید؛ کوکی ورود، رمز و محتوای خصوصی فرم را حذف کنید.
۴. مسیر واقعی سایت و صفحه ورودی را بررسی کنید
پس از جابه‌جایی سایت، دامنه ممکن است به پوشه اشتباه متصل شده باشد. در پنل هاست، مسیر ریشه دامنه را با محل فایل‌های نصب مقایسه کنید. وجود پوشه‌ای با نام وردپرس به معنی درست بودن DocumentRoot نیست؛ باید همان مسیری باشد که برای دامنه موردنظر تنظیم شده است. فایل‌های چند دامنه روی یک اکانت را جابه‌جا نکنید مگر مقصد را دقیق شناخته باشید.
اگر درخواست پوشه با اسلش پایانی مطرح باشد، وب‌سرور به‌دنبال فایل ورودی تعیین‌شده می‌گردد. مستندات نگاشت URL در Apache رابطه DocumentRoot و DirectoryIndex را توضیح می‌دهد. نبودن index.php یا اشاره به پوشه اشتباه را با باز کردن عمومی فهرست فایل‌ها جبران نکنید؛ فایل و مقصد درست باید بازگردد.
مثلاً اگر پس از استخراج بکاپ، هسته داخل public_html/site قرار گرفته ولی دامنه هنوز public_html را نشان می‌دهد، ابتدا طراحی استقرار را روشن کنید. ممکن است اصلاح مسیر دامنه لازم باشد یا انتقال کنترل‌شده فایل‌ها. افزودن یک فایل خالی به نام index، صفحه واقعی را برنمی‌گرداند و فقط نشانه خطا را عوض می‌کند.
۵. مجوز و مالکیت را بر اساس کاربر سرویس اصلاح کنید
برای خواندن یک فایل، فقط عدد مجوز همان فایل مهم نیست؛ وب‌سرور باید بتواند از پوشه‌های والد هم عبور کند. در VPS، مدیر می‌تواند مسیر واقعی را با فرمان‌های فقط‌خواندنی زیر بررسی کند. مسیر نمونه را قبل از اجرا با محل سایت جایگزین کنید:
namei -l /var/www/example.com/public/index.php
stat /var/www/example.com/public/index.phpمالک، گروه و کاربر اجرای وب‌سرور یا PHP را با مدل دسترسی میزبان تطبیق دهید. در بسیاری از استقرارها 755 برای پوشه و 644 برای فایل متداول است، ولی نسخه عمومی مناسب همه هاست‌ها نیست؛ فایل‌های حساس ممکن است محدودتر باشند و روش اجرای PHP نیز اثر دارد. راهنمای امن‌سازی وردپرس بر محدود بودن دسترسی نوشتن تأکید می‌کند.
مجوز 777 یا تغییر مالکیت بازگشتی کل اکانت را راه‌حل فوری ندانید. فقط مسیر لازم و دسترسی لازم باید اصلاح شود. اگر عددها درست‌اند ولی لاگ همچنان رد دسترسی نشان می‌دهد، مدیر باید ACL و سیاست امنیتی سیستم را نیز بررسی کند؛ خاموش کردن این سیاست‌ها برای آزمایش، گام پیش‌فرض نیست. در هاست اشتراکی، پشتیبانی باید مالکیت را مطابق ساختار سرویس بررسی کند.
۶. قانون مسیر را با لاگ وب‌سرور تطبیق دهید
در Apache، دستورهای Require و تنظیم‌های سطح پوشه می‌توانند دسترسی را رد کنند. پیام لاگ مربوط به همان درخواست را بخوانید و محل قاعده را پیدا کنید؛ .htaccess تنها محل ممکن نیست. راهنمای امنیت Apache نشان می‌دهد محدودیت پایه و مجوز مسیر باید دقیق تعریف شوند. مجوز عمومی روی ریشه فایل‌سیستم اضافه نکنید.
در Nginx، ترتیب و محل allow و deny اهمیت دارد؛ اولین تطبیق می‌تواند نتیجه را تعیین کند. قواعد location خاص، مثل مسیرهای مدیریتی یا پسوند فایل، را نیز بررسی کنید. مستندات کنترل دسترسی Nginx مرجع همین رفتار است. طبق راهنمای Nginx وردپرس، Nginx مستقل فایل .htaccess را اجرا نمی‌کند؛ پس بازسازی آن درمان این لایه نیست.
از فایل تنظیم نسخه بگیرید، فقط قاعده مرتبط را تغییر دهید و پیش از اعمال، صحت پیکربندی را آزمایش کنید. در سرور دارای کنترل‌پنل، از روش پایدار همان پنل استفاده کنید. اگر مسئولیت فنی مشخص نیست، خدمات مدیریت سرور می‌تواند مسیر بررسی را سامان دهد؛ برای مالک هاست لینوکس، تیکت مستند معمولاً نقطه شروع عملی‌تری است.
آزمون نهایی: دسترسی درست، همراه با حفاظت درست
همان درخواست خطادار را با همان روش و کاربر مجاز دوباره بررسی کنید. صفحه عمومی، ورود و عملیات اصلی را جدا بسنجید؛ باز شدن صفحه اصلی برای تأیید ذخیره نوشته کافی نیست. سپس مطمئن شوید یک مسیر خصوصی که باید بسته باشد همچنان بسته است. کش مسیر تغییرکرده را در صورت نیاز هدفمند تازه کنید و لاگ جدید را ببینید.
در گزارش پایانی، علت، قانون یا مسیر اصلاح‌شده و نتیجه قبل و بعد را بنویسید. اگر هنوز علت معلوم نیست، همراه URL، ساعت و شناسه درخواست از میزبان کمک بگیرید. برای بررسی گسترده‌تر وضعیت سایت، بررسی سلامت سایت زمانی مفید است که از شواهد مشخص این اختلال شروع شود.
پرسش‌های رایج
آیا 403 یعنی سایت هک شده است؟
خیر. قانون امنیتی، مسیر اشتباه، نبود فایل ورودی یا مجوز نامتناسب هم می‌تواند آن را ایجاد کند. نشانه‌های نفوذ باید جدا و با شواهد بررسی شوند.
آیا حذف .htaccess مشکل را حل می‌کند؟
فقط اگر قاعده نادرست واقعاً در همان فایل باشد، اصلاحش مرتبط است. حذف کامل می‌تواند حفاظت و پیوندها را خراب کند؛ در Nginx مستقل هم این فایل تعیین‌کننده نیست.
چرا فقط ذخیره نوشته 403 می‌دهد؟
درخواست ذخیره با نمایش صفحه فرق دارد. مسیر، روش، محتوای درخواست، نشست و Rule ID را بررسی کنید؛ از روی باز شدن پیشخوان نمی‌توان نتیجه ذخیره را حدس زد.
آیا دسترسی 777 خطای Forbidden را رفع می‌کند؟
ممکن است نشانه‌ای را تغییر دهد، اما دسترسی بیش از نیاز ایجاد می‌کند و درمان مناسبی نیست. مالکیت، مسیر والد و نیاز واقعی کاربر سرویس را مشخص و همان بخش را اصلاح کنید.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.