406 غير مقبول في ووردبريس محبطًا، خاصةً عندما يعيق وصول المستخدمين أو وظائف واجهة برمجة التطبيقات (API). مع ذلك، باتباع نهج منظم، يمكنك تحديد السبب الجذري بسرعة واستعادة العمليات الطبيعية. يرشدك هذا الدليل خلال عملية تشخيص المشكلة وحلها من جانب العميل والخادم، بالإضافة إلى خطوات تصحيح الأخطاء الخاصة بووردبريس.
باختصار: حلول سريعة لخطأ 406 في ووردبريس
إذا واجهت خطأ 406 غير مقبول، فقم بتطبيق هذه الفحوصات السريعة لاستعادة الوظائف:
- قم بمسح ذاكرة التخزين المؤقت واختبر المتصفح في وضع التصفح المتخفي لاستبعاد مشاكل المتصفح.
- تحقق من بنية عنوان URL وقم بإزالة امتدادات الملفات المفروضة.
- قم بتعطيل جميع الإضافات مؤقتًا، وخاصة إضافات الأمان.
- قم بالتبديل إلى السمة الافتراضية للتخلص من تعارضات السمات.
- تحقق من سجلات الخادم بحثًا عن كتل متعلقة بـ ModSecurity أو MIME.
- قم بالتراجع عن التحديثات الأخيرة إذا ظهر الخطأ بعد إجراء التغييرات.
تساهم هذه الخطوات في حل معظم أخطاء 406 بسرعة وأمان.
نظرة سريعة على خطأ HTTP 406 غير مقبول
تم تعريف رمز الحالة 406 غير مقبول في مواصفات HTTP على أنه خطأ في التفاوض على المحتوى.

يحدث ذلك عندما:
- يرسل العميل ترويسة Accept تحدد أنواع محتوى معينة.
- لا يمكن للخادم تقديم استجابة مطابقة لأنواع المحتوى هذه.
- قواعد الأمان (مثل ModSecurity ) بحظر الطلب.
- أنواع MIME أو إعدادات الخادم غير صحيحة.
في ووردبريس، يحدث هذا الخطأ عادةً بسبب:
- قواعد ملف .htaccess غير صحيحة
- أخطاء في تكوين مفاوضات المحتوى
- قوالب أو إضافات تالفة
- قواعد جدار الحماية الصارمة على مستوى الاستضافة
يُعد فهم السياق الذي يظهر فيه الخطأ (منطقة الإدارة، واجهة برمجة تطبيقات REST ، صفحة معينة، إلخ) أمرًا بالغ الأهمية للتشخيص الدقيق.
احصل على دعم فني متخصص لإصلاح أخطاء ووردبريس بسرعة
يقوم خبراؤنا في ووردبريس بتشخيص المشكلات بسرعة لاستعادة موقعك. تواصل معنا اليوم للحصول على خدمة سريعة وموثوقة لحل المشكلات، واستعد موقعك للعمل بأقل وقت توقف ممكن.
كيفية تشخيص خطأ 406 غير مقبول في ووردبريس؟
قبل تطبيق الإصلاحات، من الضروري تشخيص خطأ 406 غير مقبول بشكل صحيح.

رمز حالة HTTP هذا يرتبط عادةً بالتفاوض على المحتوى أو تصفية الأمان أو الرؤوس غير المهيأة بشكل صحيح، فإن اتباع نهج تشخيصي منظم يساعدك على تحديد السبب الدقيق.
بدلاً من التخمين، اتبع الطرق التالية لتحديد السبب الجذري بشكل منهجي.
افحص طلب الشبكة الخاص بالمتصفح
افتح أدوات مطوري المتصفح وراجع الطلب الفاشل ضمن علامة تبويب الشبكة . انتبه جيدًا إلى رؤوس Accept ورؤوس الاستجابة وتفاصيل رمز الحالة. سيساعدك هذا في تحديد ما إذا كانت المشكلة ناتجة عن تقييد التفاوض على نوع المحتوى.
اختبر في وضع التصفح المتخفي أو متصفح آخر
بعد ذلك، اختبر نفس عنوان URL في نافذة التصفح المتخفي/الخاص أو في متصفح آخر. إذا اختفى الخطأ، فقد تكون الملفات المخزنة مؤقتًا أو ملفات تعريف الارتباط أو إضافات المتصفح تتداخل مع الطلب.
تحقق من بنية عنوان URL المطلوب
راجع عنوان URL بعناية بحثًا عن أخطاء إملائية، أو مسارات غير صحيحة، أو امتدادات ملفات قسرية مثل .json أو .xml. كما يمكن أن يساعد اختبار الصفحة الرئيسية في تحديد ما إذا كانت المشكلة خاصة بعنوان URL معين.
راجع سجلات تصحيح أخطاء ووردبريس
فعّل وضع تصحيح الأخطاء في ووردبريس (WP_DEBUG) وتحقق من ملف السجل /wp-content/debug.log . تكشف هذه الخطوة عن تعارضات متعلقة بالإضافات أو القوالب أو لغة PHP والتي قد تتسبب في ظهور استجابة 406.
تحليل سجلات الوصول إلى الخادم وسجلات الأخطاء
عند تشخيص خطأ 406 غير مقبول، توفر سجلات الخادم الدليل الأكثر موثوقية.
بدلاً من الاعتماد على الافتراضات، تكشف ملفات السجل بدقة كيف عالج الخادم الطلب ولماذا تم رفضه. لذلك، ينبغي أن تكون مراجعة سجلات الوصول وسجلات الأخطاء أولوية أثناء استكشاف الأخطاء وإصلاحها.
فتح سجلات الوصول لإدخالات حالة 406 : أولاً، افحص سجلات الوصول الخاصة بخادم الويب الخاص بك للتأكد من متى وكم مرة تظهر حالة 406.
- بالنسبة لـ Apache، تحقق من : /var/log/apache2/access.log
- بالنسبة لـ NGINX، تحقق من : /var/log/nginx/access.log
ابحث تحديدًا عن إدخالات HTTP 406. يساعدك هذا في تحديد عناوين URL المتأثرة، وطرق الطلب، وعناوين IP، ووكلاء المستخدم.
افتح سجلات الأخطاء للبحث عن طوابع زمنية متطابقة : بعد ذلك، قارن هذه الإدخالات بسجلات الأخطاء . راجع سجلات أخطاء Apache وNGINX وسجلات PHP. يمكن أن تكشف الطوابع الزمنية المتطابقة ما إذا كانت المشكلة ناتجة عن سوء تكوين، أو فشل في تنفيذ البرامج النصية، أو تطبيق قواعد الأمان.
ربط سجلات النظام بإجراءات الإضافات أو القوالب : أخيرًا، قم بمواءمة الطوابع الزمنية للسجلات مع التغييرات الأخيرة في الموقع. على سبيل المثال ، تحقق مما إذا كان الخطأ قد بدأ بعد تحديث إضافة، أو تعديل قالب، أو تفعيل قاعدة أمان. غالبًا ما يُحدد هذا الربط المكون المسؤول تحديدًا عن ظهور استجابة 406.
تحقق من سجلات الأمان وجدار الحماية
أخيرًا، افحص سجلات ModSecurity أو جدار حماية تطبيقات الويب أو إضافات الأمان. في كثير من الحالات، تحظر هذه الأدوات الطلبات المشبوهة، مما يؤدي إلى ظهور خطأ 406.
كيفية حل مشكلة الخطأ 406 غير مقبول في ووردبريس؟
بمجرد تحديد الأسباب المحتملة، ابدأ في استكشاف الأخطاء وإصلاحها بشكل منهجي.
الحل الأول: استكشاف الأخطاء وإصلاحها من جانب العميل
قبل تعديل إعدادات الخادم أو إعدادات ووردبريس ، من المهم استبعاد الأسباب المتعلقة بجانب العميل.
في كثير من الحالات، يتم تشغيل خطأ 406 غير مقبول بسبب ذاكرة التخزين المؤقت للمتصفح، أو الرؤوس التقييدية، أو تداخل الشبكة المحلية.
لذلك، ابدأ بالفحوصات التالية لتحديد ما إذا كانت المشكلة تنشأ من بيئة المستخدم بدلاً من الخادم.
- أولاً، امسح ذاكرة التخزين المؤقت وملفات تعريف الارتباط في متصفحك . قد تُرسل الملفات المخزنة أو بيانات الجلسة القديمة رؤوس طلبات غير صحيحة، مما قد يؤدي إلى فشل عملية التفاوض على المحتوى. بعد مسحها، أعد تحميل الصفحة لمعرفة ما إذا كانت المشكلة لا تزال قائمة.
- بعد ذلك، افتح الرابط المتأثر في نافذة تصفح متخفي أو خاص. سيؤدي هذا إلى تعطيل معظم الإضافات والبيانات المخزنة مؤقتًا. إذا تم تحميل الصفحة بشكل صحيح، فقد تكون المشكلة متعلقة بإضافات المتصفح أو بيانات الاعتماد المخزنة.
- بعد ذلك، افتح أدوات مطوري المتصفح وافحص الطلب الفاشل ضمن علامة تبويب الشبكة. انتبه إلى قيم رأس Accept. إذا كانت هذه القيم مقيدة للغاية (مثل اشتراط JSON فقط)، فقد يرفض الخادم الاستجابة.
أخيرًا، قم بتغيير الشبكة أو أعد تشغيل جهاز التوجيه. في بعض الأحيان، قد تُعدّل إعدادات الخوادم الوكيلة أو الشبكات الافتراضية الخاصة أو جدار الحماية رؤوس الطلبات، مما يؤدي عن غير قصد إلى ظهور خطأ 406.
الحل الثاني: استكشاف الأخطاء وإصلاحها من جانب الخادم
إذا لم تحل عمليات التحقق من جانب العميل المشكلة، فإن الخطوة التالية هي فحص تكوين الخادم الخاص بك.

بما أن الخطأ 406 غير مقبول يرتبط عادةً بالتفاوض على المحتوى أو معالجة الاستجابة بشكل خاطئ، فإن مراجعة إعدادات خادم الويب الخاص بك أمر ضروري.
من خلال الفحص المنهجي لهذه المناطق، يمكنك تحديد تعارضات التكوين التي تمنع الطلبات الصحيحة.
افحص إعدادات التفاوض على محتوى خادم الويب
أولاً، قم بتحليل كيفية تعامل خادمك مع عملية التفاوض على المحتوى.
- بالنسبة لـ Apache ، راجع إعدادات وحدة mod_negotiation. تحديدًا، تحقق مما إذا كان توجيه MultiViews مُفعّلاً في ملف .htaccess الخاص بك، لأنه قد يُجبر على مطابقة محتوى غير متوقعة.
- بالنسبة لـ NGINX ، تحقق من كيفية معالجة أنواع المحتوى داخل قسم الأنواع. بالإضافة إلى ذلك، افحص قواعد إعادة الكتابة للتأكد من أنها لا تتعارض مع معالجة الطلبات.
تحقق من أنواع MIME الخاصة بالخادم للموارد المطلوبة
بعد ذلك، تأكد من أن خادمك يدعم جميع أنواع MIME المطلوبة. على سبيل المثال ، تأكد من التكوين الصحيح لأنواع application/json و text/html و application/xml.
إذا كانت هذه الأنواع مفقودة أو تم تعيينها بشكل غير صحيح، فقد يرفض الخادم الطلب ويعيد حالة 406.
مراجعة قواعد إعادة الكتابة أو إعادة التوجيه المخصصة
افحص قواعد إعادة الكتابة والتوجيه المخصصة. ابحث عن قواعد .htaccess صارمة للغاية، أو قواعد إعادة كتابة NGINX غير صحيحة، أو حلقات إعادة توجيه محتملة. حتى الأخطاء البسيطة في الإعدادات قد تُعطّل عملية التفاوض على الاستجابة وتؤدي إلى ظهور هذا الخطأ.
اضبط قواعد ModSecurity على الخادم
راجع سجلات ModSecurity لتحديد معرّف القاعدة المحدد الذي تسبب في الحظر. بمجرد تحديده، يمكنك إما تعطيل تلك القاعدة بشكل انتقائي أو إضافة عنوان URL أو المعلمة المتأثرة إلى القائمة البيضاء.
مع ذلك، تجنب تعطيل ModSecurity بالكامل. بدلاً من ذلك، قم بإجراء تعديلات دقيقة للحفاظ على الأمان مع السماح بالطلبات المشروعة.
إزالة قيود رأس القبول الإشكالية من العملاء
افحص طلبات جانب العميل أو طلبات مستوى التطبيق بحثًا عن رؤوس Accept المقيدة.
على سبيل المثال ، إذا طلب برنامج نصي فقط application/json ولكن الخادم يستجيب بـ text/html، فقد يتم رفض الطلب.
يؤدي تعديل رأس الصفحة للسماح بأنواع محتوى أوسع إلى حل مشكلة عدم التوافق هذه في كثير من الأحيان.
تنظيف مدخلات الطلب التي تؤدي إلى تفعيل قواعد الأمان
أخيرًا، راجع سلاسل الاستعلامات، ومدخلات النماذج، وبيانات واجهة برمجة التطبيقات (API). قد تؤدي الأحرف الخاصة، أو المعلمات غير المشفرة، أو الأنماط المشبوهة إلى تفعيل قواعد جدار الحماية. يقلل تنظيف المدخلات وتشفيرها بشكل صحيح من الإنذارات الكاذبة ويمنع حدوث أخطاء 406 مستقبلًا.
الحل الثالث: تصحيح أخطاء ووردبريس تحديدًا لخطأ 406
إذا لم تكشف التشخيصات على مستوى الخادم عن السبب، فقد تكون المشكلة متجذرة في ووردبريس نفسه.

بما أن الإضافات أو القوالب أو التعليمات البرمجية المخصصة يمكنها تغيير الرؤوس أو قواعد إعادة الكتابة أو معالجة الطلبات، فإن عملية تصحيح الأخطاء المنظمة ضرورية.
من خلال عزل المكونات بشكل منهجي، يمكنك تحديد ما الذي يؤدي إلى ظهور استجابة 406.
- تفعيل WP_DEBUG وWP_DEBUG_LOG في ملف wp-config.php : أولًا، فعّل وضع تصحيح الأخطاء في ووردبريس بتفعيل WP_DEBUG وWP_DEBUG_LOG في ملف wp-config.php. تسمح هذه الخطوة لووردبريس بتسجيل إشعارات PHP والتحذيرات والأخطاء في ملف /wp-content/debug.log. يمكن أن تكشف مراجعة هذا السجل عن التعارضات أو الدوال المهملة أو مشاكل الإخراج التي تُساهم في الخطأ.
- تعطيل جميع الإضافات مؤقتًا : بعد ذلك، قم بتعطيل جميع الإضافات دفعة واحدة. ثم اختبر الصفحة أو نقطة النهاية المتأثرة. إذا اختفى الخطأ، فهذا يؤكد أن إحدى الإضافات هي المسؤولة. تُعد إضافات الأمان، وجدران الحماية، أو إضافات تعديل الترويسة من الأسباب الشائعة لهذه المشكلة.
- التبديل إلى قالب ووردبريس افتراضي : بعد ذلك، قم بالتبديل مؤقتًا إلى قالب افتراضي مثل Twenty Twenty-Four . يساعد هذا في تحديد ما إذا كانت وظائف القالب أو القوالب المخصصة أو البرامج النصية المضمنة تتداخل مع معالجة الطلبات.
- أعد تثبيت الإضافات واحدة تلو الأخرى لتحديد الإضافة المُسببة للمشكلة : أخيرًا، أعد تفعيل الإضافات بشكل فردي مع إجراء اختبار في كل مرة. يساعدك هذا الأسلوب المُحكم على تحديد الإضافة التي تُسبب خطأ 406 بدقة، ومن ثم تطبيق حل مُناسب لها.
الحل الرابع: التراجع عن التحديثات الأخيرة
إذا ظهر الخطأ 406 بعد فترة وجيزة من التحديث، فمن المرجح أن تكون التغييرات الأخيرة هي السبب.
بما أن نظام ووردبريس الأساسي والإضافات والقوالب تقوم بشكل متكرر بتعديل معالجة الطلبات أو منطق الأمان، فإن التراجع عن التحديثات يمكن أن يعيد الاستقرار بسرعة.
لذلك، ينبغي أن تكون مراجعة التحديثات الأخيرة جزءًا من سير عمل التشخيص الخاص بك.
- أولاً، تحقق من لوحة تحكم ووردبريس أو سجلات الاستضافة بحثاً عن التحديثات الأخيرة. حدد ما إذا كانت المشكلة قد بدأت بعد تغيير في إصدار أحد الإضافات أو القوالب أو النظام الأساسي.
- بعد ذلك، قم بتخفيض إصدار الإضافة أو القالب المشتبه به إلى إصدار مستقر سابق. يمكنك القيام بذلك يدويًا عبر بروتوكول نقل الملفات (FTP) أو باستخدام أداة استعادة الإصدارات السابقة.
- وأخيرًا، إذا لم يؤدِ الرجوع إلى إصدار أقدم إلى حل المشكلة، فقم باستعادة نسخة احتياطية كاملة للموقع من نقطة قبل حدوث الخطأ.
تم التحقق بنجاح واختبار ما بعد الإصلاح
بعد تطبيق الإصلاحات اللازمة، من الضروري التأكد من حل مشكلة الخطأ 406 غير مقبول بشكل كامل.
بدلاً من افتراض حل المشكلة، يضمن التحقق المنظم استقرار النظام على المدى الطويل. لذا، يُنصح بإجراء اختبارات شاملة بعد الإصلاح للتأكد من عدم وجود أي تعارضات متبقية في الإعدادات.
قم بتشغيل طلبات cURL للتأكد من عدم وجود استجابات 406
أولاً، استخدم أداة curl لاختبار عناوين URL المتأثرة مباشرةً من سطر الأوامر. تتجاوز هذه الطريقة المتغيرات المتعلقة بالمتصفح وتوفر رؤوس استجابة HTTP الخام.
تأكد من أن الخادم يُعيد الآن حالة 200 OK بدلاً من 406 Not Acceptable. يُنصح باختبار نقاط نهاية متعددة، بما في ذلك مسارات واجهة برمجة التطبيقات (API).
اختبار صفحات الموقع الرئيسية عبر متصفحات متعددة
بعد ذلك، افتح الصفحات الأساسية، مثل الصفحة الرئيسية وصفحة الاتصال وشاشة تسجيل الدخول ولوحة تحكم الإدارة، على مختلف المتصفحات والأجهزة. تضمن هذه الخطوة سلوكًا متسقًا بغض النظر عما إذا كانت الجلسات مخزنة مؤقتًا أو يتم استخدام معالجة خاصة بكل متصفح.
تأكد من عدم ظهور رسائل "تم التحقق بنجاح"
أخيرًا، راجع لوحات معلومات الأمان وسجلات النظام للتأكد من عدم ظهور أي تحذيرات إضافية تتعلق بالحظر أو التحقق. تساعد المراقبة المستمرة على منع تكرار المشكلة.
نصائح إضافية للوقاية والمراقبة
بمجرد حل مشكلة الخطأ 406 غير مقبول، تصبح الأولوية التالية هي الوقاية.
نظراً لأن تعارضات التكوين وقواعد الأمان والتحديثات يمكن أن تعيد إدخال مشكلات مماثلة، فإن المراقبة والصيانة الاستباقية أمر ضروري.
من خلال تطبيق إجراءات وقائية منظمة، يمكنك تقليل وقت التوقف وتحسين استقرار الموقع على المدى الطويل.
- جدولة نسخ احتياطية منتظمة قبل التحديثات : أولاً، احرص دائمًا على إنشاء نسخ احتياطية كاملة قبل تحديث نظام ووردبريس الأساسي أو الإضافات أو القوالب. يشمل ذلك الملفات وقاعدة البيانات. بهذه الطريقة، تضمن إمكانية استعادة نسخة مستقرة بسرعة في حال تسبب التحديث في ظهور أخطاء 406 غير متوقعة.
- مراقبة سجلات الخادم بحثًا عن أخطاء 406 المتكررة : بعد ذلك، راجع سجلات الوصول إلى الخادم وسجلات الأخطاء بشكل دوري. ابحث تحديدًا عن رموز الحالة 406 المتكررة أو الطلبات المحظورة. يمكن أن يساعدك إعداد تنبيهات مراقبة السجلات في اكتشاف الأنماط مبكرًا، مما يسمح لك بمعالجة المشكلات قبل تفاقمها.
- توثيق تغييرات إعدادات النظام لتسهيل التراجع عنها مستقبلاً : احتفظ بسجل لتعديلات الخادم، وتغييرات قواعد الأمان، وتغييرات إعادة كتابة الروابط. يُسهّل التوثيق السليم عملية استكشاف الأخطاء وإصلاحها، ويُمكّن من التراجع بشكل أسرع عند الضرورة.
- اتصل بدعم الاستضافة عندما تكون الأسباب الجذرية غير واضحة : أخيرًا، إذا أشارت السجلات إلى وجود قيود على مستوى الخادم أو تطبيق جدار الحماية خارج عن سيطرتك، فاتصل بمزود خدمة الاستضافة. يمكنهم تحليل قواعد ModSecurity، أو إعدادات MIME، أو مرشحات الشبكة بشكل أكثر شمولاً.
الخاتمة
يرتبط خطأ 406 غير مقبول في ووردبريس عادةً بعدم تطابق مفاوضات المحتوى أو القيود الأمنية أو سوء تكوين الخادم.
ومع ذلك، باتباع عملية استكشاف الأخطاء وإصلاحها المنظمة، بدءًا من عمليات التحقق من جانب العميل والتقدم إلى تصحيح الأخطاء الخاصة بالخادم ووردبريس، يمكنك عزل المشكلة وحلها بكفاءة.
الأهم من ذلك كله، تحقق دائمًا من سجلات النظام قبل إجراء أي تغييرات. فمن خلال التشخيص الدقيق والمراقبة الوقائية، يمكنك تقليل الأعطال المستقبلية والحفاظ على بيئة ووردبريس مستقرة.
الأسئلة الشائعة حول خطأ 406 في ووردبريس
ماذا يعني خطأ 406 في ووردبريس؟
يُعد الخطأ 406 من بين استجابات أخطاء الخادم التي يتم تشغيلها عندما يتعذر على الخادم إنشاء استجابة مقبولة بناءً على القيم المقبولة المحددة في رؤوس الطلب.
هل الخطأ 406 مشكلة في العميل أم في الخادم؟
على الرغم من أنها غالباً ما تُصنف ضمن استجابات أخطاء العميل، إلا أنها تُعتبر عادةً استجابات أخطاء الخادم لأنها غالباً ما تنجم عن مشاكل من جانب الخادم.
ما الذي يسبب هذا الخطأ عادةً؟
تشمل الأسباب الشائعة المكونات الإضافية المعيبة، وقواعد الأمان التقييدية، أو رؤوس البيانات غير المهيأة بشكل صحيح مثل Accept-Language أو Accept-Encoding.
كيف تؤدي العناوين إلى ظهور استجابة 406؟
إذا تضمن طلب HTTP قيمًا مقبولة صارمة لنوع المحتوى أو تنسيقه، فقد لا يتمكن الخادم من إرجاع استجابة مناسبة.
هل يمكن أن تتسبب التحديثات في تعطيل موقع ويب؟
نعم، بعد التحديث الأخير، قد تتطلب التعارضات داخل نظام إدارة المحتوى أو أجزائه المتحركة استعادة إصدار سابق.
كيف يمكنني التأكد من السبب الجذري؟
للتأكد من السبب الجذري، تحقق جيدًا من سجلات جانب الخادم لتحديد طلبات HTTP المحظورة وراجع اقتراحات التكوين من نظام الاستضافة الخاص بك.
هل يمكن أن تتسبب أنواع الملفات في حدوث الخطأ؟
نعم، أحد الأمثلة على ذلك هو عندما يتم طلب ملف CSS بتنسيق غير مدعوم، مما يؤدي إلى فشل عملية التفاوض.