Configurar Icecast con HTTPS, Nginx y Wildcard

Cuando montamos la infraestructura de La MIX Radio,
nos dimos cuenta de que dejar Icecast expuesto en el puerto 8000 no era una opción viable.
Queríamos que los oyentes accedieran a través de un puerto estándar y, sobre todo, que la conexión fuera segura.
Intentar configurar Icecast con HTTPS directamente en el software es un camino lleno de complicaciones técnicas y archivos de configuración engorrosos.
Por eso, decidimos delegar toda la gestión del cifrado a un proxy inverso.

El problema de los puertos y la seguridad en streaming

Si dejamos que Icecast gestione el tráfico, el usuario tiene que escribir el puerto al final de la URL.
Esto no solo es antiestético, sino que muchos firewalls corporativos o redes públicas bloquean puertos no estándar.
Además, sin un certificado SSL, los navegadores modernos marcan la página como «No segura», lo que ahuyenta a cualquier oyente nuevo que llegue a la web.

El síntoma más común es el error de «contenido mixto».
Esto ocurre cuando tenemos la web principal en HTTPS pero el flujo de audio viaja por HTTP.
El navegador bloquea la reproducción del streaming por seguridad. Para resolver esto, necesitamos que todo el tráfico pase por un túnel cifrado antes de llegar al servidor de audio.
Una vez entendido esto, el siguiente paso es preparar el entorno donde correrá todo.

Requisitos previos para el entorno de radio

En nuestro homelab, operamos todo sobre Proxmox para mantener la flexibilidad.
Para replicar este montaje, necesitamos los siguientes elementos instalados y operativos:

• Una máquina virtual con Debian o Ubuntu (en nuestro caso, la VM 111).
• Icecast2 instalado y configurado en el puerto local 8000.
• Nginx instalado como servidor web y proxy inverso.
• Un certificado SSL Wildcard (generado con Let’s Encrypt o una CA comercial) que cubra el dominio principal y todos los subdominios.
• Acceso root o privilegios de sudo en la máquina.

Cómo configuramos el proxy inverso paso a paso

La idea es que Nginx reciba la petición en el puerto 443, gestione el certificado SSL y luego pase la petición internamente a Icecast.
De esta forma, Icecast no sabe nada de HTTPS, solo recibe tráfico HTTP local, que es mucho más rápido y sencillo de gestionar.

Primero, debemos crear un archivo de configuración específico para la radio en el directorio de sitios disponibles de Nginx. Usamos un nombre claro para no confundirlo con la web principal.

# Creamos el archivo de configuración para la radio

sudo nano /etc/nginx/sites-available/radio.conf

Ahora escribimos el bloque del servidor. Es fundamental configurar correctamente las cabeceras para que Icecast reciba la IP real del oyente y no la IP interna del servidor Nginx.
Además, desactivamos el buffering para evitar retrasos en el streaming de audio.

server {

listen 80;

server_name radio.lamixradio.com;
# Redireccionamos todo el tráfico HTTP a HTTPS

return 301 https://$host$request_uri;
}

server {

listen 443 ssl;

server_name radio.lamixradio.com;

# Rutas a los certificados Wildcard

ssl_certificate /etc/letsencrypt/live/lamixradio.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/lamixradio.com/privkey.pem;

# Optimizaciones de SSL
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;

location / {
# Pasamos el tráfico al puerto interno de Icecast

proxy_pass http://127.0.0.1:8000;

# Cabeceras críticas para que Icecast funcione correctamente

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

# Desactivamos el buffering para streaming en tiempo real

proxy_buffering off;

proxy_read_timeout 3600;

proxy_connect_timeout 90;
}
}

Una vez guardado el archivo, debemos activar el sitio creando un enlace simbólico hacia la carpeta de sitios habilitados. Esto es una práctica estándar en Debian que nos permite apagar o encender sitios rápidamente.

# Habilitamos la configuración del proxy

sudo 
ln -s /etc/nginx/sites-available/radio.conf /etc/nginx/sites-enabled/

# Verificamos que no haya errores de sintaxis antes de reiniciar

sudo 
nginx -t

# Reiniciamos el servicio para aplicar los cambios

sudo 
systemctl restart 
nginx

Con esto, ya tenemos el puente tendido. Sin embargo, para que la configuración sea completa, debemos ajustar el archivo de Icecast para que acepte las conexiones que vienen desde el proxy local.

# Editamos la configuración de Icecast

sudo nano /etc/icecast2/icecast.xml

# Buscamos la sección de bind y nos aseguramos que escuche en localhost
# o en la IP interna de la VM 111
127.0.0.1

Recuerda que al configurar Icecast con HTTPS mediante Nginx, la seguridad recae en el proxy.
Mantén Nginx actualizado y usa certificados Wildcard para simplificar la gestión de múltiples subdominios en tu homelab.

Errores que nos costaron tiempo

No todo fue fluido en el montaje de La MIX Radio.
Hubo tres fallos concretos que nos mantuvieron despiertos hasta la madrugada y que queremos que evites.

El primero fue el «502 Bad Gateway».
Al principio, Icecast estaba configurado para escuchar solo en la IP pública. Cuando Nginx intentaba conectar a 127.0.0.1:8000, Icecast rechazaba la conexión.
La solución fue cambiar el bind-address a 127.0.0.1 en el archivo XML.

El segundo problema fue el corte intermitente del audio.
Descubrimos que Nginx, por defecto, intenta almacenar en búfer las respuestas del servidor. En un streaming de audio, esto causa saltos y desincronización.
Lo resolvimos añadiendo la directiva proxy_buffering off en el bloque de localización.

El tercero fue un problema de permisos con los certificados Wildcard. Nginx no podía leer la carpeta de Let’s Encrypt debido a los permisos restrictivos de la carpeta /live/.
Tuvimos que ajustar los permisos de los directorios superiores para que el usuario www-data pudiera acceder a las claves.

Cómo saber que funciona

La verificación es sencilla pero debe ser exhaustiva.
Primero, abrimos el navegador y escribimos la URL de la radio.
Debemos ver el candado verde de HTTPS y que la URL no muestre el puerto 8000.
Si entramos en la consola de desarrollador (F12) y vamos a la pestaña «Network», el flujo de datos debe aparecer como «https» y no «http».

Otra prueba fundamental es intentar acceder por el puerto 8000 directamente. Si configuramos el firewall correctamente en Proxmox, el acceso directo al puerto 8000 debería estar bloqueado, obligando a todo el tráfico a pasar por el proxy seguro de Nginx.

Qué sigue después de asegurar el streaming

Una vez que el audio viaja seguro, el siguiente paso lógico es automatizar la gestión de esos certificados.
No queremos estar renovando manualmente cada 90 días.
En nuestra infraestructura, integramos certbot con un hook de reinicio automático de Nginx.
Esto nos permite olvidarnos de la seguridad del transporte y centrarnos en lo que importa: la música y la programación de la radio.