トラブルシューティング — ドキュメント

セットアップの問題のほとんどは、DNS、クラウドファイアウォール、または送信ポート 25 のブロックに帰着します。各々の見分け方と直し方を示します。

パネルが自分のドメインで開かない

http://server-IP/ は動くがドメインは動かない — DNS がまだ解決していません。 panel.yourdomain.com を dnschecker.org（種別 A）で確認してください。空欄なら、DNS レコードかネームサーバーが設定されていません — ドメインを向けるを参照。
ドメインにネームサーバーがまったくない — レジストラの委任が公開されていないか、権威ではない DNS ホストにレコードを設定しています。dnschecker.org（種別 NS）で NS を確認し、空か誤っていれば、レジストラでネームサーバーを直すか、Cloudflare に移してください。
ネームサーバーはどこかを指しているが、まだ解決しない（「REFUSED」） — DNS ホストが実際にはゾーンを提供していません。そこで DNS 管理を有効化するか、ドメインを Cloudflare に移してください（追加されればゾーンを常に提供します）。

HTTPS が有効でない（鍵マークがない）

panel.yourdomain.com がサーバーを指すと、約 5 分以内に HTTPS が自動で有効になります。もしそうならないなら:

A レコードが 正しい IP に解決することを確認してください（dnschecker.org）。
クラウドファイアウォール でポート 80 と 443 が開いていることを確認してください。
Cloudflare を使う場合は、panel レコードを DNS only（グレーの雲）に設定し、プロキシにしないでください。
今すぐ強制するには: root で SSH して sudo nimbopanel-enable-https を実行してください。

顧客がメールを送信できない／送信メールがバウンスまたはタイムアウトする

何かを仮定する前に システム → 送信メール を開いてください。カードは、このサーバーがポート 25 でインターネットに到達できるかを測定し、はっきりと述べます。ポートがブロックされていると報告されたら、その同じカードのフォームからリレーを設定してください — メール到達性と送信を参照。動作するリレーはメールログに status=sent を示します。

カードがポート 25 は 開いている と述べるなら、ブロックはあなたの問題ではなく、原因は他にあります。受信者のバウンスメッセージを確認し、下記の SPF/DKIM/DMARC を確認してください。

メールは送信されるが、迷惑メールに入る

メッセージが完全には認証されていません。送信ドメインについて 3 つすべてが公開され、通過していることを確認してください。

SPF がリレーを含む（例: include:spf.brevo.com）。
DKIM — ドメインがリレーで検証され、その DKIM レコードが DNS にある。
DMARC — v=DMARC1; p=none; … のレコードが存在する（Nimbopanel がドメインごとに 1 つ追加します）。

受信メールが決して届かない

ドメインの MX レコード が mail.yourdomain.com を指し、mail.yourdomain.com がサーバーに解決することを確認してください。
クラウドファイアウォールで受信ポート 25 が開いていることを確認してください（受信 25 がブロックされることはほとんどありません — ブロックされるのは送信だけです）。

ツールページ（ウェブメール、phpMyAdmin）がエラーを表示する、または読み込まれない

phpMyAdmin がパネルセッションなしで 401 を返す — それは想定どおりです。パネルの内側から開いてください（シングルサインオン）。
どちらのタイルも顧客のパネルに現れない — それらは Debian/Ubuntu 専用です。AlmaLinux、 Rocky、RHEL では、パネルは顧客を存在しないページに送るのではなく、両方を隠します。これは設計であって、不具合ではありません。
ウェブメール／サイトが 502 を返す — PHP サービスが再起動したのかもしれません。 systemctl status でサービスを確認してください。しばらくしても続くなら、アップデーター（sudo nimbopanel update）を再実行して、管理された設定を再適用してください。

顧客サイトの問題

.htaccess のルールが何もしない。 サイトは変換モードにあります。ドメイン → Apache / .htaccess で 今すぐ変換 を押すか、完全 .htaccess サポートをオンにしてください。そのページの表が、どのディレクティブがスキップされているかを正確に挙げます。 .htaccess — 2 つのモードを参照。
完全 .htaccess サポートに切り替えた直後にすべてのページが 500 を返す。 Apache に、ファイルが必要とするモジュールが欠けています — mod_rewrite が通常のもので、Debian と Ubuntu では既定でオフです。インストーラー（sudo nimbopanel update）を再実行すると必要なモジュールが有効になります。その間はアカウントを戻してください。
完全 .htaccess モードのアカウントですべてのページが 502 を返すが、他のサイトは問題ない。 Apache が動いていません: systemctl status apache2（Debian/Ubuntu）または httpd （RHEL ファミリー）。
ドキュメントルート変更後、サイトが 404 になるか空のディレクトリを表示する。 フォルダは入力どおりそのまま公開され、存在しなければ作成されるので、打ち間違いはエラーではなく空のフォルダを生みます。ドメインの行の値を読んで訂正してください。 public_html 以外のフォルダから公開するを参照。
サイトの .env や設定ファイルがダウンロードできる。 ドキュメントルートがそれより上にあります。ドキュメントルートをアプリケーションの public フォルダに移してください。 curl -sI https://domain/.env は 403 を返すはずです。

すべてのサイトが一斉に落ちた

すべての サイトが同じ瞬間に止まったなら、たいていは php-fpm が動いていません。 systemctl status php*-fpm で確認してください。php-fpm プロセスが 1 つも生きていないのに Address already in use で起動を拒否する場合、突然死したプロセスが残した古いソケットファイルがあります — 現在の Nimbopanel リリースは起動前にそれらを自分でクリアします。

どこを見るか

パネルとサービスのログは systemd ジャーナルにあります: journalctl -u nimbopanel -n 50。
メール配信の結果: journalctl -t postfix/smtp --since -10min（status=sent / status=bounced を探します）。
インストールログは /var/log/nimbopanel-install.log にあります。

それでも詰まっていますか? 正確な症状と該当するログ行を控えてください — たいていそれで素早く特定できます。