वेबसाइट पर 500 त्रुटि: इसे कैसे ठीक करें

वेबसाइट पर 500 त्रुटि: इसे कैसे ठीक करें — चरण-दर-चरण मार्गदर्शिका

क्या आप सोच रहे हैं 500 आंतरिक सर्वर त्रुटि को कैसे ठीक करें एक वेबसाइट पर? यह अक्सर शांत सप्ताह के दिन नहीं, बल्कि ठीक तब प्रकट होता है जब ट्रैफ़िक बढ़ता है, एक विज्ञापन अभियान शुरू होता है, या किसी अन्य अपडेट के तुरंत बाद। त्रुटि 500 का मतलब है आंतरिक सर्वर त्रुटि: पृष्ठ ने प्रतिक्रिया नहीं दी, लेकिन ब्राउज़र को भी कोई सटीक कारण नहीं मिला — बस एक सामान्य विफलता संकेत। यह निराशाजनक है, लेकिन इसे निदान किया जा सकता है। लगभग हमेशा।

अच्छी खबर यह है कि 500 त्रुटि अक्सर अचानक नहीं आती। यह सबसे अधिकतर टूटे हुए कोड, असफल PHP प्रक्रिया, क्षतिग्रस्त .htaccess फ़ाइल, संघर्षरत प्लगइन्स या थीम, या एक सर्वर के मेमोरी और निष्पादन समय की सीमाओं को छूने के कारण होती है। होस्ट भी दोषी हो सकता है। या नवीनतम कमिट।

यदि साइट पहले से ही लीड या बिक्री लाती है, तो 10 मिनट की डाउनटाइम भी राजस्व और विश्वास दोनों को नुकसान पहुंचाती है। यही कारण है कि क्रियाओं का क्रम अनुमान से अधिक महत्वपूर्ण है: पहले समस्या को अलग करें, फिर सेटिंग्स बदलें। कोई अराजकता नहीं।

1. 500 त्रुटि का क्या अर्थ है और यह क्यों प्रकट होती है

आंतरिक सर्वर त्रुटि एक निदान नहीं है, बल्कि कई विफलताओं के लिए एक छत्र शब्द है। सर्वर ने अनुरोध प्राप्त किया, इसे संसाधित करने की कोशिश की, और एक समस्या में चला गया जिसे वह उपयोगकर्ता को उचित तरीके से नहीं दिखा सका। बाहरी रूप से, यह सब एक जैसा दिखता है: एक सफेद पृष्ठ, एक त्रुटि संदेश, कभी-कभी एक खाली स्क्रीन।

इसके 5 सबसे सामान्य कारण हैं। पहला एक टेम्पलेट या फ़ंक्शन को संपादित करने के बाद PHP कोड त्रुटि है। दूसरा .htaccess में गलत नियम हैं। तीसरा एक प्लगइन या थीम संघर्ष है। चौथा संसाधनों की कमी है: memory_limit, max_execution_time, CPU समय। पांचवां एक सर्वर- या होस्टिंग-साइड विफलता है। और एक छठा, बहुत सामान्य है: फ़ाइल अनुमतियाँ गलत सेट की गई हैं।

WordPress और समान CMS प्लेटफार्मों पर, यह विशेष रूप से अपडेट के बाद ध्यान देने योग्य होता है। एक प्लगइन अपडेट होता है, दूसरा नहीं होता, कैश पुराना रहता है, और थीम एक फ़ंक्शन को कॉल करती है जो पहले ही हटा दी गई है। परिणाम एक छोटा लेकिन अप्रिय कैस्केड है। त्रुटि 500 को इस तरह के संयोजन पसंद हैं, यही कारण है कि WordPress 500 त्रुटि समस्या निवारण अक्सर अपडेट, कैश और संगतता जांच से शुरू होता है।

यदि साइट एक वेब एप्लिकेशन के रूप में बनाई गई है, तो श्रृंखला लंबी हो सकती है: API, कार्य कतार, डेटाबेस, बाहरी भुगतान सेवा। ऐसे प्रोजेक्ट्स में, इसके बारे में पहले से सोचना उपयोगी होता है वेबसाइट सुरक्षा और बैकअप पुनर्प्राप्ति लॉजिक, क्योंकि एक घटना बिना इवेंट लॉग के समस्या निवारण को अनुमान लगाने में बदल देती है।

2. सबसे पहले, जांचें कि त्रुटि कहाँ होती है

पहला कदम दायरे को समझना है। क्या 500 त्रुटि केवल एक पृष्ठ पर है? या पूरे साइट पर? या शायद यह प्रशासनिक क्षेत्र में दिखाई देती है जबकि सार्वजनिक भाग अभी भी लोड हो रहा है? ये 3 मामले विभिन्न कारणों की ओर इशारा करते हैं, और वह दायरा जांच सबसे तेज़ वेबसाइट 500 त्रुटि समाधान प्रारंभिक बिंदु।

यदि त्रुटि केवल एक पृष्ठ पर दिखाई देती है, तो स्थानीय कोड की तलाश करें: एक शॉर्टकोड, विजेट, फॉर्म, कस्टम टेम्पलेट, या एम्बेडेड स्क्रिप्ट। यदि पूरी साइट डाउन है, तो .htaccess, PHP, और सिस्टम सीमाओं की जांच करें। यदि प्रशासनिक क्षेत्र नहीं खुलता है, तो प्लगइन्स और थीम की जांच करें। एक अपडेट के बाद, समस्या अक्सर वहीं छिपी होती है।

एक 500 त्रुटि अक्सर नए होस्ट पर जाने के बाद भी दिखाई देती है। PHP सेटिंग्स भिन्न हो सकती हैं, फ़ोल्डर अनुमतियाँ भी भिन्न हो सकती हैं, और पुराने कॉन्फ़िग नियम हमेशा नए वातावरण में फिट नहीं होते। एक माइग्रेशन। एक आश्चर्य।

यह नोट करना मददगार होता है कि सब कुछ कब टूटा: एक प्लगइन स्थापित करने के बाद, थीम बदलने के बाद, PHP संस्करण स्विच करने के बाद, या साइट को स्थानांतरित करने के बाद। वह छोटा टाइमलाइन घंटे बचाता है। कभी-कभी पूरा दिन।

3. .htaccess और प्लगइन्स की जांच कैसे करें

.htaccess एक सामान्य कारण है। एक गलत निर्देश सर्वर को लगभग हर पृष्ठ पर 500 त्रुटियाँ लौटाने के लिए पर्याप्त है। विशेष रूप से यदि रीडायरेक्ट, कैशिंग नियम, या सुंदर पर्मालिंक को मैन्युअल रूप से संपादित किया गया हो।

.htaccess फ़ाइल का अस्थायी नाम बदलना सबसे सरल परीक्षण है, उदाहरण के लिए .htaccess_old। यदि साइट फिर से सक्रिय हो जाती है, तो आपने संभवतः कारण खोज लिया है। फिर एक नई फ़ाइल बनाएं और CMS प्रशासन पैनल में स्थायी लिंक सेटिंग्स को फिर से सहेजें। वर्डप्रेस में, यह स्थायी लिंक अनुभाग के माध्यम से किया जाता है, बिना नियमों को मैन्युअल रूप से कॉपी किए।

यदि नियमों को फिर से बनाने के बाद त्रुटि गायब हो जाती है, तो पुराने फ़ाइल को वापस लाना बेहतर नहीं है। इसमें अभी भी एक अतिरिक्त पंक्ति हो सकती है, उदाहरण के लिए एक पुराने प्लगइन से जो पहले ही हटा दिया गया है। एक अतिरिक्त निर्देश पूरे साइट को नीचे ला सकता है। केवल सिद्धांत में नहीं।

जब एक साइट जटिल रीडायरेक्ट संरचना का उपयोग करती है, विशेष रूप से एक पुन: डिज़ाइन के बाद, यह पहले से जांचने के लायक है कि पुराने URL और कैनोनिकल लिंक कैसे व्यवहार करते हैं। संरचनात्मक नवीनीकरण वाले प्रोजेक्ट्स के लिए, इसके बारे में पढ़ना सहायक हो सकता है एक वेबसाइट पुन: डिज़ाइन के लिए वेब स्टूडियो कैसे चुनें, ताकि आप सर्वर नियमों और आंतरिक मार्गों में भ्रमित न हों।

4. प्लगइन्स को निष्क्रिय करें और थीम की जांच करें

यदि .htaccess साफ है, तो प्लगइन्स पर आगे बढ़ें। वर्डप्रेस पर, यह त्वरित है: फ़ाइल प्रबंधक या FTP के माध्यम से प्लगइन्स फ़ोल्डर का नाम बदलें। सभी प्लगइन्स एक साथ अक्षम हो जाएंगे। यदि 500 त्रुटि गायब हो जाती है, तो कारण उनमें से एक है।

फिर प्लगइन्स को एक-एक करके सक्षम करें। प्रत्येक सक्रियण के बाद साइट की जांच करें। इसी तरह आप संघर्ष करने वाले मॉड्यूल को खोजते हैं, भले ही उनमें से 17 हों। थकाऊ? हाँ। काम करता है? हाँ।

टिपिकल अपराधी कैशिंग, सुरक्षा, SEO, पृष्ठ निर्माता प्लगइन्स, और कोई भी एक्सटेंशन हैं जो रूटिंग या सामग्री निर्माण में हस्तक्षेप करते हैं। कभी-कभी समस्या स्वयं प्लगइन नहीं होती, बल्कि इसका पुराना संस्करण होता है। यह विशेष रूप से अपडेट के बाद सामने आता है।

थीम के साथ वही करें: अस्थायी रूप से CMS डिफ़ॉल्ट थीम पर स्विच करें। यदि प्रशासन क्षेत्र उपलब्ध नहीं है, तो सक्रिय थीम फ़ोल्डर का नाम FTP के माध्यम से बदलें ताकि सिस्टम बैकअप विकल्प पर वापस जा सके। यदि 500 त्रुटि गायब हो जाती है, तो थीम में एक टूटी हुई टेम्पलेट, एक असंगत हुक, या एक पुराना फ़ंक्शन कॉल है।

जब साइट बाहरी सेवाओं से जुड़ी होती है, जैसे भुगतान, तो एकीकरण कोड कभी-कभी त्रुटि को ट्रिगर कर सकता है। ऐसे मामलों में, भुगतान प्रवाह का आकलन करना और जोखिमों को पहले से अपडेट करना सहायक होता है। उदाहरण के लिए, देखें कि एक वेबसाइट से स्ट्राइप को कनेक्ट करने की लागत कितनी हैयदि आपके पास समान एकीकरण और रीडायरेक्ट लॉजिक है।

5. PHP त्रुटियों और सर्वर सीमाओं की जांच करें

यदि प्लगइन्स और थीम समस्या नहीं हैं, तो लॉग्स को देखें। PHP त्रुटि लॉग आमतौर पर दिखाते हैं कि कौन सा फ़ाइल, पंक्ति, या फ़ंक्शन विफल हुआ। कभी-कभी वे इसे सीधे कहते हैं: अनुमति दी गई मेमोरी आकार समाप्त। कभी-कभी: घातक त्रुटि। कभी-कभी: कुछ भी नहीं, जो और भी बुरा है।

लॉग्स होस्टिंग नियंत्रण पैनल में, एक अलग साइट फ़ोल्डर में, या सर्वर की प्रणाली रिपोर्ट में हो सकते हैं। विभिन्न प्रदाता उन्हें विभिन्न स्थानों पर संग्रहीत करते हैं, इसलिए यहां होस्टिंग पैनल आमतौर पर आवश्यक होता है। कम से कम 2 स्थानों की जांच करें: साइट त्रुटि लॉग और खाता प्रणाली लॉग।

अब PHP सेटिंग्स पर। देखें memory_limit, max_execution_time, upload_max_filesize, post_max_size, और PHP संस्करण। यदि साइट एक PHP संस्करण अपग्रेड के बाद क्रैश होने लगी, तो एक संगत संस्करण पर वापस लौटना अक्सर इसे हल कर देता है। यदि मेमोरी बहुत कम है, तो एक भारी पृष्ठ, आयात, या प्लगइन को समाप्त करने के लिए पर्याप्त समय नहीं मिलता।

यह memory_limit सेटिंग विशेष रूप से स्टोर और बड़े कैटलॉग के लिए महत्वपूर्ण है। एक उत्पाद निर्यात पूरी संसाधन पूल का उपयोग कर सकता है। एक आयात फॉर्म भी कर सकता है। यदि साइट एनालिटिक्स, कतारें, बैकग्राउंड कार्य, और निगरानी का उपयोग करती है, तो आपके अवलोकन स्टैक का हिस्सा होना चाहिए, ताकि आप लॉग से आउटेज देख सकें न कि ग्राहक की शिकायत से।साइट एनालिटिक्स और मॉनिटरिंग प्लेटफ़ॉर्म · आपके अवलोकन स्टैक का हिस्सा होना चाहिए, ताकि आप लॉग से आउटेज देख सकें न कि ग्राहक की शिकायत से।

यदि आप सेटिंग्स कहां जांचें, इस बारे में सुनिश्चित नहीं हैं, तो अपने होस्ट से वर्तमान PHP कॉन्फ़िगरेशन और सर्वर सीमाओं को दिखाने के लिए कहें। केवल PHP संस्करण की पुष्टि करें, बल्कि वास्तविक मेमोरी सीमा, निष्पादन समय, और अपलोड आकार भी। यह आश्चर्यजनक है कि समस्या अक्सर केवल एक मान होती है।

6. कैश साफ करें और हाल के परिवर्तनों की समीक्षा करें

कैश समस्या और यह कि यह गायब है, दोनों को छिपा सकता है। इसलिए परिवर्तनों के बाद, साइट कैश, ब्राउज़र कैश, और यदि आप एक CDN का उपयोग करते हैं तो CDN कैश को साफ करें। अन्यथा, आप त्रुटि के पुराने संस्करण को देखेंगे और सोचेंगे कि कुछ भी नहीं बदला।

पहले CMS पैनल में या कैशिंग प्लगइन में कैश साफ करें। फिर ब्राउज़र कैश को साफ करें, बेहतर है कि इंकॉग्निटो मोड में। यदि साइट CDN के माध्यम से सेवा दी जाती है, तो उसे भी साफ करें। तीन स्थान, तीन कैश, एक परिणाम — केवल पूर्ण साफ करने के बाद ही आप परीक्षण पर भरोसा कर सकते हैं।

अगला, नवीनतम परिवर्तनों की समीक्षा करें। क्या आपने एक नया ब्लॉक जोड़ा? क्या आपने टेम्पलेट में एक फ़ंक्शन बदला? क्या आपने पुस्तकालय में एक ताजा फ़ाइल अपलोड की? अंतिम परिवर्तन को वापस रोल करें और फिर से परीक्षण करें। एक 500 त्रुटि अक्सर एक छोटे कोड की एक पंक्ति के बाद प्रकट होती है, न कि “मुख्य अपडेट” के बाद।

चल रहे समर्थन वाले प्रोजेक्ट्स में, ये समस्याएँ आमतौर पर कम होती हैं क्योंकि कोड और सेटिंग्स में परिवर्तन नियंत्रण के माध्यम से होते हैं। यदि आपकी साइट सक्रिय है और नियमित रूप से सुधारित होती है, तो लेख पर लॉन्च के बाद वेबसाइट समर्थन आपको यह देखने में मदद कर सकता है कि कैश और अपडेट्स को आउटेज स्थिति में कैसे नहीं जाने दिया जाए।

यह भी जांचें कि क्या CDN SSL परिवर्तनों, रीडायरेक्ट्स, या सुरक्षा नीति अपडेट के बाद टूट गया। एक गलत प्रतिक्रिया हेडर केवल आपके उपयोगकर्ताओं के एक हिस्से के लिए 500 त्रुटि को ट्रिगर कर सकता है। और इसे पकड़ना बहुत कठिन है।

7. यदि 500 त्रुटि दूर नहीं होती है तो क्या करें

यदि सभी जांचों के बाद भी साइट क्रैश हो रही है, तो व्यवस्थित रूप से काम करने का समय है। होस्टिंग समर्थन से संपर्क करके शुरू करें और विफलता के सटीक समय के लिए लॉग्स का अनुरोध करें। घंटे, तारीख, और वह पृष्ठ दें जहाँ 500 त्रुटि हुई। इसके बिना, समर्थन को इसे खोजने में अधिक समय लगेगा।

फिर फ़ाइल और फ़ोल्डर अनुमतियों की जांच करें। लोग अक्सर फ़ोल्डरों को 777 “अस्थायी” रूप से सेट करते हैं और फिर उन्हें वापस बदलना भूल जाते हैं। यह खराब प्रथा है, और केवल 500 त्रुटि के कारण नहीं: सर्वर सुरक्षा कारणों से ऐसी अनुमतियों को ब्लॉक कर सकता है। फ़ाइलों और निर्देशिकाओं के पास सही अनुमतियाँ होनी चाहिए।

यदि आपके पास एक ताजा बैकअप है, तो साइट के कार्यशील संस्करण को पुनर्स्थापित करें और देखें कि क्या विफलता गायब हो जाती है। यह विशेष रूप से खराब कोर, प्लगइन, या सर्वर माइग्रेशन अपडेट के बाद उपयोगी है। एक रोलबैक 12 असंगत परिवर्तनों को मैन्युअल रूप से ठीक करने की कोशिश करने से अधिक समय बचाता है।

जब साइट व्यवसाय के लिए महत्वपूर्ण होती है, तो पुनर्प्राप्ति में देरी न करें। कभी-कभी कल की प्रति को पुनर्स्थापित करना एक लाइन कोड की खोज में आधे दिन बिताने से सस्ता होता है। और यदि प्रोजेक्ट बाहरी अनुरोधों, फॉर्म, और एपीआई पर निर्भर करता है, तो नेटवर्क पक्ष की भी जांच करें: कभी-कभी समस्या CMS में नहीं होती, बल्कि अवसंरचना में होती है। ऐसे मामलों के लिए, एक निजी नेटवर्क अवसंरचना नियंत्रित वातावरण में जटिलता के एक भाग को स्थानांतरित करने में मदद कर सकता है।

अंतिम व्यावहारिक कदम यह है कि साइट को अस्थायी रूप से न्यूनतम कॉन्फ़िगरेशन पर स्विच करें। केवल कोर, एक थीम, एक कार्यशील प्लगइन, और बुनियादी नियम रखें। यदि उस मोड में 500 त्रुटि गायब हो जाती है, तो एक बार में घटक वापस जोड़ें। इस तरह आप बिना किसी अनावश्यक अनुमान के समस्या तत्व को खोज लेंगे। यह धीमा है, लेकिन ईमानदार है।