Nginx 配置檔案備忘

dailybird發表於2017-05-02

以下備忘 Nginx 中基礎配置的含義。

nginx.conf

/etc/nginx 中可以找到 nginx.conf 配置檔案,其配置及註釋如下:

# 執行 Nginx worker 程式的使用者群組為 nginx
user  nginx;

# 工作程式的數量,一般與 CPU 的核數相關
worker_processes  1;

# 錯誤日誌的目錄。最後一項為錯誤日誌的級別
error_log  /var/log/nginx/error.log warn;

# 儲存主程式的程式 id 的位置
pid        /var/run/nginx.pid;

# 設定一個工作程式可以連線的數量
events {
    worker_connections  1024;
}


http {
    # ...
}

有關錯誤日誌的級別可以參考:「Nginx error_log 錯誤日誌級別」。

http 模組

nginx.conf 中包含一個重要模組,其配置及註釋如下:

# --- nginx.conf ----

# 其他配置

http {
    # 這個檔案告訴瀏覽器檔案所屬的型別
    include       /etc/nginx/mime.types;
    
    # 設定了預設的型別(預設為二進位制)
    default_type  application/octet-stream;

    # 設定日誌記錄的一種格式,main 為名字
    log_format  main  `$remote_addr - $remote_user [$time_local] "$request" `
                      `$status $body_bytes_sent "$http_referer" `
                      `"$http_user_agent" "$http_x_forwarded_for"`;

    # 設定訪問日誌的位置
    access_log  /var/log/nginx/access.log  main;

    # 是否使用這種方法傳輸資料
    sendfile        on;
    #tcp_nopush     on;

    # keepalive 長連線延時
    keepalive_timeout  65;

    #gzip  on;

    # 包含的額外配置位置
    include /etc/nginx/conf.d/*.conf;
}

該段配置中有一些比較重要的部分:

mime.types

該檔案為 /etc/nginx/mine.types,表示針對不同檔案型別會返回給瀏覽器的 Content-Type 頭部資訊,以下是該檔案的部分內容:

types {
    text/html                             html htm shtml;
    text/css                              css;
    text/xml                              xml;
    image/gif                             gif;
    image/jpeg                            jpeg jpg;
    application/javascript                js;
    application/atom+xml                  atom;
    application/rss+xml                   rss;
    
    # 其他內容
}

有關這一部分的詳細資訊可以檢視:「Nginx — mime.types」和「HTTP Content-Type」。

log_format

該項配置了日誌記錄的格式,具體可以參考:「使用 log_format 為 Nginx 伺服器設定更詳細的日誌格式」。

server 模組

由於在 nginx.conf 中存在下面這條配置,使得所有在該目錄下,檔名以 .conf 結尾的檔案都會被當作配置檔案引入:

include /etc/nginx/conf.d/*.conf;

而在 /etc/nginx/conf.d/ 目錄下,提供了一個 default.conf 檔案,以下是該檔案部分內容及註釋:

# 每一個 server 定義了一個虛擬主機
server {
    # 埠號
    listen       80;
    
    # 訪問的主機名
    server_name  localhost;

    #charset koi8-r;
    
    # 這裡可以覆蓋 http 中的配置
    #access_log  /var/log/nginx/log/host.access.log  main;
    
    # 其他配置
}

在 server 模組中,location 是非常重要的配置項,我們可以使用它完成很多需求。

簡單的請求匹配

我更傾向於把它稱為路由匹配,即根據請求的型別轉發到相應的程式碼中進行處理,和路由器根據路由錶轉發資料包的過程很是相似。

server {
    
    # 其他配置
    
    server_name my.app.dev;
    
    location / {
        # 匹配時轉發到的目錄
        root   /usr/share/nginx/html;
        
        # 如以 my.app.dev 訪問,則嘗試訪問 
        # my.app.dev/index.html 
        # 或 
        # my.app.dev/index.htm
        index  index.html index.htm;
    }
    
    # 其他配置
    
}

這是一個簡單的配置,所有以 my.app.dev 發起到該主機的請求都會與這一配置匹配。如請求 my.app.dev/a.html 則相當於訪問 /usr/share/nginx/html/a.html 檔案(注意配置域名解析到該伺服器),該路徑為 root 配置內容。

正則匹配

當然也可以使用正規表示式定義:

location ~* .(jpg|jpeg|gif|png)$ {
    root   /usr/share/nginx/static/images;
}

該配置表示對圖片類的靜態資源的轉發,其中 .(jpg|jpeg|gif|png)$ 為正則內容;

~* 表示請求不區分大小寫,關於此類規則可以參考:「Nginx location 匹配規則」。

反向代理

我們還可以進行反向代理配置:

location /api {
    # 代理轉發
    proxy_pass http://api.app.dev;
    
    # 保留請求方的真實 IP
    proxy_set_header X-Real-IP $remote_addr;
    
    # 追加代理 IP
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for
}

在使用代理後,如果想讓代理後的伺服器得到的請求地址仍是真實的客戶,而不是代理伺服器,則需要增加上述配置的下面兩行。有關這二者的區別和更為詳細的資訊可以分別參考:「X-Forwarded-For 和 X-Real-IP 的區別?」和「怎樣正確設定 remote_addr 和 x_forwarded_for」。

FastCGI

對於某些需要藉助額外處理過程的檔案,Nginx 需要將請求轉發給實現了 CGI 或 FastCGI 的程式進行處理。在 PHP 中即為 php-fpm:

location ~ .php$ {

    # 注意,Nginx 和 FastCGI 通訊具有兩種形式,TCP 和 UNIX Socket 方式
    # 預設為 socket 方式
    # fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    
    # 或使用 TCP 方式
    fastcgi_pass   127.0.0.1:9000;
    
    # 預設索引檔案
    fastcgi_index  index.php;
    
    # 額外的引數:請求的指令碼檔案位置
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    
    # 引入額外的 FastCGI 配置
    include        fastcgi_params;
}

其中:fastcgi_pass 表示將該類請求轉發到哪個程式,這裡配置為 127.0.0.1:9000 是因為 php-fpm 預設監聽 9000 埠。

這裡的 $document_root$fastcgi_script_name 分別表示 root 配置指定的位置及指令碼名稱。二者連起來即為指令碼檔案的請求路徑。詳細資訊可以參考「Nginx 內建預定義變數」和「fastcgi_param 詳解 – CSDN」。

include fastcgi_params 為引入 /etc/nginx/fastcgi_params 檔案。

地址重寫

又稱為偽靜態,可以通過以下方式配置:

location / {
    index  index.php;
    try_files $uri $uri/ /index.php?$query_string;
}

try_files 後附帶三個引數(可以配置多個,中間用空格分隔),對於一個請求,會依次嘗試這三者。如對於請求 my.app.dev/comments/1,依次嘗試:

  1. my.app.dev/comments/1 按照 root 配置所表示的檔案;

  2. my.app.dev/comments/1/。這裡是目錄,會繼續按照 index 配置查詢如 index.html 等檔案;

  3. my.app.dev/index.php。注意,雖然轉發到這個檔案,但請求的 url 仍是 my.app.dev/comments/1,一般在 index.php 中會有請求解析模組專門進行匹配。

一般地址重寫都是動態語言的需求,所以地址重寫配置往往和 FastCGI 配置一同出現。

匹配順序

同路由表的匹配規則類似,請求的匹配大體上也遵循最長匹配,具體規則如下(引用自:Nginx location 匹配規則):

  1. = 字首的指令嚴格匹配這個查詢。如果找到,停止搜尋;

  2. 所有剩下的常規字串,最長的匹配。如果這個匹配使用^〜字首,搜尋停止;

  3. 正規表示式,在配置檔案中定義的順序;

  4. 如果第 3 條規則產生匹配的話,結果被使用。否則,使用第2條規則的結果。

預設匹配

在配置了 location / {...} 後,由於所有請求都屬於這一格式。在沒有更為精確的匹配符合的情況下,會進入這一配置中,實際上相當於預設配置。

當然,我們也可以用以下方式配置一個預設(預設)的 server:

server {
    listen 80 default_server;
    root /default/root;
    #root return 444;
}

使用 default_server 標註其為預設 server。這裡也可以把 root /default/root 改為 root return 444,表示當必須使用預設 server 時,直接返回 444 HTTP 狀態碼。而又由於沒有這一狀態碼,瀏覽器中會直接顯示 網頁無法正常工作

404 錯誤問題

當訪問已正確配置的地址卻出現 403 錯誤時,有可能是 SELinux 導致的。

先執行以下命令:

getenforce

如果出現 Enforcing 結果,則需要改變安全上下文:

chcon -Rt httpd_sys_content_t /your/web/dir

詳細內容可以參考 「檢視 SELinux 狀態及關閉 SELinux」 和 「Chcon 命令」。


參考

  1. 檢視 SELinux 狀態及關閉 SELinux

  2. Chcon 命令

  3. Nginx error_log 錯誤日誌級別

  4. Nginx — mime.types

  5. HTTP Content-Type

  6. 使用 log_format 為 Nginx 伺服器設定更詳細的日誌格式 – 部落格園

  7. nginx location 匹配規則

  8. X-Forwarded-For 和 X-Real-IP 的區別? – segmentfault

  9. 怎樣正確設定 remote_addr 和 x_forwarded_for – CSDN

  10. Nginx 內建預定義變數

  11. fastcgi_param 詳解 – CSDN

  12. NGINX:Web 伺服器 – 寧皓網

  13. Ubuntu 16.04LTS LNMP環境配置 – 部落格園

相關文章