Adminer.php किन खाली छ? यसको नाम परिवर्तन गर्दा राम्रो हुन्छ? कारणको विश्लेषण र ३-चरण समाधान।

हिजो दिउँसो, म सर्भरमा Adminer डाटाबेस व्यवस्थापन उपकरण कन्फिगर गर्दै थिएँ। Adminer हलुका र प्रयोग गर्न सजिलो छ; एउटै PHP फाइलले काम गर्छ, phpMyAdmin भन्दा फरक जसलाई धेरै निर्भरताहरू चाहिन्छ। मैले आधिकारिक वेबसाइटबाट पछिल्लो संस्करण डाउनलोड गरें, यसलाई सर्भरमा अपलोड गरें, अनुमतिहरू सेट गरें, र मेरो ब्राउजर खोलें, यसलाई जाँच गर्न तयार थिएँ।

त्यसपछि, सबै कुरा खाली भयो।

मैले तीन पटक पृष्ठ रिफ्रेस गरें, धेरै पटक F5 थिच्दा मेरा औंलाहरू दुखिरहेका थिए। अझै पनि केही भएन। मैले ब्राउजरको विकासकर्ता उपकरणहरू खोलेँ; यसले २०० ओके त्रुटि देखायो, तर प्रतिक्रिया बडी खाली थियो। म पूर्ण रूपमा स्तब्ध भएँ। के भइरहेको थियो?

मैले एकछिन सोचें। के यो फाइल अनुमति समस्या हुन सक्छ? मैले जाँच गरें, र यो ७५५ थियो। के यो PHP संस्करण असंगति हुन सक्छ? मैले जाँच गरें, र यो PHP ८.२ हो, जुन ठीक छ। के फाइल आफैंमा दोषपूर्ण हुन सक्छ? मैले नयाँ प्रतिलिपि डाउनलोड गरें, यसलाई अधिलेखन गरें, र यो अझै खाली छ।

कुनै अकल्पनीय कारणले गर्दा, मैले सोचेँ, किन मेरो नाम परिवर्तन गर्ने प्रयास नगर्ने?

मैले adminer.php को नाम परिवर्तन गरेर adminer1.php राखें र पृष्ठ रिफ्रेस गरें।

पहुँच सफल भयो।

म साँच्चै अचम्ममा परें। उही फाइल, उही कोड, उही सर्भर, र नाम परिवर्तन गरेर मात्र पहुँचयोग्य? यो कस्तो प्रकारको रहस्यमय तर्क हो?

खाली adminer.php फाइलको समस्या

पछि मैले महसुस गरें कि यो कुनै प्रकारको अन्धविश्वास थिएन; यो PHP क्यासिङ थियो जसले समस्या निम्त्याइरहेको थियो।

OPcache, Opcode Cache को लागि छोटो, PHP को लागि एक कार्यसम्पादन अनुकूलन विस्तार हो। यसको सिद्धान्त सरल छ: PHP एक व्याख्या गरिएको भाषा हो, र प्रत्येक अनुरोधलाई कार्यान्वयन गर्नु अघि PHP कोडलाई opcode मा कम्पाइल गर्न आवश्यक छ। OPcache ले संकलित परिणामलाई मेमोरीमा क्यास गर्छ, पछिल्ला अनुरोधहरूलाई पुन: संकलन बिना सीधै क्यास गरिएको संस्करण प्रयोग गर्न अनुमति दिन्छ, परिणामस्वरूप महत्त्वपूर्ण कार्यसम्पादन सुधार हुन्छ।

तर समस्या त्यहीँ छ।

पहिले, adminer.php ले "File not found" देखाएको थियो (मैले गलत फाइल अपलोड गरेको थिएँ), र OPcache ले त्यो गलत सामग्रीको संकलित नतिजा क्यास गरेको थियो। पछि, मैले adminer.php लाई सही कोडले प्रतिस्थापन गरें, तर OPcache ले यसलाई बेवास्ता गर्‍यो र मेमोरीबाट पुरानो क्यास पढ्न जारी राख्यो, जसको परिणामस्वरूप खाली पृष्ठ वा पुरानो त्रुटि सन्देश देखा पर्‍यो।

जब तपाईंले यसलाई adminer1.php मा पुन: नामाकरण गर्नुहुन्छ, यो OPcache को लागि पूर्ण रूपमा नयाँ फाइल मार्ग बन्छ, र यसले पुन: लोड गर्नेछ र यसलाई सही रूपमा समाधान गर्नेछ।

यो तपाईंले पहिले नै नयाँ किताब पाउनुभएको जस्तो छ, तर पुस्तकालयको अनुक्रमणिका कार्डमा अझै पनि पुरानो किताबको कल नम्बर छ। जब तपाईं यसलाई शेल्फमा खोज्न जानुहुन्छ, अवश्य पनि, यो खाली हुन्छ। तर यदि तपाईंले पुस्तकको शीर्षक परिवर्तन गर्नुभयो भने, पुस्तकालयले तपाईंको लागि नयाँ अनुक्रमणिका कार्ड सिर्जना गर्नेछ, र त्यसपछि तपाईंले यसलाई फेला पार्न सक्नुहुन्छ।

कारण १: 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 फाइल फेरि परिवर्तन गरें, पृष्ठ रिफ्रेस गरें, तर यो अझै खाली थियो। म पूर्ण रूपमा चकित भएँ।

कारण २: Nginx कन्फिगरेसन नियम प्रतिबन्धहरू

यसले दोस्रो सम्भावित कारणतर्फ डोऱ्याउँछ।

Nginx कन्फिगरेसन फाइलमा adminer.php लाई प्रतिबन्धित गर्ने विशेष नियमहरू हुन सक्छन्।

मैले पहिले HestiaCP प्यानलमा Fail2Ban कन्फिगर गरेको थिएँ र brute-force आक्रमणहरू रोक्नको लागि adminer.php को लागि एक सटीक मिलान नियम लेखेको थिएँ । नियमले adminer.php फाइलनामलाई हार्डकोड गरेको थियो, त्यसैले एक पटक तपाईंले यसलाई adminer1.php मा पुन: नामाकरण गरेपछि, तपाईंले यो Nginx नियमलाई बाइपास गर्नुभयो र यसलाई सामान्य रूपमा पहुँच गर्न सक्नुभयो।

समस्या निवारण विधि सरल छ: Nginx कन्फिगरेसनमा हार्ड-कोड गरिएका प्रविष्टिहरू खोज्नुहोस्।

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

यदि तपाईंले `location = /adminer.php { … }` जस्ता नियमहरू फेला पार्नुभयो भने, यसको अर्थ Nginx ले यो विशिष्ट फाइलनामलाई विशेष रूपमा ह्यान्डल गरिरहेको छ। यसलाई मेटाउनुहोस् वा परिमार्जन गर्नुहोस्।

कारण ३: 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 जाँच गर्नुहोस्।

यसले तपाईंलाई उत्तर बताउनेछ।

तपाईंले यहाँसम्म पढिसक्नुभएको हुनाले, यदि तपाईंलाई यो उपयोगी लाग्यो भने, कृपया यसलाई लाइक र सेयर गर्नुहोस्। यदि तपाईं पहिले अपडेटहरू प्राप्त गर्न चाहनुहुन्छ भने, तपाईं मलाई फलो पनि गर्न सक्नुहुन्छ!

मेरो लेख पढ्नुभएकोमा धन्यवाद। अर्को पटक भेटौँला।