透過尋找故障路由來恢復 ownCloud WebDAV 同步

要修復「WebDAV 介面似乎已損壞」的警告，請確認 ownCloud 的 DAV 端點可訪問，並且您的 Web 伺服器已將 WebDAV 請求（包括指定PROPFIND方法）轉發到 ownCloud 的 PHP 應用程式。正確的變更取決於公用 URL 是由 Apache、Nginx 還是反向代理處理；在編輯配置之前測試端點，以便修復故障層。

找出警告實際測試的內容

ownCloud Classic 的管理檢查器會在檔案同步檢查無法使用 WebDAV 介面時報告此警告。這通常是 Web 伺服器或請求路徑的問題，並不一定意味著檔案或資料庫已損壞。 ownCloud Server 11 的官方警告參考文件對此警告進行了單獨描述，/.well-known/caldav與/.well-known/carddav服務發現檢查無關。

使用與您的公共安裝路徑相符的 DAV 端點。在域根目錄下，端點通常為 `<path>` https://cloud.example.com/remote.php/dav；如果安裝在子目錄中，則需要包含該端點，例如 `<path>` https://cloud.example.com/owncloud/remote.php/dav。 ownCloud Classic 10.16 也提供了某些桌面和檔案管理器連接的兼容性 URL /remote.php/webdav。請勿在所有設定中將舊的客戶端 URL 和新的 DAV 端點視為可互換。

發送PROPFIND深度為零的已認證請求。在此命令中，請替換範例主機/路徑和使用者名稱。由於僅提供了用戶名，Curl 會提示輸入密碼-u。

curl -i -u 'USERNAME' -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/owncloud/remote.php/dav'

成功的 WebDAV 回應通常是207 Multi-Status。其他回應可作為線索：例如，如果回應為301或 ，302則表示重定向或規範 URL 存在問題；401如果回應為 ，則表示身份驗證未通過；如果回應為 ，則404通常表示路徑或 PHP 重寫未到達 ownCloud；如果回應為405，則501表示伺服器、代理或安全層拒絕了 DAV 方法。瀏覽器開啟 URL 並顯示登入頁面並不能證明 WebDAVPROPFIND成功。

根據 Web 伺服器佈局選擇修復方案

Apache：保持 ownCloud 的重寫規則有效

對於標準的 Apache 安裝，首先要檢查 ownCloud 提供的.htaccess檔案是否存在，以及 Apache 是否允許在安裝目錄中使用其重寫指令。 ownCloud 安裝程式和升級過程會維護這些規則。如果某些設定AllowOverride None阻止 Apache 讀取這些規則，則需要允許 ownCloud 目錄進行必要的覆蓋，或將等效規則移至虛擬主機配置中。對於典型的單一 ownCloud 站點，第一種方法更易於維護；當策略要求在應用程式目錄之外進行配置時，集中式虛擬主機規則可能更合適。

請勿將通用的重寫區塊貼到已生效的配置之上。請確認mod_rewrite已啟用，網站指向正確的 ownCloud 文件根目錄，並且請求能夠/remote.php/dav存取 PHP 處理程序。變更 Apache 配置後，請在重新載入之前執行其配置測試。在基於 Docker 的 ownCloud Classic 11 中，映像會管理其嵌入式 Apache 配置；請使用映像支援的設定和環境機制，而不是在執行的容器內編輯產生的檔案。請參閱ownCloud Server 11 故障排除文件。

Nginx：使用 ownCloud 伺服器配置

Nginx 不會讀取 Apache.htaccess檔案。如果 Nginx 直接為 ownCloud 提供服務，請使用與您的 ownCloud 版本和安裝路徑相符的 Nginx 配置，包括其 PHP 位置處理和 DAV 相關路由。自訂的最小 PHP 位置可能可以提供服務 Web 介面，但會傳回/remote.php/dav404 錯誤或將其傳遞給錯誤的處理程序。請將您目前使用的伺服器設定區塊與供應商提供的ownCloud 10.16 安裝文件進行比較，然後測試設定並重新載入 Nginx。具體的指令取決於發行版、PHP-FPM 套接字以及 ownCloud 是位於域根目錄還是子目錄中。

反向代理：保留路徑、方法和公用 URL

如果代理程式終止了 HTTPS 連線或路由了子路徑（例如 `/usr/local/bin`）/cloud，請檢查它是否將整個 DAV 路徑轉送到後端，並允許 WebDAV 方法（例如PROPFIND` PUT/usr/ MOVElocal/bin`、`/usr/local/bin`、`/usr/ DELETElocal/bin` 和 /`/us）。即使 PHP 端點正確，代理程式或 Web 應用防火牆也可能阻止某些方法。比較透過公用 URL 傳送的請求和從受信任網路直接傳送到後端的請求；如果直接存取傳回 207 狀態碼，但公用請求失敗，則應專注於檢查代理程式路由、方法篩選、重新導向和授權標頭。

僅將 ownCloud 的代理位址設定trusted_proxies為實際的代理位址。如果自動 URL 偵測失敗，`<proxy_address>` overwritehost、` <proxy_address> overwriteprotocol` 和overwritewebroot`<proxy_address>` 設定可以描述公共 URL，但它們無法修復被封鎖的 DAV 方法或缺少的 PHP 路由。不正確的代理信任可能導致偽造客戶端位址標頭。請使用適用於您網路拓撲的官方反向代理設定指南。

將 DAV 發現與文件存取分開

這些URL 幫助日曆和聯絡人用戶端發現服務端點。它們應該路由到 ownCloud 的 DAV 端點，但/.well-known/caldav如果/.well-known/carddav路由失敗，則會發出與檔案同步 WebDAV 檢查失敗不同的警告。僅修復這些發現重定向可能無法消除同步警告。對於 Apache 伺服器，ownCloud 自帶的規則在啟用後可以處理發現；Nginx 和子目錄部署需要匹配的伺服器設定。請按照ownCloud 官方警告指南，分別檢查每個 URL 及其重定向目標。

確認維修狀況

PROPFIND針對公用 DAV URL重複進行身份驗證測試，並確認其回傳成功207 Multi-Status。然後刷新 ownCloud 管理頁面，並使用桌面用戶端執行一個小型同步測試。如果請求仍然失敗，請將 HTTP 狀態碼和時間戳記與 Web 伺服器、代理、PHP 和 ownCloud 日誌進行比較。 ownCloud 文件指出，在 Docker 環境下，應用程式日誌可能位於掛載的日誌目錄中，而 Apache 和 PHP 日誌則傳送到容器輸出；docker compose logs owncloud這有助於定位這些錯誤。

ownCloud 目前的手冊涵蓋 Classic 11.0 和 10.16 兩個版本，不同版本的安裝方式有所不同；Classic 11 的文件明確指出其支援的安裝方式是 Docker。請使用已部署版本的手冊，避免盲目地將舊的 Apache 或 Nginx 設定程式碼片段套用到較新的容器或代理程式環境。