Un reverse proxy se puede usar para cargar un sitio de WordPress desde un subdirectorio mientras se carga un sitio completamente separado en el dominio raíz.

Un reverse proxy consiste en un conjunto de reglas añadidas a un servidor web que instruyen al servidor para que envíe solicitudes a un subdirectorio dado a un servidor separado.

Consideremos un ejemplo para comprender mejor para qué se puede usar un reverse proxy. Imagine que tiene un sitio web que no es de WordPress que carga en ejemplo.com y desea usar WordPress para impulsar un blog. Desea que ese blog se cargue en ejemplo.com/blog y que se ejecute en un entorno separado.

Para que esto suceda, las reglas de reverse proxy deberían configurarse en el servidor web que aloja ejemplo.com que instruye al servidor web para que envíe cualquier solicitud del subdirectorio/blog a otro servidor web que aloje el sitio web de blogs/WordPress.

Reverse Proxy Add-On

Kinsta permite y soporta el uso de reverse proxies para cargar WordPress de un subdirectorio o para apuntar un subdirectorio de su sitio a un servidor externo. Sin embargo reverse proxies son a menudo desafiantes  para ser configurados y los sitios que usan reverse proxies requieren un soporte más especial que las instalaciones regulares de WordPress.

Por eso una suscripción mensual de $50 a nuestro add-on es aplicada para cada reverse proxy si es configurado por nosotros y requieren nuestro soporte.

Por otro lado por favor permítannos un día laboral para la configuración inicial del reverse proxy. En algunos casos particulares tiempo y colaboración adicional puede ser necesario para que el reverse proxy funcione adecuadamente.

Casos de Uso de Reverse Proxy

Hay tres posibles casos de uso para reverse proxies aquí en Kinsta. Para comprender estos casos de uso, primero debemos definir dos términos: sitio principal y sitio proxy.

  • El sitio principal es el sitio que se carga en el dominio raíz.
  • El sitio proxy es el sitio que se carga del subdirectorio a través de un reverse proxy.

Volviendo a nuestro ejemplo anterior, ejemplo.com sería el sitio principal, mientras que ejemplo.com/blog sería el sitio proxy.

Con esas definiciones en mente, estos son los tres casos de uso posibles para los reverse proxies en Kinsta:

  • Los sitios principales y proxy están alojados en Kinsta: el sitio principal, ejemplo.com y el sitio proxy, ejemplo.com/blog, están alojados en Kinsta. Esto permitiría una instalación de WordPress para alimentar ejemplo.com, mientras que una instalación de WordPress completamente separada se usó en ejemplo.com/blog.
  • Sitio proxy alojado por Kinsta: Kinsta no aloja el sitio principal, ejemplo.com, mientras que Kinsta aloja el sitio proxy, ejemplo.com/blog. Esto permitiría que una instalación de WordPress alojada en Kinsta se use en ejemplo.com/blog, mientras que el sitio principal es hospedado en otro lugar.
  • Sitio principal alojado por Kinsta: Kinsta aloja el sitio principal, ejemplo.com, mientras que Kinsta no aloja el sitio proxy, ejemplo.com/blog. Esto permitiría que una instalación de WordPress alojada en Kinsta se use en ejemplo.com, mientras que el subdirectorio de blog se alojó en otro lugar.

Repasemos las implicaciones de cada opción, en particular cubriremos los límites del soporte de Kinsta para cada escenario.

Ejemplo de Servidor de Reverse Proxy

Ejemplo de Servidor de Reverse Proxy

Sitios Principales y de Proxy Alojados por Kinsta

Si ambos sitios están alojados en Kinsta, el equipo de soporte de Kinsta puede configurar las reglas de reverse proxy necesarias en el sitio principal y también configurar el sitio proxy para que se cargue sobre el reverse proxy. Tenga en cuenta que tanto el sitio principal como el sitio proxy deben estar ubicados en el mismo centro de datos. Además, es posible un corto tiempo de inactividad durante la configuración del reverse proxy a medida que Kinsta mueve los sitios a su lugar.

En este escenario, las responsabilidades del cliente incluirían lo siguiente:

  • Migrar ambos sitios al entorno de Kinsta (o enviar solicitudes de migración para que Kinsta migre los sitios).
  • Proporcionar al equipo de soporte de Kinsta una descripción clara de la configuración del dominio.
  • Permitir aproximadamente un día hábil para cada configuración de reverse proxy.

En este escenario, las responsabilidades de Kinsta incluirían lo siguiente:

  • Configurar las reglas necesarias de reverse proxy en el sitio principal.
  • Configurar el sitio proxy para cargar sobre el reverse proxy.

Solo el Sitio Proxy Alojado por Kinsta

Nota importante: si sólo el sitio proxy es alojado en Kinsta necesitamos que nos proporcione las direcciones IP del proxy server y que configure el mismo para establecer los encabezados listados en nuestras reglas de Nginx sobre reverse proxies. Estos pasos son requeridos para asegurar que nuestro sistema de analítica funcione adecuadamente y que no pongamos en la lista negra las direcciones IP de su reverse proxy.

Si solo el sitio proxy está alojado en Kinsta, configurar el reverse proxy no es algo que Kinsta pueda hacer, ya que el reverse proxy debe configurarse en el servidor que aloja el sitio principal. En este escenario, la responsabilidad de Kinsta se limita a configurar el sitio proxy para que esté listo para ser cargado a través de un reverse proxy.

En este escenario, las responsabilidades del cliente incluirían lo siguiente:

  • Migrar el sitio proxy a Kinsta (o enviar una solicitud de migración para que Kinsta migre el sitio).
  • Agregar un dominio al sitio que será utilizado por el reverse proxy. El reverse proxy debe apuntar a un dominio para acceder al sitio proxy. Normalmente, un subdominio se usa para este propósito. Por ejemplo, blog.ejemplo.com normalmente se usaría para una carga de reverse proxy en ejemplo.com/blog.
  • Proporcionar al equipo de soporte de Kinsta una descripción clara de la configuración del dominio.
  • Permitir aproximadamente un día hábil para que el sitio proxy sea configurado para cargar sobre un reverse proxy.
  • Una vez que el sitio proxy ha sido configurado, crear el reverse proxy en el servidor que aloja el sitio principal.

En este escenario, como se mencionó, la responsabilidad de Kinsta se limita a configurar el sitio proxy para que esté configurado correctamente para cargarse sobre un reverse proxy.

Solo el Sitio Principal Está Hospedado por Kinsta

Si solo el sitio principal está alojado en Kinsta, la responsabilidad de Kinsta se limita a configurar un reverse proxy para cargar el sitio proxy (alojado en otro lugar). Kinsta agregará la regla estándar de reverse proxy listada en este artículo. Las personalizaciones a esta regla se pueden hacer a petición del cliente.

En este escenario, el cliente retiene la responsabilidad de configurar el sitio proxy para que se cargue correctamente sobre el reverse proxy y para solicitar ajustes a la regla de reverse proxy en caso de que no cargue correctamente el sitio proxy.

Limitaciones de Sitios Proxy

Existen algunas limitaciones inherentes al uso de reverse proxies en Kinsta.

Además, Kinsta no admite el uso de multisitio sobre un reverse proxy.

Además, la restauración de backups o el envío de sitios de etapas en vivo en sitios que se cargan sobre un reverse proxy pueden hacer que el sitio proxy deje de cargarse correctamente.Cuando se trabaja con un sitio proxy, siempre es aconsejable programar cambios como estos para tiempos de poco tráfico y consultar con el equipo de soporte de Kinsta antes de tomar medidas como estas.

¿Luchando con el tiempo de inactividad y los problemas de WordPress? Kinsta es la solución de alojamiento diseñada para ahorrarle tiempo! Vea nuestras características

En Kinsta, cuando se trata de sitios proxy, merece la pena el uso del entorno de staging. Después de las pruebas en staging, el flujo de trabajo más simple es duplicar esos cambios en el sitio en vivo en lugar de mandar todo a producción. Además, la restauración de los backups de los sitios con proxy solo debería realizarse en caso de emergencia cuando no sea posible deshacer los cambios manualmente.

Debido a estas limitaciones, no recomendamos el uso de sitios proxy si anticipa la restauración de backups o mandar sitios en staging a producción de forma rutinaria.

Una alternativa a los sitios proxy que vale la pena considerar es el uso de una instalación multisitio del subdirectorio de WordPress.

Configuración del Reverse Proxy del Sitio Principal

Hay dos implicaciones principales para el sitio principal al cargar subdirectorios sobre reverse proxies.

  • Las reglas de reverse proxy deben agregarse para cada subdirectorio proxy.
  • El sitio principal no podrá usar los subdirectorios proxy para ningún fin, ya que todas las solicitudes para ese subdirectorio se reenviarán al sitio proxy.

Esta es la regla estándar de reverse proxy de Nginx utilizada por Kinsta para cargar un sitio a través de un reverse proxy:

location ^~ /subdirectory/ {
  access_log off;
  proxy_pass http://subdirectory.domain.com;
  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;
}

El subdirectorio real sería sustituido por el / subdirectorio / marcador de posición. Además, http://subdirectorio.domain.com se cambiaría para que coincida con el dominio utilizado para apuntar el reverse proxy en el sitio proxy.

Configuración del Sitio Proxy

Para cargar un sitio a través de un reverse proxy, se deben realizar los siguientes cambios:

  • Se debe agregar un subdirectorio a la ruta del directorio en el servidor, haciendo coincidir el subdirectorio utilizado para cargar el sitio y todos los archivos del sitio web movidos a este subdirectorio.
  • Se deben actualizar las configuraciones del servidor web para actualizar la raíz del sitio web e incluir el nuevo subdirectorio. Además, se debe agregar una reescritura a la configuración del servidor para eliminar el subdirectorio del URI de solicitud para cada solicitud entrante.
  • Todas las URLs en la base de datos del sitio proxy deben actualizarse para que coincidan con las URL del sitio en vivo (por ejemplo, ejemplo.com/blog).
  • El archivo wp-config.php del sitio debe actualizarse con una definición $_SERVER [‘HTTP_HOST’] apuntando a la URL principal del sitio (ejemplo.com en el ejemplo que hemos estado considerando).
  • Si el sitio se ve obligado a cargar vía https, se deben agregar definiciones adicionales a wp-config.php para evitar los ciclos infinitos de redirección.

Tenga en cuenta que, debido a las reglas de reescritura necesarias, un sitio proxy no debe crear URLs que dupliquen el mismo subdirectorio bajo el cual se carga el sitio proxy. Por ejemplo, un sitio proxy en ejemplo.com/blog debería evitar crear una página o directorio en ejemplo.com/blog/blog.

Resumen

El uso de reverse proxies en Kinsta es posible y tenemos varios clientes que han optado por utilizar nuestra infraestructura de esta manera. Sin embargo, es importante comprender la complejidad técnica adicional que presenta esta disposición, así como las implicaciones para el uso de los sistemas de backups y entorno de staging de Kinsta.

Si cree que un reverse proxy es la mejor solución para su presente, no dude en ponerse en contacto con el equipo de soporte de Kinsta a través del chat en MyKinsta para iniciar el proceso.

24
Shares