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

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

March 16, 2026
0 Views

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

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

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

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

สารบัญ

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

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

Nginx คืออะไร?

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

แต่เดิม Nginx ถูกสร้างขึ้นมาเพื่อแก้ปัญหา C10k problem หรือปัญหาที่เว็บเซิร์ฟเวอร์แบบดั้งเดิมอย่าง Apache มีข้อจำกัดในการรองรับคอนเนกชันพร้อมกันจำนวน 10,000 คอนเนกชัน ทำให้ Nginx กลายเป็นตัวเลือกอันดับต้นๆ สำหรับเว็บไซต์ที่มีปริมาณการเข้าชมสูง เช่น Netflix, WordPress.com, หรือ Adobe เป็นต้นครับ

Reverse Proxy คืออะไร?

Reverse Proxy คือเซิร์ฟเวอร์ตัวกลางที่อยู่หน้าเว็บเซิร์ฟเวอร์จริง (Origin Servers หรือ Backend Servers) ทำหน้าที่รับ Request จาก Client (เช่น เว็บเบราว์เซอร์ของผู้ใช้งาน) แทนเซิร์ฟเวอร์จริง จากนั้นจึงส่ง Request นั้นต่อไปยังเซิร์ฟเวอร์ Backend ที่เหมาะสม และเมื่อเซิร์ฟเวอร์ Backend ประมวลผลเสร็จ Reverse Proxy ก็จะส่ง Response กลับไปยัง Client ครับ

ประโยชน์หลักๆ ของ Reverse Proxy มีดังนี้ครับ:

  • ความปลอดภัย (Security): Reverse Proxy ช่วยซ่อน IP Address และรายละเอียดของเซิร์ฟเวอร์ Backend จาก Client โดยตรง ทำให้ยากต่อการโจมตีครับ
  • การทำ Load Balancing: เป็นฟังก์ชันหลักที่เราจะเน้นในบทความนี้ Reverse Proxy สามารถกระจาย Request ไปยังเซิร์ฟเวอร์ Backend หลายๆ ตัว เพื่อกระจายภาระงานและเพิ่มความเสถียรครับ
  • การทำ SSL/TLS Termination: Reverse Proxy สามารถจัดการการเข้ารหัสและถอดรหัส SSL/TLS ได้ ทำให้เซิร์ฟเวอร์ Backend ไม่ต้องรับภาระนี้ และสามารถโฟกัสไปที่การประมวลผลแอปพลิเคชันได้เต็มที่ครับ
  • การทำ Caching: Reverse Proxy สามารถเก็บสำเนาของ Response ที่ถูกเรียกบ่อยๆ ไว้ชั่วคราว ทำให้การตอบสนองเร็วขึ้นและลดภาระงานของ Backend ครับ
  • การบีบอัดข้อมูล (Compression): สามารถบีบอัดข้อมูล Response ก่อนส่งกลับไปยัง Client เพื่อลดแบนด์วิธที่ใช้ครับ

Load Balancing คืออะไร?

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

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

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

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

ประโยชน์ของการใช้ Nginx เป็น Reverse Proxy และ Load Balancer

การรวมเอาความสามารถของ Nginx ในการเป็นทั้ง Reverse Proxy และ Load Balancer เข้าไว้ด้วยกัน ทำให้เกิดประโยชน์มหาศาลต่อระบบของคุณครับ:

  • ประสิทธิภาพเหนือชั้น: Nginx ถูกออกแบบมาเพื่อจัดการคอนเนกชันจำนวนมากด้วยทรัพยากรที่น้อยนิด ทำให้ระบบโดยรวมทำงานได้อย่างรวดเร็วและตอบสนองได้ทันใจครับ
  • ความเสถียรและความยืดหยุ่น: หากเซิร์ฟเวอร์ Backend ตัวใดตัวหนึ่งมีปัญหา Nginx จะตรวจจับได้และหยุดส่ง Request ไปยังเซิร์ฟเวอร์นั้นทันที ทำให้ระบบโดยรวมยังคงทำงานได้ต่อเนื่อง และเมื่อเซิร์ฟเวอร์กลับมาใช้งานได้ Nginx ก็จะเริ่มส่ง Request ไปให้ใหม่โดยอัตโนมัติครับ
  • ประหยัดทรัพยากรและค่าใช้จ่าย: ด้วยความสามารถในการรองรับ Request ได้จำนวนมาก Nginx ช่วยให้คุณสามารถใช้ฮาร์ดแวร์ได้อย่างมีประสิทธิภาพสูงสุด และลดความจำเป็นในการลงทุนใน Hardware Load Balancer ที่มีราคาสูงครับ
  • จัดการ SSL/TLS ได้ง่าย: Nginx สามารถทำหน้าที่เป็นจุดรวมในการจัดการใบรับรอง SSL/TLS ทั้งหมด ทำให้การบำรุงรักษาและการอัปเดตง่ายขึ้นมากครับ
  • ขยายระบบได้ง่าย: เมื่อต้องการเพิ่มขีดความสามารถ เพียงแค่เพิ่มเซิร์ฟเวอร์ Backend เข้าไปในกลุ่ม Nginx ก็จะจัดการการกระจายภาระงานให้โดยอัตโนมัติครับ
  • ฟีเจอร์ที่หลากหลาย: นอกจาก Load Balancing แล้ว Nginx ยังมาพร้อมฟีเจอร์อื่นๆ เช่น Caching, Gzip Compression, Rate Limiting ซึ่งช่วยเพิ่มประสิทธิภาพและความปลอดภัยให้กับระบบของคุณได้อีกด้วยครับ

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

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

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

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

  • เซิร์ฟเวอร์ Linux: เซิร์ฟเวอร์สำหรับติดตั้ง Nginx (เช่น Ubuntu, CentOS) โดยเราจะเรียกเซิร์ฟเวอร์นี้ว่า Nginx Proxy Server ครับ
  • ติดตั้ง Nginx: Nginx ควรได้รับการติดตั้งบน Nginx Proxy Server ของคุณแล้ว หากยังไม่ได้ติดตั้ง สามารถทำได้โดยใช้คำสั่งสำหรับแต่ละ OS ครับ 
    # สำหรับ Ubuntu/Debian
sudo apt update
sudo apt install nginx

# สำหรับ CentOS/RHEL
sudo yum install epel-release
sudo yum install nginx

    หลังจากติดตั้งแล้ว อย่าลืมเปิดใช้งานและตรวจสอบสถานะของ Nginx ครับ

    sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx
  • Backend Servers อย่างน้อย 2 ตัว: เซิร์ฟเวอร์เหล่านี้จะทำหน้าที่ให้บริการแอปพลิเคชันจริง (เช่น เว็บแอปพลิเคชัน Node.js, PHP-FPM, Apache, หรือ Tomcat) โดยแต่ละตัวควรมี IP Address และ Port ที่แตกต่างกัน ซึ่งเราจะเรียกเซิร์ฟเวอร์เหล่านี้ว่า Backend Servers หรือ Upstream Servers ครับ
  • ความเข้าใจพื้นฐานเกี่ยวกับการใช้งาน Linux Command Line: คุณควรจะคุ้นเคยกับการใช้คำสั่งพื้นฐานใน Linux และการแก้ไขไฟล์คอนฟิกครับ
  • สิทธิ์ root หรือ sudo: เพื่อทำการติดตั้งและแก้ไขไฟล์ระบบครับ

โครงสร้างเครือข่ายที่แนะนำ

เพื่อให้เห็นภาพชัดเจน ลองนึกถึงโครงสร้างเครือข่ายประมาณนี้ครับ:

  • Nginx Proxy Server:
    • IP Address: 192.168.1.100 (หรือ Public IP ที่ผู้ใช้งานเข้าถึง)
    • Port: 80 (HTTP) และ/หรือ 443 (HTTPS)
  • Backend Server 1:
    • IP Address: 192.168.1.101
    • Port: 8001 (หรือ Port ที่แอปพลิเคชันรันอยู่)
  • Backend Server 2:
    • IP Address: 192.168.1.102
    • Port: 8002 (หรือ Port ที่แอปพลิเคชันรันอยู่)
  • Backend Server 3 (สำหรับตัวอย่างที่ซับซ้อนขึ้น):
    • IP Address: 192.168.1.103
    • Port: 8003 (หรือ Port ที่แอปพลิเคชันรันอยู่)

ผู้ใช้งานจะเข้าถึงบริการผ่าน IP Address ของ Nginx Proxy Server และ Nginx จะเป็นผู้กระจาย Request ไปยัง Backend Servers ที่อยู่ภายในเครือข่ายส่วนตัว (Private Network) ซึ่งเป็นแนวทางปฏิบัติที่ดีด้านความปลอดภัยครับ

ตรวจสอบให้แน่ใจว่า Firewall ของคุณอนุญาตให้ Nginx Proxy Server สามารถเชื่อมต่อไปยัง Backend Servers ได้ตาม Port ที่กำหนดไว้ด้วยนะครับ

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

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

ทำความเข้าใจไฟล์คอนฟิก Nginx

ไฟล์คอนฟิกหลักของ Nginx มักจะอยู่ที่ /etc/nginx/nginx.conf ครับ ภายในไฟล์นี้ จะมีการกำหนดค่า Global และมักจะมีการ Include ไฟล์คอนฟิกอื่นๆ จากไดเรกทอรี sites-available และ sites-enabled ครับ

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

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

ตัวอย่างการตั้งค่า Reverse Proxy ไปยัง Backend เดียว

มาเริ่มต้นด้วยการตั้งค่า Reverse Proxy แบบง่ายๆ โดยให้ Nginx รับ Request และส่งต่อไปยัง Backend Server เพียงตัวเดียวก่อนครับ

สร้างไฟล์คอนฟิกใหม่ เช่น /etc/nginx/conf.d/mywebapp.conf (ชื่อไฟล์อะไรก็ได้ แต่ควรลงท้ายด้วย .conf ครับ):

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

จากนั้นใส่เนื้อหาด้านล่างนี้ลงไปครับ:

server {
    listen 80;
    listen [::]:80;
    server_name myapp.example.com www.myapp.example.com; # หรือ IP Address ของ Nginx Proxy Server

    location / {
        proxy_pass http://192.168.1.101:8001; # IP และ Port ของ 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;
    }
}

มาดูคำอธิบายแต่ละส่วนกันครับ:

  • server { ... }: เป็นบล็อกที่กำหนดค่าสำหรับ Virtual Host หรือ Server Block ครับ
  • listen 80;: Nginx จะรับฟัง Request ที่เข้ามาทาง Port 80 (HTTP) ครับ
  • listen [::]:80;: เป็นการกำหนดให้รับฟัง Request ทาง IPv6 ด้วยครับ
  • server_name myapp.example.com www.myapp.example.com;: กำหนดชื่อโดเมนที่ Nginx จะตอบสนองสำหรับ Server Block นี้ หากคุณยังไม่มีโดเมน สามารถใช้ IP Address ของ Nginx Proxy Server ได้ครับ หรือใช้ _ เพื่อให้ Nginx ตอบสนองทุกชื่อโดเมนที่ไม่ตรงกับ Server Block อื่นๆ ครับ
  • location / { ... }: บล็อกนี้กำหนดว่า Request ที่เข้ามาที่ Path ใดจะถูกจัดการอย่างไร ในที่นี้ / หมายถึง Request ทั้งหมดครับ
  • proxy_pass http://192.168.1.101:8001;: นี่คือคำสั่งหลักที่บอกให้ Nginx ส่งต่อ Request ไปยัง Backend Server ที่ระบุ (192.168.1.101 ที่ Port 8001) โดยใช้โปรโตคอล HTTP ครับ
  • proxy_set_header Host $host;: เป็นการส่งต่อ Header Host จาก Request เดิมไปยัง Backend Server เพื่อให้ Backend Server รู้ว่า Request เดิมนั้นมีชื่อโฮสต์อะไรครับ (สำคัญสำหรับแอปพลิเคชันที่ใช้ Virtual Hosts)
  • proxy_set_header X-Real-IP $remote_addr;: ส่ง IP Address จริงของผู้ใช้งานไปยัง Backend Server เพราะโดยปกติ Backend Server จะเห็นแค่ IP ของ Nginx Proxy Server ครับ
  • proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;: เป็น Header มาตรฐานที่ใช้ระบุ IP Address ของ Client เดิม และ IP ของ Proxy Server ที่ผ่านมาก่อนหน้าครับ
  • proxy_set_header X-Forwarded-Proto $scheme;: ส่งโปรโตคอล (HTTP หรือ HTTPS) ที่ Client ใช้เชื่อมต่อมายัง Nginx ไปยัง Backend Server ครับ

การทดสอบและการรีโหลดคอนฟิก

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

sudo nginx -t

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

เมื่อคอนฟิกถูกต้อง ให้ทำการรีโหลด Nginx เพื่อให้การตั้งค่าใหม่มีผลครับ:

sudo systemctl reload nginx

ตอนนี้ Nginx ของคุณทำหน้าที่เป็น Reverse Proxy ไปยัง Backend Server เดียวแล้ว ลองเปิดเว็บเบราว์เซอร์และเข้าถึง http://myapp.example.com (หรือ IP ของ Nginx Proxy Server) คุณควรจะเห็นหน้าเว็บหรือแอปพลิเคชันที่รันอยู่บน Backend Server ของคุณแล้วครับ

หลักการและวิธีการทำ Load Balancing ด้วย Nginx

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

แนวคิด Upstream และ Server Group

ใน Nginx การทำ Load Balancing จะเริ่มต้นด้วยการกำหนดกลุ่มของเซิร์ฟเวอร์ Backend ที่เราเรียกว่า “Upstream Group” ครับ บล็อก upstream จะทำหน้าที่เป็นจุดรวมของ Backend Servers ที่ให้บริการแอปพลิเคชันเดียวกัน Nginx จะใช้ชื่อของ Upstream Group นี้ในการอ้างถึงเวลาส่ง Request ครับ

upstream my_backend_servers {
    server 192.168.1.101:8001;
    server 192.168.1.102:8002;
    # เพิ่มเซิร์ฟเวอร์อื่นๆ ได้ที่นี่
}

server {
    listen 80;
    server_name myapp.example.com;

    location / {
        proxy_pass http://my_backend_servers; # อ้างถึงชื่อ Upstream Group
        # ... (proxy_set_header ต่างๆ เหมือนเดิม)
    }
}

จากตัวอย่างข้างต้น my_backend_servers คือชื่อของ Upstream Group ที่เรากำหนดขึ้นมา ซึ่งประกอบด้วย Backend Servers สองตัว จากนั้นในบล็อก location เราก็ใช้ proxy_pass http://my_backend_servers; เพื่อบอกให้ Nginx ส่ง Request ไปยังกลุ่มเซิร์ฟเวอร์นี้ครับ

Load Balancing Algorithms ยอดนิยม

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

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

เป็น Algorithm ที่ง่ายที่สุดและเป็นค่าเริ่มต้นของ Nginx ครับ Nginx จะกระจาย Request ไปยัง Backend Servers ตามลำดับทีละตัวอย่างเท่าเทียมกัน เช่น Request แรกไป Server 1, Request ที่สองไป Server 2, Request ที่สามไป Server 3, แล้ววนกลับไป Server 1 ใหม่ครับ

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

Least Connected

Nginx จะส่ง Request ไปยัง Backend Server ที่มีการเชื่อมต่อ (Active Connections) อยู่น้อยที่สุดครับ Algorithm นี้เหมาะสำหรับกรณีที่ Request มีความยาวหรือใช้เวลาในการประมวลผลไม่เท่ากัน

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

IP Hash

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

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

Generic Hash

คล้ายกับ IP Hash แต่ Nginx จะใช้ค่าที่กำหนดเองมาคำนวณ Hash แทน IP Address ครับ เช่น คุณอาจจะใช้ $uri หรือ $request_uri เพื่อให้ Request สำหรับ URI เดียวกันไปที่ Backend Server ตัวเดียวกัน ซึ่งมีประโยชน์สำหรับการทำ Caching หรือการแบ่งกลุ่มข้อมูลครับ

  • ข้อดี: ยืดหยุ่นกว่า IP Hash สามารถกำหนดค่า Hash ได้ตามต้องการ
  • ข้อเสีย: ต้องพิจารณาค่าที่จะนำมา Hash ให้ดีเพื่อไม่ให้เกิดความไม่สมดุลของภาระงาน

Random

Nginx จะสุ่มเลือก Backend Server เพื่อส่ง Request ไปให้ Algorithm นี้มีสองโหมด:

  • random;: สุ่มเลือกจากเซิร์ฟเวอร์ทั้งหมด
  • random two;: สุ่มเลือกมาสองตัว แล้วส่ง Request ไปยังตัวที่มี Active Connections น้อยที่สุด (คล้าย Least Connected แต่มีการสุ่มก่อน)
  • ข้อดี: เหมาะสำหรับระบบที่มี Backend Servers จำนวนมากและไม่ต้องการ Overhead ในการติดตามสถานะการเชื่อมต่อ
  • ข้อเสีย: อาจทำให้เกิดความไม่สมดุลของภาระงานมากกว่า Least Connected

Weighted Load Balancing

เป็นการนำ Weight หรือน้ำหนักมาใส่ใน Algorithm อื่นๆ เช่น Round Robin หรือ Least Connected ครับ โดยการกำหนดค่า weight ให้กับแต่ละ Backend Server เซิร์ฟเวอร์ที่มี Weight สูงกว่าก็จะได้รับ Request มากกว่าครับ

  • ข้อดี: เหมาะสำหรับกรณีที่ Backend Servers มีประสิทธิภาพหรือทรัพยากรต่างกัน ทำให้สามารถส่ง Request ไปยังเซิร์ฟเวอร์ที่แรงกว่าได้มากขึ้น
  • ข้อเสีย: ต้องมีการประเมินประสิทธิภาพของเซิร์ฟเวอร์เพื่อกำหนด Weight ที่เหมาะสม

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

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

Algorithm หลักการทำงาน เหมาะสำหรับ ข้อดี ข้อเสีย
Round Robin กระจาย Request ตามลำดับทีละตัว Backend Servers มีประสิทธิภาพเท่ากัน, Request มีความซับซ้อนใกล้เคียงกัน ตั้งค่าง่าย, ประสิทธิภาพดีสำหรับกรณีทั่วไป ไม่คำนึงถึงภาระงานจริง, อาจเกิดความไม่สมดุล
Least Connected ส่ง Request ไปยังเซิร์ฟเวอร์ที่มี Active Connections น้อยที่สุด Backend Servers มีประสิทธิภาพเท่ากัน/ต่างกัน, Request มีความยาว/ซับซ้อนต่างกัน กระจายภาระงานได้สมดุล, ลดปัญหาคอขวด ต้องติดตามสถานะ Active Connections
IP Hash ใช้ IP Client คำนวณ Hash เพื่อส่งไปยังเซิร์ฟเวอร์เดิม แอปพลิเคชันที่ต้องการ Sticky Session (เก็บสถานะที่ Backend) รักษา Session ได้ดี, ไม่ต้องใช้ Cookie อาจทำให้ภาระงานไม่สมดุลหากมี IP ซ้ำกันเยอะ, เซิร์ฟเวอร์ล่มทำให้ Session หลุด
Generic Hash ใช้ค่าที่กำหนดเอง (เช่น $uri) คำนวณ Hash กรณีต้องการ Sticky Session ตามพารามิเตอร์อื่น, การทำ Caching เฉพาะส่วน ยืดหยุ่นสูง, กำหนดพฤติกรรมได้ละเอียด ต้องเลือกค่า Hash อย่างระมัดระวังเพื่อไม่ให้เกิดความไม่สมดุล
Random สุ่มเลือก Backend Server ระบบขนาดใหญ่ที่มี Backend Servers จำนวนมาก, ไม่ต้องการ Overhead สูง ตั้งค่าง่าย, ลด Overhead การติดตามสถานะ อาจไม่สมดุลเท่า Least Connected, มีโอกาสเกิด Hotspot ได้
Weighted Round Robin / Least Connected กำหนดน้ำหนักให้แต่ละเซิร์ฟเวอร์, เซิร์ฟเวอร์ที่มีน้ำหนักมากได้ Request มากกว่า Backend Servers มีประสิทธิภาพหรือทรัพยากรต่างกัน ใช้ทรัพยากรได้อย่างเหมาะสม, เพิ่มประสิทธิภาพรวม ต้องประเมิน Weight ที่เหมาะสม, หาก Weight ไม่ดีอาจเกิดความไม่สมดุล

การเลือก Algorithm ที่เหมาะสมขึ้นอยู่กับลักษณะของแอปพลิเคชันและทรัพยากรของ Backend Servers ของคุณครับ หากไม่แน่ใจ Round Robin หรือ Least Connected มักจะเป็นจุดเริ่มต้นที่ดีครับ

การตั้งค่า Nginx Load Balancing แบบเจาะลึก

มาถึงส่วนสำคัญที่เราจะลงมือตั้งค่า Load Balancing ด้วย Nginx กันแล้วนะครับ เราจะใช้ตัวอย่างคอนฟิกที่สามารถนำไปปรับใช้ได้จริงครับ

เช่นเคย เราจะสร้างหรือแก้ไขไฟล์คอนฟิกใน /etc/nginx/conf.d/mywebapp.conf ครับ

การกำหนดกลุ่ม Upstream Servers

ก่อนอื่น ให้เรากำหนดกลุ่มของ Backend Servers ของเราก่อนครับ ในตัวอย่างนี้ เราจะมี Backend Servers 3 ตัว รันอยู่ที่ IP และ Port ต่างกันครับ

upstream my_backend_servers {
    # Backend Servers ทั้งหมด
    server 192.168.1.101:8001;
    server 192.168.1.102:8002;
    server 192.168.1.103:8003;
}

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

    location / {
        proxy_pass http://my_backend_servers; # Nginx จะใช้ Upstream Group นี้
        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;
    }
}

เมื่อเรากำหนด upstream my_backend_servers แบบนี้ Nginx จะใช้ Algorithm แบบ Round Robin เป็นค่าเริ่มต้นครับ

การตั้งค่า Round Robin Load Balancing

ตามที่กล่าวไปข้างต้น การกำหนดกลุ่ม upstream โดยไม่มี directive ระบุ Algorithm อื่นๆ Nginx จะใช้ Round Robin โดยอัตโนมัติครับ

upstream my_backend_servers_round_robin {
    # Round Robin เป็นค่าเริ่มต้น ไม่ต้องระบุ directive
    server 192.168.1.101:8001;
    server 192.168.1.102:8002;
    server 192.168.1.103:8003;
}

server {
    listen 80;
    server_name roundrobin.example.com;

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

การตั้งค่า Least Connected Load Balancing

หากต้องการให้ Nginx ส่ง Request ไปยังเซิร์ฟเวอร์ที่มี Active Connections น้อยที่สุด ให้เพิ่ม directive least_conn; ในบล็อก upstream ครับ

upstream my_backend_servers_least_conn {
    least_conn; # กำหนดให้ใช้ Least Connected
    server 192.168.1.101:8001;
    server 192.168.1.102:8002;
    server 192.168.1.103:8003;
}

server {
    listen 80;
    server_name leastconn.example.com;

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

การตั้งค่า IP Hash Load Balancing

สำหรับการทำ Sticky Sessions โดยใช้ IP Address ของ Client ให้เพิ่ม directive ip_hash; ในบล็อก upstream ครับ

upstream my_backend_servers_ip_hash {
    ip_hash; # กำหนดให้ใช้ IP Hash
    server 192.168.1.101:8001;
    server 192.168.1.102:8002;
    server 192.168.1.103:8003;
}

server {
    listen 80;
    server_name iphash.example.com;

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

ข้อควรระวัง: หากคุณมี Nginx Proxy Server หลายตัวอยู่ด้านหน้า Nginx Load Balancer อีกที (Multi-layer Proxy) ip_hash อาจไม่ทำงานตามที่คาดหวัง เพราะ Nginx Load Balancer จะเห็น IP ของ Proxy Server ตัวหน้าสุด ไม่ใช่ IP จริงของ Client ครับ ในกรณีนี้ คุณอาจจะต้องพิจารณาใช้ hash ร่วมกับ $remote_addr หรือ $http_x_forwarded_for แต่ต้องระวังเรื่องความปลอดภัยครับ

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

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

upstream my_backend_servers_weighted {
    server 192.168.1.101:8001 weight=5; # Server นี้จะได้รับ Request มากกว่า
    server 192.168.1.102:8002 weight=3;
    server 192.168.1.103:8003 weight=1; # Server นี้จะได้รับ Request น้อยกว่า
}

server {
    listen 80;
    server_name weighted.example.com;

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

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

การจัดการสถานะเซิร์ฟเวอร์ (Health Checks และ Server Directives)

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

max_fails และ fail_timeout

Directive สองตัวนี้ใช้ในการกำหนด Health Check พื้นฐานครับ

  • max_fails=N: จำนวนครั้งสูงสุดที่ Nginx จะพยายามส่ง Request ไปยังเซิร์ฟเวอร์นั้นๆ หาก Request ล้มเหลว (เช่น เซิร์ฟเวอร์ไม่ตอบสนอง, การเชื่อมต่อถูกปฏิเสธ) Nginx จะถือว่าเซิร์ฟเวอร์นั้น “down” ครับ (ค่าเริ่มต้นคือ 1)
  • fail_timeout=T: ระยะเวลา (เป็นวินาที) ที่เซิร์ฟเวอร์จะถูกพิจารณาว่า “down” หลังจากที่ max_fails ถึงกำหนดแล้ว หลังจากหมดเวลานี้ Nginx จะลองส่ง Request ไปยังเซิร์ฟเวอร์นั้นอีกครั้งเพื่อตรวจสอบว่ากลับมาทำงานได้ปกติหรือไม่ (ค่าเริ่มต้นคือ 10 วินาที)
upstream my_backend_servers_health_check {
    server 192.168.1.101:8001 max_fails=3 fail_timeout=30s;
    server 192.168.1.102:8002 max_fails=5 fail_timeout=60s;
    server 192.168.1.103:8003; # ใช้ค่าเริ่มต้น max_fails=1, fail_timeout=10s
}

ในตัวอย่างนี้ หาก 192.168.1.101:8001 ล้มเหลว 3 ครั้งภายใน 30 วินาที Nginx จะหยุดส่ง Request ไปยังเซิร์ฟเวอร์นี้เป็นเวลา 30 วินาทีครับ

backup (เซิร์ฟเวอร์สำรอง)

ใช้เพื่อระบุเซิร์ฟเวอร์สำรองที่จะถูกใช้ต่อเมื่อ Backend Servers หลักทั้งหมด “down” หรือไม่พร้อมใช้งานครับ

upstream my_backend_servers_with_backup {
    server 192.168.1.101:8001;
    server 192.168.1.102:8002;
    server 192.168.1.103:8003 backup; # เซิร์ฟเวอร์สำรอง
}

ในที่นี้ 192.168.1.103:8003 จะถูกใช้งานก็ต่อเมื่อ Server 101 และ 102 ไม่สามารถให้บริการได้ครับ

down (ปิดการใช้งานเซิร์ฟเวอร์ชั่วคราว)

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

upstream my_backend_servers_down {
    server 192.168.1.101:8001;
    server 192.168.1.102:8002 down; # ปิดการใช้งานชั่วคราว
    server 192.168.1.103:8003;
}

เมื่อต้องการเปิดใช้งานอีกครั้ง ก็แค่ลบ down directive ออกแล้ว reload Nginx ครับ

slow_start (การอุ่นเครื่องเซิร์ฟเวอร์ใหม่)

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

upstream my_backend_servers_slow_start {
    server 192.168.1.101:8001;
    server 192.168.1.102:8002 slow_start=30s; # ค่อยๆ เพิ่มโหลดภายใน 30 วินาที
    server 192.168.1.103:8003;
}

Directive เหล่านี้เป็นเครื่องมือที่ทรงพลังในการจัดการความพร้อมใช้งานและความยืดหยุ่นของระบบ Load Balancing ของคุณครับ อย่าลืมทดสอบคอนฟิกด้วย sudo nginx -t และรีโหลด Nginx ด้วย sudo systemctl reload nginx ทุกครั้งที่มีการเปลี่ยนแปลงนะครับ

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

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

SSL/TLS Termination ที่ Nginx

การจัดการ SSL/TLS Certificate (ใบรับรองความปลอดภัย) ที่ Nginx Proxy Server (SSL/TLS Termination) เป็นแนวทางปฏิบัติที่ดีเยี่ยมครับ เพราะ Nginx มีประสิทธิภาพสูงในการประมวลผลการเข้ารหัสและถอดรหัส SSL/TLS ทำให้ Backend Servers ไม่ต้องรับภาระนี้ และสามารถโฟกัสไปที่การประมวลผลแอปพลิเคชันได้เต็มที่ครับ

สมมติว่าคุณมีใบรับรอง SSL/TLS (your_domain.crt) และ Private Key (your_domain.key) อยู่แล้ว ให้วางไว้ในไดเรกทอรีที่เหมาะสม เช่น /etc/nginx/ssl/ ครับ

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

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

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

    ssl_certificate /etc/nginx/ssl/your_domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your_domain.key;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM";
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://my_backend_servers_least_conn; # หรือ Upstream Group อื่นๆ
        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 ว่า Request มาจาก HTTPS
    }
}

ในคอนฟิกนี้:

  • Server Block แรกจะ Redirect HTTP (Port 80) ไปยัง HTTPS (Port 443) โดยอัตโนมัติครับ
  • Server Block ที่สองจะรับฟัง Request ทาง Port 443 และเปิดใช้งาน SSL/TLS พร้อมระบุไฟล์ Certificate และ Key ครับ
  • ssl_protocols และ ssl_ciphers: กำหนดโปรโตคอลและชุดการเข้ารหัสที่ปลอดภัยที่ Nginx จะใช้ครับ
  • proxy_set_header X-Forwarded-Proto https;: สำคัญมาก เพื่อบอก Backend Server ว่า Request เดิมนั้นเป็น HTTPS แม้ว่า Nginx จะส่งต่อไปยัง Backend ด้วย HTTP ก็ตามครับ

อ่านเพิ่มเติมเกี่ยวกับการตั้งค่า SSL/TLS ใน Nginx ได้ที่นี่

การทำ Caching เพื่อเพิ่มประสิทธิภาพ

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

# กำหนด Zone สำหรับ Cache ในระดับ http block (ใน nginx.conf หรือไฟล์แยก)
# sudo nano /etc/nginx/nginx.conf
# หรือ /etc/nginx/conf.d/cache.conf

http {
    # ...
    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 ของคุณ (mywebapp.conf)
server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 302 10m; # Cache Response ที่เป็น 200, 302 เป็นเวลา 10 นาที
        proxy_cache_valid 404 1m;     # Cache Response ที่เป็น 404 เป็นเวลา 1 นาที
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; # ใช้ Cache เก่าหาก Backend มีปัญหา
        proxy_cache_revalidate on; # ตรวจสอบกับ Backend ก่อนส่ง Cache เก่า
        add_header X-Cache-Status $upstream_cache_status;

        proxy_pass http://my_backend_servers_least_conn;
        # ...
    }
}

คำอธิบาย:

  • proxy_cache_path: กำหนดไดเรกทอรีสำหรับเก็บไฟล์ Cache, ขนาดของ Zone หน่วยความจำสำหรับ Key (keys_zone), ขนาดสูงสุดของ Cache (max_size), และระยะเวลาที่ไฟล์ Cache จะถูกลบหากไม่มีการเข้าถึง (inactive)
  • proxy_cache my_cache;: เปิดใช้งาน Cache โดยใช้ Zone ที่ชื่อ my_cache
  • proxy_cache_valid: กำหนดระยะเวลาการ Cache สำหรับ Response ที่มี Status Code ต่างๆ
  • proxy_cache_use_stale: กำหนดเงื่อนไขที่ Nginx จะใช้ Cache ที่หมดอายุแล้ว หาก Backend Server มีปัญหา
  • add_header X-Cache-Status $upstream_cache_status;: เพิ่ม Header เพื่อตรวจสอบสถานะของ Cache (HIT, MISS, EXPIRED, etc.)

การบีบอัดข้อมูลด้วย Gzip

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

server {
    # ...
    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;

    location / {
        proxy_pass http://my_backend_servers;
        # ...
    }
}

ในที่นี้ Nginx จะบีบอัด Response ที่มี Content-Type ตามที่ระบุ ก่อนส่งไปยัง Client ครับ

การตั้งค่า Logging ที่มีประสิทธิภาพ

การมี Logging ที่ดีช่วยให้คุณสามารถตรวจสอบการทำงานของ Nginx และ Backend Servers ได้อย่างละเอียด รวมถึงช่วยในการแก้ไขปัญหาและวิเคราะห์พฤติกรรมผู้ใช้งานครับ

server {
    # ...
    access_log /var/log/nginx/myapp_access.log custom_format; # กำหนดไฟล์และฟอร์แมตสำหรับ Access Log
    error_log /var/log/nginx/myapp_error.log warn;           # กำหนดไฟล์และระดับความสำคัญสำหรับ Error Log

    location / {
        proxy_pass http://my_backend_servers;
        # ...
    }
}

# กำหนด custom_format ใน http block (ใน nginx.conf หรือไฟล์แยก)
http {
    # ...
    log_format custom_format '$remote_addr - $remote_user [$time_local] "$request" '
                             '$status $body_bytes_sent "$http_referer" '
                             '"$http_user_agent" "$http_x_forwarded_for" '
                             '$upstream_addr $request_time $upstream_response_time';
    # ...
}

$upstream_addr และ $upstream_response_time เป็นตัวแปรที่สำคัญในการตรวจสอบว่า Nginx ส่ง Request ไปยัง Backend Server ตัวไหนและใช้เวลาตอบสนองเท่าไรครับ

Sticky Sessions สำหรับแอปพลิเคชันที่ต้องการสถานะ

นอกเหนือจาก ip_hash ซึ่งมีข้อจำกัดเรื่อง NAT/Proxy การทำ Sticky Sessions ด้วย Cookie เป็นอีกทางเลือกที่นิยมครับ โดย Nginx จะพยายามส่ง Request จาก Client เดิมไปยัง Backend Server ตัวเดิม โดยใช้ Cookie ที่ Nginx สร้างขึ้นมา

Nginx Open Source รองรับ ip_hash เท่านั้น หากต้องการ Sticky Sessions ที่ซับซ้อนกว่านี้ เช่น ด้วย Cookie ต้องใช้ Nginx Plus หรือ Module ภายนอกครับ

หมายเหตุ: คุณสมบัติ Sticky Sessions ด้วย Cookie ใน Nginx Open Source ต้องอาศัยการติดตั้งโมดูลเพิ่มเติม เช่น `ngx_http_upstream_sticky_module` หรือใช้ Nginx Plus ครับ ตัวอย่างโค้ดด้านล่างเป็นแนวคิด หากต้องการใช้งานจริงต้องตรวจสอบการติดตั้งโมดูลที่เหมาะสมครับ

# ตัวอย่าง (ต้องใช้ Nginx Plus หรือโมดูลเสริม)
upstream my_backend_servers_sticky {
    sticky cookie srv_id expires=1h domain=.example.com path=/; # ใช้ Cookie ชื่อ srv_id
    server 192.168.1.101:8001;
    server 192.168.1.102:8002;
}

server {
    listen 80;
    server_name sticky.example.com;

    location / {
        proxy_pass http://my_backend_servers_sticky;
        # ...
    }
}

การจำกัด Request Rate (Rate Limiting)

เพื่อป้องกันการโจมตี DDoS หรือการใช้งานทรัพยากรเกินควร คุณสามารถจำกัดจำนวน Request ที่ Client สามารถส่งเข้ามาได้ในช่วงเวลาหนึ่งครับ

# ใน http block (ใน nginx.conf หรือไฟล์แยก)
http {
    # ...
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s; # จำกัด 5 request/วินาที ต่อ 1 IP
    # ...
}

# ในไฟล์คอนฟิก Server Block ของคุณ (mywebapp.conf)
server {
    # ...
    location / {
        limit_req zone=mylimit burst=10 nodelay; # อนุญาตให้ burst ได้ 10 request ก่อนที่จะเริ่ม delay
        proxy_pass http://my_backend_servers;
        # ...
    }
}

limit_req_zone: กำหนด Zone สำหรับจำกัด Rate โดยใช้ IP Address ของ Client ($binary_remote_addr) และกำหนด rate ให้เป็น 5 Request ต่อวินาที (rate=5r/s) ครับ

limit_req zone=mylimit burst=10 nodelay;: นำ Zone มาใช้งานใน location โดยอนุญาตให้มี burst ได้ 10 Request ซึ่งหมายความว่าหากมี Request เกิน 5r/s มาถึง Nginx จะอนุญาตให้เกินไปได้อีก 10 Request ก่อนที่จะเริ่มส่ง HTTP 503 (Service Unavailable) ครับ

การเพิ่มความปลอดภัยให้ Nginx Reverse Proxy

การตั้งค่า Nginx ให้ปลอดภัยเป็นสิ่งสำคัญครับ

  • ซ่อน Nginx Version: ป้องกันการเปิดเผยข้อมูลเวอร์ชันของ Nginx ซึ่งอาจถูกนำไปใช้ประโยชน์ในการโจมตีได้ครับ 
    # ใน http block หรือ server block
server_tokens off;
  • เพิ่ม HTTP Security Headers: เพื่อป้องกันการโจมตีบางประเภท เช่น XSS, Clickjacking ครับ 
    server {
            # ...
            add_header X-Frame-Options "SAMEORIGIN";
            add_header X-Content-Type-Options "nosniff";
            add_header X-XSS-Protection "1; mode=block";
            add_header Referrer-Policy "no-referrer-when-downgrade";
            add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # สำหรับ HTTPS เท่านั้น
            # ...
        }
  • จำกัดขนาด Body ของ Request: ป้องกันการโจมตีแบบ Buffer Overflow หรือการส่งข้อมูลขนาดใหญ่เกินความจำเป็นครับ 
    # ใน http block หรือ server block
client_max_body_size 10M; # จำกัดขนาด Request Body ไม่เกิน 10MB

อ่านเพิ่มเติมเกี่ยวกับ Security Hardening ใน Nginx ได้ที่นี่

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

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

คำสั่ง Nginx ที่ควรรู้

คำสั่งพื้นฐานเหล่านี้จะช่วยให้คุณจัดการ Nginx ได้อย่างมีประสิทธิภาพครับ:

  • sudo nginx -t: ใช้สำหรับทดสอบความถูกต้องของไฟล์คอนฟิก Nginx ครับ ควรทำทุกครั้งก่อนที่จะ Reload หรือ Restart Nginx ครับ
  • sudo systemctl start nginx: เริ่มต้นบริการ Nginx ครับ
  • sudo systemctl stop nginx: หยุดบริการ Nginx ครับ
  • sudo systemctl restart nginx: รีสตาร์ทบริการ Nginx (หยุดแล้วเริ่มใหม่) ครับ
  • sudo systemctl reload nginx: รีโหลดไฟล์คอนฟิกใหม่โดยไม่ต้องหยุดการให้บริการ Nginx ครับ (เป็นวิธีที่แนะนำสำหรับการเปลี่ยนแปลงคอนฟิก)
  • sudo systemctl status nginx: ตรวจสอบสถานะการทำงานของ Nginx ครับ
  • sudo systemctl enable nginx: กำหนดให้ Nginx เริ่มทำงานโดยอัตโนมัติเมื่อระบบบูตครับ
  • sudo systemctl disable nginx: ปิดการเริ่มทำงานอัตโนมัติของ Nginx ครับ

การอ่าน Error Logs

เมื่อเกิดปัญหา Nginx จะบันทึกข้อผิดพลาดลงใน Error Log ซึ่งมักจะอยู่ที่ /var/log/nginx/error.log ครับ การตรวจสอบ Error Log เป็นขั้นตอนแรกและสำคัญที่สุดในการวินิจฉัยปัญหาครับ

sudo tail -f /var/log/nginx/error.log

คำสั่งนี้จะแสดง Log ล่าสุดแบบ Real-time ทำให้คุณเห็นข้อผิดพลาดที่เกิดขึ้นขณะที่คุณกำลังทดสอบระบบครับ มองหาข้อความที่ระบุถึงปัญหาเกี่ยวกับ proxy_pass, การเชื่อมต่อไปยัง Upstream Servers หรือปัญหาเกี่ยวกับไฟล์คอนฟิกครับ

เครื่องมือ Monitoring

สำหรับการ Monitoring ระบบ Load Balancing ที่ซับซ้อนและมีการใช้งานสูง อาจจำเป็นต้องใช้เครื่องมือภายนอกเข้ามาช่วยครับ

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