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

發行項
05/16/2023

由 Sourabh Shirhatti 提供

注意

這不是本文的最新版本。若要切換至最新版本，請使用目錄頂端 ASP.NET Core版本選取器。

版本選取器

如果選取器在窄瀏覽器視窗中看不到，請擴大視窗，或選取垂直省略號 (⋮) > 目錄。

目錄選取器

本指南說明為 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 應用程式。

必要條件

使用具有 sudo 許可權的標準使用者帳戶存取 Ubuntu 20.04。
伺服器上安裝的最新穩定 .NET 執行時間。
現有的 ASP.NET Core 應用程式。

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

跨應用程式發佈與複製

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

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

設定應用程式以處理安全的本機連線。如需詳細資訊，請參閱 HTTPS 組態一節。
將應用程式設定為在不安全的端點上執行：
- 停用開發環境中的 HTTPS 重新導向中介軟體 () Program.cs ：
```
if (!app.Environment.IsDevelopment())
{
    app.UseHttpsRedirection();
}
```
  如需詳細資訊，請參閱在 ASP.NET Core 中使用多個環境 (部分機器翻譯)。
- 如果檔案中的 Properties/launchSettings.json 屬性) 存在，請移除 https://localhost:5001applicationUrl (。

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

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

dotnet publish --configuration Release

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

使用整合至組織的工作流程 (的工具，將 ASP.NET Core應用程式複製到伺服器，例如、 SCPSFTP) 。例如，) ，在目錄底下 var 尋找 Web 應用程式很常見 (var/www/helloapp 。

注意

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

測試應用程式：

從命令列執行應用程式：dotnet <app_assembly>.dll。
在瀏覽器中，巡覽至 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轉送標頭中介軟體。此中介軟體會使用 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。

在回送位址上執行的 Proxy (127.0.0.0/8 、 [::1]) ，包括標準 localhost 位址 (127.0.0.1) ，預設會受到信任。如果組織內的其他受信任 Proxy 或網路處理網際網路與網頁伺服器之間的要求，請將它們新增至或 KnownNetworks ForwardedHeadersOptions 清單 KnownProxies ，下列範例會將位於 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

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

注意

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

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

sudo service nginx start

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

設定 Nginx

若要將 Nginx 設定為反向 Proxy，以將 HTTP 要求轉送至您的 ASP.NET Core應用程式，請修改 /etc/nginx/sites-available/default 。在文字編輯器中開啟它，並以下列程式碼片段取代內容：

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 keep-alive;
        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 Core SignalR 生產環境裝載和調整和裝載和部署 ASP.NET Core Blazor Server以取得詳細資訊。

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

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

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

警告

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

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

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

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

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

完成測試應用程式時，請在命令提示字元使用Ctrl+C (Windows) 或⌘+C (macOS) 關閉應用程式。

增加keepalive_requests

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

監視應用程式

伺服器已設定為將提出 http://<serveraddress>:80 的要求轉送至在上 Kestrelhttp://127.0.0.1:5000 執行的 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_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

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

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

透過設定及 Kestrel 管理 systemd 反向 Proxy 之後，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

檢視記錄

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

sudo journalctl -fu kestrel-helloapp.service

為了進一步篩選，例如、 --until 1 hour ago 或這些選項 --since today 的組合可以減少傳回的專案數。

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。

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

要求標頭欄位太長

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

警告

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

保護應用程式

啟用 AppArmor

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

設定防火牆

關閉未使用的所有外部埠。未複雜防火牆 (ufw) 提供前端 iptables ，方法是提供設定防火牆的 CLI。

警告

如果未正確設定，防火牆會防止存取整個系統。如果您使用 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

警告

如果未正確設定，防火牆會防止存取整個系統。如果您使用 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

警告

安裝 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 使用開發中命令或開發環境的憑證， (F Visual Studio Code) 5或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;

以下列檔案取代 /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 來保護網站安全。

減輕點擊劫持攻擊：

編輯 nginx.conf 檔案：
```
sudo nano /etc/nginx/nginx.conf
```
在程式碼區塊內 http{} ，新增這一行： add_header X-Frame-Options "SAMEORIGIN";
儲存檔案。
重新啟動 Nginx。

MIME 類型探查

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

編輯 nginx.conf 檔案：
```
sudo nano /etc/nginx/nginx.conf
```
在程式碼區塊內 http{} ，新增這一行： add_header X-Content-Type-Options "nosniff";
儲存檔案。
重新啟動 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：使用轉送的標頭

本指南說明在 Ubuntu 16.04 伺服器上設定生產環境就緒的 ASP.NET Core 環境。這些指示可能使用較新版本的 Ubuntu，但未經測試。

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

注意

針對 Ubuntu 14.04， supervisord 建議作為監視 Kestrel 程式的解決方案。 systemd 無法在 Ubuntu 14.04 上使用。如需 Ubuntu 14.04 指示，請參閱本主題前一版本。

本指南：

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

必要條件

以 sudo 權限使用標準使用者帳戶存取 Ubuntu 16.04 伺服器。
伺服器上安裝的最新非預覽 .NET 執行時間。
現有的 ASP.NET Core 應用程式。

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

跨應用程式發佈與複製

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

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

設定應用程式以處理安全的本機連線。如需詳細資訊，請參閱 HTTPS 組態一節。
將應用程式設定為在不安全的端點上執行：
- 停用開發環境中的 HTTPS 重新導向中介軟體 () Program.cs ：
```
if (!app.Environment.IsDevelopment())
{
    app.UseHttpsRedirection();
}
```
  如需詳細資訊，請參閱在 ASP.NET Core 中使用多個環境 (部分機器翻譯)。
- 如果檔案中的 Properties/launchSettings.json 屬性) 存在，請移除 https://localhost:5001applicationUrl (。

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

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

dotnet publish --configuration Release

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

注意

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

測試應用程式：

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

設定反向 Proxy 伺服器

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

使用反向 Proxy 伺服器

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

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

// requires using Microsoft.AspNetCore.HttpOverrides;
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

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

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

using System.Net;

var builder = WebApplication.CreateBuilder(args);

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

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

安裝 Nginx

注意

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

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

sudo service nginx start

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

設定 Nginx

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 keep-alive;
        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 應用程式，請參閱分別 SignalR ASP.NET Core生產主機和調整和裝載和部署 ASP.NET Core Blazor Server以取得詳細資訊。

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

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

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

警告

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

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

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

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

監視應用程式

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

建立服務檔

建立服務定義檔：

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

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

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

[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_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

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

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

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 Ubuntu
    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

透過設定和管理 Kestrelsystemd 反向 Proxy 時，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

檢視記錄

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

sudo journalctl -fu kestrel-helloapp.service

如需進一步篩選，例如、 --until 1 hour ago 或這些選項 --since today 的組合可能會減少傳回的專案數。

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。

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

要求標頭欄位太長

Proxy 伺服器預設設定通常會根據平臺將要求標頭欄位限制為 4 K 或 8 K。應用程式可能需要超過預設 (的欄位，例如使用 Azure Active Directory 的應用程式) 。如果需要較長的欄位，Proxy 伺服器的預設設定需要調整。要套用的值取決於案例。如需詳細資訊，請參閱您的伺服器文件。

警告

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

保護應用程式

啟用 AppArmor

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

設定防火牆

關閉未使用的所有外部埠。未複雜防火牆 (ufw) 提供前端 iptables ，方法是提供用來設定防火牆的 CLI。

警告

如未正確設定，防火牆會禁止存取整個系統。未指定正確的 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

保護 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 使用開發中命令或開發環境的憑證， (F Visual Studio Code) 5或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;

以下列檔案取代 /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。

注意

ssl_stapling
ssl_stapling_file
ssl_stapling_responder
ssl_stapling_verify

保護 Nginx 免於點閱綁架

減輕點擊劫持攻擊：

編輯 nginx.conf 檔案：
```
sudo nano /etc/nginx/nginx.conf
```
新增這一行： add_header X-Frame-Options "SAMEORIGIN";
儲存檔案。
重新啟動 Nginx。

MIME 類型探查

編輯 nginx.conf 檔案：
```
sudo nano /etc/nginx/nginx.conf
```
新增這一行： add_header X-Content-Type-Options "nosniff";
儲存檔案。
重新啟動 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：使用轉送的標頭

本指南說明在 Ubuntu 16.04 伺服器上設定生產環境就緒的 ASP.NET Core 環境。這些指示可能使用較新版本的 Ubuntu，但未經測試。

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

注意

針對 Ubuntu 14.04， supervisord 建議作為監視 Kestrel 程式的解決方案。 systemd 無法在 Ubuntu 14.04 上使用。如需 Ubuntu 14.04 指示，請參閱本主題前一版本。

本指南：

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

必要條件

以 sudo 權限使用標準使用者帳戶存取 Ubuntu 16.04 伺服器。
伺服器上安裝的最新非預覽 .NET 執行時間。
現有的 ASP.NET Core 應用程式。

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

跨應用程式發佈與複製

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

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

設定應用程式以處理安全的本機連線。如需詳細資訊，請參閱 HTTPS 組態一節。
將應用程式設定為在不安全的端點上執行：
- 停用開發環境中的 HTTPS 重新導向中介軟體 () Program.cs ：
```
if (!app.Environment.IsDevelopment())
{
    app.UseHttpsRedirection();
}
```
  如需詳細資訊，請參閱在 ASP.NET Core 中使用多個環境 (部分機器翻譯)。
- 如果檔案中的 Properties/launchSettings.json 屬性) 存在，請移除 https://localhost:5001applicationUrl (。

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

dotnet publish --configuration Release

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

注意

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

測試應用程式：

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

設定反向 Proxy 伺服器

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

使用反向 Proxy 伺服器

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

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

using Microsoft.AspNetCore.HttpOverrides;

...

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

app.UseAuthentication();

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

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

using System.Net;

...

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

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

安裝 Nginx

注意

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

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

sudo service nginx start

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

設定 Nginx

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 keep-alive;
        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 應用程式，請參閱分別 SignalR ASP.NET Core生產主機和調整和裝載和部署 ASP.NET Core Blazor Server以取得詳細資訊。

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

警告

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

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

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

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

監視應用程式

建立服務檔

建立服務定義檔：

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

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

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

[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_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

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

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

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 Ubuntu
    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

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

檢視記錄

sudo journalctl -fu kestrel-helloapp.service

如需進一步篩選，例如、 --until 1 hour ago 或這些選項 --since today 的組合可能會減少傳回的專案數。

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

資料保護

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

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

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

要求標頭欄位太長

警告

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

保護應用程式

啟用 AppArmor

設定防火牆

關閉未使用的所有外部埠。未複雜防火牆 (ufw) 提供前端 iptables ，方法是提供用來設定防火牆的 CLI。

警告

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

sudo apt-get 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 ， (F5或Ctrl+F Visual Studio Code) 5：

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

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

警告

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

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

將伺服器設定為在埠 443 上接聽 HTTPS 流量，方法是指定受信任的憑證授權單位單位所發行的有效憑證 (CA) 。
採用以下 /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;

以下列檔案取代 /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 免於點閱綁架

減輕點擊劫持攻擊：

編輯 nginx.conf 檔案：
```
sudo nano /etc/nginx/nginx.conf
```
新增這一行： add_header X-Frame-Options "SAMEORIGIN";
儲存檔案。
重新啟動 Nginx。

MIME 類型探查

編輯 nginx.conf 檔案：
```
sudo nano /etc/nginx/nginx.conf
```
新增這一行： add_header X-Content-Type-Options "nosniff";
儲存檔案。
重新啟動 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：使用轉送的標頭