Aprende cómo aplicar redirecciones en Nginx sin tener que reiniciar el servidor web.
Nginx es uno de los servidores web más conocidos junto a Apache. Antes de explicar sus ventajas y desventajas y qué característica especial tiene para las redirecciones. Entendamos a qué me refiero como "servidor web".
En este caso, como servidor web, me refiero al programa que se ejecuta en un servidor de red y se utiliza para servir el contenido web a los clientes/usuarios que estos solicitan. En un software de estas características, es de donde hay que aplicar la mayoría de implementaciones que explico en la categoría de servidores en mi web.
La mayoría de SEOs conocerán Apache, porque se puede editar por medio del archivo .htaccess, el cual nos permite hacer redirecciones y cambios en los códigos de respuesta de una forma rápida y sencilla. Apache suele ser un software de servidor web bastante sencillo de editar y donde hay multitud de ejemplos en internet de aplicaciones para SEO. Sin embargo con Nginx es otra historia.
Se suele considerar que es necesario un reinicio para que funcionen los cambios de servidor aplicados en nginx, pero se puede conseguir que estos se apliquen evitando reiniciar, siendo así un proceso menos traumático para todo el proyecto web.
A diferencia de Apache, con Nginx los cambios aplicados en la configuración no son inmediatos. Por lo que para hacer redirecciones con nginx, no basta con aplicar los comandos. El servidor tiene que procesarlos, y para que se haga esto, la práctica más común es reiniciar el servidor.
Sin embargo, en Nginx, puedes hacer cambios en la configuración sin tener que reiniciar el servidor por completo. Esto se debe a que Nginx está diseñado para ser dinámico y no requerir la interrupción del servicio al actualizar la configuración. Esto se podría hacer recargando la configuración en lugar de reiniciando el servidor por completo.
Para hacer redirecciones en Nginx sin tener que reiniciar el servidor por completo, sigue estos pasos:
/etc/nginx/nginx.conf.server en la configuración, donde se especifican los servidores virtuales de Nginx.server. Por ejemplo, si deseas redireccionar todas las solicitudes de https://example.com/test a https://example.com/prueba, puedes crear la directiva, y si no sabes como hacerlo, puedes generarla en el redireccionador de urls de nginx:server {
listen 80;
server_name example.com;
location = /test{
return 301 https://example.com/prueba;
}
}
nginx -t para asegurarte de que la sintaxis sea correcta. (Opcional, pero recomendado, si no, mínimo probarlo en un entorno de prueba.sudo systemctl reload nginx
De esta forma, la nueva configuración se cargará sin tener que reiniciar el servidor por completo.
Al recargar la configuración en vez de reiniciar, evitaremos el incordio y los posibles problemas que pueden surgir de todo un reinicio en una web. Para entender mejor la diferencia, detallo las dos opciones:
Al recargar la configuración de Nginx, se vuelven a cargar las configuraciones de los archivos de configuración de Nginx. Esto significa que Nginx volverá a leer el archivo de configuración en busca de cambios y, si hay algún cambio, se aplicarán en tiempo real sin interrumpir la conexión con los clientes. Por lo tanto, recargar la configuración de Nginx es una forma segura y no disruptiva de actualizar la configuración del servidor sin tener que detener el servicio.
Al reiniciar Nginx, se detiene el servicio de Nginx y se vuelve a iniciar. Esto significa que el servidor deja de servir solicitudes durante un breve período de tiempo, lo que puede interrumpir las conexiones activas y provocar un tiempo de inactividad en el servicio. Al reiniciar Nginx, se asegura que cualquier cambio en la configuración sea aplicado, pero también puede afectar negativamente a la experiencia del usuario, ya que los clientes que estén utilizando el servicio en ese momento se desconectarán.
Toda esta diferencia de configuración respecto a Apache tiene una razón de ser, y de hecho esta "debilidad" es debido a su gran fortaleza. Y es que a diferencia de Apache, Nginx tiene una arquitectura más ligera y escalable, lo que significa que utiliza menos recursos del sistema para manejar una mayor cantidad de solicitudes de manera más eficiente.
Además, Nginx tiene una capacidad de respuesta mucho más rápida y es capaz de manejar un gran número de solicitudes concurrentes, lo que lo convierte en prácticamente la mejor opción para sitios web de mucho tráfico.
Entre las ventajas de Nginx se encuentran: su bajo consumo de recursos, su alta capacidad de escalabilidad y su capacidad de manejar grandes cantidades de solicitudes con rapidez y eficiencia. Es por este motivo, que al ser tan eficiente y tener todo de una forma tan sólida, no tiene un ".htaccess" donde hacer los cambios y realizarlos al instante.
Decir que Nginx es más eficiente sin dar una explicación, son realmente palabras vacías. Así que es mejor comprender el motivo.
El principal motivo, es que a diferencia de apache, Nginx tiene una arquitectura asincrónica. Esto quiere decir que el programa está diseñado para manejar múltiples solicitudes sin bloquear el proceso principal. En otras palabras, cuando un cliente envía una solicitud al servidor, el servidor no espera a que se complete la solicitud antes de procesar la siguiente. Es decir, que puede procesar múltiples solicitudes de manera simultánea, incluso si una solicitud está tardando más tiempo en completarse que otras.
Mientras que apache tiene que manejar una solicitud tras otra, Nginx puede manejar varias a la vez.
En una web con un tráfico no masivo, esto apenas se nota. Pero en webs donde hacen solicitudes miles de usuarios a la vez, dependiendo del tipo de web, se puede empezar a notar.
Este tipo de arquitectura, permite que Nginx utilice menos recursos para procesar las solicitudes.
Básicamente y resumiendo, Nginx no necesita estar procesando todo por cada petición del usuario porque ya lo ha procesado. No obstante esto si bien puede ser una ventaja, a nivel de configuración nos puede resultar un problema. Uno de ellos, es que debido a esta arquitectura asincrónica, cuando queremos hacer cambios en nginx, estos no son inmediatos (como sí lo son en apache). Por lo cual suele generar ciertos desacuerdos entre departamentos por lo traumático que es reiniciar un servidor.
Es posible, que debido al nivel avanzado del artículo, no hayas podido entender del todo en qué consiste esta parte tan interesante del SEO Técnico. Este artículo es una pequeña parte de todo lo que se explica en el Máster de SEO que creé junto con Roberto Martínez.
Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB
¡Accede al Máster de SEO Técnico!Si te ha gustado esta publicación, siempre me lo puedes agradecer dándome like en esta publicación de LinkedIn sobre este mismo artículo.