Curso de Linux / Publicar un sitio con Nginx, HTTP y HTTPS

Linux

Para publicar un sitio con Nginx, prepare su directorio de archivos, el puerto de escucha, el cortafuegos, el sistema de nombres de dominio (DNS) y el certificado de seguridad de la capa de transporte (TLS). Compruebe primero el acceso local mediante el protocolo de transferencia de hipertexto (HTTP), después el acceso remoto y, finalmente, HTTPS, que protege HTTP con TLS.

Al diagnosticar fallos de conexión, consulte la revisión por capas de red, y antes de hacer público el servicio, aplique la protección del cortafuegos y de las cuentas. Según el repositorio de paquetes, las versiones de Nginx y de las herramientas de certificado pueden variar, por lo que configure según la versión instalada y la guía de la distribución correspondiente.

Los ejemplos se orientan a máquinas virtuales con instalaciones habituales de Ubuntu 26.04 LTS y Rocky Linux 9. Contenedores, WSL y otras versiones pueden requerir cambios. Prepare el acceso de recuperación y compruebe la versión como se explica en crear un entorno de práctica con una máquina virtual.

Servidores, dominios y condiciones de acceso necesarios

Se requiere un servidor Ubuntu o Rocky Linux para práctica, una cuenta sudo y medios de recuperación de consola. linux-course.test es un nombre para pruebas locales y no un nombre para registrar en DNS público. En la etapa de publicación, cambie a un dominio real que administre y, en un entorno NAT, verifique la redirección de puertos, la dirección externa del enrutador y las limitaciones del proveedor de servicios. Compruebe primero si los puertos 80 y 443 ya están en uso por otros servicios.

sudo ss -lntp
cat /etc/os-release

Instalar Nginx según la distribución

Use el primer bloque en Ubuntu y el segundo en Rocky Linux; revise los paquetes propuestos antes de aceptar. Prepare previamente una máquina virtual aislada o restricciones de red: instalar y activar Nginx puede hacer accesible una página predeterminada en el puerto 80. Conserve los sitios existentes y añada el bloque de servidor de esta práctica por separado.

sudo apt update
sudo apt install nginx curl
sudo systemctl enable --now nginx

sudo dnf install nginx curl
sudo systemctl enable --now nginx

Crear un directorio raíz de documento separado y una configuración completa

Compruebe que no haya material previo en /var/www/linux-course ni en /etc/nginx/conf.d/linux-course.conf. Si existe, conserve una copia y elija rutas y nombres nuevos. El ejemplo presupone que nginx.conf incluye los archivos conf.d/*.conf dentro del contexto HTTP. Ejecute cada orden por separado y deténgase si falla: las redirecciones pueden sobrescribir archivos. La página de prueba usa texto en inglés, que se conserva en la respuesta esperada.

sudo install -d -m 755 /var/www/linux-course
printf '<!doctype html><html lang="en"><meta charset="utf-8"><title>Linux course</title><h1>Linux course server works</h1></html>\n' | sudo tee /var/www/linux-course/index.html
sudo chmod 644 /var/www/linux-course/index.html
sudo tee /etc/nginx/conf.d/linux-course.conf > /dev/null <<'EOF'
server {
    listen 80;
    server_name linux-course.test;
    root /var/www/linux-course;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo nginx -t

Ejecute la recarga únicamente si la comprobación de configuración de Nginx con nginx -t termina correctamente. Si falla, corrija el archivo y la línea indicados y vuelva a comprobar; mantenga el servicio actual mientras resuelve el error.

sudo systemctl reload nginx
curl -i --resolve linux-course.test:80:127.0.0.1 http://linux-course.test/

Compruebe HTTP 200 y Linux course server works. --resolve define la dirección del dominio para esa solicitud, conservando el nombre HTTP; no cambia el DNS del sistema. Si el cliente usa un proxy, excluya el dominio de prueba mediante su configuración de proxy o --noproxy linux-course.test. Si aparece otra página, revise el nombre solicitado, server_name y la configuración cargada.

Distinguir entre permisos de archivos, SELinux y exposición en la red

Si SELinux está activo en Rocky Linux, revise la etiqueta con ls -Zd /var/www/linux-course. Para ese directorio bajo la política habitual de /var/www, puede restaurar etiquetas con sudo restorecon -Rv /var/www/linux-course. Otras rutas pueden requerir una regla persistente. Un error 403 no justifica desactivar SELinux ni conceder permisos 777.

Después de verificar la respuesta local, permita HTTP 80/tcp y posteriormente HTTPS 443/tcp en el rango necesario. En Ubuntu UFW se agregan reglas como sudo ufw allow 80/tcp, mientras que firewalld prueba los servicios http·https en la zona real en runtime y luego guarda solo esas reglas en permanente. También verifique el firewall en la nube y mantenga permitido SSH.

Desde otro equipo, pruebe curl -H "Host: linux-course.test" http://DIRECCION_DEL_SERVIDOR/, sustituyendo el marcador por la dirección real. Si solo falla el acceso remoto, revise escucha, cortafuegos, rutas y traducción de direcciones de red (NAT). Una respuesta 403, 404 o 502 indica que algún servidor HTTP respondió: investigue permisos, ruta o aplicación.

Aplicar el dominio real y HTTPS

Conecte los registros A·AAAA del dominio real a la dirección pública deseada. Si el servidor no proporciona IPv6, no registre un AAAA incorrecto.
Cambie server_name al dominio real y ejecute nginx -t seguido de reload. Verifique la respuesta HTTP al dominio desde otra red.
En la guía oficial de instalación de Certbot, seleccione el método de instalación adecuado para su sistema operativo y Nginx. En Ubuntu, puede usar la instalación por paquete con apt install certbot python3-certbot-nginx y en otras distribuciones primero verifique la configuración del repositorio.
Después de verificar el acceso a 80·443 y el dominio propietario, ejecute sudo certbot --nginx -d dominio_real para emitir y configurar el certificado.
Verifique el nombre, la cadena, la expiración del certificado HTTPS y la redirección, y haga una prueba de renovación con sudo certbot renew --dry-run.

En entornos donde el método de verificación HTTP está bloqueado, debe elegir otro método compatible como la verificación DNS. No suponga que ha completado la publicación HTTPS solo porque haya completado la práctica local sin requisitos de DNS público o certificado. En la etapa de prueba HTTP, no envíe información sensible como contraseñas o tokens.

Confirmación de fallos y restauración de la configuración de práctica

systemctl status nginx --no-pager
journalctl -b -u nginx -n 50 --no-pager
sudo nginx -t

Al verificar problemas, consulte también la ruta del error_log y la hora de la solicitud. Para eliminar la práctica, haga una copia de seguridad y elimine solo los archivos conf creados y, si nginx -t pasa, haga reload. Verifique documentos raíz, certificados, DNS y firewall según su uso real y solo limpie los elementos creados esta vez. No elimine en bloque sitios existentes, certificados compartidos ni reglas SSH.

Documentación oficial

Linux