.htaccess जनरेटर
अपनी वेबसाइट के लिए सामान्य .htaccess नियम जनरेट करें। आवश्यक विकल्प चुनें और जनरेट किए गए कोड को कॉपी करें।
Performance
Security
• The .htaccess file should be placed in the root directory of your website
• Make sure mod_rewrite is enabled on your Apache server
• Always backup your existing .htaccess file before replacing it
• Some hosting providers may restrict certain .htaccess directives
.htaccess जनरेटर का उपयोग कैसे करें
- 1
अपना डोमेन दर्ज करें
Domain Settings फ़ील्ड में अपना डोमेन नाम, जैसे example.com, टाइप करें।
- 2
नियम चुनें
अपनी ज़रूरत के विकल्प चुनें, जैसे Force HTTPS, www को Force या Remove करना, GZIP कम्प्रेशन, हॉटलिंक सुरक्षा, या कस्टम एरर पेज।
- 3
रीडायरेक्ट जोड़ें
URL रीडायरेक्ट के लिए, पुराना और नया पाथ दर्ज करें और स्थायी 301 या अस्थायी 302 रीडायरेक्ट चुनें।
- 4
कॉपी करें या डाउनलोड करें
Copy to Clipboard या Download .htaccess का इस्तेमाल करें और फ़ाइल को अपनी साइट की रूट डायरेक्टरी में अपलोड करें।
Apache .htaccess फ़ाइल में महारत
.htaccess फ़ाइल असल में क्या करती है
एक .htaccess फ़ाइल Apache वेब सर्वर के लिए प्रति-डायरेक्टरी कॉन्फ़िगरेशन फ़ाइल है। जब Apache को AllowOverride चालू करके बनाया जाता है, तो यह उस डायरेक्टरी की .htaccess फ़ाइल पढ़ता है जहाँ से वह सर्व कर रहा होता है, साथ ही हर मूल डायरेक्टरी की भी, और उनके निर्देशों को उस अनुरोध पर लागू करता है। इससे आप सर्वर के बर्ताव, रीडायरेक्ट, कैशिंग, एक्सेस कंट्रोल और बहुत कुछ बदल सकते हैं, बिना मुख्य सर्वर कॉन्फ़िगरेशन को छुए या Apache को फिर से शुरू किए। बदलाव ठीक अगले ही अनुरोध पर असरदार हो जाते हैं, और यही चीज़ साझा होस्टिंग पर .htaccess को इतना सुविधाजनक बनाती है जहाँ आपके पास मुख्य कॉन्फ़िग तक कोई पहुँच नहीं होती।
फ़ाइल का नाम सचमुच .htaccess है, शुरू में एक बिंदु और बिना किसी एक्सटेंशन के, और Unix जैसी प्रणालियों पर यह बिंदु इसे एक छिपी फ़ाइल बना देता है। यह उसी डायरेक्टरी में रहती है जिसका बर्ताव आप बदलना चाहते हैं; सबसे आम तौर पर वह आपकी साइट की document root होती है। रूट में रखा कोई नियम पूरी साइट पर लागू होता है, जब तक कि कोई गहरी .htaccess उसे ओवरराइड न कर दे।
सिर्फ़ Apache: Nginx और बाक़ी इसे अनदेखा करते हैं
एक भी नियम लिखने से पहले सबसे पहले यही पक्का करना है: .htaccess एक Apache विशेषता है। Nginx, दूसरा प्रमुख वेब सर्वर, .htaccess फ़ाइलें बिलकुल नहीं पढ़ता और डिज़ाइन से कभी पढ़ेगा भी नहीं। अगर आपकी साइट Nginx पर चलती है, तो रूट में .htaccess डालने से कुछ नहीं होता, और इसके बराबर के रीडायरेक्ट, रीराइट और हेडर इसके बजाय Nginx सर्वर ब्लॉक में लिखने होंगे। LiteSpeed और कुछ Apache-संगत सर्वर .htaccess सिंटैक्स समझते हैं, पर Nginx, Caddy और IIS हर एक अपने ही कॉन्फ़िगरेशन फ़ॉर्मेट का इस्तेमाल करते हैं।
अगर आपको पक्का नहीं है कि आपके पास कौन-सा सर्वर है, तो Server रिस्पॉन्स हेडर जाँचें, जिसे इस साइट का HTTP Header Viewer आपको दिखा सकता है। वहाँ Apache दिखना इस बात की पुष्टि करता है कि .htaccess काम करेगी; nginx दिखने का मतलब है कि इस फ़ाइल के साथ आप ग़लत राह पर हैं।
mod_rewrite के साथ रीडायरेक्ट और कैनॉनिकलाइज़ेशन
.htaccess का सबसे आम काम URL रीडायरेक्ट करना है, जिसे यह RewriteEngine On ब्लॉक में लिपटे mod_rewrite मॉड्यूल के ज़रिए करती है। एक साधारण स्थायी बदलाव किसी पुराने पथ से नए पथ तक Redirect 301 का इस्तेमाल करता है, जबकि RewriteRule रेगुलर एक्सप्रेशन के साथ पैटर्न-आधारित रीडायरेक्ट संभालता है। लगभग हर साइट को जिन दो कैनॉनिकलाइज़ेशन कामों की ज़रूरत होती है वे हैं एक अकेले होस्टनेम को मजबूर करना (या तो हमेशा www या हमेशा ग़ैर-www) और HTTPS को मजबूर करना, दोनों एक ऐसे RewriteCond से हासिल होते हैं जो आने वाले अनुरोध की जाँच करता है, उसके बाद एक RewriteRule जो कैनॉनिकल संस्करण के लिए 301 जारी करता है।
जिन बदलावों को आप रखना चाहते हैं उनके लिए हमेशा 301 (स्थायी) का इस्तेमाल करें, क्योंकि 301 लिंक इक्विटी को गंतव्य तक पहुँचाता है और सर्च इंजनों को अपना इंडेक्स अपडेट करने को कहता है। एक सूक्ष्म पर अहम बारीक़ी रीडायरेक्ट शृंखलाओं से बचना है: http://example.com को सीधे एक ही छलाँग में https://www.example.com भेजें, बजाय पहले https://example.com से होकर उछलने के। हर अतिरिक्त छलाँग देरी जोड़ती है और रैंकिंग संकेतों को थोड़ा कमज़ोर कर देती है, जिसे पकड़ने में इस साइट का Redirect Chain Checker मदद कर सकता है।
प्रदर्शन: कम्प्रेशन, कैशिंग और AllowOverride की क़ीमत
दो .htaccess विशेषताएँ तुरंत प्रदर्शन की जीतें देती हैं। GZIP कम्प्रेशन, जो mod_deflate के ज़रिए कॉन्फ़िगर होता है, HTML, CSS और JavaScript जैसी टेक्स्ट-आधारित प्रतिक्रियाओं को भेजे जाने से पहले सिकोड़ देता है, अक्सर ट्रांसफ़र आकार को 60 से 80 प्रतिशत तक घटाते हुए। ब्राउज़र कैशिंग, जो mod_expires या mod_headers के ज़रिए Cache-Control और Expires हेडर से सेट होती है, ब्राउज़रों को छवियों और फ़ॉन्ट जैसी स्थिर संपत्तियों को हर बार फिर से डाउनलोड करने के बजाय दोबारा इस्तेमाल करने को कहती है। मिलकर ये उपलब्ध सबसे ज़्यादा-असरदार, सबसे कम-मेहनत वाली गति सुधारों में से कुछ हैं।
हालाँकि ख़ुद .htaccess की एक छिपी क़ीमत है। चूँकि Apache को हर अनुरोध के पथ के साथ हर डायरेक्टरी में एक .htaccess फ़ाइल की जाँच करनी पड़ती है, AllowOverride चालू रखने से हर अनुरोध में फ़ाइलसिस्टम लुकअप जुड़ जाते हैं। अपने नियंत्रण वाली किसी ज़्यादा-ट्रैफ़िक साइट पर, इन निर्देशों को मुख्य सर्वर कॉन्फ़िगरेशन में ले जाना और AllowOverride None सेट करना नापने लायक़ तेज़ होता है। साझा होस्टिंग पर आपके पास आम तौर पर कोई विकल्प नहीं होता, और सुविधा ओवरहेड से बढ़कर होती है, पर यह जानना सार्थक है कि प्रदर्शन-महत्वपूर्ण सर्वरों के लिए .htaccess को क्यों हतोत्साहित किया जाता है।
सुरक्षा, त्रुटि पेज और एक्सेस कंट्रोल
रीडायरेक्ट और प्रदर्शन से परे, .htaccess का व्यापक रूप से इस्तेमाल किसी साइट को मज़बूत करने और निखारने के लिए होता है। कस्टम त्रुटि पेज, जो ErrorDocument निर्देश से सेट होते हैं, 404 और 500 प्रतिक्रियाओं के लिए Apache की भोंडी पड़ने को आतुर डिफ़ॉल्ट त्रुटि स्क्रीनों को ब्रांडेड पेजों से बदल देते हैं, जो उपयोगकर्ताओं और सुरक्षा दोनों के लिए बेहतर है। हॉटलिंक सुरक्षा Referer हेडर पर RewriteCond का इस्तेमाल करके दूसरी साइटों को आपकी छवियों को एम्बेड करने और आपका बैंडविड्थ खपाने से रोकती है। आप X-Frame-Options, Content-Security-Policy और Strict-Transport-Security जैसे सुरक्षा हेडर भी Header निर्देश के ज़रिए भेज सकते हैं।
एक्सेस कंट्रोल के लिए, .htaccess किसी डायरेक्टरी को IP पते से सीमित कर सकती है या .htpasswd के ज़रिए पासवर्ड माँग सकती है, और यह उन author-enumeration स्कैनों को रोक सकती है जो कंटेंट मैनेजमेंट सिस्टमों पर उपयोगकर्ता नामों की टोह लेते हैं। ये नियंत्रण सचमुच उपयोगी हैं, पर याद रखें कि ये तभी चलते हैं जब Apache अनुरोध को सामान्य पथ से सर्व करता है; इन्हें सिर्फ़ .htaccess पर निर्भर रहने के बजाय उचित एप्लिकेशन-स्तरीय सुरक्षा के साथ मिलाएँ।
सिंटैक्स माफ़ नहीं करता: भरोसा करने से पहले जाँचें
.htaccess के साथ सबसे बड़ा जोखिम यह है कि कोई सिंटैक्स त्रुटि आम तौर पर चुपचाप विफल नहीं होती। इसके बजाय यह उस डायरेक्टरी के नीचे के हर पेज के लिए 500 Internal Server Error छेड़ देती है, और फ़ाइल ठीक होने तक पूरी साइट को ऑफ़लाइन कर देती है। कोई कंपाइल क़दम नहीं है और परिनियोजन से पहले कोई सत्यापन नहीं है, इसलिए एक टाइपो, कोई गुमशुदा मॉड्यूल, या आपके होस्ट द्वारा बंद किया गया कोई निर्देश तुरंत सब कुछ तोड़ सकता है। Apache निर्देश क्रम के प्रति भी संवेदनशील हैं: रीराइट नियम ऊपर से नीचे की ओर जाँचे जाते हैं, और किसी ख़ास नियम से पहले रखा कोई चौड़ा नियम उन अनुरोधों को निगल सकता है जिन्हें वह ख़ास नियम पकड़ने के लिए था।
सुरक्षित तरीक़ा यह है कि बदलने से पहले मौजूदा .htaccess का हमेशा बैकअप लें, बदलाव कम-ट्रैफ़िक की खिड़कियों में परिनियोजित करें, और बाद में फ़ौरन साइट लोड करके पक्का करें कि वह अब भी जवाब देती है। अगर आपको कोई 500 त्रुटि दिखे, तो पहले बैकअप बहाल करें और बाद में डीबग करें। जब कोई निर्देश mod_rewrite या mod_deflate जैसे किसी मॉड्यूल पर निर्भर हो, तो पक्का करें कि आपके होस्ट के पास वह मॉड्यूल चालू है, क्योंकि किसी गुमशुदा मॉड्यूल के नियम त्रुटि दे सकते हैं।
अक्सर पूछे जाने वाले प्रश्न
यह जनरेटर कौन-से नियम बना सकता है?
301 और 302 रीडायरेक्ट में क्या अंतर है?
मैं जनरेट की गई .htaccess फ़ाइल कहाँ रखूँ?
क्या यह Nginx या अन्य सर्वरों पर काम करता है?
क्या जनरेट किया गया कोड कहीं भेजा जाता है?
संबंधित टूल्स
इन उपयोगी टूल्स के साथ आगे बढ़ें