A few gotchas when your Drupal site is being deployed behind caching servers and proxy_pass
In addition to the caching, the site is served up as part of a much bigger site /deep/down/in/the/url/structure, so proxy_pass is used (before caching) to rewrite the paths. Gotcha no.2 is that base_path() in drupal picks up the path of the origin server, so I had to add a condition like this in my settings.php (excuse wrapping, really must sort this site out for code samples):-
$base_url = 'http://'.$_SERVER['HTTP_X_FORWARDED_HOST'].'/path/to/my/proxied/site';
The clue to gotcha number 3 is in that last example. $_SERVER['HTTP_HOST'] reports the host of the origin server, rather than the public host, so if it is used anywhere in your code, it may cause issues. I ended up adding a function getHost() that I use to return the appropriate host, depending on where the site is being viewed (once again excuse formatting):-
$host = $_SERVER['HTTP_HOST'];
$host = $_SERVER['HTTP_X_FORWARDED_HOST'];
Gotcha No.4 was image paths in optimised css - both the Drupal-provided CSS caching and some external stuff I had using minify - these both rewrote the image paths to use those from the origin server. This meant that CSS applied images worked in the non-cached editing environment but not on live. I haven't come up with a solution for that one yet, other then to leave some of the stylesheets non-minified.
* maybe there is a solution to this, but assume in this case there is little or no scope to request server config changes.