Hi Aleks,
I think it's not the one.
AFAIU the closest match for HAProxy "dst" is $server_addr, but it doesn't
work as good with DNAT, because it hides original destination IP used by a
client, even though there is a way to retrieve this information [1].
My usecase is following:
a) I create iptab
Given this config:
proxy_next_upstream timeout;
proxy_next_upstream_timeout 50;
proxy_connect_timeout 10;
proxy_read_timeout 100;
If upstream has issues causing connect timeout, nginx will re-try 5
upstream servers until hitting 50, then fail.
If one upstream has issues causing read timeout, nginx
I would like to have an Nginx setup where I have specific logic depending
on which interface (ip) the request arrived on.
I was able to make this work by having a server stanza for each ip on the
server, but was't able to do a combination of a specific ip and a wildcard
ip (as a catchall) - is the
I managed to solve my own problem with the use of XCLIENT. There isn't a
whole lot of information out there, so maybe search engines will pick up
on this post and help someone else.
It was very easy to set up. Simply turn "xclient off" to "xclient on" in
the nginx configuration as quoted below
Thanks for your answer! It was exactly what I wanted. I'll use nginx-conf.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265742,265769#msg-265769
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
> Am 31.03.2016 um 22:05 schrieb marcosbontempo :
>
> Thanks for your answer! It was exactly what I wanted. I'll use nginx-conf.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?2,265742,265769#msg-265769
>
> ___
> nginx mailing list
> n
On Thu, Mar 31, 2016 at 01:21:02PM -0400, CJ Ess wrote:
Hi there,
> I would like to have an Nginx setup where I have specific logic depending
> on which interface (ip) the request arrived on.
multiple server{} with different "listen"; possibly with an "include
common-config" entry.
Note: "liste
On Thu, Mar 31, 2016 at 6:54 PM, Frank Liu wrote:
> Given this config:
> proxy_next_upstream timeout;
> proxy_next_upstream_timeout 50;
> proxy_connect_timeout 10;
> proxy_read_timeout 100;
> If upstream has issues causing connect timeout, nginx will re-try 5
> upstream servers until hitting 50,
Does that mean by default if one upstream server is down (connect error or
connect timeout), nginx won't try the next server and POST request will
just fail?
Thanks!
Frank
On Tue, Mar 29, 2016 at 7:48 PM, Maxim Dounin wrote:
> Hello!
>
> On Tue, Mar 29, 2016 at 06:34:59PM -0700, Frank Liu wrot
Hello!
On Thu, Mar 31, 2016 at 07:46:40PM -0700, Frank Liu wrote:
> Does that mean by default if one upstream server is down (connect error or
> connect timeout), nginx won't try the next server and POST request will
> just fail?
No. Quoting CHANGES (http://nginx.org/en/CHANGES):
*) Change
Hi,
I'm having an odd problem here. I'm trying to set up nginx with a varnish
proxy in front of it. The box is Ubuntu 15.10, nginx 1.9.3, varnish 4.0.3.
For testing I set up varnish on port 8080, and nginx was running on port 80
and 443. I shut down both, edit the config files so that varnish is
Without showing your nginx config it's unlikely that anyone will be able to
troubleshoot. Likely there is a stray listen directive that's causing this.
On Thu, Mar 31, 2016 at 9:29 PM, plutocrat
wrote:
> Hi,
>
> I'm having an odd problem here. I'm trying to set up nginx with a varnish
> proxy in
Robert Paprocki Wrote:
---
> Without showing your nginx config it's unlikely that anyone will be able
to
> troubleshoot. Likely there is a stray listen directive that's causing
this.
There are no stray listen directives. I've checked many times.
I'm sure the mailing list would be happy to help if you would provide your
config files so that debugging doesn't involve reading your mind :)
On Thu, Mar 31, 2016 at 9:42 PM, plutocrat
wrote:
> Robert Paprocki Wrote:
> ---
> > Without showing
OK, was trying to keep the post relevant and succinct, but here goes with
the config. Its a newly set up server, so pretty much standard.
=
# cat nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;
events {
worker_connections 768;
# mu
So, just to be clear, these are the ones running now without varnish. Of
course the lines with listen 80 are changed to listen 8080, and when I
restart nginx, it appears on ports 80, 8080 and 443.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265791,265796#msg-265796
16 matches
Mail list logo
