คู่มือเชื่อม Cloudflare กับ DigitalOcean Droplet 2026

A practical guide to putting Cloudflare in front of a DigitalOcean Droplet, from DNS migration through locking the Cloud Firewall to Cloudflare-only traffic.

การเอา Cloudflare มาวางหน้า DigitalOcean Droplet เป็นแพทเทิร์นที่นักพัฒนาใช้กันแพร่หลาย เพราะช่วยซ่อน IP จริงของเซิร์ฟเวอร์ กระจายโหลดผ่าน CDN และป้องกัน DDoS ได้โดยไม่เสียค่าใช้จ่ายเพิ่มจากฝั่ง DigitalOcean เลย บทความนี้พาไล่ทีละขั้นตอนตั้งแต่ย้าย DNS เปิด Proxy ตั้งค่า SSL ไปจนถึงล็อก Cloud Firewall ให้รับทราฟฟิกจาก Cloudflare เท่านั้น พร้อมข้อผิดพลาดที่พบบ่อยและวิธีแก้

ทำไมควรใช้ Cloudflare หน้า Droplet

Droplet ของ DigitalOcean มาพร้อม Public IP ที่เปิดสู่อินเทอร์เน็ตตรง ๆ ตั้งแต่วันแรกที่สร้าง ต่างจากบริการ PaaS บางเจ้าที่ซ่อน IP ต้นทางไว้ให้อัตโนมัติ ผลคือใครก็ตามที่รู้ IP ของ Droplet สามารถยิง traffic เข้ามาตรงได้ทันที ไม่ว่าจะเป็นการสแกนหาช่องโหว่ brute-force SSH หรือแม้แต่ DDoS ระดับเล็กที่ทำให้ CPU/Bandwidth ของ Droplet พุ่งจนเว็บล่ม การวาง Cloudflare ไว้ด้านหน้าจึงช่วยแก้ปัญหานี้ได้หลายชั้นพร้อมกัน อย่างแรกคือการซ่อน Origin IP เพราะเมื่อเปิด Proxy (Orange Cloud) ผู้เยี่ยมชมจะเห็นเฉพาะ IP ของ Cloudflare ไม่เห็น IP จริงของ Droplet เว้นแต่จะมีการรั่วไหลผ่านช่องทางอื่น เช่น mail server หรือ subdomain ที่ลืมเปิด proxy อย่างที่สองคือ DDoS protection ระดับ Layer 3/4/7 ที่ Cloudflare ให้ฟรีในทุกแผนรวมถึง Free plan ซึ่งครอบคลุมการโจมตีแบบ volumetric ที่ Droplet เพียงลำพังรับมือไม่ไหว อย่างที่สามคือ CDN แบบ Anycast ที่มี edge node กระจายทั่วโลก ทำให้ผู้ใช้ในไทยหรือเอเชียตะวันออกเฉียงใต้โหลดหน้าเว็บเร็วขึ้นแม้ Droplet จะตั้งอยู่ที่ region ไกล เช่น nyc1 หรือ ams3 เพราะ static asset ถูก cache ไว้ที่ edge ใกล้ผู้ใช้ อย่างที่สี่คือ SSL/TLS ฟรีระหว่างผู้ใช้กับ Cloudflare ทำให้ไม่ต้องพึ่ง Let's Encrypt เพียงอย่างเดียวสำหรับ traffic ฝั่งผู้ใช้ แม้ยังต้องมีใบรับรองระหว่าง Cloudflare กับ Droplet อยู่ดีถ้าต้องการความปลอดภัยระดับ Full Strict สุดท้ายคือการลดโหลดที่ตัว Droplet โดยตรง เพราะ static content อย่างรูปภาพ CSS JS ถูก cache ไว้ที่ edge ทำให้ Droplet ขนาดเล็กอย่างรุ่น 1 vCPU/1 GiB RAM ที่ราคาเริ่มต้น $6/เดือน สามารถรองรับ traffic ได้มากขึ้นโดยไม่ต้อง upgrade ทันที สำหรับทีมที่รันเว็บสาธารณะบน Droplet ไม่ว่าจะเป็น WordPress, Node.js app หรือ static site การเชื่อม Cloudflare จึงเป็นขั้นตอนที่คุ้มค่าและแทบไม่มีข้อเสียถ้าตั้งค่าถูกต้อง

DigitalOcean Droplets come with a public IP exposed directly to the internet from day one, unlike some PaaS providers that hide the origin IP automatically. This means anyone who knows your Droplet's IP can send traffic directly without needing your domain, whether it's scanning for vulnerabilities, brute-forcing SSH, or even small-scale DDoS attacks that spike your CPU/bandwidth until the site crashes. Placing Cloudflare in front solves this on multiple levels at once. First, it masks your origin IP—when you enable Proxy (Orange Cloud), visitors only see Cloudflare's IP addresses, not your Droplet's true IP, unless it leaks through other channels like a mail server or forgotten proxied subdomain. Second, Cloudflare provides Layer 3/4/7 DDoS protection free on every plan, including the Free tier, covering volumetric attacks that a lone Droplet cannot withstand. Third, the Anycast CDN with edge nodes worldwide means users in Thailand or Southeast Asia load pages faster even if your Droplet is in a distant region like nyc1 or ams3, because static assets cache near the user instead. Fourth, Cloudflare offers free SSL/TLS for users, reducing reliance on Let's Encrypt alone for client-facing traffic (though you still need a certificate between Cloudflare and your Droplet if you want Full Strict encryption). Fifth, static content like images, CSS, and JavaScript cached at the edge reduces load on your Droplet directly, allowing small instances with just 1 vCPU/1 GiB RAM starting at $6/month to handle much more traffic without immediate upgrade. For teams running public websites on Droplets—whether WordPress, Node.js apps, or static sites—connecting Cloudflare is a worthwhile step with almost no downside if configured correctly.

• ซ่อน Origin IP ของ Droplet ไม่ให้ผู้ใช้ทั่วไปมองเห็นโดยตรง
• DDoS protection ระดับ L3/L4/L7 ฟรีแม้ใช้ Cloudflare Free plan
• CDN แบบ Anycast ลด latency ให้ผู้ใช้ในไทย/เอเชียแม้ Droplet อยู่ region ไกล
• ลดโหลด CPU/Bandwidth ของ Droplet เพราะ static asset ถูก cache ที่ edge

ย้าย DNS ไปที่ Cloudflare

จุดที่ผู้ใช้มักถามมาคือ ขั้นตอนแรกของการเชื่อม Cloudflare เข้ากับ Droplet คือการย้ายการจัดการ DNS ของโดเมนไปอยู่ที่ Cloudflare ก่อน เริ่มจากเข้า Cloudflare dashboard แล้วกด Add a Site พิมพ์ชื่อโดเมน ระบบจะสแกนหา DNS record ที่มีอยู่เดิมโดยอัตโนมัติ ไม่ว่าจะเก็บอยู่ที่ registrar หรือที่ DigitalOcean DNS เอง ถ้าเดิมใช้ DigitalOcean เป็นผู้จัดการ DNS อยู่แล้วผ่าน doctl สามารถดึงรายการ record ทั้งหมดออกมาตรวจสอบก่อนได้ด้วยคำสั่ง doctl compute domain records list yourdomain.com เพื่อเทียบว่า Cloudflare สแกนมาครบทุก record หรือไม่ โดยเฉพาะ MX record ของอีเมลที่มักถูกมองข้าม เพราะถ้า MX หายไปหลังย้าย DNS อีเมลของโดเมนจะใช้งานไม่ได้ทันที หลังจากตรวจสอบ record ครบแล้วให้เพิ่มหรือแก้ A record ให้ชี้ไปที่ Public IP ของ Droplet และถ้ามี AAAA record สำหรับ IPv6 ก็ต้องตรวจสอบด้วยเช่นกัน ขั้นตอนถัดมา Cloudflare จะให้ nameserver คู่หนึ่งในรูปแบบเช่น aida.ns.cloudflare.com และ walt.ns.cloudflare.com ต้องนำค่านี้ไปตั้งที่ registrar ที่จดโดเมนไว้ ไม่ว่าจะเป็น GoDaddy, Namecheap หรือผู้ให้บริการโดเมนในไทย ขั้นตอนนี้สำคัญมากเพราะเป็นจุดที่ทำให้การควบคุม DNS เปลี่ยนมือจาก DigitalOcean หรือ registrar เดิมไปอยู่ที่ Cloudflay อย่างสมบูรณ์ ก่อนเปลี่ยน nameserver แนะนำให้ลด TTL ของ record สำคัญ เช่น A record ของโดเมนหลักให้เหลือ 300 วินาทีล่วงหน้าอย่างน้อย 24-48 ชั่วโมง เพื่อให้การ cutover เกิดเร็วและ propagate ทั่วโลกได้ไวขึ้นเมื่อถึงเวลาเปลี่ยนจริง การเปลี่ยน nameserver ปกติใช้เวลา propagate ตั้งแต่ไม่กี่นาทีไปจนถึง 24-48 ชั่วโมงขึ้นกับ registrar และ resolver ที่ผู้ใช้ปลายทางใช้งาน ระหว่างนี้ควรเช็คสถานะผ่าน Cloudflare dashboard ที่จะแจ้งเตือนอัตโนมัติเมื่อ nameserver เปลี่ยนสำเร็จและโดเมน active เต็มรูปแบบ

• ใช้ doctl compute domain records list ตรวจสอบ record เดิมก่อนย้ายถ้าเคยใช้ DO DNS
• ตรวจ MX record ให้ครบเพื่อไม่ให้อีเมลของโดเมนล่มหลังย้าย
• ลด TTL เหลือ 300 วินาทีล่วงหน้า 24-48 ชั่วโมงก่อน cutover จริง
• เปลี่ยน nameserver ที่ registrar เป็นคู่ที่ Cloudflare กำหนดให้

เปิด Proxy (Orange Cloud) + SSL Full Strict

หลังโดเมน active บน Cloudflare แล้ว ขั้นตอนถัดไปคือเปิดใช้งาน Proxy หรือที่เรียกกันว่า Orange Cloud บน DNS record ที่ต้องการให้ traffic วิ่งผ่าน Cloudflare เช่น A record ของ www และ root domain โดยกดที่ไอคอนเมฆข้าง record นั้นให้เปลี่ยนจากสีเทา (DNS only) เป็นสีส้ม (Proxied) ส่วน record ที่ไม่ต้องการให้ผ่าน Cloudflare เช่น subdomain สำหรับ mail server หรือ SSH เฉพาะทาง ควรปล่อยเป็นสีเทาไว้เพราะ Cloudflare ไม่ได้ proxy ทุก protocol เมื่อเปิด Proxy แล้วสิ่งที่ต้องทำต่อทันทีคือตั้งค่า SSL/TLS mode ให้ถูกต้อง ซึ่งมีให้เลือก 4 แบบคือ Off, Flexible, Full และ Full (strict) โหมดที่แนะนำสำหรับ Droplet ที่มี SSL certificate ติดตั้งอยู่แล้วคือ Full (strict) เพราะจะบังคับให้ Cloudflare ตรวจสอบใบรับรองที่ Droplet อย่างเข้มงวด ป้องกัน man-in-the-middle ระหว่าง Cloudflare กับ origin server ได้จริง ต่างจากโหมด Flexible ที่เข้ารหัสเฉพาะช่วงผู้ใช้ถึง Cloudflare แต่ฝั่ง Cloudflare ถึง Droplet ยังเป็น HTTP ธรรมดา ซึ่งมักเป็นต้นเหตุของปัญหา redirect loop เมื่อแอปฝั่ง origin บังคับ redirect ไป HTTPS อยู่แล้ว สำหรับใบรับรองที่ต้องติดตั้งบน Droplet เพื่อให้ Full Strict ทำงานได้ มีสองทางเลือกคือใช้ Let's Encrypt ผ่าน Certbot ตามปกติ หรือใช้ Cloudflare Origin CA Certificate ที่สร้างได้ฟรีจากเมนู SSL/TLS > Origin Server > Create Certificate ใบรับรองนี้อายุใช้งานได้นานสูงสุด 15 ปี ไม่ต้อง renew บ่อยเหมือน Let's Encrypt แต่ใช้ได้เฉพาะระหว่าง Cloudflare กับ origin เท่านั้น ไม่สามารถใช้ตรงกับ browser ได้ถ้ามีคนเข้าถึง Droplet โดยข้าม Cloudflare หลังติดตั้งใบรับรองที่ Nginx หรือ Apache แล้วให้เปิด Always Use HTTPS ในเมนู SSL/TLS > Edge Certificates เพื่อบังคับ redirect HTTP ไป HTTPS ทุกครั้งที่ Cloudflare edge ด้วย ลดภาระการจัดการ redirect ที่ฝั่ง Droplet เอง

• เปิด Proxy เฉพาะ record ที่ต้องการ (www, root) ปล่อย record อื่นเป็น DNS only
• ตั้ง SSL/TLS mode เป็น Full (strict) ถ้า Droplet มีใบรับรองถูกต้องแล้ว
• หลีกเลี่ยงโหมด Flexible เพราะมักทำให้เกิด redirect loop กับแอปที่บังคับ HTTPS
• สร้าง Cloudflare Origin CA Certificate ฟรี อายุใช้งานได้นานถึง 15 ปี
• เปิด Always Use HTTPS ที่ Edge Certificates เพื่อ redirect อัตโนมัติที่ edge

ตั้งค่า Firewall ให้รับเฉพาะ Cloudflare IP

การเปิด Proxy อย่างเดียวยังไม่เพียงพอ เพราะ Public IP ของ Droplet ยังคงเข้าถึงได้ตรง ๆ อยู่ ถ้าใครรู้ IP จริงก็สามารถยิง request ข้ามหน้า Cloudflare เข้ามาตรงได้ ทำให้การป้องกัน DDoS และการซ่อน Origin IP ไม่มีความหมายอีกต่อไป ขั้นตอนที่สำคัญมากคือใช้ DigitalOcean Cloud Firewall ซึ่งเป็นฟีเจอร์ที่ไม่มีค่าใช้จ่ายเพิ่มเติมใด ๆ มาล็อกให้ Droplet รับ traffic บน port 80 และ 443 เฉพาะจาก IP range ของ Cloudflare เท่านั้น รายการ IP range ทางการของ Cloudflare ทั้ง IPv4 และ IPv6 ดูได้ที่ cloudflare.com/ips และควรดึงมาใช้สดใหม่เสมอเพราะ Cloudflare มีการปรับ range เป็นระยะแม้ไม่บ่อย วิธีตั้งค่าที่สะดวกที่สุดคือใช้ doctl สร้าง firewall ใหม่ทั้ง inbound rule ครอบคลุมทุก CIDR ของ Cloudflare เช่น doctl compute firewall create --name web-cf-only --droplet-ids DROPLET_ID --inbound-rules "protocol:tcp,ports:80,address:173.245.48.0/20 protocol:tcp,ports:443,address:173.245.48.0/20" จากนั้นเพิ่ม CIDR ที่เหลือทีละช่วงด้วยคำสั่ง add-rules เช่น doctl compute firewall add-rules FIREWALL_ID --rules "protocol:tcp,ports:443,address:173.245.48.0/20" วนซ้ำจนครบทุก range ทั้ง IPv4 และ IPv6 ที่ประกาศไว้ ส่วน port อื่นที่ไม่เกี่ยวกับเว็บ เช่น SSH port 22 ควรแยก rule ต่างหากให้รับเฉพาะ IP ของทีมงานหรือ VPN ไม่ใช่เปิดกว้างให้ทุกคน เพราะ Cloud Firewall ทำงานเป็น allowlist แบบละเอียดต่อ port ได้อยู่แล้วโดยไม่มีค่าใช้จ่ายเพิ่มไม่ว่าจะตั้งกี่ rule ก็ตาม ข้อควรระวังคือถ้าลืมอัปเดต IP range เมื่อ Cloudflare เปลี่ยนแปลง อาจทำให้ Cloudflare เข้าถึง origin ไม่ได้ชั่วคราวและเว็บแสดง error 521/522 จึงแนะนำให้เขียนสคริปต์ดึงรายการ IP ล่าสุดจาก cloudflare.com/ips มาเทียบและอัปเดต firewall rule เป็นระยะ เช่น รันผ่าน cron ทุกเดือน แทนการตั้งครั้งเดียวแล้วลืม

1. ดึง IP range ล่าสุดของ Cloudflare จาก cloudflare.com/ips ทั้ง IPv4 และ IPv6
2. ใช้ doctl compute firewall create/add-rules เปิดเฉพาะ port 80/443 จาก Cloudflare range
3. แยก rule สำหรับ SSH port 22 ให้รับเฉพาะ IP ทีมงานหรือ VPN เท่านั้น

Cache และ Page Rules เบื้องต้น

สิ่งที่น่าสนใจคือ อีกหนึ่งประโยชน์หลักของการวาง Cloudflare หน้า Droplet คือความสามารถด้าน Caching ที่ช่วยลดโหลดของ origin ได้อย่างมีนัยสำคัญ ค่าเริ่มต้นของ Caching Level ที่แนะนำคือ Standard ซึ่ง cache ตาม query string ปกติ และสามารถปรับ Browser Cache TTL ในเมนู Caching เพื่อกำหนดว่า browser ของผู้ใช้ควรเก็บ static asset ไว้นานแค่ไหนก่อนขอใหม่ สำหรับการควบคุมแบบละเอียดกว่านั้น Cloudflare มี Cache Rules ซึ่งเป็นระบบใหม่ที่มาแทน Page Rules แบบเดิม ให้กำหนดเงื่อนไขและพฤติกรรม cache ต่อ path ได้ยืดหยุ่นกว่า เช่น สร้าง rule ให้ path ที่ขึ้นต้นด้วย /wp-admin หรือ /api ถูก bypass cache เสมอเพราะเป็นเนื้อหาที่เปลี่ยนแปลงบ่อยหรือเกี่ยวกับ session ผู้ใช้ ในทางกลับกันสร้างอีก rule ให้ path ของไฟล์ static เช่น .css .js .jpg .png ถูกตั้งเป็น Cache Everything พร้อมกำหนด Edge TTL ยาวขึ้น เช่น 1 เดือน เพื่อให้ edge node เก็บไฟล์เหล่านี้ไว้นานและลดการเรียกกลับมาที่ Droplet บ่อยเกินจำเป็น เมื่อมีการ deploy โค้ดใหม่หรือแก้ไข static asset ควรมีขั้นตอน purge cache ทันทีเพื่อไม่ให้ผู้ใช้เห็นเวอร์ชันเก่าค้างอยู่ ทำได้ทั้งแบบ Purge Everything ผ่าน dashboard หรือ purge เฉพาะไฟล์ผ่าน API เพื่อความแม่นยำในระบบที่มี traffic สูง ระหว่างที่กำลัง debug ปัญหาหน้าเว็บและไม่แน่ใจว่า cache รบกวนหรือไม่ สามารถเปิด Development Mode ชั่วคราวได้ ซึ่งจะ bypass cache ทั้งหมดเป็นเวลา 3 ชั่วโมงโดยอัตโนมัติ ทำให้เห็นการเปลี่ยนแปลงจาก origin แบบ real-time โดยไม่ต้อง purge ทีละไฟล์ สำหรับเว็บที่ใช้ WordPress ควรระวังเป็นพิเศษเรื่อง cache ซ้อนสองชั้น คือ cache ของปลั๊กอินในเว็บเองกับ cache ของ Cloudflare edge เพราะถ้าตั้งค่าไม่สอดคล้องกันอาจทำให้เห็นเนื้อหาเก่าค้างนานผิดปกติ

1. ตั้ง Caching Level เป็น Standard และปรับ Browser Cache TTL ตามความเหมาะสม
2. สร้าง Cache Rule bypass cache สำหรับ /wp-admin และ /api
3. ตั้ง Cache Everything พร้อม Edge TTL ยาวสำหรับไฟล์ static เช่น css/js/รูปภาพ
4. Purge cache ทันทีหลัง deploy เพื่อไม่ให้ผู้ใช้เห็นเวอร์ชันเก่าค้าง
5. เปิด Development Mode ชั่วคราวเมื่อ debug เพื่อ bypass cache ทั้งหมด 3 ชั่วโมง

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

การเชื่อม Cloudflare กับ Droplet เหมาะกับสถานการณ์ที่เว็บหรือแอปเปิดให้สาธารณะเข้าถึงและมีความเสี่ยงจะถูกโจมตีหรือมี traffic ผันผวน เช่น เว็บ WordPress หรือ WooCommerce ที่เปิดขายของจริงและกังวลเรื่อง DDoS ช่วงโปรโมชั่น เว็บข่าวหรือบล็อกที่มีผู้อ่านกระจายหลายประเทศและต้องการความเร็วในการโหลดหน้าเว็บที่สม่ำเสมอ หรือ API endpoint ที่เปิดให้บุคคลภายนอกเรียกใช้และต้องการ rate limiting เบื้องต้นก่อนถึง origin สถานการณ์อีกแบบที่ควรพิจารณาคือทีมที่รัน Droplet ขนาดเล็กอย่างรุ่น 1-2 vCPU และต้องการยืดอายุการใช้งานสเปกนั้นให้นานที่สุดก่อนต้อง upgrade เพราะ static asset จำนวนมากถูก edge cache รับภาระแทน ในทางกลับกันมีบางกรณีที่ไม่จำเป็นต้องใช้ Cloudflare proxy เลย เช่น ระบบ internal tool หรือ admin dashboard ที่เข้าถึงได้เฉพาะผ่าน VPN หรือ WireGuard อยู่แล้วไม่ได้เปิดสู่อินเทอร์เน็ตสาธารณะ กรณีนี้การเปิด proxy อาจเพิ่มความซับซ้อนโดยไม่ได้ประโยชน์เพิ่ม อีกกรณีคือแอปที่ใช้ WebSocket แบบ long-lived connection จำนวนมาก ซึ่งแม้ Cloudflare จะรองรับ WebSocket ผ่าน proxy ได้ แต่ต้องตรวจสอบ timeout และ compatibility ของแต่ละแผนให้ดีก่อน โดยเฉพาะแอป real-time ที่ sensitive กับ latency เพิ่มขึ้นเล็กน้อยจากการผ่าน edge เพิ่มอีกชั้น และสุดท้ายคือเว็บที่มี traffic ต่ำมากและไม่ได้เผชิญความเสี่ยงด้านความปลอดภัยเป็นพิเศษ อาจยังไม่จำเป็นต้องรีบตั้งค่าซับซ้อนขนาดนี้ในทันที แต่ก็ยังแนะนำให้ทำไว้ตั้งแต่ต้นเพราะการตั้งค่าไม่ยุ่งยากและไม่มีต้นทุนเพิ่มจากทั้งสองฝั่ง

1. เว็บ WordPress/WooCommerce ที่เปิดขายจริงและกังวลเรื่อง DDoS ช่วง traffic สูง
2. เว็บที่มีผู้อ่านกระจายหลายประเทศต้องการความเร็วโหลดหน้าสม่ำเสมอ
3. API สาธารณะที่ต้องการ rate limiting เบื้องต้นก่อนถึง origin

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

ปัญหาที่พบบ่อยที่สุดอันดับหนึ่งคือ redirect loop หรือ ERR_TOO_MANY_REDIRECTS ซึ่งมักเกิดจากการตั้ง SSL/TLS mode เป็น Flexible ในขณะที่แอปฝั่ง Droplet บังคับ redirect HTTP ไป HTTPS อยู่แล้ว เช่นปลั๊กอิน Force HTTPS ของ WordPress ทำให้เกิดวนลูป Cloudflare ส่ง HTTP ไป origin origin สั่ง redirect กลับไป HTTPS วนไม่จบ วิธีแก้คือเปลี่ยน SSL mode เป็น Full หรือ Full (strict) แทน อันดับสองคือ error 521 Web Server Is Down หรือ 522 Connection Timed Out ซึ่งมักไม่ได้เกิดจาก Droplet ล่มจริง แต่เกิดจาก Cloud Firewall บล็อก IP ของ Cloudflare โดยไม่ได้ตั้งใจ โดยเฉพาะหลังจากตั้ง firewall แบบ allowlist ตาม IP range แล้วลืมอัปเดตเมื่อ Cloudflare เปลี่ยน range ใหม่ วิธีตรวจสอบคือดู log ของ Nginx/Apache ว่ามี request จาก Cloudflare IP เข้ามาถึง Droplet จริงหรือไม่ ถ้าไม่มีเลยแปลว่าถูก firewall บล็อกอยู่ อันดับสามคือปัญหา real visitor IP ในระบบ log ของ Droplet กลายเป็น IP ของ Cloudflare ทั้งหมดแทนที่จะเป็น IP จริงของผู้ใช้ ทำให้ log สำหรับวิเคราะห์ traffic หรือระบบ rate-limit ที่ฝั่ง origin ทำงานผิดเพี้ยน วิธีแก้คือตั้งค่า Nginx ให้อ่าน header CF-Connecting-IP แทน โดยเพิ่ม config set_real_ip_from 173.245.48.0/20; real_ip_header CF-Connecting-IP; สำหรับทุก range ของ Cloudflare ใน nginx.conf แล้ว reload service อันดับสี่คือ mixed content warning ที่เกิดจากหน้าเว็บมีลิงก์ resource บางส่วนยังเรียกผ่าน http:// แบบ hardcode ทั้งที่เปิด Always Use HTTPS แล้ว ต้องไล่แก้ที่ source code หรือใช้ฟีเจอร์ Automatic HTTPS Rewrites ช่วยแก้บางส่วน และอันดับห้าคือ cache ค้างหลัง deploy โค้ดใหม่ ผู้ใช้ยังเห็นเวอร์ชันเก่า ซึ่งแก้ได้ด้วยการ purge cache ทุกครั้งหลัง deploy หรือผูกเข้ากับ CI/CD pipeline ให้ purge อัตโนมัติ

1. Redirect loop แก้ด้วยเปลี่ยน SSL mode จาก Flexible เป็น Full/Full Strict
2. Error 521/522 มักเกิดจาก Cloud Firewall บล็อก Cloudflare IP ไม่ใช่ Droplet ล่ม
3. Real visitor IP หายไปใน log แก้ด้วย real_ip_header CF-Connecting-IP ใน Nginx

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

เพื่อให้การเชื่อม Cloudflare กับ Droplet มั่นคงในระยะยาวและปลอดภัยจริง มีแนวทางหลักที่ควรยึดถือ ข้อแรกคือใช้ SSL/TLS mode เป็น Full (strict) เสมอ ไม่ควรใช้ Flexible ในระบบ production เพราะช่องระหว่าง Cloudflare กับ origin จะไม่ถูกเข้ารหัสและเปิดช่องให้ traffic ถูกดักฟังได้หากมีใครเข้าถึง network ระหว่างทาง ข้อสองคือล็อก Cloud Firewall ให้รับเฉพาะ Cloudflare IP range เสมอ และเพิ่มการป้องกันอีกชั้นด้วย Authenticated Origin Pulls ซึ่งเป็นฟีเจอร์ของ Cloudflare ที่บังคับให้ origin ตรวจสอบ client certificate ของ Cloudflare ก่อนตอบ request ทำให้แม้มีคนรู้ IP จริงและพยายามปลอมตัวเป็น Cloudflare ก็ยังเข้าไม่ได้ถ้าไม่มี certificate ที่ถูกต้อง ข้อสามคือหมั่นตรวจสอบและ rotate ใบรับรอง Origin CA เป็นระยะแม้จะมีอายุใช้งานได้นานถึง 15 ปี เพราะการ rotate ตามรอบช่วยลดความเสี่ยงหากใบรับรองรั่วไหลโดยไม่รู้ตัว ข้อสี่คือใช้ DigitalOcean Monitoring ควบคู่กันเพื่อตั้ง Alert Policy แจ้งเตือนเมื่อ CPU หรือ Bandwidth ของ Droplet พุ่งผิดปกติ เพราะแม้ Cloudflare จะกรอง traffic ที่เป็นอันตรายไปมากแล้ว แต่ก็ยังควรมีการเฝ้าระวังที่ฝั่ง origin เป็นชั้นสุดท้ายเสมอ ข้อห้าคือทดสอบการตั้งค่าทั้งหมดบน subdomain staging หรือโดเมนทดสอบก่อนเปิด proxy บนโดเมน production จริง เพื่อให้แน่ใจว่า SSL, cache rule และ firewall ทำงานร่วมกันได้ถูกต้องก่อนกระทบผู้ใช้จริง และข้อสุดท้ายคือเก็บเอกสารการตั้งค่าไว้เป็นลายลักษณ์อักษร ทั้ง firewall rule ที่ตั้งไว้ cache rule ที่สร้าง และ nameserver ที่ใช้ เพื่อให้ทีมงานคนอื่นหรือตัวเองในอนาคตเข้าใจโครงสร้างระบบได้เร็วเมื่อต้อง troubleshoot หรือขยายระบบต่อ

• ใช้ SSL/TLS mode Full (strict) เสมอในระบบ production ไม่ใช้ Flexible
• เปิด Authenticated Origin Pulls เสริมจาก Cloud Firewall ที่ล็อก Cloudflare IP
• Rotate ใบรับรอง Origin CA เป็นระยะแม้อายุใช้งานได้นานถึง 15 ปี

รับ $200 Free Credit →