Defaults.Exposed › การแก้ไข › HTTPS & การ redirect ไปยังการเชื่อมต่อที่ปลอดภัย

วิธีแก้ไข HTTPS & การ redirect ไปยังการเชื่อมต่อที่ปลอดภัย

HTTPS คือ padlock ในแถบเบราว์เซอร์ — มันเข้ารหัสทุกอย่างที่เดินทางระหว่างเว็บไซต์ของคุณและลูกค้าของคุณเพื่อให้ไม่สามารถอ่านหรือถูกดัดแปลงระหว่างทาง การ redirect ไปยังการเชื่อมต่อที่ปลอดภัยทำให้แน่ใจว่าผู้เข้าชมลงบนเวอร์ชันที่เข้ารหัสนั้นอัตโนมัติ แม้แต่เมื่อพวกมันพิมพ์ที่อยู่ของคุณโดยไม่มี 'https://' ทั้งสองนี้เป็นสิ่งพื้นฐานที่สุดที่เว็บไซต์จำเป็นต้องถือว่าปลอดภัยเลย

สรุปสำหรับธุรกิจของคุณ: หากไม่มี HTTPS รหัสผ่าน หมายเลขบัตร และข้อความทุกอย่างที่ลูกค้าส่งถึงคุณข้ามอินเทอร์เน็ตในรูปแบบข้อความที่อ่านได้ และ Chrome, Edge, Safari และ Firefox ทั้งหมดประทับ 'ไม่ปลอดภัย' บนเว็บไซต์ของคุณสำหรับผู้เข้าชมทุกคนก่อนที่พวกมันจะอ่านคำใดๆ หากไม่มีการ redirect แม้แต่เว็บไซต์ที่มีใบรับรองก็ยังปล่อยให้การเข้าชมครั้งแรกไม่ได้รับการปกป้อง ทั้งสองทำให้คุณสูญเสียความไว้วางใจ ยอดขาย และ search ranking — และทั้งสองฟรีในการแก้ไขในไม่กี่นาที

สิ่งนี้อาจทำให้คุณเสียค่าใช้จ่าย

• ผู้เข้าชมครั้งแรกเห็นคำเตือน 'ไม่ปลอดภัย' ขนาดใหญ่ในทันทีที่หน้าของคุณโหลด ส่วนใหญ่สมมติว่าเว็บไซต์เป็นของปลอม เสียหาย หรือไม่ปลอดภัยและออกไปหาคู่แข่ง — และคุณไม่รู้ด้วยซ้ำว่าการขายนั้นสูญหายไป
• ลูกค้าป้อนรายละเอียดบัตรหรือ log เข้าบนการเชื่อมต่อที่ไม่ได้เข้ารหัสจากร้านกาแฟ โรงแรม หรือสนามบิน ใครบางคนบน WiFi เดียวกันอ่านมันในข้อความธรรมดา และค่าใช้จ่ายที่ฉ้อโกงที่ตามมาถูกโทษที่คุณ
• การจัดซื้อหรือทีมความปลอดภัยของลูกค้าขนาดใหญ่รันการสแกนอย่างรวดเร็วก่อนเซ็นสัญญา เห็นว่าไม่มี HTTPS หรือการ redirect ที่หายไป และ park สัญญาจนกว่าคุณจะพิสูจน์ว่ามันได้รับการแก้ไข
• Google จัด ranking คุณต่ำกว่าคู่แข่งที่ให้บริการ HTTPS ดังนั้นคุณเสีย search traffic อย่างเงียบๆ เป็นเวลาหลายปีโดยไม่เคยเชื่อมโยงมันกับช่องว่างนี้
• ผู้กำกับดูแลหรือผู้ให้บริการการชำระเงินของคุณถือว่าการส่งข้อมูลส่วนตัวหรือบัตรที่ไม่ได้เข้ารหัสเป็นความล้มเหลวที่ต้องรายงาน เปลี่ยนการแก้ไขฟรีห้านาทีให้กลายเป็นปัญหา compliance

เหตุใดจึงสำคัญ HTTPS คือพื้น ไม่ใช่เพดานของความปลอดภัย web — มันคือสิ่งที่ทำให้ padlock ปรากฏขึ้นและสิ่งที่หยุดทุกอย่างที่ลูกค้าของคุณส่งจากการถูกอ่านหรือแก้ไขระหว่างทาง การ redirect ที่บังคับใช้ความปลอดภัยปิดช่องว่างที่ใบรับรองเพียงอย่างเดียวปล่อยไว้: ผู้คนแทบไม่พิมพ์ 'https://' ดังนั้นหากไม่มีการ redirect คำขอแรกของพวกมันเดินทางโดยไม่ได้รับการปกป้องก่อนที่เวอร์ชันที่ปลอดภัยจะโหลด เว็บไซต์ที่ขาดสิ่งเหล่านี้ดูไม่ปลอดภัยต่อผู้เข้าชม จัด ranking ต่ำกว่าในการค้นหา และเปิดเผยข้อมูลลูกค้าจริง — นั่นเป็นเหตุผลที่นี่เป็นความล้มเหลวเดียวที่มีน้ำหนักสูงสุดที่เราให้คะแนน

วิธีแก้ไข ทีละขั้นตอน

1. รับใบรับรอง. รับใบรับรอง TLS ฟรี — host และ CDN ส่วนใหญ่ออก Let's Encrypt อัตโนมัติ
2. ติดตั้งและ bind มัน. ใช้ใบรับรองเพื่อให้เว็บไซต์ของคุณให้บริการบน port 443
3. Redirect HTTP เป็น HTTPS. บังคับคำขอ plain-HTTP ทั้งหมดไปยังเวอร์ชัน HTTPS ด้วย 301 redirect
4. แก้ไข mixed content. อัปเดตรูปภาพ script หรือลิงก์ใดๆ ที่ยังโหลดผ่าน HTTP เพื่อให้ padlock ไม่เสียหาย
5. ยืนยันว่ามันทำงาน. ตรวจสอบใหม่เพื่อยืนยันว่าเว็บไซต์ให้บริการ HTTPS ที่ถูกต้องโดยไม่มีข้อผิดพลาด

HTTPS ในคำพูดง่ายๆ

HTTPS คือเวอร์ชันที่ปลอดภัยและเข้ารหัสของเว็บไซต์ของคุณ — อันที่แสดง padlock ในแถบที่อยู่ เมื่อผู้เข้าชมอยู่บน HTTPS ทุกอย่างที่ผ่านระหว่างเบราว์เซอร์ของพวกมันและเว็บไซต์ของคุณ (หน้าที่พวกมันเห็น แบบฟอร์มที่พวกมันกรอก รหัสผ่านของพวกมัน รายละเอียดบัตรของพวกมัน) ถูกเข้ารหัสเพื่อให้ไม่มีใครตรงกลางสามารถอ่านหรือเปลี่ยนแปลงมัน เวอร์ชันธรรมดา HTTP ส่งทั้งหมดนั้นเป็นข้อความที่อ่านได้ที่ใครก็ตามบนเครือข่ายเดียวกันสามารถดักจับ

มีสองส่วนในการทำสิ่งนี้ให้ถูกต้อง และเราตรวจสอบทั้งสอง:

• HTTPS มีอยู่เลยไหม? เว็บไซต์ของคุณมีใบรับรองความปลอดภัยที่ทำงานได้เพื่อให้เวอร์ชันที่ปลอดภัยและมี padlock มีอยู่? นี่เป็นสิ่งที่จริงจังกว่าของสอง — หากไม่มีมันไม่มีการเข้ารหัสเลย
• เว็บไซต์ของคุณบังคับผู้เข้าชมไปที่มันไหม? เกือบไม่มีใครพิมพ์ “https://” ด้วยมือ ถ้าใครพิมพ์แค่ชื่อโดเมนของคุณ เบราว์เซอร์ของมันลอง HTTP ธรรมดาก่อน forced-secure redirect เด้งคำขอนั้นอัตโนมัติไปยังเวอร์ชันที่เข้ารหัส หากไม่มีมัน ช่วงแรกของทุกการเยี่ยมชมไม่ได้รับการปกป้องแม้ว่าคุณจะมีใบรับรอง

คุณต้องการทั้งสอง ใบรับรองที่ไม่มีการ redirect คือประตูด้านหน้าที่ล็อคซึ่งผู้เข้าชมสามารถเดินรอบได้

ความเสี่ยงทางธุรกิจ

นี่คือสัญญาณพื้นฐานที่สุดว่าเว็บไซต์ปลอดภัยหรือไม่ — และที่สำคัญมันเป็นสิ่งที่ลูกค้าของคุณสามารถเห็นด้วยตัวเอง เบราว์เซอร์สมัยใหม่ทุกตัว (Chrome, Edge, Safari, Firefox) ระบุเว็บไซต์ที่ไม่มี HTTPS ว่า “ไม่ปลอดภัย” ในแถบที่อยู่ และแสดงคำเตือนถ้าใครพยายามพิมพ์ลงในแบบฟอร์ม ผู้เข้าชมของคุณไม่จำเป็นต้องรู้ว่าใบรับรองคืออะไรเพื่อตอบสนองต่อคำนั้น

นอกเหนือจากคำเตือนที่มองเห็นได้ สิ่งนี้ส่งผลต่อสามสิ่งที่เจ้าของให้ความสำคัญโดยตรง: ความไว้วางใจ (ผู้คนละทิ้งเว็บไซต์ที่ดูไม่ปลอดภัย), search ranking (Google ใช้ HTTPS เป็นสัญญาณ ranking มาหลายปีและชอบเว็บไซต์ที่ปลอดภัย) และ การเปิดเผยจริง (ข้อมูลที่ส่งผ่าน HTTP ธรรมดาสามารถถูกอ่านโดยคนอื่นบนเครือข่ายเดียวกันได้จริงๆ) มันยังเป็นชนิดของสิ่งที่ทีมความปลอดภัยของลูกค้าขนาดใหญ่ตรวจสอบในไม่กี่วินาทีระหว่าง due diligence — และการขาดมันสามารถหยุดดีล

สิ่งนี้อาจทำให้คุณสูญเสียอะไร

• การ bounce แบบเงียบ ผู้มีโอกาสเป็นลูกค้าคลิกผ่านจากผลการค้นหาหรือโฆษณา และหน้าโหลดพร้อมป้าย “ไม่ปลอดภัย” สีเทา — หรือแย่กว่านั้น คำเตือนแบบเต็มหน้าจอ พวกมันไม่ส่งอีเมลถามว่าทำไม; พวกมันแค่ปิด tab และคลิกผลลัพธ์ถัดไป คุณจ่ายเงินสำหรับการเยี่ยมชมนั้นและสูญเสียมันก่อนที่พวกมันจะอ่านคำใดๆ และไม่มีอะไรใน analytics ของคุณบอกว่าทำไม

• การ login หรือการชำระเงินที่ถูกดักจับ ลูกค้า sign in หรือชำระเงินในขณะที่อยู่บน WiFi สาธารณะที่โรงแรมหรือร้านกาแฟ เพราะการเชื่อมต่อไม่ได้เข้ารหัส ใครบางคนใกล้ๆ จับรหัสผ่านหรือหมายเลขบัตรของมันในข้อความธรรมดา การฉ้อโกงที่ตามมาถูกรายงานว่าเป็นการละเมิดของคุณ และคุณเป็นคนที่รับสายที่โกรธและ chargebacks

• ดีลที่หยุดชะงัก ผู้มีโอกาสเป็นลูกค้าขนาดใหญ่พร้อมเซ็น แต่กระบวนการจัดซื้อของพวกมันรวมถึงการตรวจสอบความปลอดภัยอย่างรวดเร็วของเว็บไซต์ของคุณ มันกลับมาพร้อมทำเครื่องหมายว่าไม่มี HTTPS หรือการ redirect ที่หายไป ทันทีคุณกำลังอธิบายช่องว่างความปลอดภัยพื้นฐานแทนที่จะปิด — และสัญญารอ หรือค่อยๆ ไปหาคู่แข่งที่ผ่านการตรวจสอบ

• การรั่วไหลของ ranking ช้า ธุรกิจสองแห่งเสนอสิ่งเดียวกัน; หนึ่งให้บริการ HTTPS ที่ปลอดภัยและอีกหนึ่งไม่ทำ search engine ดัน ranking อันที่ปลอดภัยสูงกว่า ในช่วงหลายเดือนคุณสูญเสีย traffic ฟรีที่ไหลทีละน้อยอย่างต่อเนื่องและไม่เคยเชื่อมโยงมันกับ setting เดียวนี้

• เนื้อหาที่ inject ที่คุณไม่เคยเขียน บนการเชื่อมต่อที่ไม่ได้เข้ารหัส ใครก็ตามตรงกลาง — เครือข่ายสาธารณะที่น่าสงสัย router ที่ถูก compromise — สามารถ insert pop-up ปลอม ข้อเสนอหลอกลวง หรือ malware เข้าไปในหน้าของคุณขณะที่ผู้เข้าชมโหลด สำหรับผู้เข้าชมนั้น มันดูเหมือนเว็บไซต์ของคุณทำมัน

มันคืออะไรจริงๆ

เมื่อเบราว์เซอร์เชื่อมต่อกับเว็บไซต์ผ่าน HTTPS สองสิ่งเกิดขึ้น ประการแรก เว็บไซต์นำเสนอใบรับรอง — credential ที่ออกโดยหน่วยงานที่ได้รับความไว้วางใจที่พิสูจน์ว่าเว็บไซต์เป็นสิ่งที่อ้างว่าเป็น ประการที่สอง เบราว์เซอร์และเซิร์ฟเวอร์ตกลงกันบน encryption key และใช้มันในการเข้ารหัสทุกอย่างที่พวกมันแลกเปลี่ยน การตรวจสอบแรกของเรา HTTPS มีอยู่ เพียงแค่ถาม: เราสามารถเชื่อมต่อ TLS ที่ปลอดภัยกับเว็บไซต์ของคุณบน port ที่ปลอดภัยมาตรฐาน (443) และได้รับใบรับรองที่ถูกต้องกลับมาได้ไหม? ถ้าใช่ padlock สามารถปรากฏขึ้นและการเข้ารหัสเปิดอยู่ ถ้าไม่ ไม่มีเวอร์ชันที่ปลอดภัยของเว็บไซต์ของคุณเลย — และนั่นคือความล้มเหลวที่มีน้ำหนักหนักสุดเดียวที่เราให้คะแนน

การตรวจสอบที่สอง forced-secure redirect ครอบคลุมช่องว่างที่ใบรับรองเพียงอย่างเดียวปล่อยไว้ ผู้คนพิมพ์ “yourbusiness.com” ไม่ใช่ “https://yourbusiness.com” คำขอเปล่านั้นไปยังเวอร์ชัน HTTP ธรรมดาก่อน redirect คือคำสั่งหนึ่งบรรทัดที่บอกว่า “ส่งใครก็ตามที่มาถึงในเวอร์ชันที่ไม่ปลอดภัยตรงไปยังอันที่ปลอดภัย” การตรวจสอบของเราถาม: เมื่อเราขอที่อยู่ HTTP ธรรมดาของคุณ เว็บไซต์ของคุณเด้งเราไปยัง HTTPS ไหม? ถ้าทำ ผู้เข้าชมทุกคนจบลงด้วยการได้รับการปกป้องไม่ว่าพวกมันพิมพ์ที่อยู่ของคุณอย่างไร ถ้าไม่ การ hop ที่ไม่ได้รับการปกป้องแรกนั้นพา cookies, ข้อมูลแบบฟอร์ม ในรูปแบบที่อ่านได้

“ดี” ดูเหมือน: ใบรับรองที่ถูกต้องและได้รับความไว้วางใจเพื่อให้ padlock แสดงบนทุกหน้า และ ทุกคำขอ HTTP ธรรมดาถูก redirect อัตโนมัติไปยังเวอร์ชัน HTTPS (โดยเหมาะสมด้วย “301” redirect ถาวร ซึ่งยังผ่าน search ranking ของคุณอย่างสะอาดไปยังที่อยู่ที่ปลอดภัย)

วิธีแก้ไข (ฟรี ~15 นาที)

ส่งส่วนนี้ให้ผู้ดูแลระบบ IT ของคุณหรือ support ของ hosting provider — การแก้ไขฟรี ทั้งสองส่วนนี้ไม่มีค่าใช้จ่าย: ใบรับรองที่เชื่อถือได้ฟรีและต่ออายุตัวเอง และการเปิดการ redirect เป็น setting เดียวบนแพลตฟอร์มส่วนใหญ่ ไม่มีผลิตภัณฑ์แบบเสียเงินที่จำเป็นในการผ่านสิ่งนี้

มีสองสิ่งที่ต้องเปิด บน hosting สมัยใหม่ส่วนใหญ่ การทำอันแรกมักทำให้อันที่สองเป็น toggle คลิกเดียว

1. รับใบรับรองเพื่อให้ HTTPS ทำงาน (padlock)

• Cloudflare: ถ้าเว็บไซต์ของคุณอยู่เบื้องหลัง Cloudflare SSL ถูกจัดการให้คุณ ตั้ง SSL/TLS mode เป็น “Full” (หรือ “Full (strict)” ถ้าเซิร์ฟเวอร์ origin ของคุณมีใบรับรองด้วย)
• ผู้สร้างเว็บไซต์และ managed hosting (Squarespace, Wix, Shopify, Webflow, GoDaddy Website Builder, most Microsoft 365 / Google Workspace web hosting): HTTPS ถูกให้บริการอัตโนมัติ แค่ตรวจสอบให้แน่ใจว่าเปิดใช้งานในการตั้งค่า site/domain ของคุณ — โดยปกติไม่มีอะไรต้องติดตั้ง
• cPanel hosting: เปิด SSL/TLS Status และรัน AutoSSL ซึ่งออกใบรับรอง Let’s Encrypt ฟรี
• เซิร์ฟเวอร์ของตัวเอง (VPS): ติดตั้ง Let’s Encrypt กับ Certbot — sudo certbot --nginx -d yourdomain.com (หรือ --apache) มันดึงและติดตั้งใบรับรองฟรีและตั้งค่า auto-renewal
• อื่นๆ: ติดต่อ support ของ hosting provider ของคุณและขอให้พวกมัน “enable a free SSL certificate for my domain” เกือบทั้งหมดเสนอสิ่งนี้โดยไม่มีค่าใช้จ่าย

2. บังคับผู้เข้าชมทุกคนไปยัง HTTPS (การ redirect)

• Cloudflare: SSL/TLS → Edge Certificates → เปิด “Always Use HTTPS” นั่นคือทั้งงาน
• ผู้สร้างเว็บไซต์ (Squarespace, Wix, Shopify ฯลฯ): มองหา toggle “Force HTTPS” หรือ “Secure (HTTPS)” ในการตั้งค่าเว็บไซต์ของคุณและเปิดมัน
• Nginx: เพิ่ม server block บน port 80 ที่ return permanent redirect — return 301 https://$host$request_uri;
• Apache (.htaccess): เปิด rewriting และ redirect คำขอ non-HTTPS ใดๆ — RewriteEngine On, RewriteCond %{HTTPS} off, RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
• IIS (Windows hosting): ติดตั้ง URL Rewrite module และเพิ่กฎ redirect “HTTP to HTTPS”

หลังจากทั้งสองเปิดแล้ว ทดสอบมัน: พิมพ์ที่อยู่ของคุณด้วย http:// ธรรมดาข้างหน้าและยืนยันว่าเบราว์เซอร์กระโดดไปยังเวอร์ชัน https:// ที่มี padlock อัตโนมัติ และ padlock แสดงบนหน้าหลักของคุณ

ข้อผิดพลาดทั่วไป

• ใบรับรองถูกติดตั้งแต่ไม่มีการ redirect ช่องว่างที่พบบ่อยที่สุด คุณเห็น padlock เมื่อเยี่ยมชมเว็บไซต์ของตัวเอง (เพราะเบราว์เซอร์ของคุณจำ HTTPS) ดังนั้นคุณสมมติว่าเสร็จแล้ว — แต่ผู้เข้าชมใหม่ที่พิมพ์โดเมนเปล่ายังคงลงบน HTTP ก่อน ทดสอบเวอร์ชัน http:// ธรรมดาอย่างชัดเจนเสมอ
• Mixed content หน้าของคุณโหลดผ่าน HTTPS แต่ดึงรูปภาพ script หรือ font จากที่อยู่ http:// เก่า เบราว์เซอร์บล็อกมันหรือ downgrade padlock เป็นคำเตือน อัปเดตการอ้างอิงเหล่านั้นเป็น https:// (หรือเป็น relative links) แพลตฟอร์มส่วนใหญ่มีรายงาน “mixed content” หรือ “insecure content” ที่หามัน
• Temporary (302) redirect แทน permanent (301) 302 ทำงานสำหรับผู้เข้าชมแต่บอก search engine ว่าการย้ายเป็นชั่วคราว ดังนั้น ranking value ไม่ถ่ายโอนอย่างสะอาดไปยังที่อยู่ที่ปลอดภัยของคุณ ใช้ 301 ถาวร
• Redirect เฉพาะโดเมนเปล่า ไม่ใช่ “www” (หรือในทางกลับกัน) ตรวจสอบให้แน่ใจว่าทั้ง yourdomain.com และ www.yourdomain.com จบลงบน HTTPS ไม่เช่นนั้นเส้นทางหนึ่งยังคงเปิดรับ
• ปล่อยให้ใบรับรองหมดอายุ ใบรับรองที่หมดอายุแสดงข้อผิดพลาดเบราว์เซอร์แบบเต็มหน้าจอที่หยุดผู้เข้าชมทันที ใบรับรอง Let’s Encrypt ฟรีต่ออายุอัตโนมัติ; ถ้าคุณซื้ออันหนึ่งด้วยมือ ตั้ง calendar reminder ล่วงหน้าของวันหมดอายุ

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