Conectar NGINX con uWSGI por proxy reverso

Servir una aplicación de Python en producción requiere unir NGINX, uWSGI y un socket Unix mediante un proxy reverso. Aquí verás cómo editar la configuración, validar cambios con nginx -t y reiniciar el servicio para que el dominio responda correctamente, además de una recomendación para crear un endpoint de estado que ayude a detectar fallos antes de un error 500.

¿Cómo conectar NGINX, uWSGI y el socket con un proxy reverso?

Para exponer la aplicación, uWSGI genera un archivo de socket que otro servicio usará para mostrarla en el navegador. El proxy reverso de NGINX se conecta directamente a ese socket y redirige las solicitudes de la URL (por ejemplo, la ruta deployment with Python) hacia uWSGI. Así, el tráfico HTTP llega a NGINX y este lo pasa al backend por el protocolo Unix del socket.

¿Qué es un proxy reverso en NGINX?

• Un intermediario que recibe requests HTTP y los reenvía a uWSGI.
• Se conecta al socket local en lugar de un puerto TCP.
• Simplifica el despliegue de apps Python con uWSGI.

¿Por qué usar un socket Unix con uWSGI?

• Comunicación local eficiente y segura entre NGINX y uWSGI.
• Menos exposición que abrir puertos públicos.
• Requiere especificar la ruta exacta en /tmp y cerrar con punto y coma.

¿Qué riesgos operativos considerar?

• Hay dos procesos críticos: NGINX y uWSGI. Si alguno falla, puede aparecer un error 500.
• Un endpoint de estado en NGINX ayuda a validar rápidamente si el servicio frontal responde.

¿Qué pasos seguir para editar y validar la configuración de NGINX?

El flujo práctico es directo: entrar a la terminal, abrir el archivo de configuración en /etc/nginx, incluir los parámetros de uWSGI y apuntar al socket. Luego, validar y reiniciar NGINX para aplicar los cambios.

¿Cómo editar el archivo en /etc/nginx?

• Cerrar procesos de monitoreo como htop antes de editar.
• Navegar a /etc/nginx y revisar sites-available y sites-enabled con ls.
• Abrir el archivo del sitio con privilegios de superusuario: sudo vim.
• Eliminar líneas temporales con dd en Vim.
• Agregar las directivas para uWSGI dentro del location correspondiente:

include uwsgi_params;
uwsgi_pass unix:/tmp/nombre-del-socket.sock;

• Guardar y salir en Vim con :wq.

¿Cómo validar la sintaxis y reiniciar NGINX?

• Probar la configuración antes de recargar servicios:

nginx -t

• Si la sintaxis está OK y la prueba es exitosa, reiniciar solo NGINX:

sudo service nginx restart

• Recargar el navegador y comprobar que ahora la aplicación se muestra correctamente en el dominio.

¿Qué habilidades y comandos se ponen en práctica?

• Edición segura con sudo vim y borrado de líneas con dd.
• Navegación de rutas del sistema: /etc/nginx, /tmp.
• Revisión de sitios en sites-available y sites-enabled.
• Inclusión de uwsgi_params y definición de uwsgi_pass con protocolo Unix.
• Validación con nginx -t y reinicio con sudo service nginx restart.
• Buenas prácticas: copiar y pegar la ruta del socket desde /tmp para evitar errores de tipado.

¿Cómo verificar el estado y prevenir errores 500?

Crear una nueva configuración de location para el estado en NGINX permite comprobar rápidamente si el frontal responde. Con dos procesos corriendo (NGINX y uWSGI), cualquiera puede fallar. Un endpoint de estado ayuda a distinguir si el problema está en NGINX o en uWSGI y reduce el tiempo de diagnóstico ante un HTTP 500.

• Añadir un location dedicado a verificación de estado.
• Usarlo para confirmar que NGINX está activo incluso si uWSGI cae.
• Probarlo desde la URL del dominio y automatizar verificaciones.

¿Te gustaría que revisemos juntos tu configuración de NGINX y el endpoint de estado? Comparte tu avance y dudas en los comentarios.