投稿者: manualmaton Page 1 of 276

Nextcloud32.0.2にアップデート後に表示された際に出てきた

Client Push
Client Push is not installed, this might lead to performance issue when using desktop clients.

と出てきたので、これを導入しました。筆者のようにIP/クローラー制限やMod_Securityを利用している方でもなんとかなる手順にしています。

Client Push (notify_push) とは？

正式名称は「High Performance Back-end / notify_push」。
一言でいうと、「ファイルの変更をクライアントに『瞬時に』知らせる機能」です。

導入前と導入後の違い

郵便受けの確認に例えるとわかりやすいでしょう。

• Client Pushなし（ポーリング方式）
  • クライアントが、30秒おきに「ねえ、何か新しいファイルある？」「変更ない？」とサーバーへ聞きに行きます。
  • デメリット: サーバーはずっと質問攻めにされます。また、変更があってから聞きに行くまでにタイムラグ（遅延）が発生します。
• Client Pushあり（プッシュ方式）
  • クライアント～サーバーが専用のホットライン（WebSocket）で繋がりっぱなしになります。
  • サーバー上のファイルが変更された瞬間、サーバーから「変更あったよ！」と通知（プッシュ）します。
  • メリット: 変更が即座に反映されます。無駄な問い合わせがなくなるため、サーバーの負荷も下がります。

Client Pushは導入すべきか？

「必須ではありませんが、導入すると劇的に快適になります」

• 個人利用:
  • PCで保存した写真がスマホに「パッ」と出るようになるので非常に快適です。
• 複数人/組織利用:
  • 強く推奨します。多数のユーザーによる「変更ある？」というアクセス集中を防げるため、サーバー安定化に寄与します。

環境

• Nextcloud 32.0.2
• Ubuntu 24.04
• Apache 2.4
• MySQL 8.0
• PHP 8.3 (PHP-FPM 8.3)

(再掲)フェイズゼロ：政治交渉

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

• Nextcloudの高速化に寄与するnotify_pushをサーバに入れる。
• Apacheの設定変更を行う
• ついてはこの計画でサーバ設定を行う
• そのため、追加で作業時間をいただきたい
• 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置（担当者/担当部門が強権を振るえるか否か）でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は

• 個人運用だからそもそも関係ない
• フェイズゼロをクリアした

方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。

さっくりとした手順

1. 【Nextcloud Web画面】Client Pushをインストールします。
2. 【コマンドライン】Nextcloudのメンテナンスモードを有効化します。
3. 【コマンドライン】Apacheの設定ファイルを編集します。
4. 【コマンドライン】Apacheの設定ファイルを反映させます。
5. 【コマンドライン】Nextcloudのメンテナンスモードを無効化します。
6. 【コマンドライン】notify_pushをサービス化します。
7. 【コマンドライン】Nextcloudのconfigで、Trusted Proxyを有効化します。
8. 【コマンドライン】Nextcloudのpushサービスを有効化します。
9. 【Nextcloudクライアント】レスポンスの向上を確認します。

ClientPushのインストール

Nextcloudの管理者画面 ＞「アプリ」＞ 虫眼鏡アイコンで 「Client Push」を検索 ＞ インストール・有効化します。

ここまでは単純です。

メンテナンスモードを有効化

• Nextcloudのルートディレクトリ移動

cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

• メンテナンスモード有効化

sudo -u www-data php occ maintenance:mode --on

• メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

Apache設定

Client Pushは「WebSocket」という特殊な通信を使用します。Apacheでこれを扱えるようにモジュールを有効化します。

sudo a2enmod proxy proxy_http proxy_wstunnel

念のため：apacheリスタート

• apache再開前確認

systemctl status apache2.service

active(running)を確認します

• apache再開

sudo systemctl restart apache2.service

• apache再開確認

systemctl status apache2.service

active(runnning)を確認します

このタイミングでサービス再起動が必要なのは何故かというと、

• proxy
• proxy_http
• proxy_wstunnel

を有効化していないと、この後のApache設定変更時に「これらのモジュールが無い」とサーバは判断するからです。

Nextcloudのバーチャルサイトの編集

• バーチャルファイルのバックアップ

sudo cp -pi /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)

.confやバックアップディレクトリは自分の環境に合わせます。

• バーチャルファイルのバックアップ確認

diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

差分が無いことでバックアップを確認します。

※余談：執拗なまでのバックアップ

「責任範囲を明確にするため」です。

設定ファイルというものは、どこかのミスであっという間に破綻する「すぐそこにある破滅」です。「起きてしまった破滅」からすぐリカバリーできるため、「何かあったときの責任者は誰か（芋を引くのはどいつか？）」を決める絶好の証拠になります。

○自分の設定でミスが起きた：潔く諦め、原状回復に努めましょう。
○誰かの設定ミス：追求や晒し上げは後にして、原状回復に努めましょう。責任者は誰かと追求してもサーバは止まり続けます。

ここで重要なのは、サービスが止まった「この時点で」重要なのは、「誰がやったか」ではなく「いかに早く復旧させるか」です。

• ファイル編集

/etc/apache2/sites-available/nextcloud.conf を、任意の方法で編集します。(エディタという宗教問題が絡むため)

他のリダイレクト設定やセキュリティ設定（RewriteRuleなど）に干渉されないよう、<VirtualHost *:443> ブロック内のなるべく上の方に記述するのがコツです。

<VirtualHost *:443>
    # (その他既存の設定...)

    # ====================================================
    # Nextcloud Client Push (notify_push) 設定
    # ====================================================
    <Location /push>
        ProxyPass ws://127.0.0.1:7867/ws
        ProxyPassReverse ws://127.0.0.1:7867/ws
    </Location>

    ProxyPass /push/ http://127.0.0.1:7867/
    ProxyPassReverse /push/ http://127.0.0.1:7867/
    # ====================================================

    # ... (これ以降にDocumentRootやセキュリティ設定が続く) ...

• 編集後の差分確認

diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

以下の差分を確認します。

+# ====================================================
+# Nextcloud Client Push (notify_push) 設定
+# ====================================================
+    <Location /push>
+        ProxyPass ws://127.0.0.1:7867/ws
+        ProxyPassReverse ws://127.0.0.1:7867/ws
+    </Location>
+    
+    ProxyPass /push/ http://127.0.0.1:7867/
+    ProxyPassReverse /push/ http://127.0.0.1:7867/
+# ====================================================
+

設定反映

• 整合性確認

sudo apache2ctl configtest

Syntax OKを確認します。

• apache再開前確認

systemctl status apache2.service

active(running)を確認します

• apache再開

sudo systemctl restart apache2.service

• apache再開確認

systemctl status apache2.service

active(runnning)を確認します

Notifyデーモン(サービス)を作成します。

Client Pushは、Webサーバーとは別に裏方で動くプログラムです。これを常駐させるための設定ファイルを作成します。

• ファイル作成

｀/etc/systemd/system/notify_push.service`

を、任意の方法で作成します。

※ User や WorkingDirectory、ExecStart のパスは、ご自身のNextcloudインストール環境（例: /var/www/nextcloudなど）に合わせて必ず修正してください。

[Unit]
Description = Nextcloud Client Push Node binary
After = network.target

[Service]
Type = simple
User = www-data
Group = www-data
# 【重要】環境に合わせて変更してください。特に、ExecStartは2カ所、修正箇所があります。
WorkingDirectory = /var/www/nextcloud
ExecStart = /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php
Restart = on-failure

[Install]
WantedBy = multi-user.target

• サービス有効化

sudo systemctl daemon-reload

• サービス起動

sudo systemctl enable --now notify_push

• サービス起動確認

systemctl status notify_push.service 

active(running)を確認します

Trusted Proxiesの設定（どハマりした部分）

ここがつまずきポイントでした。

サーバーが自分自身のURL（https://your.domain.com）にアクセスした際、ネットワーク環境（ヘアピンNATなど）によっては一度外に出てグローバルIP経由で戻ってくる場合があります。

この場合、Nextcloudは「外部からのアクセス」とみなして通信を拒否してしまいます。これを防ぐため、config.php に自身のグローバルIPを信頼済みプロキシとして登録します。

• configファイルのバックアップ

sudo cp -pi /path/to/nextcloud/root/config/config.php /path/to/backup/directory/config.php.$(date +%Y%m%d)

格納場所は自分の環境に合わせます。

• 差分確認(※sudo付き)

sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

差分が無いことを確認します。

ここでsudoをつけるのは、NextcloudのファイルパーミッションがNextcloudの実行ユーザとrootしか読み取れないため(640)のためです。

Nextcloudの config/config.php を開き、trusted_proxies 配列に追記します。

  'trusted_proxies' => 
  array (
    0 => '127.0.0.1',
    1 => '::1',
    2 => '203.0.113.123',  // ← 【ここに追加】あなたのサーバーのグローバルIP
  ),

• 差分確認(※sudo付き)

sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

以下を確認します。

+    2 => '203.0.113.123',

設定の手動登録

通常は occ notify_push:setup コマンドを使いますが、Bot検知やIP制限などのセキュリティ設定が厳しい環境では、接続テストで「403 Forbidden」や「404 Not Found」が出て失敗することがあります。

そのため、テストをスキップして強制的に設定値を登録するコマンドを使います。

sudo -u www-data php /var/www/nextcloud/occ config:app:set notify_push base_endpoint --value "https://your.domain.com/push"

URLはご自身のものに合わせてください。また、パス（/var/www/nextcloud）は環境に合わせて変更してください。

• notify_pushサービス再起動

sudo systemctl restart notify_push

• サービス起動確認

systemctl status notify_push.service 

active(running)を確認します。

確認

Nextcloudの管理画面（「概要」または「ログ」）を確認し、「Client Push」に関する警告が消えていれば導入成功です。

これでファイル同期が爆速になり、サーバー負荷も低減されているはずです。警告を消したいだけの場合でも、この手順を行っておけば「高セキュリティかつ高性能」な環境が手に入ります。