[TriLUG] Help with proxy setup

[Ron Kelley]

Thanks for all the great replies.  I have been working with nginx for the past week, and my config is very similar to what Igor mentioned below.  While the main wordpress page loads, some of the CSS files don’t display properly after logging into the “wp-admin” area.  Here is what I have thus far:

server {
         listen 80;
         server_name _;
         rewrite ^/(.*)/$ /$1 permanent;
         location / {
            resolver 172.16.0.21;   #Internal DNS server
            proxy_redirect             off;
            proxy_pass http://$host$uri;
            proxy_set_header Host $host ;
            proxy_set_header        Referer         $http_referer;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header        X-Forwarded-Protocol  $scheme;
         }
}

As you can see from above, I am using an internal DNS resolver for the proxy_pass stuff.  This is working about 80% but some of the pages don’t load properly (mainly the CSS stuff on the wp-admin page).  And, I don’t see any errors in the nginx access or error log files (either on the proxy server or WP server).


Any pointers?

Thanks!

-Ron







On Dec 3, 2013, at 10:05 AM, Igor Partola <igor at igorpartola.com> wrote:

I third nginx as the tool of choice. I run it as a reverse proxy in almost
all cases, proxying to either apache2 or a custom Python application. There
are very few gotcha's when using it, and it's rock solid.

Other options to consider:

- Varnish: seems to be more feature-rich, which may or may not translate
into more nuanced configuration (never used it so cannot tell)
- HAProxy: simpler than nginx, but not a full web server (I typically have
nginx serve all the static media since that's what it is good at). One nice
thing about it: it can do TCP (level 4) proxying, which is good for
non-HTTP applications.
- Apache mod_proxy: not something I would choose unless you get it working
with the event mpm. Your reverse proxy really ought to be event-based to
make it as transparent as possible.

One word of unsolicited advice: make sure you get the X-Forwarded-For
header set properly, along with the other reverse-proxying headers.
Typically, they look like this:

           proxy_pass                 http://127.0.0.1:8080;
           proxy_redirect             off;
           proxy_set_header        Host            $host;
           proxy_set_header        Referer         $http_referer;
           proxy_set_header        X-Real-IP       $remote_addr;
           proxy_set_header        X-Forwarded-For
$proxy_add_x_forwarded_for;
           proxy_set_header        X-Forwarded-Protocol  $scheme;

The last two are really important: you want your backend to know which IP
the request came from and whether the request came over HTTP or HTTPS.
Otherwise, your application server will always see the requests as coming
from localhost over HTTP.

Igor
-- 
This message was sent to: Ron Kelley <rkelleyrtp at gmail.com>
To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
Unsubscribe or edit options on the web	: http://www.trilug.org/mailman/options/trilug/rkelleyrtp%40gmail.com
Welcome to TriLUG: http://trilug.org/welcome