修正 SLES 系統中 Zypper 儲存庫刷新失敗錯誤 500 的問題。

舉例說明：假設一位名叫 Maya 的 SLES 管理員sudo zypper refresh在例行維護視窗結束後執行程式。一個儲存庫傳回“錯誤 500：內部伺服器錯誤”，而其他儲存庫則正常刷新。 Maya 的例子是假設的，但它顯示了關鍵的診斷要點：HTTP 500 錯誤是伺服器或代理等中間伺服器的回應，並不代表 Zypper 的本地元資料快取已損壞。

要修復 SUSE Linux Enterprise Server (SLES) 中的 Zypper 儲存庫刷新失敗問題，首先要確定故障的確切儲存庫及其 URL，然後確定回應是來自 SUSE 用戶中心 (SCC)、內部儲存庫鏡像工具 (RMT) 伺服器還是網路代理程式。只有在檢查了端點之後，才能嘗試強制刷新元資料。在沒有證據的情況下重新註冊電腦或刪除儲存庫配置可能會使問題更難診斷。

刷新期間出現 HTTP 500 錯誤代表什麼？

當 Zypper 刷新儲存庫時，它會從配置的 URI 下載儲存庫元資料。 HTTP 500 回應表示處理該請求的 HTTP 伺服器報告了內部錯誤。該伺服器可能是儲存庫主機、組織的鏡像伺服器，或位於 SLES 機器和儲存庫之間的代理伺服器。僅憑代碼無法確定是哪個伺服器發生故障，也無法確定 SUSE 的服務是否已關閉。

目前的 SUSE 管理指南zypper refresh將取得儲存庫變更的常規方法描述為強制執行完整刷新，並建議zypper refresh -fdb在刷新無法解決儲存庫元資料問題時執行此操作。後者會強制執行完整刷新並重建軟體包資料庫，包括強制下載原始元資料。它可以修復過時的本地元數據，但無法修復持續返回 HTTP 500 的伺服器。請參閱 SUSE 的SLES 15 SP7 管理指南。

1. 確定儲存庫並記錄確切的故障訊息

在 Maya 的範例中，刷新輸出在報告錯誤之前會列出一個儲存庫別名。首先重複執行一次該指令，並記下別名、請求 URL 主機以及其他儲存庫是否成功：

sudo zypper refresh

然後列出儲存庫別名及其配置的 URL：

zypper lr -u

將刷新輸出中失敗的別名與此清單中對應的 URI 進行比對。如果 URI 託管在組織的 RMT 或其他私有鏡像伺服器上，則應與該伺服器的管理員聯絡進行調查。如果 URI 指向公共 SUSE 服務，則應從受影響的網路進行檢查，如果可能，也應從第二個網路或其他 SLES 用戶端進行檢查。

儲存庫 URL 可能包含存取詳細資訊或簽署查詢參數。請勿在公共論壇發布未經編輯的命令輸出、支援包或 URL。請保留儲存庫別名、主機名稱、時間戳記、SLES 服務包和回應代碼；請編輯憑證和令牌。

2. 檢查錯誤是本地的、共享的還是上游的

在更改配置之前，請先進行簡單的比較。如果只有一台伺服器上的一個儲存庫發生故障，請檢查該儲存庫的 URL 及其服務。如果同一網路上的多個用戶端上的同一個儲存庫發生故障，請檢查共用代理程式、防火牆或鏡像。如果不同網路上的多個用戶端都無法存取同一個 SUSE 端點，則上游出現暫時性問題的可能性較大。這些模式僅供參考，並非確鑿證據；請與服務所有者或您所在組織的支援管道確認。

對於您有權查詢的端點，HTTP 用戶端可以顯示回應頭和最終狀態。盡可能使用準確的儲存庫元資料 URL，而不是假設儲存庫根目錄會傳回相同的回應。例如：

curl -sS -L -D - -o /dev/null 'https://repository.example.invalid/path/to/metadata'

請將範例 URL 替換為受影響的端點。請勿在共享的命令中包含嵌入式憑證或令牌。代理程式產生的錯誤頁面仍可能顯示 HTTP 500 錯誤，因此，只有當您的網路原則允許時，才可比較來自已核准的直接路徑或其他用戶端的回應。未經授權，請勿繞過必要的企業代理或安全網關。

如果故障倉庫是自訂倉庫，請其維護者檢查伺服器日誌、儲存容量、後端運作狀況以及倉庫元資料發布。如果 URL 指向 RMT，請先追蹤 RMT 的問題，而不是重複更改用戶端。 SUSE 的RMT 指南解釋說，RMT 會從 SCC 同步倉庫產品數據，並按照自身的計劃鏡像倉庫軟體包。

3. 檢查代理程式和網路配置

當上游服務無法使用、無法處理上游回應或代理設定錯誤時，網關或代理程式可能會傳回自身的 500 回應。請將故障機器的網路路徑與一台正常運作的 SLES 主機進行比較。檢查作業系統和 Zypper 的代理配置，包括儲存庫主機名稱是否意外地透過代理程式傳送或被排除在代理程式之外。

如果代理程式配置包含使用者名稱、密碼或內部主機名，請勿公開貼上。如果您是代理伺服器的管理員，請其管理員將請求時間戳與代理日誌進行比對，並確認 500 錯誤是源自代理伺服器還是上游伺服器。如果禁止直接訪問，請確保調查範圍在已批准的代理路徑內。

Maya 的例子現在有了清晰的分支：她的其他倉庫都能正常運作，只有組織內部的鏡像在多台伺服器上出現故障。這種模式首先指向共享鏡像或代理團隊，而不是系統範圍內的 SLES 註冊問題。

4. 驗證 SLES 註冊資訊和儲存庫 URL

對於透過 SUSE 註冊提供的儲存庫，請檢查系統中已註冊的產品和模組：

SUSEConnect -s
zypper lr -u

SUSE 文件SUSEConnect -s用於檢查本機安裝的產品及其狀態，以及zypper lr -u列出軟體倉庫及其來源 URI。請將輸出結果與此計算機預期使用的 SLES 版本和模組進行比較。不正確或過時的 URI 可能會導致來自已停用、不符合或配置不當的端點的錯誤。

如果缺少註冊資訊或缺少必要模組，請按照適用於您的 SLES 版本和訂閱的產品註冊流程進行操作。 SUSE 的註冊指南介紹如何註冊 SLES 以及如何管理模組和擴充。請勿在收到 HTTP 500 錯誤後立即登出或重新註冊生產環境的機器：SUSE 指出，登出作業會刪除產品的軟體倉庫，因此註冊變更應事先與系統擁有者協商。

對於自管理儲存庫，請驗證其配置的基本 URL 是否與儲存庫供應商的目前說明以及已安裝的 SLES 版本和架構相符。切勿透過更改服務包編號來猜測路徑。如果您修正了 URI，請記錄原始值，並使用常規組態管理流程僅變更受影響的儲存庫。

5. 端點恢復正常後，嘗試強制刷新重試。

伺服器或代理擁有者確認端點回應正常後，或您修復了已驗證的 URL 問題後，請重試儲存庫刷新。首先進行一次正常的刷新：

sudo zypper refresh

如果元資料仍然顯示過時或不完整，請使用 SUSE 文件中記錄的完整刷新方法：

sudo zypper refresh -fdb

這會強制 Zypper 下載原始元資料並重建其本機可解析資料庫。這是遠端端點恢復正常後一個有用的恢復步驟。如果仍傳回相同的 HTTP 500 錯誤，請停止重複執行該指令，並返回端點、代理程式或鏡像的故障排查階段；本機快取重建無法解決伺服器端故障。

6. 安全地處理一個損壞的選用儲存庫

如果確認某個第三方倉庫不可用，且您需要進行維護，請在停用該倉庫之前諮詢倉庫所有者並遵循您的變更策略。 Zypper 可以透過別名停用倉庫：

sudo zypper modifyrepo --disable REPOSITORY_ALIAS

使用與原倉庫完全相同的別名zypper lr，並記錄變更。停用軟體倉庫可能會阻止從該倉庫安裝的軟體進行更新。請勿將停用核心 SLES 更新倉庫作為一刀切的臨時解決方案，也不要僅為了消除錯誤而刪除倉庫定義。在維護者確認恢復後，重新啟用暫時停用的倉庫：

sudo zypper modifyrepo --enable REPOSITORY_ALIAS

SLES 管理指南文件介紹如何使用zypper modifyrepo. 啟用和停用儲存庫。儲存庫的行為和可用選項可能會因已安裝的 Zypper 版本而異；zypper help modifyrepo如果選項語法不同，請在主機上進行檢查。

確認維修狀況

最後執行一次徹底的刷新操作，並檢查哪些儲存庫已啟用並已排程刷新：

sudo zypper refresh
zypper lr -u

成功意味著先前失敗的儲存庫完成了元資料刷新，沒有出現 HTTP 500 錯誤，並且預期的儲存庫保持啟用狀態，且 URL 正確。如果僅在停用某個儲存庫後刷新才成功，則應將其視為臨時解決方案，而非徹底修復：來自該來源的軟體包可能不再接收更新。

在 Maya 的範例案例中，鏡像管理員修復了伺服器端回應。然後，Maya 執行常規刷新操作，-fdb僅在本地元資料仍需重建時才執行此操作，並確認鏡像別名已刷新成功。此結果僅為診斷流程範例，並非實際測試報告。

何時升級

當多個客戶端從內部端點收到相同回應時，請聯絡鏡像或代理團隊。如果在檢查本機網路路徑和註冊資訊後，錯誤仍可在官方 SUSE 端點上重現，請聯絡儲存庫擁有者或 SUSE 支援。請提供 SLES 版本和服務包、儲存庫別名、主機名稱（敏感路徑資訊已隱去）、時間戳記和時區、其他儲存庫是否刷新以及 HTTP 狀態或已脫敏的錯誤資訊摘要。這些資訊有助於服務擁有者在不洩露註冊碼或憑證的情況下追蹤失敗的請求。