I want to note that setting the default site to listen is not the behavior I want either. When I do this, then requests to other sites just hit the default site (which is an empty site). Basically, the behavior I want is that if I have define IPv6 to listen on a site then that site should be the destination. However, if I haven't defined IPv6 to listen on a site, then I still want the requestby bengalih - How to...
I just setup IPv6 on my network. I have a single A record for server.mydomain.com with about 10 CNAMEs referencing specific services proxied by NGINX. NGINX defines each of these with a server_name directive in the appropriate SERVER block along with the listen directives. I just added my AAAA for the server.mydomain.com as well so I can find the IPv6 address. I modified one of these configuby bengalih - How to...
> Note that SSL is likely the most important contributor to CPU > utilization in this setup. It might be a good idea to carefully > tune ciphers used. I believe I have set this fairly appropriately. If you know of a resource that would explain this in more detail I would appreciate it. > To re-iterate what was already written in the previous message: > nginx opens a teby bengalih - Nginx Mailing List - English
Thank you for the response Maxim. Unfortunately, while it reinforces what my understanding is from the documentation, it doesn't allow me to reconcile what I am seeing or help me understand how to tune properly. Let me explain what I am seeing now based upon your explanation. (N.B.: In my initial post I was experiencing the issue with my backend IIS server pointing its virtual directory tby bengalih - Nginx Mailing List - English
I had/have an issue where I am proxying from NGINX to a backend WebDAV server. My upload speeds were slow and had long pauses in them including very long pauses at the end (5 minutes or more on uploads around 1GB). Via packet captures I found that the NGINX server was not transmitting data synchronously to the backend WebDAV server, but was clearly doing buffering despite the fact I had set &qby bengalih - Nginx Mailing List - English
Yes, it is solved with the proper cert configuration. I hadn't fully validated some advanced SSL options like OCSP stapling as I was first trying to get all the basics working. Since my browsers all validated the certificate chain without issue, I had assumed they were installed properly. I've had the issue with including the full chain (or at least the intermediate) in the cert file before wby bengalih - Nginx Mailing List - English
Figured it out! https://www.reddit.com/r/nginx/comments/eodrjc/nginx_stripping_websocket_upgrade_headers/ fireye quote: ---------------------------------------- Got it figured out, this is a quirk of HTTP/2.0 vs 1.1. Per RFC-2616: The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol. It looks like nginx dby bengalih - Nginx Mailing List - English
I have the following in my site.conf file: ------------------------------------------------------------ #Websockets proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; ------------------------------------------------------------ My understanding is that this will set the proper headers for websoby bengalih - Nginx Mailing List - English