Reverse Proxy para servicios de IA: Nginx y Caddy

Qué cubre este artículo sobre reverse proxys

• Cómo colocar un reverse proxy frente a Ollama y otros servicios de IA
• La diferencia entre Nginx y Caddy, y cuándo usar cada herramienta
• Cifrado TLS con Let’s Encrypt, manual y automático
• Autenticación con Basic Auth y API Keys para evitar que cualquiera acceda a tus modelos
• Trampa comunes, consideraciones de hardware y un ejemplo práctico completo

Introducción: entender los reverse proxys

Quien ejecuta servicios de IA locales como Ollama se enfrenta rápidamente a una pregunta: ¿cómo accedo al servicio desde fuera sin abrir completamente las puertas? Ollama escucha por defecto en localhost:11434. Eso es seguro mientras trabajes solo desde el mismo equipo. Pero en cuanto quieras acceder a tus modelos desde el teléfono, desde la laptop en el jardín o desde otra ubicación, necesitas una solución.

Un reverse proxy es exactamente esa solución. Se sitúa entre el cliente y tu servicio de IA, maneja el cifrado TLS, se encarga de la autenticación y reenvía las solicitudes de forma ordenada. A diferencia de un forward proxy, que trabaja para el cliente, el reverse proxy actúa en nombre del servidor. Para el cliente, parece que habla directamente con el proxy.

Este artículo forma parte de la sección Operación segura y específicamente de Seguridad de red. Si primero quieres familiarizarte con la protección básica, consulta el artículo sobre Firewall. Para el contexto de Ollama mismo, los artículos sobre Acceso de red de Ollama y la API de Ollama son útiles.

¿Por qué necesito un reverse proxy?

Imagina que ejecutas Ollama en un pequeño servidor en casa. Quieres acceder a tus modelos desde cualquier lugar a través de un dominio como ki.example.de, por ejemplo para usar una app propia o dar un endpoint a colegas.

Sin un reverse proxy tienes varios problemas simultáneamente:

1. Ollama usa HTTP sin cifrar. Todo lo que envías y recibes viaja sin encriptación por la red.
2. Cualquiera que alcance el puerto puede llamar a la API. No hay autenticación.
3. Debes vincular Ollama a 0.0.0.0 para que sea accesible desde fuera. Eso expande significativamente la superficie de ataque.
4. No tienes un certificado TLS, así que el navegador protesta y las funciones modernas están bloqueadas.

Un reverse proxy resuelve todo eso de un golpe. Termina TLS, verifica autenticación, reenvía solo las solicitudes legítimas y mantiene Ollama vinculado a localhost. Obtienes una interfaz pública limpia mientras el servicio real permanece en el trasfondo.

Reverse proxy explicado brevemente

Un reverse proxy recibe solicitudes de clientes y las reenvía a uno o más servidores backend. Para el cliente, solo el proxy es visible. El servidor backend ve al proxy como remitente, no al cliente.

Las tareas principales de un reverse proxy:

• Terminación TLS: cifrado hacia afuera, tráfico sin cifrar hacia adentro
• Autenticación: verificación de credenciales antes del reenvío
• Enrutamiento: distribución entre múltiples backends según ruta o dominio
• Balanceo de carga: distribución entre múltiples instancias
• Caché y compresión: optimización de rendimiento
• Ajuste de encabezados: por ejemplo CORS o headers de seguridad

Para servicios de IA, los tres primeros puntos son más importantes. TLS y autenticación casi siempre los necesitas, enrutamiento cuando ofreces múltiples modelos o servicios bajo un solo dominio.

A quién está dirigido este artículo

Este artículo es para personas que ejecutan servicios de IA locales o en un servidor propio y quieren hacerlos accesibles de forma segura desde fuera. Deberías tener conocimientos básicos de Linux, idealmente en Ubuntu, y saber cómo moverte por tu servidor vía SSH. Los fundamentos de Docker ayudan, pero no son estrictamente necesarios porque los ejemplos también funcionan sin Docker.

Si ya tienes Ollama en marcha y ahora quieres avanzar al siguiente paso para hacerlo accesible de forma segura, has llegado al lugar correcto.

Términos importantes

Término	Explicación
Reverse Proxy	Servidor que recibe solicitudes y las reenvía a un servidor backend
Nginx	Servidor web performante y ampliamente difundido, funciona como reverse proxy
Caddy	Servidor web moderno con TLS automático vía Let’s Encrypt
TLS	Transport Layer Security, estándar para conexiones cifradas
SSL	Predecesor de TLS, comúnmente aún mencionado coloquialmente
Certificado	Certificado digital que confirma la identidad de un dominio
Basic Auth	Autenticación simple con usuario y contraseña
Proxy Pass	Directiva en Nginx que reenvía solicitudes a un servidor backend
Upstream	Definición de un servidor backend en Nginx, puede abarcar múltiples destinos
Let’s Encrypt	Autoridad certificadora gratuita para certificados TLS

Nginx como reverse proxy para Ollama

Nginx es el clásico entre los reverse proxys. Es performante, bien documentado y disponible en casi cualquier sistema. La configuración se realiza a través de archivos de texto, lo que al inicio requiere algo de acostumbramiento, pero ofrece mucha flexibilidad.

Un ejemplo mínimo que expone Ollama en localhost:11434 hacia afuera en el puerto 80:

server {
    listen 80;
    server_name ki.example.de;

    location / {
        proxy_pass http://localhost:11434;

        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;

        # Importante para respuestas en streaming de Ollama
        proxy_buffering off;
        proxy_read_timeout 300s;
    }
}

La línea proxy_pass es el corazón de la configuración. Le dice a Nginx adónde dirigir las solicitudes. Las líneas proxy_set_header se aseguran de que Ollama sepa de dónde vino originalmente la solicitud. proxy_buffering off es importante para servicios de IA porque Ollama suele entregar respuestas como stream. Con buffering activado, Nginx acumularía toda la respuesta antes de enviarla, lo que destruiría el efecto de streaming.

Caddy como reverse proxy para Ollama

Caddy toma un camino diferente. La configuración es significativamente más corta, y los certificados TLS de Let’s Encrypt se obtienen y renuevan automáticamente. Para configuraciones más pequeñas y para quienes quieren empezar rápido, Caddy es frecuentemente la mejor opción.

El equivalente al ejemplo de Nginx en Caddy se ve así:

ki.example.de {
    reverse_proxy localhost:11434
}

Eso es todo. Caddy escucha en el puerto 443, obtiene automáticamente un certificado para ki.example.de y reenvía a Ollama. El streaming funciona listo para usar, porque Caddy reenvía el streaming HTTP/1.1 al backend correctamente.

Si quieres establecer headers explícitamente, también es posible:

ki.example.de {
    reverse_proxy localhost:11434 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
    }
}

El precio de esta sencillez es que Caddy en configuraciones muy complejas ofrece menos ajustes finos que Nginx. Pero para la mayoría de configuraciones de IA eso no es un problema.

Certificados TLS

TLS es hoy en día estándar, y con razón. Sin TLS, tus llamadas API y credenciales viajan sin encriptar por la red. Con TLS están protegidas contra intrusos.

Let’s Encrypt ofrece certificados gratuitos válidos por 90 días que se renuevan automáticamente. El cliente estándar se llama certbot.

Para Nginx, obtienes un certificado así:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d ki.example.de

Certbot consulta tu dominio, lo verifica mediante una HTTP-Challenge, ajusta la configuración de Nginx automáticamente y configura un timer para la renovación. Después, tu sitio es accesible por HTTPS.

Con Caddy, este paso desaparece completamente. Caddy utiliza Let’s Encrypt automáticamente en cuanto tienes un dominio en la configuración. Solo necesitas asegurar que el puerto 443 sea accesible desde el exterior y que el dominio apunte a tu servidor.

Una alternativa para redes internas sin dominio público es usar tu propia autoridad de certificados, por ejemplo con mkcert. Tiene sentido si el servicio solo es accesible en la LAN y no posees un dominio público.

Añadir autenticación

TLS por sí solo no es suficiente. Quien conozca el endpoint puede seguir llamándolo sin credenciales. Necesitas autenticación.

Basic Auth con Nginx

Basic Auth es la forma más sencilla. Creas un archivo con nombres de usuario y hashes de contraseñas, y lo referencias en la configuración de Nginx.

sudo apt install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd meinuser

En la configuración de Nginx, añades la location:

location / {
    auth_basic "Geschuetzer Bereich";
    auth_basic_user_file /etc/nginx/.htpasswd;

    proxy_pass http://localhost:11434;
    # ... weitere proxy_set_header Zeilen
}

Al acceder, el navegador solicita usuario y contraseña. Para llamadas API, envías las credenciales en el encabezado, por ejemplo Authorization: Basic base64(user:pass).

Basic Auth con Caddy

En Caddy usas la directiva basicauth:

ki.example.de {
    basicauth {
        meinuser $2a$14$...
    }
    reverse_proxy localhost:11434
}

Generas el hash con caddy hash-password. La contraseña en sí no aparece en la configuración, solo el hash.

API Keys

Para acceso programático, las API Keys suelen ser más prácticas que Basic Auth. Estableces un encabezado como X-API-Key y lo verificas en el proxy.

En Nginx con un map:

map $http_x_api_key $api_key_valid {
    default 0;
    "dein-geheimer-key" 1;
}

server {
    # ...

    location / {
        if ($api_key_valid = 0) {
            return 401;
        }
        proxy_pass http://localhost:11434;
    }
}

En Caddy usas verificaciones header o un pequeño plugin. Para escenarios más complejos con múltiples keys o roles, merece la pena una herramienta previa como Authelia o Authentik, que ofrece Single Sign-On y políticas granulares.

Ejemplo: Ollama con Nginx y TLS

Aquí tienes un ejemplo completo y paso a paso. Partimos de un servidor Ubuntu recién instalado donde Ollama ya está en ejecución y escucha en localhost:11434.

Paso 1: Instala Nginx.

sudo apt update
sudo apt install nginx

Paso 2: Crea la configuración en /etc/nginx/sites-available/ollama.

server {
    listen 80;
    server_name ki.example.de;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name ki.example.de;

    ssl_certificate /etc/letsencrypt/live/ki.example.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ki.example.de/privkey.pem;

    auth_basic "Ollama";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://localhost:11434;

        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;

        proxy_buffering off;
        proxy_read_timeout 300s;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Paso 3: Activa el sitio y verifica Nginx.

sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Paso 4: Obtén el certificado.

sudo certbot --nginx -d ki.example.de

Paso 5: Crea un usuario.

sudo htpasswd -c /etc/nginx/.htpasswd meinuser

Paso 6: Verifica el firewall. Los puertos 80 y 443 deben estar abiertos, el puerto 11434 permanece cerrado. Más detalles en el artículo sobre Firewall.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Después, Ollama es accesible en https://ki.example.de, encriptado y con autenticación. El puerto directo 11434 permanece invisible hacia el exterior.

Tropiezos típicos

1. Ollama vinculado a 0.0.0.0. Si configuras Ollama para escuchar en todas las interfaces, eluyes la protección del reverse proxy. Mantén Ollama en localhost y deja que el proxy haga de puente hacia el exterior. Más detalles en Acceso de red Ollama.

2. Streaming roto por buffering. Sin proxy_buffering off en Nginx, el proxy acumula la respuesta completa antes de enviarla. En streams de tokens de modelos de IA, eso es indeseado. Verifica esto si no ves salida progresiva.

3. Timeouts en generaciones largas. Los prompts largos pueden tardar minutos. El timeout predeterminado de Nginx suele ser muy corto. Establece proxy_read_timeout más alto, por ejemplo 300 segundos o más.

4. Renovación de certificados olvidada. Los certificados Let’s Encrypt vencen después de 90 días. Con certbot, un timer se encarga de ello, pero verifica que esté en ejecución. Con Caddy ocurre automáticamente en segundo plano.

5. HTTP/1.0 como protocolo del backend. Nginx habla por defecto con el backend en HTTP/1.0, lo que impide Keep-Alive. Establece proxy_http_version 1.1 y vacía el encabezado Connection, como en el ejemplo anterior.

6. Problemas CORS en frontends web. Si tienes un frontend en otro dominio, necesitas encabezados CORS en el proxy. En Nginx con add_header Access-Control-Allow-Origin *, en Caddy con header Access-Control-Allow-Origin *.

7. Credenciales en texto plano en la configuración. Con Basic Auth, solo el hash está en el archivo, eso es correcto. Pero en API Keys en el map de Nginx, la key está en texto plano. Usa permisos de archivo para limitar el acceso.

8. Firewall abierto para el puerto del backend. Si el puerto 11434 está abierto hacia el exterior, cualquiera puede eludir el proxy. Ciérralo, el proxy se comunica internamente a través de localhost.

Hardware, costos y seguridad

Un reverse proxy consume pocos recursos. Nginx y Caddy funcionan sin problemas en una Raspberry Pi o un pequeño VPS con 512 MB de RAM. La carga de CPU es mínima mientras no tengas terminación TLS con tráfico muy alto.

Los costos son mínimos. Let’s Encrypt es gratuito, Nginx y Caddy son código abierto. Si no tienes tu propio servidor, puedes conseguir un pequeño VPS por pocos euros al mes. Para cargas de trabajo de IA puras en casa, ni siquiera necesitas eso, ya que el proxy puede ejecutarse en el mismo dispositivo que Ollama.

Desde el punto de vista de la seguridad: un reverse proxy no es una solución universal, pero reduce significativamente la superficie de ataque. Ollama permanece vinculado a localhost, hacia el exterior solo es visible el proxy. TLS protege la transmisión, la autenticación protege el acceso. Combinado con un Firewall limpio y actualizaciones regulares, tienes una base sólida.

Medidas adicionales que deberías considerar:

• Rate limiting para dificultar ataques de fuerza bruta contra Basic Auth
• Fail2ban para bloquear inicios de sesión fallidos repetidos
• Keys separadas para diferentes usuarios, así puedes revocarlas individualmente
• Monitoreo de access logs para detectar accesos inusuales

Enlaces útiles

• Operación segura en general
• Seguridad de red como categoría transversal
• Firewall para proteger los puertos
• Acceso a la red en Ollama para la configuración básica
• API de Ollama para los detalles de la API
• Fundamentos de Docker si ejecutas Ollama en Docker
• Ubuntu como sistema base

Recursos externos:

• Documentación de Nginx: nginx.org/en/docs/
• Documentación de Caddy: caddyserver.com/docs/
• Let’s Encrypt: letsencrypt.org
• Certbot: certbot.eff.org

FAQ

¿Necesito un proxy inverso si solo uso Ollama localmente? No. Si accedes a Ollama exclusivamente desde el mismo equipo, no necesitas un proxy inverso. Ollama escucha en localhost y no es visible hacia el exterior. Un proxy solo es relevante cuando quieres acceder desde otros dispositivos o desde fuera de tu red.

¿Nginx o Caddy, cuál elijo? Para configuraciones rápidas y principiantes, Caddy es la mejor opción porque su configuración es sencilla y TLS funciona automáticamente. Para setups complejos con múltiples dominios, balanceo de carga y ajustes finos, Nginx ofrece más flexibilidad. Ambos son adecuados para Ollama.

¿Puedo ejecutar múltiples servicios de IA detrás de un proxy? Sí. Puedes usar varias dominios, por ejemplo ollama.example.de y stable-diffusion.example.de, o rutas dentro de un mismo dominio, como example.de/ollama y example.de/sd. Esta última opción requiere reescritura de rutas, que ambos proxys soportan.

¿Cuánto cuesta Let’s Encrypt? Nada. Let’s Encrypt es gratuito, los certificados son válidos por 90 días y se renuevan automáticamente. Solo necesitas un dominio que apunte a tu servidor.

¿Es Basic Auth lo suficientemente seguro? Basic Auth sobre TLS es aceptable para setups pequeños y pocos usuarios. Para mayor seguridad y múltiples usuarios, vale la pena cambiar a API Keys o una herramienta SSO como Authelia o Authentik. Lo importante es que Basic Auth siempre use TLS, de lo contrario las credenciales se transmiten en texto plano.

¿Cómo compruebo que mi proxy inverso funciona? Abre el dominio en el navegador y verifica que ves la autenticación. Luego prueba una llamada a la API, por ejemplo curl -u user:pass https://ki.example.de/api/tags. Si recibes una respuesta JSON de Ollama, el proxy funciona.

¿Qué pasa si mi proveedor bloquea el puerto 443? Algunos proveedores bloquean los puertos entrantes para conexiones privadas. En ese caso puedes usar un puerto alternativo como 8443, pero entonces debes incluir el puerto en la URL, así: https://ki.example.de:8443. Otra opción es usar un servicio de túnel como Cloudflare Tunnel, que enruta el tráfico a través de un túnel de salida y no requiere puertos entrantes.

¿Puedo ejecutar Ollama en Docker con un proxy inverso? Sí, es incluso una práctica común. Defines Ollama y el proxy en la misma red de Docker y reenvías en el proxy al nombre del contenedor, por ejemplo proxy_pass http://ollama:11434. Encontrarás los fundamentos en el artículo Fundamentos de Docker.

¿Debo reiniciar Ollama cuando configuro el proxy? No. Ollama continúa ejecutándose sin cambios. Solo reinicia el proxy, por ejemplo con sudo systemctl reload nginx, después de ajustar la configuración.

¿Cómo renuevo los certificados manualmente? Con sudo certbot renew verificas todos los certificados y renuevas los que están próximos a vencer. Con sudo certbot renew --dry-run pruebas el proceso sin realizar cambios. En Caddy esto no es necesario, la renovación ocurre automáticamente.

Referencias

• Documentación del módulo HTTP Proxy de Nginx, nginx.org/en/docs/http/ngx_http_proxy_module.html
• Directiva reverse_proxy de Caddy, caddyserver.com/docs/caddyfile/directives/reverse_proxy
• Documentación de Let’s Encrypt, letsencrypt.org/docs/
• Documentación de Certbot, certbot.eff.org/docs/
• Documentación de Ollama, github.com/ollama/ollama/blob/main/docs/api.md