如何修復 Nextcloud 的「伺服器沒有出站指向位址」警告

如果此警告出現在 Nextcloud 的「管理設定」→「概覽」中，請先檢查 Nextcloud 伺服器是否可以解析並存取其自身的規範 URL。將其設定overwrite.cli.url為使用者實際使用的 URL，然後從執行 Nextcloud 的相同主機或容器中測試該 URL。不要一開始就為伺服器分配固定的公共出站 IP 位址。

目前 Nextcloud 管理手冊中並未明確指出「伺服器沒有外寄位址」這句話的具體措詞。它可能是改寫、翻譯或其他警告訊息。以下故障排除步驟符合管理概述中記錄的自連線檢查。如果您在設定電子郵件時看到此訊息，請改用下方單獨的 SMTP 部分。

Nextcloud 會檢查什麼，以及它不包含哪些內容

從 Nextcloud 28 開始，管理設定 → 概覽中顯示的設定檢查將從伺服器端執行，而不是從瀏覽器執行。 Nextcloud 的升級說明指出，這些檢查可以發現 DNS 解析、伺服器到自身的可及性、防火牆以及容器網路方面的問題trusted_domains。overwrite.cli.url這意味著伺服器本身的網路路徑至關重要：在您筆記型電腦瀏覽器中可以正常存取的 URL，在 Nextcloud 主機或容器中可能無法存取。 Nextcloud 28 的設定檢查說明詳細描述了這項變更以及需要檢查的方面。

這與發布指向您伺服器的 DNS 記錄不同。私有安裝可以使用內部主機名稱或位址，前提是管理員和使用者可以透過這種方式存取它。外部存取、聯盟、公共共享連結和憑證頒發可能會有不同的要求。首先，請記下您看到警告的具體位置以及您正在執行的 Nextcloud 版本和安裝方法。

1. 編輯前請先閱讀目前 URL 和代理設定。

Nextcloud 將其主要配置儲存在 ` /etc/nextcloud.conf` 目錄中config/config.php，但運行該配置的路徑和命令occ取決於 Nextcloud 的安裝方式。如果是原始碼安裝，請在 Nextcloud 目錄中執行以下命令，並將範例路徑和 Web 伺服器帳戶替換為您自己的：

sudo -u www-data php /var/www/nextcloud/occ config:system:get trusted_domains
sudo -u www-data php /var/www/nextcloud/occ config:system:get overwrite.cli.url
sudo -u www-data php /var/www/nextcloud/occ config:system:get trusted_proxies

未設定的值可能不會產生任何輸出。對於 Snap、Docker 或虛擬設備，請occ在其預期環境中執行安裝程式支援的命令；主機端的 PHP 命令可能會讀取錯誤的配置，甚至根本無法讀取任何配置。在編輯目前配置之前，請先複製一份，並將副本儲存在 Nextcloud 的運行config目錄之外，以防止其被載入為額外的設定檔。

trusted_domains這是 Nextcloud 在傳入要求中接受的主機名稱或 IP 位址清單。overwrite.cli.url這是 Nextcloud 在常規 Web 請求之外產生 URL 時（例如透過 cron 或命令列作業）所使用的規格基本 URL。它應包含協議，並在相關情況下包含安裝子目錄。目前的Nextcloud 設定參考文件記錄了這些 URL 和代理參數。

2. 從 Nextcloud 環境測試 DNS 和 HTTPS

使用與設定檔中相同的主機名稱overwrite.cli.url。在 Nextcloud 伺服器上執行這些檢查；如果 Nextcloud 是容器化的，請在應用程式容器或同一網路上的等效容器內執行這些檢查：

getent ahosts cloud.example.com
curl --connect-timeout 10 -sS -o /dev/null -w 'HTTP %{http_code}\n'   https://cloud.example.com/status.php

請將 `<hostname>`替換cloud.example.com為您的真實主機名稱。如果 Nextcloud 安裝在子目錄中（例如 `<path>`）/nextcloud，請在 `<path>` 前新增該路徑/status.php。 ` <path> getent` 應該回傳伺服器可以路由到的位址。該curl命令應該完成 TLS 驗證，並從 Nextcloud 的狀態端點收到正常的 HTTP 回應。 DNS 故障、逾時、連線被拒絕、憑證錯誤或意外重定向會將問題範圍縮小到名稱解析、路由/防火牆、反向代理或 TLS。不要加入 `<pass-certificate-check>`-k來繞過憑證檢查；這樣做只會掩蓋問題，而不是解決問題。

如果 DNS 同時傳回 IPv4 和 IPv6 位址，請確認這兩個位址都是預期的，並且都能從 Nextcloud 環境存取。過期的 AAAA 記錄可能會導致某些用戶端或伺服器端檢查選擇不可用的 IPv6 路由。只有在確認該位址不再提供服務後，才能刪除或修正 DNS 記錄。如果網域名稱解析到您的公有 IP 位址，但伺服器無法透過路由器連接，請檢查 NAT 回環（也稱為環回 NAT）配置，或配置分離等級 DNS，以便主機名稱可以從您的內部網路解析到內部位址。

3. 將規範 URL 設定為使用者實際使用的位址

對於來源安裝，請設定overwrite.cli.url為外部或內部使用的基本 URL，包括 HTTPS 和子目錄（如果存在）。例如：

sudo -u www-data php /var/www/nextcloud/occ config:system:set overwrite.cli.url   --value="https://cloud.example.com"

如果使用者透過 `<your-password>` 存取 Nextcloud https://example.com/nextcloud，請/nextcloud在值中包含 `<your-password>`。請勿在此填寫 SMTP 主機名，也不要包含頁面路徑（例如 `<your-password>` /settings/admin）。 Nextcloud 將此描述為命令列和背景 URL 產生的規格基本 URL。上述範例路徑和帳戶僅適用於常見的來源安裝；Snap 和容器安裝需要使用其各自文件中記錄的命令。

如果主機名稱在清單中缺失trusted_domains，請使用下一個未使用的數字索引新增。請先檢查現有列表，以免取代現有條目：

sudo -u www-data php /var/www/nextcloud/occ config:system:set trusted_domains 1   --value="cloud.example.com"

變更1為安裝中未使用的索引。僅新增 Nextcloud 應接受的主機名稱或 IP 位址。此設定不會建立 DNS 記錄，也不會使私人伺服器公開可存取。

4. 僅當您的網路拓撲需要時才套用反向代理設定

當反向代理終止 HTTPS 連線並將 HTTP 請求傳送到 Nextcloud 時，應用程式可能會偵測到內部協定而非面向使用者的 HTTPS 協定。 Nextcloud 要求您在設定檔中列出實際的代理位址trusted_proxies。代理還必鬚髮送相應的轉發標頭。錯誤地信任代理或廣泛的網路可能會導致客戶端偽造其 IP 位址，因此請勿直接複製範例代理 IP 位址。

如果自動 URL 偵測仍然失敗，請僅設定所需的覆蓋值。對於終止 TLS 的代理，overwriteprotocol可能需要進行設定https。overwritehost僅當 Nextcloud 無法使用代理轉送的正確主機時才設定此值；overwritewebroot僅當公共路徑未被正確偵測到時才設定此值。目前的Nextcloud 反向代理指南提供了一個範例，並警告說，受信任的代理設定取決於實際的代理軟體和網路。

5. 如果 URL 仍然無法訪問，請檢查防火牆、DNS 和容器路由。

如果 URL 正確但伺服器端curl測試失敗，請檢查 Nextcloud 與該 URL 之間的路徑。確認出站 HTTPS 已允許，容器可以查詢 DNS，並且反向代理可以將請求路由回應用程式。主機防火牆、雲端安全群組、路由器、代理程式規則或容器網路都可能封鎖此路徑。 Nextcloud 的文檔特別指出，當伺服器端檢查無法存取已設定的 URL 時，應檢查防火牆和容器網路配置。

不要為了透過自我檢查而向整個互聯網開放入站端口。如果這是一個有意設定為私有的 Nextcloud 伺服器，請使用在私有網路內部有效的主機名稱和路由。只有當服務必須能夠從外部存取時，才需要公共 DNS、路由器轉送和外部可存取的位址。如果您位於阻止入站存取的 NAT 提供者之後，那麼使用 VPN 或受支援的反向代理/隧道方案可能比更改 Nextcloud 的受信任網域清單更合適。

如果訊息來自電子郵件設定頁面

電子郵件是 Nextcloud 的一項獨立功能。 Nextcloud 本身並沒有包含完整的郵件伺服器；它需要連接到現有的 SMTP 伺服器、qmail 或 Sendmail。在「管理設定」→「基本設定」中，根據郵件提供者的要求，提供郵件伺服器的主機名稱和連接埠、加密模式、寄件者位址和憑證。使用 Nextcloud 的「傳送電子郵件」按鈕進行測試。 Nextcloud 的 Web URL 可以正常運作並不代表 SMTP 伺服器可以訪問，SMTP 伺服器主機名稱也不能取代郵件伺服器的設定資訊overwrite.cli.url。 Nextcloud的電子郵件設定指南詳細介紹了目前的郵件設定和測試方法。

核實結果，避免常見誤診

更改後，請從相同伺服器或容器重複執行 DNS 和 HTTPS 檢查，然後重新載入「管理設定」→「概覽」。確認您的使用者仍然可以透過其常用 URL 登錄，且後台產生的連結使用正確的協定和路徑。如果警告仍然存在，請記錄其完整文字、Nextcloud 版本、安裝方法以及伺服器端命令輸出。這些資訊有助於區分 URL 偵測問題、SMTP 故障或網路原則問題。

• 已驗證：目前的 Nextcloud 文件指出，伺服器端設定檢查需要配置主機名稱和規範 URL 才能解析並從伺服器存取。
• 取決於您的設定：正確的路由是使用公用位址、私人位址、分離式 DNS、反向代理、容器網路還是 NAT 回環。
• 僅以文字描述無法確定： Nextcloud 是否需要固定的公用 IP 位址，或該警告是否與 SMTP 有關。在變更網路或郵件設定之前，請先查看頁面和完整資訊。

大多數情況下，如果與管理概覽中的連接性檢查結果相符，則修正規範 URL 並使其可從 Nextcloud 運行時存取即可解決根本問題。代理程式和防火牆的變更應僅限於您的安裝實際使用的路徑。