Kodėl „Adminer.php“ tuščias? Pervadinimas veikia gerai? Priežasties analizė ir 3 žingsnių sprendimas.

Vakar popietę serveryje konfigūravau „Adminer“ duomenų bazių valdymo įrankį. „Adminer“ yra lengvas ir paprastas naudoti; darbą atlieka vienas PHP failas, kitaip nei „phpMyAdmin“ , kuriam reikia daugybės priklausomybių. Atsisiunčiau naujausią versiją iš oficialios svetainės, įkėliau ją į serverį, nustatiau teises ir atidariau naršyklę, pasiruošęs ją išbandyti.

Tada viskas ištuštėjo.

Tris kartus atnaujinau puslapį, pirštai skaudėjo nuo daugybės kartų spaustų F5. Vis dar nieko. Atidariau naršyklės kūrėjo įrankius; jie rodė klaidą „200 OK“, bet atsakymo tekstas buvo tuščias. Buvau visiškai apstulbęs. Kas vyksta?

Akimirką pagalvojau. Gal tai failo leidimų problema? Patikrinau ir radau 755. Gal tai PHP versijos nesuderinamumas? Patikrinau ir radau PHP 8.2, viskas gerai. Gal pats failas sugedęs? Atsisiunčiau naują kopiją, perrašiau, ir ji vis dar tuščia.

Dėl kažkokios nepaaiškinamos priežasties pagalvojau, kodėl nepabandžius pasikeisti vardo?

Pervadinau adminer.php į adminer1.php ir atnaujinau puslapį.

Prieiga sėkminga.

Buvau nuoširdžiai sutrikęs. Tas pats failas, tas pats kodas, tas pats serveris, o prie jo galima prisijungti tik pakeitus pavadinimą? Kas čia per mistinė logika?

Failas „adminer.php“ yra tuščias.

Vėliau supratau, kad tai nebuvo kažkoks prietaras; problemą kėlė PHP talpyklos.

„OPcache“, trumpinys nuo „Opcode Cache“, yra PHP našumo optimizavimo plėtinys. Jo principas paprastas: PHP yra interpretuojama kalba, ir kiekviena užklausa reikalauja, kad PHP kodas būtų sukompiliuotas į opkodą prieš vykdant. „OPcache“ kaupia sukompiliuotą rezultatą atmintyje, leisdama vėlesnėms užklausoms tiesiogiai naudoti talpykloje esančią versiją be perkompiliavimo, todėl žymiai pagerėja našumas.

Bet būtent čia ir slypi problema.

Anksčiau adminer.php rodė „Failas nerastas“ (įkėliau neteisingą failą), o „OPcache“ kaupė kaupiamąjį failą sukompiliuotu rezultatu pagal tą neteisingą turinį. Vėliau pakeičiau „adminer.php“ teisingu kodu, bet „OPcache“ jį ignoravo ir toliau skaitė seną kaupiamąjį failą iš atminties, todėl puslapis buvo tuščias arba buvo rodomas senas klaidos pranešimas.

Kai pervadinsite jį į adminer1.php, jis taps visiškai nauju failo keliu „OPcache“ ir bus perkrautas bei teisingai išspręstas.

Tarsi jau būtumėte gavę naują knygą, bet bibliotekos rodyklės kortelėje vis dar yra senosios knygos numeris. Kai ieškote jos lentynoje, žinoma, ji tuščia. Tačiau jei pakeisite knygos pavadinimą, biblioteka sukurs jums naują rodyklės kortelę, ir tada galėsite ją rasti.

1 priežastis: OPcache talpykloje atsiranda tuščių tarpų

Kaip su tuo kovoti?

Paleiskite PHP-FPM paslaugą iš naujo ir išvalykite OPcache talpyklą.

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

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

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

Paleidę iš naujo, pervadinkite failą atgal į adminer.php, atnaujinkite tinklalapį (rekomenduojama paspausti Ctrl+F5, kad naršyklė būtų atnaujinta priverstinai) ir problema turėtų išsispręsti.

Bet istorija dar nesibaigė.

Perkrovus PHP-FPM, pakeičiau failą adminer.php atgal, atnaujinau puslapį, bet jis vis tiek buvo tuščias. Buvau visiškai sutrikęs.

2 priežastis: „Nginx“ konfigūracijos taisyklių apribojimai

Tai veda prie antros galimos priežasties.

„Nginx“ konfigūracijos faile gali būti specialių taisyklių, ribojančių „adminer.php“.

Anksčiau „HestiaCP“ skydelyje sukonfigūravau „Fail2Ban“ ir parašiau tikslios atitikties taisyklę failui adminer.php, kad būtų išvengta „brute-force“ atakų. Taisyklėje buvo įrašytas failo pavadinimas adminer.php, todėl pervadinę jį į adminer1.php, apeidavote šią „Nginx“ taisyklę ir galėjote prie jo prisijungti įprastai.

Trikčių šalinimo metodas yra paprastas: ieškokite užkoduotų įrašų „Nginx“ konfigūracijoje.

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

Jei randate tokias taisykles kaip `location = /adminer.php { … }`, tai reiškia, kad „Nginx“ specialiai tvarko šį konkretų failo pavadinimą. Tiesiog jį ištrinkite arba pakeiskite.

3 priežastis: PHP klaidų rodymo nustatymai

Trečioji priežastis yra subtilesnė.

PHP scenarijus yra perimamas arba pateikia klaidą, bet puslapis išjungia klaidų rodymą (display_errors = Off). Gamybos aplinkoje PHP pagal numatytuosius nustatymus paslepia klaidas, rodydamas tuščią puslapį. Jei jūsų įvesties failas (pvz., index.php) dėl kokių nors priežasčių sugenda bandant įtraukti „./adminer.php“, puslapis tiesiog taps tuščias.

Šioje situacijoje patikimiausias būdas yra patikrinti klaidų žurnalą:

# 查看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

Žurnale bus nurodyta tikroji balto ekrano priežastis.

Tiesą sakant, problemą galiausiai radau patikrinęs error.log failą. Paaiškėjo, kad adminer.php iškvietė neegzistuojantį PHP plėtinį, o display_errors buvo išjungtas, todėl puslapis buvo tuščias, bet klaidų žurnale tai buvo aiškiai užfiksuota.

Sprendimai ir trikčių šalinimo veiksmai

Šis įvykis man paliko gilų įspūdį.

Techninės problemos dažnai nėra tokios paprastos, kaip atrodo iš pirmo žvilgsnio. Tuščias adminer.php failas iš pirmo žvilgsnio gali atrodyti kaip failo problema, tačiau giliau paieškojus galima atskleisti talpyklos problemą, vėliau tai gali būti konfigūracijos problema, o dar vėliau – paties kodo problema.

Jei nesate programuotojas, galite manyti, kad šie dalykai jums nereikšmingi. Tačiau pagalvokite: kiekviena jūsų naudojama programa, kiekvienas lankomas tinklalapis turi panašią sistemą, veikiančią užkulisiuose. Talpykla, konfigūracija, klaidų apdorojimas – šios sąvokos iš tikrųjų yra visur.

Lygiai kaip ir mes, žmonės. Dažnai tokie „simptomai“, kaip atidėliojimas, nerimas ir irzlumas, iš pirmo žvilgsnio gali atrodyti kaip tinginystė, tačiau giliau įsigilinus, jie gali būti susiję su neaiškiais tikslais, tolesniu gilinimusi, nesėkmės baime ir dar giliau – vaikystės patirties suformuotu mąstymu.

Tik nustatę tikrąją priežastį, galime paskirti tinkamą vaistą.

Galiausiai, jei taip pat susiduriate su tuščio adminer.php failo problema, patikrinkite jį tokia tvarka:

Pirmiausia paleiskite PHP-FPM iš naujo ir išvalykite talpyklą, tada patikrinkite „Nginx“ konfigūraciją ir galiausiai patikrinkite error.log failą.

Daugeliu atvejų pirmųjų dviejų žingsnių pakanka problemai išspręsti.

Žinoma, jei tai vis tiek nepadeda, patikrinkite error.log failą.

Tai jums pasakys atsakymą.

Kadangi jau perskaitėte iki šiol, jei manote, kad tai buvo naudinga, prašome paspausti „patinka“ ir pasidalyti. Jei norite gauti naujienas pirmieji, taip pat galite mane sekti!

Ačiū, kad perskaitėte mano straipsnį. Iki kito karto.