Cómo servir varios backends bajo un mismo dominio con enrutado por ruta y Nginx
El patrón que permite que /blog lo atienda un WordPress y el resto de rutas una aplicación Next.js, sin subdominio y sin que el navegador note el salto entre servidores.
Levantar dos aplicaciones distintas y que el visitante solo vea un dominio es un problema viejo, pero se sigue resolviendo mal cuando hay prisa. La receta es un proxy inverso delante de todo y enrutado por ruta: Nginx escucha en el dominio público y decide a qué backend manda cada petición según el prefijo de la URL. Lo que empieza por /blog va a un servidor; el resto, a otro.
El modelo mental del proxy inverso es sencillo. El navegador no habla con el servidor de la aplicación, habla con Nginx, y Nginx reenvía la petición al backend que toque. En el ejemplo que ilustra el patrón, 172.1.0.1 sirve la web principal hecha en Next.js y 172.1.0.2 sirve un WordPress para el blog. Esas direcciones no salen nunca al exterior: para el visitante todo es el mismo dominio, y el contenido de una entrada del blog lo ha montado otro de sus servidores sin que se entere.
Proxy inverso no es una redirección
Confundir proxy con redirect es el error clásico. Un 301 le dice al navegador "no pidas esta URL, pide esta otra", y el navegador lanza una segunda petición: la barra de direcciones cambia y el usuario acaba en otro host. Con un proxy inverso no hay segunda petición ni cambio de URL. El navegador sigue mostrando la ruta original mientras Nginx ha ido a buscar el contenido a otro servidor y devuelve la respuesta como si fuera suya. Ni subdominio nuevo, ni certificado aparte que explicar.
Qué más se puede colgar del mismo patrón
El enrutado por ruta no es solo para blogs. Cualquier prefijo puede apuntar a un servicio distinto:
/appa una aplicación/apia una API/admina un panel de administración/docsa la documentación
Son procesos independientes, en máquinas distintas si hace falta, con ciclos de despliegue separados. Añadir un servicio nuevo deja de ser una entrada más en DNS y pasa a ser una regla de enrutado en el proxy.
La pieza que conviene tener clara es que el DNS solo resuelve el dominio a la IP de la máquina donde corre Nginx. No hay nada ahí que sepa distinguir una ruta de otra, y por eso el reparto no se puede delegar al registrador ni a un subdominio. La decisión de a qué backend va cada petición vive entera en el proxy, que es también el punto donde se añaden cabeceras, se termina TLS o se corta el tráfico antes de llegar a la aplicación.
El precio es que ese proxy pasa a ser infraestructura crítica: si se cae, se caen a la vez la web, el blog y todo lo que cuelgue del mismo dominio, aunque los backends estén perfectamente vivos. Y cualquier backend que asuma que está en la raíz del host y genere enlaces absolutos con su propia ruta tendrá que ajustarse, porque desde fuera su prefijo es otro. Nada de esto es nuevo, pero sigue siendo la forma más barata de unificar servicios dispares bajo un único dominio sin tocar el DNS cada vez que se añade uno.
