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

.htaccess क्या है?

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

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

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

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

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

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

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

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

What .htaccess actually is

An .htaccess file is Apache's per-directory configuration file. The name is widely understood as a contraction of "hypertext access," reflecting the file's original primary use of restricting access to hypertext documents. Place one in any directory and the directives apply to that directory and every subdirectory beneath it. The file has no name before the dot (it's a Unix dot-file, hidden by default) and it must be named exactly .htaccess (lowercase, leading period) for Apache to find it under the default AccessFileName setting.

There's a real performance cost. Apache's documentation is explicit: "if AllowOverride is set to allow the use of .htaccess files, Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them." The directory tree gets walked on every HTTP request. For a request to /var/www/html/foo/bar/baz.html, Apache stat-checks /.htaccess, then /var/.htaccess, then /var/www/.htaccess, then /var/www/html/.htaccess, and so on, even when none of those files exist. Apache's own recommendation is to use main-config <Directory> blocks where possible (parsed once at startup), and reserve .htaccess for hosting environments where you don't have main-config access.

When you need it (and when you don't)

Apache lists two legitimate use cases for .htaccess: hosting providers giving users limited control without full server-config access, and cases where directives need to differ between subdirectories where the deployer controls only the file system. Outside those, the documentation explicitly recommends moving rules to <Directory> blocks in the main config.

nginx (the second-most-popular web server) does not support .htaccess at all; it deliberately rejects per-directory configuration files for performance reasons, and all configuration lives in nginx.conf and any included site files. If your project is on nginx, this generator's output won't help, you'll need server / location blocks in the nginx config file. Caddy uses its own Caddyfile syntax with automatic HTTPS via Let's Encrypt as the default. LiteSpeed and OpenLiteSpeed support .htaccess for Apache compatibility. IIS uses web.config.

URL rewriting and the canonical HTTPS pattern

Most non-trivial .htaccess work uses mod_rewrite, Apache's rule-based URL rewriting engine built on POSIX extended regular expressions. The basic shape is RewriteRule pattern substitution [flags], optionally preceded by one or more RewriteCond conditions. The standard force-HTTPS block:

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

The [L,R=301] flags mean "this is the last rule in this round" and "respond with HTTP 301 Moved Permanently." A 301 is the right choice for permanent redirects, search engines pass link equity and browsers cache aggressively. Use 302 (Found) only for genuinely temporary redirects, where you don't want the move cached.

Behind a load balancer or reverse proxy that terminates TLS, the origin server sees plain HTTP even when the user's browser is on HTTPS, a naïve RewriteCond %{HTTPS} off rule then redirects forever. The fix is to check the forwarded header instead: RewriteCond %{HTTP:X-Forwarded-Proto} !https. Cloudflare's "Flexible SSL" mode (CDN talks HTTP to origin while user uses HTTPS) is the most common cause of this redirect-loop trap.

Choose between www and non-www canonicalisation with a similar pattern. Pick one canonical hostname for SEO (avoids duplicate-content issues) and for cookie scope (a www subdomain receives different cookies than the apex by default).

Compression and caching

mod_deflate gzip-compresses textual responses, dramatically reducing transfer size on text/HTML/CSS/JS. Wrap the block in <IfModule mod_deflate.c> so it doesn't crash the site on servers where the module isn't loaded. Brotli (mod_brotli) is the modern replacement and uses the same pattern.

mod_expires sets Expires and Cache-Control: max-age headers. The widely-used "access plus 1 year" syntax means the asset can be cached for a year from the moment the user fetched it. Long max-age is correct for hashed asset filenames (app.abc123.js); shorter max-age is correct for HTML and anything mutable. For finer control, Header set Cache-Control "public, max-age=31536000, immutable" on hashed files is the modern best practice.

Security headers worth knowing

• X-Frame-Options: SAMEORIGIN: prevents the page being embedded in <iframe> on other origins. Largely superseded by CSP frame-ancestors.
• Content-Security-Policy: the modern primary defence against XSS and click-jacking. A starter: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'. Tighten over time.
• Strict-Transport-Security (HSTS), tells the browser to only ever talk HTTPS to your domain. max-age=31536000; includeSubDomains is the typical baseline. Add preload only when you're sure HTTPS is permanent, once preloaded into the browser HSTS list, removal is hard.
• X-Content-Type-Options: nosniff: prevents browsers from second-guessing the Content-Type header. The header has only one value.
• Referrer-Policy: strict-origin-when-cross-origin: the modern default; sends the full URL to same-origin requests, only the origin to cross-origin requests, and nothing on HTTPS-to-HTTP downgrade.
• Permissions-Policy: controls browser features like camera, microphone, geolocation. Replaced the older Feature-Policy header.
• X-XSS-Protection: largely deprecated. The filter has been removed from Chrome and never existed in Firefox; modern security relies on CSP. Many old guides still ship it for legacy IE, safe to omit on new sites.

Hide what shouldn't be served

Two security-hardening one-liners pay for themselves:

• Options -Indexes: disables auto-generated directory listings when there's no index.html. Many distributions ship with directory indexing on by default; a stray, unprotected directory should not leak its contents to the web.
• Block dot-files and source-control metadata. A <FilesMatch "^(\.htaccess|\.htpasswd|\.env|\.git.*)$"> block with Require all denied stops attackers from downloading .env (which often contains DB passwords and API keys) or .git/config (which exposes remote URLs and sometimes credentials). Akamai and SANS threat reports document .env exposure as one of the most common application-layer leaks of the 2020s.

Apache 2.4 replaced the older Order Allow,Deny syntax with the cleaner Require family of directives, Require all granted, Require all denied, Require ip 192.0.2.0/24, Require not ip 198.51.100.5. The old syntax still works for backward compatibility but is documented as deprecated.

Common gotchas

• mod_rewrite must be enabled at the server level. On Debian/Ubuntu: sudo a2enmod rewrite && sudo systemctl restart apache2. Without it, every RewriteRule is silently skipped.
• AllowOverride matters. If the main config has AllowOverride None for your <Directory>, every directive in your .htaccess is silently ignored. AllowOverride All permits everything; AllowOverride FileInfo AuthConfig permits just rewriting and authentication, which is enough for most use cases.
• A single typo breaks the whole site. Apache returns a 500 Internal Server Error for every request to the affected directory tree until the file is fixed. Always test in staging first; keep a backup copy named .htaccess.bak; have SSH/FTP access ready so you can rename a broken file remotely. Watch /var/log/apache2/error.log for syntax messages.
• Infinite redirect loops. Browsers cap redirect chains at around 20 hops and show ERR_TOO_MANY_REDIRECTS. The most common causes: HTTPS-redirect rule running on a server behind a TLS-terminating proxy (use %{HTTP:X-Forwarded-Proto}); www and HTTPS rules in the wrong order causing double redirects; Cloudflare Flexible SSL mode.
• The [L] flag re-runs the rewrite engine from the top with the rewritten URL. If a later rule then matches, behaviour can be surprising. Use [END] (Apache 2.3.9+) when you really want a hard stop.
• Per-directory context strips the leading slash. In .htaccess, RewriteRule ^index\.html$ home.html matches; RewriteRule ^/index\.html$ does not. This trips up everyone who copies a rule from a main-config example.
• Some directives are forbidden in .htaccess: <VirtualHost>, <Directory>, <Location>, Listen, ServerName are main-config only. The per-directory file already implicitly applies to its own directory.

More questions

Where exactly should the file go?

In the directory whose contents you want to control. Most shared-hosting users put it in their site's document root, public_html/, www/, or htdocs/ depending on the host. Apache then walks the directory tree applying the rules to that directory and every subdirectory beneath it.

301 or 302, which redirect should I use?

301 Moved Permanently for permanent moves. Search engines transfer link equity to the new URL; browsers cache the redirect aggressively. Use this for "we moved this page forever" cases. 302 Found for temporary redirects, the browser doesn't cache and search engines don't transfer ranking. Use 302 only when the move really is temporary; defaulting to 302 instead of 301 is one of the most common SEO own-goals.

How do I password-protect a directory?

Create an .htpasswd file with the htpasswd command-line utility (it stores username:bcrypt-hash lines) and store it outside your web root. Then in .htaccess: AuthType Basic, AuthName "Restricted Area", AuthUserFile /full/path/to/.htpasswd, Require valid-user. The browser shows a system Basic-auth prompt to anyone visiting the directory. This is the classic Apache pattern; for serious authentication consider an application-level login system instead.

Will this work on WordPress?

WordPress ships with its own .htaccess block (between # BEGIN WordPress and # END WordPress markers) that handles permalinks. WordPress will overwrite anything inside those markers when you save permalinks settings. Add your own rules outside the WordPress markers (typically above them) so they survive automatic regeneration.

Does anything get sent to a server?

No. The generator is JavaScript that assembles directive blocks based on your checkboxes; the output is built in your browser. Nothing about your domain or chosen options leaves the page; the tool works offline once it's loaded.

संबंधित टूल