[TriLUG] Help with proxy setup

[Ron Kelley]

Thanks for the help.  By 80%, I mean 80% of the pages load all the time while the other pages (wp-login, etc) fail to load the CSS files when using the proxy setup.

As for the setup:

pfSense firewall (NAT port 80) <—>  nginx proxy server (172.16.150.11) <—> nginx word press server-1 (172.16.150.4)
pfSense firewall (NAT port 80) <—>  nginx proxy server (172.16.150.11) <—> nginx word press server-2 (172.16.150.5)
pfSense firewall (NAT port 80) <—>  nginx proxy server (172.16.150.11) <—> nginx word press server-3 (172.16.150.6)
…
pfSense firewall (NAT port 80) <—>  nginx proxy server (172.16.150.11) <—> nginx word press server-1 (172.16.150.NNN)


If I VPN into the network, I can browse the site w/no issues at all using the local DNS server (thus, bypassing the nginx proxy).  However, if I am on the outside of the network, I have issues getting to some of the pages.

So, it appears all the issues are due to the proxy setup since the server responds perfectly well when I am on the inside the network.


Thanks again for the assist!

-Ron




On Dec 3, 2013, at 4:04 PM, Igor Partola <igor at igorpartola.com> wrote:

By "works 80% of the time" do you mean that sometimes it works and
sometimes it doesn't? If so, doing DNS resolution is probably suspect. I
can say that at least older versions of nginx also ignored the DNS TTL in
this case, and would permanently cache any A records they got. If this is
still the case, it completely negates the flexibility you get from using
DNS vs hardcoding IP's.

As for CSS not loading... So what is your setup? It seems that you have one
frontend nginx instance, that then connects to more than one nginx server
on the backend server (servers?). Does nginx on the backend run WordPress
directly? Or is there apache2 involved somewhere as well?

The basic process for debugging this goes like this:

1. Check that you can fetch the CSS file on the backend server. Use curl to
request it as directly as possible. Inspect both access and error logs on
the backend server.
2. If the above step worked, then the issue is somewhere in the reverse
proxying chain. Try the next proxy server up from the very backend.
3. Repeat until you find the step where it does not work, then examine the
configuration for that proxy.

If step 1 fails immediately, there should be an error logged.

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