I am using nginx for the first time and have some confusions regarding configurations. I have a nginx as load balancer and backends as nginx as well. With my understanding I have configured mod_security module on the load balancer as its the entry point. I have also added required response headers on the load balancer. Now I have to enable the gzip for nginx. Confusion is where it should be configured? Load balancer or the backend nginx servers?
You can configure gzip globally in /etc/nginx/nginx.conf or just for one site in e.g. /etc/nginx/sites-available/your-site.
The configuration could like this:
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
It depends.
For dynamic gzipping (e.g. HTML output of your site/app)
If your load balancer is a powerful machine, then you may want to do gzip on the load balancer, in order to reduce CPU usage elsewhere.
If you have some modsecurity rules that require inspecting the response body, and gzipping is done in the nodes, then that would mean that modsecurity needs to ungzip backend response/inspect/re-gzip (and thus cause processing overhead) or those rules would simply not work. That's another case when you want to gzip in load balancer.
In all other cases, I assume gzipping on the nodes would be better.
For static files
.. it's best to rely on static gzip (pre-compress your assets). However, since you have many backends, it means pre-compressing assets on each.
If your backends are different websites/apps (that means, you're not doing actual load balancing), it's not an issue.
If your backends are actual nodes of the same app, then you can do max gzip on each node, and "proxy cache" results on the load balancer.
Related
I have nginx acting as reverse-proxy for an ASP.net / Kestrel back-end server.
I'd like nginx to do gzip compression (ie, permessage-deflate / rfc7692) for my Websocket connections, but I can't find any config options for that.
Can nginx do that? Are there any plugins to make it work? If no, is there something else I can use?
just edit your nginx config. It is the same for static sites, proxies or websockets
gunzip on; // be sure to include this. This enables runtime decompression for clients that do not accept gzip
gzip on; //enables gzip for request
gzip_proxied any; //enables compression on proxies
gzip_types *; //compress everything there is
if this does not work, try compressing the messages befor sending them through the socket.
You can read more about it here: https://docs.nginx.com/nginx/admin-guide/web-server/compression/
I have 5 micro-services that are up and running. One of them is an nginx server that acts as a gateway( reverse proxy for other services). There is another service called 'web' that is an nginx server that serves all the client side static bundles. I have enabled gzipping in the web nginx server. But when the compressed response comes through the gateway nginx server, it decompresses the files and sends them back to the client. I tried setting gzip off and gunzip off in gateway nginx server but it is not working.
Here is the configuration of the web-nginx server:
gzip on;
gzip_comp_level 3;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_min_length 100;
gzip_buffers 4 32k;
Here is the configuration for the gateway ngnix server:
gzip off;
gunzip off;
Any kind of help is appreciated.
You need to add gzip_proxied any; to the backend nginx servers (serving static files)
Compress data even for clients that are connecting to us via proxies,
identified by the "Via" header (required for CloudFront/Cloudflare).
The default value is off which disables compression for all proxied requests, ignoring other parameters; For more info checkout the nginx docs
I found the mistake that, i failed to forward the header using proxy_pass from proxy server to actual server. With help of above answer. it worked.
I want to enable gzip compression on my virtual host with nginx. My control panel is Plesk17 but I have access to server root. I found the vhost nginx config file in this dir:
/etc/nginx/plesk.conf.d/vhosts
and add this codes in server block to enable gzip:
gzip on;
gzip_disable msie6;
gzip_proxied any;
gzip_buffers 16 8k;
gzip_types text/plain application/javascript application/x-javascript text/javascript text/xml text/css;
gzip_vary on;
After all and restarting the nginx, when I check the gzip status, it looks disabled!
For your information, I also have this comments at the top of my config file:
#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.
What's wrong? how can I enable the gzip?
To enable gzip compression for particular domain open Domains > example.com > Apache & nginx Settings > Additional nginx directives and add directives to this section.
If you want to enable it server-wide just create new file /etc/nginx/conf.d/gzip.conf add content there and restart nginx.
If I understand correctly it's better not to gzip small resources as they might actually get bigger while still having a performance hit on the CPU.
So using the gzip_min_length directive is an obvious solution to that.
However, when trying this on a server that runs a REST API I'm working on this doesn't seem to work.
When I receive an empty json response, or a very small one, the Content-Encoding header is still present and reading "gzip".
HTTP Response headers
My question is why this setting is not being respected by NginX and what can I do to fix it?
The API is built on the Lumen microframework.
I have attached the Gzip setting I'm using in my nginx.conf:
# Compression
# Enable Gzip compressed.
gzip on;
# Enable compression both for HTTP/1.0 and HTTP/1.1.
gzip_http_version 1.1;
# Compression level (1-9).
# 5 is a perfect compromise between size and cpu usage, offering about
# 75% reduction for most ascii files (almost identical to level 9).
gzip_comp_level 5;
# Don't compress anything that's already small and unlikely to shrink much
# if at all (the default is 20 bytes, which is bad as that usually leads to
# larger files after gzipping).
gzip_min_length 1000;
# Compress data even for clients that are connecting to us via proxies,
# identified by the "Via" header (required for CloudFront).
gzip_proxied any;
# Tell proxies to cache both the gzipped and regular version of a resource
# whenever the client's Accept-Encoding capabilities header varies;
# Avoids the issue where a non-gzip capable client (which is extremely rare
# today) would display gibberish if their proxy gave them the gzipped version.
gzip_vary on;
# Compress all output labeled with one of the following MIME-types.
gzip_types
application/atom+xml
application/javascript
application/json
application/rss+xml
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/svg+xml
image/x-icon
text/css
text/plain
text/x-component;
# text/html is always compressed by HttpGzipModule
Confirming my note above, this does seem to correspond to the note in the NGINX gzip module documentation stating "The length is determined only from the “Content-Length” response header field."
With gzip_min_length 1000;, my JSON responses were being gzip'ed, even if they were only 100 bytes.
I changed my application to add the Content-Length: 100 header and NGINX sends the JSON response without using the gzip encoding.
If I change the configuration to gzip_min_length 80; with the same 100-byte Content-Length, then NGINX applies the gzip encoding as expected.
Short story: you need to apply the Content-Length header for NGINX to properly handle the gzip_min_length check.
I'm trying to improve page speed on a site and using "Yslow" and "Page Speed" to monitor the speeds. I am being told by both to "compress components with gzip" and given a listing of a number of CSS and JavaScript files, for example
/css/styles.css?v=6.5.5
/jquery.flexslider.js
/4878.js
/6610.js
/homepage.css?v=6.5.5
Our hosting have informed us that nginx is doing the gzip compression on ALL assets, even if it reverse proxies back to Apache and the folllowing values from the nginx site-enable files, which is enabled at a virtual host level, confirms this:
gzip on;
gzip_disable msie6;
gzip_static on;
gzip_comp_level 9;
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
Is there a reason these tools are not picking up by the compression or is it in fact they are not being compressed at all and we need to get our hosting to add something extra?
your hosting provider claims that the requests leave nginx compressed that leaves as potential problem causes:
there's a proxy/cache/virusscanner somewhere on the network path between the nginx server and your client that strips out the compression.
your browser saves an uncompressed version of the asset, and yslow/pagespeed ends up using that (if so make sure you trying it with an empty browser-cache should fix it)
you're hosting provider's claim is false (but the posted config bit seems ok to me )
the problem could be a proxy or cache inbetween the nginx server and your browser that strips out the compression.
Some things to try:
Try checking the url's with on online checker for gzip like http://www.whatsmyip.org/http-compression-test/ or http://www.dnsqueries.com/en/check_http_gzip.php
check locally what the result of curl --compressed --head <your-asset-url> is (you should see a Content-Type: gzip if the response coming in is compressed)