如何在 Nextcloud 中啟用伺服器端加密而不明顯影響效能

截至 2026 年 10 月，Nextcloud 35 穩定版管理員文件比許多舊版教學更清楚地闡明了一個重要觀點：伺服器端加密 (SSE) 主要用於保護儲存在外部第三方儲存上的文件，並且預設的主金鑰模式比用戶金鑰模式提供更好的效能和更廣泛的身份驗證相容性。該文件還指出，與 Nextcloud 25 之前的版本相比，加密檔案現在僅增加約 1% 的儲存開銷。

但這並不意味著加密完全免費。每一次加密讀取和寫入都需要加密運算，因此任何負責任的指南都無法保證在每台伺服器上實現零 CPU 開銷或零延遲。實際目標有所不同：以一種既能避免用戶明顯感受到速度下降，又能控制資料庫和鎖定壓力，並且只加密真正需要加密的儲存的方式來啟用加密。

Nextcloud 伺服器端加密保護的內容

Nextcloud SSE 會在伺服器端對檔案內容進行加密，然後再儲存。當使用者透過 Nextcloud 下載或開啟檔案時，伺服器會在將檔案傳送給授權使用者之前對其進行解密。加密金鑰保留在 Nextcloud 伺服器上，因此，當實際文件資料儲存在您不完全信任的外部儲存提供者時，SSE 就顯得尤為有用。

SSE 不會隱藏檔案名稱或目錄結構，也無法保護檔案免受惡意 Nextcloud 管理員或完全被攻破的應用程式伺服器的攻擊。如果要求即使是伺服器管理員也無法讀取文件，那麼 Nextcloud 的端對端加密模型才是更合適的安全層。官方比較資訊請參閱Nextcloud 伺服器端加密文件。

選擇能最大限度減少不必要工作的配置。

步驟 1：備份實例並建立效能基線

加密金鑰和實例金鑰是至關重要的復原資料。 Nextcloud 強烈建議在啟用 SSE 之前備份實例配置和加密金鑰。遺失必要的金鑰或實例金鑰可能會導致加密資料無法復原。

在進行變更之前，請使用對使用者至關重要的工作負載來取得簡單的基準資料。測量一些代表性的上傳和下載操作，並記錄 PHP-FPM CPU 使用率、資料庫負載、儲存延遲以及檔案應用的回應時間。您無需進行實驗室級的基準測試。您需要的是一個可重複的前後對比測試，該測試能夠告訴您此次更新是否改變了使用者可見的行為。

此外，也要確定是否真的需要加密本機儲存。如果您的目標是保護 S3、SMB、物件儲存或其他外部後端免受儲存提供者的攻擊，那麼將本機儲存置於 SSE 之外可以避免進行對當前威脅模型而言並無額外價值的加密工作。

步驟 2：在啟用加密之前，修復快取和檔案鎖定問題。

這是最重要的性能準備。 Nextcloud 建議使用記憶體快取以獲得最佳效能，並特別推薦使用 APCu 進行本機緩存，以及 Redis 或相容的後端來實現事務性檔案鎖定。事務性文件鎖定對於加密文件尤其重要，因為 Nextcloud 必須在加密和儲存作業進行的同時安全地協調文件變更。

常見的單一伺服器配置使用 APCu 作為本地緩存，Redis 作為鎖定：

'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => '127.0.0.1',
    'port' => 6379,
    'dbindex' => 0,
],

如果 Redis 和 Nextcloud 運行在同一主機上，Nextcloud 的檔案鎖定文件建議盡可能使用 Unix 套接字。較新的 Nextcloud 35 文件還介紹了適用於 Redis 或 Valkey 相容伺服器的捆綁式 KeyValueCache 選項，該選項無需 phpredis PHP 擴充功能即可提供交易鎖定。請使用與您的部署相符的配置，而不是盲目複製範例。

還應啟用 PHP OPcache 並調整其大小，以避免重複清除已編譯的程式碼。 Nextcloud 的伺服器調優指南指出，OPcache 可以提升 PHP 應用程式的效能，並在配置的限制超過 90% 的利用率時向管理員發出警告。在部署之前，請務必查看官方的記憶體快取指南、事務性文件鎖定指南和伺服器調優指南。

步驟 3：啟用預設加密模組並使用主密鑰模式

對於大多數目前部署而言，主密鑰模式是最佳的起點。 Nextcloud 35 將其列為預設模式，並推薦用於大多數部署，同時指出它能提供更好的效能，並與更多登入相容。其缺點也很明顯：控制伺服器的管理員可以解密使用者檔案。如果這無法接受，那麼使用主金鑰的 SSE 就不是適當的安全邊界。

在網頁介面中，開啟管理員設定中的「伺服器端加密」部分，啟用伺服器端加密，然後如果 Nextcloud 報告未載入加密模組，則從「應用程式」啟用 Nextcloud 預設加密模組。返回加密設定並確認已選擇該模組。登出並重新登錄，以便初始化加密金鑰。

您也可以使用以下命令管理加密occ。目前命令參考文件記錄了以下步驟：

sudo -E -u www-data php occ app:enable encryption
sudo -E -u www-data php occ encryption:enable
sudo -E -u www-data php occ encryption:status

如果 SSE 的目的僅限於外部存儲，請在全面部署之前取消對家庭存儲進行加密的選項。此舉可以顯著減少必須通過加密層的資料量。

步驟 4：加密目標外部掛載點，並使用實際流量進行驗證

外部儲存加密是按掛載點配置的。僅對需要加密的掛載點啟用加密，然後透過 Nextcloud 上傳一個範例檔案並再次下載。透過使用者實際使用的桌面、行動裝置、WebDAV 或瀏覽器工作流程驗證存取權限。

功能測試完成後，重複步驟 1 的基準測量。比較上傳時間、下載時間、CPU 使用率、資料庫活動和儲存延遲。如果變化很小且使用者可見的回應時間穩定，則伺服器有足夠的效能餘裕。如果效能急劇下降，不要想當然地認為加密本身是唯一原因。首先檢查是否有基於資料庫的檔案鎖定、PHP-FPM 工作進程過載、外部儲存速度慢、OPcache 不足或 Redis 連線問題。

如果您需要加密在啟用 SSE 之前已存在的文件，Nextcloud 提供了相應的加密功能encryption:encrypt-all。請將此操作視為遷移工作負載，而非普通的互動式請求。由於此操作可能涉及大量數據，因此請安排在維護視窗期間進行，並確保備份和回滾計劃完善。可用的加密命令已記錄在官方的 occ 加密參考文件中。

如何判斷推廣是否健康

• 用戶並未感覺到上傳或下載時間有明顯增加。比較更改前後相同檔案大小和客戶端的使用情況。
• 資料庫負載保持穩定。資料庫活動大幅增加可能表示檔案鎖定仍在使用資料庫，而不是 Redis 或 Valkey。
• PHP 工作進程不缺 CPU 資源。加密操作會增加 CPU 負載，因此原本已接近滿載運轉的執行個體需要更多 CPU 資源。
• 在適當情況下，外部儲存延遲仍然是主要因素。速度較慢的 S3、SMB 或遠端物件儲存很容易超過加密成本。
• 管理概覽和日誌中均未顯示加密或金鑰警告。請在擴大部署範圍前解決這些警告。

導致可避免的延誤的常見錯誤

當僅需保護外部儲存空間時，也需要加密本機儲存。

這會增加加密 I/O 的數量，但可能無法解決實際威脅。請根據啟用 SSE 的原因來決定加密範圍。

在資料庫中留下事務鎖

Nextcloud 的文檔指出，預設的資料庫鎖定後端會為資料庫帶來很大的負載。使用基於 Redis 或 Valkey 的鎖定快取是消除這瓶頸最直接的方法之一。

高峰時段運行批次加密

互動式流量和全資料加密傳輸會爭用 CPU、I/O、PHP 工作流程和儲存頻寬。請將遷移工作與正常的生產流量分開。

將 SSE 視為抵禦 Nextcloud 伺服器入侵的保護措施

伺服器可以存取 SSE 金鑰，因此惡意管理員或完全被攻陷的伺服器仍處於信任邊界內。當需要應對此類威脅時，請使用端對端加密。

結論

啟用 Nextcloud 伺服器端加密且不明顯影響效能的最安全方法是：縮小加密範圍，在信任模型適用時使用預設主金鑰，先設定 APCu 和 Redis 或 Valkey 鎖定，並在變更前後對實際工作負載進行基準測試。目前的 Nextcloud 35 指南支援這種方法：主金鑰模式是效能友善的預設模式，外部儲存是 SSE 的主要用例，加密檔案大小的開銷現在約為 1%。

首先請參閱 Nextcloud 35 官方伺服器端加密指南和伺服器端加密技術細節。這些文件應始終是金鑰管理行為、遷移命令和版本特定限制的權威參考。