อ่าน PHP Error Log บน DirectAdmin หาบั๊กในเว็บ

เมื่อเว็บไซต์แสดง "500 Internal Server Error", "White Screen of Death" หรือทำงานผิดปกติ PHP Error Log คือจุดแรกที่ต้องตรวจสอบ ไฟล์ Log นี้บันทึกข้อผิดพลาดทุกอย่างที่เกิดขึ้นในโค้ด PHP ช่วยให้คุณระบุสาเหตุได้แม่นยำโดยไม่ต้องเดา บทความนี้จะสอนวิธีเปิดใช้งานและอ่าน PHP Error Log บน DirectAdmin Hosting

PHP Error Log คืออะไร

PHP Error Log คือไฟล์ข้อความที่ PHP เขียนข้อผิดพลาดลงไปทุกครั้งที่โค้ดทำงานผิดปกติ ข้อผิดพลาดแบ่งเป็นหลายระดับ ได้แก่:

• Fatal Error — ข้อผิดพลาดร้ายแรงที่ทำให้สคริปต์หยุดทำงานทันที (เช่น เรียกใช้ Function ที่ไม่มี)
• Warning — คำเตือนที่ไม่หยุดสคริปต์ แต่บ่งบอกปัญหาที่ควรแก้ไข
• Notice — ข้อสังเกตว่าโค้ดอาจมีจุดที่ควรปรับปรุง
• Parse Error — ข้อผิดพลาดด้าน Syntax เช่น ลืมปิดวงเล็บหรือเซมิโคลอน
• Deprecated — แจ้งว่าใช้ฟังก์ชันที่จะถูกยกเลิกในอนาคต

เปิดใช้งาน PHP Error Logging บน DirectAdmin

วิธีที่ 1 — แก้ไข php.ini ผ่าน DirectAdmin

1. เข้า DirectAdmin → Advanced Features → PHP Configuration
2. ค้นหาค่าต่อไปนี้และตั้งให้ตรงตามนี้:

error_reporting = E_ALL
log_errors = On
error_log = /home/username/public_html/php_errors.log
display_errors = Off

ควรตั้ง display_errors = Off บน Production Server เสมอ เพื่อป้องกันไม่ให้ Error แสดงบนหน้าเว็บต่อผู้ใช้งาน

วิธีที่ 2 — ใช้ไฟล์ .htaccess

ถ้าไม่มีสิทธิ์แก้ php.ini โดยตรง สามารถใช้ .htaccess ได้:

php_flag log_errors on
php_value error_log /home/username/public_html/php_errors.log
php_flag display_errors off
php_value error_reporting 32767

วิธีที่ 3 — ใส่ใน wp-config.php (WordPress)

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

WordPress จะบันทึก Error ไปยัง wp-content/debug.log โดยอัตโนมัติ

วิธีอ่าน PHP Error Log

หลังจากเปิดใช้งาน Error Logging แล้ว สามารถอ่านไฟล์ได้หลายวิธี:

ผ่าน DirectAdmin File Manager

1. เข้า File Manager
2. หาไฟล์ php_errors.log หรือ debug.log
3. คลิกขวาเลือก View หรือ Edit

ผ่าน SSH / Shell

# ดู 50 บรรทัดล่าสุด
tail -n 50 /home/username/public_html/php_errors.log

# ติดตาม Log แบบ Real-time
tail -f /home/username/public_html/php_errors.log

# ค้นหา Fatal Error
grep "Fatal error" /home/username/public_html/php_errors.log

วิธีอ่านและตีความ Error Messages

ตัวอย่าง Error Message ที่พบบ่อย:

[16-May-2026 10:23:45 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /home/user/public_html/wp-content/themes/mytheme/index.php:5

• วันเวลา — เมื่อไหร่เกิดข้อผิดพลาด
• ประเภท Error — Fatal error / Warning / Notice
• คำอธิบาย — Call to undefined function get_header()
• ไฟล์และบรรทัด — index.php บรรทัด 5

Error ที่พบบ่อยและวิธีแก้

• Call to undefined function — Function ไม่ได้ include ไฟล์หรือ Plugin ที่มีฟังก์ชันนั้น
• Class not found — ไม่ได้ load Autoloader หรือ use ผิด namespace
• Memory exhausted — ต้องเพิ่ม memory_limit ใน php.ini หรือ wp-config.php
• Maximum execution time exceeded — Query ช้าหรือ Loop ไม่สิ้นสุด เพิ่ม max_execution_time
• Permission denied — ไฟล์หรือโฟลเดอร์มี Permission ไม่ถูกต้อง ควรเป็น 644 สำหรับไฟล์ และ 755 สำหรับโฟลเดอร์

การตั้งค่า php.ini ที่สำคัญสำหรับ Debug

นอกจาก Error Logging แล้ว ยังมีค่าใน php.ini อีกหลายตัวที่ช่วยให้ Debug ง่ายขึ้นและป้องกันปัญหาที่พบบ่อย ตารางด้านล่างแสดงค่าที่แนะนำสำหรับสภาพแวดล้อม Development และ Production ซึ่งควรตั้งให้แตกต่างกัน

บน DirectAdmin ไปที่ Advanced Features → PHP Configuration เพื่อแก้ไขค่าเหล่านี้โดยไม่ต้องเข้าถึงเซิร์ฟเวอร์โดยตรง

Debug WordPress Error ด้วย Query Monitor Plugin

สำหรับเว็บ WordPress นอกจาก WP_DEBUG_LOG แล้ว Plugin ชื่อ Query Monitor เป็นเครื่องมือ Debug ที่ครอบคลุมที่สุดโดยไม่ต้องอ่าน Log ด้วยตาตลอดเวลา มีฟีเจอร์สำคัญดังนี้:

• Database Queries — แสดง SQL Query ทุกตัวที่รันในหน้าพร้อมเวลาที่ใช้ ช่วยหา Query ช้าหรือซ้ำโดยไม่จำเป็น
• PHP Errors — แสดง Warning, Notice และ Deprecated ที่เกิดในหน้า พร้อม Stack Trace
• Hooks & Actions — ดูว่า Hook ไหนถูกเรียกและจาก Plugin ใด ช่วยหาความขัดแย้งระหว่าง Plugin
• HTTP API Calls — แสดง HTTP Request ที่ WordPress ส่งออกไปภายนอก ช่วยหา Timeout หรือ API ที่ไม่ตอบสนอง
• Memory — แสดง RAM ที่ใช้ต่อหน้า ช่วยระบุ Plugin ที่กิน Memory สูงผิดปกติ

ติดตั้งจาก WordPress Plugin Directory ค้นหา "Query Monitor" และ Activate ได้เลย แถบ Admin Bar ด้านบนจะมีข้อมูลสรุปแบบ Real-time ในทุกหน้า ควรปิดการใช้งานก่อน Push ขึ้น Production เพราะข้อมูล Debug ไม่ควรแสดงต่อผู้ใช้จริง

ป้องกัน PHP Error Log รั่วสู่สาธารณะ

ไฟล์ Log ที่เก็บอยู่ใน public_html มีความเสี่ยงที่บุคคลภายนอกจะเข้าถึงได้โดยตรงผ่าน Browser หากไม่มีการป้องกัน Log อาจเปิดเผย Path ไฟล์ภายใน ชื่อฐานข้อมูล หรือข้อมูลสำคัญอื่น มีวิธีป้องกันหลายทาง:

วิธีที่ 1 — ย้าย Log ออกนอก public_html

ตั้งค่า error_log ให้ชี้ไปนอก Web Root เช่น:

error_log = /home/username/logs/php_errors.log

ไฟล์ที่อยู่นอก public_html จะไม่สามารถเข้าถึงผ่าน Browser ได้เลย นี่คือวิธีที่ปลอดภัยที่สุด

วิธีที่ 2 — Block ด้วย .htaccess

ถ้าจำเป็นต้องเก็บ Log ไว้ใน public_html ให้เพิ่มบรรทัดนี้ใน .htaccess:

# ป้องกันการเข้าถึงไฟล์ Log ผ่าน Browser
<FilesMatch "\.(log|txt)$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

วิธีที่ 3 — ตั้งชื่อไฟล์ที่เดาไม่ได้

เปลี่ยนชื่อ Log File จาก php_errors.log เป็นชื่อที่ซับซ้อนขึ้น เช่น err_a8f3b2c.log เพื่อลดโอกาสที่ Bot จะค้นพบ แต่ควรทำควบคู่กับวิธีอื่นด้วย ไม่ใช่พึ่งเพียงอย่างเดียว

การดูแลรักษา PHP Error Log ระยะยาว

PHP Error Log ที่ไม่ได้รับการดูแลอาจโตขึ้นจนใหญ่มากในเวลาไม่นาน โดยเฉพาะบนเว็บที่มีจำนวนผู้ใช้มากหรือมี Error ซ้ำๆ เกิดขึ้นทุกครั้งที่มีการเข้าถึงหน้านั้น ไฟล์ Log ขนาดหลาย GB อาจกินพื้นที่ Disk จนกระทบการทำงานของ Hosting ทั้งระบบ มีแนวทางจัดการดังนี้:

• ล้าง Log เป็นประจำ: ทุกสัปดาห์หรือทุกเดือนให้ตรวจและล้าง Log ที่อ่านแล้ว ผ่าน File Manager หรือคำสั่ง truncate -s 0 php_errors.log บน SSH
• ติดตาม Log Size: บน SSH ใช้ du -sh /home/username/public_html/php_errors.log เพื่อดูขนาดไฟล์ Log ได้รวดเร็ว
• แก้ Error ต้นตอ: Log ที่โตเร็วมักบ่งบอกว่ามี Error ซ้ำๆ ที่ไม่ได้รับการแก้ไข ให้ค้นหา Error ที่เกิดบ่อยที่สุดก่อน เช่น grep -c "Notice" php_errors.log เพื่อนับจำนวน แล้วแก้ Error นั้นให้หมดก่อน
• ตั้ง Log Rotation: บน VPS สามารถตั้ง logrotate เพื่อหมุนเวียนไฟล์ Log อัตโนมัติได้ แต่บน Shared Hosting มักต้องทำด้วยตนเองหรือผ่าน Cron Job
• จำกัดขนาด Error Message: ตั้ง log_errors_max_len = 1024 ใน php.ini เพื่อจำกัดความยาวแต่ละบรรทัดในไฟล์ Log ป้องกันการใช้พื้นที่มากเกินไปจาก Stack Trace ยาวๆ

การดูแล Error Log ไม่ใช่แค่การอ่านเมื่อเว็บมีปัญหา แต่ควรเป็น Routine ปกติของการบำรุงรักษาเว็บไซต์ ทีมนักพัฒนาที่ดีจะมีนโยบาย "Zero Error Policy" คือตั้งเป้าให้ Error Log ว่างเปล่าอยู่เสมอโดยแก้ทุก Notice และ Warning ให้หมดก่อนปล่อยโค้ดขึ้น Production สำหรับ Hosting ของ AsiaGB สามารถตรวจสอบพื้นที่ Disk ที่ใช้งานได้ผ่าน DirectAdmin ที่เมนู System Info & Files เพื่อให้แน่ใจว่า Log ไม่ได้กินพื้นที่เกินกำหนด

เปรียบเทียบเครื่องมือ Debug PHP บน Hosting

มีหลายวิธีในการ Debug PHP บน Shared Hosting ไม่ใช่ทุกเครื่องมือเหมาะกับทุกสถานการณ์ ตารางด้านล่างช่วยให้เลือกได้ตรงกับ Workflow ของคุณ