Varför är Adminer.php tom? Att byta namn fungerar dock bra? Analys av orsaken och en lösning i tre steg.

Igår eftermiddag konfigurerade jag databashanteringsverktyget Adminer på servern. Adminer är lätt och enkelt att använda; en enda PHP-fil gör jobbet, till skillnad från phpMyAdmin som kräver en massa beroenden. Jag laddade ner den senaste versionen från den officiella webbplatsen, laddade upp den till servern, ställde in behörigheterna och öppnade min webbläsare, redo att kolla in det.

Sedan blev allt tomt.

Jag uppdaterade sidan tre gånger, mina fingrar värkte av att trycka på F5 så många gånger. Fortfarande ingenting. Jag öppnade webbläsarens utvecklarverktyg; det visade ett 200 OK-fel, men svarstexten var tom. Jag var helt chockad. Vad pågick?

Jag funderade på det en stund. Kan det vara ett problem med filbehörigheterna? Jag kollade, och det var 755. Kan det vara en inkompatibilitet med PHP-versionen? Jag kollade, och det är PHP 8.2, vilket är okej. Kan själva filen vara felaktig? Jag laddade ner en ny kopia, skrev över den, och den är fortfarande tom.

Av någon oförklarlig anledning tänkte jag, varför inte försöka byta namn?

Jag döpte om adminer.php till adminer1.php och uppdaterade sidan.

Åtkomsten lyckades.

Jag var genuint förbryllad. Samma fil, samma kod, samma server, och den är tillgänglig bara genom att ändra namnet? Vilken slags mystisk logik är det här?

adminer.php-filen är tom.

Senare fick jag veta att detta inte var någon form av vidskepelse; det var PHP-cachning som orsakade problemet.

OPcache, förkortning för Opcode Cache, är ett prestandaoptimeringstillägg för PHP. Dess princip är enkel: PHP är ett tolkat språk, och varje förfrågan kräver att PHP-koden kompileras till opcode innan den körs. OPcache cachar det kompilerade resultatet i minnet, vilket gör att efterföljande förfrågningar kan använda den cachade versionen direkt utan omkompilering, vilket resulterar i en betydande prestandaförbättring.

Men det är där problemet ligger.

Tidigare visade adminer.php "Filen hittades inte" (jag hade laddat upp fel fil), och OPcache hade cachat det kompilerade resultatet av det felaktiga innehållet. Senare ersatte jag adminer.php med rätt kod, men OPcache ignorerade den och fortsatte att läsa den gamla cachen från minnet, vilket resulterade i en tom sida eller det gamla felmeddelandet.

När du byter namn på den till adminer1.php blir det en helt ny filsökväg för OPcache, och den kommer att ladda om och lösa den korrekt.

Det är som om du redan har fått en ny bok, men bibliotekets indexkort har fortfarande den gamla bokens utgivningsnummer. När du letar efter den i hyllan är den förstås tom. Men om du ändrar bokens titel skapar biblioteket ett nytt indexkort åt dig, och då kan du hitta det.

Orsak 1: OPcache-cache orsakar tomma utrymmen

Hur hanterar man det?

Starta om PHP-FPM-tjänsten och rensa OPcache-cachen.

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

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

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

Efter omstart, byt namn på filen tillbaka till adminer.php, uppdatera webbsidan (det rekommenderas att trycka på Ctrl+F5 för att tvinga fram en uppdatering av webbläsaren), och problemet borde vara löst.

Men historien är inte över än.

Efter att ha startat om PHP-FPM ändrade jag tillbaka admin.php-filen, uppdaterade sidan, men den var fortfarande tom. Jag var helt förbryllad.

Orsak 2: Begränsningar för Nginx-konfigurationsregler

Detta leder till den andra möjliga orsaken.

Nginx-konfigurationsfilen kan ha speciella regler som begränsar admin.php.

Jag konfigurerade tidigare Fail2Ban i HestiaCP-panelen och skrev en exakt matchningsregel för adminer.php för att förhindra brute-force-attacker. Regeln hårdkodade filnamnet adminer.php, så när du döpte om det till adminer1.php kringgick du denna Nginx-regel och kunde komma åt den normalt.

Felsökningsmetoden är enkel: sök efter hårdkodade poster i Nginx-konfigurationen.

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

Om du hittar regler som `location = /adminer.php { … }`, betyder det att Nginx hanterar just detta filnamn på ett speciellt sätt. Ta bara bort eller ändra det.

Orsak 3: PHP-felvisningsinställningar

Det tredje skälet är mer subtilt.

PHP-skriptet stoppas eller ger ett fel, men sidan inaktiverar felvisning (display_errors = Off). I en produktionsmiljö döljer PHP fel som standard och visar en tom sida. Om din inmatningsfil (t.ex. index.php) kraschar av någon anledning när du försöker inkludera "./adminer.php", kommer sidan helt enkelt att bli tom.

I den här situationen är det mest tillförlitliga att kontrollera felloggen:

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

Loggen kommer att berätta den verkliga orsaken till den vita skärmen.

Ärligt talat hittade jag äntligen problemet genom att kontrollera error.log. Det visade sig att adminer.php anropade ett icke-existerande PHP-tillägg, och display_errors var avstängt, så sidan var tom, men felloggen registrerade det tydligt.

Lösningar och felsökningssteg

Denna händelse har lämnat ett djupt intryck på mig.

Tekniska problem är ofta inte så enkla som de verkar vid första anblicken. En tom adminer.php-fil kan verka som ett filproblem vid första anblicken, men att gräva djupare kan avslöja ett cachningsproblem, längre fram kan det vara ett konfigurationsproblem, och ännu längre fram kan det vara ett problem med själva koden.

Om du inte är programmerare kanske du tror att dessa saker är irrelevanta för dig. Men tänk på det: varje app du använder, varje webbsida du besöker, har ett liknande system som körs bakom kulisserna. Cachning, konfiguration, felhantering – dessa koncept finns faktiskt överallt.

Precis som vi människor. Många gånger kan de "symptom" vi uppvisar, såsom prokrastinering, ångest och irritabilitet, verka som lathet på ytan, men om man gräver djupare kan de bero på oklara mål, ytterligare grävande, en rädsla för misslyckande och ännu djupare, ett tankesätt format av barndomsupplevelser.

Endast genom att hitta den verkliga orsaken kan vi ordinera rätt medicin.

Slutligen, om du också stöter på problemet med en tom admin.php-fil, kontrollera den i denna ordning:

Starta först om PHP-FPM och rensa cachen, kontrollera sedan Nginx-konfigurationen och slutligen error.log.

I de flesta fall räcker de två första stegen för att lösa problemet.

Om det fortfarande inte fungerar, kontrollera då error.log.

Den kommer att ge dig svaret.

Eftersom du har läst så här långt, om du tyckte att det var hjälpsamt, gilla och dela det gärna. Om du vill få uppdateringar först kan du också följa mig!

Tack för att du läste min artikel. Vi ses nästa gång.