瞭解如何將 Nginx 配置爲Web服務器

時間 2019-12-04

原文原文鏈接

原文地址：https://lufficc.com/blog/configure-nginx-as-a-web-serverphp

閱讀以前，建議先閱讀初識 Nginx。以後，咱們來了解一下 Nginx 配置。html

抽象來講，將 Nginx 配置爲 Web 服務器就是定義處理哪些 URLS 和如何處理這些URLS 對應的請求。具體來講，就是定義一些虛擬服務器（Virtual Servers），控制具備特定 IP 和域名的請求。nginx

更具體的來講， Nginx 經過定義一系列 locations 來控制對 URIS 的選擇。每個 location 定義了對映射到本身的請求的處理場景：返回一個文件或者代理請求，或者根據不一樣的錯誤代碼返回不一樣的錯誤頁面。另外，根據 URI 的不一樣，請求也能夠被重定向到其它 server 或者 location。web

設置虛擬服務器

`listen`：

Nginx 配置文件至少包含一個 server 命令，用來定義虛擬服務器。當請求到來時， Nginx 會首先選擇一個虛擬服務器來處理該請求。正則表達式

虛擬服務器定義在 http 上下文中的 server 中：編程

http {
    server {
        # Server configuration
    }
}

注意： http 中能夠定義多個 serverapi

server 配置塊使用 listen 命令監聽本機 IP 和端口號（包括 Unix domain socket and path），支持 IPv四、IPv6，IPv6地址須要用方括號括起來：瀏覽器

server {
    listen 127.0.0.1:8080;  # IPv4地址，8080端口
    # listen [2001:3CA1:10F:1A:121B:0:0:10]:80;   # IPv6地址，80端口
    # listen [::]:80;  # 聽本機的全部IPv4與IPv6地址，80端口
    # The rest of server configuration
}

上述配置，若是不寫端口號，默認使用80端口，若是不寫 IP ，則監聽本機全部 IP。服務器

`server_name`：

若是多個 server 的 listen IP 和端口號如出一轍， Nginx 經過請求頭中的 Host 與 server_name 定義的主機名進行比較，來選擇合適的虛擬服務器處理請求：cookie

server {
    listen      80;
    server_name lufficc.com  www.lufficc.com;
    ...
}

server_name 的參數能夠爲：

完整的主機名，如：api.lufficc.com 。
含有通配符（含有 *），如：*.lufficc.com 或 api.* 。
正則表達式，以 ~ 開頭。

通配符只能在開頭或結尾，並且只能與一個 . 相鄰。www.*.example.org 和 w*.example.org均無效。可是，可使用正則表達式匹配這些名稱，例如 ~^www\..+\.example\.org$ 和 ~^w.*\.example\.org$ 。並且 * 能夠匹配多個部分。名稱 * .example.org 不只匹配 www.example.org，還匹配www.sub.example.org。
對於正則表達式：Nginx 使用的正則表達式與 Perl 編程語言（PCRE）使用的正則表達式兼容。要使用正則表達式，且必須以 ~ 開頭。

命名的正則表達式能夠捕獲變量，而後使用：

server {
    server_name   ~^(www\.)?(?<domain>.+)$;

    location / {
        root   /sites/$domain;
    }
}

小括號 () 之間匹配的內容，也能夠在後面經過 $1 來引用，$2 表示的是前面第二個 () 裏的內容。所以上述內容也可寫爲：

server {
    server_name   ~^(www\.)?(.+)$;

    location / {
        root   /sites/$2;
    }
}

一個 server_name 示例：

server {
    listen      80;
    server_name api.lufficc.com  *.lufficc.com;
    ...
}

一樣，若是多個名稱匹配 Host 頭部， Nginx 採用下列順序選擇：

完整的主機名，如 api.lufficc.com。
最長的，且以 * 開頭的通配名，如：*.lufficc.com。
最長的，且以 * 結尾的通配名，如：api.* 。
第一個匹配的正則表達式。（按照配置文件中的順序）

即優先級：api.lufficc.com > *.lufficc.com > api.* > 正則。

若是 Host 頭部不匹配任何一個 server_name ,Nginx 將請求路由到默認虛擬服務器。默認虛擬服務器是指：nginx.conf 文件中第一個 server 或者顯式用 default_server 聲明：

server {
    listen      80 default_server;
    ...
}

配置 `location`

`URI` 與 `location` 參數的匹配

當選擇好 server 以後，Nginx 會根據 URIs 選擇合適的 location 來決定代理請求或者返回文件。

location 指令接受兩種類型的參數：

前綴字符串（路徑名稱）
正則表達式

對於前綴字符串參數， URIs 必須嚴格的以它開頭。例如對於 /some/path/ 參數，能夠匹配 /some/path/document.html ，可是不匹配 /my-site/some/path，由於 /my-site/some/path 不以 /some/path/ 開頭。

location /some/path/ {
    ...
}

對於正則表達式，以 ~ 開頭表示大小寫敏感，以 ~* 開頭表示大小寫不敏感。注意路徑中的 . 要寫成 \. 。例如一個匹配以 .html 或者 .htm 結尾的 URI 的 location：

location ~ \.html? {
    ...
}

正則表達式的優先級大於前綴字符串。若是找到匹配的前綴字符串，仍繼續搜索正則表達式，但若是前綴字符串以 ^~ 開頭，則再也不檢查正則表達式。

具體的搜索匹配流程以下：

將 URI 與全部的前綴字符串進行比較。
= 修飾符代表 URI 必須與前綴字符串相等（不是開始，而是相等），若是找到，則搜索中止。
若是找到的最長前綴匹配字符串以 ^~ 開頭，則再也不搜索正則表達式是否匹配。
存儲匹配的最長前綴字符串。
測試對比 URI 與正則表達式。
找到第一個匹配的正則表達式後中止。
若是沒有正則表達式匹配，使用 4 存儲的前綴字符串對應的 location。

= 修飾符擁有最高的優先級。如網站首頁訪問頻繁，咱們能夠專門定義一個 location 來減小搜索匹配次數（由於搜索到 = 修飾的匹配的 location 將中止搜索），提升速度：

location = / {
    ...
}

靜態文件和代理

location 也定義瞭如何處理匹配的請求：返回靜態文件 或者 交給代理服務器處理。下面的例子中，第一個 location 返回 /data 目錄中的靜態文件，第二個 location 則將請求傳遞給 https://lufficc.com 域名的服務器處理：

server {
    location /images/ {
        root /data;
    }

    location / {
        proxy_pass https://lufficc.com;
    }
}

root 指令定義了靜態文件的根目錄，而且和 URI 拼接造成最終的本地文件路徑。如請求 /images/example.png，則拼接後返回本地服務器文件 /data/images/example.png 。

proxy_pass 指令將請求傳遞到 URL 指向的代理服務器。讓後未來自代理服務器的響應轉發給客戶端。在上面的示例中，全部不以 /images / 開頭的 URI 的請求都將傳遞給代理服務器處理。

好比我把 proxy_pass 設置爲 https://www.baidu.com/，那麼訪問 http://search.lufficc.com/ 將獲得百度首頁同樣的響應（頁面）（感興趣的童鞋能夠本身試一試搜索功能，和百度沒差異呢）：

server{
      listen 80;
      server_name search.lufficc.com;
      location / {
              proxy_pass https://www.baidu.com;
      }
}

使用變量（Variables）

你可使用變量來使 Nginx 在不一樣的請求下采用不一樣的處理方式。變量是在運行時計算的，用做指令的參數。變量由 $ 開頭的符號表示。變量基於 Nginx 的狀態定義信息，例如當前處理的請求的屬性。

有不少預約義變量，例如核心的 HTTP 變量，你也可使用 set，map 和 geo 指令定義自定義變量。大多數變量在運行時計算，幷包含與特定請求相關的信息。例如，$remote_addr 包含客戶端 IP 地址，$uri 保存當前URI值。

一些經常使用的變量以下：

變量名稱	做用
`$uri`	請求中的當前URI(不帶請求參數)，它能夠經過內部重定向，或者使用index指令進行修改，`$uri`不包含主機名,如 `/foo/bar.html`。
`$arg_name`	請求中的的參數名，即「?」後面的`arg_name=arg_value`形式的`arg_name`
`$hostname`	主機名
`$args`	請求中的參數值
`$query_string`	同 `$args`
`$request`	表明客戶端的請求地址
`$request_uri`	這個變量等於包含一些客戶端請求參數的原始URI，它沒法修改，不包含主機名，如：`/cnphp/test.php?arg=freemouse`。
...	...

一個簡單的應用就是從 http 重定向到 https 時帶上路徑信息：

server{
       ...
       return      301 https://lufficc.com$request_uri;
       ...
}

返回特定狀態碼

若是你的網站上的一些資源永久移除了，最快最簡潔的方法就是使用 return 指令直接返回：

location /wrong/url {
    return 404;
}

return 的第一個參數是響應代碼。可選的第二個參數能夠是重定向（對應於代碼301，302，303和307）的 URL 或在響應正文中返回的文本。例如：

location /permanently/moved/url {
    return 301 http://www.example.com/moved/here;
}

return 指令能夠包含在 location 和 server 上下文中：

server{
      location / {
              return 404;
      }
}

或者：

server{
      ...
      return 404;
      location / {
          ...            
      }
}

錯誤處理

error_page 命令能夠配置特定錯誤碼的錯誤頁面，或者重定向到其餘的頁面。下面的示例將在 404 錯誤發生時返回 /404.html 頁面。

error_page 404 /404.html;

error_page 命令定義瞭如何處理錯誤，所以不會直接返回，而 return 確實會當即返回。當代理服務器或者 Nginx 處理時產生相應的錯誤的代碼，均會返回相應的錯誤頁面。

在下面的示例中，當 Nginx 找不到頁面時，它將使用代碼301替換代碼404，並將客戶端重定向到 http://example.com/new/path.html 。此配置頗有用，好比當客戶端仍嘗試用舊的 URI 訪問頁面時，301代碼通知瀏覽器頁面已永久移除，而且須要自動替換爲返回的新地址。

location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}

重寫 `URI`s

rewrite 指令能夠屢次修改請求的 URI。rewrite 的第一個參數是 URI須要匹配的正則表達式，第二個參數是將要替換的 URI。第三個參數可選，指示是否繼續能夠重寫或者返回重定向代碼（301或302）。例如：

location /users/ {
    rewrite ^/users/(.*)$ /show?user=$1 break;
}

您能夠在 server 和 location 上下文中包括多個 rewrite 指令。 Nginx 按照它們發生的順序一個一個地執行指令。當選擇 server 時，server 中的 rewrite 指令將執行一次。

在 Nginx 處理一組 rewrite 指令以後，它根據新的 URI 選擇 location 。若是所選 location仍舊包含 rewrite 指令，它們將依次執行。若是 URI 匹配全部，則在處理完全部定義的 rewrite 指令後，搜索新的 location 。

如下示例將 rewrite 指令與 return 指令結合使用：

server {
    ...
    rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra  last;
    return  403;
    ...
}

諸如 /download/some/media/file 的 URI 被改成 /download/some/mp3/file.mp3 。因爲 last 標誌，後續指令（第二個 rewrite 指令和 return 指令）被跳過，但 Nginx 繼續以更改後的 URI 處理請求。相似地，諸如 /download/some/audio/file 的 URI 被替換爲 /download/some/mp3/file.ra。若是 URI 不匹配 rewrite 指令，Nginx 將403 錯誤代碼返回給客戶端。

last 與 break的區別是：

last ：在當前 server 或 location 上下文中中止執行 rewrite 指令，可是 Nginx 繼續搜索與重寫的URI匹配的 location，並應用新 location 中的任何 rewrite 指令（這意味着 URI 可能再次改變）。
break ：中止當前上下文中 rewrite 指令的處理，並取消搜索與新 URI 匹配的 location。不會執行新 location中的 rewrite 指令。

附錄

經常使用正則

. ：匹配除換行符之外的任意字符
? ：重複0次或1次
+ ：重複1次或更屢次
*：重複0次或更屢次
\d ：匹配數字
^ ：匹配字符串的開始
$ ：匹配字符串的介紹
{n} ：重複n次
{n,} ：重複n次或更屢次
[c] ：匹配單個字符c
[a-z]：匹配a-z小寫字母的任意一個

全局變量

$args ： #這個變量等於請求行中的參數，同$query_string
$content_length ：請求頭中的Content-length字段。
$content_type ：請求頭中的Content-Type字段。
$document_root ：當前請求在root指令中指定的值。
$host ：請求主機頭字段，不然爲服務器名稱。
$http_user_agent ：客戶端agent信息
$http_cookie ：客戶端cookie信息
$limit_rate ：這個變量能夠限制鏈接速率。
$request_method ：客戶端請求的動做，一般爲GET或POST。
$remote_addr ：客戶端的IP地址。
$remote_port ：客戶端的端口。
$remote_user ：已經通過Auth Basic Module驗證的用戶名。
$request_filename ：當前請求的文件路徑，由root或alias指令與URI請求生成。
$scheme ： HTTP方法（如http，https）。
$server_protocol ：請求使用的協議，一般是HTTP/1.0或HTTP/1.1。
$server_addr ：服務器地址，在完成一次系統調用後能夠肯定這個值。
$server_name ：服務器名稱。
$server_port ：請求到達服務器的端口號。
$request_uri ：包含請求參數的原始URI，不包含主機名，如：/foo/bar.php?arg=baz。
$uri ：不帶請求參數的當前URI，$uri不包含主機名，如/foo/bar.html。
$document_uri ：與$uri相同。

例如請求：http://localhost:88/test1/test2/test.php
$host：localhost
$server_port：88
$request_uri：http://localhost:88/test1/test2/test.php
$document_uri：/test1/test2/test.php
$document_root：/var/www/html
$request_filename：/var/www/html/test1/test2/test.php