如何修復 ownCloud 行動應用程式「連線被拒絕」錯誤

ownCloud 行動應用程式中出現的「連線被拒絕」訊息通常表示在身分驗證開始之前就存在連線問題：手機已連線到某個位址，但請求的網路端點未接受連線。具體措辭可能因 Android 或 iOS 版本而異，因此請將此訊息視為症狀而非診斷結果。

以下僅為範例場景：假設有一家名為 Northstar Studio 的小型設計公司。其員工通常透過 ownCloud 行動應用程式連接https://cloud.example.com/owncloud。在更換反向代理後，多部手機顯示「連線被拒絕」。 ownCloud 網頁介面在辦公室管理員的筆記型電腦上仍然可以正常訪問，但無法透過行動數據訪問。本指南將使用此虛構場景來示範故障排除步驟如何銜接；這並非實際部署或測試結果的報告。

範例 ownCloud 行動帳戶螢幕，顯示伺服器位址 https://cloud.example.com/owncloud 和「連線被拒絕」訊息。 — 首先，請確保行動應用能夠準確連接伺服器位址。如果連線被拒絕，則無法成功登入 ownCloud。

首先，將「連線被拒絕」錯誤與登入錯誤區分開來。

不要一開始就重置使用者密碼。密碼錯誤、令牌過期或 OAuth 問題通常發生在客戶端能夠與伺服器通訊之後。 TCP 連線被拒絕更常見的原因是主機或連接埠錯誤、Web 伺服器或代理伺服器停止運作、防火牆規則，或服務僅監聽內部介面。

ownCloud 目前的行動應用程式文件確認，應用程式已配置為使用 ownCloud 伺服器 URL。 ownCloud WebDAV 文件也指出，行動應用程式應使用基本 URL 和資料夾（例如 `<your-base-url>/<your-base-url>`）example.com/owncloud，而不是手動輸入 WebDAV 端點。請參閱ownCloud WebDAV 存取文件。

1. 在行動應用程式中驗證 URL

在 Northstar 範例中，預期 URL 為 `<your_url_name>` https://cloud.example.com/owncloud。請檢查所有四個組成部分：協定、主機名稱、可選連接埠和路徑。常見錯誤包括：http://公共服務僅監聽 HTTPS 時使用 `<your_url_name>`，遺漏非標準端口，使用無法在公司外部解析的內部主機名，或輸入 DAV 端點而不是 ownCloud 基本 URL。

Android 文件指出，應用程式會在使用者輸入伺服器 URL 和憑證後測試連接，並建議使用啟用 SSL 的伺服器，以便使用 HTTPS 連接。 iOS 文件也類似，會在新增帳戶時檢查伺服器 URL、驗證方法和 TLS 憑證。請參閱ownCloud Android 連線指南和ownCloud iOS 帳戶指南。

範例行動瀏覽器顯示 cloud.example.com 拒絕連線到同一個 ownCloud URL — 在手機瀏覽器中開啟相同的網址。如果瀏覽器也無法存取，請專注於檢查網路連線和網路服務端點，而不是應用程式憑證。

2. 在應用外部測試相同的 URL

在出現問題的手機上，使用瀏覽器開啟 ownCloud 的 URL 位址。這是一個快速的分界線。如果瀏覽器可以加載 ownCloud 頁面，但應用程式無法加載，請檢查應用特定的憑證、重定向、OAuth 或帳戶配置。如果瀏覽器和應用程式在同一網路上都無法訪問，請繼續進行伺服器和網路檢查。

此外，還要從多個網路進行測試。以我們舉例的 Northstar 案例為例，辦公室 Wi-Fi 可以正常運作，但行動數據卻無法使用。這表示問題可能出在公共 DNS、防火牆、NAT 或反向代理暴露上，而不是 ownCloud 使用者名稱本身。

3. 確認公共端點確實在監聽

從一台可以存取伺服器的機器上，測試 URL 和監聽套接字。以下指令是有用的起點：

curl -I https://cloud.example.com/owncloud
sudo ss -tlnp | grep -E ':80|:443'

成功的 HTTP 回應不一定是重定向200；重定向也可以證明 Web 服務正在回應。關鍵在於 TCP 連線是否被接受。如果預期的公共連接埠上沒有任何監聽程序，請先解決此問題，然後再更改 ownCloud 應用程式設定。

終端示意圖顯示 curl 正在存取 ownCloud URL 和一個監聽 TCP 連接埠 443 的套接字。 — 伺服器端檢查可以確認 HTTPS 是否有回應以及是否有進程正在監聽 443 連接埠。

4. 檢查 Web 伺服器或反向代理

許多 ownCloud 部署會在應用程式前端部署 Apache、NGINX、HAProxy、Traefik 或其他代理程式。請確保面向公眾的服務正在運行，綁定到預期的接口，並將流量轉發到實際的 ownCloud 後端。如果代理程式已停止、僅綁定到某個介面127.0.0.1或配置了錯誤的上游端口，則可能導致立即拒絕存取。

ownCloud 對反向代理有明確的文件說明，並要求配置 ownCloud 信任的代理位址trusted_proxies。文件也說明了在代理伺服器後自動偵測主機名稱、協定或網站根目錄失敗時，如何覆寫這些設定。請參閱ownCloud 的反向代理設定指南。

範例伺服器終端機顯示了連接埠 80 和 443 的防火牆規則、正在執行的 nginx 服務以及指向 ownCloud 後端的反向代理路徑。 — 當代理伺服器位於 ownCloud 前面時，請同時驗證面向 Internet 的監聽器和代理伺服器到 ownCloud 後端的路徑。

5. 驗證防火牆、NAT 和網路路徑

如果 HTTPS 在伺服器端可以正常運作，但在區域網路外的手機上卻無法存取，請檢查主機防火牆、雲端安全群組、路由器或 NAT 規則，以及任何上游企業防火牆。對於正常的 HTTPS 部署，TCP 443 連接埠必須可透過公網位址存取。如果您有意使用自訂端口，則必須將該端口暴露出來並包含在 URL 中。

不要將停用防火牆作為永久解決方案。相反，應該確定所需的監聽器，並僅允許設計所需的流量通過。在 Northstar 場景中，真正有用的問題不是“防火牆是否已開啟？”，而是“外部客戶端能否存取 ownCloud 發布的位址和連接埠？”

手機網路設定示意圖，顯示已啟用 Wi-Fi 和行動網絡，以便在第二個網路上測試 ownCloud 連接 — 在 Wi-Fi 和行動數據之間切換是確定拒絕是否遵循某一網路路徑的實用方法。

6. 連接埠可達後，檢查 TLS 憑證和重定向。

憑證問題與實際的 TCP 連線拒絕不同，但通常會在修復網路連通性問題後立即出現。目前的 iOS 文件指出，應用程式會在新增伺服器時檢查 TLS 證書，並允許使用者查看證書詳情。 Android 文件也描述了無法驗證憑證的警告資訊。

盡可能使用主機名稱與 ownCloud 公共主機名稱相符且憑證鏈受裝置信任的憑證。此外，請檢查 HTTP 到 HTTPS 的重定向。 iOS 安全文件指出，登入期間的重定向不會被靜默執行；系統會提示使用者批准。請參閱ownCloud iOS 安全性文件。

範例 ownCloud 行動帳戶畫面顯示了相同的伺服器 URL 以及成功的安全連線。 — 在網路連線和 TLS 連線正常後，行動用戶端應該能夠透過初始伺服器連線檢查。

7. 確認 ownCloud 受信任域和代理 URL 處理

Web 伺服器接受連線後，請驗證 ownCloud 是否能辨識手機使用的主機名稱。 ownCloud 要求用於存取伺服器的 URL 必須已獲得許可trusted_domains。當您引入新的公共主機名稱、遷移服務或將先前的內部安裝暴露出來時，這一點尤其重要。

對於傳統安裝方式，請檢查配置而不是盲目編輯。您可以使用occ以下命令讀取已配置的網域：

sudo -u www-data ./occ config:system:get trusted_domains

如果缺少公共主機名，請使用occ config:system:set文件中規定的未使用陣列索引語法來新增它。官方命令參考可在ownCloud occ 命令文件OWNCLOUD_TRUSTED_DOMAINS中找到。對於容器部署，目前的 ownCloud 文件透過環境變數（例如`domain` 和 `proxy`）公開了等效的網域和代理相關設定OWNCLOUD_TRUSTED_PROXIES。

範例 config.php 編輯器，展示了 trusted_domains、HTTPS 覆蓋協定、公共主機和 /owncloud 網站根目錄設定。 — 受信任域和覆蓋設定會在網路端點可達之後變得重要，尤其是在反向代理之後。

8. 使用原手機重新測試並比較結果

返回故障裝置並依照下列步驟進行測試：首先在瀏覽器中開啟 URL，然後新增或重新連接 ownCloud 帳戶，接著開啟「檔案」視圖並確認顯示目錄清單。如果該服務需要在 Wi-Fi 和行動數據網路下都能正常運作，請分別在 Wi-Fi 和行動數據網路下重複上述步驟。

以 Northstar 為例，假設管理者發現替換後的反向代理僅在私有介面上監聽 443 連接埠。正確綁定公共監聽器即可解釋為何辦公室存取正常，而行動網路存取卻被拒絕。這只是一個推理過程的範例，並非針對實際的 ownCloud 事件。

連接成功後，桌面和行動裝置上會顯示範例 ownCloud 檔案列表 — 最後一個有用的檢查是，網頁介面和行動應用程式都能連接到同一個伺服器，並顯示預期的檔案層次結構。

快速診斷表

你所觀察到的	接下來最有用的檢查
應用程式和手機瀏覽器都被拒絕	公用主機名稱、連接埠、監聽器、防火牆、NAT、代理服務
可在 Wi-Fi 下使用，但不能在行動數據下使用	公共 DNS 和麵向網際網路的防火牆/NAT/代理路徑
瀏覽器運作正常，應用程式在憑證審核階段停止執行	TLS主機名稱、憑證鏈、重新導向
伺服器回應，但ownCloud拒絕主機連線。	`trusted_domains`以及反向代理覆蓋設定
連線成功但登入失敗	憑證、OAuth2、雙重認證或令牌策略

首先不要改變什麼

即使行動應用程式顯示“連線被拒絕”，也不要輕易更改密碼、資料庫設定、檔案權限或 PHP 記憶體限制。這些設定可能與 ownCloud 的其他故障有關，但如果客戶端完全無法建立網路連接，則不應先排查這些設定。同樣，不要為了修復公共 TLS 配置而永久忽略憑證警告。

最終核查清單

手機使用預期的 ownCloud 基本 URL，包括正確的協定、主機名稱、路徑以及（如果適用）非標準連接埠。
手機所連接的網路能夠正確解析主機名稱。
公共 Web 伺服器或反向代理正在監聽預期的 TCP 連接埠。
主機、雲端、路由器和上游防火牆允許預期的流量通過。
反向代理可以存取 ownCloud 後端。
TLS 憑證適用於公用主機名，並已被裝置接受。
主機名稱已存在於 ownCloud 的受信任域配置中。
網頁介面和行動應用程式在部署應該支援的任何網路上都能正常運作。

截至 2026 年 10 月，ownCloud 發布了其經典伺服器以及獨立的 Android 和 iOS 行動用戶端的最新文件。由於應用程式版本更新後標籤和介面可能會有所變化，因此請遵循上述故障排除順序作為可靠的方法：首先驗證網路連線是否正常，然後驗證代理程式和 TLS 行為，最後再檢查 ownCloud 應用程式和驗證設定。