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

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

March 17, 2026
0 Views

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

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

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

ทำความเข้าใจพื้นฐาน Nginx Reverse Proxy และ Load Balancing

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

Reverse Proxy คืออะไร?

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

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

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

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

  • เพิ่มความปลอดภัย: ซ่อน IP address และโครงสร้างของ backend servers ไม่ให้ไคลเอนต์ภายนอกเข้าถึงโดยตรง ช่วยป้องกันการโจมตีบางประเภทได้ครับ
  • จัดการ SSL/TLS Termination: Reverse Proxy สามารถรับผิดชอบการถอดรหัสและเข้ารหัส SSL/TLS ทั้งหมด ทำให้ backend servers ไม่ต้องเสียทรัพยากรตรงส่วนนี้ไป
  • Caching: สามารถเก็บข้อมูลที่ถูกเรียกใช้บ่อยไว้ในแคช เพื่อตอบสนองคำขอได้อย่างรวดเร็ว โดยไม่ต้องไปดึงข้อมูลจาก backend server ซ้ำๆ ครับ
  • การบีบอัดข้อมูล: ลดขนาดข้อมูลที่ส่งให้ไคลเอนต์ ทำให้โหลดหน้าเว็บได้เร็วขึ้น
  • การ Rewrite URL: สามารถปรับแต่ง URL ก่อนส่งไปยัง backend หรือก่อนส่งกลับไปยังไคลเอนต์ได้

Load Balancing คืออะไร?

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

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

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

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

Nginx กับบทบาท Reverse Proxy และ Load Balancer

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

Nginx ไม่ได้เป็นแค่เว็บเซิร์ฟเวอร์เท่านั้น แต่ยังถูกออกแบบมาให้เป็น:

1. Reverse Proxy ที่ทรงพลัง:
Nginx สามารถทำหน้าที่เป็น Reverse Proxy ได้อย่างยอดเยี่ยม ด้วยความสามารถในการจัดการ SSL Termination, Caching, Compression และการจัดการ Header ต่างๆ ได้อย่างละเอียด ทำให้เป็นทางเลือกที่เหมาะสำหรับวางอยู่หน้า Application Servers หรือ Web Servers อื่นๆ เช่น Apache, Node.js, Python, Java เป็นต้นครับ

2. Load Balancer ที่ยืดหยุ่น:
Nginx มีโมดูล Load Balancing ในตัวที่รองรับอัลกอริทึมหลายแบบ ไม่ว่าจะเป็น Round Robin, Least Connected, IP Hash และอื่นๆ อีกมากมาย ทำให้สามารถกระจายทราฟฟิกไปยัง Backend Servers ได้อย่างมีประสิทธิภาพและชาญฉลาด ช่วยให้ระบบมีความทนทานต่อความผิดพลาด (Fault Tolerance) และสามารถปรับขนาดได้ตามความต้องการครับ

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

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

เมื่อเราเข้าใจหลักการทำงานแล้ว มาดูกันว่าการนำ Nginx Reverse Proxy และ Load Balancing มาใช้ร่วมกันจะมอบประโยชน์อะไรให้กับระบบของคุณบ้างครับ

เพิ่มประสิทธิภาพและความเร็ว

  • ลดภาระของ Backend Servers: Nginx สามารถจัดการกับการเชื่อมต่อจำนวนมากได้อย่างมีประสิทธิภาพสูง และยังสามารถทำ Caching, Gzip Compression และ SSL Termination ได้เอง ทำให้ Backend Servers มีทรัพยากรมากขึ้นในการประมวลผล Logic ของแอปพลิเคชันจริงๆ ครับ
  • การตอบสนองที่รวดเร็ว: ด้วยการกระจายโหลดอย่างสม่ำเสมอ ผู้ใช้จะได้รับการตอบสนองจากเซิร์ฟเวอร์ที่ว่างที่สุด ทำให้ลด Latency และเพิ่มความเร็วในการโหลดหน้าเว็บครับ

ความพร้อมใช้งานสูง (High Availability)

  • ป้องกัน Single Point of Failure: หาก Backend Server ตัวใดตัวหนึ่งเกิดล่ม Nginx Load Balancer จะตรวจจับได้และหยุดส่งทราฟฟิกไปยังเซิร์ฟเวอร์นั้นโดยอัตโนมัติ ทำให้คำขอของผู้ใช้ยังคงถูกส่งไปยังเซิร์ฟเวอร์ที่ทำงานอยู่ได้ครับ
  • การบำรุงรักษาแบบไร้รอยต่อ: คุณสามารถถอด Backend Server ออกจากกลุ่มเพื่อบำรุงรักษา อัปเกรด หรือปรับปรุงโดยไม่ต้องหยุดบริการทั้งหมด ผู้ใช้งานจะไม่รู้สึกถึงการหยุดชะงักใดๆ ครับ

ความสามารถในการปรับขนาด (Scalability)

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

เพิ่มความปลอดภัย

  • ซ่อน Backend Servers: Nginx ทำหน้าที่เป็นด่านหน้า ทำให้ IP Address และข้อมูลภายในของ Backend Servers ถูกซ่อนไว้จากโลกภายนอก ลดความเสี่ยงจากการโจมตีโดยตรงครับ
  • กรองคำขอที่ไม่พึงประสงค์: สามารถตั้งค่า Nginx เพื่อบล็อกคำขอจาก IP Address ที่น่าสงสัย หรือจำกัดอัตราการร้องขอ (Rate Limiting) เพื่อป้องกันการโจมตีแบบ DDoS หรือ Brute-force ได้ครับ

จัดการ SSL/TLS ได้อย่างง่ายดาย

  • SSL/TLS Termination Centralization: คุณสามารถติดตั้งและจัดการ SSL/TLS Certificate ทั้งหมดไว้ที่ Nginx Reverse Proxy เพียงจุดเดียว ทำให้กระบวนการจัดการง่ายขึ้น และ Backend Servers ไม่ต้องรับภาระในการเข้ารหัส/ถอดรหัสข้อมูลครับ
  • รองรับ Let’s Encrypt: Nginx ทำงานร่วมกับ Let’s Encrypt ได้อย่างราบรื่น ทำให้การขอและต่ออายุ SSL Certificate เป็นเรื่องง่ายและฟรีครับ

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

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

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

ข้อกำหนดเบื้องต้น

เพื่อให้บทความนี้สามารถนำไปปฏิบัติได้จริง คุณควรมีสิ่งเหล่านี้ครับ:

  • เซิร์ฟเวอร์ Linux: อย่างน้อย 2 เครื่อง (VMs หรือ Physical Servers)
    • 1 เครื่องสำหรับ Nginx Reverse Proxy / Load Balancer (เรียกว่า nginx-lb)
    • อย่างน้อย 1-2 เครื่องสำหรับ Backend Web/Application Servers (เรียกว่า backend-1, backend-2) ซึ่งอาจเป็น Apache, Nginx, Node.js, PHP-FPM หรืออะไรก็ได้ที่รันบริการ HTTP/HTTPS ครับ
  • ระบบปฏิบัติการ: แนะนำ Ubuntu Server (เวอร์ชัน LTS) หรือ CentOS/RHEL เพื่อความเข้ากันได้ของคำสั่งในตัวอย่างครับ
  • สิทธิ์ผู้ดูแลระบบ (Root Privileges): หรือผู้ใช้ที่มีสิทธิ์ sudo บนเซิร์ฟเวอร์ทั้งหมด
  • ความรู้พื้นฐานเกี่ยวกับ Linux Command Line: การใช้คำสั่งพื้นฐาน, การแก้ไขไฟล์
  • เครือข่าย: ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ทั้งหมดสามารถสื่อสารกันได้ผ่านเครือข่ายภายใน (หรือภายนอก ขึ้นอยู่กับการตั้งค่า) และพอร์ตที่จำเป็น (เช่น 80, 443) เปิดอยู่บน Firewall ครับ

ในตัวอย่างนี้ เราจะสมมติว่าเรามีเซิร์ฟเวอร์ดังนี้ครับ:

  • Nginx Load Balancer (nginx-lb): IP 192.168.1.100
  • Backend Server 1 (backend-1): IP 192.168.1.101, รันบริการบนพอร์ต 80 (เช่น Nginx หรือ Apache)
  • Backend Server 2 (backend-2): IP 192.168.1.102, รันบริการบนพอร์ต 80 (เช่น Nginx หรือ Apache)

การติดตั้ง Nginx

ก่อนอื่น เราต้องติดตั้ง Nginx บนเซิร์ฟเวอร์ที่จะทำหน้าที่เป็น Load Balancer (nginx-lb) ก่อนนะครับ

สำหรับ Ubuntu/Debian:

sudo apt update
sudo apt install nginx -y

สำหรับ CentOS/RHEL:

sudo yum install epel-release -y
sudo yum install nginx -y

หลังจากติดตั้งเสร็จสิ้น Nginx ควรจะเริ่มทำงานโดยอัตโนมัติครับ คุณสามารถตรวจสอบสถานะได้ด้วยคำสั่ง:

sudo systemctl status nginx

หาก Nginx ไม่ทำงาน คุณสามารถเริ่มบริการได้ด้วย:

sudo systemctl start nginx

และเปิดใช้งานให้ Nginx เริ่มทำงานอัตโนมัติเมื่อบูตเครื่อง:

sudo systemctl enable nginx

การปรับ Firewall:
หากคุณใช้ Firewall (เช่น UFW บน Ubuntu หรือ firewalld บน CentOS) คุณต้องอนุญาตให้ Nginx รับการเชื่อมต่อบนพอร์ต 80 (HTTP) และ 443 (HTTPS) ครับ

สำหรับ UFW (Ubuntu):

sudo ufw allow 'Nginx HTTP'
sudo ufw allow 'Nginx HTTPS'
sudo ufw reload

สำหรับ firewalld (CentOS):

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

เมื่อ Nginx ติดตั้งและ Firewall ถูกตั้งค่าเรียบร้อยแล้ว คุณควรจะสามารถเข้าถึงหน้าต้อนรับของ Nginx ได้โดยการพิมพ์ IP Address ของ nginx-lb ในเบราว์เซอร์ครับ (เช่น http://192.168.1.100)

การตั้งค่า Nginx Reverse Proxy เบื้องต้น

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

โครงสร้างไฟล์คอนฟิก Nginx

ไฟล์คอนฟิกหลักของ Nginx มักจะอยู่ที่ /etc/nginx/nginx.conf ครับ ไฟล์นี้จะรวม (include) ไฟล์คอนฟิกอื่นๆ ที่อยู่ในไดเรกทอรี /etc/nginx/conf.d/ หรือ /etc/nginx/sites-enabled/ เพื่อความเป็นระเบียบ

  • /etc/nginx/nginx.conf: ไฟล์คอนฟิกหลัก กำหนดค่า global เช่น worker processes, logging, และรวมไฟล์คอนฟิกย่อย
  • /etc/nginx/sites-available/: ไดเรกทอรีสำหรับเก็บไฟล์คอนฟิกของแต่ละเว็บไซต์หรือบริการ ที่ยังไม่ได้เปิดใช้งาน
  • /etc/nginx/sites-enabled/: ไดเรกทอรีสำหรับเก็บ Symlink (Symbolic Link) ไปยังไฟล์คอนฟิกใน sites-available เพื่อเปิดใช้งาน
  • /etc/nginx/conf.d/: อีกหนึ่งไดเรกทอรีที่นิยมใช้เก็บไฟล์คอนฟิกย่อยๆ ที่จะถูกรวมเข้ามาใน nginx.conf

ในบทความนี้ เราจะใช้ /etc/nginx/conf.d/ เพื่อสร้างไฟล์คอนฟิกใหม่ครับ ซึ่งเป็นวิธีที่ง่ายและเป็นระเบียบสำหรับโปรเจกต์ส่วนใหญ่

ตัวอย่างคอนฟิก Reverse Proxy

เราจะสร้างไฟล์คอนฟิกใหม่ชื่อ /etc/nginx/conf.d/mywebapp.conf เพื่อให้ Nginx ส่งต่อคำขอทั้งหมดไปยัง Backend Server เพียงเครื่องเดียวก่อนครับ

เปิดไฟล์ด้วย Text Editor เช่น nano หรือ vim:

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

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

# /etc/nginx/conf.d/mywebapp.conf

server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com www.your_domain.com 192.168.1.100; # เปลี่ยนเป็นโดเมนหรือ IP ของ Nginx Load Balancer ของคุณ

    location / {
        proxy_pass http://192.168.1.101; # IP ของ Backend Server ของคุณ (backend-1)

        # ตั้งค่า Header เพื่อให้ 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 $scheme;

        # ตั้งค่า Timeout (ไม่จำเป็นต้องปรับถ้าไม่มีปัญหา)
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # ปิดการแคชของ Nginx ในโหมด Reverse Proxy เบื้องต้น
        proxy_buffering off;
    }

    # เพิ่ม Block สำหรับจัดการ Error Pages (ถ้าต้องการ)
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html; # หรือไดเรกทอรีที่คุณเก็บไฟล์ Error Page
    }
}

คำอธิบายส่วนประกอบหลัก:

  • listen 80;: Nginx จะรับฟังการเชื่อมต่อบนพอร์ต 80 (HTTP) ครับ
  • server_name your_domain.com www.your_domain.com 192.168.1.100;: กำหนดชื่อโดเมนหรือ IP Address ที่ Nginx จะตอบสนองสำหรับ Server Block นี้ ควรเปลี่ยนเป็นโดเมนหรือ IP Address จริงของ Nginx Load Balancer ของคุณครับ
  • location / { ... }: เป็น Block ที่บอก Nginx ว่าจะจัดการกับคำขอที่เข้ามาอย่างไร ในที่นี้คือคำขอทั้งหมดที่เข้ามา (/ คือ Path Root)
  • proxy_pass http://192.168.1.101;: นี่คือคำสั่งหลักที่บอก Nginx ให้ส่งต่อคำขอทั้งหมดไปยัง Backend Server ที่มี IP Address 192.168.1.101 บนพอร์ต 80 ครับ
  • proxy_set_header ...: บรรทัดเหล่านี้มีความสำคัญอย่างยิ่งครับ เพราะ Nginx ทำหน้าที่เป็นตัวกลาง ทำให้ Backend Server ไม่เห็น IP Address ของผู้ใช้งานจริงโดยตรง Header เหล่านี้จะช่วยส่งข้อมูลของผู้ใช้งานจริง (เช่น X-Real-IP, X-Forwarded-For) และชื่อโฮสต์ที่ผู้ใช้เรียก (Host) ไปยัง Backend Server เพื่อให้ Backend Server สามารถบันทึก Log หรือประมวลผลคำขอได้อย่างถูกต้องครับ
  • proxy_buffering off;: ในบางกรณี การปิดบัฟเฟอร์จะช่วยให้ข้อมูลถูกส่งผ่านไปยัง Backend ได้เร็วขึ้น โดยเฉพาะกับแอปพลิเคชันที่ต้องการ Real-time หรือ Long Polling ครับ

การทดสอบและเปิดใช้งาน

หลังจากบันทึกไฟล์คอนฟิกแล้ว สิ่งสำคัญคือต้องทดสอบ Syntax ของ Nginx ก่อนที่จะโหลดการตั้งค่าใหม่ครับ

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:

sudo systemctl reload nginx

ตอนนี้ Nginx ของคุณควรจะทำหน้าที่เป็น Reverse Proxy แล้วครับ ลองเข้าถึง IP Address หรือโดเมนของ nginx-lb ในเบราว์เซอร์ (เช่น http://192.168.1.100) คุณควรจะเห็นเนื้อหาที่มาจาก backend-1 ครับ

หากมีปัญหา ลองตรวจสอบไฟล์ Log ของ Nginx ที่ /var/log/nginx/error.log เพื่อหาสาเหตุครับ

การตั้งค่า Nginx Load Balancing

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

แนวคิด Upstream Block

ใน Nginx การกำหนดกลุ่มของ Backend Servers ที่จะทำ Load Balancing จะทำในบล็อกที่เรียกว่า upstream ครับ บล็อกนี้จะถูกวางไว้ในไฟล์คอนฟิกหลัก nginx.conf หรือในไฟล์คอนฟิกย่อยที่ถูก include เข้ามา เช่น /etc/nginx/conf.d/mywebapp.conf ที่เราสร้างไปก่อนหน้านี้ครับ

ภายในบล็อก upstream เราจะระบุ IP Address หรือชื่อโฮสต์ของ Backend Servers แต่ละเครื่อง พร้อมด้วยพอร์ตที่บริการกำลังทำงานอยู่ครับ

ตัวอย่าง upstream block:

# /etc/nginx/conf.d/mywebapp.conf

upstream my_backends {
    server 192.168.1.101:80; # Backend Server 1
    server 192.168.1.102:80; # Backend Server 2
    # server 192.168.1.103:80; # สามารถเพิ่ม Backend Servers ได้อีก
}

server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com www.your_domain.com 192.168.1.100;

    location / {
        proxy_pass http://my_backends; # อ้างอิงถึงชื่อ upstream block ที่เราสร้างไว้

        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;

        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        proxy_buffering off;
    }
}

ในตัวอย่างนี้ เราได้สร้าง upstream block ชื่อ my_backends และกำหนด Backend Servers สองเครื่องครับ จากนั้นใน location / block เราเปลี่ยน proxy_pass จาก IP Address โดยตรงไปเป็นชื่อของ upstream block แทน proxy_pass http://my_backends;

พารามิเตอร์เพิ่มเติมสำหรับ server ใน upstream block:

  • weight=NUMBER: กำหนดน้ำหนักให้กับเซิร์ฟเวอร์ ยิ่งมีน้ำหนักมากเท่าไหร่ ก็ยิ่งได้รับคำขอมากขึ้นเท่านั้น (ค่าเริ่มต้นคือ 1)
  • max_fails=NUMBER: จำนวนครั้งที่เซิร์ฟเวอร์ล้มเหลวในการตอบสนองคำขอในช่วง fail_timeout ก่อนที่จะถูกพิจารณาว่า “down” (ค่าเริ่มต้นคือ 1)
  • fail_timeout=TIME: ระยะเวลาที่เซิร์ฟเวอร์จะถูกพิจารณาว่า “down” หลังจาก max_fails ครั้ง และเป็นระยะเวลาที่ Nginx จะไม่ส่งคำขอไปยังเซิร์ฟเวอร์นั้น (ค่าเริ่มต้นคือ 10 วินาที)
  • backup: ระบุว่าเซิร์ฟเวอร์นี้เป็นเซิร์ฟเวอร์สำรอง จะถูกใช้เมื่อเซิร์ฟเวอร์หลักทั้งหมด “down” เท่านั้น
  • down: ทำเครื่องหมายว่าเซิร์ฟเวอร์นี้ไม่พร้อมใช้งานชั่วคราว Nginx จะไม่ส่งคำขอไปที่นี่

เช่น:

upstream my_backends {
    server 192.168.1.101:80 weight=3; # รับโหลด 3 เท่าของเซิร์ฟเวอร์อื่น
    server 192.168.1.102:80 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.103:80 backup; # เป็นเซิร์ฟเวอร์สำรอง
    server 192.168.1.104:80 down; # ปิดใช้งานชั่วคราว
}

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

Nginx รองรับอัลกอริทึม Load Balancing หลายแบบ ซึ่งสามารถระบุได้ในบล็อก upstream ครับ

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

  • คำอธิบาย: เป็นอัลกอริทึมพื้นฐานและเป็นค่าเริ่มต้นของ Nginx ครับ Nginx จะกระจายคำขอไปยัง Backend Servers ทีละเครื่องตามลำดับ เมื่อถึงเครื่องสุดท้ายก็จะวนกลับไปที่เครื่องแรกใหม่
  • กรณีใช้งาน: เหมาะสำหรับ Backend Servers ที่มีประสิทธิภาพใกล้เคียงกัน และแต่ละคำขอไม่จำเป็นต้องถูกส่งไปยังเซิร์ฟเวอร์เดิม
  • วิธีใช้งาน: ไม่ต้องระบุอะไรเป็นพิเศษใน upstream block ครับ Nginx จะใช้ Round Robin เป็นค่าเริ่มต้น
upstream my_backends {
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

Least Connected

  • คำอธิบาย: Nginx จะส่งคำขอใหม่ไปยัง Backend Server ที่มีการเชื่อมต่อที่ใช้งานอยู่น้อยที่สุด อัลกอริทึมนี้มีประสิทธิภาพดีเมื่อคำขอแต่ละรายการใช้เวลาในการประมวลผลไม่เท่ากัน
  • กรณีใช้งาน: เหมาะสำหรับ Backend Servers ที่มีประสิทธิภาพไม่เท่ากัน หรือเมื่อคำขอมีความซับซ้อนและใช้เวลาประมวลผลต่างกัน
  • วิธีใช้งาน: เพิ่มคำสั่ง least_conn; ใน upstream block
upstream my_backends {
    least_conn;
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

IP Hash

  • คำอธิบาย: Nginx จะใช้ IP Address ของไคลเอนต์ (ผู้ใช้งาน) เพื่อกำหนดว่าคำขอจะถูกส่งไปยัง Backend Server ใด ทำให้คำขอจาก IP Address เดียวกันจะถูกส่งไปยัง Backend Server เดิมเสมอ
  • กรณีใช้งาน: มีประโยชน์มากสำหรับแอปพลิเคชันที่ต้องการ Session Persistence (Sticky Sessions) กล่าวคือ ผู้ใช้งานคนเดิมจะต้องเชื่อมต่อกับ Backend Server เครื่องเดิมตลอดระยะเวลาของ Session เพื่อรักษาสถานะของ Session ไว้
  • ข้อควรระวัง: หาก Backend Server ล่ม คำขอจาก IP นั้นจะถูกส่งไปที่เซิร์ฟเวอร์อื่น แต่ Session อาจจะหายไปได้ นอกจากนี้ หากผู้ใช้จำนวนมากมาจาก IP Address เดียวกัน (เช่น อยู่หลัง NAT) อาจทำให้เกิดการกระจายโหลดที่ไม่สมดุลได้ครับ
  • วิธีใช้งาน: เพิ่มคำสั่ง ip_hash; ใน upstream block
upstream my_backends {
    ip_hash;
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

Generic Hash

  • คำอธิบาย: คล้ายกับ IP Hash แต่มีความยืดหยุ่นมากกว่า คุณสามารถระบุ Key ใดๆ ก็ได้ที่จะใช้ในการคำนวณ Hash เพื่อเลือก Backend Server เช่น URL, ชื่อ Header หรือตัวแปร Nginx อื่นๆ
  • กรณีใช้งาน: เมื่อต้องการ Sticky Sessions โดยใช้ Key อื่นที่ไม่ใช่ IP Address ของไคลเอนต์ (เช่น Session ID จาก Cookie)
  • วิธีใช้งาน: เพิ่มคำสั่ง hash KEY [consistent]; ใน upstream block
upstream my_backends {
    hash $request_uri consistent; # ใช้ URI ของคำขอเป็น Key
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

consistent พารามิเตอร์ช่วยให้การกระจายโหลดราบรื่นขึ้นเมื่อมีการเพิ่มหรือลบ Backend Servers ครับ

Random

  • คำอธิบาย: Nginx จะเลือก Backend Server แบบสุ่ม
  • กรณีใช้งาน: อาจใช้ในการทดสอบ หรือในสถานการณ์ที่ไม่ต้องการการกระจายโหลดที่สม่ำเสมอ แต่ต้องการความสุ่มที่แท้จริง
  • วิธีใช้งาน: เพิ่มคำสั่ง random [least_conn] [reselect]; ใน upstream block
upstream my_backends {
    random;
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

least_conn สามารถใช้ร่วมกับ random เพื่อให้ Nginx เลือกเซิร์ฟเวอร์แบบสุ่มจากกลุ่มเซิร์ฟเวอร์ที่มีการเชื่อมต่อน้อยที่สุดได้ครับ

Weighted Round Robin

  • คำอธิบาย: เป็นการปรับปรุงจาก Round Robin โดยการเพิ่มน้ำหนัก (weight) ให้กับแต่ละเซิร์ฟเวอร์ เซิร์ฟเวอร์ที่มีน้ำหนักมากกว่าจะได้รับคำขอมากกว่า
  • กรณีใช้งาน: เมื่อ Backend Servers มีความสามารถในการประมวลผลไม่เท่ากัน เช่น เซิร์ฟเวอร์ใหม่มีทรัพยากรเยอะกว่าเซิร์ฟเวอร์เก่า
  • วิธีใช้งาน: ใช้พารามิเตอร์ weight กับแต่ละ server ใน upstream block (Round Robin เป็นค่าเริ่มต้นอยู่แล้ว)
upstream my_backends {
    server 192.168.1.101:80 weight=3; # รับโหลด 3 เท่า
    server 192.168.1.102:80 weight=1; # รับโหลด 1 เท่า
}

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

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

อัลกอริทึม คำอธิบาย กรณีใช้งานที่ดีที่สุด Session Persistence ข้อดี ข้อเสีย
Round Robin (Default) กระจายคำขอไปยัง Backend Servers ทีละเครื่องตามลำดับ Backend Servers มีประสิทธิภาพใกล้เคียงกัน, ไม่ต้องการ Session Persistence ไม่มี ง่ายต่อการตั้งค่า, กระจายโหลดได้ดีสำหรับคำขอที่ใช้เวลาเท่ากัน อาจไม่เหมาะถ้าคำขอใช้เวลาต่างกันมาก หรือ Backend Servers มีประสิทธิภาพไม่เท่ากัน
Least Connected ส่งคำขอไปยัง Backend Server ที่มีการเชื่อมต่อที่ใช้งานอยู่น้อยที่สุด Backend Servers มีประสิทธิภาพไม่เท่ากัน, คำขอใช้เวลาประมวลผลต่างกัน ไม่มี ปรับสมดุลโหลดได้ดีกว่า Round Robin, ลด Latency โดยรวม อาจทำให้ Backend Server ที่เพิ่งเริ่มทำงานได้รับโหลดเยอะในช่วงแรก
IP Hash ใช้ IP Address ของไคลเอนต์เพื่อส่งคำขอไปยัง Backend Server เดิมเสมอ ต้องการ Session Persistence โดยใช้ IP Address ของไคลเอนต์ มี (อิงจาก IP) รักษาสถานะ Session ได้ง่าย, ไม่ต้องเก็บ Cookie เพิ่มเติม หาก Backend ล่ม Session อาจหาย, การกระจายโหลดอาจไม่สมดุลถ้า IP Source ซ้ำกันเยอะ
Generic Hash ใช้ Hash จาก Key ที่กำหนดเอง (เช่น URI, Header) เพื่อเลือก Backend Server ต้องการ Session Persistence โดยใช้ Key อื่นที่ไม่ใช่ IP Address มี (อิงจาก Key ที่กำหนด) ยืดหยุ่นกว่า IP Hash, สามารถสร้าง Sticky Session ที่ซับซ้อนขึ้นได้ ต้องกำหนด Key อย่างระมัดระวัง, การกระจายโหลดอาจไม่สมดุลขึ้นอยู่กับ Key
Random เลือก Backend Server แบบสุ่ม ใช้ในการทดสอบ, สถานการณ์ที่ต้องการความสุ่มแท้จริง ไม่มี ง่ายและรวดเร็ว การกระจายโหลดอาจไม่สม่ำเสมอ, ไม่เหมาะสำหรับการใช้งานจริงที่ต้องการประสิทธิภาพสูงสุด
Weighted Round Robin กระจายคำขอแบบ Round Robin โดยให้เซิร์ฟเวอร์ที่มี Weight มากกว่าได้รับคำขอมากกว่า Backend Servers มีประสิทธิภาพต่างกันอย่างชัดเจน ไม่มี ใช้ประโยชน์จากทรัพยากรของเซิร์ฟเวอร์ได้อย่างเต็มที่ ต้องกำหนด Weight ให้เหมาะสม, อาจต้องมีการทดสอบเพื่อหาค่าที่ถูกต้อง

การเลือกอัลกอริทึมที่เหมาะสมขึ้นอยู่กับลักษณะของแอปพลิเคชันและความต้องการของคุณครับ สำหรับแอปพลิเคชันส่วนใหญ่ Round Robin หรือ Least Connected มักจะเป็นจุดเริ่มต้นที่ดี และถ้าต้องการ Session Persistence ก็อาจพิจารณา IP Hash หรือ Generic Hash ครับ

การตั้งค่า Load Balancing ด้วย Nginx

เราจะกลับไปแก้ไขไฟล์ /etc/nginx/conf.d/mywebapp.conf ที่เราสร้างไว้ครับ เพื่อรวม upstream block เข้าไป

# /etc/nginx/conf.d/mywebapp.conf

# 1. กำหนด Upstream Block สำหรับ Backend Servers
upstream my_backends {
    # เลือกอัลกอริทึม Load Balancing ที่นี่ (ตัวอย่างนี้ใช้ Round Robin ซึ่งเป็นค่าเริ่มต้น)
    # หากต้องการ Least Connected ให้เพิ่ม: least_conn;
    # หากต้องการ IP Hash ให้เพิ่ม: ip_hash;

    server 192.168.1.101:80 weight=2 max_fails=3 fail_timeout=30s; # Backend Server 1 (มีน้ำหนัก 2 เท่า)
    server 192.168.1.102:80 weight=1 max_fails=3 fail_timeout=30s; # Backend Server 2 (มีน้ำหนัก 1 เท่า)
    # server 192.168.1.103:80 backup; # เซิร์ฟเวอร์สำรอง จะถูกใช้เมื่อเซิร์ฟเวอร์หลักล่มหมด
}

server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com www.your_domain.com 192.168.1.100; # เปลี่ยนเป็นโดเมนหรือ IP ของ Nginx LB

    # 2. ตั้งค่า Log Format (ถ้าต้องการบันทึก Backend Server ที่ตอบสนอง)
    log_format loadbalancing '$remote_addr - $remote_user [$time_local] "$request" '
                             '$status $body_bytes_sent "$http_referer" '
                             '"$http_user_agent" "$http_x_forwarded_for" '
                             'to:$upstream_addr rt:$request_time ua:$upstream_response_time';
    access_log /var/log/nginx/mywebapp_access.log loadbalancing;
    error_log /var/log/nginx/mywebapp_error.log warn;


    location / {
        proxy_pass http://my_backends; # ส่งต่อคำขอไปยังกลุ่ม Backend Servers ที่กำหนดไว้ใน upstream block

        # Header ที่จำเป็นสำหรับการส่งข้อมูลผู้ใช้จริงไปยัง Backend
        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;

        # ตั้งค่า Timeout
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # ปรับแต่ง Buffer (ถ้าจำเป็น)
        proxy_buffers 16 4k; # จำนวนและขนาดของ buffer
        proxy_buffer_size 8k; # ขนาดของ buffer สำหรับ header ของ response

        # ปิดการบัฟเฟอร์ response จาก backend (บางแอปอาจต้องการ)
        # proxy_buffering off;
    }

    # เพิ่ม Block สำหรับ Error Pages
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

หลังจากแก้ไขไฟล์แล้ว อย่าลืมทดสอบ Syntax และโหลดการตั้งค่าใหม่นะครับ:

sudo nginx -t
sudo systemctl reload nginx

ตอนนี้ Nginx ของคุณกำลังทำหน้าที่เป็น Load Balancer แล้วครับ เมื่อคุณเข้าถึง http://your_domain.com หรือ http://192.168.1.100 คำขอจะถูกกระจายไปยัง backend-1 (192.168.1.101) และ backend-2 (192.168.1.102) ตามอัลกอริทึมที่คุณเลือกครับ

คุณสามารถตรวจสอบว่าคำขอถูกส่งไปที่ Backend Server ใดได้จาก Log File ที่เรากำหนดไว้ /var/log/nginx/mywebapp_access.log โดยดูที่ฟิลด์ to:$upstream_addr ครับ

คุณสมบัติขั้นสูงและการปรับแต่ง

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

Health Checks (การตรวจสอบสถานะ Backend Server)

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

  • max_fails=NUMBER: จำนวนครั้งที่ Nginx พยายามเชื่อมต่อหรือได้รับข้อผิดพลาดจาก Backend Server (เช่น 5xx error, connection refused) ในช่วง fail_timeout หากเกินจำนวนนี้ Nginx จะถือว่า Backend Server นั้น “down”
  • fail_timeout=TIME: ระยะเวลา (เป็นวินาที) ที่ Nginx จะรอหลังจากตรวจพบว่า Backend Server “down” ก่อนที่จะพยายามส่งคำขอใหม่ไปยังเซิร์ฟเวอร์นั้นอีกครั้ง เพื่อตรวจสอบว่ากลับมาทำงานปกติแล้วหรือไม่

ตัวอย่าง:

upstream my_backends {
    server 192.168.1.101:80 max_fails=3 fail_timeout=15s; # หากล้มเหลว 3 ครั้งใน 15 วินาที จะถือว่า down
    server 192.168.1.102:80 max_fails=5 fail_timeout=20s;
}

ข้อสังเกต: Nginx Open Source ใช้ “Passive Health Check” คือจะตรวจสอบสถานะเมื่อมีการส่งคำขอจริงๆ เท่านั้น
สำหรับ “Active Health Check” ที่ Nginx จะส่งคำขอทดสอบไปยัง Backend Server อย่างต่อเนื่องโดยไม่รอคำขอจากผู้ใช้ ต้องใช้ Nginx Plus ครับ แต่คุณสามารถใช้เครื่องมือภายนอกเช่น keepalived หรือ haproxy เพื่อเสริมความสามารถ Active Health Check ได้ครับ

Session Persistence (Sticky Sessions)

สำหรับแอปพลิเคชันที่ต้องรักษาสถานะของ Session (เช่น ตะกร้าสินค้า, การล็อกอิน) ผู้ใช้งานคนเดิมควรจะเชื่อมต่อกับ Backend Server เครื่องเดิมเสมอครับ นอกจาก ip_hash ที่กล่าวไปแล้ว ยังมีวิธีอื่นๆ:

  • sticky module (Nginx Plus หรือ Third-party modules): Nginx Plus มีโมดูล sticky ที่สามารถแทรก Cookie ลงใน Response เพื่อระบุ Backend Server ที่ผู้ใช้กำลังเชื่อมต่อ เมื่อผู้ใช้ส่งคำขอครั้งต่อไป Cookie นั้นจะถูกส่งกลับมา และ Nginx จะส่งคำขอไปยัง Backend Server เครื่องเดิม
  • Cookie-based Load Balancing (Open Source Workaround): คุณสามารถใช้ hash module ร่วมกับ map และ set_cookie เพื่อสร้าง Sticky Session ที่ใช้ Cookie ได้เอง แต่วิธีนี้ค่อนข้างซับซ้อนและอยู่นอกขอบเขตของบทความนี้ครับ

หากคุณใช้ ip_hash และพบปัญหาเรื่องการกระจายโหลดไม่สมดุลจาก NAT หรือ Proxy การพิจารณา Nginx Plus หรือโซลูชันอื่นๆ อาจเป็นสิ่งจำเป็นครับ

การจัดการ SSL/TLS Termination

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

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

# /etc/nginx/conf.d/mywebapp_ssl.conf

upstream my_backends {
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com www.your_domain.com;

    # Redirect HTTP ไป HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name your_domain.com www.your_domain.com;

    # ตำแหน่งของ SSL Certificate และ Private Key
    ssl_certificate /etc/nginx/ssl/your_domain.com/fullchain.pem; # เปลี่ยน path
    ssl_certificate_key /etc/nginx/ssl/your_domain.com/privkey.pem; # เปลี่ยน path

    # การตั้งค่า SSL เพิ่มเติมเพื่อความปลอดภัย
    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 off;
    
    # เพิ่ม Header HSTS เพื่อความปลอดภัย
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    location / {
        proxy_pass http://my_backends; # ส่งต่อคำขอไปยัง Backend Servers (ที่อาจจะรับ HTTP ภายใน)

        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
        proxy_set_header X-Forwarded-Port 443;
    }
}

คุณสามารถใช้ Let’s Encrypt ร่วมกับ Certbot เพื่อขอ SSL Certificate ได้ฟรีและง่ายดายครับ

Caching (การทำแคช)

Nginx สามารถทำหน้าที่เป็น Caching Reverse Proxy เพื่อลดภาระของ Backend Servers และเพิ่มความเร็วในการตอบสนองสำหรับเนื้อหาที่ไม่ได้เปลี่ยนแปลงบ่อยๆ ได้ครับ

# ใน http block (มักจะอยู่ใน /etc/nginx/nginx.conf หรือไฟล์แยกต่างหาก)
# กำหนด path สำหรับเก็บ cache และขนาดสูงสุด
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g
                 inactive=60m use_temp_path=off;

# ใน server block หรือ location block
location / {
    proxy_cache my_cache; # อ้างอิงถึง keys_zone ที่สร้างไว้
    proxy_cache_valid 200 302 10m; # แคช response ที่มี status 200, 302 เป็นเวลา 10 นาที
    proxy_cache_valid 404 1m;    # แคช response ที่มี status 404 เป็นเวลา 1 นาที
    proxy_cache_bypass $http_pragma $http_authorization; # ไม่แคชถ้ามี header เหล่านี้
    proxy_no_cache $http_pragma $http_authorization;     # ไม่แคชถ้ามี header เหล่านี้

    add_header X-Cache-Status $upstream_cache_status; # เพิ่ม header เพื่อดูสถานะ cache

    proxy_pass http://my_backends;
    # ... (header และ config อื่นๆ เหมือนเดิม)
}

คำสั่ง proxy_cache_path ควรจะอยู่ใน http block ใน nginx.conf เพื่อให้ใช้งานได้ทั่วถึงครับ
อ่านเพิ่มเติมเกี่ยวกับการตั้งค่า Nginx Caching ได้ที่นี่ครับ

การบีบอัดข้อมูล (Gzip Compression)

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

# ใน http block (แนะนำ)
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6; # ระดับการบีบอัด (1-9, 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 หรือการใช้งานทรัพยากรมากเกินไป Nginx สามารถจำกัดอัตราการร้องขอจากไคลเอนต์ได้ครับ

# ใน http block
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s; # จำกัด 10 คำขอต่อวินาทีต่อ IP

# ใน server block หรือ location block ที่ต้องการจำกัด
location /login {
    limit_req zone=mylimit burst=5 nodelay; # อนุญาตให้มี burst ได้ 5 คำขอ
    proxy_pass http://my_backends;
}

rate=10r/s หมายถึงอนุญาต 10 คำขอต่อวินาที burst=5 หมายถึงอนุญาตให้มีคำขอที่เกิน rate ได้ชั่วคราว 5 คำขอครับ

การตรวจสอบและแก้ไขปัญหา

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

การตรวจสอบ Log

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

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