Hvorfor er Adminer.php tom? Det virker fint at omdøbe den? Analyse af årsagen og en løsning i 3 trin.

I går eftermiddags konfigurerede jeg databasehåndteringsværktøjet Adminer på serveren. Adminer er let og brugervenligt; en enkelt PHP-fil klarer jobbet, i modsætning til phpMyAdmin , som kræver en masse afhængigheder. Jeg downloadede den seneste version fra den officielle hjemmeside, uploadede den til serveren, satte tilladelserne og åbnede min browser, klar til at tjekke det ud.

Så blev alt tomt.

Jeg opdaterede siden tre gange, mine fingre værkede af at trykke på F5 så mange gange. Stadig ingenting. Jeg åbnede browserens udviklerværktøjer; den viste en 200 OK-fejl, men svarteksten var tom. Jeg var fuldstændig lamslået. Hvad foregik der?

Jeg tænkte over det et øjeblik. Kunne det være et problem med filtilladelser? Jeg tjekkede, og det var 755. Kunne det være en inkompatibilitet med PHP-versionen? Jeg tjekkede, og det er PHP 8.2, hvilket er fint. Kunne selve filen være defekt? Jeg downloadede en ny kopi, overskrev den, og den er stadig tom.

Af en eller anden uforklarlig grund tænkte jeg, hvorfor ikke prøve at ændre mit navn?

Jeg omdøbte adminer.php til adminer1.php og opdaterede siden.

Adgangen var vellykket.

Jeg var oprigtigt forvirret. Den samme fil, den samme kode, den samme server, og den er tilgængelig blot ved at ændre navnet? Hvilken slags mystisk logik er det?

adminer.php-filen er tom.

Senere indså jeg, at det ikke var en eller anden form for overtro; det var PHP-caching, der forårsagede problemet.

OPcache, en forkortelse for Opcode Cache, er en udvidelse til ydeevneoptimering af PHP. Princippet er simpelt: PHP er et fortolket sprog, og hver anmodning kræver, at PHP-koden kompileres til opcode før udførelse. OPcache cacher det kompilerede resultat i hukommelsen, hvilket giver efterfølgende anmodninger mulighed for at bruge den cachelagrede version direkte uden rekompilering, hvilket resulterer i en betydelig forbedring af ydeevnen.

Men det er dér, problemet ligger.

Tidligere viste adminer.php "Filen blev ikke fundet" (jeg havde uploadet den forkerte fil), og OPcache havde cachelagret det kompilerede resultat af det forkerte indhold. Senere erstattede jeg adminer.php med den korrekte kode, men OPcache ignorerede den og fortsatte med at læse den gamle cache fra hukommelsen, hvilket resulterede i en tom side eller den gamle fejlmeddelelse.

Når du omdøber den til adminer1.php, bliver den en helt ny filsti for OPcache, og den vil genindlæse og løse den korrekt.

Det er som om, du allerede har fået en ny bog, men bibliotekets indekskort har stadig den gamle bogs registernummer på sig. Når du går hen for at lede efter den på hylden, er den selvfølgelig tom. Men hvis du ændrer bogens titel, opretter biblioteket et nyt indekskort til dig, og så kan du finde det.

Årsag 1: OPcache-cache forårsager tomme mellemrum

Hvordan håndteres det?

Genstart PHP-FPM-tjenesten, og ryd OPcache-cachen.

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

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

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

Efter genstart skal du omdøbe filen tilbage til adminer.php, opdatere websiden (det anbefales at trykke på Ctrl+F5 for at gennemtvinge en browseropdatering), og problemet burde være løst.

Men historien er ikke slut endnu.

Efter genstart af PHP-FPM, ændrede jeg admin.php-filen tilbage, opdaterede siden, men den var stadig tom. Jeg var fuldstændig forvirret.

Årsag 2: Begrænsninger i Nginx-konfigurationsregler

Dette fører til den anden mulige årsag.

Nginx-konfigurationsfilen kan have særlige regler, der begrænser admin.php.

Jeg konfigurerede tidligere Fail2Ban i HestiaCP-panelet og skrev en præcis matchregel for adminer.php for at forhindre brute-force-angreb. Reglen hardkodede filnavnet adminer.php, så når du omdøbte den til adminer1.php, omgik du denne Nginx-regel og kunne tilgå den normalt.

Fejlfindingsmetoden er enkel: søg efter hardcodede poster i Nginx-konfigurationen.

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

Hvis du finder regler som `location = /adminer.php { … }`, betyder det, at Nginx håndterer dette specifikke filnavn specifikt. Bare slet eller rediger det.

Årsag 3: PHP-fejlvisningsindstillinger

Den tredje grund er mere subtil.

PHP-scriptet bliver opfanget eller giver en fejl, men siden deaktiverer fejlvisning (display_errors = Off). I et produktionsmiljø skjuler PHP fejl som standard og viser en tom side. Hvis din indtastningsfil (f.eks. index.php) går ned af en eller anden grund under forsøget på at inkludere "./adminer.php", vil siden simpelthen blive tom.

I denne situation er det den mest pålidelige metode at kontrollere fejlloggen:

# 查看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 vil fortælle dig den virkelige årsag til den hvide skærm.

For at være ærlig fandt jeg endelig problemet ved at tjekke error.log. Det viste sig, at adminer.php kaldte en ikke-eksisterende PHP-udvidelse, og display_errors var slået fra, så siden var tom, men fejlloggen registrerede det tydeligt.

Løsninger og fejlfindingstrin

Denne hændelse har efterladt et dybt indtryk på mig.

Tekniske problemer er ofte ikke så simple, som de ser ud til ved første øjekast. En tom adminer.php-fil kan ved første øjekast virke som et filproblem, men dybere grave kan afsløre et caching-problem, længere nede kan det være et konfigurationsproblem, og endnu længere nede kan det være et problem med selve koden.

Hvis du ikke er programmør, tror du måske, at disse ting er irrelevante for dig. Men tænk over det: hver app, du bruger, hver webside, du besøger, har et lignende system, der kører bag kulisserne. Caching, konfiguration, fejlhåndtering – disse koncepter findes faktisk overalt.

Ligesom os mennesker. Mange gange kan de "symptomer", vi udviser, såsom udsættelse, angst og irritabilitet, virke som dovenskab på overfladen, men graver man dybere, kan de skyldes uklare mål, yderligere gravning, en frygt for at fejle og endnu dybere, en tankegang formet af barndomsoplevelser.

Kun ved at finde den egentlige årsag kan vi ordinere den rette medicin.

Hvis du også støder på problemet med en tom admin.php-fil, skal du kontrollere den i denne rækkefølge:

Genstart først PHP-FPM og ryd cachen, tjek derefter Nginx-konfigurationen, og tjek til sidst error.log.

I de fleste tilfælde er de første to trin nok til at løse problemet.

Hvis det stadig ikke virker, så tjek selvfølgelig error.log.

Den vil fortælle dig svaret.

Nu du har læst så langt, så synes du meget godt om og del det, hvis du fandt det nyttigt. Hvis du vil modtage opdateringer først, kan du også følge mig!

Tak fordi du læste min artikel. Vi ses næste gang.