Nginx reverse proxy con FastAPI: publicar una API con HTTPS

Publicado el 2026-10-26 por frfrand

Configurar Nginx y Uvicorn en un VPS con TLS y upstream local

Nginx reverse proxy con FastAPI: publicar una API con HTTPS

Tu API FastAPI responde en localhost:8000, pero querés que un cliente la abra en https://api.ejemplo.com. Nginx puede recibir HTTPS y reenviar al puerto interno sin dejar expuesto Uvicorn directamente a Internet.

Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.

Qué significa Nginx reverse proxy para FastAPI y cuándo lo necesitás

El reverse proxy es una capa pública que gestiona conexiones y puede dirigir peticiones a varios servicios según dominio. FastAPI sigue ejecutándose como proceso privado, normalmente supervisado por systemd o dentro de un contenedor. HTTPS termina en Nginx y la aplicación recibe la solicitud interna.

Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.

Configuración o comandos de ejemplo

# /etc/nginx/sites-available/api.ejemplo.com
server {
    listen 80;
    server_name api.ejemplo.com;
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
# Validar sintaxis ANTES de recargar
sudo nginx -t
sudo systemctl reload nginx

Los dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.

Cómo lo haría paso a paso

Preparación. Comprueba que FastAPI funciona localmente con curl http://127.0.0.1:8000/health.
Paso 2. Crea un server block con server_name correspondiente al DNS del dominio.
Paso 3. Configura el proxy al puerto interno y los headers adecuados.
Paso 4. Activa HTTPS con un certificado válido; el bloque HTTP es solo el punto de partida.
Verificación. Verifica nginx -t, recarga y prueba por el dominio desde otra red.

Cuando termines, comprueba la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecuta una petición de lectura, una escritura en una base de prueba y consulta los logs del proceso.

Ejemplo de un proyecto de verdad

Una app de reservas tiene React en app.ejemplo.com y FastAPI en api.ejemplo.com. Ambos dominios apuntan al mismo VPS, pero Nginx enruta cada uno a su servicio correspondiente. PostgreSQL permanece en el entorno privado.

La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.

El error que evitaría

No confundas proxy_pass con la URL que usa el navegador. Si FastAPI usa autenticación basada en cookies o enlaces generados, revisa headers y configuración de proxies confiables. Nunca habilites --proxy-headers sin controlar quién puede conectar con el proceso.

Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.

¿Cómo se relaciona con ArduMaker?

En un VPS de ArduMaker podés administrar dominio, HTTPS y servicio de backend mientras mantenés el puerto 8000 interno. Esto ayuda a alojar varias aplicaciones sin abrir un puerto por proyecto.

En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.

Preguntas que aparecen cuando lo probás

¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.

¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.

¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.

Referencias

En resumen: una buena configuración de red o servidor es la que puedes explicar, verificar y recuperar cuando algo falla.