I was having trouble with supervisord being unable to start nginx on a new dev vm I had setup. In the supervisor stderr log for nginx and nginx’s error.log I was getting:
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/nginx-1.9.12/conf/nginx.conf ... nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)
I had a problem recently where Nginx wasn’t gzipping responses, despite having the necessary lines in my nginx.conf. In looking for a solution, I found quite a few posts covering various reasons why gzip might not be working. But none that fitted my case.
So, I thought I might as well share what the problem / solution was in my case, plus the other reasons why Nginx may not be gzipping files. Hopefully this will be helpful to anyone else trying to figure out why their Nginx gzip configuration isn’t working.
As part of the gzip configuration, you need to specify what mime types should be gzipped.
gzip_types text/css text/javascript text/xml text/plain;
If you had something like above, but your javascript was actually served with a mime type of application/javascript, then it wouldn’t be gzipped because application/javascript is not listed in the mime types you want gzipped.
So the solution here is just to ensure you include all mime types you want gzipped after the gzip_types directive.
Normally, as part of gzip configuration you will include a minimum size that the response must be for it to get gzipped. (There’s little benefit in gzipping already very small files).
gzip_min_length 1100;
It can be easy to forget this and think that gzip isn’t working, when actually it is working, it’s just that you’re checking with a small file that shouldn’t be gzipped.
This was what the problem was in my case. By default, Nginx will only gzip responses where the HTTP version being used is 1.1 or greater. This will be the case for nearly all browsers, but the problem comes when you have a proxy in front of your Nginx instance.
In my case, my webhost uses Nginx, which then proxies requests to my Nginx instance. And I’ve mirrored this setup in my development environment. The problem is that by default Nginx will proxy requests using HTTP1.0.
So the browser was sending the request using HTTP1.1, the frontend Nginx was receiving the request, then proxying it to my backend Nginx using HTTP1.0. My backend Nginx saw the HTTP version didn’t match the minimum gzip default of 1.1 and so sent back the response unzipped.
In this case you either need to update the proxy_http_version directive of the proxying server to use 1.1. Or you need to set the gzip_http_version to 1.0 in your config.
I think this is likely to be a rather unusual situation, but I found it described here: nginx gzip enabled but not not gzipping. Basically they had some security software installed on the client machine they were testing from. This software was deflating and inspecting all requests before they were sent on to the browser.
The same thing could happen if there was a proxy between you and the server that deflates any gzipped responses before sending them on to you. But I think it would be very rare to have proxy configured like that.
There could also be other reasons why Nginx might not be gzipping responses. For example, it could be you’re using a gzip_disable directive that matches. Or you have gzip off; somewhere later in your config. But I think the items above are likely to be the main reasons why Nginx isn’t (or looks like it isn’t) gzipping files when it should be.
WordPress Multisite with the domain mapping plugin is a good way to run multiple wordpress sites. It means you don’t have to worry about keeping WordPress and plugins up to date for each individual site.
The W3 Total Cache plugin is one of the most popular wordpress plugins for speeding up wordpess websites. One of the things it offers is serving static content from a CDN (Content Delivery Network). You don’t have to use a real CDN, but can instead a generic mirror CDN.
A generic mirror CDN doesn’t have all the benefits of a real CDN. However, because you use a different domain (or subdomain) for the CDN address, it does solve the problem of cookies being sent for static content requests. And unlike a real CDN, you don’t need to pay anything extra for it.