วิธีแก้ปัญหา Nginx 502 และ 504 Gateway Errors
แนวทางปฏิบัติในการวินิจฉัยและแก้ไขปัญหา Nginx 502 และ 504 Gateway Errors ตั้งแต่เรื่อง upstream timeouts ไปจนถึงข้อจำกัดของ worker
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ข้อผิดพลาด 502 เกิดจากระบบต้นทางล่มหรือส่งข้อมูลไม่ถูกต้อง
- ข้อผิดพลาด 504 เกิดจากระบบต้นทางตอบสนองช้าเกินไปจนหมดเวลา
- ตรวจสอบ log ด้วยคำสั่ง grep เพื่อแยกแยะปัญหาได้อย่างแม่นยำ
- ปรับแต่ง timeout และ buffer ให้เหมาะสมพร้อมตั้งค่าแจ้งเตือน
ปัญหาคลื่นข้อผิดพลาด 502 และ 504 ถือเป็นหนึ่งในเรื่องที่น่าหงุดหงิดที่สุดในการดีบักภายใต้ความกดดัน เมื่อ Nginx ทำงานปกติและเซิร์ฟเวอร์แอปพลิเคชันดูเหมือนจะเปิดอยู่ แต่ผู้ใช้กลับพบข้อผิดพลาดเกตเวย์ ปัญหาเหล่านี้แทบไม่เคยเกิดขึ้นตัว Nginx เอง แต่มักซ่อนอยู่ในการสื่อสารระหว่าง Nginx และระบบที่อยู่เบื้องหลัง
ข้อผิดพลาด 502 Bad Gateway หมายความว่า Nginx ได้รับการตอบกลับจากระบบต้นทาง แต่การตอบกลับนั้นไม่ถูกต้อง ไม่สมบูรณ์ หรือมาจากกระบวนการที่แครช ขณะที่ 504 Gateway Timeout หมายความว่า Nginx ยอมแพ้ในการรอเพราะระบบต้นทางใช้เวลานานเกินไปในการตอบสนอง การตรวจสอบ log ข้อผิดพลาดของ Nginx จึงเป็นขั้นตอนแรกที่สำคัญ
คุณสามารถเรียกดูข้อผิดพลาด upstream ล่าสุดจำนวน 50 รายการแบบเรียลไทม์ได้ด้วยคำสั่ง sudo tail -n 50 /var/log/nginx/error.log | grep upstream เพื่อค้นหาข้อความเช่น connect() failed หรือ upstream timed out ซึ่งช่วยแยกแยะระหว่างกระบวนการแครชและแบ็กพินด์ที่ทำงานช้าได้ทันที
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อระบบต้นทางซึ่งอาจเป็นแอป Node, Python/gunicorn หรือ PHP-FPM เกิดหยุดทำงานหรือหน่วยความจำ worker ไม่พอ การตั้งค่า timeout และ buffer จึงเป็นกุญแจสำคัญในการจัดการคำขอขนาดใหญ่ เช่น การเพิ่มค่า proxy_buffer_size ให้รองรับคุกกี้หรือโทเค็น JWT จำนวนมาก
การทำความเข้าใจความแตกต่างระหว่าง 502 และ 504 ช่วยให้ทีมพัฒนาสามารถกำหนดทิศทางในการแก้ปัญหาได้ตรงจุด แทนที่จะเป็นการปรับค่า timeout ให้สูงขึ้นอย่างไร้จุดหมาย ซึ่งอาจเป็นการซ่อนปัญหาคอขวดที่แท้จริงเอาไว้เบื้องหลังการรอคอยที่ยาวนานขึ้น
ก่อนที่จะทำการโหลดการตั้งค่า Nginx ใหม่ทุกครั้ง ควรทดสอบด้วยคำสั่ง nginx -t เสมอเพื่อป้องกันไม่ให้เซิร์ฟเวอร์ล่มทั้งระบบ จากนั้นใช้คำสั่ง systemctl reload nginx เพื่อความนุ่มนวลในการรักษาการเชื่อมต่อที่มีอยู่
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น