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

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

March 17, 2026
0 Views

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

สารบัญ

บทนำ: ทำไมต้อง Nginx Reverse Proxy Load Balancing?

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

ปัญหาที่พบบ่อยในการพัฒนาเว็บแอปพลิเคชัน

  • Single Point of Failure (SPOF): หากมีเซิร์ฟเวอร์เพียงเครื่องเดียวที่ให้บริการ เมื่อเซิร์ฟเวอร์นั้นเกิดปัญหา ระบบทั้งหมดก็จะหยุดชะงักทันทีครับ
  • Scalability Limits: เซิร์ฟเวอร์เดียวมีขีดจำกัดในการประมวลผลและรองรับการเชื่อมต่อพร้อมกัน เมื่อมีผู้ใช้งานเพิ่มขึ้น ระบบจะทำงานช้าลงหรือล่มได้ครับ
  • Performance Bottlenecks: การประมวลผลคำขอจำนวนมากบนเซิร์ฟเวอร์เดียว ทำให้เกิดคอขวดและประสิทธิภาพลดลงครับ
  • Security Concerns: การเปิดเผยเซิร์ฟเวอร์แอปพลิเคชันโดยตรงสู่ภายนอกอาจทำให้ตกเป็นเป้าหมายของการโจมตีได้ง่ายขึ้นครับ

บทบาทของ Reverse Proxy

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

ความสำคัญของ Load Balancing

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

ทำไมต้อง Nginx?

Nginx (Engine-X) เป็นเว็บเซิร์ฟเวอร์ที่ได้รับความนิยมอย่างแพร่หลาย ด้วยประสิทธิภาพที่โดดเด่นในการจัดการการเชื่อมต่อพร้อมกันจำนวนมาก (Concurrent Connections) และการใช้ทรัพยากรที่น้อยมากครับ Nginx ถูกออกแบบมาให้ทำงานแบบ Asynchronous และ Event-driven ซึ่งแตกต่างจากเว็บเซิร์ฟเวอร์แบบดั้งเดิม ทำให้ Nginx เหมาะอย่างยิ่งที่จะนำมาทำหน้าที่เป็น:

  • Reverse Proxy: รับคำขอจากภายนอกและส่งต่อไปยัง Backend Servers
  • Load Balancer: กระจายคำขอไปยัง Backend Servers หลายตัวอย่างชาญฉลาด
  • HTTP Cache: เก็บข้อมูลที่ถูกเรียกใช้บ่อย ๆ เพื่อลดภาระของ Backend Servers
  • SSL/TLS Terminator: จัดการการเข้ารหัส/ถอดรหัส SSL/TLS เพื่อลดภาระของ Backend Servers

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

พื้นฐานที่ควรรู้ก่อนเริ่มต้น

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

Reverse Proxy คืออะไร?

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

เปรียบเทียบง่าย ๆ ก็เหมือนกับพนักงานต้อนรับส่วนหน้า (Receptionist) ที่รับคำขอจากลูกค้า แล้วส่งต่อไปยังแผนกที่เกี่ยวข้องภายในองค์กรครับ ลูกค้าไม่จำเป็นต้องรู้ว่ามีแผนกอะไรบ้าง หรือใครเป็นคนจัดการคำขอโดยตรงครับ

ประโยชน์หลัก ๆ ของ Reverse Proxy ได้แก่:

  • เพิ่มความปลอดภัย: ปกปิด IP Address และรายละเอียดของ Backend Servers จากภายนอก ทำให้ยากต่อการโจมตีโดยตรง
  • เพิ่มประสิทธิภาพ: สามารถทำ Caching, Compression หรือ SSL Termination เพื่อลดภาระของ Backend Servers
  • อำนวยความสะดวกในการทำ Load Balancing: เป็นจุดรวมที่ใช้ในการกระจายคำขอไปยัง Backend Servers หลายตัว
  • จัดการ SSL/TLS: สามารถจัดการการเข้ารหัส/ถอดรหัส HTTPS ที่ Reverse Proxy ได้เลย ทำให้ Backend Servers ไม่ต้องรับภาระส่วนนี้ครับ

Load Balancing คืออะไร?

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

เมื่อมีคำขอเข้ามา Load Balancer จะตัดสินใจว่าจะส่งคำขอนั้นไปยังเซิร์ฟเวอร์ Backend ตัวใด โดยอาศัยอัลกอริทึมที่กำหนดไว้ เช่น Round Robin, Least Connections หรือ IP Hash เป็นต้นครับ

ประโยชน์ของการทำ Load Balancing:

  • Scalability: สามารถเพิ่มจำนวน Backend Servers ได้ง่าย ๆ เพื่อรองรับการเข้าชมที่เพิ่มขึ้น (Horizontal Scaling)
  • High Availability: หากเซิร์ฟเวอร์ Backend ตัวใดตัวหนึ่งล่ม Load Balancer จะตรวจจับได้และหยุดส่งคำขอไปให้ชั่วคราว ทำให้ระบบยังคงทำงานได้อย่างต่อเนื่องโดยไม่มีการหยุดชะงัก (Fault Tolerance)
  • Performance: กระจายภาระงานทำให้เซิร์ฟเวอร์แต่ละตัวทำงานเบาลง ลดเวลาในการตอบสนอง และเพิ่มความเร็วโดยรวมของแอปพลิเคชัน
  • Maintainability: สามารถนำเซิร์ฟเวอร์ Backend ออกไปบำรุงรักษาหรืออัปเดตได้โดยไม่กระทบต่อการทำงานของระบบโดยรวมครับ

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

เมื่อนำ Nginx มาทำหน้าที่เป็นทั้ง Reverse Proxy และ Load Balancer เราจะได้รับประโยชน์มากมายเลยครับ ไม่ว่าจะเป็น:

  • Scalability ที่เหนือกว่า: สามารถเพิ่มเซิร์ฟเวอร์ Backend ได้อย่างง่ายดายเมื่อปริมาณการใช้งานเพิ่มขึ้น ไม่ต้องกังวลว่าระบบจะรองรับไม่ไหวครับ
  • High Availability สูงสุด: Nginx สามารถตรวจจับและหลีกเลี่ยงเซิร์ฟเวอร์ Backend ที่ล่มได้โดยอัตโนมัติ ทำให้มั่นใจได้ว่าบริการของคุณจะพร้อมใช้งานอยู่เสมอ แม้จะมีเซิร์ฟเวอร์บางตัวมีปัญหาครับ
  • ประสิทธิภาพที่ยอดเยี่ยม: ด้วยสถาปัตยกรรมแบบ Event-driven Nginx สามารถจัดการการเชื่อมต่อพร้อมกันจำนวนมากได้อย่างมีประสิทธิภาพ ใช้ทรัพยากรน้อย และยังสามารถทำ Caching และ SSL Termination เพื่อลดภาระของ Backend Servers ได้อีกด้วยครับ
  • ความปลอดภัยที่แข็งแกร่ง: Nginx ทำหน้าที่เป็นด่านหน้า ป้องกันเซิร์ฟเวอร์ Backend จากการโจมตีโดยตรง และสามารถกำหนดค่าไฟร์วอลล์พื้นฐานได้ครับ
  • ความยืดหยุ่นในการตั้งค่า: Nginx มีตัวเลือกการตั้งค่าที่หลากหลายสำหรับ Load Balancing Algorithms, Health Checks และการจัดการ Session ช่วยให้คุณปรับแต่งให้เข้ากับความต้องการเฉพาะของแอปพลิเคชันได้ครับ
  • ประหยัดค่าใช้จ่าย: Nginx Open Source เป็นซอฟต์แวร์ฟรี ทำให้ประหยัดค่าใช้จ่ายเมื่อเทียบกับการใช้ Hardware Load Balancer หรือบริการ Load Balancing แบบเสียเงินครับ

หลักการทำงานของ Nginx Load Balancing

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

อัลกอริทึมการทำ Load Balancing ยอดนิยม

Nginx มีอัลกอริทึม Load Balancing ให้เลือกใช้หลายแบบ แต่ละแบบก็มีจุดเด่นและเหมาะกับการใช้งานที่แตกต่างกันไปครับ

  • Round Robin (ค่าเริ่มต้น)

    เป็นอัลกอริทึมที่ง่ายที่สุดและเป็นค่าเริ่มต้นของ Nginx ครับ โดยจะกระจายคำขอไปยังเซิร์ฟเวอร์ Backend ในกลุ่ม upstream แบบหมุนเวียนกันไปตามลำดับ (Server 1, Server 2, Server 3, Server 1, Server 2, …)

    ข้อดี: ติดตั้งง่าย ไม่ต้องตั้งค่าเพิ่มเติม กระจายโหลดได้ค่อนข้างสม่ำเสมอหากเซิร์ฟเวอร์มีประสิทธิภาพใกล้เคียงกัน

    ข้อเสีย: ไม่คำนึงถึงสถานะหรือภาระงานของเซิร์ฟเวอร์ Backend ณ ขณะนั้น หากเซิร์ฟเวอร์บางตัวทำงานช้ากว่า อาจทำให้เกิดคอขวดได้ครับ

    upstream backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
  • Least Connections (least_conn)

    อัลกอริทึมนี้จะส่งคำขอไปยังเซิร์ฟเวอร์ Backend ที่มีการเชื่อมต่อที่ใช้งานอยู่ (Active Connections) น้อยที่สุดครับ

    ข้อดี: เหมาะสำหรับสถานการณ์ที่คำขอมีระยะเวลาในการประมวลผลไม่เท่ากัน ช่วยให้เซิร์ฟเวอร์ที่มีภาระงานเบาที่สุดได้จัดการคำขอใหม่ ทำให้กระจายโหลดได้สมดุลมากขึ้น

    ข้อเสีย: ต้องใช้ Nginx Plus หรือ Module เพิ่มเติมสำหรับบางฟังก์ชันที่ซับซ้อนขึ้นมาเล็กน้อยครับ (แต่สำหรับ Nginx Open Source ก็สามารถใช้ได้ครับ)

    upstream backend_servers {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
  • IP Hash (ip_hash)

    อัลกอริทึมนี้ใช้ IP Address ของไคลเอ็นต์เป็นกุญแจในการคำนวณ Hash เพื่อเลือกเซิร์ฟเวอร์ Backend ครับ ผลคือไคลเอ็นต์คนเดิมจะถูกส่งไปยังเซิร์ฟเวอร์ Backend ตัวเดิมเสมอ ตราบใดที่เซิร์ฟเวอร์นั้นยังทำงานอยู่

    ข้อดี: เหมาะสำหรับแอปพลิเคชันที่ต้องการ Session Persistence (Sticky Sessions) โดยไม่ต้องใช้ Cookies หรือกลไกอื่น ๆ ช่วยให้ผู้ใช้งานยังคงอยู่ใน Session เดิมกับเซิร์ฟเวอร์เดิมครับ

    ข้อเสีย: หากมีไคลเอ็นต์จำนวนมากมาจาก IP Address เดียวกัน (เช่น มาจากเครือข่ายองค์กรเดียวกัน หรือใช้ Proxy) อาจทำให้เกิดการกระจายโหลดที่ไม่สมดุลได้ครับ

    upstream backend_servers {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
  • Generic Hash (hash)

    คล้ายกับ IP Hash แต่ให้คุณกำหนดกุญแจ (Key) ที่ใช้ในการคำนวณ Hash ได้เอง เช่น ใช้ URI, Header, หรือตัวแปรอื่น ๆ ครับ

    ข้อดี: ยืดหยุ่นกว่า IP Hash สามารถสร้าง Session Persistence จากค่าอื่น ๆ ที่ไม่ใช่ IP ได้

    ข้อเสีย: ต้องกำหนด Key ที่เหมาะสมเอง และอาจต้องใช้ Module เพิ่มเติมหรือ Nginx Plus สำหรับฟังก์ชันขั้นสูงบางอย่างครับ

    upstream backend_servers {
    hash $request_uri consistent; # ใช้ URI ในการทำ Hash
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
  • Random (random)

    จะสุ่มเลือกเซิร์ฟเวอร์ Backend สำหรับแต่ละคำขอ โดยสามารถกำหนด two เพื่อสุ่มเลือกสองเซิร์ฟเวอร์แล้วใช้ least_conn หรือ least_time (ต้อง Nginx Plus) มาตัดสินใจอีกทีครับ

    ข้อดี: ลดปัญหา Hot Spot ใน Cache ของ Load Balancer (ถ้ามี) และสามารถทำงานได้ดีในบางสถานการณ์

    ข้อเสีย: การกระจายโหลดอาจไม่สม่ำเสมอเท่า Round Robin หรือ Least Connections

    upstream backend_servers {
    random; # สุ่มเลือก
    # random two least_conn; # สุ่มเลือก 2 ตัวแล้วใช้ least_conn (Nginx Plus)
    server backend1.example.com;
    server backend2.example.com;
}
  • Weighted Round Robin (Weight)

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

    ข้อดี: เหมาะสำหรับกรณีที่เซิร์ฟเวอร์ Backend มีฮาร์ดแวร์หรือประสิทธิภาพไม่เท่ากัน คุณสามารถส่งโหลดไปยังเซิร์ฟเวอร์ที่ทรงพลังกว่าได้มากขึ้น

    ข้อเสีย: ยังคงไม่คำนึงถึงสถานะภาระงานจริงของเซิร์ฟเวอร์ ณ ขณะนั้นครับ

    upstream backend_servers {
    server backend1.example.com weight=3; # ได้รับ 3 เท่า
    server backend2.example.com weight=1; # ได้รับ 1 เท่า
    server backend3.example.com;         # ค่าเริ่มต้น weight=1
}

ตารางเปรียบเทียบอัลกอริทึม Load Balancing

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

อัลกอริทึม หลักการทำงาน ข้อดี ข้อเสีย เหมาะสำหรับ
Round Robin กระจายคำขอแบบหมุนเวียนไปตามลำดับ ติดตั้งง่าย, กระจายโหลดพื้นฐานดี ไม่คำนึงถึงภาระงานจริงของเซิร์ฟเวอร์ เซิร์ฟเวอร์มีประสิทธิภาพใกล้เคียงกัน, โหลดสม่ำเสมอ
Least Connections (least_conn) ส่งคำขอไปเซิร์ฟเวอร์ที่มี Active Connections น้อยที่สุด กระจายโหลดสมดุลกว่า, เหมาะกับคำขอที่มีระยะเวลาไม่เท่ากัน อาจต้องใช้ Nginx Plus สำหรับฟังก์ชันขั้นสูง เซิร์ฟเวอร์มีประสิทธิภาพต่างกัน, คำขอใช้เวลาประมวลผลต่างกัน
IP Hash (ip_hash) ใช้ IP ของไคลเอ็นต์คำนวณ Hash เพื่อส่งไปยังเซิร์ฟเวอร์เดิม รองรับ Session Persistence ได้โดยง่าย อาจทำให้โหลดไม่สมดุลหาก IP มาจากแหล่งเดียวกันมาก ๆ แอปพลิเคชันที่ต้องการ Session Persistence
Generic Hash (hash) กำหนด Key เองเพื่อคำนวณ Hash ยืดหยุ่นกว่า IP Hash ในการสร้าง Session Persistence ต้องกำหนด Key ที่เหมาะสม, อาจต้องใช้ Nginx Plus แอปพลิเคชันที่ต้องการ Session Persistence ด้วย Key เฉพาะ
Random (random) สุ่มเลือกเซิร์ฟเวอร์สำหรับแต่ละคำขอ ลด Hot Spot ใน Cache (ถ้ามี) การกระจายโหลดอาจไม่สม่ำเสมอ กรณีพิเศษที่ต้องการความสุ่ม, ไม่เน้นสมดุลโหลดเป๊ะ ๆ
Weighted Round Robin (weight) กระจายคำขอแบบ Round Robin โดยให้เซิร์ฟเวอร์ที่มี Weight มากกว่าได้รับคำขอมากกว่า เหมาะสำหรับเซิร์ฟเวอร์ที่มีประสิทธิภาพต่างกัน ยังไม่คำนึงถึงภาระงาน ณ ขณะนั้น มีเซิร์ฟเวอร์ที่มีสเปกต่างกัน

การเตรียมสภาพแวดล้อม (Prerequisites)

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

เซิร์ฟเวอร์ Nginx (Reverse Proxy)

คุณจะต้องมีเซิร์ฟเวอร์หนึ่งเครื่องสำหรับติดตั้ง Nginx เพื่อทำหน้าที่เป็น Reverse Proxy และ Load Balancer ครับ

  • ระบบปฏิบัติการ: แนะนำ Linux Distribution เช่น Ubuntu (เวอร์ชัน LTS) หรือ CentOS/Rocky Linux ครับ
  • ทรัพยากร: สำหรับการเริ่มต้น เซิร์ฟเวอร์ที่มี 1-2 vCPU และ RAM 1-2 GB ก็เพียงพอแล้วครับ แต่หากมีการใช้งานสูงขึ้นอาจต้องเพิ่มทรัพยากรตามความเหมาะสม
  • IP Address: ต้องมี Public IP Address ที่สามารถเข้าถึงได้จากภายนอก เพื่อให้ไคลเอ็นต์สามารถเชื่อมต่อไปยัง Nginx ได้ครับ

เซิร์ฟเวอร์ Backend Applications (อย่างน้อย 2 ตัว)

คุณจะต้องมีเซิร์ฟเวอร์อย่างน้อย 2 เครื่องที่รันเว็บแอปพลิเคชันของคุณอยู่ครับ เพื่อให้ Nginx สามารถกระจายโหลดไปให้ได้

  • ระบบปฏิบัติการ: สามารถเป็นอะไรก็ได้ที่รองรับแอปพลิเคชันของคุณ (เช่น Linux, Windows)
  • แอปพลิเคชัน: เว็บแอปพลิเคชันของคุณควรทำงานอยู่บนพอร์ตที่สามารถเข้าถึงได้จากเซิร์ฟเวอร์ Nginx (เช่น พอร์ต 80, 8080, 3000)
  • IP Address: ควรเป็น Private IP Address ที่เซิร์ฟเวอร์ Nginx สามารถเข้าถึงได้ (เช่น อยู่ในเครือข่ายเดียวกัน หรือมี Routing ที่ถูกต้อง)
  • ความสม่ำเสมอ: โดยทั่วไปแล้ว Backend Servers ควรจะมีโค้ดแอปพลิเคชันเวอร์ชันเดียวกันและข้อมูลที่ซิงค์กัน เพื่อให้ผู้ใช้งานได้รับประสบการณ์ที่สม่ำเสมอไม่ว่าจะถูกส่งไปเซิร์ฟเวอร์ไหนครับ

โดเมนเนมและ DNS

คุณจะต้องมีโดเมนเนม (เช่น yourdomain.com) ที่ชี้ไปยัง Public IP Address ของเซิร์ฟเวอร์ Nginx Reverse Proxy ครับ การตั้งค่า DNS (Domain Name System) โดยการเพิ่ม A record หรือ CNAME record ให้ชี้ไปยัง IP ของ Nginx Server เป็นสิ่งจำเป็นเพื่อให้ผู้ใช้งานสามารถเข้าถึงเว็บไซต์ของคุณด้วยชื่อโดเมนได้ครับ

  • A Record: yourdomain.com -> Public IP ของ Nginx Server
  • A Record: www.yourdomain.com -> Public IP ของ Nginx Server

ความรู้พื้นฐาน Linux Command Line

การตั้งค่า Nginx ส่วนใหญ่จะทำผ่าน Command Line Interface (CLI) บนระบบปฏิบัติการ Linux ครับ ดังนั้น การมีความรู้พื้นฐานเกี่ยวกับการใช้งานคำสั่ง Linux เช่น ssh, sudo, apt/yum, nano/vi, systemctl, firewall-cmd/ufw จะช่วยให้คุณสามารถดำเนินการตามคู่มือนี้ได้อย่างราบรื่นครับ

เมื่อเตรียมพร้อมทุกอย่างแล้ว เราก็จะเข้าสู่ขั้นตอนการตั้งค่าจริงกันเลยครับ!

อ่านเพิ่มเติมเกี่ยวกับ SSH และการจัดการเซิร์ฟเวอร์ Linux

คู่มือตั้งค่า Nginx Reverse Proxy Load Balancing ทีละขั้นตอน

ได้เวลาลงมือปฏิบัติจริงกันแล้วนะครับ! ในส่วนนี้ เราจะมาดูขั้นตอนการตั้งค่า Nginx Reverse Proxy Load Balancing อย่างละเอียดทีละขั้นตอนกันครับ

ขั้นตอนที่ 1: ติดตั้ง Nginx บนเซิร์ฟเวอร์ Reverse Proxy

เราจะเริ่มต้นด้วยการติดตั้ง Nginx บนเซิร์ฟเวอร์ที่เรากำหนดให้เป็น Reverse Proxy ครับ

สำหรับ Ubuntu/Debian:

sudo apt update
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx
sudo ufw allow 'Nginx HTTP'
sudo ufw allow 'Nginx HTTPS'
sudo ufw enable # หากยังไม่ได้เปิดใช้งาน UFW

สำหรับ CentOS/Rocky Linux:

sudo yum install epel-release -y
sudo yum install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

หลังจากติดตั้งเสร็จ ลองเข้า IP Address สาธารณะของเซิร์ฟเวอร์ Nginx ผ่านเว็บเบราว์เซอร์ดูครับ คุณควรจะเห็นหน้า “Welcome to Nginx!” ซึ่งแสดงว่า Nginx ทำงานได้ถูกต้องแล้วครับ

ขั้นตอนที่ 2: ตั้งค่า Backend Servers

ในตัวอย่างนี้ เราจะสมมติว่าคุณมี Backend Servers สองตัวที่รันเว็บแอปพลิเคชันอยู่บนพอร์ต 8080 ครับ เพื่อให้เห็นภาพชัดเจน เราจะสร้างไฟล์ HTML ง่าย ๆ บนแต่ละเซิร์ฟเวอร์เพื่อให้เรารู้ว่าคำขอถูกส่งไปที่เซิร์ฟเวอร์ไหนครับ

บน Backend Server 1 (สมมติ IP: 192.168.1.101):

สร้างไฟล์ /var/www/html/index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Backend Server 1</title>
</head>
<body>
    <h1>Hello from Backend Server 1!</h1>
    <p>This is the application running on 192.168.1.101.</p>
</body>
</html>

จากนั้นติดตั้งเว็บเซิร์ฟเวอร์เบา ๆ เช่น Python Simple HTTP Server หรือ Node.js Express เพื่อรันบนพอร์ต 8080 ครับ

ตัวอย่าง Python Simple HTTP Server:

sudo apt install python3-minimal -y # สำหรับ Ubuntu
cd /var/www/html
nohup python3 -m http.server 8080 &

ตัวอย่าง Node.js Express (ติดตั้ง Node.js ก่อน):

// app.js
const express = require('express');
const app = express();
const port = 8080;
const serverName = 'Backend Server 1 (192.168.1.101)';

app.get('/', (req, res) => {
  res.send(`<h1>Hello from ${serverName}!</h1><p>This is the application running on 192.168.1.101.</p>`);
});

app.listen(port, () => {
  console.log(`${serverName} listening on port ${port}`);
});
# บน Backend Server 1
sudo apt install nodejs npm -y # ติดตั้ง Node.js
mkdir ~/my-app && cd ~/my-app
# วางโค้ด app.js ที่นี่
npm init -y
npm install express
nohup node app.js &

บน Backend Server 2 (สมมติ IP: 192.168.1.102):

ทำเช่นเดียวกัน แต่แก้ไขไฟล์ index.html หรือข้อความใน app.js ให้ระบุว่าเป็น “Backend Server 2 (192.168.1.102)” ครับ

ลองทดสอบเข้าถึงจากเซิร์ฟเวอร์ Nginx โดยใช้คำสั่ง curl http://192.168.1.101:8080 และ curl http://192.168.1.102:8080 เพื่อให้แน่ใจว่า Backend Servers ทำงานได้ปกติและสามารถเข้าถึงได้จาก Nginx ครับ

ขั้นตอนที่ 3: กำหนดค่า Nginx สำหรับ Load Balancing

ตอนนี้เราจะมาตั้งค่า Nginx ให้ทำหน้าที่เป็น Reverse Proxy และ Load Balancer ครับ

ไฟล์คอนฟิกูเรชันหลักของ Nginx (`nginx.conf`)

โดยปกติแล้ว เราไม่ควรแก้ไขไฟล์ /etc/nginx/nginx.conf โดยตรงมากนักครับ แต่เราจะสร้างไฟล์คอนฟิกูเรชันใหม่ในไดเรกทอรี /etc/nginx/conf.d/ หรือ /etc/nginx/sites-available/ (แล้วสร้าง Symlink ไปที่ sites-enabled/) ครับ

ตรวจสอบให้แน่ใจว่าไฟล์ nginx.conf มีบรรทัดที่ include ไฟล์คอนฟิกูเรชันอื่น ๆ ครับ เช่น:

# ในไฟล์ /etc/nginx/nginx.conf
http {
    # ...
    include /etc/nginx/conf.d/*.conf; # บรรทัดนี้สำคัญมาก
    # ...
}

การสร้างไฟล์คอนฟิกูเรชันสำหรับ Load Balancing (`/etc/nginx/conf.d/loadbalancer.conf`)

มาสร้างไฟล์คอนฟิกูเรชันสำหรับ Load Balancing กันครับ โดยใช้โปรแกรมแก้ไขข้อความ เช่น nano หรือ vi:

sudo nano /etc/nginx/conf.d/loadbalancer.conf

จากนั้นคัดลอกโค้ดนี้ลงไปครับ

# กำหนดกลุ่มของ Backend Servers
upstream backend_servers {
    # อัลกอริทึม Load Balancing (ค่าเริ่มต้นคือ Round Robin)
    # least_conn; # ตัวอย่างการใช้อัลกอริทึม Least Connections

    server 192.168.1.101:8080; # Backend Server 1
    server 192.168.1.102:8080; # Backend Server 2
}

# กำหนด Virtual Host สำหรับโดเมนของคุณ
server {
    listen 80; # ฟังการเชื่อมต่อ HTTP บนพอร์ต 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 จริงของไคลเอ็นต์
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # ส่ง Chain ของ IP
        proxy_set_header X-Forwarded-Proto $scheme; # ส่ง Protocol (http/https)
    }
}

อย่าลืมเปลี่ยน yourdomain.com และ www.yourdomain.com เป็นชื่อโดเมนของคุณจริง ๆ นะครับ และเปลี่ยน IP Address ของ Backend Servers ให้ถูกต้องด้วยครับ

การเลือกอัลกอริทึม Load Balancing

คุณสามารถเลือกอัลกอริทึม Load Balancing ได้โดยการเพิ่ม directive ในบล็อก upstream ครับ

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

upstream backend_servers {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

ตัวอย่าง Least Connections:

upstream backend_servers {
    least_conn;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

ตัวอย่าง IP Hash:

upstream backend_servers {
    ip_hash;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

การตั้งค่า Weight และ Max Fails

คุณสามารถกำหนดน้ำหนัก (weight) ให้กับแต่ละเซิร์ฟเวอร์ และกำหนดเงื่อนไขการตรวจสอบความล้มเหลว (max_fails, fail_timeout) ได้ครับ

  • weight: กำหนดน้ำหนักการกระจายโหลด เซิร์ฟเวอร์ที่มี Weight มากกว่าจะได้รับคำขอมากกว่า (ค่าเริ่มต้นคือ 1)
  • max_fails: จำนวนครั้งที่การเชื่อมต่อกับเซิร์ฟเวอร์ Backend ล้มเหลว ก่อนที่ Nginx จะพิจารณาว่าเซิร์ฟเวอร์นั้นไม่พร้อมใช้งาน (ค่าเริ่มต้นคือ 1)
  • fail_timeout: ระยะเวลา (เป็นวินาที) ที่ Nginx จะถือว่าเซิร์ฟเวอร์ไม่พร้อมใช้งานหลังจากที่ล้มเหลวตาม max_fails ครบแล้ว (ค่าเริ่มต้นคือ 10 วินาที) หลังจากนั้น Nginx จะลองส่งคำขอไปใหม่เพื่อตรวจสอบว่ากลับมาทำงานได้หรือยังครับ
  • down: ทำเครื่องหมายว่าเซิร์ฟเวอร์นี้ไม่พร้อมใช้งานชั่วคราว
  • backup: กำหนดให้เซิร์ฟเวอร์นี้เป็นเซิร์ฟเวอร์สำรอง จะถูกใช้ก็ต่อเมื่อเซิร์ฟเวอร์หลักทั้งหมดไม่พร้อมใช้งาน
upstream backend_servers {
    least_conn; # ใช้อัลกอริทึม Least Connections

    server 192.168.1.101:8080 weight=3 max_fails=3 fail_timeout=30s; # เซิร์ฟเวอร์นี้ได้โหลด 3 เท่า, ตรวจสอบ 3 ครั้ง, พัก 30 วิ
    server 192.168.1.102:8080 weight=1 max_fails=2 fail_timeout=15s; # เซิร์ฟเวอร์นี้ได้โหลด 1 เท่า, ตรวจสอบ 2 ครั้ง, พัก 15 วิ
    server 192.168.1.103:8080 backup; # เซิร์ฟเวอร์สำรอง จะใช้เมื่อ 2 ตัวแรกใช้ไม่ได้
    # server 192.168.1.104:8080 down; # ปิดการใช้งานเซิร์ฟเวอร์นี้ชั่วคราว
}

การตั้งค่า Health Checks (Basic)

Nginx Open Source มีเพียง Passive Health Checks ซึ่งหมายถึง Nginx จะพิจารณาว่าเซิร์ฟเวอร์ Backend ล้มเหลวก็ต่อเมื่อมันพยายามส่งคำขอไปแล้วเกิดข้อผิดพลาด เช่น ไม่สามารถเชื่อมต่อได้ หรือได้รับโค้ดสถานะ 5xx ครับ (Nginx Plus มี Active Health Checks ที่สามารถส่งคำขอตรวจสอบเป็นระยะ ๆ ได้)

การตั้งค่า max_fails และ fail_timeout ในบล็อก upstream เป็นการกำหนดค่า Health Checks แบบ Passive แล้วครับ

อ่านเพิ่มเติมเกี่ยวกับการจัดการเซิร์ฟเวอร์ Backend ใน Nginx

การตั้งค่า SSL/TLS (HTTPS)

การใช้งาน HTTPS เป็นสิ่งจำเป็นในปัจจุบันครับ เราควรตั้งค่า SSL/TLS บน Nginx Reverse Proxy ครับ

1. ขอใบรับรอง SSL/TLS: แนะนำให้ใช้ Let’s Encrypt ผ่าน Certbot ซึ่งเป็นวิธีที่ง่ายและฟรีครับ

สำหรับ Ubuntu/Debian:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

สำหรับ CentOS/Rocky Linux:

sudo yum install certbot python3-certbot-nginx -y
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot จะจัดการการขอใบรับรองและแก้ไขไฟล์คอนฟิกูเรชัน Nginx ให้คุณโดยอัตโนมัติครับ

2. แก้ไขไฟล์คอนฟิกูเรชัน Nginx: หาก Certbot ไม่ได้แก้ไขให้ หรือคุณต้องการตั้งค่าด้วยตนเอง คุณจะต้องเพิ่มบล็อก server สำหรับ HTTPS ครับ

# กำหนดกลุ่มของ Backend Servers (เหมือนเดิม)
upstream backend_servers {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

# บล็อกสำหรับ HTTP (จะ Redirect ไปยัง HTTPS)
server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri; # Redirect HTTP ไป HTTPS
}

# บล็อกสำหรับ HTTPS
server {
    listen 443 ssl; # ฟังการเชื่อมต่อ HTTPS บนพอร์ต 443
    server_name yourdomain.com www.yourdomain.com;

    # ตำแหน่งของใบรับรอง SSL/TLS (Certbot จะสร้างให้)
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    # การตั้งค่า SSL/TLS เพิ่มเติมเพื่อความปลอดภัย
    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;

    location / {
        proxy_pass http://backend_servers; # ส่งต่อคำขอไปยัง 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; # ระบุว่าคำขอมาจาก HTTPS
    }
}

ขั้นตอนที่ 4: ทดสอบการตั้งค่า Nginx

หลังจากที่คุณแก้ไขไฟล์คอนฟิกูเรชัน Nginx แล้ว สิ่งสำคัญคือต้องทดสอบ Syntax ของไฟล์ก่อนที่จะ Reload หรือ Restart Nginx ครับ เพื่อป้องกันไม่ให้ Nginx หยุดทำงานเพราะการตั้งค่าผิดพลาดครับ

sudo nginx -t

หากไม่มีข้อผิดพลาด คุณจะเห็นข้อความประมาณว่า nginx: configuration file /etc/nginx/nginx.conf syntax is ok และ nginx: configuration file /etc/nginx/nginx.conf test is successful ครับ

จากนั้นให้ Reload หรือ Restart Nginx เพื่อให้การตั้งค่าใหม่มีผลครับ

sudo systemctl reload nginx # แนะนำให้ใช้ reload เพื่อลด downtime
# หรือ sudo systemctl restart nginx # หากมีการเปลี่ยนแปลงโครงสร้างที่ใหญ่

ขั้นตอนที่ 5: ทดสอบการทำงานของ Load Balancing

ถึงเวลาทดสอบการทำงานของ Load Balancing แล้วครับ

1. ทดสอบผ่านเว็บเบราว์เซอร์:
เปิดเว็บเบราว์เซอร์ของคุณแล้วเข้าถึง http://yourdomain.com หรือ https://yourdomain.com ครับ คุณควรจะเห็นข้อความ “Hello from Backend Server 1!” หรือ “Hello from Backend Server 2!” สลับกันไปเมื่อคุณกด Refresh หลาย ๆ ครั้งครับ (หากใช้ Round Robin หรือ Least Conn) หากใช้ IP Hash คุณจะเห็นข้อความจากเซิร์ฟเวอร์เดิมเสมอครับ

2. ทดสอบด้วยคำสั่ง curl:
คุณสามารถใช้คำสั่ง curl เพื่อทดสอบจาก Command Line ได้ครับ

for i in {1..10}; do curl http://yourdomain.com; done

คุณควรจะเห็น Output จาก Backend Servers ทั้งสองสลับกันไปครับ

Hello from Backend Server 1!This is the application running on 192.168.1.101.
Hello from Backend Server 2!This is the application running on 192.168.1.102.
Hello from Backend Server 1!This is the application running on 192.168.1.101.
...

3. ทดสอบ Failover:
ลองหยุดเว็บแอปพลิเคชันบน Backend Server ตัวใดตัวหนึ่ง (เช่น Server 1) แล้วลองเข้าถึงโดเมนของคุณใหม่ครับ คุณควรจะยังคงสามารถเข้าถึงเว็บไซต์ได้ แต่คราวนี้จะได้รับ Output จาก Backend Server อีกตัวหนึ่งเท่านั้นครับ (Server 2) หลังจากผ่านไปตามค่า fail_timeout ที่ตั้งไว้ Nginx จะพิจารณาว่า Server 1 ล้มเหลวและจะส่งคำขอไปยัง Server 2 เท่านั้นครับ เมื่อคุณเริ่ม Server 1 กลับมา Nginx ก็จะค่อย ๆ ส่งคำขอไปให้ใหม่ครับ

การตั้งค่าขั้นสูงและ Best Practices

เมื่อคุณได้ตั้งค่า Nginx Reverse Proxy Load Balancing พื้นฐานสำเร็จแล้ว ต่อไปเป็นการเรียนรู้การตั้งค่าขั้นสูงและแนวทางปฏิบัติที่ดีที่สุด (Best Practices) เพื่อเพิ่มประสิทธิภาพ ความเสถียร และความสามารถในการจัดการให้กับระบบของคุณครับ

Session Persistence (Sticky Sessions)

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

  • IP Hash:

    อย่างที่เราได้กล่าวไปแล้ว ip_hash เป็นวิธีที่ง่ายที่สุดในการทำ Session Persistence ใน Nginx Open Source ครับ

    upstream backend_servers {
            ip_hash;
            server 192.168.1.101:8080;
            server 192.168.1.102:8080;
        }

    ข้อควรระวัง: หากผู้ใช้จำนวนมากมาจาก IP เดียวกัน (เช่น อยู่ในเครือข่ายองค์กรเดียวกัน) อาจทำให้โหลดไม่สมดุลได้ครับ

  • Cookie-based Persistence (ต้องใช้ Nginx Plus หรือ Module ภายนอก)

    Nginx Open Source ไม่มีฟังก์ชัน Cookie-based Session Persistence มาให้โดยตรงครับ หากต้องการใช้ คุณอาจต้องพิจารณาใช้ Nginx Plus หรือติดตั้ง Module ภายนอกเช่น nginx-sticky-module ครับ ซึ่งจะซับซ้อนขึ้นมาอีกระดับครับ

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

Proxy Caching

Nginx สามารถทำหน้าที่เป็น Cache Server ได้ด้วยครับ โดยการเก็บสำเนาของ Response จาก Backend Server ไว้ชั่วคราว เมื่อคำขอเดิมเข้ามาอีกครั้ง Nginx ก็จะส่งข้อมูลจาก Cache ไปให้ไคลเอ็นต์โดยตรง โดยไม่ต้องส่งคำขอไป Backend Server ซ้ำ ทำให้ลดภาระ Backend และเพิ่มความเร็วในการตอบสนองได้อย่างมหาศาลครับ

http {
    # ...
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g
                     inactive=60m use_temp_path=off; # ตั้งค่า Path, ขนาด Cache Key, ขนาดรวม, ระยะเวลาไม่ใช้งาน

    server {
        # ...
        location / {
            proxy_cache my_cache; # เปิดใช้งาน Cache
            proxy_cache_valid 200 302 10m; # Cache 200, 302 เป็นเวลา 10 นาที
            proxy_cache_valid 404 1m; # Cache 404 เป็นเวลา 1 นาที
            proxy_cache_min_uses 1; # Cache หากมีการเรียกใช้มากกว่า 1 ครั้ง
            proxy_cache_bypass $http_pragma $http_authorization; # ไม่ Cache หากมี header เหล่านี้
            add_header X-Proxy-Cache $upstream_cache_status; # เพิ่ม header เพื่อดูสถานะ Cache

            proxy_pass http://backend_servers;
            # ... (proxy_set_header ต่างๆ)
        }
    }
}

อย่าลืมสร้างไดเรกทอรีสำหรับ Cache และกำหนดสิทธิ์ให้ Nginx สามารถเขียนได้ด้วยนะครับ เช่น sudo mkdir -p /var/cache/nginx && sudo chown www-data:www-data /var/cache/nginx (สำหรับ Ubuntu)

Proxy Buffering

Proxy Buffering คือการที่ Nginx จะบัฟเฟอร์ (เก็บพัก) Response จาก Backend Server ไว้ชั่วคราวในพื้นที่จัดเก็บของ Nginx ก่อนที่จะส่งต่อไปให้ไคลเอ็นต์ครับ

  • เปิดใช้งาน (ค่าเริ่มต้น): Nginx จะอ่าน Response ทั้งหมดจาก Backend จนเสร็จสิ้น แล้วค่อยส่งให้ไคลเอ็นต์ ทำให้ Backend ปล่อย Connection ได้เร็วขึ้น
  • ปิดใช้งาน (proxy_buffering off;): Nginx จะส่ง Response จาก Backend ไปให้ไคลเอ็นต์ทันทีที่ได้รับแต่ละส่วน เหมาะสำหรับแอปพลิเคชันที่ต้องการ Real-time Streaming หรือ Long Polling

โดยทั่วไปควรเปิดใช้งาน Proxy Buffering ไว้ครับ เพื่อเพิ่มประสิทธิภาพและลดภาระของ Backend ครับ

location / {
    proxy_buffering on; # ค่าเริ่มต้น
    proxy_buffers 8 16k; # จำนวนและขนาดของ Buffer
    proxy_buffer_size 8k; # ขนาด Buffer สำหรับส่วนหัวแรกของ Response
    # ...
}

Timeouts

การตั้งค่า Timeouts อย่างเหมาะสมเป็นสิ่งสำคัญเพื่อป้องกันไม่ให้ Nginx หรือไคลเอ็นต์ค้างรอ Backend Server ที่ตอบสนองช้าหรือล่มไปนานเกินไปครับ

  • proxy_connect_timeout 60s;: ระยะเวลาที่ Nginx จะรอเพื่อสร้างการเชื่อมต่อไปยัง Backend Server
  • proxy_send_timeout 60s;: ระยะเวลาที่ Nginx จะรอให้ Backend Server ตอบสนองหลังจากส่งคำขอไปแล้ว
  • proxy_read_timeout 60s;: ระยะเวลาที่ Nginx จะรอให้ Backend Server ส่งข้อมูลกลับมาหลังจากได้รับ Response Header แล้ว
location / {
    proxy_connect_timeout 5s; # เชื่อมต่อไป Backend ไม่เกิน 5 วินาที
    proxy_send_timeout 10s;   # ส่งข้อมูลไป Backend ไม่เกิน 10 วินาที
    proxy_read_timeout 10s;   # อ่านข้อมูลจาก Backend ไม่เกิน 10 วินาที
    # ...
}

ค่าเหล่านี้ควรปรับตามลักษณะของแอปพลิเคชันของคุณครับ หากแอปพลิเคชันมีการประมวลผลที่ใช้เวลานาน อาจต้องเพิ่มค่าเหล่านี้ครับ

Error Handling และ Failover

เมื่อ Backend Server ล้มเหลว Nginx ควรตอบสนองอย่างไร? เราสามารถกำหนดหน้า Error Page ที่เป็นมิตรกับผู้ใช้งานได้ครับ

server {
    # ...
    error_page 500 502 503 504 /50x.html; # เมื่อเกิด Error เหล่านี้ ให้แสดง 50x.html
    location = /50x.html {
        root /usr/share/nginx/html; # ตำแหน่งของไฟล์ 50x.html
        internal; # บอก Nginx ว่าไฟล์นี้สามารถเข้าถึงได้ภายในเท่านั้น
    }

    location / {
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504; # เมื่อเกิด Error เหล่านี้ ให้ลองส่งคำขอไป Backend ตัวถัดไป
        proxy_next_upstream_tries 3; # ลองกี่ครั้ง
        proxy_next_upstream_timeout 10s; # เวลาที่ใช้ในการลองใหม่
        proxy_pass http://backend_servers;
        # ...
    }
}

คุณสามารถสร้างไฟล์ /usr/share/nginx/html/50x.html ของคุณเองได้ เพื่อให้มีหน้าตาที่สวยงามและเป็นประโยชน์ต่อผู้ใช้งานครับ

Monitoring และ Logging

การตรวจสอบสถานะและบันทึก Log เป็นสิ่งสำคัญในการบริหารจัดการและแก้ไขปัญหาครับ

  • Access Log และ Error Log:

    Nginx จะบันทึก Log การเข้าถึงและข้อผิดพลาดไว้ตามค่าเริ่มต้นครับ

    http {
            # ...
            log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                            '$status $body_bytes_sent "$http_referer" '
                            '"$http_user_agent" "$http_x_forwarded_for"';

            access_log /var/log/nginx/access.log main;
            error_log /var/log/nginx/error.log warn;
            # ...
        }

    คุณสามารถใช้เครื่องมือ Log Analyzer เช่น ELK Stack (Elasticsearch, Logstash, Kibana) หรือ Grafana Loki เพื่อวิเคราะห์ Log ได้อย่างมีประสิทธิภาพครับ

  • Nginx Stub Status Module:

    เป็น Module พื้นฐานที่มาพร้อม Nginx Open Source ที่แสดงข้อมูลสถานะการทำงานของ Nginx เช่น จำนวน Active Connections, Connections ที่รับ/ส่ง/กำลังรอครับ

    server {
            listen 80;
            server_name yourdomain.com www.yourdomain.com; # หรือจะสร้าง Subdomain เฉพาะก็ได้

            location /nginx_status {
                stub_status on;
                allow 127.0.0.1; # อนุญาตเฉพาะ IP ที่ระบุ
                deny all; # ปฏิเสธการเข้าถึงจากที่อื่น
            }
            # ...
        }

    หลังจาก Reload Nginx คุณสามารถเข้าถึง http://yourdomain.com/nginx_status (จาก IP ที่อนุญาต) เพื่อดูสถานะได้ครับ

การอัปเดตและบำรุงรักษา

ควรหมั่นอัปเดต Nginx และระบบปฏิบัติการเป็นประจำ เพื่อรับแพตช์ความปลอดภัยและฟีเจอร์ใหม่ ๆ ครับ

  • Rolling Updates: หากมี Backend Servers หลายตัว คุณสามารถอัปเดตหรือบำรุงรักษาทีละตัวได้ โดยใช้ down directive ใน Nginx เพื่อนำเซิร์ฟเวอร์นั้นออกจากกลุ่มชั่วคราว แล้วค่อยนำกลับเข้าสู่ระบบเมื่อการบำรุงรักษาเสร็จสิ้นครับ
  • Backup Configuration: ควรสำรองไฟล์คอนฟิกูเรชัน Nginx เสมอ ก่อนทำการเปลี่ยนแปลงใด ๆ ครับ

ปัญหาที่พบบ่อยและการแก้ไข (Troubleshooting)

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

Nginx ไม่เริ่มทำงาน

หาก Nginx ไม่สามารถเริ่มทำงานหรือ Reload ได้ มักเกิดจากข้อผิดพลาดในไฟล์คอนฟิกูเรชันครับ

  • สาเหตุ: Syntax Error ในไฟล์ .conf, พอร์ตที่ Nginx ต้องการใช้ถูกใช้งานอยู่แล้ว, ไฟล์ไม่มีสิทธิ์ที่ถูกต้อง
  • การแก้ไข:

    • ใช้คำสั่ง sudo nginx -t เพื่อตรวจสอบ Syntax ของไฟล์คอนฟิกูเรชัน Nginx ครับ คำสั่งนี้จะระบุบรรทัดและประเภทของข้อผิดพลาดครับ
    • ตรวจสอบ Log ของ Nginx: sudo journalctl -xeu nginx หรือ sudo tail -f /var/log/nginx/error.log เพื่อดูข้อความผิดพลาดที่ละเอียดขึ้นครับ
    • ตรวจสอบว่าพอร์ต 80 และ 443 (หรือพอร์ตอื่น ๆ ที่คุณกำหนดให้ Nginx ฟัง) ไม่ได้ถูกใช้งานโดยโปรเซสอื่น ๆ ด้วยคำสั่ง sudo ss -tulpn | grep -E "80|443" ครับ
    • ตรวจสอบสิทธิ์ของไฟล์คอนฟิกูเรชันและไดเรกทอรี /etc/nginx/ ให้ Nginx สามารถอ่านได้ครับ

ไม่สามารถเข้าถึง Backend Server ได้

หาก Nginx ทำงานได้ แต่ไม่สามารถส่งคำขอไปยัง Backend Server ได้ มักเกิดจากปัญหาการเชื่อมต่อเครือข่ายหรือการตั้งค่าพอร์ตครับ

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