Hot answers tagged

3

In general caching works poorly with dynamic content, especially with content that contains things like "recently viewed" that will change every singe page load. If you really want to use caching then the first step is to disable that plug in so that there's a theoretical chance that someone might be served the same page twice. The second step is to only ...


2

That's because the directory exists, and therefore the try_files check try_files $uri $uri/ @proxy; succeeds. But there is no directory index file (typically index.html, see index), and autoindex is not turned on either (see autoindex). Depending on what you want to happen, consider the following options: Leave it as is (and may be tune which index ...


1

DerfK is right about dynamic content at the full page level, you absolutely don't want cookie leakage to occur. However you can do more caching at the layers upstream - with WordPress specifically, it has a decent pluggable object cache. This means, that while the page itself won't be cached, you can store much of the database load within a ephemeral store ...


1

The normal way to handle multi-site fail over is to have a pair of load balancers on site A in a master/slave fail over config. Then put an identical pair on the remote site. If ALL the backend servers on site A fail then use the public VIP on site B as the fallback (high latencey of course across the WAN)... But back this up with a proper DNS based load ...


1

I am looking for a similar thing. This could help you : https://github.com/phokz/mod-auth-external/tree/master/mod_authnz_external


1

The problem is your second nginx instance that's trying to serve files locally: location / { try_files $uri $uri/ =404; } Just remove that whole thing if you want to serve using http://server2.com/app/. If you want to use http://server2.com/ instead, update the config to reflect that: listen [::]:80 default_server ipv6only=on; ...



Only top voted, non community-wiki answers of a minimum length are eligible