Nextcloudの「サーバーに送信先アドレスがありません」という警告を修正する方法

Nextcloud の管理設定 → 概要でこの警告が表示される場合は、まず Nextcloud サーバーが自身の正規 URL を解決してアクセスできるかどうかを確認してください。ユーザーが実際に使用する URL を設定しoverwrite.cli.url、Nextcloud が実行されているホストまたはコンテナからその URL をテストしてください。サーバーに固定のパブリック IP アドレスを割り当てることから始めないでください。

「サーバーに送信先アドレスがありません」という正確な文言は、現在のNextcloud管理マニュアルには記載されていません。これは言い換え、翻訳、または別の警告である可能性があります。以下のトラブルシューティング手順は、管理概要に記載されている自己接続チェックに該当します。メール設定中にこのメッセージが表示された場合は、代わりに以下のSMTPセクションを参照してください。

Nextcloudがチェックする内容と、それが意味しないこと

Nextcloud 28 以降、管理設定 → 概要に表示されるセットアップ チェックは、ブラウザからではなくサーバーから実行されます。Nextcloud のアップグレード ノートによると、これらのチェックでは、DNS 解決、サーバーから自身への到達可能性、ファイアウォール、コンテナ ネットワークの問題が明らかになることがありますtrusted_domains。overwrite.cli.urlつまり、サーバー自身のネットワーク パスが重要になります。ラップトップのブラウザで動作する URL が、Nextcloud ホストまたはコンテナからアクセスすると失敗する可能性があります。Nextcloudの Nextcloud 28 セットアップ チェック ノートでは、この変更と確認すべき領域について説明しています。

これは、インターネットトラフィックをサーバーに誘導するDNSレコードを公開することとは異なります。プライベートインストールでは、管理者やユーザーがアクセスする方法として、内部ホスト名またはアドレスを使用できます。外部アクセス、フェデレーション、パブリック共有リンク、証明書の発行には、それぞれ別の要件が課される場合があります。まず、警告が表示された場所と、使用しているNextcloudのバージョンおよびインストール方法を正確にメモしてください。

1. 編集する前に、現在のURLとプロキシ設定を確認してください。

Nextcloud はメインの設定を に保存しますconfig/config.phpが、実行に使用するパスとコマンドはoccNextcloud のインストール方法によって異なります。ソースからインストールした場合は、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は、cron やコマンドライン ジョブなど、通常の Web リクエスト以外で Nextcloud が URL を生成する際に使用される正規ベース URL です。スキームと、該当する場合はインストール サブディレクトリを含める必要があります。これらの URL およびプロキシ パラメータについては、最新のNextcloud 設定リファレンスを参照してください。

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

を実際のホスト名に置き換えてくださいcloud.example.com。Nextcloud が などのサブディレクトリにインストールされている場合は/nextcloud、 の前にそのパスを追加してください/status.php。getentは、サーバーがルーティングできるアドレスを返すはずです。curlコマンドは TLS 検証を完了し、Nextcloud のステータス エンドポイントから通常の HTTP 応答を受信するはずです。 DNS の失敗、タイムアウト、接続拒否、証明書エラー、または予期しないリダイレクトが発生した場合は、問題が名前解決、ルーティング/ファイアウォール、リバース プロキシ、または TLS に絞り込まれます。 を-k証明書チェックをバイパスするために追加しないでください。これは問題を解決するのではなく、問題を隠蔽することになります。

DNSがIPv4とIPv6の両方を返す場合は、両方が意図されたものであり、Nextcloud環境から到達可能であることを確認してください。古いAAAAレコードがあると、一部のクライアントまたはサーバー側のチェックで使用できないIPv6ルートが選択される可能性があります。DNSレコードを削除または修正する場合は、そのアドレスがもはやサービスされていないことを確認してからにしてください。ドメインがパブリックIPに解決されるにもかかわらず、サーバーがルーター経由で接続できない場合は、NATループバック（ヘアピンNATとも呼ばれます）を確認するか、ホスト名がネットワーク内部から内部アドレスに解決されるようにスプリットホライズンDNSを設定してください。

3. 正規URLをユーザーが実際に使用するアドレスに設定する

ソースインストールの場合、overwrite.cli.urlHTTPSとサブディレクトリ（存在する場合）を含めた、外部または内部で使用されるベースURLを設定します。例：

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

ユーザーが Nextcloud にアクセスする場合https://example.com/nextcloud、/nextcloud値に を含めてください。ここに SMTP ホスト名を入力したり、 のようなページ パスを含めたりしないでください/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を終端してNextcloudにHTTPを送信する場合、アプリケーションはユーザー向けの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 によって受信アクセスがブロックされている場合は、Nextcloud の信頼済みドメイン リストを変更するよりも、VPN またはサポートされているリバース プロキシ/トンネル構成の方が適している場合があります。

メッセージがメール設定ページから送信された場合

メールは独立した機能です。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ランタイムからアクセス可能にすることで、根本的な不一致が解消されます。プロキシとファイアウォールの変更は、実際にインストールされているパスに限定してください。