คู่มือติดตั้ง WooCommerce บน DigitalOcean Droplet 2026

A practical DigitalOcean Droplet setup guide for running WooCommerce stores, covering server sizing, checkout SSL, cart-safe caching, and automated backups.

WooCommerce เปลี่ยน WordPress ธรรมดาให้กลายเป็นระบบร้านค้าออนไลน์ที่ต้องรับมือกับตะกร้าสินค้า การชำระเงิน และแคตตาล็อกสินค้าที่เปลี่ยนแปลงตลอดเวลา ต่างจากบล็อกหรือเว็บองค์กรทั่วไปที่เน้นหน้าเนื้อหาสถิต ร้านค้าออนไลน์มีหน้าไดนามิกอย่างตะกร้าและหน้าชำระเงินที่ต้องแยกจัดการเรื่อง caching และ SSL โดยเฉพาะ บทความนี้ต่อยอดจากการติดตั้ง WordPress พื้นฐานบน DigitalOcean Droplet ไปสู่รายละเอียดเฉพาะของ WooCommerce ตั้งแต่สเปกเซิร์ฟเวอร์ที่เหมาะสม ไปจนถึงความปลอดภัยที่เกี่ยวข้องกับการชำระเงิน

สเปก Droplet ที่แนะนำสำหรับร้านค้าออนไลน์

ร้านค้าออนไลน์ที่รัน WooCommerce บนแกนของ WordPress มีภาระงานต่างจากเว็บไซต์เนื้อหาทั่วไปอย่างชัดเจน เพราะทุกหน้าที่เกี่ยวข้องกับตะกร้าสินค้า การเข้าสู่ระบบ และการชำระเงินต้องประมวลผลแบบไดนามิกเสมอ ไม่สามารถใช้หน้า cache แบบสถิตได้เต็มรูปแบบเหมือนบล็อก ดังนั้นการเลือกสเปก Droplet จึงต้องคำนึงถึงจำนวน PHP-FPM worker ที่รองรับการเรียก AJAX ของตะกร้าสินค้าพร้อมกันหลายคน ไม่ใช่แค่ปริมาณเนื้อหาที่โหลดหน้าเดียวจบ สำหรับร้านเริ่มต้นที่มีสินค้าไม่เกินหลักร้อยรายการและทราฟฟิกยังไม่มาก Droplet ขนาด 2 GiB RAM / 1 vCPU / 50 GB SSD / 2,000 GiB transfer ราคา $12/เดือน พอทดสอบและเปิดร้านขนาดเล็กได้ แต่เมื่อเริ่มมีคำสั่งซื้อจริงและปลั๊กอินเสริม เช่น ระบบคูปอง ระบบสมาชิก หรือตัวเชื่อมต่อคลังสินค้า ควรขยับไปที่ระดับ 4 GiB RAM / 2 vCPU / 80 GB SSD / 4,000 GiB transfer ราคา $24/เดือน ซึ่งเป็นจุดที่คุ้มค่าที่สุดสำหรับร้านขนาดกลางที่มีสินค้าหลักร้อยถึงหลักพันรายการ หากแคตตาล็อกใหญ่มาก มีสินค้าหลายพันตัวแปร (variation) พร้อมทราฟฟิกช่วงโปรโมชั่นสูง ควรพิจารณา 8 GiB RAM / 4 vCPU / 160 GB SSD / 5,000 GiB transfer ราคา $48/เดือน เพื่อให้ MySQL และ PHP-FPM มีทรัพยากรเพียงพอไม่ให้หน้าตะกร้าค้างในช่วงเทศกาลลดราคา อีกจุดที่ควรวางแผนล่วงหน้าคือฐานข้อมูล เพราะตารางคำสั่งซื้อและ order meta ของ WooCommerce โตเร็วกว่าตาราง post ทั่วไปมาก เมื่อร้านเริ่มมีคำสั่งซื้อหลักพันต่อเดือน การแยกฐานข้อมูลออกไปที่ DigitalOcean Managed MySQL ซึ่งเริ่มต้นที่ $15.15/เดือน (1 vCPU / 1 GiB RAM, 10-30 GiB storage) จะช่วยลดภาระบน Droplet หลักและทำให้ backup ฐานข้อมูลเป็นอัตโนมัติโดยไม่ต้องเขียนสคริปต์เอง สำหรับผู้ใช้ในไทยที่ต้องการ latency ต่ำสำหรับลูกค้าปลายทาง แนะนำเลือก region sgp1 (Singapore) เป็นอันดับแรก รองลงมาคือ blr1 (Bangalore) และควรจำไว้ว่าการคิดค่าใช้จ่ายของ DigitalOcean เป็นแบบ per-second โดยมีค่าขั้นต่ำ 60 วินาทีหรือ $0.01 แล้วแต่ค่าไหนสูงกว่า ทำให้ทดสอบสเปกต่างๆ ก่อนตัดสินใจจริงได้โดยไม่เสียค่าใช้จ่ายสูง

Online stores running WooCommerce on top of WordPress have fundamentally different workloads than general content websites. Every page involved with shopping carts, logins, and checkout processing must always be handled dynamically—you cannot serve fully cached static pages like you would for a blog. Therefore, choosing a Droplet spec must account for the number of PHP-FPM workers handling simultaneous shopping cart AJAX calls from multiple users, not just the volume of content served on a single page load. For starter stores with a few hundred products and light traffic, a $12/month Droplet (2 GiB RAM / 1 vCPU / 50 GB SSD / 2,000 GiB transfer) is sufficient for testing and launching small shops. However, once you start receiving real orders and add plugins like coupon systems, membership systems, or inventory management integrations, you should move up to the $24/month tier (4 GiB RAM / 2 vCPU / 80 GB SSD / 4,000 GiB transfer), which offers the best value for mid-size stores with hundreds to thousands of products. For large catalogs with many product variations and high traffic during promotional periods, consider the $48/month tier (8 GiB RAM / 4 vCPU / 160 GB SSD / 5,000 GiB transfer) to give MySQL and PHP-FPM enough resources so pages don't hang during holiday sales. Another important consideration is your database, since WooCommerce's order and order meta tables grow much faster than standard post tables. Once you're processing thousands of orders monthly, moving to DigitalOcean Managed MySQL (starting at $15.15/month for 1 vCPU / 1 GiB RAM, 10-30 GiB storage) will reduce the load on your main Droplet and provide automated database backups without scripting. For Thai users needing low latency for customers, we recommend choosing the sgp1 (Singapore) region first, with blr1 (Bangalore) as a second choice. Also remember that DigitalOcean charges on a per-second basis with a 60-second minimum or $0.01 minimum—whichever is higher—so you can test different specs before making a final decision without incurring high costs.

• Droplet $12/เดือน (2 GiB/1 vCPU/50 GB SSD/2,000 GiB transfer) เหมาะสำหรับทดสอบหรือร้านสินค้าไม่เกินหลักร้อยรายการ
• Droplet $24/เดือน (4 GiB/2 vCPU/80 GB SSD/4,000 GiB transfer) จุดคุ้มค่าสำหรับร้านขนาดกลางที่เริ่มมีคำสั่งซื้อจริง
• Droplet $48/เดือน (8 GiB/4 vCPU/160 GB SSD/5,000 GiB transfer) สำหรับแคตตาล็อกใหญ่และทราฟฟิกช่วงโปรโมชั่น

ติดตั้ง WordPress + WooCommerce

ตรงนี้สำคัญ — การติดตั้ง LEMP stack, WordPress core และตั้งค่าโดเมนเบื้องต้นเป็นขั้นตอนที่เหมือนกับการติดตั้ง WordPress ทั่วไปบน Droplet ซึ่งมีรายละเอียดอยู่แล้วในคู่มือติดตั้ง WordPress บน Droplet ส่วนนี้จะเจาะเฉพาะสิ่งที่ต่างออกไปเมื่อเป้าหมายคือร้านค้าออนไลน์ หลังติดตั้ง WordPress core เสร็จ ให้ติดตั้งปลั๊กอิน WooCommerce ผ่าน WP-CLI ด้วยคำสั่ง wp plugin install woocommerce --activate แล้วรัน setup wizard เพื่อกำหนดสกุลเงิน ที่อยู่ร้าน และวิธีจัดส่ง สิ่งแรกที่ต้องปรับต่างจาก WordPress ธรรมดาคือค่า PHP เพราะ WooCommerce ต้องการทรัพยากรมากกว่าเว็บเนื้อหาทั่วไปอย่างชัดเจน ควรตั้ง memory_limit = 256M ขึ้นไปใน php.ini หรือกำหนดผ่าน define('WP_MEMORY_LIMIT', '256M'); ใน wp-config.php และเพิ่ม max_execution_time เป็นอย่างน้อย 300 วินาทีสำหรับกรณี import สินค้าจำนวนมากผ่านไฟล์ CSV อีกจุดสำคัญที่มักถูกมองข้ามคือ WP-Cron เพราะ WooCommerce ใช้ cron ควบคุมงานสำคัญ เช่น การยกเลิกคำสั่งซื้อที่ยังไม่ชำระเงินตามเวลาที่กำหนด อีเมลแจ้งเตือนสต็อกใกล้หมด และการซิงก์ subscription ระบบ WP-Cron แบบ pseudo-cron ที่ทำงานเฉพาะตอนมีคนเข้าเว็บนั้นไม่น่าเชื่อถือพอสำหรับร้านค้า จึงควรปิดด้วย define('DISABLE_WP_CRON', true); ใน wp-config.php แล้วตั้ง system cron แทนด้วยบรรทัดประมาณ */5 * * * * wget -q -O /dev/null https://yourstore.com/wp-cron.php?doing_wp_cron เพื่อให้งานเบื้องหลังรันตรงเวลาทุก 5 นาทีไม่ว่าจะมีคนเข้าเว็บหรือไม่ นอกจากนี้ควรตรวจสอบว่าตั้ง permalink เป็นแบบ Post name เพื่อให้ URL หน้าสินค้าเป็นมิตรกับ SEO และปล่อยให้ WooCommerce สร้างหน้า Cart, Checkout, My Account อัตโนมัติผ่าน setup wizard โดยไม่ต้องสร้างเพจเหล่านี้เอง

• ติดตั้ง WooCommerce ผ่าน WP-CLI: wp plugin install woocommerce --activate แล้วรัน setup wizard
• เพิ่ม WP_MEMORY_LIMIT เป็นอย่างน้อย 256M ใน wp-config.php เพื่อรองรับปลั๊กอินและ checkout
• ปิด WP-Cron แบบ pseudo-cron แล้วตั้ง system cron ทุก 5 นาที ให้งานยกเลิกออเดอร์/แจ้งเตือนสต็อกทำงานตรงเวลา
• ตั้ง permalink เป็น Post name เพื่อ URL สินค้าที่เป็นมิตรกับ SEO

ตั้งค่า SSL สำหรับหน้าชำระเงิน

หน้าชำระเงินของ WooCommerce เป็นจุดที่ละเอียดอ่อนที่สุดของร้าน เพราะเกี่ยวข้องกับข้อมูลบัตรเครดิตและข้อมูลส่วนบุคคลของลูกค้า แม้ผู้ให้บริการชำระเงินส่วนใหญ่ที่นิยมใช้กับ WooCommerce ในไทย เช่น Omise, 2C2P หรือ Stripe จะใช้วิธี hosted checkout หรือ tokenization ที่ทำให้เลขบัตรจริงไม่ผ่านเซิร์ฟเวอร์ของร้านโดยตรง (ลดขอบเขตการตรวจสอบ PCI DSS ลงเหลือระดับ SAQ A หรือ SAQ A-EP) แต่หน้าที่ฝัง iframe หรือฟอร์มของผู้ให้บริการเหล่านั้นก็ยังต้องโหลดผ่าน HTTPS เท่านั้น เพราะเบราว์เซอร์และผู้ให้บริการชำระเงินจะปฏิเสธการทำงานบนหน้าที่ไม่มี SSL หรือมี mixed content ทันที ขั้นตอนพื้นฐานคือติดตั้งใบรับรอง SSL ฟรีด้วย Let's Encrypt ผ่าน Certbot ด้วยคำสั่งประมาณ certbot --nginx -d yourstore.com -d www.yourstore.com ซึ่งจะออกใบรับรองและตั้งค่า redirect HTTP ไป HTTPS ให้อัตโนมัติ หลังจากนั้นต้องตรวจสอบมากกว่าการมี SSL เฉยๆ โดยเข้าไปที่ WooCommerce > Settings > Advanced แล้วเปิดตัวเลือก Force secure checkout เพื่อบังคับให้หน้า checkout วิ่งผ่าน HTTPS เสมอแม้ผู้ใช้เข้ามาจากลิงก์ http เก่า และควรเพิ่ม HTTP Strict Transport Security (HSTS) ที่ระดับ Nginx ด้วย header ประมาณ add_header Strict-Transport-Security "max-age=31536000" always; เพื่อบังคับเบราว์เซอร์ให้จำไว้ว่าเว็บนี้ต้องใช้ HTTPS เท่านั้นในการเชื่อมต่อครั้งถัดไป ปัญหาที่พบบ่อยคือ mixed content จากรูปสินค้าหรือสคริปต์ของธีมที่ยังลิงก์แบบ http:// อยู่ในฐานข้อมูลเก่า ซึ่งแก้ได้ด้วยการรัน search-replace ผ่าน WP-CLI เช่น wp search-replace 'http://yourstore.com' 'https://yourstore.com' และสุดท้ายควรตั้ง auto-renew ของ Certbot ให้ทำงานผ่าน cron หรือ systemd timer ที่ติดตั้งมาให้อยู่แล้ว เพื่อไม่ให้ใบรับรองหมดอายุกลางคันจนหน้าชำระเงินขึ้นเตือนความปลอดภัยใส่ลูกค้า

• ออกใบรับรอง SSL ฟรีด้วย certbot --nginx -d yourstore.com -d www.yourstore.com
• เปิด Force secure checkout ใน WooCommerce > Settings > Advanced เพื่อบังคับ HTTPS ที่หน้าชำระเงินเสมอ
• เพิ่ม HSTS header ที่ Nginx เพื่อบังคับเบราว์เซอร์ใช้ HTTPS ทุกครั้ง

เพิ่มความเร็วด้วย Caching + CDN

การเร่งความเร็วร้าน WooCommerce ต่างจากบล็อกทั่วไปตรงที่ไม่สามารถเปิด full-page cache แบบเหมารวมทั้งเว็บได้ เพราะหน้าตะกร้าสินค้า (cart) หน้าชำระเงิน (checkout) และหน้าบัญชีสมาชิก (my-account) ต้องแสดงข้อมูลเฉพาะของแต่ละคนเสมอ ถ้าตั้ง cache ผิดจุดจะเกิดปัญหาร้ายแรงกว่าเว็บช้า เช่น ลูกค้า A เห็นตะกร้าสินค้าของลูกค้า B เพราะระบบ cache ส่ง HTML หน้าเดิมซ้ำให้ทุกคน วิธีที่ถูกต้องคือแยกกฎ cache ตามประเภทหน้า หน้าสินค้า (product) และหน้าร้าน (shop) ที่เป็นเนื้อหาสาธารณะสามารถทำ full-page cache ได้ตามปกติ ส่วนหน้า cart/checkout/my-account ต้อง bypass cache เสมอ หากใช้ Nginx FastCGI cache ให้เพิ่มเงื่อนไข bypass ตาม cookie ที่ WooCommerce สร้างขึ้น เช่น fastcgi_cache_bypass $http_cookie ~* "woocommerce_items_in_cart|wp_woocommerce_session"; ควบคู่กับ fastcgi_no_cache เงื่อนไขเดียวกัน เพื่อไม่ให้หน้าที่มีตะกร้าสินค้าอยู่ถูกบันทึกเป็น static cache ถ้าใช้ปลั๊กอิน cache สำเร็จรูปอย่าง WP Rocket หรือ W3 Total Cache ก็ต้องเปิดโหมด 'WooCommerce compatibility' ที่ปลั๊กอินส่วนใหญ่มีมาให้ ซึ่งจะ exclude หน้ากลุ่มนี้อัตโนมัติ นอกเหนือจาก page cache แล้ว การเพิ่ม object cache ด้วย Redis ช่วยลดภาระ MySQL จากการ query ข้อมูล session และตะกร้าสินค้าซ้ำๆ ได้มาก โดยติดตั้ง Redis เองบน Droplet หรือใช้ Managed Valkey (ชื่อใหม่ของบริการ Managed Redis เดิม หลัง Redis เปลี่ยน license) ก็ได้ตามงบประมาณ สำหรับรูปภาพสินค้าซึ่งมักเป็นไฟล์ใหญ่และมีจำนวนมากในร้านค้า แนะนำย้ายไปเก็บที่ DigitalOcean Spaces ซึ่งเริ่มต้น $5/เดือน และมี CDN ในตัวมาให้ทันที ช่วยลดโหลดที่ Droplet หลักและทำให้รูปสินค้าโหลดเร็วขึ้นสำหรับลูกค้าที่อยู่ไกล region ที่ตั้งเซิร์ฟเวอร์

• ห้าม full-page cache หน้า cart/checkout/my-account เด็ดขาด เพราะเสี่ยงข้อมูลตะกร้าสินค้าปนกันระหว่างผู้ใช้
• ตั้ง fastcgi_cache_bypass ตาม cookie woocommerce_items_in_cart และ wp_woocommerce_session บน Nginx
• เปิดโหมด WooCommerce compatibility ในปลั๊กอิน cache เช่น WP Rocket/W3 Total Cache

Backup ข้อมูลร้านค้าอัตโนมัติ

ตรงนี้สำคัญ — ร้านค้าออนไลน์ต่างจากบล็อกตรงที่มีคำสั่งซื้อและธุรกรรมเกิดขึ้นตลอดเวลาแม้ในช่วงดึกหรือวันหยุด การสำรองข้อมูลแบบสัปดาห์ละครั้งจึงไม่เพียงพอ เพราะถ้าเซิร์ฟเวอร์มีปัญหาระหว่างวัน ร้านอาจสูญเสียคำสั่งซื้อของทั้งวันที่ผ่านมาไปเลย กลยุทธ์ backup ที่เหมาะกับ WooCommerce ควรแยกเป็นสองระดับ ระดับแรกคือ backup ทั้ง Droplet ด้วย Snapshot ของ DigitalOcean ซึ่งคิดราคา $0.06/GiB ต่อเดือน เหมาะสำหรับ backup รายสัปดาห์เพื่อกู้คืนทั้งระบบกรณีเซิร์ฟเวอร์มีปัญหาร้ายแรง ระดับที่สองคือ backup เฉพาะฐานข้อมูลที่ต้องถี่กว่านั้นมาก เพราะข้อมูลคำสั่งซื้อ ลูกค้า และสต็อกอยู่ในตาราง MySQL ทั้งหมด วิธีที่ทำได้เองคือตั้ง cron รัน mysqldump ทุกชั่วโมงหรือถี่กว่านั้นตามปริมาณคำสั่งซื้อ แล้วอัปโหลดไฟล์ dump ไปเก็บที่ DigitalOcean Spaces ผ่านเครื่องมืออย่าง rclone หรือ s3cmd เพื่อให้ backup อยู่แยกจาก Droplet หลัก ถ้าไม่อยากดูแล script เอง การย้ายฐานข้อมูลไปใช้ Managed MySQL เริ่มต้น $15.15/เดือน จะช่วยได้มาก เพราะ Managed Database ของ DigitalOcean มีระบบ backup อัตโนมัติในตัวและรองรับการกู้คืนแบบ point-in-time โดยไม่ต้องเขียนสคริปต์เพิ่ม สำหรับไฟล์อัปโหลด เช่น รูปสินค้าและใบเสร็จ ถ้าเก็บไว้บน Volume แยกต่างหากจากดิสก์หลักของ Droplet ก็สามารถทำ Volume snapshot ในราคา $0.06/GiB ต่อเดือนได้เช่นกัน สิ่งสำคัญที่มักถูกลืมคือการทดสอบกู้คืนจริงอย่างน้อยเดือนละครั้ง เพราะ backup ที่ไม่เคยถูกทดสอบกู้คืนถือว่ายังพิสูจน์ไม่ได้ว่าใช้งานได้จริงเมื่อเกิดเหตุฉุกเฉิน

• Droplet Snapshot ราคา $0.06/GiB/เดือน เหมาะ backup ทั้งระบบรายสัปดาห์
• ตั้ง cron รัน mysqldump ทุกชั่วโมงแล้วอัปโหลดไป Spaces ด้วย rclone/s3cmd สำหรับข้อมูลคำสั่งซื้อที่ต้อง backup ถี่
• Managed MySQL เริ่ม $15.15/เดือน มี automated backup และ point-in-time recovery ในตัว ไม่ต้องเขียนสคริปต์เอง
• Volume snapshot ราคา $0.06/GiB/เดือน สำหรับไฟล์อัปโหลด/รูปสินค้าที่เก็บแยก Volume

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

การติดตั้ง WooCommerce บน Droplet เองเหมาะกับร้านค้าที่ต้องการควบคุมเซิร์ฟเวอร์เต็มรูปแบบ ไม่ใช่ทุกร้านที่จำเป็นต้องเดินเส้นทางนี้ กลุ่มที่ได้ประโยชน์ชัดเจนที่สุดคือร้านที่มีปลั๊กอินหรือธีมที่ปรับแต่งเฉพาะทาง เช่น ระบบคำนวณค่าส่งที่เชื่อมต่อ API ขนส่งไทยโดยตรง ระบบเชื่อมต่อคลังสินค้ากับหน้าร้านออฟไลน์ หรือการเชื่อมต่อ payment gateway ท้องถิ่นที่ปลั๊กอินสำเร็จรูปยังไม่รองรับ ซึ่งงานเหล่านี้ต้องเข้าถึงระดับ server configuration ที่ shared hosting ทั่วไปหรือแพลตฟอร์มโฮสต์ WooCommerce สำเร็จรูปมักจำกัดไว้ อีกกลุ่มคือร้านที่มีทราฟฟิกเฉพาะช่วง เช่น แคมเปญลดราคาประจำปีที่ทราฟฟิกพุ่งสูงเป็นสิบเท่าในช่วงสั้นๆ การมี Droplet ของตัวเองทำให้ resize เพิ่ม RAM/CPU ชั่วคราวก่อนแคมเปญแล้วลดกลับหลังจบงานได้ ต่างจากแพ็กเกจ shared hosting ที่ปรับสเปกทันทีไม่ได้ ในทางกลับกัน ถ้าเป้าหมายคือเปิดร้านเล็กๆ ทดสอบตลาด ไม่มีทีมเทคนิคดูแลเซิร์ฟเวอร์ต่อเนื่อง หรือไม่ต้องการรับผิดชอบเรื่อง security patch เอง การใช้ WooCommerce hosting สำเร็จรูปหรือแพลตฟอร์ม e-commerce แบบ SaaS อาจเหมาะกว่าในระยะสั้น เพราะ Droplet ต้องการความรู้ด้าน Linux/Nginx/MySQL อยู่พอสมควรในการดูแลระยะยาว สำหรับร้านที่คาดว่าจะโตเร็วและมีทีมพัฒนาเว็บของตัวเอง การเริ่มด้วย Droplet ตั้งแต่ต้นและวางโครงสร้างให้แยก database/cache/storage ตามที่อธิบายในบทความนี้ตั้งแต่แรก จะประหยัดเวลาการย้ายระบบในอนาคตได้มากกว่าการเริ่มจากแพลตฟอร์มปิดแล้วค่อยย้ายออกทีหลัง

1. เหมาะกับร้านที่ต้องปรับแต่งปลั๊กอิน/เชื่อมต่อ API ขนส่งหรือ payment gateway ท้องถิ่นเฉพาะทาง
2. เหมาะกับร้านที่มีทราฟฟิกพุ่งเฉพาะช่วงแคมเปญ เพราะ resize Droplet เพิ่ม/ลดสเปกได้ตามต้องการ
3. ไม่เหมาะกับร้านเล็กที่ไม่มีทีมเทคนิคดูแล Linux/Nginx/MySQL ต่อเนื่อง
4. ร้านที่วางแผนโตเร็วควรแยก database/cache/storage ตั้งแต่เริ่มต้นเพื่อลดงานย้ายระบบภายหลัง

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

ในประสบการณ์ของเรา ข้อผิดพลาดที่พบบ่อยที่สุดในการติดตั้ง WooCommerce บน Droplet คือการลืมปรับค่า PHP ให้เหมาะกับปลั๊กอิน e-commerce ทำให้เจอหน้าจอขาว (white screen of death) ตอนลูกค้ากดสั่งซื้อ ซึ่งมักมาจาก memory_limit ต่ำเกินไปหรือ PHP-FPM worker ไม่พอรองรับการเรียก AJAX พร้อมกันหลายคนช่วงมีคนเข้าเว็บเยอะ วิธีแก้คือเพิ่ม memory_limit และปรับค่า pm.max_children ใน pool config ของ PHP-FPM ให้สอดคล้องกับ RAM ของ Droplet ข้อผิดพลาดที่ร้ายแรงกว่านั้นคือการตั้ง full-page cache ครอบคลุมหน้า cart/checkout โดยไม่ได้ตั้งใจ ซึ่งอย่างที่กล่าวในหัวข้อ caching อาจทำให้ลูกค้าเห็นตะกร้าสินค้าของคนอื่น หรือเห็นราคาที่ cache ไว้เก่าไม่ตรงกับโปรโมชั่นปัจจุบัน จุดที่มักถูกมองข้ามอีกอย่างคือ webhook หรือ IPN (Instant Payment Notification) จากผู้ให้บริการชำระเงิน ถ้าตั้ง Cloud Firewall เข้มเกินไปโดยไม่เปิดทางให้ IP ของ payment gateway ยิง callback กลับมาแจ้งสถานะการชำระเงิน ออเดอร์จะค้างสถานะ 'รอชำระเงิน' แม้ลูกค้าจ่ายเงินสำเร็จแล้ว จึงต้องตรวจสอบเอกสารของผู้ให้บริการแต่ละเจ้าว่าต้องเปิด IP หรือ port ใดเป็นพิเศษ อีกปัญหาที่พบบ่อยในระยะยาวคือฐานข้อมูลบวมจากตะกร้าสินค้าที่ถูกทิ้งค้าง (abandoned cart) และ transient ที่ WooCommerce สร้างไว้ชั่วคราวแต่ไม่เคยถูกล้าง ทำให้ตาราง wp_options และ wp_postmeta โตขึ้นเรื่อยๆ จนกระทบความเร็ว query ควรตั้งปลั๊กอินทำความสะอาดฐานข้อมูลหรือรัน SQL คำสั่งลบ transient ที่หมดอายุเป็นประจำ สุดท้ายคือการลืมปิดหรือจำกัดการเข้าถึง xmlrpc.php และหน้า wp-login.php ซึ่งเป็นเป้าหมายยอดนิยมของการโจมตีแบบ brute force บนเว็บ WordPress ทุกประเภทรวมถึง WooCommerce

• ปรับ memory_limit และ pm.max_children ของ PHP-FPM ให้พอรองรับ AJAX ตะกร้าสินค้าพร้อมกันหลายคน แก้ปัญหาหน้าขาวตอน checkout
• ตรวจสอบว่า cache ไม่ครอบคลุมหน้า cart/checkout เพื่อป้องกันตะกร้าสินค้าปนกันระหว่างลูกค้า
• เปิด Cloud Firewall ให้ IP ของ payment gateway ยิง webhook/IPN กลับมาได้ ไม่งั้นออเดอร์จะค้างสถานะรอชำระ
• ล้าง transient และ abandoned cart เป็นประจำ ป้องกันฐานข้อมูลบวมจนกระทบความเร็ว
• ปิดหรือจำกัด xmlrpc.php และ wp-login.php ป้องกัน brute force attack

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

นอกเหนือจากการตั้งค่าเฉพาะจุดที่กล่าวมาในบทความนี้ ควรวางแนวทางดูแลร้าน WooCommerce บน Droplet ในระยะยาวไว้เป็นระบบ เริ่มจากการมี staging environment แยกต่างหากสำหรับทดสอบปลั๊กอินหรืออัปเดต WooCommerce/WordPress core ก่อนนำขึ้นเว็บจริงเสมอ เพราะการอัปเดตที่พังบนร้านค้าจริงส่งผลกระทบเป็นรายได้ทันที ไม่ใช่แค่เว็บล่มเฉยๆ ควรเปิดใช้ WooCommerce Logs (อยู่ที่ WooCommerce > Status > Logs) เพื่อตรวจสอบ error จาก payment gateway หรือระบบจัดส่งอย่างสม่ำเสมอ โดยเฉพาะช่วงหลังอัปเดตปลั๊กอินใดๆ เรื่องความปลอดภัยที่เกี่ยวข้องกับ PCI-adjacent ควรอัปเดต WordPress core, WooCommerce และปลั๊กอินที่เกี่ยวข้องกับการชำระเงินให้เป็นเวอร์ชันล่าสุดเสมอ เพราะช่องโหว่ในปลั๊กอิน e-commerce มักถูกใช้เป็นช่องทางขโมยข้อมูลบัตรผ่านการฝัง skimmer script การจำกัดสิทธิ์เข้าถึงหน้า wp-admin ด้วย Cloud Firewall ให้เหลือเฉพาะ IP ของทีมงานเป็นอีกชั้นความปลอดภัยที่ไม่มีค่าใช้จ่ายเพิ่มเติม สำหรับร้านที่วางแผนขยายในอนาคต การใช้ Reserved IP ที่ผูกกับ Droplet ฟรีเมื่อใช้งานอยู่จะช่วยให้ย้ายไป Droplet ใหม่ที่สเปกใหญ่ขึ้นได้แบบไม่ต้องรอ DNS propagate ลดเวลาหน้าร้านล่มระหว่างการย้ายเซิร์ฟเวอร์ ควรเปิดใช้ DigitalOcean Monitoring ซึ่งฟรีอยู่แล้ว พร้อมตั้ง Alert Policy แจ้งเตือนเมื่อ CPU หรือ RAM ใกล้เต็ม เพื่อรู้ล่วงหน้าก่อนที่ร้านจะช้าลงในช่วงทราฟฟิกสูง และสุดท้ายเมื่อจำนวนสินค้าและรูปภาพเพิ่มขึ้นเรื่อยๆ จนดิสก์หลักของ Droplet เริ่มตึง การเพิ่ม Volume แยกต่างหากสำหรับ media library หรือย้ายไปใช้ Spaces ตั้งแต่เนิ่นๆ จะง่ายกว่าการต้อง migrate ข้อมูลจำนวนมากตอนดิสก์เต็มกะทันหัน

• ตั้ง staging environment ทดสอบอัปเดต WooCommerce/ปลั๊กอินก่อนขึ้นเว็บจริงเสมอ
• อัปเดต WordPress core, WooCommerce และปลั๊กอินชำระเงินเป็นเวอร์ชันล่าสุดเสมอ ป้องกันช่องโหว่ skimmer script
• จำกัดการเข้าถึง wp-admin ด้วย Cloud Firewall เฉพาะ IP ทีมงาน (ฟรี ไม่มีค่าใช้จ่ายเพิ่ม)

รับ $200 Free Credit →