Even though it seems wrong, I’m still going to try adding “always” to that just
to test. But I agree that it is not likely going to make a difference since my
goal is to send a value upstream and not apply it to the return from upstream.
To answer the other, if I inspect the page that comes back
add_header is used to add a header to a response. It’s not entirely clear to
me that that’s what you want to do. But if so, add_header won’t run for
non-200 return values by default. If you want to propagate the header for
error conditions add the “always” option:
add_header X-Origin-Forward
I hope I can explain this well enough to understand what I’m doing wrong.
The problem I am trying to solve is that I am making proxy requests to a site
that has IP restrictions. Nginx is making a request to another Proxy URL
rewrite server we use which then makes the request to the web applicati
Two questions:
1. how are you measuring memory consumption?
2. How much physical memory do you have on your host?
Assuming that you are running on Linux, can you use pidstat -r -t -u -v -w -C
“nginx”
to confirm the process’s memory consumption,
and cat /var/meminfo to view a detailed descrip
PS:
maybe I pasted too much of my config, basically the important line is:
try_files $uri /virtual_new.php =404;
Does it look legitim to you? Is it the proper way to redirect in such a
case or should I better use rewrite/redirect?
Thank you!
---
> Mix of different times in logs suggests that workers are blocked for a
long time doing something
> (and hence the time in some worker process are not updated for a long
time).
> Reasons can be different, and more information/logs are needed to say
anything for sure. In this particular case m
check the limit_req_module,
http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html
our beloved and hugely useful search engines gave this:
https://www.nginx.com/blog/rate-limiting-nginx/
it’s not possible to manipulate limits with cli though.
br,
Aziz.
> On 15 Mar 2018, at 09:52, Ma
