SLES Zypper HTTP 500：尋找故障儲存庫

當zypper refreshSLES 系統傳回 HTTP 500 錯誤時，首先要確定是哪個儲存庫 URL 傳回的。 HTTP 500 表示處理請求的伺服器遇到了意外情況；回應伺服器可能是儲存庫主機、組織的 RMT 伺服器或 HTTP 代理。隔離故障儲存庫，並在清除本機元資料之前修復或報告該端點。強制重建快取無法修復仍回傳 500 錯誤的伺服器。

SUSE 目前的 SLES 15 SP7 管理和升級指南文件中記錄了儲存庫清單和刷新命令，包括zypper refresh -fdb重建本機儲存庫元資料的命令。但這些指南並未提及目前 SLES 範圍內的 HTTP 500 錯誤。實際的解決方法取決於該 URL 指向的是 SUSE 客戶中心、內部鏡像還是第三方儲存庫。

是一個倉庫故障還是多個倉庫都故障？

首先記錄儲存庫別名和 URL。在 SLES 系統上，運作：

zypper repos -u

此-u選項會顯示每個已配置儲存庫的來源。記下哪些項目已啟用並設定為刷新，然後比較失敗 URL 的主機名稱。如果某個第三方儲存庫失敗，而 SUSE 更新來源刷新成功，則應調查該儲存庫的擁有者。如果多個儲存庫指向相同內部主機且全部失敗，則共用映像、RMT 服務、反向代理或其上游連線更有可能是問題所在。

接下來，僅按別名刷新受影響的儲存庫：

sudo zypper refresh -f 'Vendor-App'

請替換Vendor-App為顯示的準確別名zypper repos -u。這樣可以避免螢幕上出現來自無關倉庫的重複錯誤，並為您提供一個重點明確的結果，以便與管理員分享。如果別名包含空格，請保留單引號。請保留故障的準確 URL 和時間戳，但在發送日誌或螢幕截圖之前，請刪除任何嵌入的使用者名稱、密碼、令牌或其他敏感資訊。

元資料端點本身是否回傳 HTTP 500 錯誤？

閱讀完整的 Zypper 錯誤訊息，並確定其中指定的元資料 URL，該 URL 通常是儲存庫repodata目錄下的一個檔案。如果無需憑證即可查詢該端點，請將其與 SLES 主機傳回的 HTTP 回應進行比較：

curl -sS -D - -o /dev/null --max-time 20 "$METADATA_URL"

設定METADATA_URL為故障的元資料 URL，但不要將憑證放在 URL 或命令列中。此指令會列印回應頭並丟棄回應正文。類似這樣的結果HTTP/1.1 500確認請求路徑中的某個伺服器回傳了錯誤；但它並不能證明錯誤是由來源伺服器還是中間伺服器產生的。 Curl 使用的身份驗證或代理設定可能與 Zypper 不同，因此請將此視為對比，而非最終的複現。如果儲存庫存取需要身份驗證，請使用貴組織認可的測試方法，而不是暴露憑證。

500 回應與本地元資料快取問題不同。它也不同於 DNS 故障、TLS 憑證錯誤、逾時以及驗證回應（例如 401 或 403）。這些訊息需要不同的檢查。請勿停用 TLS 驗證、將儲存庫變更為純 HTTP 或重複刪除快取來消除 500 錯誤。對於 HTTP 語義，RFC 9110 將 500 定義為阻止請求完成的意外伺服器狀況。

應該在哪裡進行維修？

• SUSE 客戶中心儲存庫：如果故障看似暫時性的，請在短時間內重試一次。如果相同 SUSE 託管端點持續傳回 500 錯誤，請記錄產品、服務包、架構、儲存庫 URL 和故障時間，然後聯絡您所在組織的 SUSE 支援。如果回應顯示存在授權或存取問題，請確認註冊和訂閱詳細資訊；HTTP 500 錯誤本身並不能確定訂閱無效。
• RMT 或其他內部鏡像：請鏡像管理員檢查記錄時間點的伺服器和反向代理日誌，確認所要求的儲存庫已啟用並同步，並驗證元資料檔案是否存在於服務路徑。 SUSE 將 RMT 說明為 SLES 用戶端從本機伺服器擷取更新而非直接聯絡 SCC 的一種方式。
• 第三方軟體倉庫：請檢查供應商目前的軟體倉庫說明，並確認 URL 與已安裝的 SLES 版本和架構相符。如果軟體倉庫已遷移，請僅將其更新為該供應商發布的 URL。僅在確認軟體倉庫是可選且不再需要後才停用它；切勿為了掩蓋錯誤而停用必需的 SLES 更新來源。

您可以使用 Zypper 或 YaST 檢查和變更儲存庫狀態。例如，文件中提供的zypper modifyrepo命令可以透過別名停用儲存庫，但這只是臨時的操作選擇，並非修復故障來源的根本方法。請避免隨意編輯產生的儲存庫 URL，尤其是在服務包遷移之後，因為產品儲存庫和更新儲存庫使用特定版本的路徑。

何時應該重建本地元資料快取？

只有在伺服器或代理程式傳回有效回應後，才應重試所有已啟用的儲存庫：

sudo zypper refresh -f

如果終端現在有回應，但 Zypper 仍然報告本地儲存庫資料過時或不一致，SUSE 的 SLES 15 SP7 故障排除部分建議使用以下命令完成元資料刷新和資料庫重建：

sudo zypper refresh -fdb

這將強制下載原始元資料並重建 Zypper 的本機可解析資料庫。它適用於解決本地元資料問題；但無法解決持續出現的 500 回應。請勿將刷新儲存庫元資料與安裝更新混淆：僅在刷新成功完成後才執行常規的修補程式或更新命令。

如何驗證修復是否成功？

zypper refresh -f 'ALIAS'首先對先前失敗的來源執行此操作，然後sudo zypper refresh -f對所有已啟用的儲存庫執行此操作。當受影響的儲存庫元資料下載成功且未出現 HTTP 500 錯誤，且 Zypper 完成且未發現任何失敗的已啟用來源時，即確認修復已成功。如果仍然有某個來源失敗，請保留完整的 URL、狀態碼、回應頭和時間，並將其提供給該端點的擁有者。

官方參考資料

• SUSE SLES 15 SP7 管理指南— 管理儲存庫和已記錄的強制元資料刷新。
• SUSE SLES 15 SP7 升級指南— 列出已註冊的儲存庫及其來源 URL。
• SUSE SLES 15 SP7 儲存庫鏡像工具指南— 設定客戶端以使用 RMT。
• IETF RFC 9110：HTTP 語意— HTTP 狀態碼定義，包括 500 內部伺服器錯誤。