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

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

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

สารบัญ

• Nginx Reverse Proxy Load Balancing คืออะไร?
  • ประโยชน์ของการใช้ Nginx Reverse Proxy Load Balancing
• พื้นฐานที่ควรรู้ก่อนเริ่มต้น
  • ความเข้าใจเกี่ยวกับ Nginx
  • สภาพแวดล้อมการทำงาน
• การติดตั้ง Nginx
• Nginx Reverse Proxy: การตั้งค่าพื้นฐาน
  • หลักการทำงานของ Reverse Proxy
  • ตัวอย่างการตั้งค่า Reverse Proxy
• Nginx Load Balancing: หลักการและอัลกอริทึม
  • ความสำคัญของการกระจายโหลด
  • Upstream Block ใน Nginx
  • อัลกอริทึม Load Balancing ยอดนิยม
    • Round Robin (ค่าเริ่มต้น)
    • Least Connected
    • IP Hash
    • Weighted Round Robin
• การตั้งค่า Nginx Reverse Proxy Load Balancing แบบสมบูรณ์
  • โครงสร้างไฟล์คอนฟิกที่แนะนำ
  • ตัวอย่างคอนฟิกเต็มรูปแบบ
• การจัดการ SSL/TLS กับ Nginx Load Balancer
  • SSL Termination ที่ Nginx
  • การตั้งค่า SSL/TLS
• คุณสมบัติขั้นสูงและการปรับแต่ง
  • Health Checks
  • Session Persistence (Sticky Sessions)
  • Caching ด้วย Nginx
  • Rate Limiting
  • การบีบอัดข้อมูล (Gzip Compression)
• การตรวจสอบและแก้ไขปัญหา (Monitoring & Troubleshooting)
  • Log Files
  • Nginx Stub Status Module
  • เครื่องมือภายนอก (Prometheus, Grafana)
• เปรียบเทียบอัลกอริทึม Load Balancing ของ Nginx
• คำถามที่พบบ่อย (FAQ)
• สรุป
• พร้อมยกระดับโครงสร้างพื้นฐานของคุณแล้วหรือยัง?

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

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

Reverse Proxy

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

• Reverse Proxy ทำอะไร?
  • รับคำขอจาก Client (ผู้ใช้งาน)
  • ส่งต่อคำขอเหล่านั้นไปยัง Backend Server ที่เหมาะสม (เช่น Web Server, Application Server)
  • รับคำตอบจาก Backend Server และส่งกลับไปยัง Client

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

Load Balancing

Load Balancing คือกระบวนการกระจายปริมาณงาน (Workload) หรือคำขอ (Requests) จากผู้ใช้งานไปยังเซิร์ฟเวอร์หลาย ๆ ตัวอย่างสม่ำเสมอ เพื่อป้องกันไม่ให้เซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งทำงานหนักเกินไปจนเกิดปัญหาคอขวด (Bottleneck) หรือล่มครับ

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

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

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

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

• เพิ่มความสามารถในการปรับขนาด (Scalability): คุณสามารถเพิ่ม Backend Servers ได้ง่าย ๆ เพื่อรองรับปริมาณทราฟฟิกที่เพิ่มขึ้น โดยไม่ต้องปรับเปลี่ยน IP Address หรือ DNS ของแอปพลิเคชันหลักครับ Nginx จะช่วยกระจายโหลดไปยังเซิร์ฟเวอร์ใหม่โดยอัตโนมัติ
• เพิ่มความน่าเชื่อถือและความพร้อมใช้งานสูง (High Availability): หาก Backend Server ตัวใดตัวหนึ่งเกิดล้มเหลว Nginx จะตรวจพบและหยุดส่งคำขอไปยังเซิร์ฟเวอร์นั้นชั่วคราว และจะกระจายคำขอไปยังเซิร์ฟเวอร์อื่น ๆ ที่ยังคงทำงานได้ตามปกติ ทำให้บริการของคุณยังคงออนไลน์อยู่ได้ตลอดเวลา
• ปรับปรุงประสิทธิภาพ (Performance): Nginx สามารถทำหน้าที่เป็น Cache Server ได้ ซึ่งจะช่วยลดภาระงานของ Backend Servers และส่งผลให้เว็บไซต์หรือแอปพลิเคชันของคุณตอบสนองได้เร็วขึ้น นอกจากนี้ Nginx ยังสามารถจัดการ SSL/TLS Termination และ Gzip Compression ได้อย่างมีประสิทธิภาพ
• เพิ่มความปลอดภัย (Security): Reverse Proxy ทำหน้าที่เป็นด่านหน้า ป้องกัน Backend Servers จากการโจมตีโดยตรง ผู้โจมตีจะไม่รู้ IP Address ที่แท้จริงของ Backend Servers ทำให้การโจมตีทำได้ยากขึ้น นอกจากนี้ Nginx ยังมีฟังก์ชันการจำกัดอัตราคำขอ (Rate Limiting) เพื่อป้องกันการโจมตีแบบ DDoS หรือ Brute-force ได้อีกด้วยครับ
• ความยืดหยุ่นในการจัดการ (Flexibility): Nginx ช่วยให้คุณสามารถจัดการทราฟฟิกได้อย่างยืดหยุ่น เช่น การ Redirect คำขอ, การ Rewrite URL, การกำหนดเส้นทางคำขอไปยัง Backend Servers ที่แตกต่างกันตามประเภทของคำขอ หรือการจัดการ Static Files โดยตรง

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

ความเข้าใจเกี่ยวกับ Nginx

Nginx (อ่านว่า Engine-X) เป็นเว็บเซิร์ฟเวอร์แบบ Open Source ที่มีประสิทธิภาพสูง สามารถทำหน้าที่ได้หลากหลาย เช่น Web Server, Reverse Proxy, Load Balancer, Mail Proxy และ HTTP Cache ครับ Nginx ขึ้นชื่อเรื่องความสามารถในการจัดการการเชื่อมต่อพร้อมกันจำนวนมากได้อย่างมีประสิทธิภาพด้วยสถาปัตยกรรมแบบ event-driven, asynchronous ซึ่งแตกต่างจากเว็บเซิร์ฟเวอร์แบบเดิมที่ใช้กระบวนการแบบ thread-per-connection ครับ

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

สภาพแวดล้อมการทำงาน

เพื่อให้เห็นภาพและสามารถทดลองตั้งค่าตามได้จริง เราจะสมมติโครงสร้างพื้นฐานดังนี้ครับ

• Nginx Server (Load Balancer/Reverse Proxy): 1 เครื่อง
  • IP Address: 192.168.1.50 (หรือ IP Public ที่คุณใช้)
  • ทำหน้าที่รับคำขอจากผู้ใช้งานและกระจายโหลด
• Backend Servers (Web/Application Servers): อย่างน้อย 2 เครื่องขึ้นไป
  • Backend Server 1: 192.168.1.100:8080
  • Backend Server 2: 192.168.1.101:8080
  • (และอาจจะมี Backend Server 3: 192.168.1.102:8080)
  • เซิร์ฟเวอร์เหล่านี้จะรันแอปพลิเคชันหรือเว็บเซิร์ฟเวอร์จริง ๆ (เช่น Node.js, Python Flask, Apache, Tomcat) ที่พอร์ต 8080 หรือพอร์ตอื่น ๆ ตามที่คุณกำหนดครับ
• Domain Name: your_domain.com (ชี้มาที่ IP ของ Nginx Server)

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

การติดตั้ง Nginx

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

สำหรับระบบปฏิบัติการ 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 start nginx
sudo systemctl enable nginx

คุณสามารถตรวจสอบสถานะของ Nginx ได้โดยใช้คำสั่ง:

sudo systemctl status nginx

หากทุกอย่างถูกต้อง คุณควรจะเห็นสถานะเป็น active (running) ครับ

ถ้าคุณมี Firewall (เช่น UFW บน Ubuntu หรือ firewalld บน CentOS) ให้เปิดพอร์ต 80 (HTTP) และ 443 (HTTPS) เพื่อให้ผู้ใช้งานสามารถเข้าถึงได้ครับ

สำหรับ UFW:

sudo ufw allow 'Nginx HTTP'
sudo ufw allow 'Nginx HTTPS'
sudo ufw enable

สำหรับ firewalld:

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

Nginx Reverse Proxy: การตั้งค่าพื้นฐาน

หลักการทำงานของ Reverse Proxy

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

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

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

สร้างไฟล์ /etc/nginx/conf.d/my-app.conf:

server {
    listen 80;
    server_name your_domain.com www.your_domain.com; # แทนที่ด้วยชื่อโดเมนของคุณ

    location / {
        proxy_pass http://192.168.1.100:8080; # IP และ Port ของ Backend Server ของคุณ
        
        # ส่วนหัว (Headers) ที่สำคัญสำหรับการส่งต่อข้อมูล
        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_redirect off; # ป้องกันการเปลี่ยนเส้นทาง URL ที่ไม่พึงประสงค์
    }

    # คุณสามารถเพิ่ม location blocks สำหรับ path อื่นๆ ได้
    # เช่น location /api/ { proxy_pass http://api_backend_server; }
}

คำอธิบาย Directives ที่สำคัญ:

• listen 80;: Nginx จะรับฟังคำขอที่พอร์ต 80 (HTTP)
• server_name your_domain.com www.your_domain.com;: กำหนดชื่อโดเมนที่ Nginx จะตอบสนอง
• location / { ... }: บล็อกนี้จะจัดการคำขอทั้งหมดที่เข้ามา (path /)
• proxy_pass http://192.168.1.100:8080;: นี่คือหัวใจของการทำ Reverse Proxy ครับ มันบอก Nginx ให้ส่งต่อคำขอทั้งหมดที่เข้ามาใน location / ไปยัง Backend Server ที่มี IP 192.168.1.100 และพอร์ต 8080
• proxy_set_header Host $host;: ส่งต่อ Host header เดิมของ Client ไปยัง Backend Server ซึ่งจำเป็นอย่างยิ่งสำหรับแอปพลิเคชันที่ใช้ Host header ในการทำงาน
• proxy_set_header X-Real-IP $remote_addr;: ส่งต่อ IP Address จริงของ Client ไปยัง Backend Server หากไม่มีสิ่งนี้ Backend Server จะเห็นเพียง IP ของ Nginx Proxy เท่านั้นครับ
• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;: ส่งต่อ IP Address ของ Client รวมถึง IP ของ Proxy อื่น ๆ ที่อยู่ระหว่างทาง ทำให้ Backend Server ทราบเส้นทางของคำขอได้
• proxy_set_header X-Forwarded-Proto $scheme;: ระบุโปรโตคอล (HTTP หรือ HTTPS) ที่ Client ใช้ในการเชื่อมต่อกับ Nginx
• proxy_redirect off;: ปิดการทำงานของ proxy_redirect ซึ่งบางครั้ง Backend Server อาจส่ง Redirect Header กลับมาพร้อมกับ Hostname ภายใน ทำให้ Client ถูก Redirect ไปยัง Hostname ภายในแทนที่จะเป็นโดเมนสาธารณะครับ

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

sudo nginx -t
sudo systemctl reload nginx

หากคำสั่ง nginx -t แสดง syntax is ok และ test is successful แสดงว่าคอนฟิกของคุณถูกต้องครับ

ตอนนี้ หากคุณเข้าถึง your_domain.com (หรือ IP ของ Nginx Server) คุณจะเห็นเนื้อหาที่มาจาก Backend Server 192.168.1.100:8080 ครับ

Nginx Load Balancing: หลักการและอัลกอริทึม

ความสำคัญของการกระจายโหลด

การทำ Reverse Proxy เพียงอย่างเดียวอาจจะยังไม่เพียงพอต่อความต้องการในระบบที่มีผู้ใช้งานจำนวนมากครับ เพราะหากคุณมี Backend Server เพียงเครื่องเดียว Reverse Proxy ก็จะทำหน้าที่แค่ส่งต่อคำขอทั้งหมดไปที่เซิร์ฟเวอร์นั้น ซึ่งก็ยังคงเป็น Single Point of Failure และมีข้อจำกัดด้าน Scalability อยู่ดีครับ

นี่คือเหตุผลที่เราต้องการ Load Balancing เพื่อกระจายคำขอไปยัง Backend Servers หลาย ๆ ตัวครับ

Upstream Block ใน Nginx

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

ตัวอย่าง:

upstream myapp_backend {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    # สามารถเพิ่ม server อื่นๆ ได้อีก
}

จากนั้นใน location block คุณจะเปลี่ยน proxy_pass ให้ชี้ไปยังชื่อของ upstream block แทน IP Address โดยตรงครับ:

location / {
    proxy_pass http://myapp_backend; # ชี้ไปที่ upstream block
    # ... other proxy settings ...
}

เมื่อทำเช่นนี้ Nginx จะรับผิดชอบในการเลือก Backend Server ที่เหมาะสมจากกลุ่ม myapp_backend เพื่อส่งต่อคำขอไปให้ครับ

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

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

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

เป็นอัลกอริทึมที่ง่ายที่สุดและเป็นค่าเริ่มต้นของ Nginx ครับ Round Robin จะกระจายคำขอไปยัง Backend Servers ทีละตัวตามลำดับ เช่น คำขอแรกไป Server 1, คำขอที่สองไป Server 2, คำขอที่สามไป Server 1 อีกครั้ง และวนไปเรื่อย ๆ ครับ

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

ตัวอย่างคอนฟิก (ไม่ต้องระบุอัลกอริทึม เพราะเป็นค่าเริ่มต้น):

upstream myapp_backend {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080; # เพิ่ม Backend Server ตัวที่ 3
}

Least Connected

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

• เหมาะสำหรับ: แอปพลิเคชันที่มีการเชื่อมต่อยาวนาน (long-lived connections) เช่น WebSocket หรือฐานข้อมูล, หรือเมื่อ Backend Servers มีความสามารถในการประมวลผลที่แตกต่างกัน
• ข้อดี: มีประสิทธิภาพดีกว่า Round Robin ในสถานการณ์ที่คำขอใช้เวลาประมวลผลไม่เท่ากัน เพราะจะพิจารณาโหลดจริงของเซิร์ฟเวอร์
• ข้อจำกัด: อาจไม่เหมาะกับแอปพลิเคชันที่มีการเชื่อมต่อสั้น ๆ จำนวนมาก เพราะการประเมิน “Least Connected” อาจไม่สะท้อนภาระงานที่แท้จริง

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

upstream myapp_backend {
    least_conn; # ระบุอัลกอริทึม Least Connected
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

IP Hash

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

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

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

upstream myapp_backend {
    ip_hash; # ระบุอัลกอริทึม IP Hash
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

Weighted Round Robin

เป็นส่วนเสริมของ Round Robin ครับ คุณสามารถกำหนด “น้ำหนัก” (weight) ให้กับแต่ละ Backend Server เพื่อบอก Nginx ว่าควรส่งคำขอไปยังเซิร์ฟเวอร์นั้นบ่อยแค่ไหนเมื่อเทียบกับเซิร์ฟเวอร์อื่น ๆ

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

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

upstream myapp_backend {
    server 192.168.1.100:8080 weight=3; # Server นี้จะได้รับคำขอ 3 เท่าของ Server อื่นๆ
    server 192.168.1.101:8080 weight=1;
    server 192.168.1.102:8080; # ค่าเริ่มต้น weight=1
}

จากตัวอย่างนี้ Server 192.168.1.100 จะได้รับคำขอ 3 ใน 5 ครั้ง, Server 192.168.1.101 ได้รับ 1 ใน 5 ครั้ง, และ Server 192.168.1.102 ได้รับ 1 ใน 5 ครั้งครับ

การตั้งค่า Nginx Reverse Proxy Load Balancing แบบสมบูรณ์

โครงสร้างไฟล์คอนฟิกที่แนะนำ

เพื่อความเป็นระเบียบและง่ายต่อการจัดการ ควรแยกส่วน upstream ออกจาก server block ครับ

• ไฟล์ /etc/nginx/conf.d/upstream.conf: ใช้สำหรับเก็บ upstream block ทั้งหมดของคุณ
• ไฟล์ /etc/nginx/conf.d/loadbalancer.conf: ใช้สำหรับเก็บ server block ที่ทำหน้าที่เป็น Reverse Proxy และ Load Balancer

Nginx จะอ่านไฟล์ทั้งหมดในไดเรกทอรี conf.d (ที่ถูก include ไว้ใน nginx.conf หลัก) ทำให้การแยกไฟล์ช่วยให้จัดการได้ง่ายขึ้นครับ

ตัวอย่างคอนฟิกเต็มรูปแบบ

1. สร้างไฟล์ /etc/nginx/conf.d/upstream.conf

ในไฟล์นี้ เราจะกำหนดกลุ่มของ Backend Servers ที่ Nginx จะกระจายโหลดไปให้ครับ ในตัวอย่างนี้เราจะใช้อัลกอริทึม Round Robin (ค่าเริ่มต้น) พร้อมกับใช้ weight, backup และ down directives

upstream myapp_servers {
    # อัลกอริทึม Load Balancing (Round Robin เป็นค่าเริ่มต้น)
    # หากต้องการ Least Connected: least_conn;
    # หากต้องการ IP Hash: ip_hash;

    server 192.168.1.100:8080 weight=2 max_fails=3 fail_timeout=30s;
    server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.102:8080 backup; # เซิร์ฟเวอร์สำรอง จะถูกใช้เมื่อเซิร์ฟเวอร์หลักล้มเหลวทั้งหมด
    # server 192.168.1.103:8080 down; # เซิร์ฟเวอร์นี้จะถูกปิดใช้งานชั่วคราว (ใช้เมื่อต้องการบำรุงรักษา)
}

คำอธิบายเพิ่มเติมเกี่ยวกับ Directives ใน upstream block:

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

2. สร้างไฟล์ /etc/nginx/conf.d/loadbalancer.conf

ไฟล์นี้จะทำหน้าที่เป็น Reverse Proxy และใช้ upstream block ที่เราสร้างไว้ครับ

server {
    listen 80;
    server_name your_loadbalanced_domain.com www.your_loadbalanced_domain.com;

    # Optional: ตั้งค่า timeout สำหรับการเชื่อมต่อไปยัง backend
    proxy_connect_timeout 5s;   # เวลาที่ Nginx รอการเชื่อมต่อกับ backend
    proxy_send_timeout 5s;      # เวลาที่ Nginx รอให้ backend ส่งข้อมูลกลับ
    proxy_read_timeout 10s;     # เวลาที่ Nginx รอให้ backend อ่านข้อมูลจาก Nginx

    location / {
        proxy_pass http://myapp_servers; # ชี้ไปที่ upstream block ที่เราสร้างไว้
        
        # Headers ที่สำคัญ
        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_redirect off;

        # การจัดการข้อผิดพลาด (Error Pages)
        # error_page 500 502 503 504 /50x.html;
        # location = /50x.html {
        #     root /usr/share/nginx/html;
        # }
    }

    # หากคุณมี static files ที่ต้องการให้ Nginx จัดการโดยตรง
    # location ~* \.(css|js|gif|jpe?g|png)$ {
    #     root /var/www/your_domain/static; # กำหนด path ไปยัง static files
    #     expires 30d;
    # }
}

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

sudo nginx -t
sudo systemctl reload nginx

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

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

การจัดการ SSL/TLS กับ Nginx Load Balancer

ในปัจจุบัน การเข้ารหัสการเชื่อมต่อด้วย SSL/TLS (HTTPS) ถือเป็นสิ่งจำเป็นอย่างยิ่งสำหรับทุกเว็บไซต์ครับ Nginx สามารถทำหน้าที่เป็น SSL Terminator ได้อย่างมีประสิทธิภาพ หมายความว่า Nginx จะเป็นจุดแรกที่รับการเชื่อมต่อ HTTPS จาก Client ถอดรหัส (decrypt) ข้อมูล แล้วส่งต่อคำขอไปยัง Backend Servers ด้วย HTTP ธรรมดา (หรือ HTTPS อีกครั้งก็ได้)

SSL Termination ที่ Nginx

ประโยชน์ของการทำ SSL Termination ที่ Nginx:

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

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

การตั้งค่า SSL/TLS บน Nginx ทำได้โดยเพิ่ม listen 443 ssl; และกำหนดไฟล์ Certificate กับ Private Key ครับ

ในตัวอย่างนี้ เราจะใช้ Let’s Encrypt ซึ่งเป็นวิธีที่ได้รับความนิยมและฟรีในการรับ SSL Certificate ครับ (คุณจะต้องติดตั้ง Certbot ก่อน)

ขั้นตอน (โดยย่อสำหรับ Let’s Encrypt):

1. ติดตั้ง Certbot: https://certbot.eff.org/instructions
2. รันคำสั่งเพื่อขอ Certificate สำหรับโดเมนของคุณ (หลังจากตั้งค่า Nginx Server block สำหรับ HTTP แล้ว):

   sudo certbot --nginx -d your_loadbalanced_domain.com -d www.your_loadbalanced_domain.com

   Certbot จะจัดการการสร้างไฟล์คอนฟิก SSL ให้โดยอัตโนมัติ และมักจะสร้างไฟล์ใหม่ใน /etc/nginx/sites-available/ หรือแก้ไขไฟล์เดิมครับ

ตัวอย่างคอนฟิก Nginx สำหรับ HTTPS:

สมมติว่า Certbot ได้สร้างไฟล์ /etc/letsencrypt/live/your_loadbalanced_domain.com/fullchain.pem (สำหรับ certificate) และ privkey.pem (สำหรับ private key) ให้คุณแล้วครับ

server {
    listen 443 ssl http2; # เปิดใช้งาน HTTPS และ HTTP/2
    listen [::]:443 ssl http2; # สำหรับ IPv6

    server_name your_loadbalanced_domain.com www.your_loadbalanced_domain.com;

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

    # แนะนำการตั้งค่า SSL Security Best Practices
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1h;
    ssl_protocols TLSv1.2 TLSv1.3; # แนะนำให้ใช้ TLSv1.2 และ TLSv1.3 เท่านั้น
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on; # ให้เซิร์ฟเวอร์เลือก cipher suite ที่ปลอดภัยและมีประสิทธิภาพ

    # Optional: เปิดใช้งาน HSTS (HTTP Strict Transport Security)
    # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        proxy_pass http://myapp_servers; # ส่งต่อคำขอไปยัง upstream block (อาจเป็น HTTP หรือ HTTPS ก็ได้)
        
        # Headers ที่สำคัญ
        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; # สำคัญเพื่อให้ Backend รู้ว่ามาจาก HTTPS
        proxy_redirect off;

        proxy_connect_timeout 5s;
        proxy_send_timeout 5s;
        proxy_read_timeout 10s;
    }
}

การทำ Redirect HTTP to HTTPS:

เพื่อให้มั่นใจว่าผู้ใช้งานทุกคนจะเข้าถึงเว็บไซต์ของคุณผ่าน HTTPS เสมอ ควรตั้งค่า Redirect จาก HTTP ไปยัง HTTPS ครับ

คุณสามารถเพิ่ม server block แยกต่างหากสำหรับ HTTP:

server {
    listen 80;
    listen [::]:80;
    server_name your_loadbalanced_domain.com www.your_loadbalanced_domain.com;
    return 301 https://$host$request_uri; # Redirect ไปยัง HTTPS
}

เมื่อตั้งค่าเสร็จแล้ว ให้ทดสอบคอนฟิกและรีโหลด Nginx เหมือนเดิมครับ

sudo nginx -t
sudo systemctl reload nginx

ตอนนี้เว็บไซต์ของคุณจะถูกเข้าถึงผ่าน HTTPS และ Nginx จะจัดการ SSL Termination ก่อนที่จะส่งคำขอไปยัง Backend Servers ครับ

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

Health Checks

การทำ Health Checks คือการตรวจสอบสถานะของ Backend Servers อย่างต่อเนื่องเพื่อให้ Nginx รู้ว่าเซิร์ฟเวอร์ตัวไหนพร้อมให้บริการบ้างครับ

• Nginx OSS (Open Source): มี Health Check แบบพื้นฐานผ่าน max_fails และ fail_timeout ใน upstream block ซึ่งเราได้เห็นไปแล้วในตัวอย่างก่อนหน้านี้ครับ Nginx จะลองเชื่อมต่อไปยังเซิร์ฟเวอร์นั้น ๆ หากการเชื่อมต่อล้มเหลวตามจำนวนครั้งที่กำหนดภายในระยะเวลา fail_timeout เซิร์ฟเวอร์นั้นก็จะถูกพิจารณาว่าไม่พร้อมใช้งานชั่วคราว
• Nginx Plus: สำหรับ Nginx Plus (เวอร์ชันเชิงพาณิชย์) มี Health Check ที่ซับซ้อนและละเอียดกว่ามาก เช่น การตรวจสอบสถานะของ URL ที่ระบุ, การส่งคำขอ HTTP เพื่อตรวจสอบการตอบสนอง

สำหรับ Nginx OSS หากคุณต้องการ Health Check ที่ซับซ้อนขึ้น อาจจะต้องใช้เครื่องมือภายนอก (เช่น Nagios, Zabbix, Prometheus หรือสคริปต์แบบกำหนดเอง) ในการตรวจสอบสถานะของ Backend Servers และใช้ Nginx API หรือการแก้ไขคอนฟิกไฟล์เพื่อ down หรือ up เซิร์ฟเวอร์ที่ไม่พร้อมใช้งานครับ

Session Persistence (Sticky Sessions)

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

• IP Hash: เป็นวิธีที่ง่ายที่สุดใน Nginx OSS ที่ช่วยให้เกิด Session Persistence โดยใช้ IP ของ Client เพื่อกำหนดเซิร์ฟเวอร์ครับ อย่างไรก็ตาม มีข้อจำกัดตามที่ได้กล่าวไปแล้ว
• Cookie-based sticky sessions (Nginx Plus): Nginx Plus มีฟังก์ชันที่สามารถใช้ Cookie ในการกำหนด Session Persistence ได้ ซึ่งมีความยืดหยุ่นและแม่นยำกว่า IP Hash ครับ

หากคุณใช้ Nginx OSS และต้องการ Session Persistence ที่ซับซ้อนกว่า IP Hash อาจจะต้องพิจารณากลไกในระดับแอปพลิเคชัน (เช่น การใช้ Redis, Memcached สำหรับ Session Storage ร่วมกัน) หรือพิจารณา Nginx Plus ครับ

Caching ด้วย Nginx

Nginx สามารถทำหน้าที่เป็น Reverse Proxy Cache ได้ ซึ่งช่วยลดภาระงานของ Backend Servers และปรับปรุงความเร็วในการตอบสนองได้อย่างมากครับ โดย Nginx จะเก็บสำเนาของเนื้อหาที่ถูกร้องขอไว้ และส่งคืนสำเเนาเหล่านั้นในการร้องขอครั้งถัดไปโดยไม่ต้องไปดึงจาก Backend Servers อีก

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

# กำหนด path สำหรับเก็บ cache, ขนาด, และระยะเวลาของ zone
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;

server {
    listen 80;
    server_name your_domain.com;

    location / {
        proxy_cache my_cache; # เปิดใช้งาน cache zone ชื่อ my_cache
        proxy_cache_valid 200 302 10m; # Cache response ที่มีสถานะ 200, 302 เป็นเวลา 10 นาที
        proxy_cache_valid 404 1m;      # Cache response ที่มีสถานะ 404 เป็นเวลา 1 นาที

        # ตั้งค่า Cache key
        proxy_cache_key "$scheme$request_method$host$request_uri";

        # Optional: เพิ่ม header เพื่อตรวจสอบว่า cache ทำงานหรือไม่
        add_header X-Proxy-Cache $upstream_cache_status;

        proxy_pass http://myapp_servers;
        # ... other proxy settings ...
    }
}

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

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

Rate Limiting

Rate Limiting คือการจำกัดจำนวนคำขอที่ Client รายใดรายหนึ่งสามารถส่งมายังเซิร์ฟเวอร์ได้ภายในระยะเวลาที่กำหนด ซึ่งมีประโยชน์ในการป้องกันการโจมตีแบบ DDoS, Brute-force หรือการใช้งาน API เกินขีดจำกัดครับ

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

# กำหนด zone สำหรับ limit request
# $binary_remote_addr: ใช้ IP address ของ client เป็น key
# zone=mylimit:10m: สร้าง zone ชื่อ mylimit ขนาด 10MB
# rate=5r/s: อนุญาตให้ 5 คำขอต่อวินาที
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

server {
    listen 80;
    server_name your_domain.com;

    location /api/ {
        limit_req zone=mylimit burst=10 nodelay; # ใช้ zone mylimit
                                                # burst=10: อนุญาตให้มีคำขอเกิน rate ได้ 10 คำขอในคราวเดียว
                                                # nodelay: คำขอที่เกิน burst จะถูกปฏิเสธทันที
                                                # (ถ้าไม่มี nodelay คำขอที่เกิน burst จะถูกหน่วงเวลา)
        proxy_pass http://myapp_servers;
        # ...
    }

    location / {
        # สำหรับ path อื่นๆ อาจจะใช้ limit ที่แตกต่างกัน
        limit_req zone=mylimit burst=5;
        proxy_pass http://myapp_servers;
        # ...
    }
}

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

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

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

ตัวอย่างคอนฟิก Gzip:

# เปิดใช้งาน Gzip compression
gzip on;
gzip_vary on; # เพิ่ม Vary: Accept-Encoding header
gzip_proxied any; # บีบอัดข้อมูลที่มาจาก proxy backend
gzip_comp_level 6; # ระดับการบีบอัด (1-9, 6 เป็นค่าที่สมดุล)
gzip_buffers 16 8k; # จำนวนและขนาด buffer
gzip_http_version 1.1; # กำหนด HTTP version ที่รองรับ gzip
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml; # ประเภทไฟล์ที่จะบีบอัด
gzip_min_length 1000; # บีบอัดไฟล์ที่มีขนาดอย่างน้อย 1000 bytes

คุณสามารถเพิ่ม Directives เหล่านี้ใน http block ใน nginx.conf หลัก หรือใน server block ของคุณได้เลยครับ

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

การตรวจสอบและแก้ไขปัญหา (Monitoring & Troubleshooting)

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

Log Files

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

• Access Logs: บันทึกข้อมูลคำขอทั้งหมดที่ Nginx ได้รับ เช่น IP ของ Client, เวลา, URL ที่ร้องขอ, สถานะการตอบกลับ, ขนาดการตอบกลับ
• Error Logs: บันทึกข้อผิดพลาดที่เกิดขึ้นกับ Nginx เช่น การเชื่อมต่อล้มเหลว, ข้อผิดพลาดในการประมวลผลคำขอ, ปัญหาการตั้งค่า

โดยทั่วไปไฟล์ Log จะอยู่ที่ /var/log/nginx/access.log และ /var/log/nginx/error.log ครับ

คุณสามารถปรับแต่ง Log Format ได้ในไฟล์ nginx.conf:

http

    	
บทความที่เกี่ยวข้อง
Docker Compose สำหรับ Production ใช้งานจริง 2026
Cloud Networking: VPC, Subnet, Security Group, Transit Gateway, PrivateLink และ Multi-Cloud
Print Management คู่มือจัดการระบบพิมพ์สำหรับองค์กร
XM Signal — Free Forex EA Download · iCafeForex.com — EA Forex และเครื่องมือเทรด