在 Linux 上使用 Nginx 裝載 ASP.NET Core

作者：Sourabh Shirhatti

本指南說明為 Ubuntu、Red Hat Enterprise (RHEL) 和 SUSE Linux Enterprise Server 設定生產就緒的 ASP.NET Core 環境。

如需有關 ASP.NET Core 支援之其他 Linux 發行版本的資訊，請參閱 Linux 上 .NET Core 的必要條件。

本指南：

• 將現有的 ASP.NET Core 應用程式放在反向 Proxy 伺服器後方。
• 設定反向 Proxy 伺服器以將要求轉送至 Kestrel 網頁伺服器。
• 確保 Web 應用程式在啟動時以精靈的形式執行。
• 設定程序管理工具以協助重新啟動 Web 應用程式。

必要條件

Ubuntu

• 以 sudo 權限使用標準使用者帳戶存取 Ubuntu 20.04。
• 伺服器上已安裝最新的穩定 .NET 執行階段。
• 現有的 ASP.NET Core 應用程式。

Red Hat Enterprise Linux

• 使用具有 sudo 權限的標準使用者帳戶，存取 Red Hat Enterprise (RHEL) 8.0 或更新版本。
• 伺服器上已安裝最新的穩定 .NET 執行階段。
• 現有的 ASP.NET Core 應用程式。

SUSE Linux Enterprise Server

• 以 sudo 權限使用標準使用者帳戶存取 SLES 12 或 15。
• 伺服器上已安裝最新的穩定 .NET 執行階段。
• 現有的 ASP.NET Core 應用程式。

在升級共用架構之後的任何時間點，請重新啟動伺服器所裝載的 ASP.NET Core 應用程式。

跨應用程式發佈與複製

為架構相依部署設定應用程式。

如果應用程式在本機開發環境中執行，且伺服器未將其設定為進行安全 HTTPS 連線，請採用下列任一方法：

• 設定應用程式以處理安全的本機連線。 如需詳細資訊，請參閱 HTTPS 組態一節。

• 將應用程式設定為在不安全的端點上執行：

  • 停用開發環境 (Program.cs) 中的 HTTPS 重新導向中介軟體 ：

    if (!app.Environment.IsDevelopment())
    {
        app.UseHttpsRedirection();
    }
    

    如需詳細資訊，請參閱在 ASP.NET Core 中使用多個環境 (部分機器翻譯)。

  • 從 Properties/launchSettings.json 檔案中的 applicationUrl 屬性中移除 https://localhost:5001 (如適用)。

如需依環境設定的詳細資訊，請參閱在 ASP.NET Core 中使用多個環境。

從開發環境中執行 dotnet publish，將應用程式封裝到可在伺服器上執行的目錄 (例如 bin/Release/{TARGET FRAMEWORK MONIKER}/publish，其中 {TARGET FRAMEWORK MONIKER} 預留位置為目標 Framework Moniker (TFM))：

dotnet publish --configuration Release

如果您不想在伺服器上維護 .NET Core 執行階段，應用程式也可以發佈為獨立式部署。

使用整合至組織工作流程的工具 (SCP、SFTP 等等) 將 ASP.NET Core 應用程式複製到伺服器。 Web 應用程式通常可在 var 目錄下找到 (例如 var/www/helloapp)。

注意

在生產環境部署案例中，持續整合工作流程會執行發佈應用程式並將資產複製到伺服器的工作。

測試應用程式：

1. 從命令列執行應用程式：dotnet <app_assembly>.dll。
2. 在瀏覽器中，巡覽至 http://<serveraddress>:<port> 以確認應用程式可在 Linux 本機上正常運作。

設定反向 Proxy 伺服器

反向 Proxy 是為動態 Web 應用程式提供服務的常見設定。 反向 Proxy 會終止 HTTP 要求，並將它轉送至 ASP.NET Core 應用程式。

使用反向 Proxy 伺服器

Kestrel 非常適用於從 ASP.NET Core 提供動態內容。 不過，Web 服務功能不像 IIS、Apache 或 Nginx 這類伺服器那樣豐富。 反向 Proxy 伺服器可以讓 HTTP 伺服器卸下提供靜態內容、快取要求、壓縮要求及終止 HTTPS 等工作的負擔。 反向 Proxy 伺服器可能位在專用電腦上，或可能與 HTTP 伺服器一起部署。

為達到本指南的目的，使用 Nginx 的單一執行個體。 它會在相同的伺服器上和 HTTP 伺服器一起執行。 您可以根據需求，選擇不同的設定。

由於要求是由反向 Proxy 轉送的，請使用 Microsoft.AspNetCore.HttpOverrides 套件中的轉送標頭中介軟體，此套件會透過共用架構的 Microsoft.AspNetCore.App 中繼套件自動包含在 ASP.NET Core 應用程式中。 此中介軟體會使用 X-Forwarded-Proto 標頭來更新 Request.Scheme，以便讓重新導向 URI 及其他安全性原則正確運作。

應在其他中介軟體之前執行轉接標頭中介軟體。 這種排序可確保依賴轉送標頭資訊的中介軟體可以耗用用於處理的標頭值。 若要在診斷和錯誤處理中介軟體之後執行轉送標頭中介軟體，請參閱轉送標頭中介軟體順序。

在呼叫其他中介軟體之前，請先叫用 UseForwardedHeaders 方法。 請設定中介軟體來轉送 X-Forwarded-For 和 X-Forwarded-Proto 標頭：

using Microsoft.AspNetCore.HttpOverrides;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication();

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

app.MapGet("/", () => "Hello ForwardedHeadersOptions!");

app.Run();

如果未將任何 ForwardedHeadersOptions 指定給中介軟體，則要轉送的預設標頭會是 None。

在預設情況下，在回送位址 (127.0.0.0/8, [::1]) 上執行的 Proxy (包括標準的本機位址 127.0.0.1) 是受信任的。 如果組織內有其他受信任的 Proxy 或網路處理網際網路與網頁伺服器之間的要求，請使用 ForwardedHeadersOptions，將其新增至 KnownProxies 或 KnownNetworks 清單。 下列範例會將位於 IP 位址 10.0.0.100 的受信任 Proxy 伺服器新增至轉送標頭中介軟體 KnownProxies：

using Microsoft.AspNetCore.HttpOverrides;
using System.Net;

var builder = WebApplication.CreateBuilder(args);

// Configure forwarded headers
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

builder.Services.AddAuthentication();

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

app.MapGet("/", () => "10.0.0.100");

app.Run();

如需詳細資訊，請參閱設定 ASP.NET Core 以處理 Proxy 伺服器和負載平衡器。

安裝 Nginx

Ubuntu

使用 apt-get 來安裝 Nginx。 安裝程式建立的 systemd init 指令碼，會在系統啟動時將 Nginx 執行為精靈。 請遵循 Nginx：Official Debian/Ubuntu packages (Nginx：官方 Debian/Ubuntu 套件) 中適用於 Ubuntu 的安裝指示。

Red Hat Enterprise Linux

使用 yum-utils 來選取並安裝 Nginx 模組資料流。 請遵循 Nginx：Linux 套件 - RHEL 的 RHEL 安裝指示。

SUSE Linux Enterprise Server

使用 yum-utils 來選取並安裝 Nginx 模組資料流。 請遵循 Nginx：Linux 套件 - SLES 的 SLES 安裝指示。

注意

如果需要選用的 Nginx 模組，可能要從來源建置 Nginx。

因為 Nginx 是第一次安裝，請透過執行明確啟動它：

sudo service nginx start

確認瀏覽器會顯示 Nginx 的預設登陸頁面。 登陸頁面位於 http://<server_IP_address>/index.nginx-debian.html。

設定 Nginx

Ubuntu

若要將 Nginx 設定為反向 Proxy，以將 HTTP 要求轉送至 ASP.NET Core 應用程式，請修改 /etc/nginx/sites-available/default，並重新建立 symlink。 建立 /etc/nginx/sites-available/default 檔案之後，請使用下列命令來建立 symlink：

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

以文字編輯器開啟 /etc/nginx/sites-available/default，並以下列程式碼片段取代內容：

Red Hat Enterprise Linux

若要將 Nginx 設定為反向 Proxy，以將 HTTP 要求轉送至 ASP.NET Core 應用程式，請修改 /etc/nginx.conf。 使用下列程式碼片段更新 http{} 程式碼區塊：

SUSE Linux Enterprise Server

若要將 Nginx 設定為反向 Proxy，以將 HTTP 要求轉送至 ASP.NET Core 應用程式，請修改 /etc/nginx.conf。 使用下列程式碼片段更新 http{} 程式碼區塊：

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://127.0.0.1:5000/;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

如果應用程式是 SignalR 或 Blazor Server 應用程式，請分別參閱 ASP.NET 核心 SignalR 生產裝載和調整以及裝載和部署 ASP.NET Core 伺服器端 Blazor 應用程式，以取得詳細資訊。

當沒有任何與 server_name 相符的項目時，Nginx 會使用預設伺服器。 如果未定義任何預設伺服器，則設定檔中的第一個伺服器就是預設伺服器。 最佳做法是，在您的設定檔中新增一個會傳回狀態碼 444 的特定預設伺服器。 預設伺服器設定範例如下：

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

使用上述設定檔和預設伺服器時，Nginx 會在連接埠 80 接受主機標頭為 example.com 或 *.example.com 的公用流量。 不符合這些主機的要求將不會轉送至 Kestrel。 Nginx 會將相符的要求轉送至位於 http://127.0.0.1:5000/ 的 Kestrel。 如需詳細資訊，請參閱 nginx 如何處理要求。 若要變更 Kestrel 的 IP/連接埠，請參閱Kestrel：端點組態。

警告

如果無法指定適當的 server_name 指示詞，就會讓應用程式暴露在安全性弱點的風險下。 若您擁有整個父網域 (相對於易受攻擊的 *.com) 的控制權，子網域萬用字元繫結 (例如 *.example.com) 就沒有此安全性風險。 如需詳細資訊，請參閱 RFC 9110：HTTP 語意 (第 7.2 節：主機和 ：authority)。

建立 Nginx 設定之後，請執行 sudo nginx -t 來確認設定檔的語法。 如果設定檔測試成功，請執行 sudo nginx -s reload 來強制 Nginx 套用這些變更。

直接在伺服器上執行應用程式：

1. 巡覽至應用程式目錄。
2. 執行應用程式：dotnet <app_assembly.dll>，其中 app_assembly.dll 是應用程式的組件檔名稱。

Ubuntu

如果應用程式在伺服器上執行，但無法透過網際網路回應，請檢查伺服器的防火牆，確認連接埠 80 已開啟。 如果使用的是 Azure Ubuntu VM，請新增啓用輸入連接埠 80 流量的網路安全性群組 (NSG) 規則。 沒有必要啟用輸出連接埠 80 規則，因為啓用輸入規則時會自動授與輸出流量。

Red Hat Enterprise Linux

如果應用程式在伺服器上執行，但無法透過網際網路回應，請檢查伺服器的防火牆，確認連接埠 80 已開啟。

SUSE Linux Enterprise Server

如果應用程式在伺服器上執行，但無法透過網際網路回應，請檢查伺服器的防火牆，確認連接埠 80 已開啟。

在測試應用程式之後，請在命令提示字元中，使用 Ctrl+C (Windows) or ⌘+C (macOS) 關閉應用程式。

增加 keepalive_requests

keepalive_requests 可用來提升更高的效能，如需詳細資訊，請參閱此 GitHub 問題。

監視應用程式

伺服器已設定完成，可將對 http://<serveraddress>:80 發出的要求轉送給在位於 http://127.0.0.1:5000 的 Kestrel 上執行的 ASP.NET Core 應用程式。 不過，並未設定 Nginx 來管理 Kestrel 處理序。 您可以使用 systemd 來建立服務檔案，以啟動並監視基礎 Web 應用程式。 systemd 是 init 系統，提供許多強大的啟動、停止和管理處理序功能。

建立服務檔

建立服務定義檔：

sudo nano /etc/systemd/system/kestrel-helloapp.service

下列範例是應用程式的 .ini 服務檔案：

[Unit]
Description=Example .NET Web API App running on Linux

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_NOLOGO=true

[Install]
WantedBy=multi-user.target

在上述範例中，管理服務的使用者是由 User 選項所指定。 使用者 (www-data) 必須存在且擁有應用程式檔案的適當擁有者。

使用 TimeoutStopSec 可設定應用程式收到初始中斷訊號之後等待關閉的時間。 如果應用程式在此期間後未關閉，則會發出 SIGKILL 來終止應用程式。 提供不具單位的秒值 (例如 150)、時間範圍值 (例如 2min 30s) 或 infinity (表示停用逾時)。 TimeoutStopSec 預設為管理員組態檔 (systemd-system.conf、system.conf.d、systemd-user.conf、user.conf.d) 中的 DefaultTimeoutStopSec 值。 大多數發行版本的預設逾時為 90 秒。

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux 的檔案系統會區分大小寫。 將 ASPNETCORE_ENVIRONMENT 設定為 Production 會導致搜尋組態檔 appsettings.Production.json，而不是 appsettings.production.json。

有些值 (例如 SQL 連接字串) 必須以逸出方式處理，設定提供者才能讀取環境變數。 請使用下列命令來產生要在設定檔中使用並已適當逸出的值：

systemd-escape "<value-to-escape>"

環境變數名稱不支援冒號 (:) 分隔符號。 請使用雙底線 (__) 來取代冒號。 環境變數組態提供者會在將環境變數讀入組態時，將雙底線轉換為冒號。 在下列範例中，連接字串索引鍵 ConnectionStrings:DefaultConnection 會設定為服務定義檔中的 ConnectionStrings__DefaultConnection：

Environment=ConnectionStrings__DefaultConnection={Connection String}

儲存檔案並啟用服務。

sudo systemctl enable kestrel-helloapp.service

啟動服務並確認它正在執行。

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Linux
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

設定好反向 Proxy 並透過 systemd 管理 Kestrel 之後，Web 應用程式便已完全設定妥當，而從本機電腦瀏覽器透過 http://localhost 即可存取它。 此外，也可以從遠端電腦存取它，除非遭到任何防火牆封鎖。 檢查回應標頭時，Server 標頭會顯示是由 Kestrel 為 ASP.NET Core 應用程式提供服務。

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

檢視記錄

由於是使用 systemd 來管理使用 Kestrel 的 Web 應用程式，因此會將所有事件和處理序都記錄在集中式日誌中。 不過，此日誌包含 systemd 管理的所有服務和處理程序的所有項目。 若要檢視 kestrel-helloapp.service 的特定項目，請使用下列命令：

sudo journalctl -fu kestrel-helloapp.service

如需進一步篩選，例如 --since today、--until 1 hour ago 或這些項目的組合等時間選項，可以減少傳回的項目數目。

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

資料保護

ASP.NET Core 資料保護堆疊由數個 ASP.NET Core 中介軟體使用，包括驗證中介軟體 (例如，cookie 中介軟體) 與跨網站偽造要求 (CSRF) 保護。 即使資料保護 API 並非由使用者程式碼呼叫，仍應設定資料保護，以建立持續密碼編譯金鑰存放區。 如不設定資料保護，金鑰會保留在記憶體中，並於應用程式重新啟動時捨棄。

如果 Keyring 儲存在記憶體中，則當應用程式重新啟動時：

• 所有以 cookie 為基礎的驗證權杖都會失效。
• 當使用者提出下一個要求時，需要再次登入。
• 所有以 Keyring 保護的資料都無法再解密。 這可能會包含 CSRF 權杖和 ASP.NET Core MVC TempData cookie。

若要設定資料保護來保存及加密金鑰環，請參閱：

• ASP.NET Core 中的金鑰儲存體提供者
• 使用 ASP.NET Core 在 Windows 和 Azure 中待用金鑰加密

要求標頭欄位太長

Proxy 伺服器預設設定通常會根據平台，將要求標頭欄位限制為 4 K 或 8 K。 應用程式可能需要比預設值更長的欄位（例如，使用 Microsoft Entra ID 的應用程式）。 如果需要較長的欄位，則 Proxy 伺服器的預設設定需要進行調整。 要套用的值取決於案例。 如需詳細資訊，請參閱您的伺服器文件。

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

警告

除非必要，否則請勿增加 Proxy 緩衝區的預設值。 增加這些值會提高緩衝區溢位及惡意使用者發動拒絕服務 (DoS) 攻擊的風險。

保護應用程式

啟用 AppArmor

Linux 安全性模組 (LSM) 是 Linux 2.6 之後 Linux 核心所包含的一個架構。 LSM 支援不同的安全性模組實作。 AppArmor 是 LSM，它實作的必要存取控制系統，可將程式限定在有限的資源集中。 確定已啟用並正確設定 AppArmor。

設定防火牆

關閉所有不在使用中的外部連接埠。 簡單的防火牆 (ufw) 提供 CLI 供設定防火牆，為 iptables 提供前端。

Ubuntu

警告

如未正確設定，防火牆會禁止存取整個系統。 未指定正確的 SSH 連接埠，會導致您無法存取系統 (若您使用 SSH 連線至該連接埠)。 預設連接埠為 22。 如需詳細資訊，請參閱 ufw 簡介與手冊。

安裝 ufw 並將其設定為允許任何所需連接埠上的流量。

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Red Hat Enterprise Linux

警告

如未正確設定，防火牆會禁止存取整個系統。 未指定正確的 SSH 連接埠，會導致您無法存取系統 (若您使用 SSH 連線至該連接埠)。 預設連接埠為 22。 如需詳細資訊，請參閱 ufw 簡介。

安裝 ufw 並將其設定為允許任何所需連接埠上的流量。

sudo yum -y install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

SUSE Linux Enterprise Server

警告

如未正確設定，防火牆會禁止存取整個系統。 未指定正確的 SSH 連接埠，會導致您無法存取系統 (若您使用 SSH 連線至該連接埠)。 預設連接埠為 22。 如需詳細資訊，請參閱 ufw 簡介。

安裝 ufw 並將其設定為允許任何所需連接埠上的流量。

sudo yum -y install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

保護 Nginx

變更 Nginx 回應名稱

編輯 src/http/ngx_http_header_filter_module.c：

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

設定選項

設定伺服器的其他所需模組。 請考慮使用 ModSecurity 等 Web 應用程式防火牆來強化應用程式。

HTTPS 設定

設定應用程式以進行安全的本機連線 (HTTPS)

dotnet run 命令使用應用程式的 Properties/launchSettings.json 檔案，其設定應用程式在 applicationUrl 屬性所提供的 URL 上接聽。 例如： https://localhost:5001;http://localhost:5000 。

使用下列其中一種方法，設定應用程式將憑證用在針對 dotnet run 命令的開發，或用在開發環境 (F5，若在 Visual Studio Code 中則為 Ctrl+F5)：

• 取代組態中的預設憑證 (建議使用)
• KestrelServerOptions.ConfigureHttpsDefaults

設定反向 Prooxy 以進行安全的用戶端連線 (HTTPS)

警告

本節中的安全性組態是一般設定，可用來作為進一步自訂的起點。 我們無法提供協力廠商工具、伺服器和作業系統的支援。 使用本節中的設定需自行承擔風險。 如需詳細資訊，請存取下列資源：

• 設定 HTTPS 伺服器 (Nginx 文件)
• mozilla.org SSL 組態產生器

• 藉由指定由受信任憑證授權單位 (CA) 核發的有效憑證，將伺服器設定成在連接埠 443 上接聽 HTTPS 流量。

• 採用以下 /etc/nginx/nginx.conf 檔案所述的一些做法來強化安全性。

• 下列範例不會將伺服器設定為重新導向不安全的要求。 我們建議使用 HTTPS 重新導向中介軟體。 如需詳細資訊，請參閱在 ASP.NET Core 中強制執行 HTTPS。

  注意

  針對伺服器設定處理安全重新導向而非 HTTPS 重新導向中介軟體的開發環境，我們建議使用暫時重新導向 (302)，而非永久重新導向 (301)。 連結快取可能會導致開發環境中不穩定的行為。

• 新增 Strict-Transport-Security (HSTS) 標頭可確保用戶端提出的所有後續要求都會透過 HTTPS。 如需設定標頭的 Strict-Transport-Security 指引，請參閱 在 ASP.NET Core 中強制執行 HTTPS。

• 如果未來會停用 HTTPS，請使用下列其中一種方法：

  • 請勿新增 HSTS 標頭。
  • 選擇簡短的 max-age 值。

新增 /etc/nginx/Proxy.conf 組態檔：

proxy_redirect          off;
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;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Ubuntu

使用下列檔案取代/etc/nginx/nginx.conf 組態檔的內容。 此範例在一個組態檔中同時包含 http 和 server 區段。

Red Hat Enterprise Linux

修改 /etc/nginx/nginx.conf。 在文字編輯器中加以開啟，並以下列程式碼片段取代 http{} 和 server{} 程式碼區塊：

SUSE Linux Enterprise Server

修改 /etc/nginx/nginx.conf。 在文字編輯器中加以開啟，並以下列程式碼片段取代 http{} 和 server{} 程式碼區塊：

http {
    include        /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens  off;

    sendfile on;
    # Adjust keepalive_timeout to the lowest possible value that makes sense 
    # for your use case.
    keepalive_timeout   29;
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream helloapp{
        server 127.0.0.1:5000;
    }

    server {
        listen                    443 ssl http2;
        listen                    [::]:443 ssl http2;
        server_name               example.com *.example.com;
        ssl_certificate           /etc/ssl/certs/testCert.crt;
        ssl_certificate_key       /etc/ssl/certs/testCert.key;
        ssl_session_timeout       1d;
        ssl_protocols             TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers off;
        ssl_ciphers               ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_session_cache         shared:SSL:10m;
        ssl_session_tickets       off;
        ssl_stapling              off;

        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass http://helloapp;
            limit_req  zone=one burst=10 nodelay;
        }
    }
}

注意

Blazor WebAssembly 應用程式需要較大的 burst 參數值，以便容納應用程式提出的較大要求數目。 如需詳細資訊，請參閱裝載和部署 ASP.NET Core Blazor WebAssembly。

注意

上述範例會停用線上憑證狀態通訊協定 (OCSP) 裝訂。 如果已啟用，請確認憑證支援此功能。 如需啟用 OCSP 的詳細資訊和指引，請參閱模組ngx_HTTP_ssl_module (Nginx 文件) 文章中的下列屬性：

• ssl_stapling
• ssl_stapling_file
• ssl_stapling_responder
• ssl_stapling_verify

保護 Nginx 免於點閱綁架

點閱綁架(也稱為「UI 偽裝攻擊」) 是一種惡意攻擊，會誘騙網站訪客點選與其目前所瀏覽頁面不同的頁面上連結或按鈕。 請使用 X-FRAME-OPTIONS 來保護網站安全。

減輕點擊劫持攻擊：

1. 編輯 nginx.conf 檔案：

   sudo nano /etc/nginx/nginx.conf
   

   在 http{} 程式碼區塊內，新增以下行：add_header X-Frame-Options "SAMEORIGIN";

2. 儲存檔案。

3. 重新啟動 Nginx。

MIME 類型探查

此標頭會防止大部分的瀏覽器對遠離宣告內容類型的回應進行 MIME 探查，因為標頭會指示瀏覽器不要覆寫回應內容類型。 使用 nosniff 選項，如果伺服器顯示的內容是 text/html，則瀏覽器就會將它轉譯為 text/html。

1. 編輯 nginx.conf 檔案：

   sudo nano /etc/nginx/nginx.conf
   

   在 http{} 程式碼區塊內，新增以下行：add_header X-Content-Type-Options "nosniff";

2. 儲存檔案。

3. 重新啟動 Nginx。

其他 Nginx 建議

在伺服器中升級共用架構之後，請重新啟動伺服器所裝載的 ASP.NET Core 應用程式。

其他資源

• Linux 上 .NET Core 的必要條件
• Nginx: Binary Releases: Official Debian/Ubuntu packages (Nginx：二進位版本：正式的 Debian Ubuntu 套件)
• 針對 ASP.NET Core 專案進行疑難排解和偵錯
• 設定 ASP.NET Core 以處理 Proxy 伺服器和負載平衡器
• NGINX：使用轉送的標頭