Make nginx always return gzip content

Generally, whether gzip compression is enabled must be supported by clients in addition to server support. When the client sends the requestheader "Accept-Encoding: gzip", the server determines that it can Accept gzip compression and then responds to a Content-Encoding: gzip file and sends the compressed Content; if the client does not send Accept-Encoding, then the server

In general, gZipCompressionWhether to enable or not. In addition to server support, the client also needs support. When the client sends an Accept-ENcOding:GzipThis request header, the server thinks it can Accept gzip compression, responds to a Content-Encoding: gzip, and sends the compressed Content; if the client does not send Accept-Encoding, then the server will print out the source code honestly.

But here is a strange idea. Can the server send compressed content whether the client sends Accept-Encoding or not?

There are several advantages:

1. Further save bandwidth.
2. Prevent horizontal crawlers from capturing pages and stealing data.

It has been tested that this method does not affect normal users, because they all use advanced browsers to access the Internet. In addition, it does not affect mainstream search engines, and indexing will still be normal.

To do this, you need two nginx instances, but you can configure two virtual hosts without starting two main nginx processes. For convenience, I used to differentiate them later.

Front-end nginx:

Gzip compression is not performed on the front-end nginx. The front-end is mainly used to forcibly modify the request header, that is, to write:

1. proxy _Set_ Header Accept-Encoding 'gzip ';

In this way, nginx in the background will receive the Accept-Encoding: gzip regardless of whether the client sends the Accept-Encoding.

Complete test sample:

1. upsTrWww. backend.SuDone.com {
2. server 127.0.0.1: 80;
3 .}
4. server {
5. server_name www.sudone.com;
6. listen 80;
7.

8. loCatIon /{
9. proxy_pass http://www.backend.sudone.com;
10. include proxy. conf;
11. proxy_set_header Accept-Encoding 'gzip ';
12 .}
13 .}

Note that the upstream from proxy_pass is www.backend.sudone.com. This is required to configure two virtual hosts on one machine. Otherwise, it is not an endless loop? If you still want to use www.sudone.com, you can change the front-end listen to an Internet ip address, and the back-end will use 127.0.0.1.

Note that proxy_set_header Accept-Encoding is not recommended in proxy. conf. By default, my proxy. conf sets Accept-Encoding to null, which leads to repeated configurations. However, the proxy_set_header does not conflict with each other. It can take effect in the configuration order. I forgot whether it was effective before or after the change. I will know it after testing.

Backend nginx:

The backend nginx is responsible for compression. Here we should pay attention to the gzip version. Because nginx uses http1.0 as the proxy, the gzip version cannot be the default version 1.1, but changed to 1.0.

1. server {
2. server_name www.backend.sudone.com;
3. listen 80;
4.

5. location /{
6. root/html /;
7. gzip on;
8. gzip_http_version 1.0;
9 .}
10 .}

This is simple. I will not post other gzip parameters. You must have ready-made configurations. Just pay attention to the version.

After the configuration, test:

1. curl-I http://www.sudone.com

Content-Encoding: gzip is returned.

What about the-I parameter?

1. curl http://www.sudone.com

Print out a bunch of garbled characters and break all the characters of SecureCRT.

Author: Ayou