This may well help:
https://www.nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus/
On 10/04/2018 13:54, Salikhov Dinislam wrote:
Hello,
On Linux, NINGX can have more than 65K connections to backends per one local
address of a proxy (set via proxy_bind), as Linux support
We're seeing an 502 bad gateway responses to client on an nginx load
balanced upstream due to "no live upstreams".
The upstream in question has 2 servers defined with default settings
running over https (proxy_pass https://myupstream).
When this happens we see "no live upstreams while
My guess would be that your app is redirecting back to the slash urls
Your could test this with a directory on the webserver that has a
matching index file.
Alternatively point a browser at the upstream and check for redirects
directly
On 28/04/2017 17:52, Alex Med wrote:
Steven -
I
Yep.
On 28/04/2017 16:43, Alex Med wrote:
Steve -
Thank you so much this has brought so much clarity! I appreciate the time
you spend writing the reply.
So the rewrite ^/(.*)/$ /$1 permanent; needs to be outside of the location
definition and inside the server definition, correct?
Infinite
If I understand what you're trying to do correctly, then I think you
want something like:
# Ensure no tailing slashes
rewrite ^/(.*)/$ /$1 permanent;
location @upstream {
proxy_pass https://:xportNumber;
proxy_set_header Host $host;
proxy_set_header X-Real-IP
On 05/12/2016 17:12, Maxim Dounin wrote:
Hello!
On Mon, Dec 05, 2016 at 02:40:27PM +, Steven Hartland wrote:
On 05/12/2016 13:27, Maxim Dounin wrote:
Hello!
On Sun, Dec 04, 2016 at 09:39:59PM +, Steven Hartland wrote:
[...]
I believe the change to add a localhost bind
I believe you want proxy_ignore_client_abort on to achieve that.
On 12/01/2017 19:23, Jonathan Geyser wrote:
Richard,
On further investigation -- it looks like the client was closing the
front-end connection. I need the back-end socket to remain open
regardless of what the front-end is
On 05/12/2016 17:12, Maxim Dounin wrote:
Hello!
On Mon, Dec 05, 2016 at 02:40:27PM +, Steven Hartland wrote:
snip...
Given that the real local address of the listening socket as shown
by netstat is 10.10.96.146, it means that the socket was created
when there were no explicit 127.0.0.1
Cool thanks for this.
Looks like on http://nginx.org/en/docs/njs_about.html you have a typo on
the second line "nignScript" I assume you meant nginScript ;-)
On 05/12/2016 15:26, Igor Sysoev wrote:
Hi!
We have made recently documentation for nginScript:
On 05/12/2016 13:27, Maxim Dounin wrote:
Hello!
On Sun, Dec 04, 2016 at 09:39:59PM +, Steven Hartland wrote:
We've used nginx for years and never had an issue with nginx upgrade
until today where the upgrade command ran but almost instantly after the
new process exited.
/usr/local/etc
We've used nginx for years and never had an issue with nginx upgrade
until today where the upgrade command ran but almost instantly after the
new process exited.
/usr/local/etc/rc.d/nginx upgrade
Performing sanity check on nginx configuration:
nginx: the configuration file
On 19/10/2015 17:59, Maxim Dounin wrote:
Hello!
On Fri, Oct 16, 2015 at 06:15:30PM +0100, Steven Hartland wrote:
On 16/10/2015 13:20, Maxim Dounin wrote:
Hello!
On Fri, Oct 16, 2015 at 02:36:13AM +0100, Steven Hartland wrote:
I'm making changes to a filter module and when it detected
On 19/10/2015 22:26, Sergey Kandaurov wrote:
On Oct 19, 2015, at 8:57 PM, Maxim Dounin <mdou...@mdounin.ru> wrote:
Hello!
On Fri, Oct 16, 2015 at 06:24:11PM +0100, Steven Hartland wrote:
On 16/10/2015 13:05, Maxim Dounin wrote:
Hello!
On Fri, Oct 16, 2015 at 12:09:49AM +,
I'm making changes to a filter module and when it detected an error it
returned NGX_ERROR however the response generated to the client isn't
the expected 500 internal server error I would have expected given said
return.
So the question is do filters have to manually call
On 01/09/2015 06:58, Yichun Zhang (agentzh) wrote:
Hello!
On Tue, Sep 1, 2015 at 4:29 AM, Valentin Bartenev wrote:
#define NGX_HTTP_MAX_URI_CHANGES 10
-#define NGX_HTTP_MAX_SUBREQUESTS 200
+#define NGX_HTTP_MAX_SUBREQUESTS 50
Hmm, this change makes me sad. In
If you want to just pass the header through and not process it you can
use proxy_pass_header.
We do just this to pass X-Accel-Redirect though from server1 - server2
where its then processed.
e.g.
proxy_pass_header X-Accel-Redirect
Hope this helps.
Regards
Steve
On 19/12/2014 06:52,
First off thanks for reviewing, comments / questions inline below
On 05/12/2014 16:00, Maxim Dounin wrote:
Hello!
On Thu, Dec 04, 2014 at 09:07:57PM +, Steven Hartland wrote:
# HG changeset patch
# User Steven Hartland steven.hartl...@multiplay.co.uk
# Date 1417727204 0
# Thu Dec 04
On 04/12/2014 19:37, Maxim Dounin wrote:
Hello!
On Tue, Nov 25, 2014 at 02:22:13PM +, Steven Hartland wrote:
# HG changeset patch
# User Steven Hartland steven.hartl...@multiplay.co.uk
# Date 1416925134 0
# Tue Nov 25 14:18:54 2014 +
# Node ID
# HG changeset patch
# User Steven Hartland steven.hartl...@multiplay.co.uk
# Date 1417727204 0
# Thu Dec 04 21:06:44 2014 +
# Node ID 05d3973ece9af030d0312932938fc3d1f2f139dd
# Parent 1573fc7875fa09ee55763ce7ddc4e98d61e1deaf
Allow Partial Content responses to satisfy Range requests
# HG changeset patch
# User Steven Hartland steven.hartl...@multiplay.co.uk
# Date 1416925134 0
# Tue Nov 25 14:18:54 2014 +
# Node ID 0c3c06fabfc3b1c57710c0cced4837c10e3e9bbb
# Parent 7d7eac6e31df1d962a644f8093c1fbb8f91620ce
Allow Partial Content responses to satisfy Range requests
We use 206 cached responses.
On 23/11/2014 11:45, Piotr Sikora wrote:
Hey Maxim,
For example, it can be usable with 206 responses as well (and this
is perfectly allowed by the RFC).
206 responses won't be cached by nginx, so that's kind of a moot point.
I still think this approach is
For file logging it supports buffering see the docs here:
http://nginx.org/en/docs/http/ngx_http_log_module.html#access_log
On 11/11/2014 12:37, Alexander Todorov wrote:
Hi guys,
I've seen some reports on the web claiming nginx can serve in the
order of 1
requests per second (correct me
# HG changeset patch
# User Steven Hartland steven.hartl...@multiplay.co.uk
# Date 1409611936 0
# Mon Sep 01 22:52:16 2014 +
# Node ID 0dc608b347e24b914ee193214857de15aad2ac0b
# Parent 3f5f0ab59b359064db16e1aa52dfca335720dff6
Allow Partial Content responses to satisfy Range requests
- Original Message -
From: Maxim Dounin mdou...@mdounin.ru
To: nginx-devel@nginx.org
Sent: Monday, August 25, 2014 3:32 PM
Subject: Re: header value null termination?
Hello!
On Fri, Aug 22, 2014 at 12:30:22AM +0100, Steven Hartland wrote:
I'm creating a module in which I needed
Be good to see this in core, currently we use the 3rd party module to achieve
this:
http://wiki.nginx.org/HttpUpstreamRequestHashModule
One question on the patch, you appear to have some commented out locking is
this an oversight?
Regards
Steve
- Original Message -
From:
Hi guys the attached patch prevents http file cache from
logging a critical error when a file delete fails due to
it not existing, which I'm sure was never the intention.
N.B. Sorry if this appears as a duplicate, sent initially
from the wrong email address.
Regards
Steve
- Original Message -
From: Maxim Dounin mdou...@mdounin.ru
To: nginx-devel@nginx.org
Sent: Tuesday, November 19, 2013 4:52 PM
Subject: Re: Patch: Prevent crit error being loggged on delete of non-existent
file
Hello!
On Tue, Nov 19, 2013 at 04:43:54PM -, Steven Hartland wrote
27 matches
Mail list logo
