แก้ปัญหา Mixed Content เมื่อเว็บ HTTPS ยังโหลดทรัพยากรผ่าน HTTP

Mixed Content คืออะไร

เมื่อคุณติดตั้ง SSL Certificate และเปิดเว็บด้วย HTTPS แล้ว เบราว์เซอร์คาดหวังว่าทรัพยากร ทุกชิ้น ในหน้า ไม่ว่าจะเป็นรูปภาพ, JavaScript, CSS, ฟอนต์, หรือ iframe จะต้องโหลดผ่าน HTTPS เช่นกัน

Mixed Content (หรือ Mixed Content Warning) คือสถานการณ์ที่หน้าเว็บโหลดผ่าน HTTPS แต่ยังมีทรัพยากรบางส่วนที่อ้างอิง URL เริ่มต้นด้วย http:// แทนที่จะเป็น https:// ทำให้เบราว์เซอร์แสดงคำเตือนหรือบล็อกทรัพยากรเหล่านั้นทันที

ปัญหานี้พบบ่อยมากในเว็บที่เพิ่งย้ายจาก HTTP เป็น HTTPS เพราะ URL ในฐานข้อมูล, โค้ด HTML, และไฟล์ต่างๆ ยังคงอ้างอิง http:// ตามเดิม

ประเภทของ Mixed Content

เบราว์เซอร์แบ่ง Mixed Content ออกเป็น 2 ประเภทหลัก ซึ่งมีระดับความเสี่ยงและการจัดการที่แตกต่างกัน:

ประเภท	ทรัพยากรที่เกี่ยวข้อง	พฤติกรรมของเบราว์เซอร์	ความเสี่ยง
Active Mixed Content	JavaScript (.js), CSS (.css), iframe, XHR/Fetch	บล็อกทันที (ไม่โหลดเลย)	สูงมาก
Passive Mixed Content	รูปภาพ (.jpg, .png, .gif), เสียง, วิดีโอ	โหลดได้แต่แสดง Warning	ต่ำกว่า

Active Mixed Content — อันตรายสูง

JavaScript หรือ CSS ที่โหลดผ่าน HTTP อาจถูกผู้โจมตีดักจับและแก้ไขเนื้อหาระหว่างทาง (Man-in-the-Middle Attack) ก่อนที่เบราว์เซอร์จะได้รับ ทำให้ผู้ใช้อาจได้รับมัลแวร์หรือถูกขโมยข้อมูลโดยไม่รู้ตัว Chrome, Firefox และ Safari จึงบล็อก Active Mixed Content ทันทีตั้งแต่ปี 2020 เป็นต้นมา

Passive Mixed Content — เสี่ยงน้อยกว่า แต่ยังมีผล

รูปภาพที่โหลดผ่าน HTTP ไม่สามารถแก้ไขเนื้อหาหน้าเว็บได้โดยตรง แต่ผู้โจมตียังสามารถแทรกรูปภาพปลอม หรือตรวจสอบว่าผู้ใช้เข้าชมหน้าใดบ้างได้ เบราว์เซอร์จึงยังโหลดรูปภาพ HTTP ได้แต่จะแสดงไอคอนเตือนใน Address Bar แทนไอคอนกุญแจสีเขียว

ปัญหาที่เกิดจาก Mixed Content

• ไอคอนกุญแจหายหรือแสดงคำว่า "Not Secure" — ผู้ใช้เห็นว่าเว็บไม่ปลอดภัยแม้จะมี SSL อยู่แล้ว
• สคริปต์และสไตล์ถูกบล็อก — หน้าเว็บอาจแสดงผลผิดพลาด ปุ่มไม่ทำงาน หรือ layout พัง
• รูปภาพไม่โหลด (บางกรณี) — เบราว์เซอร์รุ่นใหม่บางตัวอัปเกรด Passive Mixed Content เป็น HTTPS อัตโนมัติ แต่ถ้าไม่มีไฟล์ HTTPS จริงก็จะโหลดไม่ได้
• ผลกระทบต่อ SEO — Core Web Vitals อาจแย่ลง หน้าที่แสดงคำเตือน Mixed Content อาจได้คะแนน SEO ต่ำกว่า
• Console Error ทำให้ debug ยาก — ปัญหาที่ซ่อนอยู่ในไฟล์ 3rd-party อาจหาได้ยากถ้าไม่รู้ว่ามาจาก Mixed Content

วิธีตรวจหา Mixed Content

ก่อนแก้ ต้องรู้ก่อนว่า Mixed Content อยู่ที่ไหน มีหลายวิธีในการตรวจ:

1. Chrome DevTools — วิธีที่แม่นยำที่สุด

1. เปิดหน้าเว็บที่ต้องการตรวจใน Chrome
2. กด F12 หรือ Ctrl+Shift+I เพื่อเปิด DevTools
3. ไปที่แท็บ Console — จะเห็นข้อความสีแดง/เหลืองที่ขึ้นต้นด้วย "Mixed Content"
4. ไปที่แท็บ Network แล้วโหลดหน้าใหม่ — กรอง URL ที่ขึ้นต้นด้วย http://

2. เครื่องมือออนไลน์

• Why No Padlock (whynopadlock.com) — ตรวจ Mixed Content แบบ Public URL ได้ฟรี
• JitBit SSL Checker — ตรวจ URL ทั้งเว็บไซต์แบบ Crawl
• SSL Shopper SSL Checker — เหมาะสำหรับตรวจการติดตั้ง SSL Certificate

3. Search URL ใน Source Code

สำหรับ CMS อย่าง WordPress ให้ค้นหา http:// ใน Source Code ของหน้า (กด Ctrl+U ใน Chrome) เพื่อหา URL ที่ยังไม่ได้อัปเกรด

แก้ Mixed Content ทั่วไป

วิธีแก้ขึ้นอยู่กับแหล่งที่มาของ Mixed Content เรามาแยกกรณีกัน:

กรณีที่ 1: URL ที่คุณควบคุมได้ (ไฟล์ของเว็บตัวเอง)

เปลี่ยน URL ในโค้ด HTML, CSS หรือ JS จาก http:// เป็น https:// หรือใช้ Protocol-relative URL ที่ไม่ระบุ Protocol:

<!-- แบบเก่า (ผิด) -->
<img src="http://example.com/img/photo.jpg">
<script src="http://example.com/js/main.js"></script>

<!-- แบบถูกต้อง -->
<img src="https://example.com/img/photo.jpg">
<script src="https://example.com/js/main.js"></script>

<!-- หรือ Protocol-relative (ใช้ได้ทั้ง http และ https) -->
<img src="//example.com/img/photo.jpg">

กรณีที่ 2: ทรัพยากรจาก External Service

หาก External Service รองรับ HTTPS อยู่แล้ว ให้เปลี่ยน URL เป็น https:// ตรงๆ หากไม่รองรับ HTTPS ให้ดาวน์โหลดไฟล์มาโฮสต์บนเซิร์ฟเวอร์ของตัวเองแทน

กรณีที่ 3: URL ในฐานข้อมูล

สำหรับ CMS ที่เก็บ URL ในฐานข้อมูล (เช่น WordPress) ต้องอัปเดตข้อมูลในฐานข้อมูลด้วย ไม่ใช่แค่แก้ไฟล์ PHP — ดูรายละเอียดในหัวข้อ WordPress ด้านล่าง

แก้ Mixed Content บน WordPress

WordPress เก็บ URL ในฐานข้อมูล MySQL ทำให้การย้ายจาก HTTP เป็น HTTPS ต้องอัปเดตฐานข้อมูลด้วย มีหลายวิธี:

วิธีที่ 1: Plugin Really Simple SSL (แนะนำสำหรับมือใหม่)

1. ติดตั้ง Plugin Really Simple SSL จาก WordPress.org
2. Activate แล้วกด "Go ahead, activate SSL!"
3. Plugin จะ Redirect HTTP → HTTPS และเพิ่ม Header ที่จำเป็นอัตโนมัติ
4. ตรวจสอบผลใน Console อีกครั้ง

วิธีที่ 2: Plugin Better Search Replace (แก้ฐานข้อมูลถาวร)

1. ติดตั้ง Plugin Better Search Replace
2. ไปที่ Tools → Better Search Replace
3. ช่อง "Search for": http://yourdomain.com
4. ช่อง "Replace with": https://yourdomain.com
5. เลือก Table ทั้งหมด หรืออย่างน้อย wp_posts, wp_postmeta, wp_options
6. กด "Run Search/Replace" — แนะนำให้ทำ Dry Run ก่อนเพื่อดูจำนวน Record ที่จะเปลี่ยน

วิธีที่ 3: WP-CLI (สำหรับผู้ใช้ที่มี SSH Access)

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid

ตั้งค่า wp-config.php เพิ่มเติม

เพิ่มบรรทัดเหล่านี้ใน wp-config.php เพื่อบังคับ HTTPS ในทุกส่วน:

define('FORCE_SSL_ADMIN', true);
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');

แก้ Mixed Content บน DirectAdmin Hosting

สำหรับผู้ใช้ AsiaGB Hosting ที่ใช้ DirectAdmin เป็น Control Panel สามารถจัดการ SSL และแก้ Mixed Content ได้ผ่าน Panel โดยตรง:

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

ใช้ CSP Header เป็นตาข่ายนิรภัย

แม้จะแก้ URL ในโค้ดและฐานข้อมูลแล้ว ยังอาจมี URL ที่ตกหล่นอยู่ การใช้ HTTP Header Content-Security-Policy: upgrade-insecure-requests เป็นตาข่ายนิรภัยที่บอกให้เบราว์เซอร์อัปเกรด HTTP เป็น HTTPS อัตโนมัติสำหรับทรัพยากรทุกชิ้นในหน้า

เพิ่มใน .htaccess:

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

ตัวเลือกเพิ่มเติม: HSTS Header

เมื่อแก้ Mixed Content ครบแล้ว ควรเพิ่ม HSTS (HTTP Strict Transport Security) เพื่อบังคับให้เบราว์เซอร์ใช้ HTTPS เสมอ ลด Redirect Overhead และป้องกัน Protocol Downgrade Attack:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

ป้องกัน Mixed Content ในอนาคต

เมื่อแก้ปัญหาเรียบร้อยแล้ว ควรมีมาตรการป้องกันไม่ให้เกิดซ้ำ:

• ตั้ง Default URL เป็น HTTPS ในระบบ — ทั้ง WordPress Site URL, Database URL และ Config ต้องเป็น https:// เสมอ
• ใช้ Protocol-relative URL เมื่อ Hardcode — เช่น //cdn.example.com/file.js แทน http://cdn.example.com/file.js
• ตรวจสอบ Plugin และ Theme ใหม่ทุกตัว — ก่อน Activate ให้ดู Source Code ว่ามี HTTP URL ฝังอยู่ไหม
• ใช้ Content-Security-Policy report-uri — รับ Report ทุกครั้งที่มี Mixed Content เกิดขึ้น
• Automation: CI/CD ตรวจ Mixed Content — หาก Deploy บ่อยให้เพิ่มขั้นตอนตรวจ Mixed Content ใน Pipeline
• รันทดสอบหลัง Deploy ทุกครั้ง — ใช้ Script ตรวจ Console Error หรือ Tool อย่าง Puppeteer เพื่อ Automate การตรวจ

คำถามที่พบบ่อย (FAQ)