HTTP Error 500 (Internal Server Error) — วิธีแก้ครบทุกสาเหตุปี 2026 บน WordPress + อื่น

คุณเปิดเว็บไซต์ตัวเองตอนเช้าแล้วเจอข้อความสีขาวบนพื้นจอที่เขียนว่า “HTTP Error 500 — Internal Server Error” หัวใจคุณคงตกวูบ เพราะ error ตัวนี้คือฝันร้ายของ webmaster ทุกคน มันไม่บอกสาเหตุ ไม่บอกบรรทัด ไม่บอกว่าต้องแก้ตรงไหน บางครั้งหน้าบ้านยังเปิดได้ แต่ wp-admin เข้าไม่ได้ บางครั้งทั้งเว็บล่มหมด บางครั้งเกิดเฉพาะบางหน้า

ในบทความนี้ คุณจะได้เรียนรู้สาเหตุทั้ง 10 อย่างที่ทำให้เกิด HTTP 500 พร้อมวิธีแก้ทีละขั้นตอนแบบละเอียดสำหรับ WordPress, Static Site (Netlify, Vercel, Cloudflare Pages), และ Custom Server (Nginx, Apache) คุณจะได้รู้วิธีดู error log วิธีกู้ wp-admin ที่เข้าไม่ได้ และเครื่องมือที่ใช้วินิจฉัยปัญหาได้ตรงจุด

ถ้าคุณกำลังเจอ HTTP 500 อยู่ตอนนี้ อ่านบทความนี้จบแล้วคุณจะแก้ได้ภายใน 30 นาที — ไม่ต้องรอ host เปิด ticket ไม่ต้องจ้างใครมาแก้ และไม่ต้องเสียลูกค้าระหว่างเว็บล่ม

HTTP 500 คืออะไร และทำไมมันถึงน่ารำคาญที่สุด

HTTP 500 Internal Server Error เป็น HTTP status code ที่อยู่ในตระกูล 5xx server-side errors หมายความว่าปัญหาเกิดที่ฝั่ง server ไม่ใช่ฝั่ง browser หรือฝั่งคุณ มันต่างจาก 4xx errors (เช่น 404 Not Found, 403 Forbidden) ที่บอกว่าปัญหาเกิดจาก client request

ปัญหาคือ HTTP 500 เป็น generic catch-all error — เมื่อ server เจอปัญหาที่ไม่รู้จะจัดประเภทยังไง มันจะคืน 500 มาให้ คุณจึงไม่มีทางรู้สาเหตุที่แท้จริงจากตัว error code อย่างเดียว

ตระกูล 5xx server-side errors

Code	ชื่อ	ความหมาย
500	Internal Server Error	server เจอปัญหาแต่ไม่บอกสาเหตุ
501	Not Implemented	server ไม่รองรับ method นั้น
502	Bad Gateway	upstream server ส่งคำตอบที่ผิด
503	Service Unavailable	server ล่มชั่วคราว / maintenance
504	Gateway Timeout	upstream ตอบช้าเกินไป
507	Insufficient Storage	server เนื้อที่เต็ม
508	Loop Detected	infinite loop ใน server logic

ในกลุ่มนี้ HTTP 500 เป็นตัวที่คนเจอบ่อยที่สุดเพราะมันคลุมสาเหตุได้กว้างที่สุด ตั้งแต่ PHP syntax error ไปจนถึง server overload

ทำไม HTTP 500 ถึงไม่บอกสาเหตุ?

เหตุผลคือเรื่องของ security ถ้า error message บอกรายละเอียดมากเกินไป (เช่น path ของไฟล์ database password บรรทัดของ PHP error) hacker จะใช้ข้อมูลนั้นโจมตีได้ Web server จึงตั้งค่า default ให้ซ่อน error message ไว้ใน log แทนการแสดงบนหน้าจอ คุณจึงต้องไปดู log เอง

ผลกระทบที่เกิดขึ้นทันที

SEO ตก — Googlebot ที่ crawl เจอ 500 หลายครั้งจะมองว่าเว็บไม่เสถียร และลด crawl rate
Conversion หาย — ลูกค้าที่กำลังจะกดซื้อจะออกทันทีและไม่กลับมา
Bounce rate พุ่ง — Google Analytics จะบันทึกว่ามี user เข้าแล้วออกทันที
Brand trust ลดลง — โดยเฉพาะถ้าเป็น e-commerce หรือ SaaS

ดังนั้นการแก้ HTTP 500 ให้เร็วที่สุดจึงเป็นเรื่องเร่งด่วน ไม่ใช่แค่ปัญหา technical แต่เป็นปัญหา business

10 สาเหตุที่พบบ่อยที่สุดของ HTTP 500

หลังจากแก้ HTTP 500 มาหลายร้อยเคส เราพบว่าสาเหตุส่วนใหญ่หนีไม่พ้น 10 อย่างนี้ ตารางนี้สรุปสาเหตุ ความถี่ที่พบ และระดับความยากในการแก้:

#	สาเหตุ	ความถี่ที่พบ	ความยาก	เครื่องมือที่ใช้
1	PHP fatal error / syntax error	สูงมาก	ปานกลาง	error_log, WP_DEBUG
2	.htaccess broken / corrupt	สูง	ง่าย	FTP, text editor
3	Plugin/theme conflict	สูงมาก	ง่าย	FTP, WP admin
4	Memory limit exhausted	สูง	ง่าย	wp-config.php, php.ini
5	File/folder permission ผิด	ปานกลาง	ง่าย	chmod, FTP
6	mod_security block	ปานกลาง	ปานกลาง	server config, host support
7	MySQL connection crash	ปานกลาง	ปานกลาง	error_log, MySQL CLI
8	Cron job stuck	ต่ำ	ยาก	wp-cli, cron log
9	Error log full / disk full	ต่ำ	ง่าย	df, du commands
10	Server overload (CPU/RAM)	ปานกลาง	ยาก	top, htop, server monitor

1. PHP Fatal Error / Syntax Error

สาเหตุอันดับหนึ่ง — เกิดจาก PHP code เขียนผิด syntax หรือเรียก function ที่ไม่มีอยู่ มักเกิดหลังอัพเดต plugin/theme หรือหลังแก้ไฟล์ functions.php

ตัวอย่าง PHP fatal error:

Fatal error: Uncaught Error: Call to undefined function
Parse error: syntax error, unexpected token
Fatal error: Cannot redeclare function

2. .htaccess Broken หรือ Corrupt

ไฟล์ .htaccess ของ Apache ที่เขียน rewrite rule ผิด จะทำให้ server แสดง 500 ทันที พบบ่อยหลังติดตั้ง plugin SEO หรือ caching plugin ที่เขียน .htaccess เพิ่ม

3. Plugin หรือ Theme Conflict

Plugin สองตัวเขียน function ชื่อเดียวกัน หรือ theme เก่าที่ใช้ deprecated function ของ PHP 8 ก็ทำให้เกิด 500 ได้

4. Memory Limit Exhausted

PHP memory_limit default ของ WordPress คือ 40MB ถ้า plugin หรือ query ใช้ memory เกินนั้น จะเกิด fatal error และโชว์ 500

5. File/Folder Permission ผิด

มาตรฐานของ Linux web server คือ folder = 755, file = 644 ถ้า upload ไฟล์มาแล้ว permission เพี้ยน เช่น 777 (Apache จะ refuse) หรือ 600 (ไม่ executable) จะเกิด 500

6. mod_security Block

mod_security คือ Web Application Firewall (WAF) ของ Apache ที่ block request ที่ดูเป็น attack เช่น SQL injection, XSS บางครั้งมัน false positive ทำให้ legitimate request โดน block และคืน 500

7. MySQL Connection Crash

ถ้า MySQL service ล่ม หรือ connection pool เต็ม PHP จะเรียก database ไม่ได้และเกิด fatal error

8. Cron Job Stuck

WP-Cron ที่ค้างเพราะ task ใช้เวลานานเกิน max_execution_time ทำให้ request ค้างและ timeout เป็น 500

9. Error Log Full หรือ Disk Full

ถ้า error log เขียนเยอะมากจน disk เต็ม server จะเขียนไฟล์อะไรไม่ได้ รวมถึง session file และ cache file ทำให้ทุก request ล่ม

10. Server Overload (CPU/RAM)

shared hosting ที่มีคน abuse resource มากเกิน หรือ VPS ที่โดน DDoS จะทำให้ CPU/RAM เต็ม 100% และ server reject request ทุกตัว

วิธีแก้ทีละสาเหตุ — WordPress Specific

ส่วนนี้เป็นคู่มือแก้ไขสำหรับ WordPress โดยเฉพาะ เพราะ WordPress เป็น CMS ที่เจอ HTTP 500 บ่อยที่สุด

Step 1: เปิด WP_DEBUG เพื่อดูสาเหตุที่แท้จริง

ก่อนแก้ คุณต้องรู้ก่อนว่า error คืออะไร เปิด WP_DEBUG ใน wp-config.php:

// wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

หลังเปิดแล้ว error จะถูกเขียนใน /wp-content/debug.log ให้คุณเปิดดูทาง FTP

สำคัญ: ตั้ง WP_DEBUG_DISPLAY เป็น false เพื่อไม่ให้ user เห็น error message บนหน้าเว็บ (security risk)

Step 2: แก้ .htaccess

วิธีง่ายที่สุด — เปลี่ยนชื่อ .htaccess เป็น .htaccess_old ผ่าน FTP แล้วลองเข้าเว็บใหม่ ถ้าเว็บกลับมา แสดงว่าปัญหาอยู่ที่ .htaccess

จากนั้นเข้า WordPress admin > Settings > Permalinks แล้วกด Save (โดยไม่ต้องเปลี่ยนอะไร) WordPress จะ generate .htaccess ใหม่ให้:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Step 3: ปิด Plugin ทั้งหมดผ่าน FTP

ถ้า wp-admin เข้าไม่ได้ คุณต้องปิด plugin ผ่าน FTP โดยเปลี่ยนชื่อ folder:

# ผ่าน SSH หรือ FTP
mv wp-content/plugins wp-content/plugins_disabled

WordPress จะ deactivate plugin ทั้งหมดทันที ถ้าเว็บกลับมา แสดงว่ามี plugin ตัวใดตัวหนึ่งคือต้นเหตุ ให้เปลี่ยนชื่อกลับเป็น plugins แล้ว rename folder ของ plugin ทีละตัวเพื่อหาตัวที่มีปัญหา

Step 4: เปลี่ยนเป็น Default Theme

ถ้าปัญหาไม่ใช่ plugin ลองเปลี่ยน theme เป็น default theme (เช่น Twenty Twenty-Six) ผ่าน FTP:

mv wp-content/themes/your-theme wp-content/themes/your-theme_disabled

WordPress จะ fallback ไปใช้ default theme อัตโนมัติ ถ้าเว็บกลับมา แสดงว่า theme เป็นต้นเหตุ

Step 5: เพิ่ม PHP Memory Limit

แก้ใน wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

หรือสร้าง .user.ini ใน WordPress root:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

หรือแก้ใน php.ini (ถ้ามีสิทธิ์):

memory_limit = 256M

Step 6: รีเซ็ต File Permission

ตั้ง permission ให้ถูกต้องผ่าน SSH:

# Folder = 755
find /path/to/wordpress -type d -exec chmod 755 {} \;

# File = 644
find /path/to/wordpress -type f -exec chmod 644 {} \;

# wp-config.php = 600 (highest security)
chmod 600 /path/to/wordpress/wp-config.php

Step 7: ลด mod_security False Positive

ถ้าโดน mod_security block ให้ติดต่อ host แจ้งว่าโดน false positive หรือเพิ่ม whitelist ใน .htaccess:

<IfModule mod_security.c>
SecRuleEngine Off
</IfModule>

คำเตือน: ปิด mod_security ทั้งหมดเป็น security risk ควรขอ host เปิด whitelist เฉพาะ rule ที่ false positive แทน

Step 8: รีสตาร์ท MySQL

ถ้า error log บอกว่า “Error establishing a database connection” หรือ MySQL crash ให้ restart service:

# Ubuntu/Debian
sudo systemctl restart mysql

# CentOS/RHEL
sudo systemctl restart mariadb

# ตรวจสอบสถานะ
sudo systemctl status mysql

Step 9: เคลียร์ WP-Cron ที่ค้าง

ใช้ WP-CLI:

# ดู cron list
wp cron event list

# ลบ event ที่ค้าง
wp cron event delete <hook-name>

# Run cron ทั้งหมดเลย
wp cron event run --due-now

หรือ disable WP-Cron แล้วใช้ system cron แทน:

// wp-config.php
define( 'DISABLE_WP_CRON', true );

# /etc/crontab
*/5 * * * * www-data wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Step 10: เคลียร์ Disk Space

# ดูเนื้อที่ disk
df -h

# ดูว่าโฟลเดอร์ไหนใช้เยอะ
du -sh /var/log/* | sort -h

# ลบ log เก่า
sudo truncate -s 0 /var/log/apache2/error.log
sudo find /var/log -name "*.gz" -delete

ตรวจสอบ Error Log — ที่มาของคำตอบที่แท้จริง

Error log คือเครื่องมือสำคัญที่สุดในการแก้ HTTP 500 มันบอกเราว่า error เกิดที่ไฟล์ไหน บรรทัดไหน และเป็น error อะไร

ดู Error Log ผ่าน cPanel

ถ้าใช้ shared hosting ที่มี cPanel:

Login cPanel
ไปที่ section “Metrics” > “Errors”
คุณจะเห็น error log แบบ realtime

ดู Error Log ผ่าน FTP

Connect FTP ไปที่ public_html
หาไฟล์ชื่อ error_log (ไม่มี .log extension)
Download มาเปิดดู

ตัวอย่าง error log ที่บอกชัด:

[Sat Jun 20 14:23:11.234567 2026] [php:error] [pid 12345]
PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product()
in /home/user/public_html/wp-content/themes/my-theme/functions.php:127

จาก log นี้รู้ได้เลยว่า:

ไฟล์ที่มีปัญหา: functions.php
บรรทัด: 127
สาเหตุ: เรียก WooCommerce function แต่ WooCommerce ไม่ได้เปิดใช้งาน

ดู Error Log ผ่าน Command Line

ถ้าเข้าถึง SSH ได้:

# Apache (Ubuntu/Debian)
tail -f /var/log/apache2/error.log

# Apache (CentOS/RHEL)
tail -f /var/log/httpd/error_log

# Nginx
tail -f /var/log/nginx/error.log

# PHP-FPM
tail -f /var/log/php-fpm/error.log

# WordPress debug log
tail -f /path/to/wordpress/wp-content/debug.log

คำสั่ง tail -f จะแสดง log แบบ realtime คุณสามารถ refresh เว็บแล้วดูได้ทันทีว่ามี error อะไรเกิดขึ้น

Filter เฉพาะ HTTP 500

# กรองเฉพาะ access log ที่เป็น 500
grep ' 500 ' /var/log/apache2/access.log

# ดู 20 IP ที่เจอ 500 บ่อยที่สุด
grep ' 500 ' /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# ดู URL ที่เจอ 500 บ่อยที่สุด
grep ' 500 ' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

อ่าน Error Log ให้เข้าใจ

Error log แต่ละบรรทัดประกอบด้วย:

Timestamp — เวลาที่เกิด error
Severity — error level (notice, warning, error, fatal)
PID — process ID
Message — ข้อความ error
File path + line number — ตำแหน่งที่ error เกิด

ระดับ severity ที่ต้องสนใจ:

notice — แค่ข้อสังเกต ไม่ทำให้เว็บล่ม
warning — เตือน แต่ยังทำงานต่อได้
error — error ที่ทำให้ function นั้นล้มเหลว แต่เว็บอาจยังทำงานต่อได้
fatal — error ที่ทำให้ PHP หยุดทำงาน → HTTP 500

Debug WP-Admin ที่เข้าไม่ได้

สถานการณ์ที่แย่ที่สุด — wp-admin เข้าไม่ได้เพราะเจอ HTTP 500 คุณจึงต้องแก้ผ่าน FTP/SSH เท่านั้น

ขั้นตอนกู้ WP-Admin ทีละขั้น

ขั้นที่ 1: Connect FTP ไปที่ WordPress root

ขั้นที่ 2: เปิด WP_DEBUG เพื่อดู error message:

// wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

ขั้นที่ 3: เปิดดูไฟล์ /wp-content/debug.log

ขั้นที่ 4: ถ้า error บอกว่ามาจาก plugin ให้ rename folder plugin นั้น:

# Disable plugin ทั้งหมด
mv wp-content/plugins wp-content/plugins_disabled
mkdir wp-content/plugins

# หรือ disable plugin ทีละตัว
mv wp-content/plugins/problematic-plugin wp-content/plugins/problematic-plugin_disabled

ขั้นที่ 5: ถ้า error บอกว่ามาจาก theme ให้สลับเป็น default theme:

mv wp-content/themes/active-theme wp-content/themes/active-theme_disabled

WordPress จะหา default theme (twentytwentysix, twentytwentyfive) มาใช้แทนอัตโนมัติ

ขั้นที่ 6: Reset file permission:

cd /path/to/wordpress
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

ขั้นที่ 7: ลอง login wp-admin อีกครั้ง

ใช้ Recovery Mode ของ WordPress 5.2+

WordPress 5.2+ มี Fatal Error Protection ที่จะส่ง email ไปยัง admin พร้อม link เข้า Recovery Mode

ถ้าไม่ได้รับ email ตรวจสอบ:

Admin email ใน wp_options ถูกต้อง
SMTP plugin ทำงาน
Email ไม่ตกถัง spam

Recovery Mode link จะเปิด wp-admin ในโหมดพิเศษที่ disable plugin/theme ที่มีปัญหา

Reset Admin Password ผ่าน Database

ถ้าลืม password admin ก็แก้ผ่าน phpMyAdmin:

UPDATE wp_users 
SET user_pass = MD5('NewPassword123!')
WHERE user_login = 'admin';

หรือใช้ WP-CLI:

wp user update admin --user_pass="NewPassword123!"

HTTP 500 บน Static Site (Netlify, Vercel, Cloudflare Pages)

Static site host ไม่ใช้ PHP แต่ก็เจอ HTTP 500 ได้ในรูปแบบที่ต่างออกไป

Netlify HTTP 500 — สาเหตุที่พบบ่อย

1. Build Error

ถ้า build script crash เว็บจะ deploy ไม่สำเร็จ และเวอร์ชันใหม่จะคืน 500:

# ดู build log
netlify deploy --logs

# หรือเช็คใน Netlify dashboard
# Site > Deploys > Click latest > See logs

แก้:

ตรวจสอบ Node version ใน .nvmrc
เช็ค dependency missing ใน package.json
ทดสอบ npm run build ในเครื่อง local ก่อน

2. Netlify Functions Timeout

Serverless function ของ Netlify จำกัด execution time 10 วินาที (Pro plan 26 วินาที) ถ้าเกินจะคืน 500:

// netlify/functions/slow-function.js
exports.handler = async (event, context) => {
  // ถ้า function ใช้เวลา > 10s จะเกิด 500
  const data = await fetch('https://slow-api.com/data');
  return {
    statusCode: 200,
    body: JSON.stringify(data),
  };
};

แก้: ใช้ background function หรือย้ายงานหนักไป queue

3. Environment Variable Missing

ถ้า function ใช้ env var ที่ไม่ได้ตั้งใน Netlify dashboard จะเกิด error:

# ตั้งใน Netlify UI: Site > Site settings > Environment variables
# หรือผ่าน CLI:
netlify env:set API_KEY "your-key-here"

Vercel HTTP 500

1. Edge Function Limit

Vercel Edge Function จำกัด 1MB ถ้า bundle ใหญ่กว่านี้จะ deploy ไม่ได้:

// next.config.js
module.exports = {
  experimental: {
    serverComponentsExternalPackages: ['heavy-library'],
  },
};

2. API Route Memory

Serverless API route ของ Vercel มี memory limit 1024MB (Hobby) / 3008MB (Pro) ถ้าใช้เกินจะ 500:

// vercel.json
{
  "functions": {
    "api/heavy.js": {
      "memory": 3008,
      "maxDuration": 60
    }
  }
}

Cloudflare Pages HTTP 500

1. Pages Function Error

Pages Function ที่ throw exception โดยไม่ catch จะเกิด 500:

// functions/api/data.js
export async function onRequest(context) {
  try {
    const data = await fetch(context.env.API_URL);
    return new Response(JSON.stringify(data));
  } catch (error) {
    return new Response(
      JSON.stringify({ error: error.message }),
      { status: 500 }
    );
  }
}

2. Worker CPU Limit

Worker จำกัด CPU time 50ms (Free) / 30s (Paid) ถ้าเกินจะเกิด 500

ตั้งค่าผ่าน wrangler.toml:

[limits]
cpu_ms = 30000

อ่านเพิ่มเติมเรื่อง Cloudflare ที่บทความ Cloudflare Complete Guide 2026

HTTP 500 บน Custom Server (Nginx, Apache)

ถ้าคุณรัน server ของตัวเอง การแก้ HTTP 500 ต้องลึกถึง config file

Nginx Configuration

ตรวจสอบ Config Syntax

# ทดสอบว่า config ถูกต้อง
sudo nginx -t

# ถ้าเจอ error ตัวอย่าง:
# nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/default:42

# Reload หลังแก้
sudo systemctl reload nginx

Nginx Config ตัวอย่างที่ถูกต้อง

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 300;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
    }

    # Error pages
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

Nginx Error Log

# Realtime monitor
sudo tail -f /var/log/nginx/error.log

# ตัวอย่าง error
# 2026/06/20 14:30:11 [crit] 1234#0: *56789 connect() to 
# unix:/var/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Error นี้บอกว่า PHP-FPM socket ไม่มี ต้องเช็คว่า PHP-FPM service ทำงานอยู่หรือไม่:

sudo systemctl status php8.3-fpm
sudo systemctl restart php8.3-fpm

Apache Configuration

ตรวจสอบ Config Syntax

# Ubuntu/Debian
sudo apache2ctl configtest
# หรือ
sudo apachectl configtest

# CentOS/RHEL
sudo httpd -t

# Output ที่ดี:
# Syntax OK

# Reload หลังแก้
sudo systemctl reload apache2

Apache Virtual Host ตัวอย่าง

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com/public

    <Directory /var/www/example.com/public>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined

    # PHP-FPM
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

Apache Module ที่จำเป็น

# Enable module ที่ WordPress ต้องการ
sudo a2enmod rewrite
sudo a2enmod headers
sudo a2enmod expires

# Restart
sudo systemctl restart apache2

ถ้า mod_rewrite ไม่ได้ enable WordPress permalinks จะใช้ไม่ได้ และอาจคืน 500

Tools ที่ใช้แก้ HTTP 500

เครื่องมือเหล่านี้ช่วยให้คุณวินิจฉัยและแก้ HTTP 500 ได้เร็วขึ้น

Wordfence — Security Scanner

Wordfence เป็น security plugin ที่:

Scan malware ที่ทำให้เกิด PHP error
ดู failed login attempt ที่ทำให้ MySQL overload
Block IP ที่พยายาม attack จนทำให้ server crash

ติดตั้งและ scan:

wp plugin install wordfence --activate
wp wordfence-cli scan --threat-feed=enterprise

Site Health Tool (Built-in WordPress)

WordPress 5.2+ มี Site Health tool ใน Tools > Site Health ที่บอก:

PHP version
Memory limit
Max execution time
Required PHP extension
Database health

ใช้ตรวจสอบว่า environment พร้อมรองรับ WordPress หรือไม่

Query Monitor — Debug Tool

Query Monitor เป็น plugin ที่แสดง:

Database query ทั้งหมดในหน้านั้น
PHP error/warning/notice ที่เกิด
HTTP request ภายนอก
Hook ที่ run
Memory usage

ติดตั้ง:

wp plugin install query-monitor --activate

หลังเปิด admin bar จะมี toolbar ใหม่ที่แสดงข้อมูล debug แบบ realtime

Server Monitoring Tools

1. New Relic — APM (Application Performance Monitoring) ที่ระดับ PHP code

2. Datadog — Infrastructure monitoring + APM

3. UptimeRobot — Ping monitor ที่จะแจ้งเตือนทันทีที่เว็บคืน 500

4. Better Uptime — Modern uptime monitor พร้อม status page

Command Line Tools

# ดู process ที่ใช้ resource มากที่สุด
top
htop

# ดู memory usage
free -m

# ดู disk usage
df -h
du -sh /var/log/*

# ดู open file
lsof | grep php

# ดู network connection
netstat -tulpn

# ดู MySQL process
mysqladmin processlist

เมื่อไหร่ควรเรียก Host Provider

บางครั้งคุณแก้เองไม่ได้ และต้องพึ่ง host ในกรณีต่อไปนี้:

กรณีที่ต้องติดต่อ Host

mod_security blocking — คุณไม่มีสิทธิ์แก้ rule ของ ModSecurity ต้องให้ host เพิ่ม whitelist
PHP-FPM crash ซ้ำ — ถ้า PHP-FPM ล่มทุก 1-2 ชั่วโมง อาจเป็น server config ที่ host ต้องปรับ
MySQL down — ถ้าเป็น managed MySQL host ต้อง restart service ให้
DDoS attack — ต้องเปิด DDoS protection ที่ระดับ network
Resource limit hit — เช่น CPU limit, RAM limit ของ shared hosting

ข้อมูลที่ต้องเตรียมก่อนติดต่อ Host

เวลา (timestamp) ที่เกิด error
URL ที่เจอ error
IP ของผู้ที่เจอ (ของคุณเอง)
Screenshot ของ error
Error log ที่ดึงมาได้
ขั้นตอนที่ลองแก้แล้ว
Browser และ OS

ตัวอย่าง ticket ที่ดี:

Subject: HTTP 500 Error บน example.com ตั้งแต่ 14:30 ของวันที่ 20 มิ.ย. 2026

รายละเอียด:
- URL: https://example.com/products/widget-123
- IP ของผม: 203.0.113.1
- Error message: HTTP Error 500
- เริ่มเกิดเมื่อ: 20 มิ.ย. 2026, 14:30
- ผมได้ลองแก้:
  1. Disable plugin ทั้งหมด - ไม่หาย
  2. Switch theme เป็น Twenty Twenty-Six - ไม่หาย
  3. Reset file permission - ไม่หาย
  4. เพิ่ม WP_MEMORY_LIMIT เป็น 512M - ไม่หาย

Error log จาก /var/log/apache2/error.log:
[Sat Jun 20 14:30:11 2026] [crit] 1234#0: *56789 
ModSecurity: Access denied with code 500 ...

รบกวนช่วยตรวจสอบ ModSecurity rule และเปิด whitelist 
สำหรับ IP ของผมหรือสำหรับ URL pattern /products/*

ขอบคุณครับ

ถ้าคุณต้องการที่ปรึกษาเรื่อง web hosting หรือ server optimization สามารถติดต่อทีม Southern Whale เพื่อรับคำปรึกษาฟรี

5 ข้อผิดพลาดที่คนทำตอนแก้ HTTP 500

ในประสบการณ์การแก้ HTTP 500 ให้ลูกค้าหลายร้อยเคส เราเห็นข้อผิดพลาดเดิม ๆ ที่ทำให้ปัญหาแย่ลง

1. ลบ .htaccess โดยไม่ Backup

หลายคนเจอ HTTP 500 แล้วลบ .htaccess ทันที โดยไม่ rename หรือ backup ทำให้ rewrite rule ของ plugin SEO, security plugin หายหมด เว็บอาจจะกลับมาแสดงผลได้ แต่ permalink พัง, security rule หาย, redirect rule หาย

ที่ถูก: rename เป็น .htaccess_backup_20260620 ก่อนเสมอ

2. เปิด WP_DEBUG_DISPLAY บน Production

// ผิด — จะแสดง error บนหน้าเว็บให้ user เห็น
define( 'WP_DEBUG_DISPLAY', true );

Error message ที่แสดงต่อ public อาจเปิดเผย:

Path ของไฟล์ใน server
Database table prefix
Function name ที่ใช้
Library version

Hacker จะใช้ข้อมูลนี้วาง attack vector

ที่ถูก: ใช้ WP_DEBUG_DISPLAY = false และ WP_DEBUG_LOG = true แทน

3. ใช้ chmod 777 เพื่อ “แก้” Permission

# ผิด — เปิด permission 777 ทำให้ใครก็เขียนได้
chmod -R 777 /var/www/wordpress

Permission 777 หมายถึงทุกคน (รวมถึง hacker ที่ exploit ได้) สามารถ read/write/execute ไฟล์ทั้งหมด นี่คือเสี่ยงต่อ malware injection อย่างมาก

ที่ถูก: ใช้ 755 สำหรับ folder, 644 สำหรับ file, 600 สำหรับ wp-config.php

4. ปิด Plugin ทุกตัวพร้อมกันโดยไม่เช็คที่ละตัว

หลายคนเจอ HTTP 500 แล้ว disable plugin ทุกตัวพร้อมกันผ่าน FTP เว็บกลับมา แล้ว enable กลับทั้งหมดพร้อมกัน เว็บ 500 อีก แต่ไม่รู้ว่าตัวไหนคือต้นเหตุ

ที่ถูก: Disable plugin ทุกตัว แล้ว enable ทีละตัว เริ่มจากตัวที่ไม่ค่อยมี dependency ก่อน แล้วเช็คทีละครั้ง

5. ไม่อ่าน Error Log

นี่คือข้อผิดพลาดที่พบบ่อยที่สุด — คนเจอ HTTP 500 แล้วเริ่ม google วิธีแก้ทั่วไปทันที โดยไม่เปิด error log ดู

Error log บอกคำตอบที่แท้จริงเสมอ การไม่อ่าน log คือการพยายามแก้ปัญหาโดยไม่รู้สาเหตุ — เปลืองเวลาและอาจสร้างปัญหาใหม่

ที่ถูก: ขั้นแรกของการแก้ HTTP 500 คือเปิด /wp-content/debug.log หรือ error_log ของ Apache/Nginx ก่อนเสมอ

ถ้าต้องการปรึกษาเรื่อง WordPress plugin หรือ Web Development Southern Whale พร้อมช่วยคุณวิเคราะห์และแก้ไขปัญหาเชิงลึก

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

Q1: HTTP 500 ต่างจาก 502, 503, 504 ยังไง?

ทั้ง 4 เป็น 5xx server error เหมือนกัน แต่ความหมายต่างกัน:

500 Internal Server Error — server เจอปัญหาแต่ไม่บอกสาเหตุ (catch-all)
502 Bad Gateway — server กลางส่ง response ที่ผิดจาก upstream (เช่น Nginx ไม่ได้ response ที่ดีจาก PHP-FPM)
503 Service Unavailable — server ล่มชั่วคราว / กำลัง maintenance
504 Gateway Timeout — server กลางรอ upstream นานเกินไป (ตอบไม่ทัน)

ถ้าเจอ 502 บ่อย ๆ ปัญหามักอยู่ที่ PHP-FPM crash หรือ upstream server ล่ม ส่วน 504 มักเป็น query database ที่ช้าจน timeout

Q2: HTTP 500 บอกไหมว่าเกิดจาก plugin ตัวไหน?

โดยตัว HTTP 500 status code ไม่บอก แต่ error log บอกได้ ตัวอย่าง:

PHP Fatal error: Uncaught Error in 
/wp-content/plugins/woocommerce/includes/class-wc-cart.php:1234

จาก path บอกได้ทันทีว่า WooCommerce เป็นต้นเหตุ เปิด WP_DEBUG_LOG แล้วเช็ค path ของไฟล์ใน error message

ถ้าไม่อยากดู log ก็ใช้วิธี disable plugin ทีละตัวแล้วเช็ค ใช้เวลาเยอะกว่าแต่ใช้ได้ผล

Q3: ทำไม HTTP 500 เกิดเฉพาะบางหน้า บางหน้าไม่เกิด?

มีหลายสาเหตุ:

Plugin ที่ใช้เฉพาะบางหน้า — เช่น WooCommerce checkout page มี plugin ที่ load เฉพาะหน้านั้น
Memory limit — บางหน้ามี query หนัก ทำให้ใช้ memory เกิน limit
Specific template — single.php, page-special.php มี code ที่ผิด
URL pattern match mod_security — บาง URL pattern (เช่น ที่มี SQL keyword) โดน ModSecurity block

ตรวจสอบโดย: ดู error log ของแต่ละ request ว่ามาจากไฟล์ไหน หรือ run Query Monitor บนหน้าที่มีปัญหา

Q4: HTTP 500 ส่งผลต่อ SEO มากแค่ไหน?

ส่งผลมาก ถ้าเกิดบ่อยและเป็นเวลานาน Google จะ:

ลด crawl budget — Googlebot ที่เจอ 500 บ่อยจะลด crawl rate
De-index — ถ้า 500 ค้างหลายวัน Google อาจ remove URL นั้นออกจาก index ชั่วคราว
ลด ranking — ถ้าเว็บ unstable บ่อย ๆ ranking ทั้งเว็บอาจตก

แก้ให้เร็วที่สุด และตรวจสอบ Search Console > Crawl Stats เพื่อดูว่า Googlebot เจอ 5xx error กี่ครั้ง

อ่านเพิ่มเติมเรื่อง INP optimization ที่กระทบ SEO ใน Core Web Vitals

Q5: ใช้ Cloudflare ช่วยลด HTTP 500 ได้ไหม?

ช่วยได้บางส่วน:

ข้อดี:

Cache static asset ช่วยลด load บน origin server
Argo Tunnel ช่วยลด timeout issue
DDoS protection กัน traffic spike ที่ทำให้ server crash

ข้อจำกัด:

ถ้า origin server (WordPress backend) crash Cloudflare ก็ช่วยไม่ได้
Cloudflare Workers ที่มี bug ก็ยังคืน 500 เอง

ตั้งค่า “Always Online” feature ของ Cloudflare ให้แสดง cached version แทน 500 page ได้ในระหว่างที่ origin server ล่ม

Q6: ควร monitor HTTP 500 ยังไง?

ใช้ uptime monitor + error tracking:

UptimeRobot/Better Uptime — Ping URL ทุก 1-5 นาที แจ้งเตือนเมื่อเจอ 500
Sentry — ดักจับ PHP error/JavaScript error แบบ realtime
New Relic — APM ที่บอกถึง code level ว่า function ไหนช้าหรือ throw error
Google Search Console — ดู crawl error report

แจ้งเตือนผ่าน Slack, Email, SMS, PagerDuty เพื่อให้รับรู้ทันที

Q7: HTTP 500 กับ White Screen of Death (WSOD) ต่างกันไหม?

ใช่ ต่างกัน:

HTTP 500 — server คืน status code 500 + แสดงหน้า error
White Screen of Death — server คืน status code 200 แต่หน้า render ไม่ได้ (เห็นจอขาวอย่างเดียว)

WSOD มักเกิดจาก:

PHP error ที่ไม่ระบุ status code (เช่น JavaScript error ที่ break rendering)
WP_DEBUG_DISPLAY = false แต่ display_errors ก็ปิด → ไม่แสดง error message แต่ HTML ก็ render ไม่ครบ

วิธีดู: เปิด Network tab ใน DevTools ดู HTTP status code ของ response

Q8: ป้องกัน HTTP 500 ในอนาคตยังไง?

ก่อนอัพเดต:

Backup เว็บทุกครั้งก่อนอัพเดต WordPress core, plugin, theme
ทดสอบ update ใน staging environment ก่อน
ตรวจสอบ compatibility ของ PHP version

Monitoring:

ติดตั้ง uptime monitor
ตั้ง error tracking
ดู error log อย่างสม่ำเสมอ (อย่างน้อยสัปดาห์ละครั้ง)

Best practice:

ใช้ plugin จากผู้พัฒนาที่ไว้ใจได้
จำกัด plugin ให้น้อยที่สุดเท่าที่จำเป็น
อัพเดต PHP version อย่างน้อยปีละครั้ง
ใช้ caching plugin เพื่อลด load
ตั้ง memory_limit, max_execution_time ให้เพียงพอ

Security:

ติดตั้ง security plugin (Wordfence, Sucuri)
เปิด WAF (Cloudflare, Sucuri Firewall)
จำกัด login attempts
เปลี่ยน wp-admin URL

ดูเพิ่มเติมเรื่อง LCP Optimization เพื่อเข้าใจ Core Web Vitals ที่ส่งผลต่อ user experience

สรุป

HTTP 500 Internal Server Error เป็น error ที่ดูน่ากลัวเพราะไม่บอกสาเหตุ แต่ในความจริงแล้วมีสาเหตุที่ระบุได้ชัดเจน 10 อย่างหลัก ๆ และส่วนใหญ่แก้ได้ในเวลาไม่นานถ้าคุณรู้วิธี

สรุปขั้นตอนการแก้ HTTP 500 ที่ทรงประสิทธิภาพที่สุด:

อ่าน error log ก่อนเสมอ — ที่ /wp-content/debug.log หรือ /var/log/apache2/error.log
เปิด WP_DEBUG ถ้ายังไม่เคยเปิด — แต่ต้องตั้ง WP_DEBUG_DISPLAY = false เพื่อความปลอดภัย
Backup .htaccess ก่อนแตะต้องทุกครั้ง
Disable plugin ทีละตัว เพื่อหาตัวที่มีปัญหา
เปลี่ยน theme เป็น default เพื่อตัดความเป็นไปได้
เพิ่ม PHP memory limit ถ้าเจอ memory error
Reset file permission ให้ถูกมาตรฐาน
ตรวจสอบ MySQL ว่ายัง connect ได้
เคลียร์ disk space ถ้า disk เต็ม
ติดต่อ host ถ้าเป็นปัญหาระดับ server

สำหรับ Static Site (Netlify, Vercel, Cloudflare Pages) เน้นดู build log, function timeout และ environment variable

สำหรับ Custom Server (Nginx, Apache) ใช้ nginx -t หรือ apachectl configtest ตรวจสอบ config syntax ก่อนเสมอ

การป้องกันที่ดีกว่าการแก้ — ตั้ง uptime monitor, error tracking, backup เสมอก่อนอัพเดต และทดสอบใน staging ก่อน production

ถ้าคุณต้องการความช่วยเหลือในการแก้ HTTP 500 ที่ซับซ้อน หรือต้องการ optimize server ให้ stable ขึ้น สามารถติดต่อทีม Southern Whale เพื่อรับคำปรึกษาฟรี เรามีประสบการณ์แก้ปัญหา HTTP 500 มาแล้วมากกว่า 500 เคส ตั้งแต่ shared hosting, VPS ไปจนถึง enterprise infrastructure

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

Cloudflare Complete Guide 2026 — ใช้ Cloudflare ลด HTTP 500 และเพิ่ม performance
INP Interaction to Next Paint 2026 — Core Web Vitals ที่กระทบ user experience
LCP Largest Contentful Paint Optimization 2026 — เร่งเว็บให้โหลดเร็วและลด server load
บริการ Web Development — พัฒนาเว็บที่ stable และเร็ว
WordPress Plugin ที่แนะนำ — Plugin ที่ปลอดภัยและไม่ทำให้เว็บ crash