Чому файл Adminer.php порожній? Перейменування працює нормально? Аналіз причини та 3-етапне рішення.

Вчора вдень я налаштовував інструмент керування базами даних Adminer на сервері. Adminer легкий і простий у використанні; один PHP-файл виконує всю роботу, на відміну від phpMyAdmin , який вимагає купи залежностей. Я завантажив останню версію з офіційного сайту, завантажив її на сервер, встановив дозволи та відкрив браузер, готовий перевірити.

Потім все стало порожнім.

Чому файл Adminer.php порожній? Перейменування працює нормально? Аналіз причини та 3-етапне рішення.

Я тричі оновлював сторінку, пальці боліли від стількох натискань F5. Все ще нічого. Я відкрив інструменти розробника браузера; вони показували помилку 200 OK, але тіло відповіді було порожнім. Я був повністю приголомшений. Що відбувається?

Я на мить задумався. Можливо, це проблема з правами доступу до файлу? Я перевірив, і це було 755. Можливо, це несумісність версій PHP? Я перевірив, і це PHP 8.2, що нормально. Можливо, сам файл пошкоджений? Я завантажив нову копію, перезаписав її, а вона все ще порожня.

З якоїсь незрозумілої причини, подумав я, чому б не спробувати змінити ім'я?

Я перейменував adminer.php на adminer1.php та оновив сторінку.

Доступ успішно отримано.

Я був щиро збентежений. Той самий файл, той самий код, той самий сервер, і до нього можна отримати доступ, лише змінивши назву? Що це за містична логіка?

Проблема з пустим файлом adminer.php

Пізніше я зрозумів, що це не було якесь забобони; саме кешування PHP спричиняло проблему.

OPcache, скорочення від Opcode Cache (кеш операційних кодів), — це розширення для оптимізації продуктивності PHP. Його принцип простий: PHP — це інтерпретована мова, і кожен запит вимагає компіляції PHP-коду в опкод перед виконанням. OPcache кешує скомпільований результат у пам'яті, дозволяючи наступним запитам використовувати кешовану версію безпосередньо без повторної компіляції, що призводить до значного покращення продуктивності.

Але саме в цьому і полягає проблема.

Раніше adminer.php відображав повідомлення "Файл не знайдено" (я завантажив неправильний файл), і OPcache кешував скомпільований результат цього неправильного вмісту. Пізніше я замінив adminer.php правильним кодом, але OPcache проігнорував його та продовжував зчитувати старий кеш з пам'яті, що призводило до порожньої сторінки або старого повідомлення про помилку.

Коли ви перейменуєте його на adminer1.php, це стане абсолютно новим шляхом до файлу для OPcache, і він перезавантажить та вирішить його правильно.

Це ніби ви вже отримали нову книгу, але на бібліотечній картці все ще є номер старої книги. Коли ви підете шукати її на полиці, вона, звісно, ​​порожня. Але якщо ви зміните назву книги, бібліотека створить для вас нову картку, і тоді ви зможете її знайти.

Причина 1: Кеш OPcache спричиняє пробіли

Як з цим боротися?

Перезапустіть службу PHP-FPM та очистіть кеш OPcache.

# 查看正在运行的PHP版本
php -v

# 重启对应的PHP-FPM(例如PHP 8.5)
sudo systemctl restart php8.5-fpm

# 或者重启所有PHP-FPM服务
sudo systemctl restart php*-fpm

Після перезавантаження перейменуйте файл назад на adminer.php, оновіть веб-сторінку (рекомендується натиснути Ctrl+F5 для примусового оновлення браузера), і проблема має бути вирішена.

Але історія ще не закінчена.

Після перезапуску PHP-FPM я змінив файл adminer.php, оновив сторінку, але вона все ще була порожньою. Я був повністю збентежений.

Причина 2: Обмеження правил конфігурації Nginx

Це призводить до другої можливої ​​причини.

Файл конфігурації Nginx може мати спеціальні правила, що обмежують доступ до adminer.php.

Раніше я налаштував Fail2Ban на панелі HestiaCP та написав правило точної відповідності для adminer.php, щоб запобігти атакам методом повного перебору. У правилі було жорстко закодовано ім'я файлу adminer.php, тому після перейменування його на adminer1.php ви обійшли це правило Nginx і змогли отримати доступ до сайту нормально.

Метод усунення несправностей простий: пошук жорстко закодованих записів у конфігурації Nginx.

sudo grep -rn "adminer.php" /etc/nginx/

Якщо ви знайдете правила на кшталт `location = /adminer.php { … }`, це означає, що Nginx обробляє саме це ім'я файлу. Просто видаліть або змініть його.

Причина 3: налаштування відображення помилок PHP

Третя причина більш тонка.

PHP-скрипт перехоплюється або видає помилку, але сторінка вимикає відображення помилок (display_errors = Off). У робочому середовищі PHP приховує помилки за замовчуванням, відображаючи порожню сторінку. Якщо ваш файл входу (наприклад, index.php) з якоїсь причини аварійно завершує роботу під час спроби включити "./adminer.php", сторінка просто стане порожньою.

У таких ситуаціях перевірка журналу помилок є найнадійнішим методом:

# 查看Nginx错误日志
sudo tail -n 20 /var/log/nginx/error.log

# 或者查看HestiaCP对应域名的error日志
sudo tail -n 20 /var/log/nginx/domains/adminer.domain.com.error.log

У журналі буде вказано справжню причину білого екрану.

Чесно кажучи, я нарешті знайшов проблему, перевіривши error.log. Виявилося, що adminer.php викликав неіснуюче розширення PHP, а display_errors був вимкнений, тому сторінка була порожньою, але журнал помилок чітко записав це.

Рішення та кроки усунення несправностей

Цей інцидент справив на мене глибоке враження.

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

Якщо ви не програміст, ви можете вважати, що ці речі для вас не мають значення. Але подумайте: кожен додаток, який ви використовуєте, кожна веб-сторінка, яку ви відвідуєте, має подібну систему, що працює за лаштунками. Кешування, налаштування, обробка помилок — ці концепції насправді всюди.

Так само, як і ми, люди. Часто «симптоми», які ми проявляємо, такі як прокрастинація, тривога та дратівливість, на перший погляд можуть здаватися лінню, але якщо копнути глибше, вони можуть бути пов’язані з нечіткими цілями, подальшим дослідженням, страхом невдачі та ще глибше – зі способами мислення, сформованими дитячим досвідом.

Тільки знайшовши справжню причину, ми можемо призначити правильні ліки.

Зрештою, якщо ви також зіткнулися з проблемою порожнього файлу adminer.php, перевірте його в такому порядку:

Спочатку перезапустіть PHP-FPM та очистіть кеш, потім перевірте конфігурацію Nginx і, нарешті, перевірте error.log.

У більшості випадків перших двох кроків достатньо для вирішення проблеми.

Звісно, ​​якщо це все ще не спрацює, перевірте error.log.

Воно підкаже вам відповідь.

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

Дякую, що прочитали мою статтю. До зустрічі наступного разу.

Сподіваємося, що стаття «Adminer.php Access Blank? Rename Works Normal? Analysis of Announcement and 3 Steps to Comprehensive Solution the Problem» («Доступ до Adminer.php порожній? Перейменування працює нормально? Аналіз причин та 3 кроки для повного вирішення проблеми»), опублікована в блозі Ченя Вейляна ( https://www.chenweiliang.com/ ), буде вам корисною.

Не соромтеся поділитися посиланням на цю статтю: https://www.chenweiliang.com/cwl-34403.html

Щоб розкрити більше прихованих хитрощів🔑, приєднуйтесь до нашого Telegram-каналу!

Поділіться та поставте лайк, якщо вам подобається! Ваші розповсюдження та вподобання — наша постійна мотивація!

 

发表 评论

您的邮箱地址不会被公开。必填项已用*标注

Прокрутка до початку