Bakit blangko ang Adminer.php? Pero maayos naman ang pagpapalit ng pangalan nito? Pagsusuri ng sanhi at isang 3-hakbang na solusyon.

Kahapon ng hapon, kino-configure ko ang Adminer database management tool sa server. Magaan at madaling gamitin ang Adminer; isang PHP file lang ang nakakagawa ng trabaho, hindi tulad ng phpMyAdmin na nangangailangan ng maraming dependency. Na-download ko ang pinakabagong bersyon mula sa opisyal na website, in-upload ito sa server, itinakda ang mga permission, at binuksan ang aking browser, handa nang tingnan ito.

Pagkatapos, naging blanko ang lahat.

Tatlong beses kong ni-refresh ang pahina, sumasakit na ang mga daliri ko sa paulit-ulit na pagpindot sa F5. Wala pa rin. Binuksan ko ang developer tools ng browser; nagpakita ito ng 200 OK error, pero walang laman ang response body. Natigilan ako nang husto. Ano ang nangyayari?

Pinag-isipan ko ito sandali. Maaari kayang problema ito sa pahintulot ng file? Tiningnan ko, at ito ay 755. Maaari kayang hindi tugma ang bersyon ng PHP? Tiningnan ko, at ito ay PHP 8.2, na ayos naman. Maaari kayang may depekto ang mismong file? Nag-download ako ng bagong kopya, pinalitan ito, at blangko pa rin ito.

Sa hindi maipaliwanag na dahilan, naisip ko, bakit hindi ko subukang palitan ang pangalan ko?

Pinalitan ko ang pangalan ng adminer.php ng ​​adminer1.php at ni-refresh ang pahina.

Matagumpay ang pag-access.

Naguluhan talaga ako. Parehong file, parehong code, parehong server, at maa-access lang ito sa pamamagitan ng pagpapalit ng pangalan? Anong klaseng mistikal na lohika ito?

Ang isyu ng isang blangkong adminer.php file

Kalaunan ay napagtanto ko na hindi pala ito isang uri ng pamahiin; ang PHP caching ang sanhi ng problema.

Ang OPcache, maikli para sa Opcode Cache, ay isang extension sa pag-optimize ng pagganap para sa PHP. Simple lang ang prinsipyo nito: Ang PHP ay isang wikang binibigyang-kahulugan, at ang bawat kahilingan ay nangangailangan ng pag-compile ng PHP code sa opcode bago isagawa. Inilalagay ng OPcache ang na-compile na resulta sa memorya, na nagpapahintulot sa mga kasunod na kahilingan na gamitin nang direkta ang naka-cache na bersyon nang walang muling pag-compile, na nagreresulta sa isang makabuluhang pagpapabuti sa pagganap.

Pero doon nakasalalay ang problema.

Dati, ipinapakita ng adminer.php ang "File not found" (maling file ang na-upload ko), at na-cache ng OPcache ang na-compile na resulta ng maling nilalamang iyon. Kalaunan, pinalitan ko ang adminer.php ng ​​tamang code, ngunit hindi ito pinansin ng OPcache at ipinagpatuloy ang pagbabasa ng lumang cache mula sa memorya, na nagresulta sa isang blangkong pahina o lumang mensahe ng error.

Kapag binago mo ang pangalan nito sa adminer1.php, ito ay magiging isang ganap na bagong path ng file para sa OPcache, at ire-reload at mare-resolve ito nang tama.

Parang nakakuha ka na ng bagong libro, pero ang index card ng library ay may call number pa rin ng lumang libro. Kapag hinanap mo ito sa shelf, siyempre, wala itong laman. Pero kung babaguhin mo ang pamagat ng libro, gagawa ang library ng bagong index card para sa iyo, at saka mo ito mahahanap.

Dahilan 1: Ang OPcache cache ay nagdudulot ng mga blangkong espasyo

Paano haharapin ito?

I-restart ang serbisyo ng PHP-FPM at i-clear ang OPcache cache.

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

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

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

Pagkatapos mag-restart, palitan ang pangalan ng file pabalik sa adminer.php, i-refresh ang webpage (inirerekomenda na pindutin ang Ctrl+F5 para piliting i-refresh ang browser), at dapat ay nalutas na ang problema.

Pero hindi pa tapos ang kwento.

Pagkatapos kong i-restart ang PHP-FPM, binago ko ang adminer.php file, ni-refresh ang pahina, pero blangko pa rin ito. Naguluhan talaga ako.

Dahilan 2: Mga paghihigpit sa tuntunin ng pagsasaayos ng Nginx

Ito ang humahantong sa pangalawang posibleng dahilan.

Ang Nginx configuration file ay maaaring may mga espesyal na panuntunan na naghihigpit sa adminer.php.

Nauna ko nang na-configure ang Fail2Ban sa HestiaCP panel at sumulat ng exact match rule para sa adminer.php para maiwasan ang brute-force attacks. Itinatag ng rule ang filename na adminer.php, kaya kapag pinalitan mo na ito ng pangalan sa adminer1.php, nalampasan mo na ang Nginx rule na ito at maaari mo na itong ma-access nang normal.

Simple lang ang paraan ng pag-troubleshoot: maghanap ng mga hard-coded na entry sa configuration ng Nginx.

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

Kung makakita ka ng mga panuntunan tulad ng `location = /adminer.php { … }`, nangangahulugan ito na espesyal na pinangangasiwaan ng Nginx ang partikular na pangalan ng file na ito. Burahin o baguhin lamang ito.

Dahilan 3: Mga setting ng pagpapakita ng error sa PHP

Ang ikatlong dahilan ay mas banayad.

Ang PHP script ay naharang o naglalabas ng error, ngunit hindi pinapagana ng pahina ang pagpapakita ng error (display_errors = Off). Sa isang production environment, itinatago ng PHP ang mga error bilang default, na nagpapakita ng isang blangkong pahina. Kung ang iyong entry file (hal., index.php) ay mag-crash sa ilang kadahilanan habang sinusubukang isama ang "./adminer.php", ang pahina ay magiging blangko lamang.

Sa ganitong mga sitwasyon, ang pagsuri sa error log ang pinaka-maaasahang paraan:

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

Sasabihin sa iyo ng log ang tunay na dahilan ng puting screen.

Sa totoo lang, sa wakas ay nahanap ko na ang problema sa pamamagitan ng pagtingin sa error.log. Lumalabas na tumatawag ang adminer.php ng ​​isang hindi umiiral na PHP extension, at naka-off ang display_errors, kaya blangko ang pahina, ngunit malinaw itong naitala ng error log.

Mga solusyon at hakbang sa pag-troubleshoot

Malalim ang impresyon na iniwan sa akin ng pangyayaring ito.

Ang mga teknikal na problema ay kadalasang hindi kasing simple ng inaakala sa unang tingin. Ang isang blangkong adminer.php file ay maaaring mukhang isang problema sa file sa unang tingin, ngunit ang pagsisiyasat nang mas malalim ay maaaring magbunyag ng problema sa caching, na sa kalaunan ay maaaring isang isyu sa configuration, at sa kalaunan ay maaaring isang problema sa mismong code.

Kung hindi ka isang programmer, maaaring isipin mong walang kaugnayan sa iyo ang mga bagay na ito. Pero isipin mo: bawat app na ginagamit mo, bawat webpage na binibisita mo, ay may katulad na sistemang tumatakbo sa likod ng mga eksena. Pag-cache, pag-configure, paghawak ng error—ang mga konseptong ito ay nasa lahat ng dako.

Tulad nating mga tao. Madalas, ang mga "sintomas" na ating ipinapakita, tulad ng pagpapaliban-liban, pagkabalisa, at pagkairita, ay maaaring mukhang katamaran sa unang tingin, ngunit kung susuriin pa nang mas malalim, maaaring ang mga ito ay dahil sa hindi malinaw na mga layunin, patuloy na pagsisiyasat, takot sa pagkabigo, at mas malalim pa, isang pag-iisip na hinubog ng mga karanasan noong bata pa.

Sa pamamagitan lamang ng pagtuklas ng tunay na ugat ng sanhi ay maaari nating maireseta ang tamang gamot.

Panghuli, kung nakakaranas ka rin ng problema ng isang blangkong adminer.php file, suriin ito sa ganitong pagkakasunod-sunod:

Una, i-restart ang PHP-FPM at i-clear ang cache, pagkatapos ay suriin ang configuration ng Nginx, at panghuli, suriin ang error.log.

Sa karamihan ng mga kaso, ang unang dalawang hakbang ay sapat na upang malutas ang problema.

Siyempre, kung hindi pa rin iyon gumagana, tingnan mo ang error.log.

Sasabihin nito sa iyo ang sagot.

Dahil nabasa mo na ito hanggang dito, kung nakatulong ito sa iyo, paki-like at share naman. Kung gusto mo munang makatanggap ng mga update, puwede mo rin akong sundan!

Salamat sa pagbabasa ng aking artikulo. Sa susunod na lang ulit.