Home » Nginx Reverse Proxy Load Balancing คู่มือตั้งค่า
ไม่มีหมวดหมู่

Nginx Reverse Proxy Load Balancing คู่มือตั้งค่า

March 18, 2026
2 Views

ในยุคดิจิทัลที่ทุกธุรกิจต้องพึ่งพาเว็บไซต์และแอปพลิเคชันออนไลน์ การรับมือกับปริมาณผู้ใช้งานที่เพิ่มขึ้นอย่างรวดเร็ว และการรับประกันความต่อเนื่องของบริการ (High Availability) กลายเป็นสิ่งสำคัญอันดับต้น ๆ เลยใช่ไหมครับ? ไม่มีใครอยากให้เว็บไซต์ล่มหรือทำงานช้าลงเมื่อมีผู้เข้าชมจำนวนมาก หรือต้องเจอกับปัญหาบริการหยุดชะงักเพราะเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งเกิดขัดข้องใช่ไหมครับ? นี่คือจุดที่เทคโนโลยีอย่าง Nginx Reverse Proxy และ Load Balancing เข้ามามีบทบาทสำคัญในการช่วยให้ระบบของคุณแข็งแกร่ง ยืดหยุ่น และพร้อมรับมือกับทุกสถานการณ์

บทความนี้ SiamLancard.com จะพาคุณเจาะลึกถึงวิธีการตั้งค่า Nginx เพื่อใช้งานเป็น Reverse Proxy และ Load Balancer พร้อมตัวอย่างการตั้งค่าที่ใช้งานได้จริงแบบละเอียดทุกขั้นตอนครับ ไม่ว่าคุณจะเป็นนักพัฒนา DevOps Engineer หรือ System Administrator ที่ต้องการเพิ่มประสิทธิภาพและเสถียรภาพให้กับแอปพลิเคชันของคุณ บทความนี้จะให้ข้อมูลเชิงลึกและแนวทางปฏิบัติที่คุณสามารถนำไปใช้ได้ทันทีครับ มาเริ่มกันเลย!

สารบัญ

Nginx Reverse Proxy Load Balancing คืออะไร?

ก่อนที่เราจะลงลึกไปถึงการตั้งค่า เรามาทำความเข้าใจพื้นฐานของแต่ละองค์ประกอบกันก่อนนะครับ เพื่อให้เห็นภาพรวมว่าแต่ละส่วนทำงานร่วมกันอย่างไรและมีประโยชน์อย่างไรต่อระบบของเราครับ

Reverse Proxy คืออะไร?

โดยปกติแล้ว เมื่อผู้ใช้งานเข้าถึงเว็บไซต์หรือแอปพลิเคชัน เซิร์ฟเวอร์ที่ตอบสนองคำขอจะเป็นเซิร์ฟเวอร์โดยตรงที่โฮสต์แอปพลิเคชันนั้น ๆ ซึ่งเรียกว่า “Origin Server” หรือ “Backend Server” ครับ

แต่สำหรับ Reverse Proxy นั้น จะเป็นเซิร์ฟเวอร์ตัวกลางที่อยู่หน้า Backend Server ทำหน้าที่รับคำขอทั้งหมดจากไคลเอนต์ (เช่น เว็บบราวเซอร์ของผู้ใช้งาน) ก่อนที่จะส่งต่อคำขอนั้นไปยัง Backend Server ที่เหมาะสม และเมื่อ Backend Server ประมวลผลเสร็จแล้ว Reverse Proxy ก็จะรับผลลัพธ์กลับมาและส่งต่อไปยังไคลเอนต์อีกทีครับ พูดง่าย ๆ คือ ผู้ใช้งานจะ “คุย” กับ Reverse Proxy โดยตรง ไม่ได้คุยกับ Backend Server โดยตรงเลยครับ

ประโยชน์หลัก ๆ ของ Reverse Proxy:

  • ความปลอดภัย: ซ่อน IP Address และรายละเอียดของ Backend Server จากโลกภายนอก ทำให้แฮกเกอร์เข้าถึง Backend Server ได้ยากขึ้น และยังสามารถใช้เป็นจุดรวมสำหรับการทำ SSL/TLS Termination (ถอดรหัส SSL) ได้ครับ
  • ประสิทธิภาพ: สามารถทำ Caching คอนเทนต์บางส่วนได้ ทำให้ลดภาระของ Backend Server และตอบสนองคำขอได้เร็วขึ้น
  • การทำ Load Balancing: เป็นหัวใจสำคัญของบทความนี้ ซึ่งจะอธิบายในหัวข้อถัดไปครับ
  • การทำ SSL/TLS Offloading: Reverse Proxy สามารถจัดการการเข้ารหัสและถอดรหัส SSL/TLS ได้ ทำให้ Backend Server ไม่ต้องรับภาระในส่วนนี้
  • การจัดการ URL Rewriting และ A/B Testing: สามารถปรับแต่ง URL หรือส่งผู้ใช้งานไปยังเวอร์ชันต่าง ๆ ของแอปพลิเคชันได้

Load Balancing คืออะไร?

Load Balancing คือกระบวนการกระจายปริมาณงาน (Network Traffic หรือ Workload) ข้ามไปยังเซิร์ฟเวอร์หลาย ๆ ตัวอย่างมีประสิทธิภาพครับ เป้าหมายหลักคือการเพิ่มความสามารถในการรองรับปริมาณผู้ใช้งาน (Scalability), เพิ่มความน่าเชื่อถือ (Reliability) และลดเวลาตอบสนอง (Response Time) ของแอปพลิเคชัน

ลองนึกภาพว่าคุณมีเว็บไซต์ยอดนิยมที่มีผู้เข้าชมพร้อมกันหลายพันคน หากมีเพียงเซิร์ฟเวอร์เดียว เซิร์ฟเวอร์นั้นก็อาจจะทำงานหนักเกินไปจนช้าลงหรือล่มไปเลยก็ได้ใช่ไหมครับ?

Load Balancer จะเข้ามาช่วยแก้ปัญหานี้โดยการรับคำขอทั้งหมดและกระจายคำขอเหล่านั้นไปยัง Backend Server ที่ทำงานอยู่และมีภาระงานน้อยที่สุด ทำให้ไม่มีเซิร์ฟเวอร์ใดทำงานหนักเกินไป และถ้ามีเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งล่ม Load Balancer ก็จะหยุดส่งคำขอไปที่เซิร์ฟเวอร์นั้นชั่วคราว และเปลี่ยนไปส่งคำขอไปยังเซิร์ฟเวอร์อื่นที่ยังคงทำงานอยู่แทนครับ ผู้ใช้งานจึงไม่รู้สึกว่าบริการหยุดชะงักเลยครับ

ประโยชน์หลัก ๆ ของ Load Balancing:

  • เพิ่ม Scalability: สามารถเพิ่มจำนวน Backend Server ได้อย่างง่ายดายเพื่อรองรับปริมาณผู้ใช้งานที่เพิ่มขึ้น
  • เพิ่ม High Availability: หากเซิร์ฟเวอร์ตัวใดตัวหนึ่งล่ม ระบบโดยรวมก็ยังคงทำงานต่อไปได้ เพราะ Load Balancer จะส่งคำขอไปยังเซิร์ฟเวอร์ตัวอื่นที่ยังใช้งานได้
  • เพิ่มประสิทธิภาพ: ลดภาระงานของแต่ละเซิร์ฟเวอร์ ทำให้แอปพลิเคชันทำงานได้เร็วขึ้น
  • ลด Downtime: สามารถบำรุงรักษาหรืออัปเดตเซิร์ฟเวอร์แต่ละตัวได้โดยไม่ต้องหยุดบริการทั้งหมด

ทำไมต้อง Nginx สำหรับ Reverse Proxy และ Load Balancing?

Nginx (อ่านว่า “Engine-X”) เป็นเว็บเซิร์ฟเวอร์โอเพนซอร์สที่ได้รับความนิยมอย่างมาก ด้วยความสามารถที่หลากหลายและประสิทธิภาพที่โดดเด่น Nginx ถูกออกแบบมาให้สามารถจัดการกับ Connection จำนวนมหาศาลพร้อมกันได้ ทำให้เหมาะอย่างยิ่งสำหรับการใช้งานเป็น Reverse Proxy และ Load Balancer ครับ

จุดเด่นของ Nginx:

  • สถาปัตยกรรมแบบ Event-Driven: Nginx ใช้โมเดลการประมวลผลแบบ Non-blocking, Event-driven ซึ่งหมายความว่ามันสามารถจัดการกับคำขอพร้อมกันได้หลายพันหรือหลายหมื่นรายการด้วยทรัพยากรที่น้อยกว่าเว็บเซิร์ฟเวอร์แบบอื่น ๆ ที่ใช้โมเดล Process-per-request (เช่น Apache ในบางโหมด)
  • ประสิทธิภาพสูง: มีความเร็วและประสิทธิภาพที่เหนือกว่าในการจัดการกับ Static Content และการเป็น Reverse Proxy
  • การใช้ทรัพยากรต่ำ: ใช้หน่วยความจำ (RAM) และ CPU น้อยกว่าเมื่อเทียบกับคู่แข่งในการจัดการงานที่คล้ายกัน
  • ความยืดหยุ่น: สามารถตั้งค่าได้หลากหลายรูปแบบ รองรับการทำ SSL/TLS Offloading, Caching, Compression, Rate Limiting และอื่น ๆ อีกมากมาย
  • ความน่าเชื่อถือ: ถูกใช้งานโดยเว็บไซต์ที่มีปริมาณทราฟฟิกสูงระดับโลกจำนวนมาก

ด้วยเหตุผลเหล่านี้ Nginx จึงเป็นตัวเลือกที่ยอดเยี่ยมในการสร้างระบบ Reverse Proxy และ Load Balancing ที่แข็งแกร่งและมีประสิทธิภาพสำหรับแอปพลิเคชันของคุณครับ

ประโยชน์ของการใช้ Nginx Reverse Proxy Load Balancing

การนำ Nginx มาใช้เป็น Reverse Proxy และ Load Balancer ไม่ได้เป็นเพียงแค่การกระจายโหลดเท่านั้น แต่ยังนำมาซึ่งประโยชน์มากมายที่ช่วยยกระดับโครงสร้างพื้นฐานของแอปพลิเคชันและเว็บไซต์ของคุณได้อย่างมีนัยสำคัญครับ

  • เพิ่มความน่าเชื่อถือและความพร้อมใช้งาน (High Availability):

    นี่คือประโยชน์ที่ชัดเจนที่สุดครับ หากเซิร์ฟเวอร์ Backend ตัวใดตัวหนึ่งเกิดล่ม, ขัดข้อง หรือต้องปิดปรับปรุง Nginx Load Balancer จะตรวจจับได้และหยุดส่งทราฟฟิกไปยังเซิร์ฟเวอร์นั้นทันที และเปลี่ยนไปส่งคำขอให้เซิร์ฟเวอร์อื่นที่ยังทำงานอยู่แทน ผู้ใช้งานจะไม่รู้สึกถึงการหยุดชะงักของบริการเลยครับ ซึ่งเป็นสิ่งสำคัญอย่างยิ่งสำหรับแอปพลิเคชันที่ต้องการ Downtime เป็นศูนย์

  • เพิ่มความสามารถในการรองรับปริมาณงาน (Scalability):

    เมื่อปริมาณผู้ใช้งานเพิ่มขึ้น คุณสามารถเพิ่ม Backend Server ได้อย่างง่ายดาย (Horizontal Scaling) เพียงแค่เพิ่มเซิร์ฟเวอร์ใหม่เข้าไปในกลุ่ม Backend Servers ที่ Nginx ดูแลอยู่ Nginx ก็จะเริ่มกระจายโหลดไปยังเซิร์ฟเวอร์ใหม่โดยอัตโนมัติ ทำให้ระบบสามารถรองรับการเติบโตได้โดยไม่ต้องกังวลเรื่องคอขวดครับ

  • ปรับปรุงประสิทธิภาพโดยรวม (Performance Improvement):
    • ลดภาระของ Backend Server: Nginx สามารถทำ SSL/TLS Termination, Gzip Compression และ Static File Caching ได้ ซึ่งหมายความว่า Backend Server ไม่ต้องใช้ทรัพยากรในการทำงานเหล่านี้ ทำให้มีทรัพยากรมากขึ้นในการประมวลผล Logic ของแอปพลิเคชัน
    • ลดเวลาตอบสนอง: ด้วยการกระจายโหลดอย่างเหมาะสมและฟีเจอร์ Caching Nginx ช่วยให้คำขอได้รับการตอบสนองเร็วขึ้น
  • เพิ่มความปลอดภัย (Enhanced Security):
    • ซ่อน Backend Servers: Nginx ทำหน้าที่เป็นเกราะป้องกันชั้นแรก ซ่อน IP Address และโครงสร้างภายในของ Backend Servers จากภายนอก ทำให้ลดความเสี่ยงจากการโจมตีโดยตรง
    • จัดการ SSL/TLS: Nginx สามารถจัดการใบรับรอง SSL/TLS ทั้งหมดได้ในจุดเดียว ทำให้การจัดการความปลอดภัยง่ายขึ้นและลดภาระของ Backend Server
    • ป้องกันการโจมตี DDoS และ Brute Force: สามารถตั้งค่า Rate Limiting เพื่อจำกัดจำนวนคำขอจาก IP Address เดียวกันในช่วงเวลาหนึ่ง ช่วยป้องกันการโจมตีบางประเภทได้ครับ
  • อำนวยความสะดวกในการบำรุงรักษาและอัปเดต (Easier Maintenance and Updates):

    คุณสามารถนำ Backend Server ออกจากกลุ่มชั่วคราวเพื่อทำการบำรุงรักษา, อัปเดต หรือปรับใช้เวอร์ชันใหม่ของแอปพลิเคชันได้โดยที่บริการยังคงทำงานต่อไปได้ตามปกติ เพียงแค่ Nginx จะหยุดส่งทราฟฟิกไปที่เซิร์ฟเวอร์นั้น ๆ ชั่วคราว ซึ่งช่วยลด Downtime ได้อย่างมากครับ

  • การจัดการทราฟฟิกที่ยืดหยุ่น (Flexible Traffic Management):

    Nginx มีความสามารถในการจัดการทราฟฟิกได้อย่างยืดหยุ่น เช่น การทำ URL Rewriting, การส่งทราฟฟิกไปยัง Backend Server ที่แตกต่างกันตาม URL Path หรือ Header, และการทำ A/B Testing ซึ่งช่วยให้คุณสามารถทดลองคุณสมบัติใหม่ ๆ หรือปรับแต่งประสบการณ์ผู้ใช้งานได้ง่ายขึ้นครับ

จากประโยชน์ทั้งหมดที่กล่าวมา จะเห็นได้ว่าการใช้ Nginx Reverse Proxy Load Balancing ไม่ใช่แค่ทางเลือก แต่เป็นสิ่งจำเป็นสำหรับระบบที่ต้องการความเสถียร ประสิทธิภาพ และความปลอดภัยในปัจจุบันครับ

พื้นฐานการทำงานของ Nginx Load Balancing Algorithms

Nginx มีวิธีการกระจายโหลด (Load Balancing Algorithms) หลายแบบให้เลือกใช้ ซึ่งแต่ละแบบก็มีจุดเด่นและเหมาะกับการใช้งานที่แตกต่างกันไปครับ การเลือก Algorithm ที่เหมาะสมจะช่วยให้ระบบของคุณทำงานได้อย่างมีประสิทธิภาพสูงสุด

Round Robin

นี่คือ Algorithm พื้นฐานและเป็นค่าเริ่มต้นของ Nginx ครับ หลักการทำงานคือ Nginx จะกระจายคำขอของผู้ใช้งานไปยัง Backend Server แต่ละตัวตามลำดับ โดยจะวนไปเรื่อย ๆ เช่น คำขอแรกไป Server A, คำขอที่สองไป Server B, คำขอที่สามไป Server C, และคำขอที่สี่กลับไป Server A อีกครั้งครับ

  • ข้อดี: ใช้งานง่าย, ไม่ต้องตั้งค่าอะไรเพิ่มเติม, เหมาะสำหรับ Backend Server ที่มีประสิทธิภาพใกล้เคียงกัน
  • ข้อเสีย: ไม่ได้คำนึงถึงภาระงานปัจจุบันของแต่ละเซิร์ฟเวอร์ หากเซิร์ฟเวอร์บางตัวทำงานหนักกว่าตัวอื่น ๆ ก็อาจจะไม่ใช่ทางเลือกที่ดีที่สุด

ตัวอย่างการตั้งค่า (เป็นค่าเริ่มต้น ไม่ต้องระบุ Algorithm ชัดเจน):


upstream backend_servers {
    server 192.168.1.101;
    server 192.168.1.102;
    server 192.168.1.103;
}

Least Connected

Algorithm นี้จะส่งคำขอใหม่ไปยัง Backend Server ที่มีจำนวน Active Connections น้อยที่สุดครับ โดย Nginx จะคอยติดตามจำนวน Connection ของแต่ละเซิร์ฟเวอร์อยู่ตลอดเวลา

  • ข้อดี: ช่วยให้ Backend Server ที่มีภาระงานน้อยที่สุดได้รับคำขอใหม่ ทำให้กระจายโหลดได้สมดุลขึ้น เหมาะสำหรับ Backend Server ที่มีประสิทธิภาพไม่เท่ากัน หรือมี Connection ที่ใช้เวลานานต่างกัน
  • ข้อเสีย: มี Overhead ในการติดตาม Connection เล็กน้อย

ตัวอย่างการตั้งค่า:


upstream backend_servers {
    least_conn;
    server 192.168.1.101;
    server 192.168.1.102;
    server 192.168.1.103;
}

IP Hash

Algorithm นี้จะใช้ IP Address ของผู้ใช้งานเป็นตัวกำหนดว่าคำขอจะถูกส่งไปยัง Backend Server ตัวไหนครับ โดยจะใช้ฟังก์ชัน Hash กับ IP Address ของไคลเอนต์ เพื่อให้คำขอจาก IP Address เดิมถูกส่งไปยัง Backend Server ตัวเดิมเสมอ

  • ข้อดี: เหมาะสำหรับการทำ Session Persistence หรือ Session Affinity ซึ่งสำคัญสำหรับแอปพลิเคชันที่ต้องการให้ผู้ใช้งานคนเดิมคุยกับ Backend Server ตัวเดิมตลอดเวลา (เช่น เว็บไซต์ E-commerce ที่มีการเก็บข้อมูลใน Session)
  • ข้อเสีย: หากมี IP Address ที่ส่งคำขอจำนวนมากจากจุดเดียวกัน (เช่น จากสำนักงานใหญ่ที่มีการใช้ NAT ออกไป) อาจทำให้โหลดไม่สมดุลได้ และหาก Backend Server ตัวใดตัวหนึ่งล่ม การทำ Session Persistence อาจจะหยุดชะงักชั่วคราว

ตัวอย่างการตั้งค่า:


upstream backend_servers {
    ip_hash;
    server 192.168.1.101;
    server 192.168.1.102;
    server 192.168.1.103;
}

ข้อควรระวังสำหรับ IP Hash: หาก Backend Server ตัวใดตัวหนึ่งถูกนำออกหรือเพิ่มเข้ามาในกลุ่ม อาจทำให้ Hash เปลี่ยนแปลงและส่งผลกระทบต่อ Session ของผู้ใช้งานบางรายได้ครับ

Weighted Round Robin

เป็นส่วนเสริมของ Round Robin ครับ โดยเราสามารถกำหนด “น้ำหนัก” (Weight) ให้กับแต่ละ Backend Server ได้ เซิร์ฟเวอร์ที่มี Weight สูงกว่าก็จะได้รับคำขอในสัดส่วนที่มากกว่าครับ

  • ข้อดี: เหมาะสำหรับกรณีที่ Backend Server มีประสิทธิภาพไม่เท่ากัน (เช่น มีเครื่องเก่ากับเครื่องใหม่ปนกัน) ทำให้สามารถส่งทราฟฟิกไปที่เครื่องที่มีประสิทธิภาพสูงกว่าได้มากขึ้น
  • ข้อเสีย: ยังคงไม่ได้คำนึงถึงภาระงานปัจจุบันของแต่ละเซิร์ฟเวอร์

ตัวอย่างการตั้งค่า:


upstream backend_servers {
    server 192.168.1.101 weight=3; # ได้รับ 3 เท่าของเซิร์ฟเวอร์อื่น
    server 192.168.1.102 weight=1;
    server 192.168.1.103 weight=1;
}

ในตัวอย่างนี้ Server 101 จะได้รับคำขอ 3 ครั้ง ในขณะที่ Server 102 และ 103 จะได้รับ 1 ครั้ง ในทุก ๆ 5 คำขอครับ

Generic Hash และ Random (สำหรับ Nginx Plus)

Nginx Open Source มี round_robin, least_conn, และ ip_hash ส่วน Nginx Plus (เวอร์ชันเสียเงิน) จะมี Algorithm ขั้นสูงเพิ่มเติม เช่น:

  • Generic Hash: คล้ายกับ IP Hash แต่สามารถใช้ตัวแปรอื่น ๆ มาคำนวณ Hash ได้ เช่น URI, Cookie, หรือ Argument ของคำขอ ทำให้มีความยืดหยุ่นในการทำ Session Persistence มากขึ้น
  • Random: สุ่มเลือก Backend Server โดยมีตัวเลือกในการใช้ Weight หรือ Least Connected ร่วมด้วย
  • Least Time: (Nginx Plus) เลือก Backend Server ที่มีเวลาตอบสนองโดยเฉลี่ยเร็วที่สุดและมี Active Connections น้อยที่สุด

บทความนี้จะเน้นไปที่ Nginx Open Source เป็นหลัก แต่ก็ควรทราบว่ามี Algorithm เหล่านี้อยู่ใน Nginx Plus ด้วยนะครับ

ตารางเปรียบเทียบ Load Balancing Algorithms

เพื่อช่วยให้คุณตัดสินใจได้ง่ายขึ้นว่าควรเลือก Algorithm แบบไหน ผมได้สรุปข้อดี ข้อเสีย และกรณีที่เหมาะสมสำหรับการใช้งานในตารางด้านล่างนี้ครับ

Algorithm หลักการทำงาน ข้อดี ข้อเสีย กรณีที่เหมาะสม
Round Robin กระจายคำขอตามลำดับไปยังเซิร์ฟเวอร์แต่ละตัว วนไปเรื่อย ๆ ใช้งานง่าย, ค่าเริ่มต้น, เหมาะสำหรับเซิร์ฟเวอร์ที่มีประสิทธิภาพเท่ากัน ไม่คำนึงถึงภาระงานปัจจุบันของเซิร์ฟเวอร์ แอปพลิเคชัน Stateless, Backend Servers มีประสิทธิภาพเท่ากัน
Least Connected ส่งคำขอไปยังเซิร์ฟเวอร์ที่มี Active Connections น้อยที่สุด กระจายโหลดได้สมดุลกว่า, เหมาะสำหรับเซิร์ฟเวอร์ที่มีประสิทธิภาพต่างกัน, จัดการ Connection ที่ใช้เวลานานได้ดี มี Overhead ในการติดตาม Connection เล็กน้อย แอปพลิเคชันที่มี Connection ใช้เวลาต่างกัน (เช่น WebSocket), Backend Servers ประสิทธิภาพไม่เท่ากัน
IP Hash ใช้ IP Address ของไคลเอนต์คำนวณ Hash เพื่อส่งไปยังเซิร์ฟเวอร์ตัวเดิม รักษา Session Persistence (Session Affinity) ได้ดี อาจทำให้โหลดไม่สมดุลหากมี IP Address เดียวส่งคำขอจำนวนมาก, การเปลี่ยนแปลงเซิร์ฟเวอร์มีผลต่อ Session แอปพลิเคชัน Stateful ที่ต้องการ Session Persistence (เช่น ตะกร้าสินค้าใน E-commerce)
Weighted Round Robin กระจายคำขอตามลำดับและ “น้ำหนัก” ที่กำหนดให้แต่ละเซิร์ฟเวอร์ สามารถให้น้ำหนักกับเซิร์ฟเวอร์ที่มีประสิทธิภาพสูงกว่าได้มากขึ้น ยังคงไม่คำนึงถึงภาระงานปัจจุบันของเซิร์ฟเวอร์ Backend Servers มีประสิทธิภาพไม่เท่ากัน และคุณต้องการกำหนดสัดส่วนการรับโหลดด้วยตนเอง

การเตรียมความพร้อมก่อนตั้งค่า Nginx

ก่อนที่เราจะลงมือตั้งค่า Nginx สิ่งสำคัญคือต้องมีการเตรียมความพร้อมที่ดี เพื่อให้กระบวนการติดตั้งและตั้งค่าเป็นไปอย่างราบรื่น และลดปัญหาที่อาจเกิดขึ้นในภายหลังครับ

ความต้องการของระบบ

  • ระบบปฏิบัติการ (Operating System): Nginx สามารถติดตั้งได้บน Linux Distros ยอดนิยม (Ubuntu, CentOS, Debian), FreeBSD, และแม้แต่ Windows (แต่ส่วนใหญ่จะใช้งานบน Linux สำหรับ Production Environment) แนะนำให้ใช้ Linux Server เช่น Ubuntu LTS หรือ CentOS Stream/RHEL เพื่อความเสถียรและระยะเวลา Support ที่ยาวนานครับ
  • ทรัพยากรฮาร์ดแวร์:
    • RAM: Nginx เป็นโปรแกรมที่ใช้ RAM ค่อนข้างน้อย แต่ถ้ามีการทำ Caching จำนวนมาก หรือมี Connection พร้อมกันสูง ก็ต้องการ RAM เพิ่มขึ้น
    • CPU: สำหรับการทำ Load Balancing ทั่วไป Nginx ไม่ได้ใช้ CPU มากนัก แต่หากมีการทำ SSL/TLS Termination หรือ Gzip Compression จำนวนมาก ก็อาจจะต้องการ CPU ที่มีประสิทธิภาพสูงขึ้น
    • Storage: ไม่ได้ต้องการพื้นที่จัดเก็บมากนัก เว้นแต่จะมีการเก็บ Log จำนวนมาก หรือใช้ Nginx Caching ที่มีขนาดใหญ่
  • สิทธิ์ผู้ดูแลระบบ (Root/Sudo Access): คุณจะต้องมีสิทธิ์ในการติดตั้งซอฟต์แวร์และแก้ไขไฟล์ Configuration บนเซิร์ฟเวอร์

โครงสร้างเครือข่ายและการวางแผน IP Address

การวางแผนโครงสร้างเครือข่ายเป็นสิ่งสำคัญเพื่อให้ Nginx สามารถเชื่อมต่อกับ Backend Server และส่งทราฟฟิกได้อย่างถูกต้องครับ

  • Nginx Load Balancer Server:
    • Public IP Address: สำหรับรับคำขอจากผู้ใช้งานภายนอก (ถ้า Nginx เป็น Edge Server)
    • Private IP Address: สำหรับการสื่อสารภายในกับ Backend Servers (เป็นทางเลือกที่ดีด้านความปลอดภัย)
  • Backend Servers (Web/Application Servers):
    • Private IP Address: ควรมี Private IP Address เพื่อให้ Nginx สามารถเข้าถึงได้ โดยไม่จำเป็นต้องเปิด Public IP ให้ Backend Servers โดยตรง (ช่วยเพิ่มความปลอดภัย)
    • Port Number: ตรวจสอบว่า Backend Servers รันอยู่บน Port อะไร (เช่น 80 สำหรับ HTTP, 443 สำหรับ HTTPS, หรือ Port อื่น ๆ สำหรับ Application Server)
  • Firewall Rules:
    • สำหรับ Nginx Server: เปิด Port 80 (HTTP) และ 443 (HTTPS) เพื่อรับคำขอจากภายนอก
    • สำหรับ Backend Servers: เปิด Port ที่แอปพลิเคชันทำงานอยู่ (เช่น 80, 443, 8080) เฉพาะ IP Address ของ Nginx Server เท่านั้น เพื่อจำกัดการเข้าถึงและเพิ่มความปลอดภัย
  • DNS Configuration:

    โดเมนของคุณ (เช่น yourdomain.com) ควรชี้ไปยัง Public IP Address ของ Nginx Load Balancer Server ครับ

ตัวอย่างโครงสร้าง IP:

  • Nginx Load Balancer: Public IP (เช่น 203.0.113.10), Private IP (เช่น 10.0.0.10)
  • Backend Server 1: Private IP (เช่น 10.0.0.21) รันแอปพลิเคชันบน Port 80
  • Backend Server 2: Private IP (เช่น 10.0.0.22) รันแอปพลิเคชันบน Port 80
  • Backend Server 3: Private IP (เช่น 10.0.0.23) รันแอปพลิเคชันบน Port 80

การติดตั้ง Nginx

หากคุณยังไม่ได้ติดตั้ง Nginx บนเซิร์ฟเวอร์ที่ต้องการใช้งานเป็น Load Balancer สามารถทำได้ง่าย ๆ ตามขั้นตอนสำหรับ Linux Distros ยอดนิยมครับ

บน Ubuntu/Debian:


sudo apt update
sudo apt install nginx
sudo systemctl enable nginx
sudo systemctl start nginx

บน CentOS/RHEL/Fedora:


sudo yum install epel-release # สำหรับ CentOS/RHEL 7
sudo dnf install nginx # สำหรับ CentOS/RHEL 8/9 หรือ Fedora
sudo systemctl enable nginx
sudo systemctl start nginx
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

หลังจากติดตั้งเสร็จ คุณควรจะสามารถเข้าถึงหน้า Welcome to Nginx ได้โดยการเปิดเว็บเบราว์เซอร์ไปที่ IP Address สาธารณะของ Nginx Server ครับ

เมื่อเตรียมความพร้อมทั้งหมดเรียบร้อยแล้ว เราก็พร้อมที่จะเข้าสู่ขั้นตอนการตั้งค่า Nginx เพื่อใช้งานเป็น Reverse Proxy และ Load Balancer กันแล้วครับ

อ่านเพิ่มเติมเกี่ยวกับการติดตั้ง Nginx

ขั้นตอนการตั้งค่า Nginx Reverse Proxy Load Balancing

ตอนนี้เรามาถึงส่วนที่สำคัญที่สุดแล้วครับ คือการตั้งค่า Nginx Configuration File เพื่อให้มันทำหน้าที่เป็น Reverse Proxy และ Load Balancer ได้อย่างที่เราต้องการ โดยไฟล์หลักที่เราจะแก้ไขคือ /etc/nginx/nginx.conf หรือสร้างไฟล์แยกต่างหากในไดเรกทอรี /etc/nginx/conf.d/ หรือ /etc/nginx/sites-available/ แล้ว symlink ไปยัง /etc/nginx/sites-enabled/ ครับ สำหรับบทความนี้ เราจะใช้แนวทางที่นิยมคือสร้างไฟล์แยกใน /etc/nginx/conf.d/ ครับ

ก่อนอื่น ให้ลบหรือย้ายไฟล์ default.conf ใน /etc/nginx/conf.d/ ออกไปก่อน (ถ้ามี) เพื่อหลีกเลี่ยงความขัดแย้ง:


sudo mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.bak

จากนั้น สร้างไฟล์ใหม่ เช่น /etc/nginx/conf.d/loadbalancer.conf ด้วยคำสั่ง sudo nano /etc/nginx/conf.d/loadbalancer.conf ครับ

1. กำหนด Backend Servers ด้วย Upstream Block

นี่คือขั้นตอนแรกและสำคัญที่สุดในการบอก Nginx ว่ามี Backend Server อะไรบ้างที่ต้องการจะกระจายโหลดไปหาครับ เราจะใช้ Directive ที่ชื่อว่า upstream

เปิดไฟล์ /etc/nginx/conf.d/loadbalancer.conf และเพิ่ม Upstream Block ดังนี้:


# /etc/nginx/conf.d/loadbalancer.conf

upstream backend_servers {
    # Load Balancing Algorithm (ในที่นี้คือ Round Robin - เป็นค่าเริ่มต้น)
    # หากต้องการใช้ least_conn; หรือ ip_hash; ให้เพิ่มบรรทัดนั้นที่นี่

    server 10.0.0.21:80; # Backend Server 1
    server 10.0.0.22:80; # Backend Server 2
    server 10.0.0.23:80; # Backend Server 3
}

# ส่วนที่เหลือของ Configuration จะมาในขั้นตอนต่อไป

คำอธิบาย:

  • upstream backend_servers { ... }: เป็นการกำหนดกลุ่มของ Backend Server โดยตั้งชื่อว่า backend_servers (คุณสามารถตั้งชื่ออะไรก็ได้ตามความเหมาะสม)
  • server IP_ADDRESS:PORT;: แต่ละบรรทัดคือการระบุ IP Address และ Port ของ Backend Server ของคุณ

ตัวเลือกเพิ่มเติมสำหรับ Server Directive:

คุณสามารถเพิ่มพารามิเตอร์อื่น ๆ ลงในแต่ละ server เพื่อปรับแต่งพฤติกรรมของ Load Balancer ได้ เช่น:

  • weight=N: กำหนดน้ำหนัก (Weight) ให้กับเซิร์ฟเวอร์ สำหรับ Weighted Round Robin (ค่าเริ่มต้นคือ 1) เช่น server 10.0.0.21:80 weight=3;
  • max_fails=N: กำหนดจำนวนครั้งสูงสุดที่ Nginx จะพยายามเชื่อมต่อไปยังเซิร์ฟเวอร์นี้ หากล้มเหลวเกิน N ครั้ง Nginx จะถือว่าเซิร์ฟเวอร์นี้ล่ม (ค่าเริ่มต้นคือ 1)
  • fail_timeout=TIME: กำหนดระยะเวลาที่ Nginx จะถือว่าเซิร์ฟเวอร์ล่ม หากตรวจพบว่าล้มเหลวตาม max_fails หลังจากเวลานี้ Nginx จะลองส่งคำขออีกครั้ง (ค่าเริ่มต้นคือ 10 วินาที) เช่น server 10.0.0.21:80 max_fails=3 fail_timeout=30s;
  • backup: ระบุว่าเซิร์ฟเวอร์นี้เป็นเซิร์ฟเวอร์สำรอง จะถูกใช้งานเฉพาะเมื่อเซิร์ฟเวอร์หลักทั้งหมดล่ม เช่น server 10.0.0.24:80 backup;
  • down: ระบุว่าเซิร์ฟเวอร์นี้ไม่พร้อมใช้งาน Nginx จะไม่ส่งคำขอไปหาเซิร์ฟเวอร์นี้ (มีประโยชน์เมื่อต้องการนำเซิร์ฟเวอร์ออกชั่วคราว) เช่น server 10.0.0.25:80 down;

ตัวอย่าง Upstream พร้อมตัวเลือกเพิ่มเติม:


upstream backend_servers {
    least_conn; # ใช้วิธี Least Connected

    server 10.0.0.21:80 weight=2 max_fails=3 fail_timeout=30s;
    server 10.0.0.22:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.23:80;
    server 10.0.0.24:80 backup; # เซิร์ฟเวอร์สำรอง
    # server 10.0.0.25:80 down; # เซิร์ฟเวอร์นี้ถูกปิดใช้งานชั่วคราว
}

2. ตั้งค่า Server Block สำหรับ Reverse Proxy

หลังจากกำหนดกลุ่ม Backend Server แล้ว เราต้องบอก Nginx ว่าจะรับคำขอจากภายนอกอย่างไร และจะส่งต่อคำขอเหล่านั้นไปที่ upstream ที่เราเพิ่งกำหนดไว้ครับ โดยเราจะใช้ server block และ location block

เพิ่มโค้ดต่อไปนี้ลงในไฟล์ /etc/nginx/conf.d/loadbalancer.conf หลังจาก upstream block:


server {
    listen 80; # Nginx จะรอรับคำขอ HTTP ที่ Port 80
    server_name yourdomain.com www.yourdomain.com; # ระบุโดเมนของคุณ

    location / {
        proxy_pass http://backend_servers; # ส่งต่อคำขอทั้งหมดไปยังกลุ่ม backend_servers
        proxy_set_header Host $host; # ส่ง Host Header เดิมไป Backend
        proxy_set_header X-Real-IP $remote_addr; # ส่ง IP ผู้ใช้งานจริงไป Backend
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # ส่ง Chain ของ Proxy IP ไป Backend
        proxy_set_header X-Forwarded-Proto $scheme; # บอก Backend ว่า Connection เป็น HTTP หรือ HTTPS
    }
}

คำอธิบาย:

  • listen 80;: Nginx จะรับฟังคำขอ HTTP ที่ Port 80
  • server_name yourdomain.com www.yourdomain.com;: กำหนดชื่อโดเมนที่ Server Block นี้จะตอบสนอง คุณควรเปลี่ยนเป็นโดเมนของคุณเองครับ
  • location / { ... }: บล็อกนี้หมายถึงคำขอทั้งหมดที่เข้ามา (Path /)
  • proxy_pass http://backend_servers;: นี่คือหัวใจสำคัญ! Nginx จะส่งต่อคำขอไปยังกลุ่ม Backend Server ที่เรากำหนดไว้ใน upstream backend_servers โดยใช้โปรโตคอล HTTP
  • proxy_set_header ...;: บรรทัดเหล่านี้มีความสำคัญมากในการส่งข้อมูล Header ที่จำเป็นจากผู้ใช้งานไปยัง Backend Server เพื่อให้ Backend Server รู้ว่าคำขอมาจากไหน และควรตอบกลับอย่างไร
    • Host $host;: จำเป็นอย่างยิ่ง เพื่อให้ Backend Server รู้ว่ากำลังตอบสนองคำขอสำหรับโดเมนใด
    • X-Real-IP $remote_addr;: ส่ง IP Address จริงของผู้ใช้งานไปให้ Backend Server
    • X-Forwarded-For $proxy_add_x_forwarded_for;: ส่ง IP Address ของผู้ใช้งานและ IP Address ของ Proxy Server ที่อยู่ระหว่างทาง
    • X-Forwarded-Proto $scheme;: บอก Backend Server ว่า Connection เดิมเป็น HTTP หรือ HTTPS (สำคัญสำหรับการทำ SSL/TLS Termination ที่ Nginx)

3. การเลือก Algorithm สำหรับ Load Balancing

การเลือก Algorithm จะทำใน upstream block ครับ เพียงแค่เพิ่ม Directive ที่เหมาะสมเข้าไปตามที่อธิบายไปในหัวข้อ พื้นฐานการทำงานของ Nginx Load Balancing Algorithms

ตัวอย่าง Round Robin (ค่าเริ่มต้น ไม่ต้องระบุ):


upstream backend_servers {
    server 10.0.0.21:80;
    server 10.0.0.22:80;
}

ตัวอย่าง Least Connected:


upstream backend_servers {
    least_conn; # เพิ่มบรรทัดนี้
    server 10.0.0.21:80;
    server 10.0.0.22:80;
}

ตัวอย่าง IP Hash:


upstream backend_servers {
    ip_hash; # เพิ่มบรรทัดนี้
    server 10.0.0.21:80;
    server 10.0.0.22:80;
}

ตัวอย่าง Weighted Round Robin:


upstream backend_servers {
    server 10.0.0.21:80 weight=2;
    server 10.0.0.22:80 weight=1;
}

4. การตั้งค่า Health Checks และ Failover

Nginx Open Source มี Health Check พื้นฐานมาให้ในตัว โดยใช้พารามิเตอร์ max_fails และ fail_timeout ใน server directive ภายใน upstream block ครับ

  • max_fails=N: จำนวนครั้งที่ Nginx จะลองเชื่อมต่อไปยัง Backend Server เมื่อคำขอล้มเหลว หากล้มเหลวเกิน N ครั้งภายใน fail_timeout Nginx จะพิจารณาว่าเซิร์ฟเวอร์นั้นไม่ทำงาน
  • fail_timeout=TIME: ระยะเวลา (เช่น 10s, 1m) ที่ Nginx จะถือว่า Backend Server ล่ม หลังจากเวลานี้ Nginx จะลองส่งคำขออีกครั้งหนึ่งเพื่อตรวจสอบว่าเซิร์ฟเวอร์กลับมาทำงานหรือยัง

ตัวอย่าง:


upstream backend_servers {
    server 10.0.0.21:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.22:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.23:80 backup; # เซิร์ฟเวอร์สำรอง จะถูกใช้เมื่อเซิร์ฟเวอร์หลักทั้งหมดล่ม
}

ในตัวอย่างนี้ หาก Backend Server 10.0.0.21 ล้มเหลว 3 ครั้งภายใน 30 วินาที Nginx จะหยุดส่งทราฟฟิกไปหาเซิร์ฟเวอร์นี้เป็นเวลา 30 วินาทีครับ หลังจาก 30 วินาที Nginx จะลองส่งคำขออีกครั้ง หากสำเร็จก็จะกลับมาใช้งานได้ตามปกติ หากล้มเหลวอีกก็จะเข้าสู่สถานะ Failed อีกครั้ง

สำหรับ Health Check ที่ซับซ้อนและมีฟังก์ชันการมอนิเตอร์ที่ละเอียดกว่า เช่น การตรวจสอบ HTTP Status Code หรือ Content ของหน้าเว็บ จะต้องใช้ Nginx Plus หรือโมดูล Third-party ครับ

5. การปรับแต่งประสิทธิภาพและความปลอดภัยเพิ่มเติม

Nginx มีความสามารถมากมายที่เราสามารถนำมาใช้เพื่อเพิ่มประสิทธิภาพและความปลอดภัยให้กับระบบ Load Balancing ของเราได้ครับ

SSL/TLS Termination (HTTPS)

การทำ SSL/TLS Termination ที่ Nginx Reverse Proxy เป็นแนวทางปฏิบัติที่ดี ช่วยลดภาระของ Backend Server และรวมการจัดการใบรับรองไว้ที่จุดเดียวครับ

ขั้นตอน:

  1. ติดตั้งใบรับรอง SSL/TLS (เช่น Let’s Encrypt) บน Nginx Server
  2. ตั้งค่า Server Block ให้ฟัง Port 443 และระบุไฟล์ใบรับรอง
  3. บังคับเปลี่ยนเส้นทาง (Redirect) HTTP ไป HTTPS

ตัวอย่างการตั้งค่า HTTPS:


# HTTP to HTTPS Redirect
server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri; # Redirect HTTP to HTTPS
}

# HTTPS Server Block
server {
    listen 443 ssl http2; # ฟัง Port 443 สำหรับ HTTPS และ HTTP/2
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; # Path ไปยังใบรับรอง SSL
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # Path ไปยัง Private Key

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3; # แนะนำให้ใช้ Protocol ที่ปลอดภัยเท่านั้น
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https; # สำคัญมากในการบอก Backend ว่าเป็น HTTPS
    }
}

อย่าลืมเปลี่ยน yourdomain.com และ Path ของไฟล์ SSL Certificate ให้ถูกต้องนะครับ

Caching

Nginx สามารถทำ Caching สำหรับ Static Content หรือแม้แต่ Dynamic Content บางส่วนได้ เพื่อลดภาระ Backend Server และเพิ่มความเร็วในการตอบสนอง


# ใน http block (มักจะอยู่ใน /etc/nginx/nginx.conf)
http {
    # ... อื่นๆ
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;
    # ...
}

# ใน server block หรือ location block ของคุณ
server {
    # ...
    location / {
        proxy_cache my_cache; # เปิดใช้งาน cache ที่กำหนดไว้
        proxy_cache_valid 200 302 10m; # Cache response code 200, 302 เป็นเวลา 10 นาที
        proxy_cache_valid 404 1m; # Cache 404 error เป็นเวลา 1 นาที
        proxy_cache_min_uses 1; # จะ cache เมื่อมีการร้องขออย่างน้อย 1 ครั้ง
        proxy_cache_background_update on; # ให้ Nginx อัปเดต cache ใน background

        # ... proxy_pass และ header อื่นๆ
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # ตัวอย่างสำหรับแคชเฉพาะ Static Files
    location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg)$ {
        expires 365d; # ตั้งค่า cache header สำหรับ browser
        add_header Cache-Control "public, no-transform";
        proxy_pass http://backend_servers; # ยังคงส่งไปที่ backend แต่ cache ด้วย browser
        proxy_set_header Host $host;
    }
}

อย่าลืมสร้างไดเรกทอรีสำหรับแคช: sudo mkdir -p /var/cache/nginx && sudo chown -R www-data:www-data /var/cache/nginx (สำหรับ Ubuntu/Debian) หรือ nginx:nginx (สำหรับ CentOS) ครับ

Gzip Compression

การบีบอัดข้อมูล (Gzip Compression) ช่วยลดขนาดของ Response ที่ส่งกลับไปยังผู้ใช้งาน ทำให้โหลดหน้าเว็บได้เร็วขึ้นครับ

เพิ่มโค้ดต่อไปนี้ใน http block ใน /etc/nginx/nginx.conf:


http {
    # ... อื่นๆ
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # ...
}

Rate Limiting

เพื่อป้องกันการโจมตี DDoS หรือ Brute Force คุณสามารถจำกัดจำนวนคำขอจาก IP Address เดียวกันได้ครับ

เพิ่มโค้ดใน http block (สำหรับกำหนด Zone) และใน server block (สำหรับนำไปใช้งาน):


http {
    # ... อื่นๆ
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s; # อนุญาต 5 คำขอต่อวินาทีต่อ IP
    # ...
}

server {
    # ...
    location / {
        limit_req zone=mylimit burst=10 nodelay; # ใช้ zone ที่กำหนดไว้, อนุญาตให้มี burst ได้ 10 คำขอ
        # ... proxy_pass
    }
}

rate=5r/s หมายถึงอนุญาตให้ 5 คำขอต่อวินาที burst=10 หมายถึงอนุญาตให้มีคำขอส่วนเกินได้ 10 คำขอ ก่อนที่จะเริ่มปฏิเสธคำขอ และ nodelay หมายถึงจะไม่มีการหน่วงเวลาคำขอที่เกิน burst ครับ

Security Headers

การเพิ่ม Security Headers ช่วยเพิ่มความปลอดภัยให้กับเว็บแอปพลิเคชันของคุณได้

เพิ่มใน server block:


server {
    # ...
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # สำหรับ HTTPS เท่านั้น
    # ...
}

การตั้งค่าเหล่านี้จะช่วยให้ Nginx Reverse Proxy Load Balancer ของคุณไม่เพียงแต่กระจายโหลดได้อย่างมีประสิทธิภาพ แต่ยังแข็งแกร่ง ปลอดภัย และตอบสนองได้รวดเร็วขึ้นด้วยครับ

อ่านเพิ่มเติมเกี่ยวกับ Nginx Security Best Practices

ตัวอย่างการตั้งค่า Nginx Reverse Proxy Load Balancing แบบ Full Configuration

เพื่อให้เห็นภาพรวมอย่างชัดเจน นี่คือตัวอย่างไฟล์ /etc/nginx/conf.d/loadbalancer.conf ที่รวมการตั้งค่าทั้งหมดเข้าด้วยกัน โดยมีสมมติฐานว่าเราต้องการทำ Load Balancing สำหรับเว็บไซต์ yourdomain.com ผ่าน HTTPS โดยมี Backend Server 3 ตัว และใช้ Least Connected Algorithm พร้อม Health Check พื้นฐานครับ


# /etc/nginx/conf.d/loadbalancer.conf

# กำหนดกลุ่ม Backend Servers
upstream backend_servers {
    least_conn; # ใช้ Load Balancing แบบ Least Connected

    # Backend Servers พร้อม Health Check และ Weight (ถ้าต้องการ)
    server 10.0.0.21:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.22:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.23:80 max_fails=3 fail_timeout=30s;
    # server 10.0.0.24:80 backup; # ตัวอย่างเซิร์ฟเวอร์สำรอง
}

# Server Block สำหรับ Redirect HTTP ไป HTTPS
server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com; # เปลี่ยนเป็นโดเมนของคุณ
    return 301 https://$host$request_uri; # Redirect HTTP request to HTTPS
}

# Server Block สำหรับ HTTPS Reverse Proxy และ Load Balancing
server {
    listen 443 ssl http2; # ฟัง Port 443 สำหรับ HTTPS และเปิดใช้งาน HTTP/2
    server_name yourdomain.com www.yourdomain.com; # เปลี่ยนเป็นโดเมนของคุณ

    # กำหนด Path ของ SSL Certificate และ Key
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    # SSL/TLS Security Configuration
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;

    # Global Rate Limiting (ถ้าต้องการ) - ต้องกำหนด limit_req_zone ใน http block ก่อน
    # limit_req zone=mylimit burst=10 nodelay;

    # Security Headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Main Location Block สำหรับ Reverse Proxy
    location / {
        proxy_pass http://backend_servers; # ส่งต่อคำขอไปยังกลุ่ม Backend Server
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https; # แจ้ง Backend ว่าคำขอเดิมเป็น HTTPS

        # การตั้งค่า Timeout ต่างๆ
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        send_timeout 60s;

        # การจัดการ Error Pages (ถ้า Backend Server ล่มทั้งหมด)
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root /usr/share/nginx/html; # Path ไปยังไฟล์ Error Page ของ Nginx
            internal;
        }
    }

    # Optional: Cache สำหรับ Static Files (ต้องกำหนด proxy_cache_path ใน http block ก่อน)
    # location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg)$ {
    #     expires 365d;
    #     add_header Cache-Control "public, no-transform";
    #     proxy_pass http://backend_servers;
    #     proxy_set_header Host $host;
    # }
}

ข้อควรจำ:

  • เปลี่ยน yourdomain.com เป็นโดเมนจริงของคุณ
  • ตรวจสอบ Path ของ SSL Certificate และ Key ให้ถูกต้อง
  • ปรับ IP Address ของ Backend Servers ให้ตรงกับระบบของคุณ
  • หากคุณต้องการใช้ Caching หรือ Gzip Compression อย่าลืมเพิ่มการตั้งค่าใน http block ในไฟล์ /etc/nginx/nginx.conf ด้วยนะครับ (ตามตัวอย่างในหัวข้อ 5.5.2 และ 5.5.3)

การทดสอบและตรวจสอบการทำงาน

หลังจากที่คุณได้ตั้งค่า Nginx Configuration File เรียบร้อยแล้ว ขั้นตอนต่อไปคือการทดสอบและตรวจสอบให้แน่ใจว่าทุกอย่างทำงานได้อย่างถูกต้องและไม่มีข้อผิดพลาดครับ การตรวจสอบอย่างละเอียดจะช่วยให้ระบบของคุณมีเสถียรภาพและลดโอกาสการเกิด Downtime ครับ

ทดสอบ Syntax ของ Nginx Configuration

ก่อนที่จะ Reload หรือ Restart Nginx Service ทุกครั้ง ควรตรวจสอบ Syntax ของไฟล์ Configuration ก่อนเสมอ เพื่อป้องกันไม่ให้ Nginx ไม่สามารถ Start ได้เนื่องจากมีข้อผิดพลาดครับ


sudo nginx -t
  • หากการตั้งค่าถูกต้อง คุณจะเห็นข้อความประมาณว่า: 
    
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
  • หากมีข้อผิดพลาด Nginx จะแสดงข้อความระบุบรรทัดและประเภทของข้อผิดพลาด เพื่อให้คุณสามารถกลับไปแก้ไขได้

รีโหลดหรือรีสตาร์ท Nginx Service

หลังจากตรวจสอบ Syntax แล้ว หากทุกอย่างเรียบร้อย คุณสามารถสั่งให้ Nginx โหลด Configuration ใหม่ได้โดยไม่ต้องหยุดบริการ ซึ่งเป็นวิธีที่ดีที่สุดในการปรับใช้การเปลี่ยนแปลงใน Production Environment ครับ


sudo systemctl reload nginx

หรือหากคุณต้องการ Restart Nginx ทั้งหมด (ซึ่งอาจทำให้ Connection ที่มีอยู่ถูกตัด) ก็ใช้คำสั่ง:


sudo systemctl restart nginx

ตรวจสอบสถานะของ Nginx Service เพื่อให้แน่ใจว่ากำลังทำงานอยู่:


sudo systemctl status nginx

คุณควรเห็นสถานะเป็น active (running) ครับ

ทดสอบ Load Balancing

วิธีการทดสอบ Load Balancing มีหลายวิธีครับ:

  1. ใช้เว็บเบราว์เซอร์:

    เปิดเว็บเบราว์เซอร์และเข้าถึงโดเมนของคุณ หาก Backend Server ของคุณมีการแสดงข้อมูลที่แตกต่างกันเล็กน้อย (เช่น ชื่อเซิร์ฟเวอร์, IP Address ของเซิร์ฟเวอร์ที่ตอบกลับ) คุณจะสังเกตเห็นว่าแต่ละครั้งที่คุณกด Refresh หรือเปิดแท็บใหม่ อาจจะเห็น Response จาก Backend Server ที่แตกต่างกันไปครับ

  2. ใช้คำสั่ง curl:

    คุณสามารถใช้ curl เพื่อส่งคำขอซ้ำ ๆ และตรวจสอบ Response Header หาก Backend Server ของคุณมีการตั้งค่าให้ส่ง Header ที่ระบุตัวตน (เช่น X-Served-By: server_name) จะช่วยให้คุณเห็นว่าคำขอถูกส่งไปยังเซิร์ฟเวอร์ใด

    
for i in $(seq 1 10); do curl -s -I http://yourdomain.com | grep "HTTP/1\|X-Served-By"; done

    ผลลัพธ์ที่ได้ควรแสดงว่าคำขอถูกกระจายไปยัง Backend Server ต่าง ๆ ตาม Algorithm ที่คุณเลือกครับ

  3. ตรวจสอบ Log ไฟล์ของ Backend Servers:

    เข้าสู่ระบบ Backend Server แต่ละตัวและตรวจสอบ Access Log ของเว็บเซิร์ฟเวอร์ (เช่น Apache หรือ Nginx บน Backend) คุณจะเห็นว่ามีคำขอเข้ามาจาก IP Address ของ Nginx Load Balancer Server และมีการกระจายคำขอไปยังเซิร์ฟเวอร์แต่ละตัวครับ

  4. จำลองการล่มของ Backend Server:

    เพื่อทดสอบ Health Check และ Failover คุณสามารถหยุดบริการเว็บเซิร์ฟเวอร์บน Backend Server ตัวใดตัวหนึ่งชั่วคราว (เช่น sudo systemctl stop nginx บน Backend Server) จากนั้นลองเข้าถึงเว็บไซต์ของคุณอีกครั้ง Nginx ควรจะหยุดส่งทราฟฟิกไปยังเซิร์ฟเวอร์ที่ล่มและส่งไปยังเซิร์ฟเวอร์ที่เหลือแทน ผู้ใช้งานไม่ควรสังเกตเห็นความผิดปกติใด ๆ ครับ

    หลังจากนั้น ให้เริ่มบริการเว็บเซิร์ฟเวอร์บน Backend Server ที่หยุดไป Nginx ควรจะตรวจจับได้ว่าเซิร์ฟเวอร์กลับมาทำงานแล้วและเริ่มส่งทราฟฟิกกลับไปอีกครั้ง

    5. ตรวจสอบ Log ไฟล์

    Log ไฟล์ของ Nginx เป็นแหล่งข้อมูลสำคัญในการตรวจสอบการทำงานและแก้ไขปัญหาครับ

    • Access Log: บันทึกคำขอทั้งหมดที่เข้ามายัง Nginx โดยปกติจะอยู่ที่ /var/log/nginx/access.log
    • Error Log: บันทึกข้อผิดพลาดที่เกิดขึ้นกับ Nginx โดยปกติจะอยู่ที่ /var/log/nginx/error.log

    คุณสามารถดู Log แบบ Real-time ได้ด้วยคำสั่ง tail -f /var/log/nginx/access.log หรือ tail -f /var/log/nginx/error.log ในขณะที่กำลังทดสอบครับ

    การตรวจสอบอย่างรอบคอบในขั้นตอนนี้จะช่วยให้คุณมั่นใจได้ว่า Nginx Reverse Proxy Load Balancer ของคุณทำงานได้อย่างสมบูรณ์แบบก่อนที่จะนำไปใช้งานจริงครับ

    การดูแลรักษาและแก้ไขปัญหาเบื้องต้น

    หลังจากตั้งค่าและนำ Nginx Reverse Proxy Load Balancing ไปใช้งานแล้ว การดูแลรักษาและการแก้ไขปัญหาที่อาจเกิดขึ้นเป็นสิ่งสำคัญเพื่อให้ระบบทำงานได้อย่างราบรื่นและมีประสิทธิภาพสูงสุดครับ

    ตรวจสอบ Log ไฟล์อย่างสม่ำเสมอ

    Log ไฟล์เป็นเครื่องมือที่ดีที่สุดในการทำความเข้าใจว่าเกิดอะไรขึ้นกับระบบของคุณครับ

Related Articles
จัดส่งรวดเร็วส่งด่วนทั่วประเทศ
รับประกันสินค้าเคลมง่าย มีใบรับประกัน
ผ่อนชำระได้บัตรเครดิต 0% สูงสุด 10 เดือน
สะสมแต้ม รับส่วนลดส่วนลดและคะแนนสะสม

ติดต่อเรา | LINE: @siamlancard

Facebook | YouTube | LINE OA

เว็บในเครือ: SiamCafe.net | iCafeForex.com | Siam2R.com | XMSignal.com

© 2026 SiamLancard — จำหน่ายการ์ดแลน อุปกรณ์ Server และเครื่องพิมพ์ใบเสร็จ

SiamLancard
Logo
Free Forex EA Download — XM Signal · EA Forex ฟรี
iCafeForex.com - สอนเทรด Forex | SiamCafe.net
Shopping cart