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

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

March 15, 2026
0 Views

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

สารบัญ

Nginx Reverse Proxy Load Balancing คืออะไร ทำไมต้องใช้?

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

Nginx คืออะไร?

Nginx (อ่านว่า “Engine-x”) คือเว็บเซิร์ฟเวอร์แบบ Open Source ที่มีประสิทธิภาพสูง มีชื่อเสียงในด้านความสามารถในการจัดการการเชื่อมต่อพร้อมกันจำนวนมาก (C10k problem) ด้วยโมเดลการทำงานแบบ Asynchronous และ Event-driven ทำให้ Nginx สามารถจัดการกับ Traffic จำนวนมากโดยใช้ทรัพยากรระบบน้อยกว่าเว็บเซิร์ฟเวอร์แบบอื่น ๆ ครับ นอกจากจะเป็นเว็บเซิร์ฟเวอร์หลักแล้ว Nginx ยังถูกใช้งานอย่างแพร่หลายในบทบาทของ Reverse Proxy, Load Balancer, HTTP Cache และ Web Accelerator อีกด้วยครับ

Reverse Proxy คืออะไร?

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

ประโยชน์ของ Reverse Proxy:

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

Load Balancing คืออะไร?

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

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

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

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

  • เพิ่มประสิทธิภาพและความเร็ว: Nginx สามารถจัดการการเชื่อมต่อได้จำนวนมหาศาล และการกระจายโหลดไปยัง Backend Servers หลายตัวทำให้แต่ละคำขอได้รับการตอบสนองที่รวดเร็วขึ้นครับ
  • ความเสถียรและความพร้อมใช้งานสูง (High Availability): หากมี Backend Server ตัวใดเกิดปัญหา Nginx จะตรวจพบและหยุดส่ง Traffic ไปยังเซิร์ฟเวอร์นั้นโดยอัตโนมัติ ทำให้เว็บไซต์ของคุณยังคงออนไลน์อยู่ได้โดยไม่สะดุดครับ
  • ความสามารถในการขยายขนาด (Scalability): คุณสามารถเพิ่ม Backend Servers ได้ง่าย ๆ เพื่อรองรับจำนวนผู้ใช้งานที่เพิ่มขึ้น โดยไม่ต้องปรับเปลี่ยนโครงสร้างพื้นฐานด้านหน้าเลยครับ
  • ความปลอดภัยที่เพิ่มขึ้น: Nginx ทำหน้าที่เป็นด่านหน้า ปกป้อง Backend Servers จากการโจมตีโดยตรง และสามารถกรอง Traffic ที่น่าสงสัยได้ครับ
  • การจัดการ SSL/TLS ที่ง่ายขึ้น: สามารถทำ SSL Termination ได้ที่ Nginx ทำให้ Backend Servers ไม่ต้องแบกรับภาระการเข้ารหัส/ถอดรหัส และคุณสามารถจัดการใบรับรอง SSL ได้ที่จุดเดียวครับ
  • ลดต้นทุน: Nginx เป็น Open Source ทำให้คุณไม่ต้องเสียค่าใช้จ่ายด้าน License และด้วยประสิทธิภาพที่สูง ทำให้คุณอาจใช้ทรัพยากรฮาร์ดแวร์น้อยลงครับ

สิ่งที่คุณต้องมีก่อนเริ่มต้น

เพื่อให้การตั้งค่า Nginx Reverse Proxy Load Balancing เป็นไปอย่างราบรื่น คุณควรมีสิ่งเหล่านี้เตรียมไว้ก่อนนะครับ:

  • เซิร์ฟเวอร์สำหรับ Nginx Reverse Proxy: นี่คือเซิร์ฟเวอร์ที่จะติดตั้ง Nginx และทำหน้าที่เป็นด่านหน้า ควรเป็นเซิร์ฟเวอร์ที่มีทรัพยากรเพียงพอในการรับ Traffic ทั้งหมดครับ (แนะนำ Ubuntu/Debian หรือ CentOS/RHEL)
  • เว็บแอปพลิเคชัน/Backend Servers อย่างน้อย 2 ตัว: เพื่อให้เห็นผลของการทำ Load Balancing คุณจำเป็นต้องมีเซิร์ฟเวอร์ที่รันแอปพลิเคชันของคุณอยู่จริงอย่างน้อย 2 ตัว หรือมากกว่านั้นครับ (เช่น เซิร์ฟเวอร์ Node.js, PHP-FPM, Apache, Tomcat เป็นต้น) แต่ละ Backend Server ควรมี IP Address ที่แตกต่างกันครับ
  • ความรู้พื้นฐานเกี่ยวกับ Linux Command Line: คุณจะต้องใช้คำสั่งพื้นฐานในการติดตั้ง ซ่อมบำรุง และแก้ไขไฟล์คอนฟิกครับ
  • โดเมน (ไม่บังคับ แต่แนะนำ): หากคุณมีโดเมน จะทำให้การตั้งค่า SSL และการเข้าถึงเว็บไซต์สะดวกขึ้นมากครับ หากไม่มี คุณสามารถใช้ IP Address ในการทดสอบได้ครับ
  • การเข้าถึงแบบ Root หรือ sudo: เพื่อทำการติดตั้งและแก้ไขไฟล์ระบบครับ

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

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

สำหรับ 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
sudo systemctl enable nginx

ตรวจสอบให้แน่ใจว่า Firewall ของคุณ (เช่น UFW หรือ firewalld) อนุญาตการเชื่อมต่อบนพอร์ต 80 (HTTP) และ 443 (HTTPS) ด้วยนะครับ

# สำหรับ UFW (Ubuntu)
sudo ufw allow 'Nginx HTTP'
sudo ufw allow 'Nginx HTTPS'
sudo ufw enable

# สำหรับ firewalld (CentOS)
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

ขั้นตอนที่ 2: เตรียม Backend Servers (เว็บแอปพลิเคชัน)

ในตัวอย่างนี้ เราจะสมมติว่าคุณมี Backend Servers สองตัวที่รันเว็บแอปพลิเคชันอยู่บนพอร์ต 8080 (หรือพอร์ตใดๆ ที่คุณกำหนด) และมี IP Address ดังนี้ครับ:

  • Backend Server 1: 192.168.1.101:8080
  • Backend Server 2: 192.168.1.102:8080

เพื่อความง่ายในการทดสอบ คุณอาจสร้างไฟล์ index.html ง่ายๆ บนแต่ละ Backend Server เพื่อระบุว่ากำลังตอบกลับจากเซิร์ฟเวอร์ตัวไหนอยู่ครับ ตัวอย่างเช่น:

บน 192.168.1.101 (ที่ /var/www/html/index.html หรือ Directory ที่เว็บเซิร์ฟเวอร์ของคุณใช้):

<!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 (192.168.1.101)</h1>
    <p>This request was processed by the first backend server.</p>
</body>
</html>

บน 192.168.1.102 (ที่ /var/www/html/index.html หรือ Directory ที่เว็บเซิร์ฟเวอร์ของคุณใช้):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Backend Server 2</title>
</head>
<body>
    <h1>Hello from Backend Server 2 (192.168.1.102)</h1>
    <p>This request was processed by the second backend server.</p>
</body>
</html>

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

ขั้นตอนที่ 3: ตั้งค่า Nginx Reverse Proxy และ Load Balancing

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

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

สร้างไฟล์คอนฟิกใหม่ เช่น /etc/nginx/sites-available/siamlancard.conf:

sudo nano /etc/nginx/sites-available/siamlancard.conf

3.1: กำหนด Upstream Block

upstream block คือส่วนที่เราจะกำหนดกลุ่มของ Backend Servers ที่ Nginx จะใช้ในการกระจาย Traffic ครับ

upstream backend_servers {
    # Load Balancing Algorithm (จะอธิบายเพิ่มเติมในหัวข้อถัดไป)
    # เช่น round-robin (ค่าเริ่มต้น), least_conn, ip_hash
    # round-robin; # ไม่ต้องระบุก็ได้ เพราะเป็นค่าเริ่มต้น

    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    # เพิ่ม server อื่นๆ ได้ตามต้องการ
}

ในตัวอย่างนี้ เราตั้งชื่อกลุ่ม Backend Servers ว่า backend_servers และระบุ IP Address พร้อมพอร์ตของแต่ละ Backend Server ครับ Nginx จะใช้กลไก Load Balancing แบบ Round Robin เป็นค่าเริ่มต้น หากคุณไม่ได้ระบุ Algorithm อื่นๆ ครับ

3.2: กำหนด Server Block

server block คือส่วนที่ Nginx จะรับฟังคำขอจาก Client และส่งต่อคำขอเหล่านั้นไปยัง upstream block ที่เรากำหนดไว้ครับ

server {
    listen 80; # Nginx จะรับฟังคำขอ HTTP บนพอร์ต 80
    server_name your_domain.com www.your_domain.com; # ใส่ชื่อโดเมนของคุณ หรือ IP Address ของ Nginx Proxy

    location / {
        proxy_pass http://backend_servers; # ส่งต่อคำขอไปยัง upstream block ที่ชื่อ backend_servers
        proxy_set_header Host $host; # ส่งต่อ Host header ไปยัง Backend
        proxy_set_header X-Real-IP $remote_addr; # ส่งต่อ IP จริงของ Client ไปยัง Backend
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # ส่งต่อ IP Client ผ่าน proxy หลายชั้น
        proxy_set_header X-Forwarded-Proto $scheme; # ระบุโปรโตคอล (HTTP/HTTPS) ที่ใช้
    }
}

คำสั่ง proxy_pass http://backend_servers; เป็นหัวใจสำคัญที่บอกให้ Nginx ส่งต่อคำขอไปยังกลุ่ม Backend Servers ที่เรากำหนดไว้ใน upstream block ครับ

ส่วน proxy_set_header มีความสำคัญมากในการส่งผ่านข้อมูลของ Client ต้นทาง (เช่น IP Address, Hostname) ไปยัง Backend Servers ซึ่ง Backend Servers มักจะใช้ข้อมูลเหล่านี้ในการประมวลผลหรือบันทึก Log ครับ

3.3: การตั้งค่าคอนฟิกตัวอย่าง (รวม Upstream และ Server Block)

นี่คือตัวอย่างคอนฟิกแบบเต็มสำหรับ /etc/nginx/sites-available/siamlancard.conf ครับ โดยมีการเพิ่มการตั้งค่าที่แนะนำอื่นๆ เพื่อประสิทธิภาพและความเสถียรครับ

# กำหนดกลุ่ม Backend Servers สำหรับ Load Balancing
upstream backend_servers {
    # Load Balancing Algorithm: Round Robin (ค่าเริ่มต้น)
    # หากต้องการใช้ Least Connections: least_conn;
    # หากต้องการใช้ IP Hash: ip_hash;

    server 192.168.1.101:8080 weight=5 max_fails=3 fail_timeout=10s;
    server 192.168.1.102:8080 weight=1 max_fails=3 fail_timeout=10s;
    # เพิ่ม server อื่นๆ ได้ตามต้องการ
    # weight: กำหนดสัดส่วนการส่ง Traffic (server แรกได้ 5 ส่วน, server ที่สองได้ 1 ส่วน)
    # max_fails: จำนวนครั้งที่ server ตอบสนองผิดพลาดก่อนจะถูกพิจารณาว่า down
    # fail_timeout: ระยะเวลาที่ server จะถูกพิจารณาว่า down หลังจาก max_fails ถึงค่าที่กำหนด
}

# Server Block สำหรับการรับคำขอ HTTP (พอร์ต 80)
server {
    listen 80;
    server_name your_domain.com www.your_domain.com; # แทนที่ด้วยโดเมนของคุณ

    # ตั้งค่าสำหรับ Reverse Proxy
    location / {
        proxy_pass http://backend_servers; # ส่งต่อคำขอไปยัง upstream block

        # กำหนด Header เพื่อส่งข้อมูล Client ไปยัง 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;
        proxy_set_header Upgrade $http_upgrade; # สำหรับ WebSocket
        proxy_set_header Connection "upgrade"; # สำหรับ WebSocket

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

        # ปรับปรุงประสิทธิภาพของ Proxy Cache (ถ้ามีการเปิดใช้งาน)
        proxy_buffering on;
        proxy_buffers 16 4k;
        proxy_buffer_size 4k;
        proxy_max_temp_file_size 0;

        # ป้องกันการส่งต่อข้อมูลที่เป็นอันตราย
        proxy_hide_header X-Powered-By;
        proxy_hide_header Server;
    }

    # สำหรับไฟล์ Static (เช่น รูปภาพ, CSS, JS) สามารถให้ Nginx เสิร์ฟโดยตรงได้เพื่อลดภาระ Backend
    # location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
    #     root /var/www/static_files; # กำหนด path สำหรับไฟล์ static
    #     expires 30d; # กำหนด Cache Control
    #     access_log off;
    #     log_not_found off;
    # }

    # สำหรับการจัดการ Error Pages
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

คำอธิบายการตั้งค่าเพิ่มเติม:

  • weight=N: กำหนดน้ำหนักให้กับแต่ละเซิร์ฟเวอร์ ถ้า server1 มี weight=5 และ server2 มี weight=1, server1 จะได้รับ Traffic มากกว่า server2 ถึง 5 เท่าครับ
  • max_fails=N: จำนวนครั้งที่ Backend Server ล้มเหลวในการตอบสนองคำขอ (เช่น Connection refused, 5xx errors) ก่อนที่ Nginx จะถือว่าเซิร์ฟเวอร์นั้นไม่พร้อมใช้งานครับ
  • fail_timeout=Ns: ระยะเวลา (เป็นวินาที) ที่ Nginx จะหยุดส่ง Traffic ไปยัง Backend Server ที่ถูกทำเครื่องหมายว่า “down” หลังจาก fail_timeout Nginx จะลองส่งคำขออีกครั้งเพื่อตรวจสอบว่าเซิร์ฟเวอร์กลับมาใช้งานได้หรือยังครับ
  • proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout: ตั้งค่า Timeout สำหรับการเชื่อมต่อ, การส่งข้อมูล และการอ่านข้อมูลจาก Backend Servers ครับ
  • proxy_buffering on; proxy_buffers 16 4k;: การเปิดใช้งาน Buffering ช่วยให้ Nginx สามารถเก็บข้อมูลที่ได้รับจาก Backend Servers ไว้ใน Buffer ก่อนที่จะส่งต่อไปยัง Client ซึ่งช่วยปรับปรุงประสิทธิภาพโดยเฉพาะอย่างยิ่งกับ Backend Servers ที่ตอบสนองช้าครับ
  • proxy_hide_header X-Powered-By; proxy_hide_header Server;: ซ่อน Header ที่อาจเปิดเผยข้อมูลเกี่ยวกับ Backend Server ซึ่งช่วยเพิ่มความปลอดภัยได้เล็กน้อยครับ

3.4: เปิดใช้งานและทดสอบคอนฟิก

หลังจากบันทึกไฟล์ siamlancard.conf แล้ว คุณต้องเปิดใช้งานมันโดยการสร้าง Symbolic Link ไปยัง /etc/nginx/sites-enabled/ ครับ

sudo ln -s /etc/nginx/sites-available/siamlancard.conf /etc/nginx/sites-enabled/

จากนั้น ตรวจสอบความถูกต้องของคอนฟิก Nginx ก่อนที่จะ Reload บริการ:

sudo nginx -t

ถ้าคอนฟิกถูกต้อง คุณจะเห็นข้อความประมาณว่า syntax is ok และ test is successful ครับ หากมีข้อผิดพลาด Nginx จะแจ้งตำแหน่งและประเภทของข้อผิดพลาดให้คุณทราบ เพื่อให้คุณแก้ไขได้ทันท่วงทีครับ

สุดท้าย ให้ Reload Nginx เพื่อให้การตั้งค่าใหม่มีผล:

sudo systemctl reload nginx

ตอนนี้คุณสามารถลองเข้าถึงโดเมน your_domain.com (หรือ IP Address ของ Nginx Reverse Proxy) ผ่านเว็บเบราว์เซอร์ได้เลยครับ หากทุกอย่างถูกต้อง คุณควรจะเห็นหน้าเว็บที่มาจาก Backend Server สลับกันไปมาเมื่อคุณ Refresh หน้าเว็บซ้ำ ๆ (หากใช้ Round Robin) หรือตาม Algorithm ที่คุณเลือกครับ

ทำความรู้จักกับ Load Balancing Algorithms ของ Nginx

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

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

เป็น Algorithm พื้นฐานและเป็นค่าเริ่มต้นของ Nginx ครับ Nginx จะกระจายคำขอไปยัง Backend Servers แบบหมุนเวียนไปเรื่อยๆ ตามลำดับครับ

  • หลักการทำงาน: เซิร์ฟเวอร์ 1, เซิร์ฟเวอร์ 2, เซิร์ฟเวอร์ 3, เซิร์ฟเวอร์ 1, เซิร์ฟเวอร์ 2, …
  • ข้อดี: ใช้งานง่าย ตั้งค่าง่าย และกระจายโหลดได้ค่อนข้างสม่ำเสมอหาก Backend Servers มีประสิทธิภาพใกล้เคียงกันครับ
  • ข้อเสีย: ไม่ได้พิจารณาภาระงานปัจจุบันของแต่ละเซิร์ฟเวอร์ ถ้ามีเซิร์ฟเวอร์ที่ช้ากว่าหรือมีภาระงานสูงอยู่แล้ว ก็อาจจะยังได้รับ Traffic เท่าเดิมครับ
  • การตั้งค่า: ไม่ต้องระบุอะไรใน upstream block ก็ได้ หรือระบุ round-robin; (ซึ่งเป็น Nginx Plus feature, สำหรับ Open Source จะเป็น default อยู่แล้ว)
upstream backend_servers {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

Least Connections (least_conn)

Nginx จะส่งคำขอใหม่ไปยัง Backend Server ที่มีการเชื่อมต่อที่ใช้งานอยู่น้อยที่สุด (least active connections) ครับ

  • หลักการทำงาน: ตรวจสอบจำนวนการเชื่อมต่อที่กำลัง active อยู่ของแต่ละเซิร์ฟเวอร์ และส่งคำขอใหม่ไปยังเซิร์ฟเวอร์ที่มีค่าน้อยที่สุดครับ
  • ข้อดี: มีประสิทธิภาพดีเยี่ยมเมื่อ Traffic มีการกระจายที่ไม่สม่ำเสมอ หรือเมื่อ Backend Servers มีความสามารถในการประมวลผลที่แตกต่างกัน ช่วยให้เซิร์ฟเวอร์ที่มีภาระงานน้อยได้รับคำขอเพิ่มขึ้นครับ
  • ข้อเสีย: ต้องพึ่งพาการนับจำนวนการเชื่อมต่อ ซึ่งอาจไม่สะท้อนถึงภาระงานจริงเสมอไป (เช่น การเชื่อมต่อที่ active อยู่นานแต่ไม่มีการทำงาน)
  • การตั้งค่า: 
    upstream backend_servers {
            least_conn;
            server 192.168.1.101:8080;
            server 192.168.1.102:8080;
        }

IP Hash (ip_hash)

Nginx จะใช้ IP Address ของ Client ในการคำนวณ Hash เพื่อตัดสินใจว่าจะส่งคำขอไปยัง Backend Server ตัวไหนครับ ทำให้ Client เดิมจะถูกส่งไปยัง Backend Server ตัวเดิมเสมอ ตราบใดที่เซิร์ฟเวอร์นั้นยังทำงานอยู่ครับ นี่คือวิธีหนึ่งในการทำ “Sticky Sessions” ครับ

  • หลักการทำงาน: Hash IP ของ Client แล้วใช้ผลลัพธ์ในการเลือกเซิร์ฟเวอร์
  • ข้อดี: เหมาะสำหรับแอปพลิเคชันที่ต้องการ “Sticky Sessions” ซึ่งหมายถึงการที่ผู้ใช้งานคนเดิมจะต้องเชื่อมต่อกับ Backend Server ตัวเดิมตลอดการใช้งาน (เช่น แอปพลิเคชันที่เก็บ Session State ไว้ในหน่วยความจำของเซิร์ฟเวอร์นั้นๆ)
  • ข้อเสีย: อาจทำให้เกิดการกระจายโหลดที่ไม่สมดุล หาก IP Address ของ Client มีการกระจุกตัว หรือมี Traffic จาก IP เดียวกันจำนวนมาก
  • การตั้งค่า: 
    upstream backend_servers {
            ip_hash;
            server 192.168.1.101:8080;
            server 192.168.1.102:8080;
        }

Generic Hash (hash key [consistent])

คล้ายกับ IP Hash แต่ให้ความยืดหยุ่นมากขึ้นโดยอนุญาตให้คุณระบุ key ใดๆ ก็ได้ในการคำนวณ Hash ครับ เช่น คุณอาจใช้ Header, Cookie หรือ URL เป็น key ครับ

  • หลักการทำงาน: Hash ค่าของ key ที่กำหนด (เช่น $request_uri, $cookie_session) เพื่อเลือกเซิร์ฟเวอร์
  • ข้อดี: มีความยืดหยุ่นสูงในการกำหนด Logic สำหรับ Sticky Sessions หรือการแคชตาม key ที่กำหนด
  • ข้อเสีย: ต้องเลือก key ที่เหมาะสม และอาจทำให้เกิดการกระจายโหลดที่ไม่สมดุลได้เช่นกันหาก key มีการกระจุกตัว
  • การตั้งค่า: 
    upstream backend_servers {
            hash $request_uri consistent; # ใช้ URI ของคำขอเป็น key
            server 192.168.1.101:8080;
            server 192.168.1.102:8080;
        }

    consistent parameter ช่วยลดการย้ายเซสชันเมื่อมีการเพิ่มหรือลดเซิร์ฟเวอร์ในกลุ่มครับ

Random (random [two | least_time])

Nginx จะสุ่มเลือก Backend Server ครับ

  • หลักการทำงาน: สุ่มเลือกเซิร์ฟเวอร์
  • ข้อดี: ง่าย รวดเร็ว และบางครั้งมีประโยชน์ในการทดสอบ
  • ข้อเสีย: ไม่ได้พิจารณาภาระงานหรือความสามารถของเซิร์ฟเวอร์ อาจทำให้โหลดไม่สมดุล
  • การตั้งค่า: 
    upstream backend_servers {
            random; # สุ่มแบบปกติ
            # random two; # สุ่มเลือกสองเซิร์ฟเวอร์ แล้วใช้ least_conn ในการเลือกหนึ่งในสองนั้น
            # random two least_time=header; # สุ่มสอง แล้วเลือกตัวที่ตอบสนองเร็วที่สุด (สำหรับ Nginx Plus)
            server 192.168.1.101:8080;
            server 192.168.1.102:8080;
        }

Sticky Sessions (Third-party module หรือ IP Hash)

Sticky Sessions ไม่ได้เป็น Algorithm โดยตรง แต่เป็นคุณสมบัติที่ Load Balancer ต้องมีเพื่อให้ Client เดิมถูกส่งไปยัง Backend Server ตัวเดิมเสมอครับ Nginx Open Source สามารถทำ Sticky Sessions ได้ด้วย ip_hash ครับ สำหรับ Nginx Plus จะมีโมดูล sticky ที่มีความสามารถสูงกว่าและยืดหยุ่นกว่าครับ

  • ความสำคัญ: จำเป็นสำหรับแอปพลิเคชันที่เก็บสถานะของผู้ใช้งาน (Session State) ไว้ในหน่วยความจำของ Backend Server นั้นๆ หากผู้ใช้งานถูกสลับไปมาระหว่างเซิร์ฟเวอร์ อาจทำให้ Session หลุดหรือข้อมูลหายได้ครับ
  • ทางเลือกสำหรับ Nginx Open Source: ใช้ ip_hash หรือ hash ตามที่อธิบายไปแล้วครับ

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

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

Algorithm คำอธิบาย ข้อดี ข้อเสีย กรณีการใช้งานที่เหมาะสม
Round Robin กระจายคำขอแบบหมุนเวียนไปตามลำดับ ตั้งค่าง่าย, กระจายโหลดสม่ำเสมอหาก Backend มีประสิทธิภาพเท่ากัน ไม่คำนึงถึงภาระงานจริงของเซิร์ฟเวอร์, อาจเกิด Load Imbalance ได้ Backend Servers มีประสิทธิภาพเท่ากัน, ไม่ต้องการ Sticky Sessions
Least Connections ส่งคำขอไปยังเซิร์ฟเวอร์ที่มี Active Connections น้อยที่สุด ปรับสมดุลโหลดได้ดีขึ้น, เหมาะกับ Backend ที่ประสิทธิภาพต่างกัน, ตอบสนองได้ดีเมื่อมี Traffic ไม่สม่ำเสมอ การเชื่อมต่ออาจไม่สะท้อนภาระงานจริงเสมอไป Backend Servers มีประสิทธิภาพต่างกัน, ต้องการปรับสมดุลโหลดแบบไดนามิก
IP Hash ใช้ IP ของ Client คำนวณ Hash เพื่อส่งไปยังเซิร์ฟเวอร์เดิม รองรับ Sticky Sessions ได้ง่าย อาจทำให้เกิด Load Imbalance หาก IP กระจุกตัว, Traffic จาก CDN อาจถูกส่งไปเซิร์ฟเวอร์เดียว แอปพลิเคชันที่ต้องการ Sticky Sessions โดยอาศัย IP ของ Client เป็นหลัก
Generic Hash ใช้ค่า Key ที่กำหนด (เช่น URI, Cookie) คำนวณ Hash เพื่อส่งไปยังเซิร์ฟเวอร์เดิม ยืดหยุ่นกว่า IP Hash, รองรับ Sticky Sessions ที่ซับซ้อนขึ้น ต้องเลือก Key ที่เหมาะสม, อาจเกิด Load Imbalance ได้ แอปพลิเคชันที่ต้องการ Sticky Sessions หรือการแคชแบบละเอียด, กรณี IP Hash ไม่เหมาะสม
Random สุ่มเลือก Backend Server ง่ายและรวดเร็ว ไม่คำนึงถึงภาระงานหรือสถานะของเซิร์ฟเวอร์, อาจทำให้โหลดไม่สมดุลมาก การทดสอบ, หรือสถานการณ์ที่ต้องการกระจายโหลดแบบสุ่มจริง ๆ (ไม่ค่อยนิยมใช้ในการผลิต)

เคล็ดลับ: สำหรับแอปพลิเคชันส่วนใหญ่ที่ไม่มีความซับซ้อนมากนัก Least Connections มักจะเป็นตัวเลือกที่ดีที่สุดในการปรับสมดุลโหลดได้อย่างมีประสิทธิภาพครับ หากแอปพลิเคชันของคุณต้องการ Sticky Sessions และ IP Hash ไม่ได้ทำให้เกิดปัญหา Load Imbalance ก็สามารถใช้ IP Hash ได้เลยครับ หากต้องการความยืดหยุ่นมากขึ้นสำหรับ Sticky Sessions หรือ Caching ที่ละเอียดอ่อน Generic Hash จะเป็นตัวเลือกที่น่าสนใจครับ

อ่านเพิ่มเติมเกี่ยวกับการเลือก Load Balancing Algorithm ที่เหมาะสม

การตั้งค่า Health Checks สำหรับ Backend Servers

Health Checks เป็นสิ่งสำคัญอย่างยิ่งในการทำ Load Balancing ครับ Nginx จะใช้ Health Checks เพื่อตรวจสอบสถานะของ Backend Servers ว่ายังคงทำงานปกติและสามารถรับ Traffic ได้หรือไม่ หากเซิร์ฟเวอร์ใดล้มเหลว Nginx จะหยุดส่ง Traffic ไปยังเซิร์ฟเวอร์นั้นโดยอัตโนมัติ เพื่อป้องกันไม่ให้ผู้ใช้งานได้รับ Error ครับ

สำหรับ Nginx Open Source จะมี Health Checks แบบ Passive ซึ่งอาศัยพารามิเตอร์ max_fails และ fail_timeout ใน upstream block ครับ

upstream backend_servers {
    least_conn;
    server 192.168.1.101:8080 weight=5 max_fails=3 fail_timeout=10s;
    server 192.168.1.102:8080 weight=1 max_fails=3 fail_timeout=10s;
    # server 192.168.1.103:8080 backup; # เซิร์ฟเวอร์สำรอง จะถูกใช้เมื่อเซิร์ฟเวอร์หลักล้มเหลวทั้งหมด
    # server 192.168.1.104:8080 down; # ทำเครื่องหมายว่าเซิร์ฟเวอร์นี้ไม่พร้อมใช้งานชั่วคราว
}
  • max_fails=3: หมายถึง หาก Nginx ไม่สามารถเชื่อมต่อกับ Backend Server ได้ หรือ Backend Server ตอบกลับด้วย Error (เช่น 5xx) 3 ครั้งติดต่อกัน Nginx จะถือว่าเซิร์ฟเวอร์นั้น “down” ครับ (ค่าเริ่มต้นคือ 1 ครับ)
  • fail_timeout=10s: หมายถึง หลังจากที่เซิร์ฟเวอร์ถูกทำเครื่องหมายว่า “down” Nginx จะหยุดส่ง Traffic ไปยังเซิร์ฟเวอร์นั้นเป็นเวลา 10 วินาทีครับ หลังจาก 10 วินาที Nginx จะลองส่งคำขออีกครั้ง (เพียง 1 ครั้ง) เพื่อตรวจสอบว่าเซิร์ฟเวอร์กลับมาทำงานปกติหรือยัง หากกลับมาแล้วก็จะเริ่มส่ง Traffic ไปให้ตามปกติครับ

ข้อสังเกต: Nginx Open Source มีเพียง Passive Health Checks ซึ่งหมายความว่า Nginx จะตรวจจับความล้มเหลวเฉพาะเมื่อมีคำขอถูกส่งไปยัง Backend Server นั้นๆ ครับ หากไม่มีคำขอเข้า Nginx ก็จะไม่ทราบสถานะของ Backend Server ครับ สำหรับ Active Health Checks ที่ Nginx จะส่งคำขอตรวจสอบเป็นระยะๆ แม้ว่าจะไม่มี Traffic เข้ามา (เช่น ping หรือ HTTP request) จะมีอยู่ใน Nginx Plus หรือต้องใช้ Third-party modules ครับ

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

การทำ SSL/TLS Termination ที่ Reverse Proxy (ในที่นี้คือ Nginx) เป็นแนวทางที่แนะนำอย่างยิ่งครับ หรือที่เรียกว่า SSL Offloading ซึ่งมีประโยชน์หลายประการ:

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

ในการตั้งค่า SSL Termination คุณจะต้องมีใบรับรอง SSL/TLS (Certificate) สำหรับโดเมนของคุณก่อนครับ คุณสามารถขอใบรับรองฟรีได้จาก Let’s Encrypt โดยใช้ Certbot หรือซื้อจากผู้ให้บริการ SSL ครับ

สมมติว่าคุณมีใบรับรองและ Private Key อยู่ที่ /etc/letsencrypt/live/your_domain.com/fullchain.pem และ /etc/letsencrypt/live/your_domain.com/privkey.pem ตามลำดับ

เพิ่ม server block สำหรับ HTTPS (พอร์ต 443) ในไฟล์ /etc/nginx/sites-available/siamlancard.conf:

# Server Block สำหรับการรับคำขอ HTTPS (พอร์ต 443)
server {
    listen 443 ssl http2; # เปิดใช้งาน SSL และ HTTP/2
    listen [::]:443 ssl http2; # สำหรับ IPv6
    server_name your_domain.com www.your_domain.com; # แทนที่ด้วยโดเมนของคุณ

    # กำหนด Path ของใบรับรอง SSL
    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;

    # แนะนำการตั้งค่า SSL ที่ปลอดภัย
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3; # ใช้ Protocol ที่ปลอดภัย
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s; # DNS Resolver สำหรับ SSL Stapling
    resolver_timeout 5s;

    # เพิ่ม Security Headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    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";

    # การตั้งค่า Reverse Proxy เหมือนเดิม
    location / {
        proxy_pass http://backend_servers; # ส่งต่อคำขอไปยัง upstream block (เป็น HTTP เพราะ SSL ถูก Terminate ที่ Nginx แล้ว)
        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"
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        send_timeout 60s;

        proxy_buffering on;
        proxy_buffers 16 4k;
        proxy_buffer_size 4k;
        proxy_max_temp_file_size 0;

        proxy_hide_header X-Powered-By;
        proxy_hide_header Server;
    }
    # ... (ส่วน error_page หรือ static files เหมือนเดิม)
}

# Server Block สำหรับ Redirect HTTP ไป HTTPS (สำคัญมากเพื่อความปลอดภัย)
server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com www.your_domain.com;
    return 301 https://$host$request_uri; # Redirect HTTP ทั้งหมดไป HTTPS
}

หลังจากเพิ่มคอนฟิกนี้แล้ว อย่าลืมตรวจสอบ sudo nginx -t และ sudo systemctl reload nginx ด้วยนะครับ ตอนนี้เว็บไซต์ของคุณก็จะเข้าถึงผ่าน HTTPS และมีการทำ Load Balancing เรียบร้อยแล้วครับ

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

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

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

Nginx Caching (proxy_cache)

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

# ใน http block (มักจะอยู่ใน /etc/nginx/nginx.conf)
http {
    # ... การตั้งค่าอื่นๆ ...

    # กำหนดพื้นที่สำหรับ Cache
    proxy_cache_path /var/cache/nginx/siamlancard_cache levels=1:2 keys_zone=siamlancard_cache:10m inactive=60m max_size=1g;

    server {
        # ... server block ของคุณ ...

        location / {
            proxy_cache siamlancard_cache; # เปิดใช้งาน Cache ด้วยชื่อที่กำหนด
            proxy_cache_valid 200 302 10m; # Cache Response ที่เป็น 200, 302 เป็นเวลา 10 นาที
            proxy_cache_valid 404 1m; # Cache 404 error เป็นเวลา 1 นาที
            proxy_cache_bypass $http_pragma $http_authorization; # ไม่ Cache หากมี Pragma หรือ Authorization Header
            proxy_no_cache $http_pragma $http_authorization; # ไม่ใช้ Cache หากมี Pragma หรือ Authorization Header
            add_header X-Proxy-Cache $upstream_cache_status; # เพิ่ม Header เพื่อดูสถานะ Cache (HIT/MISS/BYPASS)

            proxy_pass http://backend_servers;
            # ... การตั้งค่า proxy_set_header อื่นๆ ...
        }
    }
}

อย่าลืมสร้าง Directory สำหรับ Cache และตั้งค่าสิทธิ์ให้ Nginx สามารถเขียนได้:

sudo mkdir -p /var/cache/nginx/siamlancard_cache
sudo chown -R www-data:www-data /var/cache/nginx/siamlancard_cache # สำหรับ Ubuntu/Debian
# sudo chown -R nginx:nginx /var/cache/nginx/siamlancard_cache # สำหรับ CentOS/RHEL

Rate Limiting (limit_req)

เพื่อป้องกันการโจมตีแบบ Brute-force หรือ DoS/DDoS ที่ทำให้ Backend Servers ทำงานหนักเกินไป คุณสามารถใช้ Rate Limiting เพื่อจำกัดจำนวนคำขอจาก IP Address เดียวกันในช่วงเวลาหนึ่งได้ครับ

# ใน http block (มักจะอยู่ใน /etc/nginx/nginx.conf)
http {
    # ... การตั้งค่าอื่นๆ ...

    # กำหนด Zone สำหรับ Rate Limiting
    # zone=mylimit:10m: สร้างพื้นที่หน่วยความจำขนาด 10MB สำหรับเก็บสถานะ
    # rate=10r/s: อนุญาต 10 คำขอต่อวินาที
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

    server {
        # ... server block ของคุณ ...

        location / {
            limit_req zone=mylimit burst=20 nodelay; # ใช้ Zone ที่กำหนด
            # burst=20: อนุญาตให้มี Traffic พุ่งสูงขึ้นได้ 20 คำขอ ก่อนที่จะเริ่มปฏิเสธ
            # nodelay: คำขอที่เกิน burst จะถูกปฏิเสธทันที แทนที่จะถูกหน่วงเวลา

            proxy_pass http://backend_servers;
            # ... การตั้งค่าอื่นๆ ...
        }
    }
}

หากมีคำขอเกินกว่าที่กำหนด Nginx จะตอบกลับด้วยสถานะ 503 Service Unavailable ครับ

Gzip Compression

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

# ใน http block (มักจะอยู่ใน /etc/nginx/nginx.conf)
http {
    # ... การตั้งค่าอื่นๆ ...

    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; # ประเภทไฟล์ที่จะบีบอัด

    server {
        # ... server block ของคุณ ...
    }
}

Logging

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

คุณสามารถปรับแต่งรูปแบบของ Access Log ได้ใน http block:

http {
    log_format custom_log '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for" "$upstream_addr"'; # เพิ่ม $upstream_addr

    access_log /var/log/nginx/access.log custom_log;
    error_log /var/log/nginx/error.log warn; # หรือ info, error, crit

    server {
        # ... server block ของคุณ ...
    }
}

$upstream_addr จะแสดง IP Address และพอร์ตของ Backend Server ที่ตอบกลับคำขอนั้นๆ ซึ่งมีประโยชน์มากในการตรวจสอบว่า Load Balancing ทำงานอย่างไรและ Backend Server ตัวใดมีปัญหาครับ

การแก้ไขปัญหาทั่วไป

เมื่อเกิดปัญหาในการตั้งค่า Nginx Reverse Proxy Load Balancing นี่คือแนวทางในการแก้ไขปัญหาเบื้องต้นครับ

  • Nginx ไม่เริ่มทำงานหรือไม่ยอม Reload:
    • ใช้คำสั่ง sudo nginx -t เพื่อตรวจสอบ Syntax ของไฟล์คอนฟิก Nginx ครับ คำสั่งนี้จะระบุบรรทัดและประเภทของข้อผิดพลาด ทำให้คุณแก้ไขได้ตรงจุดครับ
    • ตรวจสอบ Log files ของ Nginx: /var/log/nginx/error.log จะบอกสาเหตุที่ Nginx ไม่สามารถเริ่มทำงานได้ครับ
    • ตรวจสอบว่ามีโปรเซสอื่นกำลังใช้พอร์ต 80 หรือ 443 อยู่หรือไม่ ด้วยคำสั่ง sudo lsof -i :80 หรือ sudo netstat -tulpn | grep :80 ครับ
  • ไม่สามารถเข้าถึงเว็บไซต์ได้ หรือได้ 502 Bad Gateway:
    • ตรวจสอบว่า Backend Servers ของคุณทำงานอยู่และสามารถเข้าถึงได้จากเซิร์ฟเวอร์ Nginx ครับ ลองใช้ curl http://192.168.1.101:8080 (แทนที่ด้วย IP และพอร์ตจริงของ Backend) จากเซิร์ฟเวอร์ Nginx เพื่อทดสอบการเชื่อมต่อโดยตรงครับ
    • ตรวจสอบ Firewall บน Backend Servers ว่าอนุญาตการเชื่อมต่อจาก Nginx Reverse Proxy หรือไม่ครับ
    • ตรวจสอบคอนฟิก proxy_pass ใน Nginx ว่าชี้ไปที่ upstream block ถูกต้องหรือไม่ และชื่อ upstream block ตรงกันหรือไม่ครับ
    • ตรวจสอบ Nginx Error Log (/var/log/nginx/error.log) มักจะมีข้อมูลที่บอกสาเหตุของ 502 Error ครับ
  • Load Balancing ไม่ทำงานตามที่คาดหวัง (เช่น ไม่สลับเซิร์ฟเวอร์):
    • ตรวจสอบว่าคุณได้ระบุ Load Balancing Algorithm ที่ต้องการใน upstream block แล้วหรือไม่ครับ (เช่น least_conn; หรือ ip_hash;)
    • หากใช้ ip_hash คำขอจาก IP เดียวกันจะไปที่เซิร์ฟเวอร์เดิมเสมอ ลองทดสอบจาก IP Address ที่แตกต่างกันดูครับ
    • ตรวจสอบ weight parameter หากมีการกำหนด อาจทำให้ Traffic ไม่ถูกกระจายอย่างสม่ำเสมอตามจำนวนเซิร์ฟเวอร์ครับ
    • ตรวจสอบ Nginx Access Log หากคุณได้เพิ่ม $upstream_addr เข้าไปใน Log Format คุณจะเห็นว่าคำขอแต่ละครั้งถูกส่งไปที่ Backend Server ตัวไหนครับ
  • ปัญหา SSL/TLS (เช่น เว็บไซต์ไม่ปลอดภัย, Mixed Content):
    • ตรวจสอบ Path ของ ssl_certificate และ ssl_certificate_key ว่าถูกต้องหรือไม่ครับ
    • ตรวจสอบสิทธิ์การเข้าถึงไฟล์ใบรับรองและ Private Key ว่า Nginx สามารถอ่านได้หรือไม่ครับ
    • ตรวจสอบว่าคุณได้ Redirect HTTP ไปยัง HTTPS อย่างถูกต้องแล้วหรือไม่ครับ (return 301 https://$host$request_uri;)
    • ใช้เครื่องมือออนไลน์เช่น SSL Labs’ SSL Server Test เพื่อตรวจสอบการตั้งค่า SSL ของคุณครับ
  • ประสิทธิภาพไม่ดีเท่าที่ควร:
    • ตรวจสอบการตั้งค่า proxy_buffering, proxy_buffers และ proxy_buffer_size ครับ
    • พิจารณาเปิดใช้งาน Nginx Caching หากเนื้อหาของคุณเหมาะสม
    • ตรวจสอบ Log ของ Backend Servers เพื่อหาสาเหตุของปัญหาประสิทธิภาพจากฝั่งแอปพลิเคชันครับ
    • ตรวจสอบทรัพยากร (CPU, RAM, Disk I/O, Network) บนทั้ง Nginx Proxy และ Backend Servers ครับ

คำถามที่พบบ่อย (FAQ)

Q1: Reverse Proxy ต่างจาก Load Balancer อย่างไร?

A1: Reverse Proxy เป็นเซิร์ฟเวอร์ตัวกลางที่รับคำขอจาก Client และส่งต่อให้ Backend Server เพียง หนึ่ง ตัว (หรือกลุ่มหนึ่ง) เพื่อเพิ่มความปลอดภัย, Caching, และจัดการ SSL ครับ ส่วน Load Balancer คือเทคนิคหรืออุปกรณ์ที่ใช้ในการกระจาย Traffic ไปยัง Backend Servers หลาย ตัว เพื่อปรับสมดุลภาระงานและเพิ่มความพร้อมใช้งานครับ Nginx สามารถทำได้ทั้งสองบทบาทพร้อมกัน โดยทำหน้าที่เป็น Reverse Proxy ที่มีฟังก์ชัน Load Balancing ในตัวครับ

Q2: ทำไมต้องใช้ Nginx แทน Load Balancer อื่นๆ เช่น

บทความที่เกี่ยวข้อง

Siam2R.com — Portfolio งาน IT · XM Signal — Free Forex EA Download

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