nginx ngx_http_module(9) 指令詳解

nginx 模塊目錄

nginx 全指令目錄

一、目錄

1.1 模塊簡介

• ngx_http_uwsgi_module：uWSGI支持模塊，允許Nginx與uWSGI服務器進行通信。uWSGI是一種應用服務器協議，廣泛用于Python Web應用的部署。通過該模塊，Nginx可以將動態請求轉發給uWSGI服務器處理，并將響應返回給客戶端。常用的指令包括 uwsgi_pass 用于指定uWSGI服務器地址和端口。

1.2 指令目錄

1.2.1 ngx_http_uwsgi_module

• uwsgi_bind
• uwsgi_buffer_size
• uwsgi_buffering
• uwsgi_buffers
• uwsgi_busy_buffers_size
• uwsgi_cache
• uwsgi_cache_background_update
• uwsgi_cache_bypass
• uwsgi_cache_key
• uwsgi_cache_lock
• uwsgi_cache_lock_age
• uwsgi_cache_lock_timeout
• uwsgi_cache_max_range_offset
• uwsgi_cache_methods
• uwsgi_cache_min_uses
• uwsgi_cache_path
• uwsgi_cache_purge
• uwsgi_cache_revalidate
• uwsgi_cache_use_stale
• uwsgi_cache_valid
• uwsgi_connect_timeout
• uwsgi_force_ranges
• uwsgi_hide_header
• uwsgi_ignore_client_abort
• uwsgi_ignore_headers
• uwsgi_intercept_errors
• uwsgi_limit_rate
• uwsgi_max_temp_file_size
• uwsgi_modifier1
• uwsgi_modifier2
• uwsgi_next_upstream
• uwsgi_next_upstream_timeout
• uwsgi_next_upstream_tries
• uwsgi_no_cache
• uwsgi_param
• uwsgi_pass
• uwsgi_pass_header
• uwsgi_pass_request_body
• uwsgi_pass_request_headers
• uwsgi_read_timeout
• uwsgi_request_buffering
• uwsgi_send_timeout
• uwsgi_socket_keepalive
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_cache
• uwsgi_ssl_certificate_key
• uwsgi_ssl_ciphers
• uwsgi_ssl_conf_command
• uwsgi_ssl_crl
• uwsgi_ssl_key_log
• uwsgi_ssl_name
• uwsgi_ssl_password_file
• uwsgi_ssl_protocols
• uwsgi_ssl_server_name
• uwsgi_ssl_session_reuse
• uwsgi_ssl_trusted_certificate
• uwsgi_ssl_verify
• uwsgi_ssl_verify_depth
• uwsgi_store
• uwsgi_store_access
• uwsgi_temp_file_write_size
• uwsgi_temp_path

二、解釋

2.1 ngx_http_uwsgi_module

ngx_http_uwsgi_module 是 Nginx 的一個模塊，用于與 uWSGI 應用服務器進行通信。uWSGI 是一個快速、自適應的 WSGI 服務器，廣泛用于 Python Web 應用的部署。通過 ngx_http_uwsgi_module，Nginx 可以將請求轉發給 uWSGI 服務器，并處理響應返回給客戶端。

主要功能

• 請求轉發：將客戶端的請求轉發給 uWSGI 應用服務器。
• 負載均衡：通過 upstream 指令實現多個 uWSGI 實例之間的負載均衡。
• 緩存控制：設置緩存相關的頭部信息，控制緩存行為。
• 重試機制：當某個 uWSGI 服務器不可用時，可以自動嘗試其他服務器。
• 健康檢查：結合 upstream 和 health_check 模塊實現對 uWSGI 服務器的健康狀態監控。

常用指令

以下是與 ngx_http_uwsgi_module 模塊相關的常用配置指令及其簡要說明：

• uwsgi_pass：指定 uWSGI 服務器的地址和端口，或使用 Unix 域套接字路徑。

• uwsgi_param：在轉發請求之前修改或添加 uWSGI 參數。

• uwsgi_cache：啟用緩存并指定緩存區域名稱。

• uwsgi_cache_valid：為不同的響應碼設置緩存的有效時間。

• uwsgi_next_upstream：定義在哪些情況下應嘗試下一個上游服務器。

• uwsgi_read_timeout：設置等待 uWSGI 服務器響應的超時時間。

• uwsgi_connect_timeout：設置連接到 uWSGI 服務器的超時時間。

使用示例

以下是一些具體的配置示例，展示如何利用 ngx_http_uwsgi_module 來實現各種功能。

基本配置

假設你想將所有 /app/ 路徑下的請求代理到一個 uWSGI 服務器：

http {upstream uwsgi_backend {server 127.0.0.1:3031;  # uWSGI 服務器地址和端口}server {listen 80;server_name example.com;location /app/ {# 將請求轉發給 upstream 定義的 uwsgi_backend 組uwsgi_pass uwsgi_backend;# 修改請求頭uwsgi_param Host $host;uwsgi_param X-Real-IP $remote_addr;uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;uwsgi_param X-Forwarded-Proto $scheme;# 設置 uWSGI 協議版本uwsgi_protocol uwsgi;}}
}

在這個例子中：

• upstream uwsgi_backend 定義了一個包含單個 uWSGI 服務器的組。
• location /app/ 匹配 /app/ 路徑下的請求，并將其轉發給 uwsgi_backend 組中的服務器。
• uwsgi_param 指令用于修改請求頭，確保 uWSGI 服務器能獲取客戶端的真實 IP 地址和其他信息。

緩存配置

你可以結合 uwsgi_cache 指令啟用緩存功能，以減少對 uWSGI 服務器的請求次數：

http {# 定義緩存區域uwsgi_cache_path /var/cache/nginx/uwsgi_cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location /static/ {uwsgi_pass uwsgi_backend;# 啟用緩存uwsgi_cache my_cache;uwsgi_cache_valid 200 302 10m;uwsgi_cache_valid 404 1m;# 添加緩存相關頭部add_header X-UWSGI-Cache $upstream_cache_status;}location /dynamic/ {uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• uwsgi_cache_path 定義了一個名為 my_cache 的緩存區域，位于 /var/cache/nginx/uwsgi_cache 目錄下。
• uwsgi_cache 啟用了緩存，并指定了緩存區域。
• uwsgi_cache_valid 設置了不同 HTTP 狀態碼的緩存有效期。
• add_header X-UWSGI-Cache $upstream_cache_status; 添加了一個響應頭，顯示緩存狀態（如 HIT 或 MISS）。

負載均衡和重試機制

你可以配置負載均衡策略，并在某些情況下自動重試其他服務器：

http {upstream uwsgi_backend {server 192.168.1.1:3031;server 192.168.1.2:3031;server backup.example.com:3031 backup;  # 備份服務器# 加權輪詢# server 192.168.1.1:3031 weight=3;# server 192.168.1.2:3031 weight=1;# 最少連接# least_conn;}server {listen 80;server_name example.com;location / {uwsgi_pass uwsgi_backend;# 當出現錯誤或超時時重試其他服務器uwsgi_next_upstream error timeout http_500 http_502 http_503 http_504;# 連接超時時間uwsgi_connect_timeout 5s;# 讀取響應超時時間uwsgi_read_timeout 30s;}}
}

在這個例子中：

• upstream uwsgi_backend 定義了一個包含多個 uWSGI 服務器的組，并指定了一個備份服務器。
• uwsgi_next_upstream 指令定義了在哪些情況下應嘗試下一個上游服務器（如連接錯誤、超時、HTTP 500 錯誤等）。
• uwsgi_connect_timeout 和 uwsgi_read_timeout 分別設置了連接和讀取響應的超時時間。

請求頭修改

你可以根據需要修改請求頭，以便更好地控制請求轉發過程：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {uwsgi_pass uwsgi_backend;# 修改請求頭uwsgi_param Host $host;uwsgi_param X-Real-IP $remote_addr;uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;uwsgi_param X-Forwarded-Proto $scheme;# 添加自定義請求頭uwsgi_param X-Custom-Header "CustomValue";}}
}

在這個例子中：

• uwsgi_param 指令用于修改請求頭，確保 uWSGI 服務器能獲取客戶端的真實 IP 地址和其他信息。
• 你還可以添加自定義請求頭，如 X-Custom-Header。

健康檢查

雖然 ngx_http_uwsgi_module 本身不直接提供健康檢查功能，但可以通過結合 ngx_http_upstream_module 和 ngx_http_upstream_hc_module 實現健康檢查：

http {upstream uwsgi_backend {server 192.168.1.1:3031;server 192.168.1.2:3031;# 啟用健康檢查health_check interval=10 fails=3 passes=2;}server {listen 80;server_name example.com;location / {uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• health_check 指令啟用了健康檢查，默認情況下每 10 秒檢查一次，連續失敗 3 次即認為服務器不可用，連續成功 2 次即認為服務器恢復可用。

注意事項

• 性能考慮：

  • 配置合理的超時時間和重試機制，避免不必要的延遲和資源浪費。
  • 如果有大量并發請求，考慮使用負載均衡和緩存機制來分擔壓力。

• 安全性：

  • 確保 uWSGI 服務器的安全性，避免未經授權的訪問。
  • 對敏感數據進行加密傳輸，防止中間人攻擊。

• 日志記錄：

  • 合理配置日志級別和格式，便于監控和故障排查。特別是注意記錄請求轉發和響應處理的日志。

2.1.1 指令列表

uwsgi_bind

uwsgi_bind 指令用于指定 uWSGI 服務器綁定的地址和端口。這有助于控制 Nginx 如何與 uWSGI 后端通信。

Syntax:	uwsgi_bind address [transparent] | off;
Default: —
Context: http, server, location

• address：uWSGI 服務器綁定的地址（IP 地址或主機名）和端口。
• transparent：可選參數，啟用透明代理模式，允許 Nginx 以客戶端 IP 地址與 uWSGI 服務器通信。
• off：禁用綁定配置。

案例

基本用法

最簡單的 uwsgi_bind 用法是指定 uWSGI 服務器綁定的地址：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 綁定到 uWSGI 服務器的地址和端口uwsgi_bind 127.0.0.1:3031;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶訪問 example.com 時，Nginx 將通過 127.0.0.1:3031 與 uWSGI 服務器通信。

使用透明代理模式

你可以啟用透明代理模式來保留客戶端的真實 IP 地址：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 綁定到 uWSGI 服務器的地址和端口，并啟用透明代理模式uwsgi_bind 127.0.0.1:3031 transparent;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• Nginx 將以客戶端的實際 IP 地址與 uWSGI 服務器通信，而不是使用 Nginx 的 IP 地址。

注意事項

• 安全性：確保透明代理模式不會暴露內部網絡結構或導致安全風險。
• 權限要求：透明代理模式通常需要特定的操作系統權限（如 CAP_NET_ADMIN），請確保正確配置。

uwsgi_buffer_size

uwsgi_buffer_size 指令用于設置用于讀取 uWSGI 響應的第一部分的緩沖區大小。這對于處理大響應頭非常有用。

Syntax:	uwsgi_buffer_size size;
Default: uwsgi_buffer_size 4k|8k;
Context: http, server, location

• size：用于讀取 uWSGI 響應第一部分的緩沖區大小，默認為 4 KB 或 8 KB。

案例

基本用法

最簡單的 uwsgi_buffer_size 用法是設置緩沖區大小：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 設置 uwsgi 緩沖區大小為 16 KBuwsgi_buffer_size 16k;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當 Nginx 從 uWSGI 服務器讀取響應時，將使用 16 KB 的緩沖區來處理響應的第一部分。

注意事項

• 性能優化：合理設置緩沖區大小以避免頻繁的內存分配和釋放，特別是在處理大響應頭的情況下。
• 資源平衡：確保設置的大小不會占用過多內存，特別是在高并發環境下。

uwsgi_buffering

uwsgi_buffering 指令用于控制是否啟用 uWSGI 響應的緩沖功能。這有助于提高性能，但可能會影響實時性。

Syntax:	uwsgi_buffering on | off;
Default: uwsgi_buffering on;
Context: http, server, location

• on：啟用 uWSGI 響應的緩沖功能，默認行為。
• off：禁用 uWSGI 響應的緩沖功能。

案例

基本用法

最簡單的 uwsgi_buffering 用法是啟用或禁用緩沖功能：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 禁用 uwsgi 響應的緩沖功能uwsgi_buffering off;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶訪問 example.com 時，Nginx 將直接將 uWSGI 響應傳遞給客戶端，而不進行緩沖。

注意事項

• 性能與實時性：啟用緩沖功能可以提高性能，但在某些情況下（如實時應用）可能需要禁用緩沖。
• 資源管理：禁用緩沖功能可能導致更高的內存和 CPU 使用率，特別是在處理大數據量時。

uwsgi_buffers

uwsgi_buffers 指令用于設置用于讀取 uWSGI 響應的緩沖區數量和大小。這有助于優化響應處理的性能。

Syntax:	uwsgi_buffers number size;
Default: uwsgi_buffers 8 4k|8k;
Context: http, server, location

• number：用于讀取 uWSGI 響應的緩沖區數量。
• size：每個緩沖區的大小，默認為 4 KB 或 8 KB。

案例

基本用法

最簡單的 uwsgi_buffers 用法是設置緩沖區的數量和大小：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 設置 uwsgi 緩沖區的數量為 16，每個緩沖區大小為 8 KBuwsgi_buffers 16 8k;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• Nginx 將使用 16 個 8 KB 的緩沖區來讀取 uWSGI 響應。

注意事項

• 性能優化：合理設置緩沖區的數量和大小以避免頻繁的內存分配和釋放，特別是在處理大數據量響應時。
• 資源平衡：確保設置的數量和大小不會占用過多內存，特別是在高并發環境下。

uwsgi_busy_buffers_size

uwsgi_busy_buffers_size 用于設置在處理 uwsgi 響應時，同時處于繁忙狀態的緩沖區的最大總大小。這有助于控制內存使用并優化性能。

Syntax: uwsgi_busy_buffers_size size;
Default: uwsgi_busy_buffers_size 8k|16k;
Context: http, server, location

• size：指定繁忙緩沖區的總大小，默認值為 8KB 或 16KB（取決于平臺）。

案例

基本用法

最簡單的 uwsgi_busy_buffers_size 用法是指定緩沖區大小：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_busy_buffers_size 16k;  # 設置繁忙緩沖區大小為 16KB}
}

在這個例子中，設置了 uwsgi_busy_buffers_size 16k，這意味著繁忙緩沖區的總大小為 16KB。

調整緩沖區大小

根據實際需求調整緩沖區大小：

server {listen 80;server_name example.com;location /small_buffers/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_busy_buffers_size 8k;  # 較小的緩沖區大小}location /large_buffers/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_busy_buffers_size 32k;  # 較大的緩沖區大小}
}

在這個例子中：

• 對于 /small_buffers/ 路徑下的請求，設置了較小的緩沖區大小（8KB）。
• 對于 /large_buffers/ 路徑下的請求，設置了較大的緩沖區大小（32KB）。

注意事項

• 性能優化：合理設置緩沖區大小，確保既能滿足應用需求，又不會浪費資源。
• 應用場景：根據具體的應用場景選擇合適的緩沖區大小，例如高并發場景下可能需要更大的緩沖區。

uwsgi_cache

uwsgi_cache 用于啟用或禁用 uwsgi 緩存，并指定緩存區域。這有助于提高響應速度，減少后端服務器的負載。

Syntax: uwsgi_cache zone | off;
Default: uwsgi_cache off;
Context: http, server, location

• zone：指定要使用的共享緩存區域。
• off：禁用 uwsgi 緩存（默認行為）。

案例

基本用法

最簡單的 uwsgi_cache 用法是啟用緩存并指定緩存區域：

http {uwsgi_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache my_cache;  # 啟用 uwsgi 緩存并指定緩存區域}}
}

在這個例子中，啟用了 uwsgi 緩存，并指定了名為 my_cache 的緩存區域。

禁用緩存

根據實際需求禁用 uwsgi 緩存：

server {listen 80;server_name example.com;location /no_cache/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache off;  # 禁用 uwsgi 緩存}
}

在這個例子中，對于 /no_cache/ 路徑下的請求，禁用了 uwsgi 緩存。

注意事項

• 緩存配置：確保正確配置緩存路徑和參數，以避免磁盤空間不足或其他問題。
• 緩存策略：根據實際需求選擇合適的緩存策略，確保既能提高性能，又不會影響數據一致性。

uwsgi_cache_background_update

uwsgi_cache_background_update 用于控制是否在后臺更新緩存內容。這有助于保持緩存的有效性，減少用戶等待時間。

Syntax: uwsgi_cache_background_update on | off;
Default: uwsgi_cache_background_update off;
Context: http, server, location
This directive appeared in version 1.11.10.

• on：啟用后臺更新（從版本 1.11.10 開始支持）。
• off：禁用后臺更新（默認行為）。

案例

基本用法

最簡單的 uwsgi_cache_background_update 用法是啟用后臺更新：

http {uwsgi_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache my_cache;uwsgi_cache_background_update on;  # 啟用后臺更新}}
}

在這個例子中，啟用了后臺更新功能，確保緩存內容在后臺進行更新。

禁用后臺更新

根據實際需求禁用后臺更新：

server {listen 80;server_name example.com;location /disable_bg_update/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache my_cache;uwsgi_cache_background_update off;  # 禁用后臺更新}
}

在這個例子中，對于 /disable_bg_update/ 路徑下的請求，禁用了后臺更新功能。

注意事項

• 用戶體驗：啟用后臺更新可以減少用戶等待時間，但需要注意緩存一致性和更新頻率。
• 系統負載：后臺更新可能會增加系統的負載，特別是在高并發場景下。

uwsgi_cache_bypass

uwsgi_cache_bypass 用于定義哪些條件下不使用緩存。這有助于靈活控制緩存的使用，確保某些請求總是直接訪問后端服務器。

Syntax: uwsgi_cache_bypass string ...;
Default: —
Context: http, server, location

• string：指定一個或多個條件表達式，當這些條件為真時，跳過緩存。

案例

基本用法

最簡單的 uwsgi_cache_bypass 用法是指定條件來跳過緩存：

http {uwsgi_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache my_cache;uwsgi_cache_bypass $cookie_nocache $arg_nocache;  # 當存在特定 Cookie 或查詢參數時不使用緩存}}
}

在這個例子中，當請求包含 $cookie_nocache 或 $arg_nocache 參數時，跳過緩存。

復雜條件

根據實際需求定義更復雜的條件：

server {listen 80;server_name example.com;location /complex_bypass/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache my_cache;uwsgi_cache_bypass $cookie_nocache $arg_nocache $http_x_custom_header;  # 多個條件組合}location /always_bypass/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache my_cache;uwsgi_cache_bypass 1;  # 總是跳過緩存}
}

在這個例子中：

• 對于 /complex_bypass/ 路徑下的請求，當存在 $cookie_nocache、$arg_nocache 或自定義頭 $http_x_custom_header 時，跳過緩存。
• 對于 /always_bypass/ 路徑下的請求，總是跳過緩存。

注意事項

• 靈活性：通過定義不同的條件，可以靈活控制哪些請求跳過緩存。
• 一致性：確保跳過緩存的條件符合業務邏輯，避免不必要的性能損失。

uwsgi_cache_key

uwsgi_cache_key 指令用于定義緩存鍵值的字符串。這個指令幫助確定哪些請求會被視為相同的請求并使用相同的緩存。

Syntax:	uwsgi_cache_key string;
Default:	—
Context:	http, server, location

• string：指定緩存鍵值的字符串表達式，通常包含變量如 $request_uri 或 $host。

案例

基本用法

最簡單的 uwsgi_cache_key 用法是指定一個具體的緩存鍵值字符串：

http {uwsgi_cache_path /tmp/uwsgi_cache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_key $scheme$proxy_host$request_uri;}}
}

在這個例子中：

• 設置了 uwsgi_cache_key $scheme$proxy_host$request_uri，這意味著Nginx將根據協議、代理主機和請求URI生成緩存鍵值。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置不同的緩存鍵值字符串：

server {listen 80;server_name example1.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example1.sock;uwsgi_cache mycache;uwsgi_cache_key $scheme$proxy_host$request_uri;}
}server {listen 80;server_name example2.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example2.sock;uwsgi_cache mycache;uwsgi_cache_key $scheme$request_uri;}
}

在這個例子中：

• 對于 example1.com，設置了 uwsgi_cache_key $scheme$proxy_host$request_uri。
• 對于 example2.com，設置了 uwsgi_cache_key $scheme$request_uri。

注意事項

• 唯一性與一致性：確保緩存鍵值字符串能夠唯一標識每個請求，避免沖突。
• 適用場景：適用于需要緩存響應的應用場景。例如，在高并發網站、API網關等環境中使用。
• 調試和監控：如果你遇到緩存鍵值問題，可以檢查以下幾點：
  • 確保緩存鍵值字符串設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_cache_lock

uwsgi_cache_lock 指令用于控制是否啟用緩存鎖功能。這個指令幫助防止緩存穿透（cache stampede）問題。

Syntax:	uwsgi_cache_lock on | off;
Default:	uwsgi_cache_lock off;
Context:	http, server, location
This directive appeared in version 1.1.12.

• on：啟用緩存鎖功能。
• off：禁用緩存鎖功能（默認值）。

案例

基本用法

最簡單的 uwsgi_cache_lock 用法是指定是否啟用緩存鎖功能：

http {uwsgi_cache_path /tmp/uwsgi_cache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_lock on;}}
}

在這個例子中：

• 設置了 uwsgi_cache_lock on，這意味著Nginx將啟用緩存鎖功能。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置是否啟用緩存鎖功能：

server {listen 80;server_name example1.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example1.sock;uwsgi_cache mycache;uwsgi_cache_lock on;}
}server {listen 80;server_name example2.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example2.sock;uwsgi_cache mycache;uwsgi_cache_lock off;}
}

在這個例子中：

• 對于 example1.com，設置了 uwsgi_cache_lock on。
• 對于 example2.com，設置了 uwsgi_cache_lock off。

注意事項

• 性能與資源平衡：啟用緩存鎖可以防止緩存穿透，但可能會增加請求延遲。根據實際需求選擇是否啟用。
• 適用場景：適用于需要防止緩存穿透的應用場景。例如，在高并發網站、API網關等環境中使用。
• 調試和監控：如果你遇到緩存鎖問題，可以檢查以下幾點：
  • 確保緩存鎖設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_cache_lock_age

uwsgi_cache_lock_age 指令用于指定緩存鎖的有效期。這個指令幫助控制緩存鎖的時間窗口。

Syntax:	uwsgi_cache_lock_age time;
Default:	uwsgi_cache_lock_age 5s;
Context:	http, server, location
This directive appeared in version 1.7.8.

• time：指定緩存鎖的有效期，默認為 5s（5秒）。

案例

基本用法

最簡單的 uwsgi_cache_lock_age 用法是指定一個具體的有效期：

http {uwsgi_cache_path /tmp/uwsgi_cache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_lock on;uwsgi_cache_lock_age 10s;}}
}

在這個例子中：

• 設置了 uwsgi_cache_lock_age 10s，這意味著緩存鎖的有效期為10秒。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置不同的緩存鎖有效期：

server {listen 80;server_name example1.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example1.sock;uwsgi_cache mycache;uwsgi_cache_lock on;uwsgi_cache_lock_age 5s;}
}server {listen 80;server_name example2.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example2.sock;uwsgi_cache mycache;uwsgi_cache_lock on;uwsgi_cache_lock_age 15s;}
}

在這個例子中：

• 對于 example1.com，設置了 uwsgi_cache_lock_age 5s。
• 對于 example2.com，設置了 uwsgi_cache_lock_age 15s。

注意事項

• 時間窗口管理：合理設置緩存鎖的有效期，避免過長導致的資源占用或過短影響效果。
• 適用場景：適用于需要精確控制緩存鎖時間窗口的應用場景。例如，在需要精細調整緩存策略的高并發網站、API網關等環境中使用。
• 調試和監控：如果你遇到緩存鎖有效期問題，可以檢查以下幾點：
  • 確保緩存鎖有效期設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_cache_lock_timeout

uwsgi_cache_lock_timeout 指令用于指定等待緩存鎖釋放的最大超時時間。這個指令幫助控制請求在等待緩存鎖時的最大等待時間。

Syntax:	uwsgi_cache_lock_timeout time;
Default:	uwsgi_cache_lock_timeout 5s;
Context:	http, server, location
This directive appeared in version 1.1.12.

• time：指定等待緩存鎖釋放的最大超時時間，默認為 5s（5秒）。

案例

基本用法

最簡單的 uwsgi_cache_lock_timeout 用法是指定一個具體的超時時間：

http {uwsgi_cache_path /tmp/uwsgi_cache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_lock on;uwsgi_cache_lock_timeout 10s;}}
}

在這個例子中：

• 設置了 uwsgi_cache_lock_timeout 10s，這意味著請求在等待緩存鎖時的最大等待時間為10秒。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置不同的緩存鎖超時時間：

server {listen 80;server_name example1.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example1.sock;uwsgi_cache mycache;uwsgi_cache_lock on;uwsgi_cache_lock_timeout 5s;}
}server {listen 80;server_name example2.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example2.sock;uwsgi_cache mycache;uwsgi_cache_lock on;uwsgi_cache_lock_timeout 20s;}
}

在這個例子中：

• 對于 example1.com，設置了 uwsgi_cache_lock_timeout 5s。
• 對于 example2.com，設置了 uwsgi_cache_lock_timeout 20s。

注意事項

• 超時管理：合理設置最大等待時間，避免過長導致的請求阻塞或過短影響緩存命中率。
• 適用場景：適用于需要控制請求等待緩存鎖時的最大等待時間的應用場景。例如，在需要優化響應時間和緩存命中率的高并發網站、API網關等環境中使用。
• 調試和監控：如果你遇到緩存鎖超時問題，可以檢查以下幾點：
  • 確保緩存鎖超時時間設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_cache_max_range_offset

uwsgi_cache_max_range_offset 指令用于設置緩存的最大范圍偏移量（以字節為單位），用于處理 HTTP Range 請求。

Syntax:	uwsgi_cache_max_range_offset number;
Default:	—
Context:	http, server, location
This directive appeared in version 1.11.6.

• number：指定最大范圍偏移量的大小（以字節為單位）。

案例

基本用法

最簡單的 uwsgi_cache_max_range_offset 用法是指定最大范圍偏移量：

server {listen 80;server_name example.com;location /downloads/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 設置最大范圍偏移量為 10MBuwsgi_cache_max_range_offset 10485760; # 10MB in bytesuwsgi_cache my_cache;}
}

在這個例子中：

• 最大范圍偏移量設置為 10MB（即 10485760 字節）。

注意事項

• 性能優化：合理設置最大范圍偏移量可以避免緩存過多的大文件片段，從而節省緩存空間。
• 適用場景：適用于需要處理大文件部分請求的應用場景。例如，在下載服務或視頻流媒體應用中，適當設置最大范圍偏移量可以優化緩存使用。
• 調試和監控：如果你遇到范圍偏移量問題，可以檢查以下幾點：
  • 確保數值設置合理，不會導致緩存溢出或浪費。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_cache_methods

uwsgi_cache_methods 指令用于設置哪些 HTTP 方法的響應可以被緩存。

Syntax:	uwsgi_cache_methods GET | HEAD | POST ...;
Default:	uwsgi_cache_methods GET HEAD;
Context:	http, server, location

• GET：允許緩存 GET 請求的響應。
• HEAD：允許緩存 HEAD 請求的響應。
• POST：允許緩存 POST 請求的響應。
• 其他方法：如 PUT、DELETE 等可以根據需要添加。

案例

基本用法

最簡單的 uwsgi_cache_methods 用法是指定允許緩存的方法：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 允許緩存 GET、HEAD 和 POST 請求的響應uwsgi_cache_methods GET HEAD POST;uwsgi_cache my_cache;}
}

在這個例子中：

• 允許緩存 GET、HEAD 和 POST 請求的響應。

使用默認值

你可以選擇使用默認值：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 使用默認值（僅允許緩存 GET 和 HEAD 請求的響應）uwsgi_cache_methods GET HEAD;uwsgi_cache my_cache;}
}

在這個例子中：

• 僅允許緩存 GET 和 HEAD 請求的響應（默認值）。

注意事項

• 安全性：確保只有安全且適合緩存的 HTTP 方法被啟用。例如，通常不建議緩存 POST 請求的響應，因為它們通常是動態生成的。
• 適用場景：適用于需要根據不同的 HTTP 方法來管理緩存的應用場景。例如，在 RESTful API 中，可能需要緩存 GET 請求的結果，但不緩存 POST 請求的結果。
• 調試和監控：如果你遇到緩存方法問題，可以檢查以下幾點：
  • 確保啟用的 HTTP 方法符合實際需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_cache_min_uses

uwsgi_cache_min_uses 指令用于設置一個響應必須被請求多少次才能被緩存。

Syntax:	uwsgi_cache_min_uses number;
Default:	uwsgi_cache_min_uses 1;
Context:	http, server, location

• number：指定響應必須被請求的次數，默認值為 1。

案例

基本用法

最簡單的 uwsgi_cache_min_uses 用法是指定最小請求次數：

server {listen 80;server_name example.com;location /data/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 設置響應必須被請求 3 次才能被緩存uwsgi_cache_min_uses 3;uwsgi_cache my_cache;}
}

在這個例子中：

• 響應必須被請求 3 次才能被緩存。

使用默認值

你可以選擇使用默認值：

server {listen 80;server_name example.com;location /data/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 使用默認值（響應只需被請求 1 次即可被緩存）uwsgi_cache_min_uses 1;uwsgi_cache my_cache;}
}

在這個例子中：

• 響應只需被請求 1 次即可被緩存（默認值）。

注意事項

• 性能優化：合理設置最小請求次數可以減少不必要的緩存更新，特別是在高并發場景下。
• 適用場景：適用于需要控制緩存頻率的應用場景。例如，在高流量網站中，適當增加最小請求次數可以減少緩存的頻繁更新。
• 調試和監控：如果你遇到最小請求次數問題，可以檢查以下幾點：
  • 確保數值設置合理，不會導致緩存過早或過晚更新。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_cache_path

uwsgi_cache_path 指令用于定義緩存存儲的位置及其參數。

Syntax:	uwsgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [min_free=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];
Default:	—
Context:	http

• path：指定緩存存儲的路徑。
• levels：指定緩存文件的目錄層次結構。
• use_temp_path：是否使用臨時目錄進行寫入操作。
• keys_zone：指定共享內存區的名稱和大小。
• inactive：指定緩存項在未訪問期間保持有效的最大時間。
• max_size：指定緩存的最大尺寸。
• min_free：指定緩存分區中應保留的最小空閑空間。
• manager_files：指定每次清理時要刪除的緩存文件數。
• manager_sleep：指定每次清理之間的睡眠時間。
• manager_threshold：指定每次清理的最大執行時間。
• loader_files：指定每次加載時要加載的緩存文件數。
• loader_sleep：指定每次加載之間的睡眠時間。
• loader_threshold：指定每次加載的最大執行時間。
• purger：是否啟用緩存清除器。
• purger_files：指定每次清除時要刪除的緩存文件數。
• purger_sleep：指定每次清除之間的睡眠時間。
• purger_threshold：指定每次清除的最大執行時間。

案例

基本用法

最簡單的 uwsgi_cache_path 用法是指定緩存存儲的基本參數：

http {uwsgi_cache_path /var/cache/nginx/uwsgi levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;uwsgi_cache my_cache;uwsgi_cache_valid 200 1h;}}
}

在這個例子中：

• 緩存存儲在 /var/cache/nginx/uwsgi 目錄下。
• 目錄層次結構為 1:2。
• 共享內存區名為 my_cache，大小為 10MB。
• 緩存項在未訪問期間保持有效的時間為 60 分鐘。
• 緩存的最大尺寸為 1GB。

更詳細的配置

你可以進一步細化配置：

http {uwsgi_cache_path /var/cache/nginx/uwsgi levels=1:2 use_temp_path=off keys_zone=my_cache:10m inactive=60m max_size=1g min_free=100m manager_files=100 manager_sleep=50ms manager_threshold=200ms loader_files=100 loader_sleep=50ms loader_threshold=200ms purger=on purger_files=100 purger_sleep=50ms purger_threshold=200ms;server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;uwsgi_cache my_cache;uwsgi_cache_valid 200 1h;}}
}

在這個例子中：

• 啟用了更多的緩存管理選項，如 min_free、manager_files、loader_files 和 purger。

注意事項

• 緩存管理：合理配置緩存路徑及相關參數可以顯著提高緩存性能和穩定性。確保路徑具有足夠的存儲空間，并定期清理無效緩存。
• 適用場景：適用于需要詳細管理緩存存儲和性能的應用場景。例如，在高流量網站或復雜應用中，適當的緩存配置可以顯著提升系統性能。
• 調試和監控：如果你遇到緩存路徑問題，可以檢查以下幾點：
  • 確保路徑設置正確且具有足夠的權限。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_cache_purge

uwsgi_cache_purge 指令用于指定哪些請求可以清除緩存。這對于在特定條件下（如內容更新時）手動或自動清除緩存非常有用。

Syntax:	uwsgi_cache_purge string ...;
Default:	—
Context:	http, server, location
This directive appeared in version 1.5.7.

• string：指定一個或多個條件字符串，匹配這些條件的請求將觸發緩存清除操作。

案例

基本用法

假設我們希望允許通過帶有特定查詢參數（如 purge=true）的請求來清除緩存：

http {uwsgi_cache_path /tmp/uwsgicache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_purge $arg_purge purge;  # 如果請求包含 ?purge=purge，則清除緩存}}
}

在這個例子中，如果請求包含 ?purge=purge 查詢參數，Nginx 將清除相應的緩存條目。

注意事項

• 安全性：確保只有授權用戶或系統能夠觸發緩存清除操作，以防止濫用。
• 性能影響：頻繁的緩存清除操作可能會影響性能，需合理規劃。

uwsgi_cache_revalidate

uwsgi_cache_revalidate 指令用于控制是否在緩存過期后重新驗證緩存內容。這對于確保緩存數據的及時性和準確性非常重要。

Syntax:	uwsgi_cache_revalidate on | off;
Default:	uwsgi_cache_revalidate off;
Context:	http, server, location
This directive appeared in version 1.5.7.

• on：當緩存過期時，Nginx 將向后端服務器發送一個條件請求（如 If-Modified-Since 或 If-None-Match），以檢查是否有更新的內容。
• off（默認）：當緩存過期時，Nginx 將直接從后端服務器獲取新內容。

案例

啟用重新驗證

假設我們希望在緩存過期后重新驗證緩存內容：

http {uwsgi_cache_path /tmp/uwsgicache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_revalidate on;  # 在緩存過期后重新驗證}}
}

禁用重新驗證

如果我們不希望在緩存過期后重新驗證：

http {uwsgi_cache_path /tmp/uwsgicache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_revalidate off;  # 默認行為，直接從后端服務器獲取新內容}}
}

注意事項

• 性能優化：啟用重新驗證可以在一定程度上減少不必要的全量請求，提高緩存命中率。
• 帶寬節省：使用條件請求可以節省帶寬，特別是在靜態資源較多的情況下。

uwsgi_cache_use_stale

uwsgi_cache_use_stale 指令用于控制在某些錯誤情況下是否使用過期的緩存內容。這對于提高服務的可用性非常有用，尤其是在后端服務器不可用時。

Syntax:	uwsgi_cache_use_stale error | timeout | invalid_header | updating | http_500 | http_503 | http_403 | http_404 | http_429 | off ...;
Default:	uwsgi_cache_use_stale off;
Context:	http, server, location

• error：當與后端服務器的連接發生錯誤時使用過期緩存。
• timeout：當與后端服務器的連接超時時使用過期緩存。
• invalid_header：當收到無效響應頭時使用過期緩存。
• updating：當正在更新緩存時使用過期緩存。
• http_500、http_503、http_403、http_404、http_429：分別對應不同的HTTP狀態碼。
• off（默認）：不使用過期緩存。

案例

使用多種錯誤情況下的過期緩存

假設我們希望在多種錯誤情況下使用過期緩存：

http {uwsgi_cache_path /tmp/uwsgicache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_use_stale error timeout invalid_header http_500 http_503;  # 在多種錯誤情況下使用過期緩存}}
}

禁用過期緩存

如果我們不希望在任何錯誤情況下使用過期緩存：

http {uwsgi_cache_path /tmp/uwsgicache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;uwsgi_cache_use_stale off;  # 默認行為，不使用過期緩存}}
}

注意事項

• 服務可用性：在后端服務器不可用時提供過期但可用的內容，可以顯著提高用戶體驗。
• 一致性：需要權衡緩存一致性和服務可用性之間的關系，避免長時間顯示過期內容。

uwsgi_cache_valid

uwsgi_cache_valid 指令用于設置不同HTTP響應碼的緩存有效期。這對于控制緩存策略和確保緩存內容的有效性非常重要。

Syntax:	uwsgi_cache_valid [code ...] time;
Default:	—
Context:	http, server, location

• code：指定一個或多個HTTP響應碼（如 200、404、500 等）。
• time：指定緩存有效時間，格式為 time[units]，例如 1h 表示1小時。

案例

設置不同響應碼的緩存有效期

假設我們希望對不同的HTTP響應碼設置不同的緩存有效期：

http {uwsgi_cache_path /tmp/uwsgicache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;# 對200響應碼設置1小時的緩存有效期uwsgi_cache_valid 200 1h;# 對404響應碼設置1分鐘的緩存有效期uwsgi_cache_valid 404 1m;# 對所有其他響應碼設置5分鐘的緩存有效期uwsgi_cache_valid any 5m;}}
}

設置統一的緩存有效期

如果我們希望對所有響應碼設置相同的緩存有效期：

http {uwsgi_cache_path /tmp/uwsgicache levels=1:2 keys_zone=mycache:10m;server {listen 80;server_name example.com;location / {uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_cache mycache;# 對所有響應碼設置1小時的緩存有效期uwsgi_cache_valid any 1h;}}
}

注意事項

• 緩存策略：根據實際需求設置合理的緩存有效期，確保緩存內容的新鮮度和有效性。
• 性能優化：適當調整緩存有效期，可以顯著提高性能并減少后端服務器負載。

uwsgi_connect_timeout

uwsgi_connect_timeout 指令用于設置 Nginx 與 uWSGI 服務器建立連接的超時時間。這有助于防止長時間等待導致的性能問題。

Syntax:	uwsgi_connect_timeout time;
Default: uwsgi_connect_timeout 60s;
Context: http, server, location

• time：Nginx 與 uWSGI 服務器建立連接的超時時間，默認為 60 秒。

案例

基本用法

最簡單的 uwsgi_connect_timeout 用法是指定連接超時時間：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 設置連接超時時間為 30 秒uwsgi_connect_timeout 30s;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶訪問 example.com 時，Nginx 將嘗試在 30 秒內與 uWSGI 服務器建立連接。如果超過這個時間仍未成功連接，Nginx 將返回錯誤。

注意事項

• 性能影響：過長的超時時間可能導致請求延遲，過短的超時時間可能導致頻繁失敗。
• 可靠性：確保 uWSGI 服務器的可用性和響應速度，以避免不必要的超時。

uwsgi_force_ranges

uwsgi_force_ranges 指令用于強制啟用對部分內容請求（Range Requests）的支持。這使得 Nginx 可以處理客戶端的部分內容請求，即使 uWSGI 服務器未明確支持。

Syntax:	uwsgi_force_ranges on | off;
Default: uwsgi_force_ranges off;
Context: http, server, location
This directive appeared in version 1.7.7.

• on：強制啟用 Range Requests 支持。
• off：不強制啟用 Range Requests 支持，默認行為。

案例

基本用法

最簡單的 uwsgi_force_ranges 用法是啟用或禁用強制范圍請求支持：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 強制啟用 Range Requests 支持uwsgi_force_ranges on;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶發送部分內容請求時，Nginx 將處理這些請求并從 uWSGI 服務器獲取相應的內容片段，即使 uWSGI 服務器本身未明確支持 Range Requests。

注意事項

• 兼容性：確保應用程序能夠正確處理部分內容請求，特別是在啟用強制支持的情況下。
• 性能優化：合理使用 Range Requests 可以提高大文件下載的用戶體驗，但也可能增加服務器負載。

uwsgi_hide_header

uwsgi_hide_header 指令用于隱藏來自 uWSGI 服務器響應中的特定 HTTP 頭字段。這有助于控制傳遞給客戶端的響應頭信息。

Syntax:	uwsgi_hide_header field;
Default: —
Context: http, server, location

• field：需要隱藏的 HTTP 頭字段名稱。

案例

基本用法

最簡單的 uwsgi_hide_header 用法是指定要隱藏的響應頭字段：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 隱藏 X-Powered-By 響應頭uwsgi_hide_header X-Powered-By;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當 uWSGI 服務器返回響應時，Nginx 將隱藏 X-Powered-By 響應頭字段，使其不會傳遞給客戶端。

注意事項

• 安全性：隱藏敏感的響應頭字段可以減少潛在的安全風險，如暴露技術棧信息。
• 調試和監控：在開發和調試過程中，確保必要的響應頭字段未被誤隱藏。

uwsgi_ignore_client_abort

uwsgi_ignore_client_abort 指令用于控制當客戶端中斷連接時，Nginx 是否繼續處理與 uWSGI 服務器的請求。這有助于提高后臺任務的可靠性和完整性。

Syntax:	uwsgi_ignore_client_abort on | off;
Default: uwsgi_ignore_client_abort off;
Context: http, server, location

• on：當客戶端中斷連接時，Nginx 繼續處理與 uWSGI 服務器的請求。
• off：當客戶端中斷連接時，Nginx 中止與 uWSGI 服務器的請求，默認行為。

案例

基本用法

最簡單的 uwsgi_ignore_client_abort 用法是啟用或禁用忽略客戶端中斷：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 啟用忽略客戶端中斷uwsgi_ignore_client_abort on;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶中斷連接時，Nginx 將繼續處理與 uWSGI 服務器的請求，直到完成或遇到其他錯誤。

注意事項

• 后臺任務：對于需要保證執行完整性的后臺任務（如數據導入/導出），啟用該選項可以確保任務不會因客戶端中斷而終止。
• 資源管理：注意不要濫用此選項，以免在高并發環境下占用過多資源。

uwsgi_ignore_headers

uwsgi_ignore_headers 用于指定哪些響應頭不應傳遞給客戶端。這有助于控制從 uwsgi 后端服務器返回的響應頭，避免不必要的或潛在有害的頭信息被傳遞。

Syntax: uwsgi_ignore_headers field ...;
Default: —
Context: http, server, location

• field：指定一個或多個響應頭字段名稱，這些字段將不會傳遞給客戶端。

案例

基本用法

最簡單的 uwsgi_ignore_headers 用法是指定要忽略的響應頭：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ignore_headers Set-Cookie X-Accel-Redirect;  # 忽略 Set-Cookie 和 X-Accel-Redirect 響應頭}
}

在這個例子中，設置了 uwsgi_ignore_headers Set-Cookie X-Accel-Redirect，這意味著 Nginx 將不會將 Set-Cookie 和 X-Accel-Redirect 響應頭傳遞給客戶端。

多個響應頭

根據實際需求忽略多個響應頭：

server {listen 80;server_name example.com;location /ignore_multiple_headers/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ignore_headers Cache-Control Expires Pragma;  # 忽略多個響應頭}location /ignore_single_header/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ignore_headers Server;  # 僅忽略 Server 響應頭}
}

在這個例子中：

• 對于 /ignore_multiple_headers/ 路徑下的請求，忽略了 Cache-Control、Expires 和 Pragma 響應頭。
• 對于 /ignore_single_header/ 路徑下的請求，僅忽略了 Server 響應頭。

注意事項

• 安全性：確保忽略不必要的響應頭，以提高安全性并減少信息泄露。
• 功能完整性：謹慎選擇要忽略的響應頭，確保不會影響應用的功能和性能。

uwsgi_intercept_errors

uwsgi_intercept_errors 用于控制是否攔截 uwsgi 后端返回的錯誤頁面，并允許 Nginx 提供自定義的錯誤頁面。這有助于提供一致的用戶體驗，并增強錯誤處理能力。

Syntax: uwsgi_intercept_errors on | off;
Default: uwsgi_intercept_errors off;
Context: http, server, location

• on：啟用錯誤攔截（Nginx 將處理后端返回的錯誤狀態碼）。
• off：禁用錯誤攔截（默認行為，后端直接返回錯誤頁面）。

案例

基本用法

最簡單的 uwsgi_intercept_errors 用法是啟用錯誤攔截：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_intercept_errors on;  # 啟用錯誤攔截error_page 500 502 503 504 /50x.html;  # 定義自定義錯誤頁面}
}

在這個例子中，啟用了錯誤攔截，并指定了自定義的 5xx 錯誤頁面 /50x.html。

禁用錯誤攔截

根據實際需求禁用錯誤攔截：

server {listen 80;server_name example.com;location /no_intercept/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_intercept_errors off;  # 禁用錯誤攔截}
}

在這個例子中，對于 /no_intercept/ 路徑下的請求，禁用了錯誤攔截功能，后端直接返回錯誤頁面。

注意事項

• 用戶體驗：啟用錯誤攔截可以提供更友好的用戶界面，但需要確保自定義錯誤頁面的設計合理。
• 錯誤處理：結合 error_page 指令，定義合適的錯誤頁面路徑和內容。

uwsgi_limit_rate

uwsgi_limit_rate 用于限制從 uwsgi 后端傳輸到客戶端的數據速率。這有助于控制帶寬使用，特別是在高流量場景下。

Syntax: uwsgi_limit_rate rate;
Default: uwsgi_limit_rate 0;
Context: http, server, location
This directive appeared in version 1.7.7.

• rate：指定數據傳輸速率（字節/秒）。默認值為 0，表示不限制速率。

案例

基本用法

最簡單的 uwsgi_limit_rate 用法是指定傳輸速率：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_limit_rate 1024k;  # 限制傳輸速率為 1024 KB/s}
}

在這個例子中，設置了 uwsgi_limit_rate 1024k，這意味著傳輸速率限制為 1024 KB/s。

動態調整速率

根據實際需求動態調整傳輸速率：

server {listen 80;server_name example.com;location /low_rate/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_limit_rate 512k;  # 較低的傳輸速率}location /high_rate/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_limit_rate 2048k;  # 較高的傳輸速率}
}

在這個例子中：

• 對于 /low_rate/ 路徑下的請求，傳輸速率限制為 512 KB/s。
• 對于 /high_rate/ 路徑下的請求，傳輸速率限制為 2048 KB/s。

注意事項

• 帶寬管理：合理設置傳輸速率，確保既能滿足應用需求，又不會過度占用帶寬資源。
• 用戶體驗：在高延遲或低帶寬場景下，適當降低傳輸速率可能有助于改善用戶體驗。

uwsgi_max_temp_file_size

uwsgi_max_temp_file_size 用于設置 uwsgi 請求臨時文件的最大大小。當 uwsgi 響應體超過此大小時，Nginx 將其寫入臨時文件而不是內存中。

Syntax: uwsgi_max_temp_file_size size;
Default: uwsgi_max_temp_file_size 1024m;
Context: http, server, location

• size：指定臨時文件的最大大小，默認值為 1024 MB。

案例

基本用法

最簡單的 uwsgi_max_temp_file_size 用法是指定臨時文件的最大大小：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_max_temp_file_size 512m;  # 設置臨時文件最大大小為 512 MB}
}

在這個例子中，設置了 uwsgi_max_temp_file_size 512m，這意味著臨時文件的最大大小為 512 MB。

調整臨時文件大小

根據實際需求調整臨時文件大小：

server {listen 80;server_name example.com;location /small_temp_files/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_max_temp_file_size 256m;  # 較小的臨時文件大小}location /large_temp_files/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_max_temp_file_size 2048m;  # 較大的臨時文件大小}
}

在這個例子中：

• 對于 /small_temp_files/ 路徑下的請求，臨時文件的最大大小為 256 MB。
• 對于 /large_temp_files/ 路徑下的請求，臨時文件的最大大小為 2048 MB。

注意事項

• 內存管理：合理設置臨時文件大小，避免因大響應體導致內存溢出或其他問題。
• 磁盤使用：確保有足夠的磁盤空間來存儲臨時文件，特別是在高負載情況下。

uwsgi_modifier1

uwsgi_modifier1 指令用于設置 UWSGI 協議的第一個修飾符（modifier1）。這個指令幫助定義請求如何被處理。

Syntax:	uwsgi_modifier1 number;
Default:	uwsgi_modifier1 0;
Context:	http, server, location

• number：指定一個整數值作為第一個修飾符，默認為 0。

案例

基本用法

最簡單的 uwsgi_modifier1 用法是指定一個具體的修飾符值：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_modifier1 1;}
}

在這個例子中：

• 設置了 uwsgi_modifier1 1，這意味著Nginx將使用修飾符1來處理請求。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置不同的修飾符值：

server {listen 80;server_name example1.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example1.sock;uwsgi_modifier1 1;}
}server {listen 80;server_name example2.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example2.sock;uwsgi_modifier1 2;}
}

在這個例子中：

• 對于 example1.com，設置了 uwsgi_modifier1 1。
• 對于 example2.com，設置了 uwsgi_modifier1 2。

注意事項

• 協議兼容性：確保設置的修飾符與UWSGI應用服務器的期望值一致，以避免通信問題。
• 適用場景：適用于需要通過UWSGI協議傳遞特定信息的應用場景。例如，在需要自定義請求處理邏輯的復雜應用中使用。
• 調試和監控：如果你遇到修飾符問題，可以檢查以下幾點：
  • 確保修飾符設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_modifier2

uwsgi_modifier2 指令用于設置 UWSGI 協議的第二個修飾符（modifier2）。這個指令進一步幫助定義請求如何被處理。

Syntax:	uwsgi_modifier2 number;
Default:	uwsgi_modifier2 0;
Context:	http, server, location

• number：指定一個整數值作為第二個修飾符，默認為 0。

案例

基本用法

最簡單的 uwsgi_modifier2 用法是指定一個具體的修飾符值：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_modifier2 1;}
}

在這個例子中：

• 設置了 uwsgi_modifier2 1，這意味著Nginx將使用修飾符1來處理請求。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置不同的修飾符值：

server {listen 80;server_name example1.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example1.sock;uwsgi_modifier2 1;}
}server {listen 80;server_name example2.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example2.sock;uwsgi_modifier2 2;}
}

在這個例子中：

• 對于 example1.com，設置了 uwsgi_modifier2 1。
• 對于 example2.com，設置了 uwsgi_modifier2 2。

注意事項

• 協議兼容性：確保設置的修飾符與UWSGI應用服務器的期望值一致，以避免通信問題。
• 適用場景：適用于需要通過UWSGI協議傳遞更多特定信息的應用場景。例如，在需要更復雜的請求處理邏輯的高級應用中使用。
• 調試和監控：如果你遇到修飾符問題，可以檢查以下幾點：
  • 確保修飾符設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_next_upstream

uwsgi_next_upstream 指令用于控制當出現某些錯誤時是否嘗試轉發到下一個上游服務器。這個指令幫助提高請求的成功率。

Syntax:	uwsgi_next_upstream error | timeout | invalid_header | http_500 | http_503 | http_403 | http_404 | http_429 | non_idempotent | off ...;
Default:	uwsgi_next_upstream error timeout;
Context:	http, server, location

• error：在發生錯誤時重試。
• timeout：在超時時重試。
• invalid_header：在接收到無效響應頭時重試。
• http_500：在接收HTTP 500響應時重試。
• http_503：在接收HTTP 503響應時重試。
• http_403：在接收HTTP 403響應時重試。
• http_404：在接收HTTP 404響應時重試。
• http_429：在接收HTTP 429響應時重試。
• non_idempotent：允許對非冪等請求進行重試。
• off：禁用重試功能。

案例

基本用法

最簡單的 uwsgi_next_upstream 用法是指定哪些情況會觸發重試：

upstream backend {server backend1.example.com;server backend2.example.com;
}server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_next_upstream error timeout http_500 http_503;}
}

在這個例子中：

• 設置了 uwsgi_next_upstream error timeout http_500 http_503，這意味著Nginx將在發生錯誤、超時或接收到HTTP 500或503響應時重試。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置不同的重試策略：

upstream backend_group1 {server backend1.example.com;server backend2.example.com;
}upstream backend_group2 {server backend3.example.com;server backend4.example.com;
}server {listen 80;server_name example.com;location /group1/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_group1.sock;uwsgi_next_upstream error timeout;}location /group2/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_group2.sock;uwsgi_next_upstream error timeout http_500 http_503;}
}

在這個例子中：

• 對于 /group1/ 路徑，設置了 uwsgi_next_upstream error timeout。
• 對于 /group2/ 路徑，設置了 uwsgi_next_upstream error timeout http_500 http_503。

注意事項

• 重試策略：合理設置重試條件，避免不必要的重試影響性能或導致其他問題。
• 適用場景：適用于需要提高請求成功率的應用場景。例如，在高可用性網站、API網關等環境中使用。
• 調試和監控：如果你遇到重試策略問題，可以檢查以下幾點：
  • 確保重試條件設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_next_upstream_timeout

uwsgi_next_upstream_timeout 指令用于設置在嘗試將請求傳遞給下一個上游服務器之前的最大等待時間。這個指令幫助控制請求在失敗后重試其他上游服務器的超時時間。

Syntax:	uwsgi_next_upstream_timeout time;
Default:	uwsgi_next_upstream_timeout 0;
Context:	http, server, location
This directive appeared in version 1.7.5.

• time：指定最大等待時間。如果設置為 0，則表示沒有超時限制，默認值是 0。

案例

基本用法

最簡單的 uwsgi_next_upstream_timeout 用法是指定一個具體的時間值：

http {upstream backend {server backend1.example.com;server backend2.example.com;}server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_next_upstream_timeout 5s;}}
}

在這個例子中：

• 設置了 uwsgi_next_upstream_timeout 5s，這意味著Nginx將在嘗試將請求傳遞給下一個上游服務器之前等待最多5秒。

動態設置不同配置

你可以根據不同的域名或服務器塊動態設置不同的超時時間：

server {listen 80;server_name example1.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example1.sock;uwsgi_next_upstream_timeout 3s;}
}server {listen 80;server_name example2.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi_example2.sock;uwsgi_next_upstream_timeout 10s;}
}

在這個例子中：

• 對于 example1.com，設置了 uwsgi_next_upstream_timeout 3s。
• 對于 example2.com，設置了 uwsgi_next_upstream_timeout 10s。

注意事項

• 超時管理：合理設置最大等待時間，避免過長導致的請求阻塞或過短影響重試機制的有效性。
• 適用場景：適用于需要在請求失敗后自動重試其他上游服務器的應用場景。例如，在高可用性和負載均衡環境中使用。
• 調試和監控：如果你遇到超時問題，可以檢查以下幾點：
  • 確保超時時間設置合理，并符合你的需求。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。
  • 使用工具模擬不同負載條件下的請求進行測試，確保在各種情況下都能正常工作。

uwsgi_next_upstream_tries

uwsgi_next_upstream_tries 指令用于設置嘗試將請求傳遞給下一個上游服務器的最大次數。

Syntax:	uwsgi_next_upstream_tries number;
Default:	uwsgi_next_upstream_tries 0;
Context:	http, server, location
This directive appeared in version 1.7.5.

• number：指定最大嘗試次數，默認值為 0（表示不限制）。

案例

基本用法

最簡單的 uwsgi_next_upstream_tries 用法是指定最大嘗試次數：

server {listen 80;server_name example.com;upstream backend {server backend1.example.com;server backend2.example.com;server backend3.example.com;}location /api/ {uwsgi_pass backend;include uwsgi_params;# 設置最多嘗試 2 次將請求傳遞給下一個上游服務器uwsgi_next_upstream_tries 2;}
}

在這個例子中：

• 最多嘗試 2 次將請求傳遞給下一個上游服務器。

使用默認值

你可以選擇使用默認值（不限制嘗試次數）：

server {listen 80;server_name example.com;upstream backend {server backend1.example.com;server backend2.example.com;server backend3.example.com;}location /api/ {uwsgi_pass backend;include uwsgi_params;# 使用默認值（不限制嘗試次數）uwsgi_next_upstream_tries 0;}
}

在這個例子中：

• 不限制嘗試次數（默認值）。

注意事項

• 容錯能力：合理設置最大嘗試次數可以提高系統的容錯能力，但過多的嘗試可能會增加延遲。
• 適用場景：適用于需要高可用性和容錯能力的應用場景。例如，在負載均衡和故障轉移場景中，適當設置最大嘗試次數可以提高系統的穩定性。
• 調試和監控：如果你遇到嘗試次數問題，可以檢查以下幾點：
  • 確保數值設置合理，不會導致過多的重試或過早放棄。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_no_cache

uwsgi_no_cache 指令用于定義哪些條件下的響應不應被緩存。

Syntax:	uwsgi_no_cache string ...;
Default:	—
Context:	http, server, location

• string：指定一個或多個條件表達式，滿足這些條件時響應不應被緩存。

案例

基本用法

最簡單的 uwsgi_no_cache 用法是指定不緩存的條件：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 當 $cookie_nocache 存在時不緩存響應uwsgi_no_cache $cookie_nocache;uwsgi_cache my_cache;}
}

在這個例子中：

• 如果請求包含 $cookie_nocache 變量，則響應不會被緩存。

多個條件

你可以指定多個條件：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 當 $cookie_nocache 或 $arg_debug 存在時不緩存響應uwsgi_no_cache $cookie_nocache $arg_debug;uwsgi_cache my_cache;}
}

在這個例子中：

• 如果請求包含 $cookie_nocache 或 $arg_debug 變量，則響應不會被緩存。

注意事項

• 靈活性：通過設置不同的條件表達式，可以根據實際需求靈活地控制哪些響應不應被緩存。
• 適用場景：適用于需要根據特定條件控制緩存行為的應用場景。例如，在處理用戶登錄狀態或調試模式時，可能需要禁用緩存。
• 調試和監控：如果你遇到不緩存條件問題，可以檢查以下幾點：
  • 確保條件表達式正確無誤。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_param

uwsgi_param 指令用于向 uWSGI 服務器傳遞參數。

Syntax:	uwsgi_param parameter value [if_not_empty];
Default:	—
Context:	http, server, location

• parameter：指定要傳遞的參數名稱。
• value：指定參數的值。
• if_not_empty：可選參數，僅在值不為空時傳遞該參數。

案例

基本用法

最簡單的 uwsgi_param 用法是傳遞一個參數：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 向 uWSGI 服務器傳遞自定義參數uwsgi_param CUSTOM_HEADER "CustomValue";}
}

在這個例子中：

• 向 uWSGI 服務器傳遞了一個名為 CUSTOM_HEADER 的參數，其值為 CustomValue。

使用 if_not_empty 選項

你可以使用 if_not_empty 選項，僅在值不為空時傳遞參數：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 僅在值不為空時傳遞自定義參數uwsgi_param CUSTOM_HEADER $http_custom_header if_not_empty;}
}

在這個例子中：

• 僅在 $http_custom_header 變量不為空時，才會向 uWSGI 服務器傳遞 CUSTOM_HEADER 參數。

注意事項

• 參數傳遞：確保傳遞的參數與 uWSGI 應用的需求匹配，避免不必要的參數傳遞。
• 適用場景：適用于需要在 Nginx 和 uWSGI 之間傳遞額外信息的應用場景。例如，在處理自定義 HTTP 頭部或動態參數時，可以通過 uwsgi_param 進行傳遞。
• 調試和監控：如果你遇到參數傳遞問題，可以檢查以下幾點：
  • 確保參數名稱和值正確無誤。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_pass

uwsgi_pass 指令用于指定 uWSGI 服務器的地址。

Syntax:	uwsgi_pass [protocol://]address;
Default:	—
Context:	location, if in location

• protocol：可選參數，指定協議（通常為 unix:// 或 127.0.0.1:）。
• address：指定 uWSGI 服務器的地址，可以是 Unix 套接字路徑或 IP 地址加端口號。

案例

基本用法

最簡單的 uwsgi_pass 用法是指定 uWSGI 服務器的地址：

server {listen 80;server_name example.com;location /api/ {# 將請求轉發到本地的 uWSGI 服務器，使用 Unix 套接字uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;}
}

在這個例子中：

• 請求被轉發到位于 /tmp/uwsgi.sock 的 uWSGI 服務器。

使用 IP 地址和端口

你也可以使用 IP 地址和端口：

server {listen 80;server_name example.com;location /api/ {# 將請求轉發到遠程的 uWSGI 服務器uwsgi_pass 192.168.1.10:3031;include uwsgi_params;}
}

在這個例子中：

• 請求被轉發到 IP 地址為 192.168.1.10，端口號為 3031 的 uWSGI 服務器。

注意事項

• 地址配置：確保 uWSGI 服務器的地址配置正確，并且具有適當的權限訪問套接字或網絡端口。
• 適用場景：適用于需要將請求轉發到 uWSGI 服務器的應用場景。例如，在部署 Python Web 應用時，通常會使用 uwsgi_pass 將請求轉發到 uWSGI 服務器。
• 調試和監控：如果你遇到轉發地址問題，可以檢查以下幾點：
  • 確保套接字路徑或 IP 地址和端口號正確無誤。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_pass_header

uwsgi_pass_header 指令用于指定哪些請求頭字段應該傳遞給后端的 uWSGI 服務器。這對于在某些情況下需要控制哪些頭部信息傳遞到后端非常有用。

Syntax:	uwsgi_pass_header field;
Default:	—
Context:	http, server, location

• field：指定要傳遞的請求頭字段名稱。

案例

基本用法

假設我們希望將特定的請求頭字段（如 X-Custom-Header）傳遞給后端的 uWSGI 服務器：

http {server {listen 80;server_name example.com;location /custom {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 傳遞 X-Custom-Header 請求頭uwsgi_pass_header X-Custom-Header;}}
}

在這個例子中，uwsgi_pass_header X-Custom-Header; 確保了 X-Custom-Header 請求頭會被傳遞給后端的 uWSGI 服務器。

注意事項

• 安全性：確保只傳遞必要的請求頭字段，避免泄露敏感信息。
• 靈活性：可以根據具體需求靈活配置需要傳遞的請求頭字段。

uwsgi_pass_request_body

uwsgi_pass_request_body 指令用于控制是否將請求體傳遞給后端的 uWSGI 服務器。這對于處理某些特殊場景（如上傳文件或大請求體時）非常有用。

Syntax:	uwsgi_pass_request_body on | off;
Default:	uwsgi_pass_request_body on;
Context:	http, server, location

• on（默認）：將請求體傳遞給后端的 uWSGI 服務器。
• off：不將請求體傳遞給后端的 uWSGI 服務器。

案例

啟用請求體傳遞

假設我們希望將請求體傳遞給后端的 uWSGI 服務器：

http {server {listen 80;server_name example.com;location /upload {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 默認行為，啟用請求體傳遞uwsgi_pass_request_body on;}}
}

禁用請求體傳遞

如果我們不希望將請求體傳遞給后端的 uWSGI 服務器：

http {server {listen 80;server_name example.com;location /no-body {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 禁用請求體傳遞uwsgi_pass_request_body off;}}
}

注意事項

• 性能影響：禁用請求體傳遞可以減少網絡傳輸的數據量，但可能導致后端無法正確處理請求。
• 適用場景：適用于不需要請求體的場景，如健康檢查或簡單的狀態查詢。

uwsgi_pass_request_headers

uwsgi_pass_request_headers 指令用于控制是否將請求頭傳遞給后端的 uWSGI 服務器。這對于處理某些特殊場景（如自定義請求頭過濾）非常有用。

Syntax:	uwsgi_pass_request_headers on | off;
Default:	uwsgi_pass_request_headers on;
Context:	http, server, location

• on（默認）：將請求頭傳遞給后端的 uWSGI 服務器。
• off：不將請求頭傳遞給后端的 uWSGI 服務器。

案例

啟用請求頭傳遞

假設我們希望將請求頭傳遞給后端的 uWSGI 服務器：

http {server {listen 80;server_name example.com;location /default {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 默認行為，啟用請求頭傳遞uwsgi_pass_request_headers on;}}
}

禁用請求頭傳遞

如果我們不希望將請求頭傳遞給后端的 uWSGI 服務器：

http {server {listen 80;server_name example.com;location /no-headers {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 禁用請求頭傳遞uwsgi_pass_request_headers off;}}
}

注意事項

• 安全性：禁用請求頭傳遞可以防止潛在的安全風險，特別是當請求頭包含敏感信息時。
• 靈活性：可以根據具體需求靈活配置是否傳遞請求頭。

uwsgi_read_timeout

uwsgi_read_timeout 指令用于設置從后端 uWSGI 服務器讀取響應的超時時間。這對于確保請求不會因為后端響應過慢而長時間掛起非常有用。

Syntax:	uwsgi_read_timeout time;
Default:	uwsgi_read_timeout 60s;
Context:	http, server, location

• time：指定超時時間，格式為 time[units]，例如 60s 表示60秒。

案例

設置較長的超時時間

假設我們希望設置較長的超時時間為120秒（2分鐘）：

http {server {listen 80;server_name example.com;location /long-processing {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 設置120秒的讀取超時時間uwsgi_read_timeout 120s;}}
}

使用默認超時時間

如果我們希望使用默認的60秒超時時間：

http {server {listen 80;server_name example.com;location /default-timeout {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 使用默認的60秒超時時間uwsgi_read_timeout 60s;}}
}

注意事項

• 性能優化：適當調整超時時間，可以在保證響應速度的同時避免不必要的等待。
• 用戶體驗：過長的超時時間可能導致用戶長時間等待，需根據實際業務需求進行調整。

uwsgi_request_buffering

uwsgi_request_buffering 指令用于控制是否啟用客戶端請求的緩沖功能。這有助于提高性能，但可能會影響實時性。

Syntax:	uwsgi_request_buffering on | off;
Default: uwsgi_request_buffering on;
Context: http, server, location
This directive appeared in version 1.7.11.

• on：啟用客戶端請求的緩沖功能，默認行為。
• off：禁用客戶端請求的緩沖功能。

案例

基本用法

最簡單的 uwsgi_request_buffering 用法是啟用或禁用請求緩沖功能：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 禁用請求緩沖功能uwsgi_request_buffering off;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶訪問 example.com 時，Nginx 將直接將客戶端請求傳遞給 uWSGI 服務器，而不進行緩沖。

注意事項

• 性能與實時性：啟用緩沖功能可以提高性能，但在某些情況下（如實時應用）可能需要禁用緩沖。
• 資源管理：禁用緩沖功能可能導致更高的內存和 CPU 使用率，特別是在處理大數據量請求時。

uwsgi_send_timeout

uwsgi_send_timeout 指令用于設置 Nginx 向 uWSGI 服務器發送請求的超時時間。這有助于防止長時間等待導致的性能問題。

Syntax:	uwsgi_send_timeout time;
Default: uwsgi_send_timeout 60s;
Context: http, server, location

• time：Nginx 向 uWSGI 服務器發送請求的超時時間，默認為 60 秒。

案例

基本用法

最簡單的 uwsgi_send_timeout 用法是指定發送超時時間：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 設置發送超時時間為 30 秒uwsgi_send_timeout 30s;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶訪問 example.com 時，Nginx 將嘗試在 30 秒內向 uWSGI 服務器發送請求。如果超過這個時間仍未成功發送，Nginx 將返回錯誤。

注意事項

• 性能影響：過長的超時時間可能導致請求延遲，過短的超時時間可能導致頻繁失敗。
• 可靠性：確保 uWSGI 服務器的可用性和響應速度，以避免不必要的超時。

uwsgi_socket_keepalive

uwsgi_socket_keepalive 指令用于控制是否啟用與 uWSGI 服務器之間的套接字保持連接（Keep-Alive）。這有助于減少建立新連接的開銷。

Syntax:	uwsgi_socket_keepalive on | off;
Default: uwsgi_socket_keepalive off;
Context: http, server, location
This directive appeared in version 1.15.6.

• on：啟用與 uWSGI 服務器之間的套接字保持連接。
• off：不啟用與 uWSGI 服務器之間的套接字保持連接，默認行為。

案例

基本用法

最簡單的 uwsgi_socket_keepalive 用法是啟用或禁用套接字保持連接：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location / {# 啟用套接字保持連接uwsgi_socket_keepalive on;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當 Nginx 與 uWSGI 服務器通信時，將使用 Keep-Alive 連接，從而減少每次請求建立新連接的開銷。

注意事項

• 性能優化：啟用套接字保持連接可以顯著提高性能，尤其是在高并發環境下。
• 資源管理：注意不要濫用此選項，以免在高負載下占用過多資源。

uwsgi_ssl_certificate

uwsgi_ssl_certificate 指令用于指定用于與 uWSGI 服務器進行 SSL/TLS 通信的證書文件路徑。這有助于確保安全的通信通道。

Syntax:	uwsgi_ssl_certificate file;
Default: —
Context: http, server, location
This directive appeared in version 1.7.8.

• file：SSL/TLS 證書文件的路徑。

案例

基本用法

最簡單的 uwsgi_ssl_certificate 用法是指定 SSL/TLS 證書文件的路徑：

http {upstream uwsgi_backend {server 127.0.0.1:3031 ssl;}server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;ssl_certificate_key /etc/nginx/ssl/example.key;location / {# 指定用于與 uWSGI 服務器進行 SSL/TLS 通信的證書文件路徑uwsgi_ssl_certificate /etc/nginx/ssl/uwsgi_example.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/uwsgi_example.key;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當 Nginx 與 uWSGI 服務器通過 SSL/TLS 進行通信時，將使用 /etc/nginx/ssl/uwsgi_example.crt 作為證書文件。

注意事項

• 安全性：確保證書文件的安全性，防止未經授權的訪問。
• 證書有效性：定期檢查并更新證書，確保其有效性和可信度。

uwsgi_ssl_certificate_cache

uwsgi_ssl_certificate_cache 用于控制 uwsgi SSL 證書的緩存行為。這有助于提高 SSL/TLS 握手的效率，特別是在頻繁使用相同證書的情況下。

Syntax: uwsgi_ssl_certificate_cache off;uwsgi_ssl_certificate_cache max=N [inactive=time] [valid=time];
Default: uwsgi_ssl_certificate_cache off;
Context: http, server, location
This directive appeared in version 1.27.4.

• off：禁用證書緩存（默認行為）。
• max=N：指定緩存的最大條目數。
• [inactive=time]：可選參數，指定條目在未被訪問的時間超過指定時間后將被移除（如 10m 表示 10 分鐘）。
• [valid=time]：可選參數，指定條目的有效時間（如 1h 表示 1 小時）。

案例

基本用法

最簡單的 uwsgi_ssl_certificate_cache 用法是啟用證書緩存并設置最大條目數：

http {uwsgi_ssl_certificate_cache max=1000 inactive=10m valid=1h;  # 啟用證書緩存，并設置相關參數server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_certificate_cache max=1000 inactive=10m valid=1h;  # 在 location 中啟用證書緩存}}
}

在這個例子中，設置了證書緩存的最大條目數為 1000，條目在未被訪問超過 10 分鐘后將被移除，且條目的有效時間為 1 小時。

禁用證書緩存

根據實際需求禁用證書緩存：

server {listen 80;server_name example.com;location /no_cert_cache/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_certificate_cache off;  # 禁用證書緩存}
}

在這個例子中，對于 /no_cert_cache/ 路徑下的請求，禁用了證書緩存功能。

注意事項

• 性能優化：合理設置緩存大小和有效期，確保既能提高性能，又不會占用過多內存資源。
• 安全性：定期更新證書，并確保緩存中的證書保持最新狀態。

uwsgi_ssl_certificate_key

uwsgi_ssl_certificate_key 用于指定 uwsgi SSL 連接使用的私鑰文件路徑。這有助于配置 SSL/TLS 安全連接。

Syntax: uwsgi_ssl_certificate_key file;
Default: —
Context: http, server, location
This directive appeared in version 1.7.8.

• file：指定包含私鑰的文件路徑。

案例

基本用法

最簡單的 uwsgi_ssl_certificate_key 用法是指定私鑰文件路徑：

server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/example.key;  # 指定私鑰文件路徑location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;}
}

在這個例子中，指定了私鑰文件路徑 /etc/nginx/ssl/example.key。

多個私鑰文件

根據實際需求指定不同的私鑰文件：

server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;location /secure_endpoint/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_certificate_key /etc/nginx/ssl/example_secure.key;  # 特定路徑的私鑰文件}location /default_endpoint/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_certificate_key /etc/nginx/ssl/example.key;  # 默認路徑的私鑰文件}
}

在這個例子中：

• 對于 /secure_endpoint/ 路徑下的請求，使用了特定路徑的私鑰文件 /etc/nginx/ssl/example_secure.key。
• 對于 /default_endpoint/ 路徑下的請求，使用了默認路徑的私鑰文件 /etc/nginx/ssl/example.key。

注意事項

• 安全性：確保私鑰文件的安全性，避免未經授權的訪問。
• 正確配置：確保私鑰文件與對應的證書文件匹配，以避免 SSL 配置錯誤。

uwsgi_ssl_ciphers

uwsgi_ssl_ciphers 用于指定 uwsgi SSL 連接允許的加密套件列表。這有助于增強 SSL/TLS 連接的安全性。

Syntax: uwsgi_ssl_ciphers ciphers;
Default: uwsgi_ssl_ciphers DEFAULT;
Context: http, server, location
This directive appeared in version 1.5.8.

• ciphers：指定一個或多個加密套件名稱，使用冒號分隔。

案例

基本用法

最簡單的 uwsgi_ssl_ciphers 用法是指定加密套件列表：

server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/example.key;uwsgi_ssl_ciphers HIGH:!aNULL:!MD5;  # 指定加密套件列表location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;}
}

在這個例子中，設置了加密套件列表為 HIGH:!aNULL:!MD5，這意味著只允許高安全性的加密套件，并排除匿名 Diffie-Hellman 和 MD5 加密算法。

自定義加密套件

根據實際需求自定義加密套件列表：

server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/example.key;location /strong_security/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384;  # 強加密套件}location /default_security/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_ciphers DEFAULT;  # 默認加密套件}
}

在這個例子中：

• 對于 /strong_security/ 路徑下的請求，使用了強加密套件。
• 對于 /default_security/ 路徑下的請求，使用了默認加密套件。

注意事項

• 安全性：選擇合適的加密套件列表，確保連接的安全性。
• 兼容性：確保所選加密套件與客戶端兼容，避免不必要的連接失敗。

uwsgi_ssl_conf_command

uwsgi_ssl_conf_command 用于向 OpenSSL 發送額外的配置命令。這有助于更細粒度地控制 SSL/TLS 配置。

Syntax: uwsgi_ssl_conf_command name value;
Default: —
Context: http, server, location
This directive appeared in version 1.19.4.

• name：指定 OpenSSL 配置命令的名稱。
• value：指定 OpenSSL 配置命令的值。

案例

基本用法

最簡單的 uwsgi_ssl_conf_command 用法是指定 OpenSSL 配置命令及其值：

server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/example.key;uwsgi_ssl_conf_command Options Mode=TLSv1.2;  # 設置 OpenSSL 配置命令location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;}
}

在這個例子中，設置了 OpenSSL 配置命令 Options Mode=TLSv1.2，這意味著強制使用 TLS 1.2 協議。

多個配置命令

根據實際需求添加多個 OpenSSL 配置命令：

server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/example.key;location /custom_tls_settings/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_conf_command Options Mode=TLSv1.2;  # 強制使用 TLS 1.2uwsgi_ssl_conf_command CipherString DOWNGRADE_SERVER;  # 設置降級服務器策略}location /default_tls_settings/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_ssl_conf_command Options Mode=TLSv1.3;  # 強制使用 TLS 1.3}
}

在這個例子中：

• 對于 /custom_tls_settings/ 路徑下的請求，設置了強制使用 TLS 1.2 和降級服務器策略。
• 對于 /default_tls_settings/ 路徑下的請求，設置了強制使用 TLS 1.3。

注意事項

• 細粒度控制：通過 uwsgi_ssl_conf_command 可以進行更細粒度的 SSL/TLS 控制，但需要謹慎使用，以免影響連接的兼容性和安全性。
• OpenSSL 文檔：參考 OpenSSL 的官方文檔，了解可用的配置命令及其作用。

uwsgi_ssl_crl

uwsgi_ssl_crl 指令用于指定包含吊銷證書列表（CRL）的文件路徑。

Syntax:	uwsgi_ssl_crl file;
Default:	—
Context:	http, server, location
This directive appeared in version 1.7.0.

• file：指定包含 CRL 的文件路徑。

案例

基本用法

最簡單的 uwsgi_ssl_crl 用法是指定包含 CRL 的文件路徑：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 啟用 SSL 并指定 CRL 文件uwsgi_ssl_certificate /etc/nginx/ssl/uwsgi.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/uwsgi.key;uwsgi_ssl_crl /etc/nginx/ssl/crl.pem;}
}

在這個例子中：

• 使用 /etc/nginx/ssl/crl.pem 文件作為 CRL 文件，以確保連接到 uWSGI 服務器時驗證客戶端證書的有效性。

注意事項

• 安全性：確保 CRL 文件是最新的，并定期更新以保持系統的安全性。
• 適用場景：適用于需要對客戶端證書進行嚴格驗證的應用場景。例如，在企業級應用或需要高安全性的環境中，使用 CRL 可以防止使用已吊銷的證書。
• 調試和監控：如果你遇到 CRL 文件問題，可以檢查以下幾點：
  • 確保文件路徑正確且具有適當的權限。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_ssl_key_log

uwsgi_ssl_key_log 指令用于指定記錄 SSL 私鑰材料的日志文件路徑。

Syntax:	uwsgi_ssl_key_log path;
Default:	—
Context:	http, server, location
This directive appeared in version 1.27.2.

• path：指定日志文件的路徑。

案例

基本用法

最簡單的 uwsgi_ssl_key_log 用法是指定日志文件的路徑：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 啟用 SSL 并指定私鑰日志文件uwsgi_ssl_certificate /etc/nginx/ssl/uwsgi.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/uwsgi.key;uwsgi_ssl_key_log /var/log/nginx/uwsgi_ssl_key.log;}
}

在這個例子中：

• 將 SSL 私鑰材料記錄到 /var/log/nginx/uwsgi_ssl_key.log 文件中。

注意事項

• 安全性：確保私鑰日志文件存儲在一個安全的位置，并限制訪問權限，以防止敏感信息泄露。
• 適用場景：適用于需要調試 SSL/TLS 連接或分析 SSL 私鑰材料的應用場景。例如，在開發和測試階段，記錄私鑰材料可以幫助排查連接問題。
• 調試和監控：如果你遇到私鑰日志文件問題，可以檢查以下幾點：
  • 確保文件路徑正確且具有適當的權限。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_ssl_name

uwsgi_ssl_name 指令用于指定用于 SSL 握手的主機名。

Syntax:	uwsgi_ssl_name name;
Default:	uwsgi_ssl_name host from uwsgi_pass;
Context:	http, server, location
This directive appeared in version 1.7.0.

• name：指定用于 SSL 握手的主機名，默認值為從 uwsgi_pass 中提取的主機名。

案例

基本用法

最簡單的 uwsgi_ssl_name 用法是指定用于 SSL 握手的主機名：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 啟用 SSL 并指定用于 SSL 握手的主機名uwsgi_ssl_certificate /etc/nginx/ssl/uwsgi.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/uwsgi.key;uwsgi_ssl_name backend.example.com;}
}

在這個例子中：

• 使用 backend.example.com 作為用于 SSL 握手的主機名。

使用默認值

你可以選擇使用默認值（從 uwsgi_pass 提取的主機名）：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 啟用 SSL 并使用默認的主機名uwsgi_ssl_certificate /etc/nginx/ssl/uwsgi.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/uwsgi.key;}
}

在這個例子中：

• 使用從 uwsgi_pass 提取的主機名作為用于 SSL 握手的主機名（默認值）。

注意事項

• 主機名匹配：確保指定的主機名與 SSL 證書中的主機名匹配，以避免 SSL 驗證失敗。
• 適用場景：適用于需要明確指定用于 SSL 握手的主機名的應用場景。例如，在多域名或多服務器環境中，明確指定主機名可以確保正確的 SSL 配置。
• 調試和監控：如果你遇到主機名問題，可以檢查以下幾點：
  • 確保主機名正確無誤，并與 SSL 證書中的主機名匹配。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_ssl_password_file

uwsgi_ssl_password_file 指令用于指定包含 SSL 私鑰密碼的文件路徑。

Syntax:	uwsgi_ssl_password_file file;
Default:	—
Context:	http, server, location
This directive appeared in version 1.7.8.

• file：指定包含 SSL 私鑰密碼的文件路徑。

案例

基本用法

最簡單的 uwsgi_ssl_password_file 用法是指定包含私鑰密碼的文件路徑：

server {listen 80;server_name example.com;location /api/ {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 啟用 SSL 并指定私鑰密碼文件uwsgi_ssl_certificate /etc/nginx/ssl/uwsgi.crt;uwsgi_ssl_certificate_key /etc/nginx/ssl/uwsgi.key;uwsgi_ssl_password_file /etc/nginx/ssl/uwsgi_password.txt;}
}

在這個例子中：

• 使用 /etc/nginx/ssl/uwsgi_password.txt 文件中的密碼來解密 SSL 私鑰。

注意事項

• 安全性：確保私鑰密碼文件存儲在一個安全的位置，并限制訪問權限，以防止密碼泄露。
• 適用場景：適用于需要加密私鑰并使用密碼保護的應用場景。例如，在生產環境中，使用加密的私鑰和密碼可以增加額外的安全層。
• 調試和監控：如果你遇到私鑰密碼文件問題，可以檢查以下幾點：
  • 確保文件路徑正確且具有適當的權限。
  • 查看Nginx的日志文件，確認是否有與此相關的警告或錯誤信息。

uwsgi_ssl_protocols

uwsgi_ssl_protocols 指令用于指定允許的SSL/TLS協議版本。這有助于確保與后端 uWSGI 服務器之間的通信安全，通過禁用不安全的協議版本來減少潛在的安全風險。

Syntax:	uwsgi_ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];
Default:	uwsgi_ssl_protocols TLSv1.2 TLSv1.3;
Context:	http, server, location
This directive appeared in version 1.5.8.

• [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3]：指定允許使用的SSL/TLS協議版本，默認為 TLSv1.2 和 TLSv1.3。

案例

啟用特定的SSL/TLS協議版本

假設我們希望僅啟用 TLSv1.2 和 TLSv1.3 協議：

http {server {listen 80;server_name example.com;location /secure {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 僅啟用 TLSv1.2 和 TLSv1.3 協議uwsgi_ssl_protocols TLSv1.2 TLSv1.3;}}
}

禁用所有舊版本的協議

如果我們希望禁用所有舊版本的協議（如 SSLv2, SSLv3, TLSv1, TLSv1.1），僅使用最新的協議版本：

http {server {listen 80;server_name example.com;location /latest {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 僅啟用最新的 TLSv1.3 協議uwsgi_ssl_protocols TLSv1.3;}}
}

注意事項

• 安全性：建議禁用不安全的舊版本協議（如 SSLv2, SSLv3, TLSv1, TLSv1.1），以防止中間人攻擊和其他安全漏洞。
• 兼容性：確保后端服務器支持所需的TLS版本，避免因不兼容導致連接失敗。

uwsgi_ssl_server_name

uwsgi_ssl_server_name 指令用于控制是否在與后端 uWSGI 服務器建立SSL連接時發送服務器名稱指示（SNI）。這對于多域名環境中的正確SSL證書匹配非常有用。

Syntax:	uwsgi_ssl_server_name on | off;
Default:	uwsgi_ssl_server_name off;
Context:	http, server, location
This directive appeared in version 1.7.0.

• on：啟用SNI，將在SSL握手時發送服務器名稱。
• off（默認）：禁用SNI，不會發送服務器名稱。

案例

啟用SNI

假設我們在一個多域名環境中需要啟用SNI：

http {server {listen 80;server_name example.com;location /secure {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 啟用SNIuwsgi_ssl_server_name on;}}
}

禁用SNI

如果我們不需要或不希望發送服務器名稱：

http {server {listen 80;server_name example.com;location /no-sni {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 禁用SNIuwsgi_ssl_server_name off;}}
}

注意事項

• 多域名支持：在多域名環境下，啟用SNI可以確保正確的SSL證書匹配，避免證書錯誤。
• 兼容性：確保后端服務器支持SNI，特別是在處理多個域名時。

uwsgi_ssl_session_reuse

uwsgi_ssl_session_reuse 指令用于控制是否重用SSL會話。這可以顯著提高性能，尤其是在高并發場景下。

Syntax:	uwsgi_ssl_session_reuse on | off;
Default:	uwsgi_ssl_session_reuse on;
Context:	http, server, location
This directive appeared in version 1.5.8.

• on（默認）：啟用SSL會話重用。
• off：禁用SSL會話重用。

案例

啟用會話重用

假設我們希望啟用SSL會話重用以提高性能：

http {server {listen 80;server_name example.com;location /secure {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 啟用SSL會話重用uwsgi_ssl_session_reuse on;}}
}

禁用會話重用

如果我們出于某些原因（如調試或測試）需要禁用SSL會話重用：

http {server {listen 80;server_name example.com;location /no-reuse {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 禁用SSL會話重用uwsgi_ssl_session_reuse off;}}
}

注意事項

• 性能優化：啟用SSL會話重用可以顯著減少SSL握手的時間，提高性能。
• 安全性：在某些情況下，禁用會話重用可能有助于緩解特定的安全問題，但通常應保持啟用狀態。

uwsgi_ssl_trusted_certificate

uwsgi_ssl_trusted_certificate 指令用于指定信任的CA證書文件路徑。這對于驗證后端 uWSGI 服務器的SSL證書非常有用，確保通信的安全性。

Syntax:	uwsgi_ssl_trusted_certificate file;
Default:	—
Context:	http, server, location
This directive appeared in version 1.7.0.

• file：指定包含信任的CA證書的文件路徑。

案例

配置信任的CA證書

假設我們需要配置一個信任的CA證書文件 /etc/nginx/trusted_ca.crt：

http {server {listen 80;server_name example.com;location /secure {uwsgi_pass unix:/tmp/uwsgi.sock;include uwsgi_params;# 配置信任的CA證書文件uwsgi_ssl_trusted_certificate /etc/nginx/trusted_ca.crt;}}
}

注意事項

• 安全性：確保配置的CA證書文件是可信的，以防止中間人攻擊。
• 路徑管理：確保提供的文件路徑正確且Nginx進程有權限讀取該文件。

uwsgi_ssl_verify

uwsgi_ssl_verify 指令用于控制是否啟用對 uWSGI 服務器 SSL/TLS 證書的驗證。這有助于確保與 uWSGI 服務器的安全通信。

Syntax:	uwsgi_ssl_verify on | off;
Default: uwsgi_ssl_verify off;
Context: http, server, location
This directive appeared in version 1.7.0.

• on：啟用對 uWSGI 服務器 SSL/TLS 證書的驗證。
• off：禁用對 uWSGI 服務器 SSL/TLS 證書的驗證，默認行為。

案例

基本用法

最簡單的 uwsgi_ssl_verify 用法是啟用或禁用 SSL/TLS 證書驗證：

http {upstream uwsgi_backend {server 127.0.0.1:3031 ssl;}server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;ssl_certificate_key /etc/nginx/ssl/example.key;location / {# 啟用對 uWSGI 服務器 SSL/TLS 證書的驗證uwsgi_ssl_verify on;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當 Nginx 與 uWSGI 服務器通過 SSL/TLS 進行通信時，將驗證 uWSGI 服務器提供的 SSL/TLS 證書的有效性。

注意事項

• 安全性：啟用證書驗證可以防止中間人攻擊（MITM），但在開發環境中可能會因為自簽名證書等原因導致驗證失敗。
• 配置要求：確保正確的 CA 證書路徑和配置，以便成功驗證 uWSGI 服務器的證書。

uwsgi_ssl_verify_depth

uwsgi_ssl_verify_depth 指令用于設置 SSL/TLS 證書鏈驗證的最大深度。這有助于控制證書鏈驗證的范圍。

Syntax:	uwsgi_ssl_verify_depth number;
Default: uwsgi_ssl_verify_depth 1;
Context: http, server, location
This directive appeared in version 1.7.0.

• number：SSL/TLS 證書鏈驗證的最大深度，默認為 1。

案例

基本用法

最簡單的 uwsgi_ssl_verify_depth 用法是指定證書鏈驗證的最大深度：

http {upstream uwsgi_backend {server 127.0.0.1:3031 ssl;}server {listen 443 ssl;server_name example.com;ssl_certificate /etc/nginx/ssl/example.crt;ssl_certificate_key /etc/nginx/ssl/example.key;location / {# 設置 SSL/TLS 證書鏈驗證的最大深度為 3uwsgi_ssl_verify on;uwsgi_ssl_verify_depth 3;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當 Nginx 驗證 uWSGI 服務器的 SSL/TLS 證書時，允許的最大證書鏈深度為 3。

注意事項

• 證書鏈長度：根據實際使用的證書鏈長度合理設置驗證深度，避免因深度不足而導致驗證失敗。
• 性能考慮：增加驗證深度可能會增加驗證時間，特別是在高并發環境下。

uwsgi_store

uwsgi_store 指令用于控制是否將 uWSGI 服務器響應的內容存儲到本地文件系統中。這有助于緩存動態內容或保存上傳文件。

Syntax:	uwsgi_store on | off | string;
Default: uwsgi_store off;
Context: http, server, location

• on：啟用存儲功能，存儲路徑基于 uwsgi_store_path 指令。
• off：禁用存儲功能，默認行為。
• string：指定存儲路徑，支持變量（如 $request_filename）。

案例

基本用法

最簡單的 uwsgi_store 用法是啟用或禁用存儲功能：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location /downloads {# 啟用存儲功能并將響應存儲到 /var/www/downloads 目錄下uwsgi_store on;uwsgi_store_path /var/www/downloads;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當用戶訪問 /downloads 路徑時，Nginx 將 uWSGI 服務器的響應內容存儲到 /var/www/downloads 目錄下。

注意事項

• 存儲路徑：確保指定的存儲路徑存在并且 Nginx 對其具有寫權限。
• 資源管理：注意不要濫用此選項，以免占用過多磁盤空間。

uwsgi_store_access

uwsgi_store_access 指令用于設置存儲文件的訪問權限。這有助于控制誰可以讀取或修改存儲的文件。

Syntax:	uwsgi_store_access users:permissions ...;
Default: uwsgi_store_access user:rw;
Context: http, server, location

• users:permissions：指定哪些用戶或用戶組可以訪問存儲的文件以及他們的權限。例如 user:rw 表示文件所有者具有讀寫權限。

案例

基本用法

最簡單的 uwsgi_store_access 用法是指定存儲文件的訪問權限：

http {upstream uwsgi_backend {server 127.0.0.1:3031;}server {listen 80;server_name example.com;location /downloads {# 啟用存儲功能并將響應存儲到 /var/www/downloads 目錄下uwsgi_store on;uwsgi_store_path /var/www/downloads;# 設置存儲文件的訪問權限為文件所有者讀寫，組和其他用戶只讀uwsgi_store_access user:rw group:r others:r;uwsgi_pass uwsgi_backend;}}
}

在這個例子中：

• 當 uWSGI 服務器的響應內容被存儲到 /var/www/downloads 目錄下時，文件的所有者具有讀寫權限，而組和其他用戶只有讀權限。

注意事項

• 權限設置：根據實際需求合理設置文件的訪問權限，確保安全性和可用性的平衡。
• 文件管理：定期檢查和清理存儲目錄，避免不必要的文件積累。

uwsgi_temp_file_write_size

uwsgi_temp_file_write_size 用于設置在處理 uwsgi 響應時，寫入臨時文件的最大塊大小。這有助于控制內存使用和優化性能，特別是在處理大響應體時。

Syntax: uwsgi_temp_file_write_size size;
Default: uwsgi_temp_file_write_size 8k|16k;
Context: http, server, location

• size：指定每次寫入臨時文件的最大塊大小，默認值為 8KB 或 16KB（取決于平臺）。

案例

基本用法

最簡單的 uwsgi_temp_file_write_size 用法是指定寫入塊大小：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_file_write_size 16k;  # 設置每次寫入塊大小為 16KB}
}

在這個例子中，設置了 uwsgi_temp_file_write_size 16k，這意味著每次寫入臨時文件的最大塊大小為 16KB。

調整寫入塊大小

根據實際需求調整寫入塊大小：

server {listen 80;server_name example.com;location /small_chunk/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_file_write_size 8k;  # 較小的寫入塊大小}location /large_chunk/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_file_write_size 32k;  # 較大的寫入塊大小}
}

在這個例子中：

• 對于 /small_chunk/ 路徑下的請求，設置了較小的寫入塊大小（8KB）。
• 對于 /large_chunk/ 路徑下的請求，設置了較大的寫入塊大小（32KB）。

注意事項

• 性能優化：合理設置寫入塊大小，確保既能滿足應用需求，又不會浪費資源。
• 應用場景：根據具體的應用場景選擇合適的寫入塊大小，例如高并發或大響應體場景下可能需要更大的寫入塊大小。

uwsgi_temp_path

uwsgi_temp_path 用于指定存儲 uwsgi 臨時文件的目錄路徑，并可配置多級子目錄結構。這有助于更好地管理臨時文件，避免單個目錄下文件過多導致的性能問題。

Syntax: uwsgi_temp_path path [level1 [level2 [level3]]];
Default: uwsgi_temp_path uwsgi_temp;
Context: http, server, location

• path：指定臨時文件存儲的根目錄。
• [level1 [level2 [level3]]]：可選參數，指定多級子目錄結構的深度和每級的哈希位數（如 1:2:2 表示第一級目錄有 2 位哈希，第二級和第三級各有 2 位哈希）。

案例

基本用法

最簡單的 uwsgi_temp_path 用法是指定臨時文件存儲路徑：

server {listen 80;server_name example.com;location / {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_path /var/tmp/nginx/uwsgi_temp;  # 指定臨時文件存儲路徑}
}

在這個例子中，指定了臨時文件存儲路徑為 /var/tmp/nginx/uwsgi_temp。

配置多級子目錄

根據實際需求配置多級子目錄結構：

server {listen 80;server_name example.com;location /single_level/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_path /var/tmp/nginx/uwsgi_temp 1;  # 單級子目錄結構}location /multi_level/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_path /var/tmp/nginx/uwsgi_temp 1:2:2;  # 多級子目錄結構}
}

在這個例子中：

• 對于 /single_level/ 路徑下的請求，設置了單級子目錄結構，每級目錄有 1 位哈希。
• 對于 /multi_level/ 路徑下的請求，設置了多級子目錄結構，第一級目錄有 2 位哈希，第二級和第三級各有 2 位哈希。

完整配置示例

結合多個指令進行完整配置：

http {uwsgi_temp_path /var/tmp/nginx/uwsgi_temp 1:2:2;  # 全局配置，適用于所有服務器和位置塊server {listen 80;server_name example.com;location /default_temp_path/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_file_write_size 16k;  # 設置每次寫入塊大小為 16KB}location /custom_temp_path/ {include uwsgi_params;uwsgi_pass unix:/tmp/uwsgi.sock;uwsgi_temp_path /var/tmp/nginx/custom_uwsgi_temp 1:2:2;  # 自定義臨時文件存儲路徑和子目錄結構uwsgi_temp_file_write_size 32k;  # 設置每次寫入塊大小為 32KB}}
}

在這個例子中：

• 對于 /default_temp_path/ 路徑下的請求，使用了全局配置的臨時文件存儲路徑和默認寫入塊大小。
• 對于 /custom_temp_path/ 路徑下的請求，使用了自定義的臨時文件存儲路徑 /var/tmp/nginx/custom_uwsgi_temp 和多級子目錄結構 1:2:2，并設置了寫入塊大小為 32KB。

注意事項

• 文件管理：合理配置臨時文件路徑和子目錄結構，避免單個目錄下文件過多影響性能。
• 磁盤空間：確保有足夠的磁盤空間來存儲臨時文件，特別是在高負載情況下。
• 權限設置：確保 Nginx 進程對指定的臨時文件路徑具有適當的讀寫權限。