NGINX 反向代理與 Python 環境設定整合

在 Linux 環境下，將 NGINX 設定為反向代理伺服器並且 Python 和 Django 框架整合，需要幾個步驟。首先，需確認系統已安裝 Python，並根據 Linux 發行版使用 dnf install python python-devel 或 apt install python python-dev 指令進行安裝。接著，使用 pip 安裝 Django，指令為 pip install Django==版本號，例如 pip install Django==5.0.3。為使 Django 透過 FastCGI 與 NGINX 整合，還需安裝 flup 函式庫。安裝完成後，建立 Django 專案並執行 FastCGI 程式管理器，指令為 python manage.py runfcgi method=prefork host=127.0.0.1 port=9000 pidfile=/var/run/django.pid。最後，設定 NGINX 組態，指定後端伺服器地址和埠號，並設定必要的引數，例如 proxy_pass、proxy_set_header 等。實際應用中，NGINX 的反向代理功能可以提升網站效能和安全性，例如透過快取機制減少後端伺服器負載，並透過負載平衡功能將流量分發到多台伺服器，提高網站的可用性和容錯能力。此外，NGINX 還提供許多進階功能，例如設定請求轉發規則、自訂錯誤頁面、控制 TCP 連線等，可根據實際需求進行調整。

設定 NGINX 與 Python 環境

在 Linux 系統上設定 Python 與 Django，並且 NGINX 整合，是一個相對順暢的過程，主要涉及幾個簡單的指令。以下是詳細的步驟，包含了如何安裝 Python、Django、FastCGI 管理器及組態 NGINX。

安裝 Python

首先，確保你的系統已經有 Python。大多數 Linux 發行版都會在官方套件函式庫中提供 Python。根據你使用的 Linux 發行版，可以使用以下指令來安裝 Python：

對於使用 dnf 作為套件管理器的 Red Hat 基礎系統：

[root@local ~]# dnf install python python-devel

對於使用 apt 作為套件管理器的 Ubuntu 或 Debian 系統：

[root@local ~]# apt install python python-dev

這些指令會自動解決所需的依賴項。

安裝 Django

Django 的安裝會使用 pip，這是一個簡化 Python 套件安裝的工具。首先，安裝 pip：

對於使用 dnf 作為套件管理器的 Red Hat 基礎系統：

[root@local ~]# dnf install python-pip

對於使用 apt 作為套件管理器的 Ubuntu 或 Debian 系統：

[root@local ~]# apt install python-pip

接下來，使用 pip 安裝 Django。假設我們要安裝最新穩定版本（例如 5.0.3）：

[root@website.com ~]# pip install Django==5.0.3

安裝 FastCGI 管理器所需的 flup 函式庫

要讓 Django 透過 FastCGI 與 NGINX 整合，還需要安裝 flup 函式庫，這個函式庫提供了 FastCGI 協定的實作：

對於使用 dnf 作為套件管理器的 Red Hat 基礎系統：

[root@local ~]# dnf install python-flup

請注意，這需要啟用 EPEL 儲存函式庫；否則，你可能需要從原始碼編譯。

對於使用 apt 作為套件管理器的 Ubuntu 或 Debian 系統：

[root@local ~]# apt install python-flup

啟動 FastCGI 程式管理器

現在，我們可以開始建立 Django 專案了。執行以下指令來建立新專案：

[root@website.com ~]# django-admin startproject mysite

接下來，進入新建立的 mysite 目錄並執行 FastCGI 程式管理器：

[root@website.com mysite]# python manage.py runfcgi method=prefork host=127.0.0.1 port=9000 pidfile=/var/run/django.pid

如果一切正確組態且依賴項已安裝，這個指令應該沒有輸出。這表示 FastCGI 程式管理器正在後台執行，等待連線。你可以使用 ps 指令來驗證應用程式是否正在執行（例如，執行 ps aux | grep python）。如果沒有看到任何執行中的程式，嘗試更改指令中的埠號。

組態 NGINX

接下來是組態 NGINX 的部分。NGINX 的組態類別似於 PHP 的組態：

server {
    server_name .website.com;
    listen 80;

    # 插入 Python 專案公共檔案路徑
    root /home/website/www;
    index index.html;

    location / {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_script_name;
        include fastcgi_params;
    }
}

這樣就完成了透過 FastCGI 與 NGINX 整合 Python 的設定。

NGINX 作為反向代理

隨著網路技術的演進，現代網路不僅僅是簡單的靜態網站，還包括許多複雜的 SaaS 應用程式、部落格、新聞網站等。NGINX 原本就設計為快速靜態檔案伺服器和反向代理伺服器。它能夠接收來自外部世界的請求並轉發到內部伺服器，然後將回應傳回給使用者。

搭建反向代理機制

運作方式如下圖所示：

此圖示展示了 NGINX 作為反向代理伺服器的基本架構。NGINX 接收來自外部世界的所有請求，並將它們轉發到內部伺服器（例如 Node.js、Apache），然後將回應傳回給使用者。內部伺服器只與 NGINX 通訊，而不直接與外部世界互動。

組態 NGINX Proxy 模組

NGINX 預設提供 proxy 模組，這個模組允許將 HTTP 請求從客戶端轉發到後端伺服器。以下是一些主要組態專案：

• 基本地址和埠號資訊：指定後端伺服器的地址和埠號。
• 快取、緩衝和暫存檔選項：控制請求和回應的快取行為。
• 限制、超時和錯誤行為：設定請求和連線的限制和超時時間。
• 其他雜項選項：包括日誌記錄、安全性設定等。

以下是一個簡單的反向代理組態範例：

server {
    server_name example.com;
    listen 80;

    location / {
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

NGINX 反向代理模組的探討

在深入瞭解 NGINX 反向代理模組之前，我們先來看看如何使用這些指令來建立基本的組態。這些指令會讓你能夠設定後端伺服器的位置、要傳遞的資訊以及傳遞方式。

基本指令

首先，我們來看看幾個主要的指令，這些指令可以幫助我們建立基本的反向代理組態。

proxy_pass

proxy_pass 指令用來指定請求應該轉發到哪個後端伺服器，並且可以指定伺服器的位置。

proxy_pass http://hostname:port;

• HTTP 轉發：proxy_pass http://hostname:port;
• Unix 域通訊端：proxy_pass http://unix:/path/to/file.socket;
• 上游塊：proxy_pass http://myblock;
• 安全流量：可以使用 https:// 來處理安全流量。

例如：

proxy_pass http://localhost:8080;
proxy_pass http://127.0.0.1:8080;
proxy_pass http://unix:/tmp/nginx.sock;
proxy_pass https://192.168.0.1;
proxy_pass http://localhost:8080/uri/;

使用上游塊

你也可以使用上游塊來管理多個後端伺服器：

upstream backend {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
}

location ~* .php$ {
    proxy_pass http://backend;
}

proxy_method

proxy_method 指令允許你覆寫請求的 HTTP 方法。例如，你可以將所有請求轉發為 POST 方法。

proxy_method POST;

proxy_hide_header

預設情況下，NGINX 在將後端伺服器的回應轉發給客戶端時會忽略一些標頭，如 Date、Server、X-Pad 和 X-Accel-*。你可以使用 proxy_hide_header 指令來隱藏額外的標頭。

proxy_hide_header Cache-Control;

proxy_pass_header

相反地，如果你想強制將某些標頭傳遞給客戶端，可以使用 proxy_pass_header 指令。

proxy_pass_header Date;

控制請求與回應

除了基本組態之外，我們還可以控制請求體和標頭是否被轉發給後端伺服器。

proxy_pass_request_body 與 proxy_pass_request_headers

這兩個指令分別用來控制是否轉發請求體和額外的請求標頭。

proxy_pass_request_body on;
proxy_pass_request_headers off;

重寫重定向 URL

當後端伺服器觸發重定向時，你可以使用 proxy_redirect 指令來重寫 Location 標頭中的 URL。

proxy_redirect off;
proxy_redirect default;
proxy_redirect http://localhost:8080/ http://example.com/;

轉發到下一個上游伺服器

當 proxy_pass 與上游塊結合使用時，你可以使用 proxy_next_upstream 指令來定義在哪些情況下應該放棄請求並轉發到下一個上游伺服器。

proxy_next_upstream error timeout http_504;

控制快取、緩衝與臨時檔案

為了減少對後端伺服器的請求數量，我們可以建立快取系統並控制緩衝選項和臨時檔案的處理方式。

proxy_buffer_size

這個指令設定從後端伺服器讀取回應開頭時的緩衝區大小，通常包含簡單的標頭資料。

proxy_buffer_size 4k;

proxy_buffering 與 proxy_request_buffering

這些指令控制是否將後端伺服器的回應或客戶端請求進行緩衝。預設值為開啟。

proxy_buffering on;
proxy_request_buffering off;

proxy_buffers

這個指令設定用於讀取後端伺服器回應資料的緩衝區數量和大小。

fastcgi_buffers 8 4k;

proxy_busy_buffers_size

當從後端接收到的資料超過此值時，緩衝區會被清空並將資料傳送給客戶端。

proxy_busy_buffers_size 8k;

proxy_cache

這個指令定義一個快取區域。所給予的識別碼將在其他指令中重複使用。

proxy_cache cache1;

流程圖示：NGINX Proxy Workflow

此圖示展示了 NGINX Proxy 的基本工作流程，包括請求進入、轉發到後端伺服器以及傳回給客戶端的過程。

此圖示解說：

• A：Client Request：客戶端發出請求。
• B：NGINX：NGINX 接收到請求並進行處理。
• C：Proxy Pass：根據 proxy_pass 指令將請求轉發到後端伺服器。
• D：Backend Server：後端伺服器處理請求並傳回回應。
• E：Response：NGINX 接收到回應並進行必要的處理。
• F：Client：最終回應傳回給客戶端。

透過以上指令和組態，玄貓能夠幫助你深入瞭解並有效運用 NGINX 的反向代理功能。

NGINX 作為反向代理的深度解析

NGINX 作為一款強大的網頁伺服器，其反向代理功能在現代網路架構中扮演著至關重要的角色。本文將探討 NGINX 的反向代理模組，並詳細介紹其各項指令的應用與組態。透過具體案例和深度分析，玄貓將帶你瞭解如何有效地使用 NGINX 作為反向代理來提升網站效能和穩定性。

反向代理快取機制

在動態網站中，快取是提升效能的關鍵技術之一。NGINX 提供了多種指令來組態反向代理的快取行為。以下是幾個核心指令及其應用。

快取鍵定義

proxy_cache_key 指令用於定義快取鍵，即區分不同快取條目的依據。預設情況下，若將 proxy_cache_key 設為 $uri，則所有具有相同 URI 的請求都會被視為同一個快取條目。

proxy_cache_key $scheme$host$request_uri $cookie_user;

內容解密：

這段程式碼定義了快取鍵的組成部分。$scheme 表示請求的協定（如 HTTP 或 HTTPS），$host 表示主機名稱，而 $request_uri 則是完整的請求 URI。這樣的設計能夠確保不同查詢字串的請求不會被錯誤地快取在同一個條目中。例如，/index.php 和 /index.php?page=contact 會被視為不同的快取條目。

快取路徑設定

proxy_cache_path 指令用於設定快取檔案的儲存路徑及其他引數。

proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=zone1:10m inactive=10m max_size=200M;

內容解密：

這段程式碼設定了快取檔案的儲存路徑為 /tmp/nginx_cache，並且定義了子目錄層級（levels）為 1:2。這意味著會有一個子目錄層級，並在該層級下再分一個子目錄。keys_zone 指令則將快取分配到名為 zone1 的記憶體區域中，並設定其大小為 10MB。inactive=10m 表示如果某個快取條目在 10 分鐘內未被存取，則會被移除。最後，max_size=200M 限制了整個快取空間不得超過 200MB。

HTTP 方法與最小使用次數

HTTP 方法

proxy_cache_methods 指令用於定義哪些 HTTP 操作方法可以被快取。預設情況下，GET 和 HEAD 操作方法可以被快取。

proxy_cache_methods OPTIONS;

內容解密：

這段程式碼將 OPTIONS 操作方法加入到可快取的方法列表中。這樣，當 OPTIONS 請求到達時，NGINX 會根據組態決定是否將其結果進行快取。

最小使用次數

proxy_cache_min_uses 指令則定義了一個請求至少要被存取多少次才會被快取。

proxy_cache_min_uses 1;

內容解密：

這段程式碼設定了最小使用次數為 1 次，即當某個請求首次存取時就會立即進行快取。

自訂快取有效期

自訂回應狀態碼

proxy_cache_valid 指令允許根據不同的回應狀態碼來設定各自的快取時間。

proxy_cache_valid 404 1m;
proxy_cache_valid 500 502 504 5m;
proxy_cache_valid 200 10m;

內容解密：

這些程式碼分別設定了對於不同狀態碼的回應如何進行快取。例如，狀態碼 404 (Not Found) 的回應會被快取在 1分鐘 (1m)，而 5xx (Server Error) 的回應則會被快取在 5分鐘 (5m) 中。這樣可以根據實際情況靈活調整不同錯誤和成功回應的處理策略。

舊版資料提供策略

提供過期資料

當後端伺服器無法即時回應時，NGINX 是否提供舊版資料可以由 proxy_cache_use_stale 指令控制。

proxy_cache_use_stale error timeout;

內容解密：

這段程式碼設定了當出現錯誤或連線超時時（timeout），NGINX 應該提供過期（stale）但仍可用的資料給前端使用者以維持服務穩定性。

暫時檔案設定

暫時檔案大小限制

當處理大型檔案時，可以使用 proxy_max_temp_file_size 指令來限制暫時檔案的大小。

proxy_max_temp_file_size 5m;

內容解密：

這段程式碼將暫時檔案大小限制在 5MB (5m)。如果伺服器需要處理更大檔案而超過此限制時，伺服器會將超過部分分割成多個較小的暫時檔案進行處理。

暫時檔案寫入速度

當伺服器需要寫入暫時檔案到儲存裝置上時，「寫入速度」可以透過 proxy_temp_file_write_size 指令控制。

proxy_temp_file_write_size 預設值：2 * proxy_buffer_size

內容解密：

這段程式碼表示寫入暫時檔案到儲存裝置上的寫入速度與每次寫入操作中的資料量相關。「每次寫入操作」指的是一次寫入動作所包含的資料量。「write buffer size」指的是在寫入過程中使用的緩衝區大小。預設值是「兩倍 proxy_buffer_size」。

暫時檔案儲存在路徑

最後，「暫時檔案」與「快取資料」儲存在「伺服器上的路徑」可以由 proxy_temp_path 指令來控制。

proxy_temp_path /tmp/nginx_proxy;

內容解密：

此段程式碼將「暫時檔案」與「快取資料」儲存在 /tmp/nginx_proxy 路徑下面。該路徑必須已經存在且具有可讀取及寫入許可權；否則「伺服器」無法正常執行該功能。「快取資料」通常用來儲存在「伺服器記憶體中」，而「暫時檔案」則用來儲存在「磁碟驅動器」上。「快取資料」優先於「暫時檔案」，因為「快取資料」讀取速度比較快。「快取資料」與「暫時檔案」都能夠有效地減少對後端伺服器的負載，「但實際效果取決於具體情況」。

各種超時間隔及錯誤處理機制

以下幾項指令用於組態 NGINX 與後端伺服器之間通訊行為、時間處理及錯誤管理策略。

語法與時間處理細節

建立連線時間超限處理指令

proxy_connect_timeout 15;

內容解密：

這段程式碼設定了 NGINX 與後端伺服器建立連線所需時間超過 15秒 (15s) 的情況下進行相關處理。「建立連線時間超限處理指令」用來控制 NGINX 與後端伺服器建立連線所需時間。「時間值（seconds）」指的是等待時間單位以秒計算。

読取後端伺服器資料超限處理指令

proxy_read_timeout 預設值：60s;

內容解密：

此段程式碼表示從後端伺服器讀取資料時間超過預設值 (60秒) 的情況下進行相關處理。「讀取後端伺服器資料超限處理指令」用來控制從後端伺服器讀取資料所需時間。「時間值（seconds）」指的是等待時間單位以秒計算。

傳送資料至後端伺服器時間超限處理指令

proxy_send_timeout 預設值：60s;

內容解密：

此段程式碼表示傳送資料至後端伺服器時間超過預設值 (60秒) 的情況下進行相關處理。「傳送資料至後端伺服器時間超限處理指令」用來控制傳送資料至後端伺服器所需時間。「時間值（seconds）」指的是等待時間單位以秒計算。

雜項指令說明與其他組態技巧

忽略客戶端終止請求功能開啟與否之詳細說明

當客戶端終止請求後，「忽略客戶端終止請求功能開啟與否之詳細說明」（是否繼續執行相關操作）可以由 proxy_ignore_client_abort 指令來控制。

proxy_ignore_client_abort on|off;

內容解密：

當組態值設定為 on 或 off 時，「忽略客戶端終止請求功能開啟與否之詳細說明」（是否繼續執行相關操作）就分別代表繼續執行或停止執行相關操作。 該語法適用於各種場景且可根據實際需要做出適當調整與組態。 如果客戶端強迫終止連線或者網路異常導致連線失敗，「忽略客戶端終止請求功能開啟與否之詳細說明」（是否繼續執行相關操作）就可以根據需要做出選擇。 通常如果設定了 on 值代表繼續執行相關操作直到完成全部工作。 如果希望提高效率並縮短完成時間，「忽略客戶端終止請求功能開啟與否之詳細說明」（是否繼續執行相關操作）就可以考慮組態 off 值。

調整 NGINX 錯誤頁面顯示方式細節說明

NGINX 預設情況下會直接將錯誤頁面顯示給客戶端顯示。 如果希望調整錯誤頁面顯示方式細節（例如自訂錯誤頁面或重新導向錯誤頁面）可以使用以下指令：

error_page http_status_code [http_status_code ...] uri;

其中 http_status_code 是 HTTP 指令碼錯誤狀態碼, uri 是自訂錯誤頁面地址或重新導向地址。 例如：

error_page   404              /404.html;

此段程式碼代表當發生 HTTP 指令碼錯誤狀態碼 “404” 的情況下, Nginx 優先顯示自訂錯誤頁面 “404.html” 。

控制 TCP 心跳包技術細節說明

TCP 心跳包技術是指 TCP 在沒有任何資料傳輸時, 主動傳送保活包以保持連線活躍狀態, 防止因長時間無資料傳輸導致連線失效。 如果希望調整 TCP 心跳包技術細節(例如傳送頻率)可以使用以下指令：

keepalive_timeout time [header_timeout];

其中 time 是心跳包間隔時間, header_timeout 是 HTTP 頭部回應超時時間。 例如：

keepalive_timeout    timeout_value seconds;

此段程式碼代表 TCP 心跳包間隔時間設定為 timeout_value 個秒, 超過此間隔後再次傳送心跳包以保持連線活躍狀態, 預防因長時間無資料傳輸導致連線失效。

負載平衡策略概述圖示

以下為負載平衡策略概述圖示（以 Plantuml 語法呈現）：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title NGINX 反向代理與 Python 環境設定整合

package "Linux Shell 操作" {
    package "檔案操作" {
        component [ls/cd/pwd] as nav
        component [cp/mv/rm] as file
        component [chmod/chown] as perm
    }

    package "文字處理" {
        component [grep] as grep
        component [sed] as sed
        component [awk] as awk
        component [cut/sort/uniq] as text
    }

    package "系統管理" {
        component [ps/top/htop] as process
        component [systemctl] as service
        component [cron] as cron
    }

    package "管線與重導向" {
        component [| 管線] as pipe
        component [> >> 輸出] as redirect
        component [$() 命令替換] as subst
    }
}

nav --> file : 檔案管理
file --> perm : 權限設定
grep --> sed : 過濾處理
sed --> awk : 欄位處理
pipe --> redirect : 串接命令
process --> service : 服務管理

note right of pipe
  命令1 | 命令2
  前者輸出作為後者輸入
end note

@enduml

負載平衡策略概述圖示內容解說：

此圖示展示了一個典型的負載平衡架構：客戶端（Client）首先發起請求至負載平衡器（Load Balancer），負載平衡器根據組態選擇合適的後端伺服器（Server A、Server B 或 Server C）進行請求轉發。這樣設計能夠有效分散流量、提高系統穩定性和效能。

NGINX 及技術挑戰

隨著技術不斷進步，NGINX 作為反向代理的一些潛在改進方向包括但不限於以下幾點：

• 高效快取管理：進一步最佳化快取機制，減少磁碟 I/O 操作，提高快取命中率。
• 安全性增強：加強對常見攻擊手法如 DDoS、SQL 注入等的防禦能力。
• 模組擴充套件：支援更多第三方模組和外掛，增強功能擴充套件性。
• 自動化維運：提升自動化維運能力，減少人工干預和操作風險。

總結而言，NGINX 作為反向代理在現代網路架構中的應用範疇廣泛且深遠。透過合理組態和最佳化其各項指令和引數設定，玄貓相信能夠顯著提升系統效能和穩定性。