Posted by gerold on June 3, 2011 at 6:42pm
we have a high-trafficked d6 site and we subscribed to third-party service to handle malicious traffics. this third-party service functions as our reverse proxy and cdn which runs nginx. is there a need for us to enable d6 reverse proxy setting or not? if there is, do we need to apply a d6 patch (http://drupal.org/node/466444) for reverse proxy? any known issue with nginx as reverse proxy?
Thanks!
Comments
I don't know of any issues
I don't know of any issues with nginx (but I am also not using it), but you'll need the D6 core reverse proxy setting especially for getting the correct IP adresses of your visitors, because currently you'll just find the IPs of your reverse proxy in the log.
So setting it up like that example in default.settings.php should work fine with all those IP adresses, which your reverse proxys have.
Best Wishes,
Fabian
Use Pressflow
Use pressflow so you don't have to apply that patch or this one as well
http://drupal.org/node/621748#comment-3086860
I think you're mixing things up
the original IP is provided at the server level. If you're running Apache you need the rapf module properly configured and also to add a header that forwards the real IP to the nginx proxy config. Like this:
proxy_set_header X-Real-IP $remote_addr;I suppose that your CDN provider already did that. You can check the incoming traffic. Use, e.g.,
tcpdumpfor capturing the traffic between the proxy and the backend to see what is being sent if needed.As suggested above use pressflow and save yourself a lot of trouble hunting down and applying the patches.
thanks a lot for feedback!
thanks a lot for feedback! yes, we are now looking into pressflow migration. For now we are concern of possible issues by setting a d6 site behind proxy but without turning on drupal reverse proxy config. does this affect drupal sessions and other behavior? because drupal sees all traffic coming from our reverse proxy ips and not the actual client ip.
The reasonhen
why it sees all the traffic ascoming from the proxy it's because you haven't installed the rpaf Apache module.
Also there's no migration of stock drupal to pressflow. You just download the snapshot tarball from the github repo and do a:
tar zxvf <snapshot tarball> -C /path/to/your/site/root --strip-components=1and you're done. There's no database updates, nada. Now you have nice things besides the support for reverse proxies like a cache for path aliases (needs to be enabled) for example.
Go ahead and try it. As for the sessions you'll need to have:
proxy_cache_bypass $cookie_NO_CACHE $cookie_LOGGED_IN;proxy_no_cache $cookie_NO_CACHE $cookie_LOGGED_IN;
The
$cookie_NO_CACHEand$cookie_LOGGED_INvariables are set by pressflow when submitting a form.But I suppose that your CDN provider did their homework and already have that in their Nginx proxy config.
You must enable the the
$reverse_proxyvariable in your settings.php:<?php$conf['reverse_proxy'] = TRUE;
?>
That's well docummented on the
default.settings.phpfile that comes with pressflow.There is other stuff like the use of the
X-Forwarded-Forfor header for constraining the IPs of the clients/proxies at the app level that can connect to the backend but above you have everything you need. Besides I believe you should do that at the server (Apache) level.@perusio -- thanks for
@perusio -- thanks for detailed response. i had the site moved or replaced by pressflow without issue, i setup my apache x-forwarded-for to give me correct/actual client ip on apache logs, and was able to test/configure the site to connect to reverse proxy (nginx) without issue, but right now we are not ready to have the pressflow and reverse proxy set into production, so i would like to know the drawbacks of "having the site behind proxy but without turning on drupal's reverse proxy config".
Thanks!
The drawback is that the IPs
The drawback is that the IPs in the drupal logs will be wrong.
Basically everything that uses the ip_address() function, will get the address of the proxy instead of the real client ip.
Without Pressflow Drupal will send out a SESSION cookie always, which might prevent nginx from caching the pages. (at least in Varnish that is a problem).
So while static assets will be cached, drupal content will most probably be not until you upgrade to Pressflow.
Best Wishes,
Fabian
You'll need to do the
heavy lifting that pressflow cookie setting does yourself.
Something like this will do, probably:
set $no_cache 0;
if ($http_cookie ~* SESS) {
set $no_cache 1;
}
proxy_cache_bypass $no_cache;
proxy_no_cache $no_cache;
There's also a bunch of headers that won't be set, like the
Varyheader.