.htaccess फ़ाइल जनरेटर

.htaccess क्या है?

.htaccess फ़ाइल Apache वेब सर्वर के लिए कॉन्फ़िगरेशन फ़ाइल है। यह URL पुनर्निर्देशन, सुरक्षा नियम, पहुँच नियंत्रण और प्रदर्शन अनुकूलन परिभाषित करने देती है।

अक्सर पूछे जाने वाले प्रश्न

.htaccess फ़ाइल कहाँ रखें?

इसे अपनी साइट की रूट डायरेक्टरी में रखें (आमतौर पर public_html या www)। नियम उस डायरेक्टरी और उप-डायरेक्टरी पर लागू होते हैं।

क्या यह Nginx के साथ काम करेगा?

नहीं। .htaccess Apache-विशिष्ट है। Nginx nginx.conf या उपलब्ध साइट फ़ाइलों में अपने स्वयं के कॉन्फ़िगरेशन सिंटैक्स का उपयोग करता है।

क्या .htaccess मेरी साइट को धीमा कर सकता है?

Apache प्रत्येक अनुरोध पर .htaccess जाँचता है, इसलिए बहुत बड़ी फ़ाइलें ओवरहेड जोड़ सकती हैं। उच्च ट्रैफ़िक साइटों के लिए जाँच न्यूनतम रखें।

.htaccess वास्तव में क्या है

.htaccess file Apache की per-directory configuration file है। Name widely «hypertext access» के contraction के रूप में समझा जाता है, जो file के original primary use को reflect करता है, hypertext documents तक access restrict करना। किसी भी directory में एक रखें और directives उस directory और उसके नीचे के हर subdirectory पर apply होती हैं। File में dot से पहले कोई name नहीं होता (यह एक Unix dot-file है, default में hidden) और इसे exactly .htaccess (lowercase, leading period) नाम होना चाहिए ताकि Apache इसे default AccessFileName setting के तहत find कर सके।

Real performance cost है। Apache का documentation explicit है: «यदि AllowOverride .htaccess files के use की allow करने के लिए set है, तो Apache हर directory में .htaccess files देखेगा। इस प्रकार, .htaccess files permit करने से performance hit होती है, चाहे आप actually उन्हें use करें या न करें।» Directory tree every HTTP request पर walk होती है। /var/www/html/foo/bar/baz.html पर एक request के लिए, Apache /.htaccess stat-check करता है, फिर /var/.htaccess, फिर /var/www/.htaccess, फिर /var/www/html/.htaccess, और ऐसे ही, भले ही उनमें से कोई भी file exist न करे। Apache की खुद की recommendation है कि जहां possible हो main-config <Directory> blocks use करें (startup पर एक बार parse होते हैं), और .htaccess उन hosting environments के लिए reserve करें जहां आपके पास main-config access नहीं है।

इसकी ज़रूरत कब है (और कब नहीं)

Apache .htaccess के लिए दो legitimate use cases list करता है: hosting providers users को full server-config access के बिना limited control देते हुए, और ऐसे cases जहां directives को subdirectories के बीच differ करने की ज़रूरत हो जहां deployer केवल file system control करता हो। इनके बाहर, documentation explicitly <Directory> blocks में main config में rules move करने की recommend करता है।

nginx (second-most-popular web server) .htaccess को बिल्कुल support नहीं करता; यह performance reasons के लिए deliberately per-directory configuration files reject करता है, और सभी configuration nginx.conf और किसी भी included site files में live करती है। यदि आपका project nginx पर है, तो इस generator का output help नहीं करेगा, आपको nginx config file में server / location blocks चाहिए। Caddy अपना Caddyfile syntax use करता है जिसमें default के रूप में Let's Encrypt via automatic HTTPS है। LiteSpeed और OpenLiteSpeed Apache compatibility के लिए .htaccess support करते हैं। IIS web.config use करता है।

URL rewriting और canonical HTTPS pattern

अधिकांश non-trivial .htaccess work mod_rewrite use करता है, Apache का rule-based URL rewriting engine जो POSIX extended regular expressions पर built है। Basic shape है RewriteRule pattern substitution [flags], optionally एक या अधिक RewriteCond conditions से preceded। Standard force-HTTPS block:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

[L,R=301] flags का मतलब है «यह इस round में last rule है» और «HTTP 301 Moved Permanently के साथ respond करें।» 301 permanent redirects के लिए सही choice है, search engines link equity pass करते हैं और browsers aggressively cache करते हैं। 302 (Found) केवल genuinely temporary redirects के लिए use करें, जहां आप move cached नहीं चाहते।

TLS terminate करने वाले load balancer या reverse proxy के पीछे, origin server plain HTTP देखता है भले ही user का browser HTTPS पर हो, और ऐसे में naïve RewriteCond %{HTTPS} off rule forever redirect करता रहता है। Fix है forwarded header check करना: RewriteCond %{HTTP:X-Forwarded-Proto} !https। Cloudflare का «Flexible SSL» mode (CDN user के लिए HTTPS use करते हुए origin को HTTP से बात करता है) इस redirect-loop trap का सबसे common कारण है।

www और non-www canonicalisation के बीच similar pattern से choose करें। SEO के लिए एक canonical hostname चुनें (duplicate-content issues avoid करता है) और cookie scope के लिए (एक www subdomain default में apex से different cookies receive करता है)।

Compression और caching

mod_deflate textual responses को gzip-compress करता है, text/HTML/CSS/JS पर transfer size dramatically reduce करता है। Block को <IfModule mod_deflate.c> में wrap करें ताकि उन servers पर site crash न हो जहां module loaded नहीं है। Brotli (mod_brotli) modern replacement है और same pattern use करता है।

mod_expires Expires और Cache-Control: max-age headers set करता है। Widely-used «access plus 1 year» syntax का मतलब है कि asset को user के fetch करने के moment से एक साल के लिए cache किया जा सकता है। Long max-age hashed asset filenames (app.abc123.js) के लिए correct है; shorter max-age HTML और किसी भी mutable चीज़ के लिए correct है। Finer control के लिए, hashed files पर Header set Cache-Control "public, max-age=31536000, immutable" modern best practice है।

जानने योग्य Security headers

• X-Frame-Options: SAMEORIGIN: page को other origins पर <iframe> में embed होने से रोकता है। Largely CSP frame-ancestors द्वारा superseded।
• Content-Security-Policy: XSS और click-jacking के against modern primary defence। एक starter: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'। समय के साथ tighten करें।
• Strict-Transport-Security (HSTS), browser को बताता है कि आपके domain को हमेशा केवल HTTPS से बात करे। max-age=31536000; includeSubDomains typical baseline है। preload केवल तभी add करें जब आप sure हों कि HTTPS permanent है, एक बार browser HSTS list में preloaded होने के बाद removal hard है।
• X-Content-Type-Options: nosniff: browsers को Content-Type header के बारे में second-guessing से रोकता है। Header का केवल एक value होता है।
• Referrer-Policy: strict-origin-when-cross-origin: modern default; same-origin requests को full URL send करता है, cross-origin requests को केवल origin, और HTTPS-to-HTTP downgrade पर कुछ नहीं।
• Permissions-Policy: browser features जैसे camera, microphone, geolocation control करता है। Older Feature-Policy header को replace किया।
• X-XSS-Protection: largely deprecated। Filter Chrome से remove हो चुका है और Firefox में कभी था ही नहीं; modern security CSP पर rely करती है। कई old guides इसे legacy IE के लिए still ship करते हैं, नए sites पर omit करना safe है।

जो serve नहीं होना चाहिए उसे छुपाएं

दो security-hardening one-liners खुद के लिए pay करते हैं:

• Options -Indexes: जब कोई index.html न हो तो auto-generated directory listings disable करता है। कई distributions directory indexing default में on के साथ ship करती हैं; एक stray, unprotected directory को web पर अपनी contents leak नहीं करनी चाहिए।
• Dot-files और source-control metadata block करें। <FilesMatch "^(\.htaccess|\.htpasswd|\.env|\.git.*)$"> block Require all denied के साथ attackers को .env (जिसमें अक्सर DB passwords और API keys होते हैं) या .git/config (जो remote URLs और कभी-कभी credentials expose करता है) download करने से रोकता है। Akamai और SANS threat reports .env exposure को 2020s के most common application-layer leaks में से एक document करते हैं।

Apache 2.4 ने older Order Allow,Deny syntax को cleaner Require family of directives से replace किया, Require all granted, Require all denied, Require ip 192.0.2.0/24, Require not ip 198.51.100.5। Old syntax backward compatibility के लिए still काम करता है लेकिन deprecated के रूप में documented है।

सामान्य समस्याएं

• mod_rewrite server level पर enabled होना चाहिए। Debian/Ubuntu पर: sudo a2enmod rewrite && sudo systemctl restart apache2। इसके बिना, हर RewriteRule silently skip होता है।
• AllowOverride matters। यदि main config में AllowOverride None है आपके <Directory> के लिए, तो आपके .htaccess में हर directive silently ignore होती है। AllowOverride All सब कुछ permit करता है; AllowOverride FileInfo AuthConfig सिर्फ rewriting और authentication permit करता है, जो अधिकांश use cases के लिए enough है।
• एक typo पूरी site break कर देता है। Apache affected directory tree पर हर request के लिए 500 Internal Server Error return करता है जब तक file fix न हो। हमेशा staging में पहले test करें; .htaccess.bak नाम का backup copy रखें; SSH/FTP access ready रखें ताकि broken file remotely rename कर सकें। Syntax messages के लिए /var/log/apache2/error.log watch करें।
• Infinite redirect loops। Browsers redirect chains को around 20 hops पर cap करते हैं और ERR_TOO_MANY_REDIRECTS show करते हैं। Most common causes: TLS-terminating proxy के पीछे server पर running HTTPS-redirect rule (%{HTTP:X-Forwarded-Proto} use करें); wrong order में www और HTTPS rules जो double redirects cause करते हैं; Cloudflare Flexible SSL mode।
• [L] flag rewrite engine को rewritten URL के साथ top से re-run करता है। यदि कोई बाद का rule match करता है, तो behaviour surprising हो सकता है। [END] (Apache 2.3.9+) use करें जब आप really hard stop चाहते हों।
• Per-directory context leading slash strip करता है। .htaccess में, RewriteRule ^index\.html$ home.html match करता है; RewriteRule ^/index\.html$ नहीं। यह हर उस person को trip करता है जो main-config example से rule copy करता है।
• कुछ directives .htaccess में forbidden हैं: <VirtualHost>, <Directory>, <Location>, Listen, ServerName main-config only हैं। Per-directory file already implicitly अपनी directory पर apply होती है।

अधिक Questions

File exactly कहां होनी चाहिए?

उस directory में जिसके contents आप control करना चाहते हैं। अधिकांश shared-hosting users इसे अपने site के document root में रखते हैं, host के हिसाब से public_html/, www/, या htdocs/। Apache फिर directory tree walk करता है उस directory और उसके नीचे के हर subdirectory पर rules apply करते हुए।

301 या 302, कौन सा redirect use करूं?

301 Moved Permanently permanent moves के लिए। Search engines new URL पर link equity transfer करते हैं; browsers redirect को aggressively cache करते हैं। इसे «we moved this page forever» cases के लिए use करें। 302 Found temporary redirects के लिए, browser cache नहीं करता और search engines ranking transfer नहीं करते। 302 केवल तभी use करें जब move really temporary हो; 301 की जगह 302 default करना most common SEO own-goals में से एक है।

Directory को password-protect कैसे करूं?

.htpasswd file htpasswd command-line utility से create करें (यह username:bcrypt-hash lines store करता है) और इसे अपने web root के outside रखें। फिर .htaccess में: AuthType Basic, AuthName "Restricted Area", AuthUserFile /full/path/to/.htpasswd, Require valid-user। Browser directory visit करने वाले किसी भी person को system Basic-auth prompt दिखाता है। यह classic Apache pattern है; serious authentication के लिए application-level login system consider करें।

क्या यह WordPress पर काम करेगा?

WordPress अपना .htaccess block ship करता है (# BEGIN WordPress और # END WordPress markers के बीच) जो permalinks handle करता है। WordPress permalink settings save करने पर उन markers के अंदर कुछ भी overwrite करता है। WordPress markers के outside अपने rules add करें (typically उनके ऊपर) ताकि वे automatic regeneration में survive करें।

क्या कुछ server पर भेजा जाता है?

नहीं। Generator JavaScript है जो आपके checkboxes के आधार पर directive blocks assemble करता है; output आपके browser में built होता है। आपके domain या chosen options के बारे में कुछ भी page से नहीं जाता; tool एक बार load होने के बाद offline काम करता है।

संबंधित टूल