インストールガイド

自社サーバーへ Connection を設置し、運用を始めるまでの手順です。

設置後の運用（更新・バックアップ・復元・トラブルシュート）は同梱の 運用ガイド、利用者向けの使い方は ユーザーガイド を参照してください。

想定作業時間: 30〜60 分（サーバーと DB の準備が済んでいる場合）
必要な権限: サーバーへの SSH ログイン、Web サーバーと cron の設定変更

うまくいかないときは §11 トラブルシュートへ。 症状別の対処をまとめてあります。

この文書の構成

	節	内容
§1	動作要件	PHP・DB・拡張・cron など、始める前の確認
§2	事前に用意するもの	データベース・設置先・SMTP・TLS 証明書
§3	展開と初期設定	zip の展開から `.env`・鍵・DB・権限まで
§4	Web サーバーの設定	Nginx / Apache / php.ini
§5	TLS / リバースプロキシ	https 化と `TRUSTED_PROXIES`
§6	cron とキューワーカー	この2つは必須です
§7	設定できているかを確認する	自己診断（16項目）で設定漏れを洗い出す
§8	初期セットアップ	ブラウザで管理者アカウントを作る
§9	メールが届くことを確認する	運用開始前に必ず実施
§10	運用開始前の最終確認	チェックリスト
§11	トラブルシュート	症状別の対処

1. 動作要件

必須

項目	要件
PHP	8.3 以上（CLI と Web で同じバージョン）
PHP 拡張	`curl` `gd` `sodium` `zip` `pdo_mysql` `mbstring` `openssl` `pdo` `tokenizer` `xml` `ctype` `fileinfo` `json`
データベース	MySQL 8.0 以上（MariaDB も動作します）
Web サーバー	Nginx / Apache など + PHP-FPM
cron	`php artisan schedule:run` を毎分実行できること
常駐プロセス	キューワーカーを常駐させられること（supervisor / systemd など）
PHP 関数	`proc_open` / `exec` が無効化されていないこと（管理画面からの更新に必要）

vendor/ とビルド済みのフロントエンド資産は配布物に同梱済みです。導入先に Composer と Node.js は要りません。

推奨

mysqldump が PATH にあること。 自動バックアップが MySQL のダンプに使います。無いと、アプリは正常に動いたままバックアップだけが毎晩静かに失敗します。
pcntl 拡張。キューワーカーの安全な停止とタイムアウト制御に使われます（無くても動作します）。
ディスクの空き。更新の適用時に、配布物のおよそ 3 倍の一時領域を使います。

対応していないもの

Laravel Octane には対応していません。 通常の PHP-FPM 構成で運用してください。
複数サーバーでの負荷分散構成は想定していません（アップロード実体と storage/ をサーバー上に置く前提です）。
SQLite でも起動はしますが、運用には向きません（同時アクセスに弱く、バックアップに sqlite3 コマンドが別途必要になります）。検証用途に留めてください。

2. 事前に用意するもの

データベースと接続用ユーザー。 文字セットは utf8mb4 にしてください。

CREATE DATABASE connection CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'connection'@'localhost' IDENTIFIED BY '安全なパスワード';
GRANT ALL PRIVILEGES ON connection.* TO 'connection'@'localhost';
FLUSH PRIVILEGES;

設置先のディレクトリ。 Web の公開ディレクトリの外に置いてください（公開するのはこの中の public/ だけです）。例: /var/www/connection
メール送信の手段（SMTP サーバーの情報）。招待・通知・パスワード再設定はすべてメールに依存します。
独自ドメインと TLS 証明書。 https で運用してください。

3. 展開と初期設定

以下は設置先を /var/www/connection、Web サーバーの実行ユーザーを www-data とした例です。

3-1. 配布物を展開する

cd /var/www
unzip connection-1.0.0.zip          # connection-1.0.0/ が展開されます
mv connection-1.0.0 connection
cd connection

3-2. 設定ファイルを作る

cp .env.example .env

.env をエディタで開き、最低限つぎの項目を設定します。各行の意味はファイル内のコメントに書いてあります。

APP_URL=https://connection.example.com   # 実際にブラウザで開く URL（スキーム込み・末尾スラッシュなし）
APP_TIMEZONE=Asia/Tokyo                  # 導入先の地域

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=connection
DB_USERNAME=connection
DB_PASSWORD="用意したパスワード"

MAIL_MAILER=smtp                         # log のままだとメールは送信されません
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_USERNAME=...
MAIL_PASSWORD="..."
MAIL_FROM_ADDRESS="connection@example.com"

SESSION_SECURE_COOKIE=true               # https で運用する場合（コメントを外す）

パスワードは二重引用符で囲んでください。 記号を含む強いパスワードを推奨していますが、 # から後ろはコメント扱いになり、空白があるとそこで値が切れます。囲んでおけばどちらも起こりません。

APP_TIMEZONE は必ず導入先の地域に合わせてください。 定期処理の実行時刻だけでなく、期限リマインダーが「当日」と判断する日付の境目もこの値で決まります。UTC のままだと、日本では朝8時のリマインダーが夕方に届き、当日ぶんの通知が前日の夜に飛びます。

APP_ENV=production と APP_DEBUG=false はそのままにしてください。APP_DEBUG=true のまま公開すると、エラー画面でデータベースの認証情報や APP_KEY が訪問者に見えます。

3-3. 暗号化キーを生成する

php artisan key:generate

★この時点で .env を控えてください
Section titled “★この時点で .env を控えてください”

.env はバックアップに含まれません。 とくに APP_KEY を失うと、バックアップからデータベースを復元しても、暗号化された列（利用者の2要素認証の秘密鍵など）を復号できません。 .env をパスワードマネージャなど、サーバーとは別の安全な場所へ1部保管してください。

3-4. データベースを初期化する

php artisan migrate --force

--force は本番環境で対話確認を省くために必要です。--seed は付けないでください（デモデータは開発環境専用です）。

3-5. アップロード画像の公開リンクを作る

php artisan storage:link

ロゴ・ファビコン・アバターの配信に使います。これを忘れると、設定した画像が表示されません。

3-6. キャッシュを生成する

php artisan optimize

設定・ルート・イベントのキャッシュをまとめて作ります。.env や config/ を変更したら、そのつど実行し直してください。

このあと（手順 6-2）キューワーカーを常駐させると、ワーカーは起動時の設定を持ち続けます。 .env を変更したときは php artisan optimize に加えて、ワーカーの再起動も必要です（手順 3-7 より後は sudo -u www-data php artisan optimize として実行します）。

3-7. 権限を設定する

Web サーバーの実行ユーザーが storage/ と bootstrap/cache/ へ書き込めるようにします。

sudo chown -R www-data:www-data /var/www/connection
sudo chmod -R 775 /var/www/connection/storage /var/www/connection/bootstrap/cache
sudo chmod 600 /var/www/connection/.env

配布 zip はファイルとディレクトリの権限を正規化した状態で作られているため、展開したツリー全体に chmod をかけ直す必要はありません（一律に 644 を当てると、vendor/bin/ の実行可能スクリプトから実行権限が落ちます）。所有者の変更と、上の2つだけで足ります。

.env を 600 にするのは、同じサーバーの他の利用者から読めないようにするためです（データベースの認証情報と APP_KEY が入っています）。

★これ以降の php artisan は Web サーバーと同じユーザーで実行してください
Section titled “★これ以降の php artisan は Web サーバーと同じユーザーで実行してください”
Terminal window
sudo -u www-data php artisan connection:doctor      # 例
ここで所有者を www-data に揃えたため、素の php artisan は storage/ へ書き込めず、自己診断（手順 7）が「storage の書き込み権限」で [問題] を出します。かといって sudo で root として実行すると、今度は作られたキャッシュ（bootstrap/cache/*.php）とログが root 所有になり、以後 Web サーバーから書き換えられなくなります（更新の「キャッシュの作り直し」がそこで失敗します）。

作業ユーザーを www-data グループに入れて運用する方法もありますが、その場合も新しく作られるファイルの所有者は作業ユーザーになります。sudo -u www-data を付けるのがいちばん確実です。cron とキューワーカー（手順 6）も同じユーザーで動かしてください。

管理画面から更新を適用する予定がある場合は、/var/www/connection の全体が Web サーバーの実行ユーザーで書き換えられる必要があります（更新はファイルを置き換えます）。上の chown -R がそれを満たしています。

4. Web サーバーの設定

公開するのは public/ だけです。 ドキュメントルートを /var/www/connection/public に向けてください。1つ上の階層を公開すると、.env が URL 一本で読めてしまいます。

以下の設定例は、代表的な構成をもとにしたものです。 PHP-FPM のソケット名・証明書の置き場所・モジュールの有効化方法は、ディストリビューションやバージョンによって異なります。ご利用の環境に合わせて読み替えてください。適用したあとは、手順 7 の自己診断と、実際に https でアクセスできることで確認できます。

Nginx の例

server {
    listen 443 ssl;
    http2 on;                    # nginx 1.25.1 未満では `listen 443 ssl http2;` と書きます
    server_name connection.example.com;

    root /var/www/connection/public;
    index index.php;

    ssl_certificate     /etc/letsencrypt/live/connection.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/connection.example.com/privkey.pem;

    # ファイル共有の上限（20MB）より大きく取る。小さいとアップロードが 413 で失敗する。
    client_max_body_size 32M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        # 実在するファイルにだけ PHP を渡す。これが無いと、存在しないパスの .php まで
        # FPM へ転送され、想定外のファイルが実行される経路が残る。
        try_files $uri =404;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

server {
    listen 80;
    server_name connection.example.com;
    return 301 https://$host$request_uri;
}

Apache の例

public/ に同梱の .htaccess がそのまま使えます。mod_rewrite mod_ssl を有効にし、 AllowOverride All を設定してください。

<VirtualHost *:443>
    ServerName connection.example.com
    DocumentRoot /var/www/connection/public

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/connection.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/connection.example.com/privkey.pem

    <Directory /var/www/connection/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

# http でのアクセスを https へ回す（この vhost が無いと、素の http でつながったままになります）
<VirtualHost *:80>
    ServerName connection.example.com
    Redirect permanent / https://connection.example.com/
</VirtualHost>

Let’s Encrypt を certbot --apache / certbot --nginx で導入している場合、証明書の指定と http からの転送は certbot が自動で書き込みます。その場合は上の該当行を重複させないでください。

php.ini

ファイル共有の上限は 20MB です。サーバー側の上限がこれより低いと、利用者にはアップロード失敗として現れます（PHP の初期値は 2MB なので、たいていの環境で調整が必要です）。

編集する php.ini の場所は次で確認できます。

php --ini      # "Loaded Configuration File" の行が本体

upload_max_filesize = 32M
post_max_size = 32M

設定後は PHP-FPM を再起動してください。

php --ini が示すのは CLI の php.ini です。 多くのディストリビューションでは CLI と PHP-FPM で別の php.ini を使います（/etc/php/8.3/cli/php.ini と /etc/php/8.3/fpm/php.ini など）。アップロードに実際に効くのは FPM 側なので、両方を揃えてください。

Web 側で本当に効いている値は、設置後に**管理画面の「システム状態」**に表示されます（コマンドの connection:doctor は CLI 側の値を見ます）。この2つが食い違っている場合は、画面の表示のほうが正解です。

5. TLS / リバースプロキシ

TLS を Web サーバーで直接終端している場合

APP_URL を https:// で始め、.env の SESSION_SECURE_COOKIE=true を有効にすれば完了です。

TLS をリバースプロキシ / ロードバランサで終端している場合

アプリは平文で受け取るため、そのままでは接続元が常にプロキシの IP になります。 ログイン・パスワード再確認・招待・検索の回数制限はすべて接続元 IP で束ねているので、利用者全員が1つの枠を共有することになり、誰か1人の試行で全員が締め出されます。

.env に、信頼するプロキシを指定してください。

TRUSTED_PROXIES=10.0.0.1              # 単一のプロキシ
# TRUSTED_PROXIES=127.0.0.1,::1       # 同じサーバー上のプロキシ
# TRUSTED_PROXIES=192.168.0.0/16      # 範囲指定（カンマ区切りで併記できます）

プロキシは X-Forwarded-For と X-Forwarded-Proto を転送するよう設定してください。

転送ヘッダは、プロキシ側で必ず「書き直す」設定にしてください。 信頼したプロキシからは X-Forwarded-Host や X-Forwarded-Port も同時に信用されるため、クライアントが送ってきた値をプロキシがそのまま素通しすると、それも信じることになります。nginx なら proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; のように、プロキシ自身が値を決めます。（Host そのものは APP_URL のホストとの完全一致に固定されているため、当アプリでは細工したホストは 400 になります。上は多層防御としての推奨です。）

TRUSTED_PROXIES=* は最後の手段です。 転送ヘッダは誰でも詐称できるため、アプリのポートへ外部から直接届く構成で * にすると、利用者が自分の IP を自由に名乗れます（回数制限の回避になります）。CDN などでプロキシの IP を列挙できない場合に限って使い、同時にアプリのポートへはプロキシからしか接続できないようにしてください。

設定を変えたら sudo -u www-data php artisan optimize を実行し直します。

6. cron とキューワーカー

この2つは必須です。止まると、通知メール・期限リマインダー・自動バックアップが エラーも出さずに静かに止まります。

6-1. cron（スケジューラ）

インストール先のユーザー（Web サーバーと同じユーザーを推奨）の crontab に1行追加します。

* * * * * cd /var/www/connection && php artisan schedule:run >> /dev/null 2>&1

これ1行で、次がすべて動きます。

時刻	内容
毎分	稼働の記録（自己診断が「cron が止まった」ことを検出するために使います）
01:00	古いバックアップの整理
01:30	自動バックアップ
03:00	新しいバージョンの確認
04:00	バックアップ保存先の点検
08:00	期限が近い課題のリマインダー送信

時刻はすべて APP_TIMEZONE に従います。

6-2. キューワーカー

通知メールはキュー経由で送られます。ワーカーが常駐していないと、メールは1通も届かず、キューに溜まったままになります。

以下の設定例も、代表的な構成をもとにしたものです。 PHP の実行ファイルの場所（/usr/bin/php）・設定ファイルの置き場所・サービスの管理方法は環境によって異なります。常駐できたかどうかは、**手順 7 の自己診断の「キューワーカー」**で確認できます（記録が現れるまで数分かかります）。

supervisor の例（/etc/supervisor/conf.d/connection-worker.conf）:

[program:connection-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/connection/artisan queue:work --sleep=3 --tries=3 --max-time=3600
directory=/var/www/connection
autostart=true
autorestart=true
stopwaitsecs=3600
user=www-data
numprocs=1
redirect_stderr=true
stdout_logfile=/var/www/connection/storage/logs/worker.log

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start connection-worker:*

systemd の例（/etc/systemd/system/connection-worker.service）:

[Unit]
Description=Connection queue worker
After=network.target

[Service]
User=www-data
Group=www-data
Restart=always
RestartSec=5
WorkingDirectory=/var/www/connection
ExecStart=/usr/bin/php /var/www/connection/artisan queue:work --sleep=3 --tries=3 --max-time=3600

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now connection-worker

必ず監視プロセス（supervisor / systemd）の下で動かしてください。 アプリは更新のたびにワーカーへ「次の仕事の前に終了して」と合図します。立ち上げ直すのは監視プロセスの役目で、監視が無いとワーカーは止まったまま戻りません。

ワーカーの表示言語は cron / systemd の環境ではなく .env の APP_LOCALE に従います（メールは受信者ごとの言語で組み立てられます）。

7. 設定できているかを確認する

自己診断を実行してください。ここまでの設定漏れは、ほぼすべてここに出ます。

sudo -u www-data php artisan connection:doctor

全 16 項目が [正常] [警告] [問題] のいずれかで並び、最後に件数の要約が出ます。 [問題] があると終了コードが 1 になります（[警告] は 0 のままです）。

ここまでの手順を終えた直後は、次のようになります。

[正常] アプリのタイムゾーン — タイムゾーン: Asia/Tokyo
[正常] キャッシュストア — キャッシュストア: database
[正常] アプリの URL — APP_URL: https://connection.example.com
[正常] セッションクッキー — セッションクッキーに secure が付いています。
[正常] 信頼するプロキシ — 信頼するプロキシは指定されていません（転送ヘッダは読みません）。
[正常] セッションドライバ — セッションドライバ: database
[正常] アプリの言語 — 言語: ja
[正常] MySQL の sql_mode — NO_BACKSLASH_ESCAPES は設定されていません。
[正常] アップロードサイズの上限 — サーバー上限 32 MB（アプリ上限 20 MB）。
[正常] PHP 拡張 — 必要な PHP 拡張はすべて読み込まれています。
[正常] storage の書き込み権限 — storage とキャッシュのディレクトリは書き込み可能です。
[正常] 更新の準備状況 — 配信元が設定されていません。このインスタンスは更新の確認も適用も行いません。
[正常] バックアップ保存先の安全性 — バックアップディスク: backups
[警告] スケジューラ（cron） — スケジューラのハートビートがまだ記録されていません。
 cron が「php artisan schedule:run」を毎分実行するようにし、数分後に再確認してください。
[警告] キューワーカー — スケジューラが稼働していないため、キューワーカーの状態を判断できません。
 先にスケジューラ（cron）を直してから、キューワーカーを再確認してください。
[警告] 最新のバックアップ — バックアップはまだ作成されていません。
 夜間バックアップが走るよう cron を稼働させるか、「php artisan backup:run」を一度実行してください。

検査 — 正常: 13・警告: 3・問題: 0

最後の3つの [警告] は、この時点では正常です。 どれも「動いた痕跡がまだ無い」ことを言っており、cron を登録した直後は記録が現れるまで数分かかります。翌朝に最初のバックアップができれば、3つとも [正常] に変わります。

[問題] が1件でもあれば、公開する前に解消してください。 各行の下に是正のヒントが表示されます。よくある指摘は次のとおりです。

表示	対処
タイムゾーンが UTC	`.env` の `APP_TIMEZONE` を設定して `sudo -u www-data php artisan optimize`
APP_URL が http	https にする（手順 5）
セッションクッキーに secure が付いていない	`.env` の `SESSION_SECURE_COOKIE=true`
storage に書き込めない	手順 3-7 の権限設定。`sudo -u www-data` を付けて実行しているかも確認（素の `php artisan` だと自分のアカウントの権限で判定されます）
拡張が足りない	不足している拡張を PHP に追加して PHP-FPM を再起動
アップロードサイズの上限がアプリ上限より低い	php.ini の `upload_max_filesize` / `post_max_size`（手順 4）
`proc_open` / `exec` が無効	php.ini の `disable_functions` から外す（共用ホスティングでは提供元へ確認）
信頼するプロキシが `*`	プロキシの IP / CIDR を列挙する（手順 5）
スケジューラの稼働記録がない	cron の設定（手順 6-1）。登録直後は数分待ってから再実行
キューワーカーの稼働記録がない	ワーカーの常駐（手順 6-2）。こちらも記録には数分かかります

同じ内容は、設置後に管理画面の 「システム状態」 からも確認できます。

--json を付けると機械可読な形式で出力されます（監視やサポートへの連携に使えます）。

sudo -u www-data php artisan connection:doctor --json

8. 初期セットアップ（ブラウザ）

APP_URL をブラウザで開くと、セットアップウィザードが表示されます。

管理者アカウント — 表示名・メールアドレス・パスワードを入力します。ここで作るのがインスタンス管理者（admin）です。
ライセンスキー（任意） — 購入時に発行されたキーを入力します。後から管理画面でも設定できます。ウィザードではキーの形式だけを確認して保存するため、状態は「未確認」から始まります。セットアップ後に管理画面（インスタンス設定 → ライセンス）で「ライセンスを再確認」を1度押してください。 更新を受け取れる期限がそこで確定します（更新の適用にはこの確認が必要です。アプリの機能はどちらでも変わりません）。
ブランディング（任意） — サービス名・ロゴ・テーマカラーを設定します。

最後の画面で「完了」を押すと、管理者アカウントと設定がまとめて作成され、そのままログインした状態になります。途中で離脱した場合は何も保存されません（最初からやり直せます）。

セットアップが完了すると、ウィザードの URL は閉じられます（再実行による管理者の再作成はできません）。

ブラウザを使わずに管理者を作ることもできます。
Terminal window
sudo -u www-data php artisan connection:create-admin
ただし、この方法で管理者を作るとウィザードは二度と開きません（管理者が存在する時点でセットアップ済みと判定され、/setup は 404 になります。ウィザードを使いまわして管理者を追加作成されるのを防ぐためです）。ブラウザでアクセスするとログイン画面が出るので、サービス名・ロゴ・テーマカラーはログイン後に管理画面のインスタンス設定から設定してください。

ウィザードでまとめて設定したい場合は、このコマンドを使わず、この節の冒頭（ブラウザで APP_URL を開くところ）から進めてください。

9. メールが届くことを確認する

招待・通知・パスワード再設定はすべてメールに依存します。運用を始める前に、実際に届くことを確認してください。

管理者でログインします。
プロジェクトを1つ作り、自分以外のメールアドレスをメンバーとして招待します。
招待メールが届くことを確認します。

届かない場合、上から順に確認してください。

.env の MAIL_MAILER が log のままになっていないか。 これが既定値です。log の間、メールはどこにも送信されません。

log にしても、既定ではログにも何も残りません。 ログへの書き出しは debug レベルで行われる一方、.env の既定は LOG_LEVEL=info のためです。手元で本文を確認したい場合だけ、一時的に LOG_LEVEL=debug にしてください（確認が終わったら info に戻します。debug のままだと利用者の氏名や課題名がログに残り続けます）。
キューワーカーが動いているか（手順 6-2）。通知メールはキュー経由のため、ワーカーが止まっているとキューに溜まったままになります。 sudo -u www-data php artisan connection:doctor の「キューワーカー」で最後に処理した時刻が分かります。
.env を変更したあと、キューワーカーを再起動したか。 ワーカーは起動時に読み込んだ設定を持ち続けます。メールの設定を直しても、ワーカーを再起動するまで古い設定のまま送り続けます（実際にこれで見落としやすい状態になります）。
Terminal window
```
sudo -u www-data php artisan optimize                          # 設定キャッシュを作り直す
sudo supervisorctl restart connection-worker:*   # ワーカーを入れ替える
```
storage/logs/laravel-*.log に SMTP のエラーが出ていないか確認します。
差出人アドレス（MAIL_FROM_ADDRESS）が、送信ドメインの SPF / DKIM を通せるアドレスになっているか確認します。

10. 運用開始前の最終確認

sudo -u www-data php artisan connection:doctor に [問題] が無い
https でアクセスでき、http は https へリダイレクトされる
管理者でログインでき、プロジェクトを作成できる
招待メールが実際に届く
.env（とくに APP_KEY）をサーバーの外に控えた
翌朝、storage/backups/connection/ にバックアップが1本できている（cron の動作確認。すぐ確かめたい場合は sudo -u www-data php artisan backup:run）
更新の配信設定を確認した（管理画面の「システム状態」→ バージョンと更新）

これ以降の運用は 運用ガイド を参照してください。

11. トラブルシュート

まず sudo -u www-data php artisan connection:doctor を実行してください。以下は、それでも分からない場合の症状別の対処です。

画面が真っ白になる / 500 エラーになる

その日のログの末尾を見ます。ログは日付ごとのファイル（laravel-2026-07-29.log）で、 laravel.log というファイルは作られません。

tail -n 50 "storage/logs/laravel-$(date +%F).log"

多いのは次の2つです。

storage/ または bootstrap/cache/ に書き込めない → 手順 3-7 の権限設定。
.env を変更したのにキャッシュを作り直していない → sudo -u www-data php artisan optimize。

原因の切り分けのために一時的に APP_DEBUG=true にする場合は、確認が終わったら必ず false に戻して sudo -u www-data php artisan optimize を実行してください（エラー画面に認証情報が出ます）。

「ページの有効期限が切れました」（419）が出る

セッションが失効しています。ブラウザを再読み込みしてやり直してください。繰り返す場合:

APP_URL が実際にアクセスしている URL と一致しているか確認します。
http でアクセスしているのに SESSION_SECURE_COOKIE=true になっていないか確認します（この組み合わせだとクッキーが送られず、ログインが完了しません）。自己診断が指摘します。

ログインしてもログイン画面に戻される

SESSION_SECURE_COOKIE と実際のスキームの不一致が最有力です（上と同じ）。 CACHE_STORE / SESSION_DRIVER が .env の推奨値になっているかも確認してください。

ロゴやアバターが表示されない

sudo -u www-data php artisan storage:link を実行し忘れています（手順 3-5）。

メールが届かない

手順 9 を参照してください。

アップロードが失敗する

20MB を超えていないか確認します（ファイル共有の上限。コメントの添付は 10MB）。
サーバー側の上限が足りているか確認します（手順 4 の php.ini、Nginx の client_max_body_size）。自己診断の「アップロードサイズの上限」が実効値を表示します。
対応する形式か確認します。jpg jpeg png gif webp pdf txt csv md doc docx xls xlsx ppt pptx zip のみで、拡張子を変えても中身で判定されます。

通知メールもリマインダーも来ない / バックアップができていない

cron が動いていません（手順 6-1）。自己診断の「スケジューラ」が最後の稼働時刻を表示します。

日本語の表示が英語になる

利用者ごとの言語はプロフィール設定で選べます。
インスタンス全体の既定は管理画面のインスタンス設定「既定の言語」です。
バージョンアップ前から居る利用者は、以前の設定が残っているため、プロフィールから選び直してもらう必要がある場合があります。

それでも解決しない場合

次の情報を添えてサポートへ連絡してください（.env そのものは送らないでください。認証情報が含まれます）。

sudo -u www-data php artisan connection:doctor --json > doctor.json
tail -n 200 storage/logs/laravel-*.log > app.log