Configurar un servidor web Apache consiste en preparar el servicio para que pueda recibir peticiones HTTP o HTTPS, localizar el sitio correcto, entregar los archivos adecuados y aplicar reglas básicas de seguridad, rendimiento y mantenimiento. Apache HTTP Server sigue siendo una de las opciones más usadas para publicar páginas web, aplicaciones PHP, paneles internos, APIs y sitios corporativos porque es estable, flexible y tiene una enorme cantidad de módulos.
En esta guía veremos una configuración práctica desde cero: instalación, estructura de archivos, hosts virtuales, módulos importantes, permisos, HTTPS, logs, reglas de seguridad y comprobaciones finales. El objetivo no es memorizar cada directiva de Apache, sino entender qué se configura, dónde se configura y cómo diagnosticar problemas comunes.
👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis
👉 También te dejo por aquí una guía de comandos Linux por categorías
Qué es Apache y cómo funciona
Apache es un servidor web. Su función principal es escuchar conexiones en uno o varios puertos, normalmente el puerto 80 para HTTP y el 443 para HTTPS, interpretar la petición del navegador y devolver una respuesta. Esa respuesta puede ser un archivo HTML, una imagen, una hoja CSS, una descarga, una redirección o el resultado generado por una aplicación.
Apache se organiza mediante archivos de configuración. En distribuciones basadas en Debian o Ubuntu, la configuración suele estar en /etc/apache2/. En sistemas Red Hat, Rocky Linux, AlmaLinux o CentOS, suele encontrarse en /etc/httpd/. Aunque cambie la ruta, la lógica es muy parecida: hay una configuración global, módulos que se activan o desactivan, sitios definidos como hosts virtuales y archivos de log para revisar lo que ocurre.
Un concepto clave es el de host virtual. Un mismo servidor puede alojar varios dominios, por ejemplo example.com, tienda.example.com y blog.example.net. Apache decide qué configuración usar leyendo el dominio de la petición y comparándolo con las directivas ServerName y ServerAlias.
Instalación de servidor web Apache
En Debian o Ubuntu, Apache se instala desde los repositorios oficiales:
sudo apt update
sudo apt install apache2Después de instalarlo, se puede comprobar el estado del servicio:
sudo systemctl status apache2En Rocky Linux, AlmaLinux, CentOS o Fedora, el paquete suele llamarse httpd:
sudo dnf install httpd
sudo systemctl enable --now httpd
sudo systemctl status httpdSi el servicio está activo, el navegador debería mostrar la página por defecto al visitar la IP del servidor. Si no carga, conviene revisar tres puntos: que Apache esté iniciado, que el firewall permita tráfico web y que el servidor sea accesible desde la red.
Puertos y firewall
Apache normalmente escucha en los puertos 80 y 443. El puerto 80 se usa para HTTP sin cifrado. El puerto 443 se usa para HTTPS con certificado TLS. En servidores públicos, lo habitual es permitir ambos, redirigiendo después todo el tráfico HTTP hacia HTTPS.
En Ubuntu con UFW:
sudo ufw allow 'Apache Full'
sudo ufw statusTambién se pueden abrir los puertos directamente:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcpEn sistemas con firewalld:
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reloadUna configuración correcta de Apache no servirá de mucho si el firewall bloquea las conexiones. Por eso, cuando una página no carga desde fuera pero sí responde localmente, el firewall y las reglas del proveedor de hosting son los primeros lugares que conviene revisar.
Estructura de configuración en Debian y Ubuntu
En Debian y Ubuntu, Apache tiene una estructura muy cómoda:
/etc/apache2/
├── apache2.conf
├── ports.conf
├── mods-available/
├── mods-enabled/
├── sites-available/
├── sites-enabled/
├── conf-available/
└── conf-enabled/apache2.conf contiene la configuración principal. ports.conf define los puertos en los que Apache escucha. mods-available contiene módulos disponibles y mods-enabled contiene enlaces a los módulos activos. Lo mismo ocurre con los sitios: sites-available guarda configuraciones disponibles y sites-enabled contiene las configuraciones activas.
Esta separación evita editar todo en un único archivo enorme. Lo recomendable es crear un archivo de configuración por sitio dentro de sites-available y activarlo con a2ensite.
Crear el directorio del sitio
Antes de crear el host virtual, conviene preparar el directorio donde vivirán los archivos del sitio. Una ruta común es /var/www/nombre-del-sitio.
sudo mkdir -p /var/www/configuracion-apache/public_htmlDespués, se asigna la propiedad al usuario que administrará los archivos:
sudo chown -R $USER:www-data /var/www/configuracion-apacheY se aplican permisos razonables:
sudo find /var/www/configuracion-apache -type d -exec chmod 755 {} \;
sudo find /var/www/configuracion-apache -type f -exec chmod 644 {} \;Estos permisos permiten que Apache lea el contenido sin dejar archivos ejecutables o modificables innecesariamente. En sitios con aplicaciones que necesitan escribir en ciertas carpetas, como WordPress en wp-content/uploads, los permisos deben ajustarse con más cuidado solo en esas rutas concretas.
Crear una página de prueba
Para comprobar que el host virtual funciona, se puede crear un index.html sencillo:
nano /var/www/configuracion-apache/public_html/index.htmlContenido de ejemplo:
<!doctype html>
<html lang="es">
<head>
<meta charset="utf-8">
<title>Configuración Apache</title>
</head>
<body>
<h1>Apache funciona correctamente</h1>
<p>Este sitio se sirve desde un host virtual propio.</p>
</body>
</html>Esta prueba permite separar dos tipos de problemas: si Apache sirve este archivo, el servidor web funciona; si después falla una aplicación concreta, el problema probablemente está en la aplicación, en PHP, en la base de datos o en sus permisos.
Configurar un host virtual
Un host virtual indica a Apache qué dominio atender, qué carpeta usar como raíz del sitio y qué reglas aplicar. En Debian o Ubuntu, se puede crear un archivo como este:
sudo nano /etc/apache2/sites-available/configuracion-apache.confEjemplo básico:
<VirtualHost *:80>
ServerName ejemplo.com
ServerAlias www.ejemplo.com
ServerAdmin [email protected]
DocumentRoot /var/www/configuracion-apache/public_html
<Directory /var/www/configuracion-apache/public_html>
Options -Indexes +FollowSymLinks
AllowOverride All
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/configuracion-apache-error.log
CustomLog ${APACHE_LOG_DIR}/configuracion-apache-access.log combined
</VirtualHost>La directiva ServerName define el dominio principal. ServerAlias permite añadir variantes, como el subdominio www. DocumentRoot indica la carpeta pública del sitio. El bloque Directory define permisos y comportamiento para esa carpeta.
La línea Options -Indexes es especialmente importante. Desactiva el listado automático de directorios, evitando que Apache muestre el contenido de una carpeta cuando no existe un archivo índice. AllowOverride All permite que archivos .htaccess modifiquen ciertas reglas, algo habitual en WordPress y otros CMS. Si no se necesita .htaccess, es mejor usar una configuración más restrictiva para mejorar rendimiento y control.
Para activar el sitio:
sudo a2ensite configuracion-apache.conf
sudo apache2ctl configtest
sudo systemctl reload apache2apache2ctl configtest comprueba la sintaxis antes de recargar. Es una práctica esencial, porque evita reiniciar el servicio con una configuración rota.
Desactivar el sitio por defecto
En instalaciones nuevas, el servidor web Apache suele traer un sitio por defecto activo. Si se va a servir un dominio propio, conviene desactivarlo:
sudo a2dissite 000-default.conf
sudo apache2ctl configtest
sudo systemctl reload apache2No siempre es obligatorio, pero reduce confusiones. Si una petición llega sin coincidir con ningún dominio configurado, Apache usa el primer host virtual cargado. Mantener activo el sitio por defecto puede hacer que aparezca una página inesperada al visitar una IP o un dominio mal apuntado.
Configuración en Red Hat / Rocky Linux
En sistemas tipo Red Hat, el archivo principal suele estar en /etc/httpd/conf/httpd.conf, y las configuraciones adicionales se guardan en /etc/httpd/conf.d/.
Un host virtual puede crearse así:
sudo nano /etc/httpd/conf.d/configuracion-apache.confEjemplo:
<VirtualHost *:80>
ServerName ejemplo.com
ServerAlias www.ejemplo.com
DocumentRoot /var/www/configuracion-apache/public_html
<Directory /var/www/configuracion-apache/public_html>
Options -Indexes +FollowSymLinks
AllowOverride All
Require all granted
</Directory>
ErrorLog /var/log/httpd/configuracion-apache-error.log
CustomLog /var/log/httpd/configuracion-apache-access.log combined
</VirtualHost>Después:
sudo apachectl configtest
sudo systemctl reload httpdLa idea es la misma, aunque cambien los comandos de activación. En Red Hat no se usan a2ensite o a2enmod por defecto; normalmente se coloca el archivo .conf en conf.d y Apache lo carga automáticamente.
Activar módulos importantes
Apache puede ampliar sus funciones mediante módulos. Algunos de los más comunes son:
rewrite: permite reescrituras de URL y enlaces permanentes amigables.
ssl: habilita HTTPS.
headers: permite añadir o modificar cabeceras HTTP.
expires: controla caché mediante cabeceras de expiración.
proxy y proxy_http: permiten usar Apache como proxy inverso hacia una aplicación interna.
En Ubuntu o Debian, se activan con a2enmod:
sudo a2enmod rewrite
sudo a2enmod ssl
sudo a2enmod headers
sudo a2enmod expires
sudo systemctl reload apache2En sistemas Red Hat, muchos módulos ya están disponibles si el paquete correspondiente está instalado. La configuración puede variar según la versión, por lo que conviene revisar /etc/httpd/conf.modules.d/.
Redirección de HTTP a HTTPS
Aunque Certbot puede crear la redirección, es útil entender cómo funciona. Un host virtual en el puerto 80 puede redirigir todo el tráfico a HTTPS:
<VirtualHost *:80>
ServerName ejemplo.com
ServerAlias www.ejemplo.com
Redirect permanent / https://ejemplo.com/
</VirtualHost>El host virtual HTTPS sería el encargado de servir el sitio real:
<VirtualHost *:443>
ServerName ejemplo.com
ServerAlias www.ejemplo.com
DocumentRoot /var/www/configuracion-apache/public_html
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/ejemplo.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ejemplo.com/privkey.pem
<Directory /var/www/configuracion-apache/public_html>
Options -Indexes +FollowSymLinks
AllowOverride All
Require all granted
</Directory>
</VirtualHost>En la práctica, si se usa Certbot, este archivo puede quedar dividido o modificado automáticamente. Aun así, revisar la configuración ayuda a detectar duplicidades o redirecciones en bucle.
Configurar Apache para WordPress
WordPress funciona muy bien con Apache, especialmente cuando se usa mod_rewrite para enlaces permanentes. Una configuración típica necesita permitir .htaccess en la carpeta pública:
<Directory /var/www/wordpress/public_html>
Options -Indexes +FollowSymLinks
AllowOverride All
Require all granted
</Directory>Después se activa el módulo de reescritura:
sudo a2enmod rewrite
sudo systemctl reload apache2Dentro de WordPress, al guardar los enlaces permanentes, el CMS genera reglas en .htaccess. Si las páginas internas devuelven error 404 pero la portada funciona, suele ser señal de que mod_rewrite no está activo o AllowOverride no permite leer las reglas.
Para un entorno más controlado, las reglas de WordPress pueden trasladarse del .htaccess al host virtual, pero eso exige administrar los cambios manualmente. En sitios compartidos o administrados por usuarios no técnicos, .htaccess sigue siendo una solución práctica.
Logs de Apache
Los logs son la herramienta principal para diagnosticar problemas. Apache registra accesos y errores. En Debian o Ubuntu suelen estar en /var/log/apache2/; en Red Hat, en /var/log/httpd/.
Para ver errores recientes:
sudo tail -f /var/log/apache2/error.logSi el host virtual tiene logs propios:
sudo tail -f /var/log/apache2/configuracion-apache-error.logEl log de errores puede mostrar problemas de permisos, módulos no cargados, errores de sintaxis, certificados incorrectos o fallos al acceder a archivos. El log de accesos muestra qué URLs se están solicitando, desde qué IPs y con qué códigos de respuesta.
Los códigos más frecuentes son:
200: respuesta correcta.
301 o 302: redirección.
403: acceso prohibido.
404: recurso no encontrado.
500: error interno del servidor.
502 o 503: habituales cuando Apache actúa como proxy y la aplicación de destino no responde.
Permisos y propietario de archivos
Muchos errores de Apache se deben a permisos. El servidor necesita leer los archivos públicos, pero no debería tener permisos excesivos. Una base razonable para archivos estáticos es:
sudo find /var/www/sitio -type d -exec chmod 755 {} \;
sudo find /var/www/sitio -type f -exec chmod 644 {} \;El propietario depende del flujo de trabajo. En un servidor administrado por una persona, puede ser cómodo que el usuario despliegue archivos y que el grupo pertenezca al usuario web. En un servidor con despliegue automatizado, puede haber un usuario específico para la aplicación.
Lo importante es evitar soluciones como chmod 777. Aunque pueden hacer que un error desaparezca, abren la puerta a modificaciones no deseadas y problemas de seguridad. Si Apache no puede leer un archivo, lo correcto es identificar qué usuario ejecuta el proceso y ajustar propietario, grupo o permisos de forma precisa.
Seguridad básica en Apache
Una instalación por defecto puede funcionar, pero no siempre está endurecida. Algunas medidas básicas ayudan mucho.
Primero, desactivar el listado de directorios:
Options -IndexesSegundo, reducir la información expuesta por el servidor. En Debian o Ubuntu, se puede ajustar en /etc/apache2/conf-available/security.conf:
ServerTokens Prod
ServerSignature OffTercero, añadir cabeceras de seguridad con mod_headers:
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"También puede añadirse una política HSTS cuando el sitio ya funciona correctamente solo con HTTPS:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"HSTS debe activarse con cuidado. Si se configura mal en un dominio o subdominios que no tienen HTTPS preparado, los navegadores pueden bloquear el acceso.
Rendimiento y compresión
Apache puede comprimir respuestas para reducir transferencia y mejorar tiempos de carga. En Debian o Ubuntu:
sudo a2enmod deflate
sudo systemctl reload apache2Una configuración básica puede incluir:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
AddOutputFilterByType DEFLATE application/javascript application/json
</IfModule>También se pueden definir reglas de caché con mod_expires:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/webp "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>La caché mejora el rendimiento, pero hay que aplicarla con criterio. En archivos que cambian a menudo, una caché larga puede hacer que los usuarios vean versiones antiguas. Por eso muchas aplicaciones añaden versiones a los nombres de archivos CSS y JavaScript.
Apache como proxy inverso
Apache también puede colocarse delante de aplicaciones que corren en otro puerto, como Node.js, Python, Java o contenedores. En ese caso, Apache recibe la petición pública y la reenvía a una aplicación interna.
Primero se activan los módulos necesarios:
sudo a2enmod proxy proxy_http headers
sudo systemctl reload apache2Ejemplo de host virtual:
<VirtualHost *:80>
ServerName app.ejemplo.com
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/
ErrorLog ${APACHE_LOG_DIR}/app-error.log
CustomLog ${APACHE_LOG_DIR}/app-access.log combined
</VirtualHost>Este patrón es útil cuando la aplicación no debe exponerse directamente a internet. Apache gestiona el dominio, HTTPS, logs y algunas cabeceras, mientras la aplicación escucha solo en localhost.
Conclusión
La configuración de un servidor web Apache se entiende mejor como una suma de piezas: servicio activo, puertos abiertos, dominio apuntando al servidor, host virtual correcto, permisos adecuados, módulos necesarios y logs bien ubicados. Cuando cada pieza está clara, Apache deja de ser una caja negra y se convierte en una herramienta predecible.
La mejor práctica para la configuracion de un servidor web Apache, es avanzar por pasos: instalar, probar la página por defecto, crear el directorio del sitio, activar el host virtual, comprobar logs, añadir HTTPS y endurecer la configuración. Así, si algo falla, sabrás exactamente en qué punto buscar.
