Hi, I've seen a pattern of errors on Nginx under load, where a single host returns a large burst of 500 errors along with messages in the error log like: > 2021/02/03 00:52:32 217#0: *289501 bind(1.2.3.4) failed (98: Address already in use) while connecting to upstream, client: 127.0.0.2, server: local_upstream, request: "HEAD /library/movie.mp4 HTTP/1.1", upstream: "httpby jarstewa - Other discussion
When running load tests against an Nginx server, I seen a failure mode that results in Nginx returning 5xx errors, and the error log is filled with messages like: > 140#0: *1572276 bind(0.0.0.0) failed (98: Address already in use) while connecting to upstream My theories for what might be happening here were: 1) File handles exhausted 2) Ephemeral ports or sockets exhausted 3) Nginxby jarstewa - Other discussion
Bumping this thread in the hopes that someone knows the answer.by jarstewa - Nginx Mailing List - English
Is there an equivalent of max_fails (http://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) if I'm using proxy_pass without an upstream block? E.g. http { server { resolver 10.0.0.2 valid=5s; set $upstream_server http://foo.bar:80; location ~* \.(html)$ { proxy_pass $upstream_server; } } }by jarstewa - Nginx Mailing List - English
I am interested in using Nginx as a load balancer to shard requests across a fleet of docker containers uses consistent hashing and service discovery as described by https://www.nginx.com/blog/dns-service-discovery-nginx-plus/ and https://www.nginx.com/resources/wiki/modules/consistent_hash/. My docker containers are running in AWS ECS, so it looks like Route53 autonaming would be a great way toby jarstewa - Other discussion
Hmm, I notice this from the map documentation: > Since variables are evaluated only when they are used, the mere declaration even of a large number of “map” variables does not add any extra costs to request processing. Here is what I suspect: 1) The limit_req directive is being processed before the auth subrequest 2) Therefore, when the limit_req is present, the mapped variablesby jarstewa - Nginx Mailing List - English
Digging into this some more today, I've continued to find what seems to be odd behavior. If I remove all of the limit_req directives, then the mapped variables based on the upstream are always present: { "upstream_http_tier": "", "tier": "02x", "http_tier": "", "key_two": "", "key_tby jarstewa - Nginx Mailing List - English
Francis Daly Wrote: ------------------------------------------------------- > On Wed, Aug 29, 2018 at 07:14:01PM -0400, jarstewa wrote: > > Hi there, > > I do not know the answer, and I have not tested the code you provided. > > But, one suggestion which might be quick for you to test: > > what happens if you change all of your variable names so that they dby jarstewa - Nginx Mailing List - English
I'm hoping to use the limit_req directive with different rates based on a header that is returned from the auth subrequest. I got some ideas from https://www.ruby-forum.com/topic/4418040 but am running into a few problems. Here is my configuration: > user nginx; > worker_processes auto; > error_log /var/log/nginx/error.log warn; > pidby jarstewa - Nginx Mailing List - English
I'm currently using the auth_request directive and caching the result based on a guid + IP address: >location /auth { > internal; > > proxy_pass_request_body off; > proxy_pass $upstream_server/auth?id=$guid&requestor=$last_client_ip; > > proxy_cache auth_cache; > set $auth_cache_key "${guid}|${last_client_ip}"; > proxy_cache_kby jarstewa - Nginx Mailing List - English
Maxim Dounin Wrote: ------------------------------------------------------- > The explanation on why it isn't working was in the first paragraph > I wrote: > > : The limit_req directive doesn't try to limit requests already > : limited, as well as subrequests within these requests. You should > : configure all limits you want to apply to a request in one place. My aby jarstewa - Nginx Mailing List - English
Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > ... > Note well that this configuration implies that every request to > "/out/..." will generate a subrequest to "/auth". As such, you > can safely move the "limit_req zone=auth ..." limit to "location > /out/", as results will be (mostly) idenby jarstewa - Nginx Mailing List - English
Hi, I currently have an nginx configuration that uses the limit_req directive to throttle upstream content requests. Now I'm trying to add similar rate limiting for auth requests, but I haven't been able to get the auth throttle to kick in during testing (whereas the content throttle works as expected). Is there some known limitation of using limit_req against auth_request requests, or do I simpby jarstewa - Nginx Mailing List - English