在為 Nextcloud 提供服務的 HTTPS 端點新增 HSTS 標頭

Nextcloud 的「Strict-Transport-Security」（嚴格傳輸安全性）警告表示其檢查未在公共 HTTPS 回應中偵測到max-age至少15552000180 天的 HSTS 標頭。請在提供 HTTPS 服務的 Web 伺服器或反向代理程式上新增此標頭，然後測試該公用 URL。 HSTS 不是 Nextcloud 的設置config.php，普通的 HTTP 回應也無法在瀏覽器中建立 HSTS 策略。

更改配置前需要檢查哪些內容

• 確認 Nextcloud 網站透過 HTTPS 正確加載，並為其主機名稱提供有效的憑證。
• 確定哪個服務終止 TLS：Apache、NGINX、負載平衡器、容器入口或外部代理程式。
• 檢查該服務是否已設定Strict-Transport-Security。從面向公眾的 TLS 端點發送明確的策略；重複或衝突的標頭會使驗證變得混亂。
• 在新增 HTTPS 之前，請確認所有子網域都已準備好使用 HTTPS includeSubDomains。不要preload為了快速消除此警告而啟用 HTTPS。

HSTS 會告知瀏覽器，日後與該主機名稱的連線必須使用 HTTPS。這有助於防止瀏覽器在收到策略後降級到 HTTP。它不會取代 TLS、修復無效憑證或重定向首次 HTTP 存取；因此，還需要配置單獨的 HTTP 到 HTTPS 重定向。 Nextcloud 35 的管理手冊指出，最低間隔時間為 15552000 秒，並建議在 Web 伺服器中設定標頭。在代理部署中，實際的強制執行點是向訪客傳回回應的元件。

制定基準政策

Nextcloud 主機名稱的保守起始策略是：

Strict-Transport-Security: max-age=15552000

這樣就滿足了 Nextcloud 文件的最低生命週期要求，而無需自動將策略應用於每個子網域。確認所有相關子網域持續支援 HTTPS 後，您可以考慮新增此策略; includeSubDomains。已學習此指令的瀏覽器也會要求這些子網域使用 HTTPS。如果某個內部控制面板、郵件主機或仍依賴 HTTP 的舊版服務在該瀏覽器中無法訪問，則在遷移完成或策略過期之前，這些服務可能無法存取。

阿帕契

對於 Apache TLS 虛擬主機，請啟用mod_headers該指令並將其放置在 HTTPS 虛擬主機中，而不僅僅是連接埠 80 重定向主機中：

<VirtualHost *:443>
    ServerName cloud.example.com
    # Keep the existing TLS and Nextcloud configuration here.
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>
</VirtualHost>

取代範例主機名，並保留您現有的憑證和代理或 PHP 配置。 Nextcloud 的 Apache 安全加固範例使用Header always setHTTPS 虛擬主機。使用您的發行版支援的 config-test 命令驗證 Apache 配置，僅在測試通過時才重新載入 Apache。

NGINX

server在 NGINX 中，在監聽公共 Nextcloud 主機名稱上的 HTTPS 請求的程式碼區塊內新增標頭：

server {
    listen 443 ssl;
    server_name cloud.example.com;
    # Keep your existing TLS and Nextcloud locations here.
    add_header Strict-Transport-Security "max-age=15552000" always;
}

請勿將此配置完全替換伺服器的現有配置。 NGINX 標頭繼承取決於巢狀位置是否定義了自己的add_header指令；請檢查實際配置並測試典型回應，包括靜態資源和 DAV 端點。 Nextcloud 官方 NGINX 範例在其 HTTPS 配置中包含 HSTS 設置，並提醒管理員啟用預先載入。

反向代理或入口

如果負載平衡器、入口伺服器或託管代理程式在將流量轉送至 Nextcloud 之前終止了 HTTPS 連接，則除非您的架構有意在受信任的上游伺服器上新增了 HSTS，否則請在該公用 TLS 層設定 HSTS。僅由後端新增的標頭可能會被代理伺服器移除或取代。反之，在兩層都設定 HSTS 可能會導致重複值。請檢查代理伺服器的回應標頭配置，並確保其 HTTPS 路由是正在測試的路由。保持 Nextcloud 的受信任代理程式和 HTTPS URL 設定與現有部署保持一致，但不要將這些設定視為發送標頭的替代方案。

驗證公眾反應

1. 使用平台的語法檢查器檢查已變更的 Web 伺服器或代理程式配置。
2. 重新載入或部署已驗證的配置。
3. 請求公共 HTTPS 位址並檢查回應頭：curl -sSI https://cloud.example.com/尋找至少Strict-Transport-Security為.max-age15552000
4. 在瀏覽器的開發者工具中，檢查來自相同公用主機名稱的回應。這可以揭示是否存在篡改請求頭的代理，或者是否存在繞過預期虛擬主機的路由。
5. 重新載入 Nextcloud 的管理 → 概覽頁面，並允許其安全檢查刷新。

如果curl未顯示 HSTS 標頭，請確認 DNS 指向您編輯的端點，要求使用 HTTPS，且代理程式未移除該標頭。如果該標頭出現在首頁但未出現在其他回應中，請檢查 NGINX 位置級指令或代理回應標頭規則。如果公共回應正確但 Nextcloud 仍然發出警告，請驗證管理員檢查是否使用相同的外部可見主機名稱和協議，然後檢查伺服器和檢查之間的任何快取或代理層。

僅在進行全局審查後才使用預加載

預載是一個獨立且影響重大的選擇。預先載入指令本身並不會註冊網域名稱；瀏覽器預先載入清單有其自身的提交要求。目前的瀏覽器指南要求長時間max-age註冊includeSubDomains。 Nextcloud 警告稱，從已發布的預先載入清單中移除網域可能需要數月才能生效。因此，在應用預先載入策略之前，請先執行基準策略，清點所有受影響的主機名，確認 HTTPS 在整個網域中都能正常運作，並查看官方的預先載入要求。大多數 Nextcloud 管理員無需選擇預先載入即可解決此特定警告。

參考資料：Nextcloud 35 安全警告、Nextcloud 加強指南、Nextcloud NGINX 設定和MDN 的 HSTS 標頭參考。