Jonathan M. Wrote:
On 18 February 2013 15:06, jims [email protected] wrote:
I am new to nginx, it being recommended to solve a problem.
[ Having read your mail, this kind of reverse proxying is exactly what
nginx is very good at; I think you’re just trying to do too much, too
quickly, and need to step back from the problem for a moment to
identify what your first steps should be; then iterate from simple to
complex behaviours, only moving forward once each behaviour works
Point taken. Going straight for the desired end result doesn’t always
Thanks for your response, Jonathan. It has been helpful. Read on for
responses to your comments…
When you say “referrer”, do you really mean the referrer as
distinguished by client-originated HTTP headers? I wouldn’t do that,
When I say “referrer” I mean the site where the link is presented to the
user. If that is what is “distinguished by client-originated HTTP
The desired result is that if a person is in our pool of testers and is
testing the development website, any app server link (although pointing
putatively to the production app server) would be sent to the
that’s front-ending the test app server. The idea is to minimize
unauthorized traffic to the test server. By using only links that get
the production app server, if someone saves the link and tries again
they will hit the production app server’s reverse-proxy front-end. They
would only hit our test app server if they are actively testing for us.
Once testing is complete, the proven code can be promoted to te
webste without having to deal with changing test links to prod links in
process Those who will be maintaining the links ongoing should not be
expected either to change links as part of a move-to-production or to
to learn how to put variables into all the links, and we would not have
modify the CMS to handle links with variables - they should be able to
and paste to create links, which resulting content should be able to be
promoted to production without change, or it defeats the purpose of
modern content-management system.
The app servers can only be accessed over https, and the proxy will
eventually but not quite yet.
That last part may be more of an issue for you, as you’ll discover you
need an IP address per SSL site you want to host.
Normally, yes, and each of the app server hostnames has its own
IP address now, with trusted certs associated. We are working on
a wildcard cert which we’d use for the proxy as well as the website, and
will add IP addresses to the proxy if necessary. I would hope that,
we want the proxy to choose between two back-end app servers for the
front-end uri, depending on whether or not there is a referrer of the
development website, one IP should be all that’s needed on the
than trying to redirect to another server name, with one server name
servicing one proxied server and the other, the other proxied
Goodness, no. I wouldn’t /touch/ referer headers for HTTP routing. So
OK. How would you recommend ensuring that if you click on a link on our
site, it goes to the proxied test app server but if you access that same
in any other way, whether by way of a link on the prod website, a
someone emailing you the link - the request goes to the proxied prod app
server? As I said, I’m an nginx newb, so monosyllabic responses are
Regardless, I can’t seem to get past the connection to the backend
I keep getting a 110 connection failure. I have tried several
configurations but none seem to work.
What does a connection, via telnet/netcat, from the server, show you?
I get a connection. I haven’t figured out the right HTTP command to
get a valid response yet, but I get a response - not a timeout.
See my earlier response explaining the business requirement, to
why this is a desireable behavior.
contradicts the above 2 lines, then it’s not legal nginx config.
If you look at the example conf I posted, that configuration - two
server stanzas, each with a location directive, and I get that message.
probably have something else misconfigured. Again, newb…
The redirect is a redirect - telling nginx to use a different
“upstream” server from what it would normally use based on the URL in
request. However, if there is a better way to get the same result I am
for it. For example, a method whereby the same front-end url chooses an
upstream server based on the valid_referer criterion, or whatever it is
would recommend other than the referrer,.
I don’t have a config file to post because it has gone through a
iterations already, none of which have been saved.
apt-get install git-core
I don’t want to install apt on my centos server How 'bout ‘yum
access_log /var/log/nginx/devpxyaccess.log main;
access_log /var/log/nginx/pxyaccess.log main ;
Irrespective of this, there are much nicer ways to achieve this, which
- Nginx maps to translate from client Host header to backend FQDN.
Would that work if the goal is to direct traffic based on where you’re
coming from? I will explore…
- Access/error logs specified using variables, but DRY them out at a
higher level than per-server (i.e. state them once, globally, at the
The logs are specified at per-server to quickly identify where the
lies. They will be only at the nginx.conf http level when I have a
- A single server stanza, switching between backends.
I like the idea - I’m just stuck on how to get it to switch based on
the client is coming from…
When you do what?
When I set up my included config file to use the two-server-stanza
configuration I posted (with hostnames/addresses pointing to real-life
stuff, of course) that’s what I get when issuing the service restart.
Jonathan M. // Oxford, London, UK
nginx mailing list
Thanks again - you’ve been quite helpful.
Posted at Nginx Forum: