nginx（二）：進階配置介紹--rewrite用法，壓縮，https虛擬主機等

時間  2019-12-05
標籤 nginx 進階 配置 介紹 rewrite 用法 壓縮 https 虛擬 主機 欄目 Nginx 简体版
原文   原文鏈接

一、nginx基本狀態信息頁面

配置示例：javascript

location  /basic_status {
                            stub_status;
                        }

頁面展現含義：php

Active connections: 291 
server accepts handled requests
    16630948 16630948 31070465 
Reading: 6 Writing: 179 Waiting: 106     

Active connections: 活動狀態的鏈接數；
accepts：已經接受的客戶端請求的總數；
handled：已經處理完成的客戶端請求的總數；
requests：客戶端發來的總的請求數；
Reading：處於讀取客戶端請求報文首部的鏈接的鏈接數；
Writing：處於向客戶端發送響應報文過程當中的鏈接數；
Waiting：處於等待客戶端發出請求的空閒鏈接數；

二、記錄請求日誌

指令：css

  1. log_format
    做用域: http
  2. access_log
    做用域: http, server, location, if in location, limit_except
  3. open_log_file_cache
    做用域: http, server, location

2.1 log_format

在http區域定製日誌格式
用法：log_format name string ...;
name指定一個格式名稱，string可使用nginx核心模塊及其它模塊內嵌的變量指定格式。html

2.2 access_log

可在每一個server中，或location中指定一個日誌存放路徑
用法：前端

access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log off;

指定日誌存放路徑path，格式format，緩衝區大小buffer，也可啓用壓縮日誌，指定壓縮級別gzipjava

2.3 open_log_file_cache

定義一個緩存保存活躍的日誌文件描述符數據
用法：nginx

open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
open_log_file_cache off;

max：緩存的最大文件描述符數量；
min_users：在inactive指定的時長內訪問大於等於此值方可被看成活動項；
inactive：非活動時長；
valid：驗證緩存中各緩存項是否爲活動項的時間間隔；
配置示例：web

log_format combined '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $bytes_sent '
                       '"$http_referer" "$http_user_agent" "$gzip_ratio"';

access_log /var/logs/nginx-access.log combined buffer=32k;
open_log_file_cache max=1000 inactive=20s valid=1m min_uses=2;

三、rewrite重寫

將用戶請求的URI基於regex所描述的模式進行檢查，然後完成替換；
URL重寫是一個很是有用的功能，若是一個網站在改進的過程當中結構發生變化，無需客戶端更改已保存訪問地址仍可正常訪問；提高網站安全性，如放盜鏈行爲。正則表達式

3.1 rewrite

syntax: rewrite regex replacement [flag]
Context:    server, location, if

將用戶請求的URI基於regex所描述的模式匹配檢查，匹配到時將其替換成replacement指定的新URI；
rewrite指令在同一級配置塊中存在多條rewrite規則，會按照順序自上而下逐一執行；被某一規則替換完成後，從新開始新一輪檢查，所以自己具備循環機制，flag所表示的標誌位可控制循環機制；若是replacement是以http://或其餘協議開頭的字符串，則直接以重定向方式返回給客戶端；
另外，rewrite指令接收到的URI是不包含host地址的，例如http://cutemsyu.com/articles/...，不包含"cutemsyu.com" ，在寫regex規則時應當注意。後端

[flag] 可用標識以下：

  • last：中止在當前區域繼續處理，將重寫的新URI在各location中從新處理；
  • break：將此處重寫的URI在本塊中繼續處理，但新的URI不會轉向其餘location中處理；
  • redirect：將重寫的URI直接返回給客戶端，狀態代碼爲302，表示臨時重定向。用在replacement不以"http://"或"https://"開頭的狀況下；
  • permanent：將重寫的URI直接返回給客戶端，狀態碼爲301，指明爲永久重定向。

Example：

#flag 是last的一個例子
server {
    ...
    rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra  last;
    return  403;
    ...
}

#若是上面的rewrite規則寫在location中，則應該使用break標識，防止死循環，若是循環超過10此，返回500錯誤碼
location /download/ {
    rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 break;
    rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra  break;
    return  403;
}

3.2 return

syntax: return code [text];
        return code URL;
        return URL;
context: server, location, if

中止處理並返回一個狀態碼給客戶端。

3.3 if 指令

syntax: if (condition) { ... }
context: server, location

引入一個新的配置上下文，知足條件時執行配置塊中的指令
condition爲判斷條件，支持三種設置方法：

  • 變量名，若是變量值爲空字符串或者以0開頭的任意字符串，則表示條件爲false
  • 使用比較符判斷變量與字符串的邏輯關係
  • 判斷文件或目錄存在狀況

其中 比較操做符有：

  • =
  • !=
  • ~ 模式匹配，區分字符大小寫
  • ~* 模式匹配，不區分字符大小寫
  • !~：模式不匹配，區分字符大小寫
  • !~*：模式不匹配，不區分字符大小寫

文件及目錄存在性判斷：

  • -e, !-e 檢查一個文件，目錄，或軟連接是否存在
  • -f, !-f 檢查一個文件是否存在
  • -d, !-d 檢查一個目錄是否存在
  • -x, !-x 檢查一個文件是否可執行

Example：

if ($http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /msie/$1 break;
}

if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
    set $id $1;  
}

if ($request_method = POST) {
    return 405;
}

if ($slow) {
    limit_rate 10k;
}

if ($invalid_referer) {
    return 403;
}

3.4 rewrite的應用

3.4.1 域名跳轉

Example：

#訪問video.cutemsyu.com 跳轉至v.cutemsyu.com
server {
    listen 80;
    server_name video.cutemsyu.com;
    rewrite ^(.*) http://v.cutemsyu.com$1 ;
    ...
}

3.4.2 rewrite uri中參數

默認狀況下nginx進行rewrite後都會自動添加舊地址中參數部分,在replacement末尾添加"?"便可屏蔽舊地址中的參數
Example:

##原來的訪問的url爲http://cutemsyu.com/article/nature/index.php?id=22341
   rewrite ^/article/nature/(.*) http://cutemsyu.com/article/natrue.html permanent
   重寫以後訪問的URL爲http://cutemsyu.com/article/nature.html?id=22341
   也就是說原有的參數部分它會自動補上
   rewrite ^/article/nature/(.*) http://cutemsyu.com/article/natrue.html? permanent
   重寫以後的URL爲http://cutemsyu.com/article/nature.html,沒有原來的參數部分

3.4.3 防盜鏈

一般爲了加快客戶端訪問資源響應時間，服務器不會一次性將所有資源響應給客戶端，首先傳回網頁的文本內容，當客戶端解析文本內容中的圖片、視頻等資源時會再次向服務器發起請求。當某個站點將圖片連接指向其餘服務器，給其餘服務器形成負擔，這就是非法的盜鏈行爲。咱們在搭建服務站點時要有意識防範盜鏈行爲。
http協議頭部中referer頭域表示訪問當前資源的源地址，根據referer中的源地址URL來判斷是否來自本站，如非本站的地址，採起阻斷措施防止盜鏈。

syntax: valid_referers none | blocked | server_names | string ...;
context: server,location;

valid_referers 指令根據規則檢測頭域中referer中值是否合法，若是非法內嵌變量 $invalid_referer 值爲1.
參數含義：

  • none，表示檢測referer爲空的狀況
  • blocked，表示檢測referer的值被防火牆或者代理服務器刪除的狀況，一般referer的值不以http://或https:// 開頭
  • server_names，referer的值應該被包含在server_name中

  • string，定義字符串形式。

    1. 開始或尾部帶有通配符*
    2. 正則表達式，以~引導，匹配http://後面的內容

Example：

#若是發現盜鏈，重寫連接爲指定的表示禁止盜用的圖片
server {
    listen 80;
    server_name v.cutemsyu.com;
    location ~* ^.+\.(gif|jpg|png|flv|mp4|swf)$ {
        valid_referers none blocked server_names *.cutemsyu.com ~\.google\.
        if ($invalid_referer) {
            rewrite ^/ http://v.cutemsyu.com/images/forbbiden.jpg
        }
    }
}

四、gzip壓縮

壓縮文本數據，提高網絡響應速度，做爲靜態服務器使用頗有必要開啓，壓縮文本將節省大量帶寬，同時提高響應速度。可是若是做爲反向代理服務器則須要考慮，壓縮功能是否應該由後端服務器承擔，以此減輕前端服務器CPU壓力。

4.1 ngx_http_gzip_module

該模塊功能是對指定類型數據使用gzip方法壓縮
做用域Context: http, server, location

  1. gzip on |off;

此模塊gzip功能啓用或禁用

  1. gzip_types mime-types ... ;

壓縮過濾器，僅對指定的MIME類型進行壓縮處理

  1. gzip_comp_level level;

設置壓縮級別1-9，默認值爲1壓縮速率最快，壓縮比最低

  1. gzip_min_length length;

啓用壓縮功能的響應報文大小閾值，小於該置不進行壓縮。防止有些小數據壓縮以後更大的狀況，推薦值爲1024

  1. gzip_buffers number size;

壓縮數據使用緩衝區大小，size默認爲內存分頁大小

  1. gzip_disable regex;

舊版本的瀏覽器對於gzip功能支持不完善，對於該指令配置的正則信息與瀏覽器類型匹配，匹配成功的響應不進行壓縮處理

  1. gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any ...;

nginx做爲反向代理服務器接收後端服務器響應結果壓縮控制

4.2 ngx_http_gunzip_module

解壓模塊，該模塊對於不支持壓縮功能的瀏覽器請求，響應結果若是被壓縮則將其解壓後返回給客戶端。適用於某些以gzip方式壓縮過存儲的數據。
做用域Context: http, server, location
提示該模塊不是默認編譯內容，編譯選項--with-http_gunzip_module

  1. gunzip on |off ;
    是否開啓該模塊功能

    1. gunzip buffers number size;

用於解壓數據使用的緩衝區空間配置

4.3 ngx_http_gzip_static_module

靜態壓縮模塊，該模塊容許發送預壓縮數據，若是客戶端請求的數據已被壓縮過，且客戶端支持gzip壓縮，則直接返回壓縮數據。
做用域Context: http, server, location
提示該模塊不是默認編譯內容，編譯選項--with-http_gzip_static_module

  1. gzip_static on | off ;
    是否開啓該模塊
  2. gzip_disable regex;
    對於適配瀏覽器類型禁止gzip功能

4.4 配置示例

gzip on;
gzip_comp_level 3;
gzip_types text/html text/css text/xml text/plain application/javascript;
gzip_min_length 1024;
gzip_disable "MISE [4-6]\.";
gzip_buffers 8 16K;
gunzip on;         #支持自動解壓功能

五、ssl模塊

HTTP協議屬於明文協議，經過抓包就可獲取一些隱私數據。HTTPS經由超文本傳輸協議HTTP通訊，可是數據包由SSL/TLS 安全協議加密，實現加密數據與認證功能。
ngx_http_ssl_module 該模塊指令定義https相關設置：證書文件，私鑰文件，ssl會話緩存等內容。
做用域Context: http, server

5.1 指令介紹

1. ssl on | off;
 設定虛擬主機是否啓用HTTPS協議
 2. ssl_certificate file;
 指定當前虛擬主機使用的PEM格式的證書文件
 3. ssl_certificate_key file;
 指定當前虛擬主機上與其證書相匹配的私鑰文件
 4. ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
 支持ssl協議版本，默認爲後三個
 5. ssl_session_cache off | none | [builtin[:size]] [ shared:name:size ];
 ssl會話緩存設置。
 builtin[:size] --使用OpenSSL內建的緩存，此緩存爲每worker私有。容易產生內存碎片不推薦。
 shared:name:size --worker之間共享的緩存區域，size單位爲bytes，1MB可存儲4000個會話；name爲共享緩存區域名稱，多個虛擬主機可以使用同一個共享緩存區。
 6. ssl_session_timeout time;
 客戶端可重複使用會話參數的超時時長。默認5分鐘

Example：

server {
                listen 443 ssl;
                server_name www.cutemsyu.com;
                root /website/ssl/htdocs;
                ssl on;
                ssl_certificate /etc/nginx/ssl/nginx.crt;
                ssl_certificate_key /etc/nginx/ssl/nginx.key;
                ssl_session_cache shared:sslcache:15m;
                ssl_session_timeout 3m;
            }

5.2 基於域名的HTTPS虛擬主機

值得考慮的一個問題是如何實現多個HTTPS虛擬主機監聽在同一IP地址上。
狀況一：每一個虛擬主機使用各自的證書文件，以下

server {
    listen          443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

如此配置的話，客戶端訪問這兩個站點創建SSL會話時收到的都是默認主機的證書文件。該問題是因爲SSL協議形成的，SSL連接在客戶端發送HTTP請求以前創建起來的，然而nginx並不知道所請求的服務主機名，所以返回默認服務器證書文件。
解決方法一：
多個HTTPS虛擬主機使用同一證書文件和私鑰文件，證書和私鑰配置指令在http級別設定，server共享其配置

ssl_certificate     common.crt;
ssl_certificate_key common.key;

server {
    listen          443 ssl;
    server_name     www.example.com;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ...
}

解決辦法二：
更通用的辦法是使用TLS Server Name Indication extension技術，即SNI。SNI容許在客戶端創建SSL會話時傳遞請求服務器名稱，這樣服務器就會知道該發送哪一個虛擬主機下的證書文件。該技術須要瀏覽器支持，通常主流瀏覽器都已支持

  • Opera 8.0;
  • MSIE 7.0 (but only on Windows Vista or higher);
  • Firefox 2.0 and other browsers using Mozilla Platform rv:1.8.1;
  • Safari 3.2.1 (Windows version supports SNI on Vista or higher);
  • and Chrome (Windows version supports SNI on Vista or higher, too)

同時確保nginx支持SNI功能：

$ nginx -V
...
TLS SNI support enabled
...

本篇文章到此結束，下篇總結nginx反向代理，fastcgi模塊，感謝關注！

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程