Supongamos que desea servir algunos caminos con carriles, y algunos otros caminos con wordpress. o desea que la aplicación sirva páginas de raíles si están disponibles, y retroceda en wordpress de otro modo.

Para SEO y generalmente tener una buena estructura de recursos en línea, tal vez quieras que las aplicaciones (las llamaremos ríos arriba) compartan el espacio de nombres. En otras palabras, si usted es categorías de servicios, desea que los caminos se vean como /categorías/tea-kettles , /categorías/coffee-mugs en lugar de /blog/categorías/tea-kettles y /rails-app/categories/coffee-mugs . La pregunta entonces es, ¿cuál es la solución técnica de este desafío?

Usaremos Nginx para abordar este problema.

upstream backends {
servidor 192.2.0.1;
servidor 192.2.0.2;
...
}

servidor {
...

ubicación / {
proxy_pass http://backends;
proxy_next_upstream error timeout http_404;
}
}

donde los servidores de corriente son carriles y wordpress, en ese orden.

¡Vamos a probarlo en el localhost!

Y para archivos en disco, tal vez activos estáticos, el config es el siguiente:

ubicación / {
root /path/to/root;
try_files $uri @fallback;
}

ubicación @fallback {
proxy_pass http://...
}

Otra solución menos preferible y no comprobada sería:

ubicación / {
# Enviar 404s a B
error_page 404 = @backendB;
proxy_intercept_errores on;
log_not_found off;

Prueba el proxy como normal
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://A;
}

ubicación @backendB {}
Si A no funcionó, probemos B.
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://B;

# Any 404s here are handled normally.
}