ข้ามไปยังเนื้อหา
กลับหน้ารายการบทความ

Caddy: เปิด HTTPS อัตโนมัติและทำ Reverse Proxy ให้แอปบนเซิร์ฟเวอร์เดียว

วาง Caddy หน้าแอปเพื่อรับ TLS จัดเส้นทางคำขอ และตรวจจุดที่ทำให้ใบรับรองออกไม่สำเร็จ

Caddy: เปิด HTTPS อัตโนมัติและทำ Reverse Proxy ให้แอปบนเซิร์ฟเวอร์เดียว

Caddy เป็นเว็บเซิร์ฟเวอร์โอเพนซอร์สที่ใช้เป็น reverse proxy ได้โดยมีระบบจัดการ HTTPS ในตัว เหมาะกับกรณีที่มีแอปฟังพอร์ตภายในเครื่องอยู่แล้ว แต่ต้องการเปิดโดเมนสาธารณะผ่าน TLS โดยไม่ต้องเขียนขั้นตอนขอและต่ออายุใบรับรองเอง บทความนี้ยึดจาก HTTPS quick-start, Automatic HTTPS และ reverse_proxy ของโครงการ

โครงสร้างที่ต้องเข้าใจก่อน

สมมติแอปตอบที่ 127.0.0.1:3000 และโดเมนคือ app.example.com ผู้ใช้เชื่อมต่อพอร์ต 443 ของ Caddy; Caddy รับ TLS แล้วส่ง HTTP ต่อให้แอปภายใน คำสั่ง reverse_proxy เป็นตัวกำหนด upstream ส่วนชื่อโดเมนใน site block เป็นตัวทำให้ Caddy เปิด automatic HTTPS พร้อม redirect จาก HTTP ตามเงื่อนไขในเอกสาร ไม่จำเป็นต้องให้แอปแต่ละตัวจัดการ certificate ซ้ำกัน

เริ่มทดลอง

  1. ชี้ DNS A/AAAA ของโดเมนไปยัง IP ของเครื่อง และเปิดพอร์ต 80/443 ให้เข้าจากอินเทอร์เน็ตได้
  2. ตรวจว่าแอปต้นทางตอบภายในเครื่อง เช่น curl -I http://127.0.0.1:3000
  3. สร้างไฟล์ Caddyfile ดังนี้
app.example.com {
    reverse_proxy 127.0.0.1:3000
}
  1. ใช้ caddy validate --config Caddyfile ตรวจ syntax แล้วเริ่มบริการด้วยวิธีที่เหมาะกับเครื่อง เช่น systemd; เปิด https://app.example.com และตรวจสถานะตอบกลับจริง

ถ้าหลายแอปใช้โดเมนต่างกัน ให้เพิ่ม site block แยกต่อโดเมน หากหลายเส้นทางอยู่ในโดเมนเดียว ให้กำหนด matcher/handler ให้ชัดเจนและทดสอบแต่ละ path เพราะการ proxy ทั้งโดเมนแบบตัวอย่างจะส่งทุกคำขอไป upstream เดียว

วัดผลและแก้ปัญหา

ตรวจทั้ง curl -I https://app.example.com, หน้าแอปจริง และ log ของ Caddy หาก certificate ไม่ออก ให้ตรวจ DNS, firewall, reverse proxy/CDN ที่ขวาง challenge และว่าพอร์ต 80/443 ถูกบริการอื่นจับอยู่หรือไม่ Caddy ต้องมีพื้นที่เก็บข้อมูลที่คงอยู่เพื่อเก็บใบรับรองและกุญแจ หากรันเป็นคอนเทนเนอร์โดยไม่ผูก volume ข้อมูลนี้อาจหายเมื่อสร้างคอนเทนเนอร์ใหม่

เมื่อมี CDN อยู่หน้า Caddy อย่าเชื่อ header ระบุตัวผู้ใช้ที่ client ส่งมาเองโดยไม่มีการกำหนด trusted proxies ที่เหมาะสม เอกสาร reverse_proxy แนะนำให้กำหนด trust ในระดับ servers เพื่อให้การตีความ client IP สอดคล้องกัน อีกประเด็นคือ HTTPS ที่ปลายหน้าไม่ได้แปลว่า upstream ปลอดภัยเอง หากส่งต่อข้ามเครือข่ายที่ไม่ไว้ใจ ต้องประเมินการเข้ารหัสช่วง Caddy ถึงแอปด้วย

สรุปการนำไปใช้

เริ่มจากแอปเดียวและโดเมนเดียว ตรวจ DNS, พอร์ต, การตอบของ upstream และการเก็บ certificate ก่อนขยายไปหลายบริการ วิธีนี้ทำให้แยกได้ว่าปัญหาอยู่ที่ TLS, การจัดเส้นทาง หรือแอปปลายทาง อ่านรายละเอียดเพิ่มเติมจาก เอกสาร Caddy.