คู่มือแก้ไขปัญหาเซิร์ฟเวอร์เว็บบน ServBay

ServBay รองรับการใช้ Caddy, NGINX และ Apache เป็น เซิร์ฟเวอร์เว็บหลัก เพื่อสร้างความยืดหยุ่นในการพัฒนาเว็บไซต์บนเครื่องของคุณ ระหว่างการใช้งาน อาจพบปัญหาเว็บไซต์เข้าไม่ได้ โหลดช้า หรือพบข้อผิดพลาด เช่น 500 Internal Server Error คู่มือนี้จะช่วยให้คุณวิเคราะห์และแก้ไขปัญหาเกี่ยวกับเซิร์ฟเวอร์เว็บที่พบได้บ่อยใน ServBay

ใช้เครื่องมือวินิจฉัยปัญหาของ ServBay

ServBay มี เครื่องมือวินิจฉัยปัญหา อัตโนมัติในตัว ช่วยตรวจจับและแจ้งเตือนปัญหาการตั้งค่าหรือบริการที่ผิดปกติ แนะนำให้ใช้เครื่องมือนี้ทันทีเมื่อพบปัญหา เพื่อการวิเคราะห์ด้วยตนเองที่รวดเร็ว

เปิดแอป ServBay แล้วคลิก วินิจฉัยปัญหา ในเมนูด้านซ้าย เพื่อเข้าหน้าต่างเครื่องมือวินิจฉัยปัญหา

เครื่องมือนี้จะตรวจสอบสถานะส่วนประกอบหลักของ ServBay การใช้พอร์ต การเขียนไวยากรณ์ไฟล์คอนฟิก ฯลฯ พร้อมแสดงคำแนะนำ เพื่อให้คุณระบุปัญหาได้ทันที

ตรวจสอบไฟล์คอนฟิกของเซิร์ฟเวอร์เว็บ

ข้อผิดพลาดในไฟล์คอนฟิกของเซิร์ฟเวอร์เว็บ คือสาเหตุสำคัญที่ทำให้เว็บไซต์ใช้งานไม่ได้ ServBay มีเครื่องมือเช็คไวยากรณ์ไฟล์แยกตามแต่ละเซิร์ฟเวอร์เว็บ

ตรวจสอบ Caddyfile

ใช้คำสั่ง validate ของ Caddy เพื่อตรวจสอบไฟล์ Caddyfile ว่าถูกต้องหรือไม่

/Applications/ServBay/bin/caddy validate -c /Applications/ServBay/etc/caddy/Caddyfile

ถ้าไฟล์คอนฟิกถูกต้อง คำสั่งจะคืนค่า Valid configuration หากมีปัญหา จะแจ้งรายละเอียดของข้อผิดพลาด

หมายเหตุ: คำสั่ง caddy validate อาจแสดงข้อมูล INFO หรือ WARN จำนวนมาก ซึ่งส่วนใหญ่เป็นข้อความแจ้งกระบวนการโหลดของ Caddy ไม่ได้หมายถึงข้อผิดพลาดเสมอไป ขอแค่มีผลลัพธ์ Valid configuration ก็ใช้งานได้

ตัวอย่างข้อผิดพลาดที่พบใน Caddyfile:

• ไฟล์ใบรับรอง SSL ไม่พบ:

  2024/12/09 17:24:16.970 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  ... (ข้อมูล INFO/WARN อื่นๆ) ...
  Error: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open /Applications/ServBay/ssl/private/tls-certs/mail.servbay.host/mail.servbay.host.1crt: no such file or directory

  ถ้ามีข้อผิดพลาดลักษณะ loading certificates: open xxxxx: no such file or directory แสดงว่าพาธไฟล์ใบรับรอง SSL ที่ตั้งไว้ใน Caddyfile ไม่ถูกต้องหรือไม่มีอยู่จริง กรุณาตรวจสอบพาธไฟล์ใบรับรอง (.crt/.cer/.pem) และคีย์ส่วนตัว (.key) ให้ถูกต้อง รวมถึงเช็คว่าไฟล์มีจริงหรือไม่ ServBay รองรับการนำเข้าใบรับรองด้วยตนเองหรือขอใบรับรองอัตโนมัติด้วย ACME ตรวจสอบการตั้งค่า SSL ของ ServBay ให้ถูกต้อง

• พาธไดเรกทอรีเว็บไซต์ผิด (มีช่องว่าง):

  2024/12/09 17:26:37.371 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  Error: adapting config using caddyfile: parsing caddyfile tokens for 'root': too many arguments; should only be a matcher and a path, at /Applications/ServBay/etc/caddy/Caddyfile:1388

  ข้อผิดพลาด parsing caddyfile tokens for 'root': too many arguments เกิดจากพาธไดเร็กทอรีเว็บไซต์มีช่องว่างในชื่อ เช่น root * /Applications/ServBay/www/public web คำว่า public web ถูกแยกเป็น 2 อาร์กิวเมนต์ที่ Caddy ไม่รับ ให้ใช้เครื่องหมายคำพูดคู่ " ครอบพาธ เช่น root * "/Applications/ServBay/www/public web"

  แนะนำ: เพื่อป้องกันปัญหานี้ ให้หลีกเลี่ยงการตั้งชื่อไฟล์หรือโฟลเดอร์ที่มีช่องว่างหรือสัญลักษณ์พิเศษ ใช้เครื่องหมาย - หรือ _ แทน เช่น public-folder หรือ public_dir

• Rewrite rule ผิดพลาด:

  หากใช้กฎ rewrite ที่ไม่เป็นไปตามไวยากรณ์ของ Caddy เช่น การคัดลอกกฎจาก NGINX มาใช้โดยตรง อาจทำให้ตรวจสอบคอนฟิกไม่ผ่าน กรุณาศึกษา เอกสาร rewrite ของ Caddy หรืออ่าน คู่มือย้ายเว็บไซต์จาก NGINX มายัง ServBay เพื่อใช้ไวยากรณ์ให้ถูกต้อง

ตรวจสอบคอนฟิก NGINX

ใช้คำสั่ง -t ใน NGINX เช็คไวยากรณ์และความถูกต้องของไฟล์คอนฟิก

/Applications/ServBay/bin/nginx -t

ถ้าคอนฟิกถูกต้อง ผลลัพธ์จะเป็น:

nginx: the configuration file /Applications/ServBay/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /Applications/ServBay/etc/nginx/nginx.conf test is successful

หากมีข้อผิดพลาด NGINX จะแจ้งชื่อไฟล์และบรรทัดที่ผิดพลาดโดยตรง ข้อผิดพลาดที่พบได้บ่อย ได้แก่

1. ข้อผิดพลาดไวยากรณ์: เช่น ลืมเครื่องหมาย ; หรือวงเล็บปิด } ไม่ครบ
2. ไฟล์พาธผิด: เช่น ตั้งค่าคำสั่ง include พาธไฟล์หรือโฟลเดอร์ผิด หรือไม่มีจริง
3. พอร์ตซ้ำซ้อน: กำหนดพอร์ตที่ถูกใช้งานโดยแอปอื่นในระบบ

ตรวจสอบคอนฟิก Apache

ใช้คำสั่ง apachectl configtest ของ Apache เพื่อตรวจสอบไวยากรณ์ไฟล์คอนฟิก

/Applications/ServBay/bin/apachectl configtest

ถ้าคอนฟิกถูกต้อง ผลลัพธ์คือ Syntax OK หากพบปัญหา จะมีข้อความแจ้งเตือนโดยละเอียด ข้อผิดพลาดที่เจอบ่อยคือ

1. โมดูลโหลดไม่ได้: มีโมดูล (LoadModule) ในไฟล์คอนฟิกที่ไม่มีอยู่ หรือระบุพาธผิด
2. .htaccess มีไวยากรณ์ผิด: หากมีไฟล์ .htaccess ในโฟลเดอร์เว็บและเขียนผิด อาจทำให้ทดสอบคอนฟิกทั้งระบบล้มเหลว หรือเข้าถึงบางโฟลเดอร์ไม่ได้
3. ตั้งค่าสิทธิ์ไดเรกทอรีผิด: ชุดคำสั่ง Directory, Files และการตั้งค่าการเข้าถึง (Require, Allow, Deny) อาจปิดกั้นการเข้าถึงไฟล์เว็บไซต์

วิธีแก้ไขข้อผิดพลาด 500 Internal Server Error

500 Internal Server Error คือ รหัสสถานะ HTTP ที่บ่งบอกว่าเซิร์ฟเวอร์พบข้อผิดพลาดที่ไม่คาดคิดในระหว่างประมวลผลคำขอ สำหรับเว็บแอปโดยมาก หมายถึงสคริปต์ฝั่งเซิร์ฟเวอร์ (เช่น PHP, Python, Node.js) ทำงานผิดพลาด

ขั้นตอนวิเคราะห์เบื้องต้น

เมื่อพบ error 500 ให้ตรวจสอบดังนี้

1. ดูบันทึกข้อผิดพลาดของเซิร์ฟเวอร์เว็บ: ขั้นตอนแรกที่สุด ตรวจสอบ log ของเซิร์ฟเวอร์ ส่วนใหญ่จะบอกสาเหตุละเอียดยิบ เช่น ไฟล์สคริปต์ผิด, ไม่มีไฟล์, สิทธิ์ไม่พอ ฯลฯ

   • Caddy: /Applications/ServBay/var/logs/caddy/error.log
   • NGINX: /Applications/ServBay/var/logs/nginx/error.log
   • Apache: /Applications/ServBay/var/logs/apache/error.log ดู log ล่าสุด และค้นหาคำว่า error หรือ critical

2. เช็คว่าบริการฝั่งเซิร์ฟเวอร์ (PHP-FPM) รันอยู่หรือไม่: สำหรับเว็บที่ใช้ PHP ให้แน่ใจว่า PHP-FPM เปิดอยู่

   ps aux | grep php-fpm

   ถ้าไม่มี php-fpm: master process หรือ php-fpm: pool www แสดงว่า PHP-FPM ปิดอยู่หรือแครชไปแล้ว สามารถเปิดใหม่ผ่าน UI ของ ServBay หรือใช้คำสั่ง servbayctl

3. ตรวจสอบ log ข้อผิดพลาดของสคริปต์ฝั่งหลังบ้าน (PHP): ถ้า log ของเซิร์ฟเวอร์เว็บฟ้องว่า FastCGI หรือมี error จากสคริปต์ ให้ดู log ของภาษานั้น ๆ เพิ่มเติม

   • PHP: /Applications/ServBay/var/logs/php/php_error.log หา error อย่าง Fatal error, Parse error, Warning, Notice โดยเฉพาะอันที่เกี่ยวกับสคริปต์ที่ร้องขอ แนะนำเปิด display_errors ใน dev environment (แก้ใน php.ini) เพื่อดู error จริง

4. ตรวจสอบสิทธิ์ไฟล์และโฟลเดอร์: โดยปกติ process เว็บเซิร์ฟเวอร์จะรันในชื่อผู้ใช้เฉพาะ (เช่น _www) ต้องมีสิทธิ์อ่านไฟล์หรือเขียนโฟลเดอร์อัพโหลด/ล็อกได้

   ls -la /Applications/ServBay/www/your-site/

   ตรวจสอบให้ web server user เข้าถึงได้ทั้ง root directory และ sub directory รวมถึง upload/log พิเศษที่ต้องเขียนได้ ใช้ chmod และ chown แก้ไขได้เสมอ แต่ระวัง

เทคนิคแยกปัญหา 500 ตามประเภทเซิร์ฟเวอร์เว็บ

• Caddy:

  1. FastCGI: เช็คคำสั่ง php_fastcgi หรือ reverse_proxy ใน Caddyfile ชี้ไปหา PHP-FPM (โดยปกติ 127.0.0.1:9000 หรือ unix:/path/to/php-fpm.sock)
  2. PHP-FPM: ให้แน่ใจว่าใช้ PHP version และ PHP-FPM ถูกตัวและรันอยู่ใน ServBay
  3. Reverse Proxy: ถ้ามี reverse_proxy ชี้ไปที่หลังบ้านอื่น (เช่น Node.js) ให้เช็ค port, address และสถานะของ backend

• NGINX:

  1. fastcgi_pass: ตรวจสอบว่า fastcgi_pass ใน nginx.conf หรือไฟล์คอนฟิกเว็บแต่ละตัวชี้ถูกต้องไปยัง PHP-FPM
  2. client_max_body_size: หากอัพโหลดไฟล์ใหญ่แล้ว error 500 ให้ลองปรับขนาดนี้ให้ใหญ่ขึ้น
  3. try_files: ตรวจสอบว่า try_files เขียนถูกไหม ตรงไฟล์/อินเด็กซ์ หรือส่งต่อ fastcgi ได้

• Apache:

  1. mod_rewrite: ใช้ .htaccess rewrite ต้องเปิดโมดูลนี้ก่อน
  2. .htaccess: .htaccess ผิดพลาดทำให้ 500 ได้โดยตรง ตรวจเช็ค RewriteRule และไวยากรณ์อื่น
  3. AllowOverride: ให้แน่ใจว่าคอนฟิก Apache ตั้งค่า AllowOverride ถูกต้องเพื่อให้ .htaccess ทำงาน เช่น All หรือรวม FileInfo, Limit

การจัดการบริการ (Service Management)

เมื่อต้องปรับคอนฟิกหรือแก้ปัญหาหลังบ้านเสร็จ ปกติควรรีสตาร์ทบริการเซิร์ฟเวอร์เว็บเพื่อให้การเปลี่ยนแปลงมีผล

รีสตาร์ทบริการ

ใช้คำสั่ง servbayctl restart รีสตาร์ทบริการเซิร์ฟเวอร์เว็บที่ต้องการ

# รีสตาร์ท Caddy
servbayctl restart caddy -all

# รีสตาร์ท NGINX
servbayctl restart nginx -all

# รีสตาร์ท Apache
servbayctl restart apache -all

ตัวเลือก -all จะรีสตาร์ทบริการที่เกี่ยวข้องกับเซิร์ฟเวอร์เว็บนั้น ๆ เช่น หากมี FastCGI จะรีสตาร์ท PHP-FPM ให้อัตโนมัติ

ตรวจสอบสถานะบริการ

ใช้คำสั่ง servbayctl status เพื่อตรวจสอบสถานะการทำงานของบริการ

# เช็คสถานะ Caddy
servbayctl status caddy -all

# เช็คสถานะ NGINX
servbayctl status nginx -all

# เช็คสถานะ Apache
servbayctl status apache -all

ผลลัพธ์ที่ได้จะแสดงสถานะ เช่น running (กำลังทำงาน), stopped (หยุดแล้ว) หรือสถานะอื่น ๆ เพื่อยืนยันว่าบริการเริ่มทำงานสำเร็จ

ขั้นตอนการแก้ปัญหาขั้นสูง

ถ้ายังแก้ปัญหาไม่ได้ อาจต้องวิเคราะห์ลึกขึ้น:

1. ใช้ DevTools ของเบราว์เซอร์: กด F12 เปิดเครื่องมือสำหรับนักพัฒนา ไปที่แท็บ Console กับ Network หาดูข้อผิดพลาดของ JavaScript, HTTP status และ response body เพื่อแยกปัญหาหน้าเว็บหรือหลังบ้าน
2. ใช้ curl -v: เปิดเทอร์มินัลแล้วรัน curl -v your-website.servbay.demo เพื่อดูขั้นตอนการเชื่อมต่อ, header, TLS ฯลฯ (แทนชื่อโดเมนเป็นของแต่ละเว็บ)
3. ปิด Firewall ชั่วคราว: อาจมีไฟร์วอลล์ของ macOS หรือโปรแกรมเสริมบล็อคการเชื่อมต่อ ลองปิดชั่วคราวเพื่อตรวจสอบ หากเข้าได้ต้องปรับ rule ให้พอร์ตของ ServBay เช่น 80, 443 ผ่านได้
4. ทดสอบบนเบราว์เซอร์/อุปกรณ์อื่น: ลองเปิดเว็บจาก browser หรือเครื่องอื่น ถ้ายัง error แปลว่าปัญหาไม่ได้เกิดจาก cache หรือ config อุปกรณ์
5. ตรวจสอบ DNS/hosts: ถ้าใช้ชื่อโดเมนที่ตั้งเอง (ไม่ใช่ localhost หรือ IP) ดูว่า /etc/hosts หรือ local DNS ชี้มาที่ 127.0.0.1 หรือ ::1 จริงหรือเปล่า

สรุป

ปัญหาเซิร์ฟเวอร์เว็บเป็นเรื่องปกติของงานพัฒนาท้องถิ่น เพียงคุณไล่เช็คไวยากรณ์คอนฟิก ดู log ข้อผิดพลาด ตรวจสอบสถานะบริการ และเช็คสิทธิ์ไฟล์ ก็แก้ได้เกือบทุกกรณี ServBay มีเครื่องมือวินิจฉัยและ servbayctl เป็นผู้ช่วยอันทรงพลัง หากยังติดขัด ควรอ่านเอกสาร ServBay เพิ่มเติม หรือขอความช่วยเหลือจากทีมสนับสนุนเทคนิค