WordPress 500 Внутрішня помилка сервера: Найпоширеніші причини та швидкий план виправлення

Що насправді означає WordPress 500 (і чого воно не означає)

Код стану 500 означає, що сервер не зміг виконати запит через непередбачену ситуацію. Це не означає, що запит був некоректним (це 400/404),
і це не означає, що вас обмежують за частотою запитів (429) або що ваш апстрім недоступний (502/504). 500 зазвичай генерується самим веб‑сервером або середовищем застосунку.

У світі WordPress «500 Internal Server Error» зазвичай відповідає одному з наступного:

• Помилки конфігурації веб‑сервера (погані правила перезапису, невірні директиви, відсутні модулі).
• Збої середовища PHP або фатальні помилки (некоопійовані винятки, невизначені функції, вичерпання пам’яті).
• Проблеми пулу PHP‑FPM (досягнуто max_children, таймаути slowlog, дозволи сокета).
• Проблеми з правами/власністю файлової системи (не можна читати плагіни/теми, не можна записувати кеш/тимчасові файли).
• Обмеження ресурсів (перевантаження CPU, диск заповнений, вичерпано іноди).
• Правила безпеки/WAF, які змушують апстрім повертати загальні 500.

Також не забувайте, що «WordPress 500» іноді — не WordPress. Це може бути CDN, який повертає загальний 500, бо походження повернуло інше або край не може коректно дістатися до origin. Завжди перевіряйте, де саме створюється код стану.

Одне висловлювання, яке варто тримати в голові під час інциденту, належить Вернеру Фогельсу (CTO Amazon): «Все ламається постійно». Це не песимізм; це планування.

Швидкий план діагностики (перші/другі/треті перевірки)

Крок 0: Припиніть гадати. Підтвердіть шар, що відмовляє.

Перш ніж торкатися WordPress, визначте, чи 500 походить від edge (CDN/WAF), веб‑сервера (Nginx/Apache) або PHP (PHP‑FPM/mod_php).
Ваш перший успіх — звузити зону впливу.

Перша перевірка (2 хвилини): відтворіть і зафіксуйте заголовки відповіді

• Якщо заголовки показують server: cloudflare або подібне, перевірте, чи це origin‑500 або помилка, згенерована на краю.
• Якщо ви бачите X-Powered-By: PHP і заголовок з ідентифікатором запиту від платформи, у вас є нитка, за яку тягнути.

Друга перевірка (5 хвилин): читайте потрібні журнали, а не всі підряд

• Журнал помилок веб‑сервера для відповідного часу й шляху запиту.
• Журнал помилок PHP‑FPM (або php_errors у syslog/journald).
• Журнал відладки WordPress лише якщо він увімкнений — і краще увімкніть тимчасово.

Третя перевірка (10 хвилин): ізолюйте WordPress від платформи

• Зверніться до статичного файлу (наприклад, /favicon.ico), щоб перевірити, чи веб‑сервер взагалі щось обслуговує.
• Зверніться до /wp-login.php і простого PHP‑інфо ендпойнта, якщо він є (або тимчасово створіть безпечний і потім видаліть його).
• Вимкніть плагіни й перемкніть тему (безпечним шляхом), якщо журнали вказують на фатали PHP або проблеми з порядком завантаження плагінів.

Якщо виконати ці три перевірки дисципліновано, більшість інцидентів 500 швидко переходять із «таємничого» у «тічковий для дій».
Якщо ви їх пропустите, діяти під стресом будете типово: зміните п’ять речей і нічого не дізнаєтесь.

Найпоширеніші причини (за шарами)

1) CDN/WAF та зворотні проксі: помилки origin у маскуванні

CDN може або коректно переслати origin‑500, або згенерувати свій 500, якщо не може дістатися до origin, не проходить TLS‑handshake або отримує некоректну відповідь.
Деякі керовані WAF також блокують запити й повертають брендову сторінку помилки, яка користувачам виглядає як «500‑подібна».

Ваше завдання: перевірити, чи origin повертає 500 при прямому доступі (обхід CDN) і чи запит не переписується несподівано.

2) Nginx/Apache: правила перезапису, дозволи та неправильні маршрути

WordPress сильно залежить від перезаписів. Одна неправильна директива може перетворитися на 500. Те ж стосується некоректного .htaccess або конфігу Nginx, що посилається на відсутній файл.
В Apache 500 також з’являється, коли сервер зустрічає директиву, якої не розуміє (часто після зміни модулів).

3) Середовище PHP: фатали, пам’ять і несумісні версії

Більшість реальних WordPress 500 — це фатали PHP. Оновлення плагіна викликає виклик функції, якої немає у вашій версії PHP. Тема очікує наявність розширення.
Витік пам’яті призводить до «Allowed memory size exhausted» і середовище перериває виконання посеред запиту.

Ще один часто зустрічаючийся винуватець — проблеми з OPCache після розгортання. OPcache чудовий — поки ним все гаразд. Очистити його може означати різницю між стабільністю і «привидуванням».

4) PHP‑FPM: пула під тиском

Коли PHP‑FPM досягає pm.max_children, запити ставляться в чергу. Залежно від таймаутів веб‑сервера це часто проявляється як 502/504, але може також виглядати як 500,
якщо upstream некоректно налаштований або застосунок повертає частковий вивід. Також: проблеми з дозволами сокета та обмеження chroot/open_basedir можуть виглядати як помилки застосунку.

5) Файлова система та зберігання: диск заповнений, вичерпано іноди, дрейф дозволів

WordPress записує файли. Кеші, завантаження, оновлення плагінів, тимчасові файли, сесії, іноді журнали. Якщо диск заповнений, ви отримаєте несподівано загальні помилки.
Якщо вичерпані іноди, на диску може бути багато вільних гігабайтів, але система фактично «повна».

Дрейф дозволів трапляється частіше, ніж визнають: одне ручне редагування від root, одне розгортання, що змінило власність, одне посилення безпеки, яке заблокує користувача PHP від читання файлу плагіна.
Веб‑стек відповідає — ви вже здогадалися — 500.

6) База даних та зовнішні залежності: помилки погано піднімаються вгору

Чисті відмови бази даних зазвичай показують «Error establishing a database connection», але залежно від обробки помилок і шарів кешування об’єктів,
винятки БД можуть бути поглинуті й повторно кинути як загальні 500. Redis/Memcached‑помилки можуть робити те саме.

Жарт №1: Помилка 500 — це спосіб сервера сказати «у мене теж є почуття», і зараз вони переважно в паніці.

Практичні завдання з командами, виводами та рішеннями

Це виробничі завдання. Вони передбачають Linux, Nginx або Apache і PHP‑FPM. Налаштуйте шляхи під вашу дистрибуцію.
Кожне завдання містить (a) команду, (b) що типовий вивід означає, і (c) рішення, яке потрібно застосувати далі.

Завдання 1: Захопіть невдалу відповідь і підтвердіть, де згенеровано 500

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | sed -n '1,20p'
HTTP/2 500
date: Fri, 26 Dec 2025 18:42:10 GMT
content-type: text/html; charset=UTF-8
server: nginx
x-request-id: 7f2c9a4e9b0f3c1a

Що це означає: Відповідь походить від nginx (не CDN). Ідентифікатор запиту — золота монета, якщо ваші журнали його містять.
Рішення: Йдіть одразу в журнали помилок Nginx і PHP‑FPM для цього часу/ідентифікатора запиту.

Завдання 2: Обхід CDN і звернення до origin напряму (якщо можливо)

cr0x@server:~$ curl -sS -D- -o /dev/null -H "Host: example.com" http://203.0.113.10/ | sed -n '1,20p'
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Fri, 26 Dec 2025 18:42:13 GMT
Content-Type: text/html

Що це означає: Origin теж повертає 500. Це не «CDN поводиться дивно».
Рішення: Трасуйте стек origin. Якщо origin повертає 200, а CDN — 500, досліджуйте правила краю, TLS, WAF або health checks origin.

Завдання 3: Дивіться журнал помилок веб‑сервера в реальному часі під час відтворення

cr0x@server:~$ sudo tail -n 50 -f /var/log/nginx/error.log
2025/12/26 18:42:10 [error] 1129#1129: *928 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /var/www/html/wp-includes/formatting.php:1234" while reading response header from upstream, client: 198.51.100.23, server: example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "example.com"

Що це означає: Чітка корінна причина: фатал PHP через відсутнє розширення mbstring.
Рішення: Встановіть/увімкніть відсутнє розширення, перезавантажте PHP‑FPM і повторіть тест. Не чіпайте плагіни поки стек сам не підказує, у чому проблема.

Завдання 4: Перевірте стан служби PHP‑FPM і останні помилки

cr0x@server:~$ sudo systemctl status php8.1-fpm --no-pager -l
● php8.1-fpm.service - The PHP 8.1 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.1-fpm.service; enabled)
     Active: active (running) since Fri 2025-12-26 17:01:22 UTC; 1h 40min ago
   Main PID: 901 (php-fpm8.1)
     Status: "Processes active: 12, idle: 4, Requests: 28291, slow: 7, Traffic: 0.0req/sec"
     ...

Що це означає: Служба працює. «slow: 7» натякає на повільні запити, але не обов’язково на причину 500.
Рішення: Якщо помилок не видно у веб‑журналах, перегляньте журнали PHP‑FPM і розгляньте тимчасове увімкнення slowlog.

Завдання 5: Перегляньте журнал помилок PHP‑FPM на фатали або насичення пулу

cr0x@server:~$ sudo tail -n 80 /var/log/php8.1-fpm.log
[26-Dec-2025 18:42:10] WARNING: [pool www] child 2134 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /var/www/html/wp-includes/formatting.php:1234"
[26-Dec-2025 18:40:55] WARNING: [pool www] server reached pm.max_children setting (20), consider raising it

Що це означає: Дві проблеми: відсутнє розширення (негайні 500) і насичення пулу (ризик продуктивності).
Рішення: Спочатку виправте фатал (відновлення сервісу), потім вирішіть питання пропускної здатності: підвищуйте pm.max_children лише після перевірки запасу ОЗП.

Завдання 6: Підтвердіть, що розширення PHP і версія відповідають очікуванням WordPress

cr0x@server:~$ php -v
PHP 8.1.26 (cli) (built: Nov 21 2025 10:12:33) (NTS)

cr0x@server:~$ php -m | egrep -i 'mbstring|mysqli|curl|gd|imagick|zip|openssl' || true
curl
mysqli
openssl
zip

Що це означає: Немає mbstring. Ядро WordPress і багато плагінів його очікують.
Рішення: Встановіть пакет php-mbstring для вашої дистрибуції, перезапустіть PHP‑FPM, повторіть тест. Якщо CLI відрізняється від FPM, перевірте шлях ini FPM.

Завдання 7: Перевірте синтаксис конфігурації веб‑сервера (дешево, швидко, часто пропускають)

cr0x@server:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Що це означає: Конфіг Nginx розбирається коректно.
Рішення: Якщо тут помилки, виправте їх перед будь‑якими іншими діями. Жодна діагностика WordPress не допоможе, якщо веб‑сервер не завантажує правила правильно.

Завдання 8: Для Apache перевірте конфіг і вплив .htaccess

cr0x@server:~$ sudo apachectl configtest
Syntax OK

Що це означає: Основна конфігурація Apache OK. Це не гарантує, що .htaccess не ламає запити.
Рішення: Тимчасово перемістіть .htaccess, якщо підозрюєте проблеми з перезаписом, і повторіть тест.

Завдання 9: Карантин .htaccess, щоб виключити погані директиви

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo mv .htaccess .htaccess.bak.$(date +%s)
cr0x@server:~$ sudo -u www-data php -l index.php
No syntax errors detected in index.php

Що це означає: Якщо сайт відновиться після переміщення .htaccess, ваші правила перезапису або директиви були невірні.
Рішення: Відновіть постійні посилання з адмінки WordPress після стабілізації або відтворіть мінімальні стандартні правила перезапису і поступово поверніть зміни.

Завдання 10: Безпечно відключіть плагіни без wp-admin (перейменування каталогу)

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:~$ sudo mv plugins plugins.disabled.$(date +%s)
cr0x@server:~$ ls -1
mu-plugins
plugins.disabled.1766774712
themes
uploads

Що це означає: WordPress не завантажить звичайні плагіни, якщо каталог відсутній/перейменований. Він все ще завантажує mu-plugins.
Рішення: Якщо 500 зникає, фатал спричинив плагін. Поверніть каталог, а потім вмикайте плагіни частинами або по одному, щоб знайти винуватця.

Завдання 11: Переключіться на стандартну тему (коли підозрюєте код теми)

cr0x@server:~$ cd /var/www/html/wp-content/themes
cr0x@server:~$ sudo mv mytheme mytheme.disabled.$(date +%s)
cr0x@server:~$ ls -1
mytheme.disabled.1766774766
twentytwentyfour
twentytwentythree

Що це означає: Якщо активна тема відсутня, WordPress перейде на встановлену стандартну тему.
Рішення: Якщо це вирішує 500, тема пошкоджена або несумісна. Відкотіть розгортання теми або виправте фатальну помилку.

Завдання 12: Увімкніть логування WordPress (тимчасово та відповідально)

cr0x@server:~$ sudo cp -a /var/www/html/wp-config.php /var/www/html/wp-config.php.bak.$(date +%s)
cr0x@server:~$ sudo grep -n "WP_DEBUG" /var/www/html/wp-config.php || true

cr0x@server:~$ sudo sed -i "s/\/\* That's all, stop editing! Happy publishing. \*\//define('WP_DEBUG', true);\ndefine('WP_DEBUG_LOG', true);\ndefine('WP_DEBUG_DISPLAY', false);\n\n\/\* That's all, stop editing! Happy publishing. \*\//" /var/www/html/wp-config.php

cr0x@server:~$ sudo -u www-data tail -n 30 /var/www/html/wp-content/debug.log
[26-Dec-2025 18:45:03 UTC] PHP Fatal error:  Uncaught Error: Class "WooCommerce" not found in /var/www/html/wp-content/themes/mytheme/functions.php:211

Що це означає: Тема очікує WooCommerce, але плагіни вимкнені або WooCommerce не завантажився.
Рішення: Виправте припущення про залежності (захистити код за допомогою class_exists) або відновіть потрібний плагін після стабілізації. Також: вимкніть debug після завершення; журнали можуть відкривати внутрішні дані.

Завдання 13: Перевірте використання диска та вичерпання інодів (проблеми зі зберіганням часто викликають 500)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  200M 100% /

cr0x@server:~$ df -i
Filesystem       Inodes   IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 2621401      39  100% /

Що це означає: У вас немає місця і немає інодів. Оновлення WordPress, кеші, тимчасові файли — все може несподівано відмовляти.
Рішення: Негайно звільніть місце (журнали, старі релізи, кеш), потім виправте причину (ротація логів, політика кешу, розмір розділу).

Завдання 14: Швидко знайдіть найбільших «пожирачів» простору

cr0x@server:~$ sudo du -xhd1 /var | sort -h
120M	/var/cache
1.4G	/var/log
6.8G	/var/lib

cr0x@server:~$ sudo ls -lhS /var/log | head
-rw-r----- 1 syslog adm  920M Dec 26 18:40 syslog
-rw-r----- 1 root  adm  210M Dec 26 18:15 nginx-error.log

Що це означає: Логи їдять диск. Це часто корелює з новим циклом помилок (наприклад, фатал плагіна, що спамить журнал).
Рішення: Ротувати/стиснути журнали, щоб відновити місце, але також виправте цикл помилок. Інакше через годину ви повернетесь сюди.

Завдання 15: Перевірте власність файлів і дозволи у директоріях WordPress

cr0x@server:~$ sudo namei -l /var/www/html/wp-content
f: /var/www/html/wp-content
drwxr-xr-x root     root     /
drwxr-xr-x root     root     var
drwxr-xr-x root     root     www
drwxr-xr-x root     root     html
drwx------ root     root     wp-content

Що це означає: wp-content має режим 700 і належить root. PHP, що працює як www-data, не може читати/писати. Очікуйте 500 і дивну поведінку адмінки.
Рішення: Виправте власність/дозволи відповідно до моделі розгортання (зазвичай читабельність для www-data, обмежена записуваність для uploads/cache).

Завдання 16: Перевірте дозволи сокета PHP‑FPM і з’єднання від Nginx

cr0x@server:~$ ls -l /run/php/php8.1-fpm.sock
srw-rw---- 1 www-data www-data 0 Dec 26 17:01 /run/php/php8.1-fpm.sock

cr0x@server:~$ sudo grep -R "fastcgi_pass" -n /etc/nginx/sites-enabled | head
/etc/nginx/sites-enabled/example.conf:42: fastcgi_pass unix:/run/php/php8.1-fpm.sock;

Що це означає: Сокет існує і відповідає конфігу. Якби дозволи були неправильні або шлях не збігався, Nginx логував би помилки з’єднання upstream.
Рішення: Якщо шлях сокета відрізняється, узгодьте конфігурацію Nginx або директиву listen у PHP‑FPM, потім перезавантажте служби.

Завдання 17: Перевірте насичення пулу й запас пам’яті перед тим, як «просто підвищити max_children»

cr0x@server:~$ ps -o pid,rss,cmd -C php-fpm8.1 | head
  PID   RSS CMD
  901  17800 php-fpm: master process (/etc/php/8.1/fpm/php-fpm.conf)
 2134 145200 php-fpm: pool www
 2135 152300 php-fpm: pool www

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:            2048        1530          85          40         432         260
Swap:           1024         950          74

Що це означає: Воркери займають ≈150MB RSS кожен. У вас мало доступної пам’яті і йде активний свопінг.
Рішення: Не підвищуйте pm.max_children поки що. Зменшіть використання пам’яті (плагіни, налаштування кешу об’єктів), додайте ОЗП або масштабуйтесь горизонтально.

Завдання 18: Знайдіть фатали PHP у journald (типово для systemd‑дистрибуцій)

cr0x@server:~$ sudo journalctl -u php8.1-fpm -S "10 minutes ago" --no-pager | tail -n 30
Dec 26 18:42:10 server php-fpm8.1[901]: PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /var/www/html/wp-includes/formatting.php:1234

Що це означає: Підтверджує фатал серед часу інциденту.
Рішення: Виправте відсутню залежність; якщо після цього з’являться інші фатали, продовжуйте ітерації — не припускайте, що проблема лише одна.

Завдання 19: Протестуйте один PHP‑файл через шлях веб‑сервера

cr0x@server:~$ printf '%s\n' '/dev/null
cr0x@server:~$ curl -sS -D- http://127.0.0.1/health.php | sed -n '1,10p'
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8

OK

Що це означає: Виконання PHP через стек працює. Отже, помилка, ймовірно, в кодовому шляху WordPress (плагіни/тема/ядро), а не в підключенні до FPM.
Рішення: Сфокусуйтесь на WordPress і його залежностях; тимчасовий ендпойнт видаліть після інциденту.

Завдання 20: Видаліть тимчасовий тестовий ендпойнт (бо майбутній ви заслуговує спокою)

cr0x@server:~$ sudo rm -f /var/www/html/health.php
cr0x@server:~$ test ! -e /var/www/html/health.php && echo "removed"
removed

Що це означає: Ендпойнт видалено.
Рішення: Якщо потрібні постійні перевірки здоров’я, реалізуйте їх правильно (обмежений шлях, автентифікація та моніторинг), а не залишайте тест як артефакт інциденту.

Три міні‑історії з корпоративного життя (реалістичні відмови)

Міні‑історія 1: Інцидент через хибне припущення

Маркетинговий сайт працював за CDN і керованим WAF. Команда побачила сплеск «500 помилок» у синтетичному моніторингу і рефлекторно припустила, що WordPress впав.
Вони кинулись прямо в wp-content, перейменували плагіни і навіть відкотили тему.

Нічого не змінилося. Помилка вперто трималась. Тим часом через редагування origin під час пікового трафіку з’явився дрейф дозволів:
швидке scp від root залишило файли, що належали root, у каталозі плагінів. Сайт став гіршим. Тепер були періодичні 500 і дивна поведінка адмінки.

Корінна причина була upstream: вендор WAF випустив новий набір правил, що трактував поширений параметр запиту з їхнього трекінгу як підозрілий.
WAF повертав загальну сторінку 500 (не 403), бо «безпека через неоднозначність» — схоже, ще якось товарна функція.

Виправлення було нудним: обійти CDN/WAF, підтвердити здоров’я origin, додати виняток для параметра трекінгу і налаштувати правило. Потім скасувати непотрібні зміни на origin.
Урок: 500 — не визнання провини WordPress. Це симптом. Підтвердіть, де він створюється, перш ніж братися до «операцій».

Міні‑історія 2: Оптимізація, що підвела

Команда платформи хотіла швидших сторінок і менше CPU. Вони ввімкнули агресивний full‑page кеш через плагін, плюс server‑side microcaching в Nginx.
На папері: менше виконань PHP, щасливіша база даних, менша вартість. І тиждень все виглядало добре.

Потім почалася рекламна кампанія. Трафік зріс, як і спроби входу (законні та ні). Налаштування кешу випадково кешувало відповіді, що не мали кешуватися:
фрагменти сторінок для залогінених користувачів і, гірше, іноді цикли редиректів для користувачів з певними cookie. Сесії PHP сходили з розуму. Ключі кешу були неправильні.

Під навантаженням воркери PHP‑FPM зависли. Запити накопичувались. Веб‑сервер почав повертати мікс 500 і 502 залежно від того, який таймаут спрацював першим.
Плагін також писав величезні файли кешу у каталог на кореневому файловому розділі. Диск досяг 100% і все стало «internal server error», включно з несуміжними сервісами.

Виправлення не було «ніколи більше не включати кеш». Це: обмежити поведінку кешу, встановити правильні правила обходу для автентифікованих користувачів, перемістити зберігання кешу на виділений том,
ввести квоти на диск та сповіщення по inode. Оптимізація не була неправильною; бракувало запобіжних механізмів.

Міні‑історія 3: Нудна, але правильна практика, що врятувала ситуацію

Контентний сайт використовував строгий pipeline розгортання: імунні релізи, конфіги в контролі версій і префлайт, який запускав nginx -t,
PHP‑синтакс‑перевірку кастомного коду і смоук‑тест, що робив запити до /, /wp-login.php і статичного активу.

Інженер змерджив зміну до правил перезапису Nginx для обробки старої структури URL. Конфіг пройшов синтаксис, але смоук‑тест упав: головна сторінка повертала 500.
Pipeline автоматично зупинив розгортання і залишив старий конфіг у роботі. Ніякої інцидентної сторінки. Ніякої аварійної наради. Просто провалений job і трохи роздратований інженер.

Помилка була тонкою: правило перезапису посилалося на іменовану групу захоплення, якої не існувало для деяких шляхів, що спричиняло внутрішній цикл редиректів і 500.
Оскільки смоук‑тест включав головну сторінку і кілька репрезентативних URL, він зловив це одразу.

Мораль агресивно несексуальна: префлайти і смоук‑тести дешевші за героїчні заходи. Не потрібно ідеального тестування; потрібні декілька перевірок, які голосно падають.

Поширені помилки: симптом → корінна причина → виправлення

Найшвидший спосіб дебагу — впізнати шаблони. Найповільніший — трактувати кожний 500 як щось принципово нове.
Ось помилки, які я часто бачу в реальних системах.

1) «500 тільки на /wp-admin» → вичерпання пам’яті або хуки адмінки → підвищити пам’ять правильно і виправити плагін

• Симптом: Головна сторінка завантажується; wp-admin повертає 500.
• Корінна причина: Адмін‑сторінки завантажують більше коду (плагіни, редактори, конструктори). Ліміт пам’яті занадто малий або фатал у хуку, що виконується лише в адмінці.
• Виправлення: Перевірте журнали PHP на «Allowed memory size exhausted», встановіть пам’ять у php.ini (не лише у wp-config) для PHP‑FPM і оновіть/вимкніть плагін.

2) «500 після увімкнення пермалінків» → погана конфігурація перезапису → відновіть базові правила

• Симптом: Працює на ?p=123, падає на красивих URL.
• Корінна причина: Відсутній mod_rewrite (Apache), неправильний try_files (Nginx) або зламаний .htaccess.
• Виправлення: Перевірте налаштування перезапису сервера, перегенеруйте пермалінки, тримайте правила мінімальними.

3) «500 після оновлення PHP» → невідповідність розширень або застарілий код → узгодьте розширення і оновіть код

• Симптом: Сайт впав відразу після зміни версії PHP.
• Корінна причина: Плагін/тема використовує видалені/застарілі функції; необхідні розширення не встановлені для нової версії PHP.
• Виправлення: Перевірте журнали фаталів, встановіть відсутні модулі, відкотіть PHP при потребі, потім оновіть плагіни/теми для сумісності.

4) «Інтермітентні 500 під навантаженням» → насичення пулу PHP‑FPM або повільна БД → масштабування або налаштування, а не лише підвищення таймаутів

• Симптом: Випадкові 500 під час піків трафіку.
• Корінна причина: Воркери FPM вичерпано, або запит до БД зависає і споживає воркери. Таймаути каскадують.
• Виправлення: Виміряйте RAM на воркер, налаштуйте pm.max_children відповідально, додайте кешування/object cache, оптимізуйте повільні запити, масштабуйтесь.

5) «500 після ‘малих змін конфігу’» → перезавантаження Nginx/Apache пройшло, але поведінка зламалась → швидко порівняйте конфіги і відкотіть

• Симптом: Ні розгортання коду, але хтось підправив конфіг.
• Корінна причина: Неправильний upstream сокет, неправильний root, невірний порядок блоків location, внутрішні цикли редиректів.
• Виправлення: Спочатку відкотіть зміну конфігу, потім повторно застосуйте її з тестами. У інцидентах відкат важливіший за хитрощі.

6) «500 плюс ‘permission denied’ у журналах» → дрейф власності → виправте owner/group і umask

• Симптом: У журналах згадується «Permission denied» при читанні PHP‑файлів або записі кеш/завантажень.
• Корінна причина: Файли скопійовані як root; процес розгортання непослідовний; посилення безпеки змінило режими директорій.
• Виправлення: Відновіть коректну власність, уніфікуйте користувача для розгортання і припиніть редагувати продакшен як root, якщо не бажаєте рецидиву інцидентів.

Контрольні списки / покроковий план

Контрольний список швидкого відновлення (мета: 15–30 хвилин)

1. Підтвердіть джерело 500: curl заголовки; обійдіть CDN, якщо можливо.
2. Перевірте журнал помилок веб‑сервера: шукайте FastCGI/PHP фатали, помилки дозволів, цикли перезаписів.
3. Перевірте журнали PHP‑FPM: фатали, досягнуто max_children, сегфолти, тригери slowlog.
4. Перевірте коректність конфігів: nginx -t / apachectl configtest.
5. Перевірте диск + іноди: заповнений диск створює «таємничі» відмови.
6. Карантин плагінів: перейменуйте wp-content/plugins, якщо журнали вказують на плагіни.
7. Тимчасова тема: перейменуйте активну тему, якщо вона підозрюється.
8. Відновіть відомо робочий стан: відкотіть останнє розгортання, відновіть з бекапу/снапшоту, якщо підозрюється корупція.
9. Приберіть тимчасові зміни для відладки: вимкніть WP_DEBUG і видаліть тестові ендпойнти.

Контрольний список для корінних причин і загартування (мета: той самий день)

1. Зробіть журнали запитуваними: централізуйте Nginx/Apache + PHP‑FPM журнали з ідентифікаторами запитів.
2. Додайте смоук‑тести: головна, wp-login, репрезентативний запис і статичний актив.
3. Закріпіть розгортання: послідовна власність, без ад‑хок редагувань root, імунні каталоги релізів де можливо.
4. Моніторте правильні метрики: відсоток диска, відсоток inode, черга/діти PHP‑FPM, рівень 5xx, затримка БД.
5. Визначте відкат: одна команда або одна кнопка. Якщо відкат потребує наради — це не відкат.
6. Аудит плагінів: видаліть покинуті плагіни, фіксуйте версії, тестуйте оновлення у стаді.

Жарт №2: Єдина річ більш постійна, ніж тимчасове виправлення — це тикет зі статусом «не повториться».

Цікаві факти та історичний контекст (що справді допомагає дебагу)

• HTTP 500 існує з ранніх днів HTTP/1.0, але він завжди був catch‑all — отже покладатися треба на журнали, а не на код стану.
• WordPress починався як форк b2/cafelog; його екосистема плагінів швидко вибухнула, і ця розширюваність часто є джерелом рантайм‑сюрпризів.
• .htaccess існує головним чином через спільний хостинг: пер‑директорні переопреділення дозволяли юзерам змінювати перезаписи без root. Це також давало їм можливість ламати речі без root.
• «Біла сторінка смерті» часто — фатал PHP з вимкненим відображенням помилок. Користувач бачить пусто; логи бачать правду.
• PHP‑FPM став поширеною моделлю розгортання, бо краще керує процесами, ніж класичний CGI, і гнучкіший за mod_php для сучасних стеків.
• OPcache значно знижує CPU, кешуючи скомпільований байткод, але застарілий кеш може імітувати «рандомні» 500 після розгортань.
• Вичерпання інодів старше за хмарні технології: ext‑файлові системи можуть вичерпати іноди раніше ніж байти, і веб‑додатки з великою кількістю дрібних файлів особливо уразливі.
• Багато CDN історично повертали загальні 5xx сторінки, навіть коли origin повертав конкретний код, через що команди спочатку діагностували не той шар.
• Модель перезапису WordPress залежить від front controller (index.php обробляє «красиві URL»), тому неправильні правила перезапису виглядають як тотальна відмова сайту.

Поширені питання

1) Чому WordPress показує 500 замість корисної помилки?

У продакшні відображення помилок PHP, як правило, вимкнено (правильно), тож фатали не показують стек‑трейс. Веб‑сервер повертає 500, бо upstream зазнав відмови.
Ваша корисна помилка — у журналах.

2) Чи завжди 500 спричинені плагінами?

Ні. Плагіни часті, але налаштування сервера, відсутні розширення PHP, дозволи, заповнений диск і насичення пулу PHP‑FPM так само поширені у реальних середовищах.
Починайте з журналів, а не з упереджень.

3) Який найшвидший безпечний спосіб відключити всі плагіни?

Перейменуйте wp-content/plugins на інший. WordPress не завантажить звичайні плагіни. Якщо сайт відновиться, ви підтвердили клас проблеми.
Пам’ятайте, що mu-plugins все одно завантажуються.

4) Якщо я збільшив memory_limit, чи це виправить 500?

Іноді. Якщо в журналах є повідомлення про вичерпання пам’яті — так. Але це може приховати витік пам’яті або надто важкий плагін.
Також переконайтесь, що ви змінюєте ліміт у правильному місці (PHP‑FPM pool/php.ini), а не тільки в константах WordPress.

5) Чому 500 іноді з’являється лише час від часу?

Переривчасті 500 зазвичай виникають від поведінки, залежної від навантаження: насичення PHP‑FPM, повільна БД, гонки у шарах кешування, поступове заповнення диска або ненадійна зовнішня залежність. Шукайте кореляції з трафіком і метриками ресурсів.

6) Що робити, якщо журнали порожні?

Тоді ви дивитесь не там або логування некоректно налаштовано. Підтвердіть, який веб‑сервер активний, шляхи до журналів і перевірте journald.
Також перевірте, що ваш запит дійсно доходить до origin (обійдіть CDN/WAF і підтвердіть).

7) Я на Apache. Чи видаляти .htaccess?

Не видаляйте; візьміть у карантин. Перейменуйте його, щоб швидко відновити. Якщо видалення вирішує проблему, відновіть мінімальний WordPress .htaccess і обережно знову застосуйте зміни.

8) Чи може проблема з БД проявлятися як 500?

Так. Хоча WordPress часто показує повідомлення про підключення до БД, деякі шари кешування об’єктів і кастомний код кидають винятки, які перетворюються на 500.
Перевірте журнали PHP на винятки БД і веб‑журнали на таймаути upstream.

9) Як визначити, чи це PHP‑FPM чи код WordPress?

Створіть тимчасовий мінімальний PHP‑ендоінт (або використайте наявний health check) і запросіть його через той самий vhost.
Якщо він працює, PHP‑FPM, ймовірно, у порядку, а збої — у кодовому шляху WordPress. Після видаліть ендпойнт.

10) Що найефективніше запобігає повторюваним інцидентам 500?

Pipeline розгортання з смоук‑тестами і одноатна команда відкату. Ви переживете зламані плагіни, якщо можете відкотитись за секунди, а не погоджуватися в чаті.

Висновок: наступні кроки, що дійсно знижують повтори

Помилки WordPress 500 не рідкість і не містичні. Вони кажуть вашій системі «щось зламалося», але відмовляються уточнити що.
Ваше завдання — змусити її говорити: підтвердіть шар, прочитайте журнали, ізолюйте середовище, потім або проробіть фікс, або сміливо відкотіться.

Якщо ви хочете практичну послідовність заходів після ліквідації пожежі, зробіть це:

1. Переконайтесь, що журнали Nginx/Apache і PHP‑FPM зберігаються, ротуються і доступні для пошуку.
2. Додайте набір смоук‑тестів, що запускаються при кожному розгортанні і зміні конфігурації.
3. Поставте запобіжні механізми щодо зберігання: сповіщення про диск і inode, розумні локи для кешу і обмеження.
4. Уніфікуйте власність файлів і механіку розгортання, щоб дрейф дозволів перестав бути постійним персонажем у ваших інцидентних звітах.
5. Тестуйте оновлення плагінів/тем у стадії, а PHP‑оновлення розглядайте як проект сумісності, а не «дрібне обслуговування».

Зробіть це, і наступного разу, коли побачите «500 Internal Server Error», це буде півгодинне виправлення з чистим постмортемом, а не вечір інтерпретативного дебагу.