Generador .htaccess

¿Qué es un .htaccess?

El archivo .htaccess es un archivo de configuración para los servidores web Apache. Permite definir redirecciones de URL, encabezados de seguridad, reglas de caché y mucho más · sin modificar la configuración principal del servidor.

Preguntas frecuentes

¿Dónde colocar el archivo .htaccess?

Colócalo en el directorio raíz de tu sitio (generalmente public_html o www). Las reglas se aplican a ese directorio y a todos sus subdirectorios.

¿Funcionará con Nginx?

No. .htaccess es específico de Apache. Nginx usa su propia sintaxis de configuración en nginx.conf o en los archivos de configuración del sitio.

¿.htaccess puede ralentizar mi sitio?

Apache consulta el .htaccess en cada petición, por lo que archivos muy voluminosos pueden añadir sobrecarga. Para sitios con mucho tráfico, mover las reglas a la configuración principal de Apache es más rápido.

Qué es realmente .htaccess

Un archivo .htaccess es el archivo de configuración por directorio de Apache. El nombre se entiende ampliamente como una contracción de «hypertext access» (acceso a hipertexto), lo que refleja el uso principal original del archivo de restringir el acceso a documentos de hipertexto. Coloca uno en cualquier directorio y las directivas se aplican a ese directorio y a todos los subdirectorios que haya debajo. El archivo no tiene nombre antes del punto (es un archivo oculto de Unix, oculto de forma predeterminada) y debe llamarse exactamente .htaccess (en minúsculas, con un punto inicial) para que Apache lo encuentre con la configuración AccessFileName predeterminada.

Hay un coste de rendimiento real. La documentación de Apache es explícita: «si AllowOverride está configurado para permitir el uso de archivos .htaccess, Apache buscará archivos .htaccess en cada directorio. Por lo tanto, permitir los archivos .htaccess provoca una penalización de rendimiento, tanto si realmente los usas como si no». El árbol de directorios se recorre en cada petición HTTP. Para una petición a /var/www/html/foo/bar/baz.html, Apache comprueba con stat /.htaccess, luego /var/.htaccess, luego /var/www/.htaccess, luego /var/www/html/.htaccess, y así sucesivamente, incluso cuando ninguno de esos archivos existe. La propia recomendación de Apache es usar bloques <Directory> de la configuración principal cuando sea posible (analizados una sola vez al inicio) y reservar .htaccess para los entornos de alojamiento donde no tienes acceso a la configuración principal.

Cuándo lo necesitas (y cuándo no)

Apache enumera dos casos de uso legítimos para .htaccess: los proveedores de alojamiento que dan a los usuarios un control limitado sin acceso completo a la configuración del servidor, y los casos en los que las directivas deben diferir entre subdirectorios donde quien hace el despliegue controla solo el sistema de archivos. Fuera de esos, la documentación recomienda explícitamente trasladar las reglas a bloques <Directory> de la configuración principal.

nginx (el segundo servidor web más popular) no admite .htaccess en absoluto; rechaza deliberadamente los archivos de configuración por directorio por razones de rendimiento, y toda la configuración vive en nginx.conf y en cualquier archivo de sitio incluido. Si tu proyecto está en nginx, la salida de este generador no te ayudará: necesitarás bloques server / location en el archivo de configuración de nginx. Caddy usa su propia sintaxis de Caddyfile con HTTPS automático mediante Let's Encrypt de forma predeterminada. LiteSpeed y OpenLiteSpeed admiten .htaccess por compatibilidad con Apache. IIS usa web.config.

La reescritura de URL y el patrón canónico de HTTPS

La mayor parte del trabajo no trivial con .htaccess usa mod_rewrite, el motor de reescritura de URL basado en reglas de Apache, construido sobre las expresiones regulares extendidas de POSIX. La forma básica es RewriteRule pattern substitution [flags], opcionalmente precedida de una o más condiciones RewriteCond. El bloque estándar para forzar HTTPS:

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

Los flags [L,R=301] significan «esta es la última regla de esta ronda» y «responde con HTTP 301 Moved Permanently». Un 301 es la opción correcta para las redirecciones permanentes: los motores de búsqueda transmiten la autoridad de enlace y los navegadores la almacenan en caché de forma agresiva. Usa 302 (Found) solo para redirecciones genuinamente temporales, cuando no quieres que el movimiento se almacene en caché.

Detrás de un balanceador de carga o un proxy inverso que termina el TLS, el servidor de origen ve HTTP plano aunque el navegador del usuario esté en HTTPS; una regla RewriteCond %{HTTPS} off ingenua entonces redirige eternamente. La solución es comprobar la cabecera reenviada en su lugar: RewriteCond %{HTTP:X-Forwarded-Proto} !https. El modo «Flexible SSL» de Cloudflare (la CDN habla HTTP con el origen mientras el usuario usa HTTPS) es la causa más común de esta trampa del bucle de redirección.

Elige entre la canonicalización con www y sin www con un patrón similar. Elige un nombre de host canónico para el SEO (evita los problemas de contenido duplicado) y para el ámbito de las cookies (un subdominio www recibe cookies diferentes a las del dominio raíz de forma predeterminada).

Compresión y almacenamiento en caché

mod_deflate comprime con gzip las respuestas de texto, lo que reduce drásticamente el tamaño de transferencia en texto/HTML/CSS/JS. Envuelve el bloque en <IfModule mod_deflate.c> para que no bloquee el sitio en los servidores donde el módulo no está cargado. Brotli (mod_brotli) es el reemplazo moderno y usa el mismo patrón.

mod_expires establece las cabeceras Expires y Cache-Control: max-age. La sintaxis muy usada «access plus 1 year» significa que el recurso puede almacenarse en caché durante un año desde el momento en que el usuario lo obtuvo. Un max-age largo es correcto para los nombres de archivo de recursos con hash (app.abc123.js); un max-age más corto es correcto para el HTML y cualquier cosa mutable. Para un control más fino, Header set Cache-Control "public, max-age=31536000, immutable" en los archivos con hash es la mejor práctica moderna.

Cabeceras de seguridad que conviene conocer

• X-Frame-Options: SAMEORIGIN: evita que la página se incruste en un <iframe> en otros orígenes. En gran medida, ha sido sustituida por frame-ancestors de CSP.
• Content-Security-Policy: la principal defensa moderna contra XSS y el secuestro de clics. Una de inicio: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'. Ve ajustándola con el tiempo.
• Strict-Transport-Security (HSTS): le dice al navegador que solo hable HTTPS con tu dominio. max-age=31536000; includeSubDomains es la base típica. Añade preload solo cuando estés seguro de que el HTTPS es permanente: una vez precargado en la lista HSTS del navegador, la eliminación es difícil.
• X-Content-Type-Options: nosniff: evita que los navegadores cuestionen la cabecera Content-Type. La cabecera solo tiene un valor.
• Referrer-Policy: strict-origin-when-cross-origin: el valor predeterminado moderno; envía la URL completa a las peticiones del mismo origen, solo el origen a las peticiones de origen cruzado, y nada en una degradación de HTTPS a HTTP.
• Permissions-Policy: controla funciones del navegador como la cámara, el micrófono o la geolocalización. Sustituyó a la antigua cabecera Feature-Policy.
• X-XSS-Protection: en gran medida obsoleta. El filtro se ha eliminado de Chrome y nunca existió en Firefox; la seguridad moderna se basa en CSP. Muchas guías antiguas todavía la incluyen para el IE heredado; es seguro omitirla en los sitios nuevos.

Ocultar lo que no debería servirse

Dos líneas únicas de refuerzo de la seguridad que se amortizan solas:

• Options -Indexes: desactiva los listados de directorio autogenerados cuando no hay index.html. Muchas distribuciones vienen con la indexación de directorios activada de forma predeterminada; un directorio perdido y sin proteger no debería filtrar su contenido a la web.
• Bloquea los archivos con punto y los metadatos de control de versiones. Un bloque <FilesMatch "^(\.htaccess|\.htpasswd|\.env|\.git.*)$"> con Require all denied impide que los atacantes descarguen .env (que a menudo contiene contraseñas de bases de datos y claves de API) o .git/config (que expone las URL remotas y a veces las credenciales). Los informes de amenazas de Akamai y SANS documentan la exposición de .env como una de las filtraciones a nivel de aplicación más comunes de la década de 2020.

Apache 2.4 sustituyó la antigua sintaxis Order Allow,Deny por la más limpia familia de directivas Require: Require all granted, Require all denied, Require ip 192.0.2.0/24, Require not ip 198.51.100.5. La sintaxis antigua todavía funciona por retrocompatibilidad, pero está documentada como obsoleta.

Trampas comunes

• mod_rewrite debe estar habilitado a nivel del servidor. En Debian/Ubuntu: sudo a2enmod rewrite && sudo systemctl restart apache2. Sin él, cada RewriteRule se omite en silencio.
• AllowOverride importa. Si la configuración principal tiene AllowOverride None para tu <Directory>, cada directiva de tu .htaccess se ignora en silencio. AllowOverride All permite todo; AllowOverride FileInfo AuthConfig permite solo la reescritura y la autenticación, lo que es suficiente para la mayoría de los casos de uso.
• Un solo error tipográfico rompe todo el sitio. Apache devuelve un error 500 Internal Server Error para cada petición al árbol de directorios afectado hasta que se corrige el archivo. Prueba siempre primero en el entorno de pruebas; mantén una copia de seguridad llamada .htaccess.bak; ten acceso SSH/FTP listo para poder renombrar un archivo roto de forma remota. Vigila /var/log/apache2/error.log en busca de mensajes de sintaxis.
• Bucles de redirección infinitos. Los navegadores limitan las cadenas de redirección a unos 20 saltos y muestran ERR_TOO_MANY_REDIRECTS. Las causas más comunes: una regla de redirección a HTTPS que se ejecuta en un servidor detrás de un proxy que termina el TLS (usa %{HTTP:X-Forwarded-Proto}); reglas de www y de HTTPS en el orden equivocado que provocan redirecciones dobles; el modo Flexible SSL de Cloudflare.
• El flag [L] vuelve a ejecutar el motor de reescritura desde arriba con la URL reescrita. Si una regla posterior coincide entonces, el comportamiento puede ser sorprendente. Usa [END] (Apache 2.3.9+) cuando de verdad quieras una parada en seco.
• El contexto por directorio elimina la barra inicial. En .htaccess, RewriteRule ^index\.html$ home.html coincide; RewriteRule ^/index\.html$ no. Esto hace tropezar a todo el que copia una regla de un ejemplo de la configuración principal.
• Algunas directivas están prohibidas en .htaccess: <VirtualHost>, <Directory>, <Location>, Listen, ServerName son exclusivas de la configuración principal. El archivo por directorio ya se aplica implícitamente a su propio directorio.

Más preguntas

¿Dónde debería ir exactamente el archivo?

En el directorio cuyo contenido quieres controlar. La mayoría de los usuarios de alojamiento compartido lo ponen en la raíz del documento de su sitio: public_html/, www/ o htdocs/, según el host. Apache recorre entonces el árbol de directorios aplicando las reglas a ese directorio y a todos los subdirectorios que haya debajo.

301 o 302, ¿qué redirección debo usar?

301 Moved Permanently para los movimientos permanentes. Los motores de búsqueda transfieren la autoridad de enlace a la nueva URL; los navegadores almacenan la redirección en caché de forma agresiva. Úsalo para los casos de «hemos movido esta página para siempre». 302 Found para las redirecciones temporales: el navegador no la almacena en caché y los motores de búsqueda no transfieren el posicionamiento. Usa 302 solo cuando el movimiento sea realmente temporal; usar 302 en lugar de 301 por defecto es uno de los autogoles de SEO más comunes.

¿Cómo protejo un directorio con contraseña?

Crea un archivo .htpasswd con la utilidad de línea de comandos htpasswd (almacena líneas username:bcrypt-hash) y guárdalo fuera de la raíz de tu web. Luego, en .htaccess: AuthType Basic, AuthName "Restricted Area", AuthUserFile /full/path/to/.htpasswd, Require valid-user. El navegador muestra una solicitud de autenticación básica del sistema a quien visite el directorio. Este es el patrón clásico de Apache; para una autenticación seria, considera en su lugar un sistema de inicio de sesión a nivel de aplicación.

¿Funcionará en WordPress?

WordPress incluye su propio bloque .htaccess (entre los marcadores # BEGIN WordPress y # END WordPress) que gestiona los enlaces permanentes. WordPress sobrescribirá cualquier cosa dentro de esos marcadores cuando guardes los ajustes de los enlaces permanentes. Añade tus propias reglas fuera de los marcadores de WordPress (normalmente por encima de ellos) para que sobrevivan a la regeneración automática.

¿Se envía algo a un servidor?

No. El generador es JavaScript que ensambla bloques de directivas según tus casillas de verificación; la salida se construye en tu navegador. Nada sobre tu dominio o las opciones que elijas sale de la página; la herramienta funciona sin conexión una vez cargada.

Herramientas relacionadas