# Issue Summary
* After executing Nginx soft reload with "service nginx reload", nginx is
able to close a lot of connections gracefully, but some connections aren't
closed gracefully and Nginx is sending an RST packet. For these connections,
Nginx didn't send FIN packet, and it didn't send "Connection: Close" header.
The connections are HTTP/1.1 keep alive connections.
# Expected Behaviour
* After executing Nginx soft reload, Nginx is gracefully closing all
connections by sending a "Connection: close" header in the response or a FIN
packet.
# Supporting Data
I have tcpdump of 5 such connections where nginx didn't close the connection
gracefully after nginx reload.
Here's the tcpdump -
https://drive.google.com/file/d/1UquhmJET9i8ShEizu8453iUKpprutILV/view?usp=…
If we analyse one such connection, we see that nginx didn't send FIN packet
on this connection, refer this image - https://i.imgur.com/zqyLOLc.png
If we see the response of second last request, we see nginx didn't send
"Connection: close" header either, refer this image -
https://i.imgur.com/P2uu722.png
In this image I have plotted FIN packets sent by nginx over time -
https://i.imgur.com/5lNAmnk.png
Nginx was reloaded on 2022-01-12 13:57:44 UTC.
FIN packet graph (https://i.imgur.com/5lNAmnk.png) shows that Nginx was able
to close a lot of connections gracefully at the time of reload, but it
wasn't able to close the 5 connections. TCP dump of which I've shared above
(https://drive.google.com/file/d/1UquhmJET9i8ShEizu8453iUKpprutILV/view?usp=…).
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,293375,293375#msg-293375
Excuse me for refer to quite old issue, we found a different behavior
regarding their headers order in case of X-Accel-Expires which is not 0 and
Cache-Control has any of no-store, no-cache or private.
It is very easy reproducing process.
ngx_http_upstream.c has two method ngx_http_upstream_process_cache_control
and ngx_http_upstream_process_accel_expires which operations their cache
related headers, Cache-Control is processed in
ngx_http_upstream_process_cache_control, X-Accel-Expires is processed in
process_accel_expires.
ngx_http_upstream_process_cache_control in ngx_http_upstream.c
4738 if (r->cache->valid_sec != 0 && u->headers_in.x_accel_expires !=
NULL) {
4739 return NGX_OK;
4740 }
4741
4742 start = h->value.data;
4743 last = start + h->value.len;
4744
4745 if (ngx_strlcasestrn(start, last, (u_char *) "no-cache", 8 - 1) !=
NULL
4746 || ngx_strlcasestrn(start, last, (u_char *) "no-store", 8 - 1)
!= NULL
4747 || ngx_strlcasestrn(start, last, (u_char *) "private", 7 - 1)
!= NULL)
4748 {
4749 u->cacheable = 0;
4750 return NGX_OK;
4751 }
If Cache-Control from upstream has a value of no-store, no-cache or
private, u->cacheable = 0; in ngx_http_upstream_process_cache_control
In the case of before processing ngx_http_upstream_process_accel_expires, if
it sets u->cacheable = 0 for this procedure, it does not cache according to
Cache-Control. X-Accel-Expires is only overwriting valid_sec.
OTOH, In the case of after processing
ngx_http_upstream_process_accel_expires,
ngx_http_upstream_process_cache_control returns NGX_OK earlier than the
procedure of Cache-Control: no-xxx or private.
In this case, it does cache, the cache is following x-accel-expires values.
It ignores Cache-Control.
As this result it seems not to override entirely Cache-Control by
X-Accel-Expires. And It has differential behavor according to order of
upstream header. We could not find this behavior in any nginx documents.
Could you tell me what is true?
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,219520,293374#msg-293374
Hello,
We have an responseHeader with technical information sent by the upstream
server tomcat.
We want to log this information in nginx and delete the header to avoid to
be visible in the response Header to the client.
log_format formatjson escape=json '{
'"tomcat_container_id": "$TOMCAT_CONTAINER_ID" }';
Nginx.conf in http {
map $sent_http_Container_Id $TOMCAT_CONTAINER_ID {
default $sent_http_Container_Id;
}
more_clear_headers 'Container-Id';
When I do this, my log tomcat_container_id is empty.
If I comment the more_clear_header command line, I have my log fill with the
right value but the header is also sent to the client.
So I don’t understand why my $TOMCAT_CONTAINER_ID Is clear when I delete the
header and not clear if I don’t.
Thanks for your help.
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,293336,293336#msg-293336
Hi,
I have some questions about Nginx performance. How many concurrent
connections can Nginx handle? What throughput can Nginx achieve when
serving a large number of small pages to a large number of clients (the
maximum number supported)? How does Nginx achieve its performance? Is the
epoll event loop all done in a single thread or are multiple threads used
to split the work of serving so many different clients?
thanks in advance
James Read
Hello,
As you may noticed already mailing list was migrated to mailman3. It differs significantly from mailman2 we used previously.
Please pay attention to a few noticeable changes:
* Mailman3 does not add X-BeenThere header to the outbound emails anymore. If you used this header for your filters, you should switch to the List-Id header (or List-Post header).
* Old archives are available on https://mailman.nginx.org/pipermail/, New archives started on Jan 1 2020 and could be found on https://mailman.nginx.org/mailman3/lists/
* mail interface for subscribing/unsubscribing works as before, but web interface and authorisation have changed. To get access to the web interface you need to "sign up" with your email address, "reset password" will not work as technically there is no web user yet.
Hi Everyone,
I need to build a modern Nginx from sources on an older platform. The
need arises because the organization can't upgrade a particular set of
machines. We want to set up a Nginx proxy to handle the front-end
work.
I've got Bzip, zLib and OpenSSL built and installed in /opt, but I am
having trouble getting Nginx to compile and [presumably] link against
them. In this case we don't want Nginx building them from sources.
Rather, we want Nginx to use the includes in /opt/include, and the
libraries in /opt/lib.
Typically GNU software using Autotools use an option like
--with-openssl-prefix. Nginx does not provide the option. Nginx also
does not provide the customary --includedir and --libdir. (And I
understand Nginx is not GNU).
How do we tell Nginx the prefix path for the libraries?
Thanks in advance.
Before updating RPM packages
```
nginx-module-perl-1.20.2-1.el7.ngx.x86_64
nginx-1.20.2-1.el7.ngx.x86_64
nginx-module-xslt-1.20.2-1.el7.ngx.x86_64
nginx-filesystem-1.20.1-9.el7.noarch
nginx-module-njs-1.20.2+0.7.0-1.el7.ngx.x86_64
nginx-module-geoip-1.20.2-1.el7.ngx.x86_64
nginx-module-image-filter-1.20.2-1.el7.ngx.x86_64
```
After updating RPM packages
```
nginx-module-perl-1.20.2-1.el7.ngx.x86_64
nginx-1.20.2-1.el7.ngx.x86_64
nginx-module-xslt-1.20.2-1.el7.ngx.x86_64
nginx-filesystem-1.20.1-9.el7.noarch
nginx-module-geoip-1.20.2-1.el7.ngx.x86_64
nginx-module-njs-1.20.2+0.7.1-1.el7.ngx.x86_64
nginx-module-image-filter-1.20.2-1.el7.ngx.x86_64
```
After yum update is executed `nginx-module-njs` package was updated and now
nginx throws `unknown directive "js_include"` although with the previous
version (nginx-module-njs-1.20.2+0.7.0-1.el7.ngx.x86_64) it worked
Anyone knows why updating to
`nginx-module-njs-1.20.2+0.7.1-1.el7.ngx.x86_64` from
`nginx-module-njs-1.20.2+0.7.0-1.el7.ngx.x86_64` starts throwing that error.
Is this a bug in official repo
(http://nginx.org/packages/centos/$releasever/$basearch/) ?
CentOS Linux release 7.9.2009 (Core)
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,293320,293320#msg-293320
Hello,
I am using nginx on a VPS to proxy requests to a GCP server. When working
with IPv4, everything works as desired. However, if we enable IPv6 on client
machine, we see that the first call (/auth) fails with 401, and all
subsequent calls are successful. We cannot see the first call on GCP. I have
made sure that AAAA records do exist, GCP endpoint supports IPv6. This is my
configuration for Nginx (some values redacted).
server {
listen 80;
listen [::]:80;
server_name xxxxx.us www.xxxxx.us;
location / {
return 301 https://xxxxx.us$request_uri;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name xxxxx.us www.xxxxx.us;
root /var/www/xxxxx.us/html;
index index.html;
# SSL
ssl_certificate fullchain.pem;
ssl_certificate_key privkey.pem;
ssl_trusted_certificate chain.pem;
# Security
include options-ssl-nginx.conf;
ssl_dhparam ssl-dhparams.pem;
client_max_body_size 10M;
location / {
proxy_pass https://xxxxx.appspot.com/;
}
location /gcp/ {
proxy_pass https://xxxxx.appspot.com/;
}
Proxy pass /gcp/ is the one we are using for redirecting to GCP. I am always
getting the first call as 401, but second call (same), succeeds. Please let
me know if you have seen this before and what I can change to fix this.
Also, just to reiterate, if we disable IPv6 on the calling machine, there
are no issues.
Logs (two subsequent calls):
"POST /gcp/users/auth HTTP/2.0" 401 0 "http://localhost:3000/"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/96.0.4664.11
0 Safari/537.36"
"POST /gcp/users/auth HTTP/2.0" 200 606 "http://localhost:3000
/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/96.0.4664.
110 Safari/537.36"
Thanks.
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,293266,293266#msg-293266
