Logré configurar un proxy inverso de mi aplicación heroku con lo siguiente en config.ru
require ::File.expand_path('../config/environment', __FILE__)
use Rack::ReverseProxy do
reverse_proxy /^\/blog(.*)$/, 'http://blog.domain.com$1', opts={:preserve_host => true}
end
run Appname::Application
Esto permite que mi aplicación heroku se ejecute en dominio.com y que dominio.com/blog aparezca como la URL mientras se sirve el sitio de wordpress blog.dominio.com. Genial hasta ahora.
El sitio de wordpress se sirve correctamente cuando voy a domain.com/blog, sin embargo, cuando voy a cualquier página más profunda, como una publicación individual, wordpress arroja un error. Estaba usando enlaces permanentes con la fecha y el título en la URL del formulario: domian.com/blog/2012/07/a-great-blog-post – Parece que a Worpress ahora no le gusta esto. Cuando volví a cambiar los enlaces al formulario domain.com/blog/?p=4, la página se mostró correctamente.
Parece que no maneja correctamente las barras diagonales finales después del dominio inicial.com/blog. Lo que encuentro extraño es que domain.com/blog/wp-admin (y toda la aplicación de administración de WP) funciona sin contratiempos.
¿Alguien puede ver algún problema evidente por el cual las páginas/publicaciones con múltiples barras inclinadas “https://stackoverflow.com/” podrían estar causando problemas?
¡Gracias por adelantado!
Bueno, encontré una solución, por alguna razón en la configuración de WP para el enlace permanente, no me gustó ninguna de las opciones predeterminadas, excepto el formulario donde puede recuperar la publicación por identificación. (http://www.dominio.com/blog/?p=123)
Para fines de SEO, quería que el título de la publicación estuviera en la URL. Así que ingresé en el campo de estructura personalizada: /index.php/%postname%/
Parece que requería index.php para que wordpress manejara el enrutamiento correctamente.
Este es el error que parece arrojar Apache: Error interno del servidor El servidor encontró un error interno o una configuración incorrecta y no pudo completar su solicitud. Comuníquese con el administrador del servidor, root@localhost e infórmele la hora en que ocurrió el error y cualquier cosa que haya hecho que pueda haber causado el error. Puede haber más información disponible sobre este error en el registro de errores del servidor.
– cmetcalfe
6 de julio de 2012 a las 16:18
Utilicé un proxy inverso de rack y New Relic me dice que las solicitudes pasan mucho tiempo allí, ahora estoy intentando github.com/ryandotsmith/nginx-buildpack lo malo es que se explica con unicornio mientras que hoy puma es el servidor recomendado.
– sitios
4 oct 2015 a las 17:13