502 vs 504 vs 500 Error: เปรียบเทียบข้อผิดพลาดเซิร์ฟเวอร์และวิธีแก้ปัญหาฉบับสมบูรณ์

เข้าใจ Error ยอดนิยมบนเว็บเซิร์ฟเวอร์: 502, 504, และ 500

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

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

วันนี้ผมจะเปรียบเทียบ error 502, 504, และ 500 อย่างละเอียด พร้อมแนะนำวิธีจัดการในแต่ละกรณี เพื่อให้คุณสามารถตัดสินใจได้อย่างรวดเร็ว

Error 502 Bad Gateway คืออะไร

502 Bad Gateway เป็นข้อผิดพลาดที่เกิดเมื่อ reverse proxy หรือ load balancer ไม่สามารถรับ response ที่ถูกต้องจาก upstream server (เซิร์ฟเวอร์ที่เก็บแอปพลิเคชันหลัก) ได้

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

สาเหตุ Error 502 ที่พบบ่อย

• แอปพลิเคชัน backend (Node.js, Python, PHP-FPM ฯลฯ) ขัดข้องหรือหยุดทำงาน
• การเชื่อมต่อระหว่าง reverse proxy กับ backend timeout หรือหลุด
• Configuration ของ upstream server ผิด (ชี้ไปยัง port ที่ไม่ถูกต้อง)
• Backend server รับทำงานไม่ไหว (resource หมด CPU หรือ memory ไม่พอ)
• Database connection error ทำให้ application crash

วิธีแก้ Error 502

ขั้นที่ 1: ตรวจสอบสถานะ backend process

เข้า server ผ่าน SSH แล้วตรวจดูว่า application process ยังรันอยู่หรือไม่

• ถ้าใช้ PM2 (Node.js): pm2 status
• ถ้าใช้ PHP-FPM: systemctl status php-fpm
• ถ้าใช้ Supervisor: supervisorctl status

ถ้า process ตาย ให้ restart มันสิ

ขั้นที่ 2: ดูลอก error

ไฟล์ log ของ application เก็บคำใบ้เกี่ยวกับสาเหตุแท้ ตัวอย่างเช่น:

• Node.js: /path/to/app.log
• PHP: /var/log/php-fpm/error.log
• Nginx: /var/log/nginx/error.log

ขั้นที่ 3: ตรวจ configuration

ในไฟล์ Nginx config ที่มี upstream block ให้เช็คว่า server address และ port ถูกต้องไหม

ขั้นที่ 4: ดูการใช้ resource

บ่อยครั้ง 502 เกิดเพราะ memory หรือ CPU หมด ลองใช้ top หรือ free -h เพื่อดูการใช้ resource แบบเรียลไทม์

Error 504 Gateway Timeout คืออะไร

504 Gateway Timeout เกิดเมื่อ reverse proxy รอ response จาก backend server เกินกว่า timeout limit ที่ตั้งไว้

อีกนัยหนึ่ง: backend server ยังรันงานอยู่ แต่มันทำงานช้ามากจนกว่า proxy ท้อแล้ว

สาเหตุ Error 504 ที่พบบ่อย

• Query database มีปัญหา (ช้าเกินไป หรือ slow query ที่ lock table)
• API request ไปเรียก third-party service แต่บริการนั้นทำงานช้า
• Backend process ทำงาน CPU-intensive มาก (เช่น image processing, large file generation)
• Network latency สูง ระหว่าง proxy กับ backend
• Timeout value ที่ตั้งไว้สั้นเกินไป

วิธีแก้ Error 504

ขั้นที่ 1: ระบุงานไหนที่ช้า

ตรวจ slow query log ถ้าใช้ MySQL หรือ PostgreSQL

• MySQL: SELECT * FROM mysql.slow_log;
• PostgreSQL: เปิด log_duration = on ใน postgresql.conf

ขั้นที่ 2: ปรับ timeout value

เพิ่ม timeout ในไฟล์ Nginx:

• proxy_connect_timeout (connection timeout) ค่าเริ่มต้น 60s
• proxy_send_timeout (เวลาส่ง request) ค่าเริ่มต้น 60s
• proxy_read_timeout (เวลารอ response) ค่าเริ่มต้น 60s

ตัวอย่าง:

• proxy_read_timeout 300s; (เพิ่มเป็น 5 นาที)

ขั้นที่ 3: optimize query และ code

แก้ query ให้มีประสิทธิภาพ เพิ่ม index, cache ผลลัพธ์ หรือ async processing งานที่กินเวลา

ขั้นที่ 4: ใช้ queue หรือ background job

งานที่ใช้เวลานาน (เช่น sending email, image resize) ควรเลื่อนไปจัดการแบบ async โดยใช้ tool เช่น Redis Queue, Celery หรือ Bull

Error 500 Internal Server Error คืออะไร

500 Internal Server Error คือ error สุดท้ายที่ server ไม่รู้ว่าจะทำยังไง ปกติเกิดจาก unhandled exception ของ application

มันเป็น "ฉันไม่รู้เหตุผล" error โดยทั่วไป

สาเหตุ Error 500 ที่พบบ่อย

• Application code มี syntax error หรือ fatal error
• Database connection fail (wrong credentials, database down)
• Memory leak หรือ out of memory
• Permission issue (file, directory)
• Third-party library conflict หรือ deprecated function
• Unhandled exception ใน application code

วิธีแก้ Error 500

ขั้นที่ 1: เปิด error reporting

ในไฟล์ config ของ application ให้เปิด debug mode เพื่อดูข้อมูล error ที่เกิดขึ้น

ตัวอย่าง (PHP):

• error_reporting = E_ALL;
• display_errors = On;

ตัวอย่าง (Node.js):

• NODE_ENV = development

ขั้นที่ 2: ตรวจ application log

ไป log file หลักของ application ดูว่ามี error trace อะไร

ขั้นที่ 3: ตรวจ permission

ตรวจสิทธิ์เข้าถึง file และ directory

• ls -la /path/to/file
• chmod 755 /path/to/directory

ขั้นที่ 4: test database connection

เข้า application server console แล้ว test connection ไปยัง database

ขั้นที่ 5: restart application

บ่อยครั้ง simple restart แก้ปัญหาได้ โดยเฉพาะเมื่อ memory leak

เปรียบเทียบรายละเอียด: 502 vs 504 vs 500

ด้านสาเหตุหลัก

502 Bad Gateway: ปัญหา communication ระหว่าง proxy กับ backend (connection ขาด, backend down, ไม่ได้รับ response)

504 Gateway Timeout: ปัญหา speed (backend ทำงาน แต่ช้าเกินไป)

500 Internal Server Error: ปัญหา application logic (code มีข้อผิดพลาด, configuration ผิด, resource หมด)

ด้านการแก้ไข

502 Bad Gateway: เน้นตรวจสุขภาพของ process backend และ connection

504 Gateway Timeout: เน้นปรับประสิทธิภาพ (optimize query, เพิ่ม timeout, async processing)

500 Internal Server Error: เน้นหา bug ใน code และ configuration

ด้านความรุนแรง

502: เซิร์ฟเวอร์แทบจะ offline ทั้งหมด ผู้ใช้ไม่สามารถใช้งานได้เลย

504: ผู้ใช้รอได้ เพราะสักพัก request อาจสำเร็จ (ถ้า timeout ปลายน้ำมีค่าสูง)

500: อาจได้บาง page บาง function ทำงาน ขึ้นอยู่ว่าปัญหาจำเพาะมากไหม

เลือกวิธีแก้อย่างไรให้ถูกจุด

ได้รับ 502 Error ทำยังไร

ให้ความสำคัญเป็นอันดับแรก: restart application และตรวจสถานะ process

• คำสั่ง: systemctl restart app-name หรือ pm2 restart app
• ถ้ายังไม่ได้ ตรวจ upstream server configuration ว่าชี้ไปถูก port ไหม
• ดู error log เพื่อหา root cause (database ตัด, socket ไม่พร้อม)

ได้รับ 504 Error ทำยังไร

อดใจรอได้: มันมักไม่ใช่ emergent ถ้าหลังจากนั้นเว็บก็ใช้ได้ปกติ

• เพิ่ม proxy timeout ก่อนเป็นการชั่วคราว
• ทำการ optimize query database อย่างชิ้นชิ้น
• หา slow query ที่เป็นสาเหตุ
• พิจารณาเลื่อนงานหนัก (export, image generation) ไปแบบ background job

ได้รับ 500 Error ทำยังไร

ค่อนข้างปรับปรุงยาก: เพราะต้องหา bug

• ดู error log ที่ detail เพื่อรู้ว่าสาเหตุคือ line code ไหน
• ตรวจ recent deployment หรือ code change
• ลองใช้ staging environment เพื่อ replicate error
• ถ้ารีบเร่ง ให้ rollback เวอร์ชัน application ไปก่อนหน้า

ป้องกันไม่ให้เกิด Error ในอนาคต

สำหรับ 502

• Health check: ตั้ง Nginx upstream health check ให้มันรู้เมื่อ backend ตายแล้วสามารถ failover ได้
• Auto restart: ใช้ PM2, Supervisor หรือ systemd ให้ restart application โดยอัตโนมัติ
• Monitoring: ติด alert เมื่อ process crash เพื่อให้ทีมรู้เร็ว
• Load balancing: ไว้ backend server ตั้งแต่ 2 ตัวขึ้นไป ถ้าตัวนึงตาย อีกตัวยังใช้ได้

สำหรับ 504

• Database optimization: เพิ่ม index ที่เหมาะสม, analyze query plan
• Caching: cache ผลลัพธ์ที่ไม่เปลี่ยน บ่อยๆ (ใช้ Redis หรือ Memcached)
• Async processing: push งานหนัก ไปคิว (Redis Queue, Celery) ไม่ให้ request เองต้องรอ
• CDN: ถ้า static content เยอะ ใช้ CDN เพื่อลดโหลด server

สำหรับ 500

• Comprehensive error handling: wrap code ใน try-catch เพื่อให้ error ได้จัดการ
• Staging environment: test feature ก่อนขึ้น production
• Unit test & integration test: เขียน test เพื่อจับ bug ตั้งแต่ dev
• Code review: ให้เพื่อนดู code ก่อนถ้า possible
• Logging & monitoring: record error log อย่างละเอียด เพื่อ debug ทีหลัง

สรุปคร่าวและข้อเสนอแนะ

502, 504, และ 500 เป็น error ที่ต่างเรื่องราวกันแล้ว แม้แต่วิธีแก้ไขก็แตกต่างกัน

502 บ่งบอกว่า backend server มีปัญหาร้ายแรง ต้องจัดการด่วน โดยเริ่มจาก restart หรือตรวจสถานะ process

504 หมายความว่า server ช้า เป็นเรื่องของ performance tuning ที่อาจใช้เวลานานขึ้นเล็กน้อย

500 มาจากภายใน application ซึ่งเป็นเรื่องของ code quality ต้องหา bug ให้เจอ

ตัวสำคัญคือ เมื่อได้รับ error ให้ไม่ตกใจ ปฏิบัติตามขั้นตอนที่ระบุในบทความนี้ 90% ของปัญหามักแก้ไขได้ในเวลาอันสั้น เพราะว่า ปัญหาส่วนใหญ่เป็นปัญหาสามัญๆ ที่เคยเกิดกับคนอื่นมาแล้ว

อีกเรื่องหนึ่งที่สำคัญพอๆ กันคือการป้องกัน ลองนำมาตรการป้องกันที่ยกมาใช้ตั้งแต่ตอนนี้ เพื่อไม่ให้เกิด error เหล่านี้ในอนาคต เสียเวลาว่างเพื่อตั้งค่า health check, add index database, หรือเขียน unit test จะดีกว่าตื่นตรงกลางคืนเพราะเว็บขัดข้อง