KapsuleHost हर वेबसाइट को एक उच्च प्रदर्शन वाले वेब सर्वर से सर्व करता है जो .htaccess को नहीं पढ़ता, इसलिए आप उस फ़ाइल में जो भी नियम जोड़ें, उनका कोई असर नहीं होता: यह गाइड बताती है कि इसका WordPress साइट के लिए क्या मतलब है, और वह KPanel सेटिंग दिखाती है जो उसी का काम करती है।
यदि आप किसी शेयर्ड cPanel होस्ट से आए हैं, तो संभवतः .htaccess वह जगह थी जहाँ आप रीडायरेक्ट, HTTPS को जबरदस्ती करना, कस्टम एरर पेज और बॉट ब्लॉक डालते थे। यह सभी चीज़ें KapsuleHost पर भी काम करती हैं। बस इन्हें टेक्स्ट फ़ाइल के बजाय KPanel में सेट किया जाता है, और क्योंकि इन्हें सर्वर स्तर पर लागू किया जाता है, ये तेज़ होती हैं और किसी टाइपो से आपकी साइट को नुकसान नहीं पहुँचा सकतीं।
यहाँ .htaccess कुछ क्यों नहीं करता
.htaccess Apache वेब सर्वर के लिए एक प्रति-डायरेक्टरी कॉन्फ़िगरेशन फ़ाइल है। Apache हर एक रिक्वेस्ट पर इसे फिर से पढ़ता है, जो इसे सुविधाजनक तो बनाता ही है, साथ ही धीमा भी बनाता है।
KapsuleHost Apache नहीं चलाता। आपकी साइट एक इवेंट ड्रिवन वेब सर्वर द्वारा सर्व की जाती है जो अपना कॉन्फ़िगरेशन स्टार्टअप पर केवल एक बार लोड करता है, और यही एक बड़ा कारण है कि यहाँ साइटें लोड में भी तेज़ी से जवाब देती हैं। उस सर्वर के पास प्रति-डायरेक्टरी ओवरराइड फ़ाइल जैसा कुछ भी नहीं है, इसलिए यह कभी .htaccess को खोलता ही नहीं।
KapsuleHost साइट पर .htaccess में नियम जोड़ना चुपचाप विफल हो जाता है। न कोई त्रुटि आती है, न कोई चेतावनी, और फ़ाइल ठीक वहीं रहती है जहाँ आपने उसे छोड़ा था। नियम बस कभी चलते ही नहीं। यदि आप किसी WordPress ट्यूटोरियल का पालन कर रहे हैं जो कहता है "इसे अपने .htaccess में जोड़ें", तो इसके बजाय नीचे दी गई तालिका में KPanel का समतुल्य ढूंढें।
अच्छी बात यह है कि यह सामान्य .htaccess की डरावनी कहानी से उलट है: फ़ाइल में सिंटैक्स त्रुटि यहाँ आपकी साइट को डाउन नहीं कर सकती, क्योंकि कुछ भी इसे पार्स ही नहीं करता।
इसके बिना अब भी क्या काम करता है
परमालिंक्स। Apache पर WordPress साइट को .htaccess की ज़रूरत पड़ने का सबसे आम कारण प्रेटी परमालिंक्स हैं। KapsuleHost पर रीराइट आपकी साइट के सर्वर कॉन्फ़िगरेशन में ही बना होता है, इसलिए /2026/07/my-post/ बिना किसी .htaccess ब्लॉक के WordPress के ज़रिए रिज़ॉल्व हो जाता है। यदि परमालिंक्स 404 दे रहे हैं, तो इसका कारण कुछ और है: देखें WordPress परमालिंक समस्याओं को ठीक करना।
WordPress का फ़ाइल में लिखना। WordPress और कुछ प्लगइन अब भी # BEGIN/# END ब्लॉक को .htaccess में लिखते हैं क्योंकि वे मानकर चलते हैं कि Apache चल रहा है। इससे कोई नुकसान नहीं होता। फ़ाइल असली है, लिखने योग्य है, और आप इसे फाइल मैनेजर में देख पाएंगे। बस इसका कोई पाठक नहीं है।
सुरक्षा प्लगइन जो "हार्डनिंग लागू हो गई" की रिपोर्ट करते हैं। वे प्लगइन जो दावा करते हैं कि उन्होंने xmlrpc.php या wp-config.php को .htaccess संपादित करके लॉक कर दिया है, वास्तव में इस प्लेटफ़ॉर्म पर कुछ भी सुरक्षित नहीं कर पाए हैं। इसके बजाय साइट के अपने सुरक्षा टैब का उपयोग करें, जो सर्वर पर समतुल्य नियम लागू करता है।
आम .htaccess नियमों के लिए KPanel समतुल्य
इनमें से हर एक साइट पर ही मौजूद होता है: वेबसाइटें, फिर आपकी साइट, फिर दिखाया गया टैब।
| आप .htaccess में जो लिखते | KPanel में यह कहाँ मिलता है |
|---|---|
HTTPS को जबरदस्ती करने के लिए RewriteCond %{HTTPS} off | सेटिंग्स, फिर Behavior के अंतर्गत HTTPS को जबरदस्ती करें |
Redirect 301 /old /new | सेटिंग्स, फिर रीडायरेक्ट |
ErrorDocument 404 /404.html | सेटिंग्स, फिर त्रुटि पृष्ठ |
किसी फ़ोल्डर को पासवर्ड से सुरक्षित करने के लिए AuthType Basic | सेटिंग्स, फिर पासवर्ड सुरक्षा |
किसी पते को ब्लॉक करने के लिए Require not ip 203.0.113.4 | WordPress, फिर सुरक्षा |
क्रॉलर को ब्लॉक करने के लिए RewriteCond %{HTTP_USER_AGENT} (BadBot) | प्रदर्शन, फिर क्रॉलर |
DirectoryIndex index.php index.html | Serving के अंतर्गत सेटिंग्स, फिर डायरेक्टरी इंडेक्स |
कम्प्रेशन और कैशिंग के लिए mod_deflate / mod_expires | पहले से चालू है। कम्प्रेशन और कैश हेडर सर्वर पर सेट होते हैं |
इनमें से दो चीज़ें .htaccess वाले संस्करण से कहीं ज़्यादा कर सकती हैं। रीडायरेक्ट एग्ज़ैक्ट पाथ, ट्रेलिंग-स्लैश प्रीफ़िक्स और /blog/* जैसे वाइल्डकार्ड को सपोर्ट करते हैं, और आपके सेव करने के बाद KPanel रीडायरेक्ट को लाइव जाँचता भी है। एरर पेज अपने असली स्टेटस कोड के साथ सर्व होते हैं, इसलिए एक कस्टम 404 पेज सर्च इंजन के लिए अब भी वास्तव में 404 ही रहता है, न कि माफ़ी के साथ एक 200।
फ़ाइल को ढूंढना और पढ़ना
आप फिर भी .htaccess को देखना चाह सकते हैं, आमतौर पर यह जानने के लिए कि किसी प्लगइन ने उसमें क्या लिखा है, या KPanel में दोबारा बनाने से पहले नियमों की नकल लेने के लिए।
WordPress टैब से
- KPanel में साइन इन करें और बाईं साइडबार में वेबसाइटें पर क्लिक करें।
- वांछित साइट पर क्लिक करें।
- WordPress टैब खोलें, फिर wp-config सेक्शन खोलें।
.htaccessपैनल तक स्क्रॉल करें। सामग्री केवल पढ़ने के लिए दिखाई जाती है, और यदि आपको बदलाव करना हो तो एक Edit बटन मौजूद है।
फाइल मैनेजर से
- साइट खोलें, फिर सेटिंग्स, फिर फाइल मैनेजर।
- टूलबार में छिपी हुई फ़ाइलें दिखाएं पर क्लिक करें। डॉट से शुरू होने वाली फ़ाइलें डिफ़ॉल्ट रूप से छिपी होती हैं, इसलिए ऐसा करने तक
.htaccessदिखाई नहीं देगी। - इसे बिल्ट-इन एडिटर में खोलने के लिए
.htaccessपर क्लिक करें।
यह फ़ाइल आपकी साइट के रूट में, wp-config.php और wp-content के साथ मौजूद होती है। एडिटर और उसके परमिशन नियंत्रणों की पूरी जानकारी फाइल मैनेजर का उपयोग करना में है।
साइट के रूट में कुछ भी संपादित करने से पहले बैकअप ले लें, भले ही वह फ़ाइल पढ़ी ही न जा रही हो। इसमें कुछ खर्च नहीं होता और इसका मतलब है कि एक क्लिक में आप वापस आ सकते हैं। देखें बैकअप लेना।
डिफ़ॉल्ट WordPress ब्लॉक
संदर्भ के लिए, यह वह ब्लॉक है जिसे WordPress खुद के लिए लिखता है। Apache होस्ट पर यह परमालिंक्स को चलाता है। KapsuleHost पर यह निष्क्रिय है, और इसे हटाने से कुछ भी नहीं टूटेगा:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
यदि आप बाद में साइट को किसी Apache होस्ट पर ले जा सकते हैं, तो इसे यथावत रहने दें। अगली बार जब आप अपनी परमालिंक सेटिंग्स सेव करेंगे, तो WordPress इसे वैसे भी फिर से लिख देगा।
यदि आप नियमों को माइग्रेट कर रहे हैं
जब आप किसी साइट को cPanel से लेकर आते हैं, तो पुरानी होस्टिंग रद्द करने से पहले पुराना .htaccess खोलें और इसे पंक्ति दर पंक्ति देखें:
- रीडायरेक्ट। हर
RedirectयाRewriteRuleको सेटिंग्स, फिर रीडायरेक्ट में फिर से बनाएं। हर नियम के लिए एक पंक्ति। स्थायी बदलाव के लिए 301 चुनें, और अगर बदलाव पलटा जा सकता है तो 302 चुनें। - HTTPS को जबरदस्ती करना। इसे हटा दें। इसके बजाय साइट की सेटिंग्स में HTTPS को जबरदस्ती करें चालू करें।
- IP ब्लॉक। WordPress, फिर सुरक्षा में, IP ब्लॉकिंग पैनल में फिर से बनाएं।
- कैशिंग और कम्प्रेशन हेडर। इन्हें हटा दें। इनका ध्यान आपके लिए पहले से रखा जाता है, और पुराने होस्ट से बचे
mod_expiresनियम अक्सर भ्रामक कैश व्यवहार का स्रोत बनते हैं। - जो कुछ भी किसी प्लगइन ने लिखा हो। इसे अनदेखा करें। नई साइट पर प्लगइन को फिर से इंस्टॉल करें और उसे अपना काम करने दें।
आपके माइग्रेशन में फ़ाइल खुद सुरक्षित रहती है, इसलिए सूची पर काम करते समय कुछ भी नहीं खोता। पूरा माइग्रेशन वॉकथ्रू: cPanel से वेबसाइट माइग्रेट करना।
समस्या निवारण
"मैंने .htaccess में एक रीडायरेक्ट जोड़ा और कुछ नहीं हुआ।" यह अपेक्षित है। इसे सेटिंग्स, फिर रीडायरेक्ट में जोड़ें। वहाँ का Status कॉलम बताता है कि रीडायरेक्ट लाइव में सत्यापित हुआ या नहीं।
"एक प्लगइन कहता है कि मेरी साइट हार्डनेड है लेकिन एक स्कैनर असहमत है।" प्लगइन ने .htaccess नियम लिखे हैं जिन्हें पढ़ा ही नहीं जा रहा। वास्तव में लागू किए गए सुरक्षा उपायों के लिए साइट के सुरक्षा टैब की जाँच करें।
"मेरे पुराने होस्ट के .htaccess में ऐसे नियम थे जो मुझे समझ नहीं आते।" इन्हें बिना समझे कॉपी न करें। फ़ाइल संलग्न करके एक टिकट खोलें और हम आपको बताएंगे कि किनका KapsuleHost पर समतुल्य मौजूद है और कौन-से नियम केवल किसी शेयर्ड Apache होस्ट की कमी को पूरा करने के लिए थे।
"परमालिंक्स टूटे हुए हैं।" यहाँ यह .htaccess की समस्या नहीं है। WordPress परमालिंक समस्याओं को ठीक करना पर जाएँ, या साइट के WordPress टैब से, फिर त्वरित कार्य, फिर रीराइट फ्लश करें से रीराइट नियमों को फ्लश करें।