العودة إلى المدونة

موقعك ما زال "غير آمن" بعد تثبيت SSL؟ اكتشف المحتوى المختلط وأصلحه

فريق تحرير IM Host25 أكتوبر 20266 دقائق قراءة
موقعك ما زال "غير آمن" بعد تثبيت SSL؟ اكتشف المحتوى المختلط وأصلحه

ثبّت شهادة SSL، وأصبح العنوان يبدأ بـ https://، ومع ذلك ما زال المتصفح يعرض "غير آمن" أو قفلًا مع تحذير. في أغلب الحالات تكون الشهادة سليمة، والمشكلة في المحتوى المختلط (Mixed Content): الصفحة تُحمَّل عبر HTTPS، لكن بعض صورها أو سكربتاتها أو ملفات التنسيق أو الخطوط ما زالت تُحمَّل عبر HTTP العادي.

يشرح هذا الدليل كيف تتأكد أن المحتوى المختلط هو السبب، وكيف تعثر على كل رابط غير آمن، وكيف تصلحه بالطريقة الصحيحة في ووردبريس وفي المواقع الأخرى. ويتناول أيضًا الحالات القليلة التي تكون فيها المشكلة في الشهادة نفسها.

لماذا يكسر رابط http:// واحد علامة القفل

لا يحمي HTTPS الصفحة كاملة إلا إذا كان كل مورد فيها مشفّرًا. فإذا حُمّل سكربت عبر HTTP، يستطيع أي طرف على مسار الشبكة تعديله والتحكم في الصفحة. ولهذا تتعامل المتصفحات مع الأمر بجدية.

  • المحتوى المختلط النشط (السكربتات وiframe وملفات التنسيق وطلبات fetch وXHR) يُحظر. وقد تبدو الصفحة معطوبة: تنسيقات مفقودة، وعروض شرائح لا تتحرك، ونماذج لا تُرسل.

  • المحتوى المختلط الخامل (الصور والصوت والفيديو) ترقّيه المتصفحات الحديثة غالبًا إلى HTTPS تلقائيًا. وإذا لم تكن نسخة HTTPS موجودة يُحظر الملف وتُعلَّم الصفحة بأنها غير آمنة بالكامل.

وفي الحالتين الحل واحد: اجعل كل رابط في الصفحة يستخدم HTTPS.

الخطوة 1: تأكد أن المشكلة محتوى مختلط

افتح الصفحة في Chrome أو Edge أو Firefox، واضغط F12، وافتح تبويب Console، ثم أعد تحميل الصفحة. يظهر المحتوى المختلط برسائل مثل هذه:

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure image 'http://example.com/wp-content/uploads/logo.png'. This content should also be served over HTTPS.

كل رسالة تذكر الملف بعينه. وفي Chrome تعرض لوحة Security في أدوات المطور ملخصًا لوجود محتوى مختلط ولصلاحية الشهادة. لا تكتفِ بالصفحة الرئيسية؛ فالمقالات وصفحات المنتجات وصفحة الدفع كثيرًا ما تحتوي على محتوى قديم بروابط مكتوبة يدويًا.

الخطوة 2: اعثر على كل رابط http://

لا تعرض وحدة التحكم إلا ما تحمّله الصفحة الحالية. لفحص HTML وCSS مباشرة استخدم curl وgrep:

# List http:// references in the HTML of one page
curl -s https://example.com/ | grep -oE '(src|href)="http://[^"]+"' | sort -u

# Check CSS files too (background images and fonts)
curl -s https://example.com/wp-content/themes/your-theme/style.css | grep -o 'http://[^)"]*' | sort -u

المصادر المعتادة للروابط غير الآمنة:

  • روابط الصور والروابط المحفوظة داخل المقالات والصفحات قبل انتقال الموقع إلى HTTPS.

  • خيارات القالب وإعدادات أدوات بناء الصفحات التي تحفظ روابط كاملة، مثل الشعار أو صورة الخلفية.

  • روابط مكتوبة يدويًا في ملفات القالب أو CSS القالب الفرعي أو JavaScript مخصص.

  • تضمينات وأدوات خارجية أُضيفت بعنوان http://.

  • خطوط وأيقونات تُحمَّل من شبكة CDN خارجية عبر http://.

الخطوة 3: الإصلاح في ووردبريس

اجعل رابطي الموقع يبدآن بـ HTTPS

في Settings > General تأكد أن WordPress Address (URL) وSite Address (URL) يبدآن بـ https://. إذا كان الحقلان غير قابلين للتعديل فهما مضبوطان في wp-config.php عبر WP_HOME وWP_SITEURL، فعدّلهما هناك.

استبدل الروابط القديمة في قاعدة البيانات

المقالات والودجات وكثير من إعدادات الإضافات تحفظ روابط كاملة في قاعدة البيانات. الاستبدال المباشر عبر SQL قد يُفسد البيانات المتسلسلة (serialized)، لذا استخدم أداة تفهمها. باستخدام WP-CLI:

# 1. Back up the database first
wp db export before-https.sql

# 2. Preview what would change
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

# 3. Run it for real
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

# 4. Repeat for the www version if your old URLs used it
wp search-replace 'http://www.example.com' 'https://www.example.com' --skip-columns=guid

# 5. Flush caches
wp cache flush

لماذا نتجاوز عمود guid؟ لأن ووردبريس يستخدمه معرّفًا دائمًا للخلاصات وليس رابطًا، وتغييره قد يجعل قارئات الخلاصات تعرض المقالات القديمة كأنها جديدة. وإذا لم تستطع استخدام WP-CLI فإضافة بحث واستبدال تدعم البيانات المتسلسلة تؤدي المهمة نفسها. خذ نسخة احتياطية أولًا في الحالتين.

بعض أدوات بناء الصفحات تحتفظ بنسخة خاصة من الروابط في ملفات CSS مولّدة. بعد الاستبدال استخدم أدوات الأداة نفسها لإعادة توليد CSS أو استبدال الروابط، ثم امسح ذاكرتها المؤقتة.

أصلح الروابط المكتوبة في ملفات القالب والإضافات

إذا ظل grep يجد http:// بعد استبدال قاعدة البيانات، فالرابط موجود في ملف. غيّر http:// إلى https:// في القالب الفرعي. ولروابط نطاقك يمكنك أيضًا استخدام مسار يبدأ من الجذر مثل /wp-content/uploads/logo.png. وإذا كان الرابط يأتي من إضافة لا تستطيع تعديلها فحدّثها أو استبدلها.

امسح كل ذاكرة مؤقتة

قد تبدو الصفحة التي أصلحتها معطوبة لأن نسخة قديمة منها مخزنة. امسح ذاكرة إضافة التخزين المؤقت (مثل LiteSpeed Cache) وذاكرة أي CDN، واختبر في نافذة تصفح خاصة.

الخطوة 4: حوّل كل زيارات HTTP إلى HTTPS

إصلاح الروابط يزيل التحذير، لكن الزوار ومحركات البحث قد يصلون إلى العنوان القديم http://. وجّههم إلى HTTPS بتحويل دائم. على Apache أو LiteSpeed أضف هذا قرب بداية ملف .htaccess:

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

على Nginx استخدم كتلة server منفصلة على المنفذ 80 تحتوي return 301 https://$host$request_uri;. كما توفر كثير من لوحات التحكم خيار "Force HTTPS" الذي يؤدي الغرض نفسه. استخدم طريقة واحدة فقط لتجنب حلقات التحويل.

خلف Proxy أو CDN؟ انتبه لحلقات التحويل

إذا كان HTTPS ينتهي عند Proxy أو CDN يتصل بخادمك عبر HTTP، فقد يظن ووردبريس أن كل طلب HTTP ويستمر في التحويل. الحل هو الاعتماد على ترويسة البروتوكول التي يمررها الـ Proxy:

/* In wp-config.php, above the line "That's all, stop editing!" */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

افعل ذلك فقط إذا كان خادمك فعلًا خلف Proxy يضبط هذه الترويسة.

شبكة أمان مؤقتة: upgrade-insecure-requests

يمكن لتوجيه في سياسة أمان المحتوى (CSP) أن يطلب من المتصفحات جلب كل مورد http:// عبر HTTPS بدلًا منه:

Header always set Content-Security-Policy "upgrade-insecure-requests"

يُخفي هذا العَرَض أثناء التنظيف، وهو مفيد في المواقع الكبيرة التي تحمل سنوات من المحتوى القديم. لكنه لا يفيد إذا لم يكن للمورد نسخة HTTPS، ولا يصلح الروابط التي تراها محركات البحث والمواقع الأخرى. تعامل معه كحل مؤقت لا كإصلاح نهائي.

عندما لا تكون المشكلة محتوى مختلطًا

إذا لم تظهر رسائل محتوى مختلط في وحدة التحكم وما زال المتصفح يحذّر، فافحص الشهادة نفسها:

# Who issued the certificate, which names it covers, and when it expires
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -ext subjectAltName -dates

  • عدم تطابق الاسم: الشهادة تغطي example.com ولا تغطي www.example.com أو العكس. أعد إصدارها للاسمين.

  • منتهية الصلاحية: تاريخ notAfter قد مضى. جدّدها وتأكد أن التجديد التلقائي يعمل.

  • سلسلة غير مكتملة: يرسل الخادم الشهادة دون الشهادة الوسيطة، فترفضها بعض المتصفحات ومعظم الهواتف. ثبّت السلسلة الكاملة التي توفرها جهة الإصدار.

  • شهادة موقّعة ذاتيًا: مناسبة للاختبار فقط، ولا تثق بها المتصفحات العامة أبدًا.

قائمة تحقق سريعة

  1. لا تظهر تحذيرات محتوى مختلط في وحدة التحكم على الصفحة الرئيسية ومقال وصفحة منتج وصفحة الدفع.

  2. رابطا ووردبريس يستخدمان https://.

  3. لم يبقَ أي رابط http:// لنطاقك في HTML أو CSS.

  4. العنوان http:// يتحول إلى https:// بتحويل 301، دون حلقة تحويل.

  5. الشهادة تغطي كل الأسماء التي تستخدمها وليست قريبة من الانتهاء.

شغّل موقعك مع SSL على IM HOST

تتضمن استضافة ووردبريس من IM HOST شهادة SSL مجانية، وتخزين NVMe، وLiteSpeed Cache، ونسخًا احتياطية يومية مجانية طوال مدة الاشتراك، فتستطيع الاعتماد على نقطة استعادة قبل أي عملية بحث واستبدال. وإذا احتجت إلى نوع آخر من الشهادات فاطّلع على شهادات SSL. ويستطيع مهندسونا المتاحون على مدار الساعة فحص شهادتك ومساعدتك في تتبع ما تبقى من روابط غير آمنة.

المزيد من مدونتنا

اكتشف المزيد من الأدلة العملية ورؤى الخدمات من فريق IM Host.

عرض كل المقالات