記事ディレクトリ
昨日の午後、サーバー上でAdminerデータベース管理ツールを設定していました。Adminerは軽量で使いやすく、phpMyAdminのように多くの依存関係を必要とするのではなく、単一のPHPファイルで動作します。公式サイトから最新バージョンをダウンロードし、サーバーにアップロードして権限を設定し、ブラウザを開いて動作確認をしました。
そして、画面は真っ暗になった。
ページを3回更新したが、F5キーを何度も押したせいで指が痛くなった。それでも何も変化なし。ブラウザの開発者ツールを開いてみると、200 OKエラーが表示されたが、レスポンスボディは空だった。私は完全に呆然とした。一体何が起こっているのだろうか？
少し考えてみました。ファイル権限の問題でしょうか？確認したところ、755でした。PHPのバージョンの互換性の問題でしょうか？確認したところ、PHP 8.2で問題ありません。ファイル自体に問題があるのでしょうか？新しいコピーをダウンロードして上書きしてみましたが、やはり空白のままです。
なぜか分からないが、名前を変えてみようと思った。
adminer.php を adminer1.php に名前変更し、ページを更新しました。
アクセスに成功しました。
本当に困惑しました。同じファイル、同じコード、同じサーバーなのに、名前を変えるだけでアクセスできるなんて？一体どんな不思議な仕組みなんでしょうか？
adminer.php ファイルは空です。
後になって分かったのですが、これは迷信などではなく、PHPのキャッシュが問題の原因だったのです。
OPcache（Opcode Cacheの略）は、PHPのパフォーマンス最適化拡張機能です。その原理はシンプルです。PHPはインタプリタ型言語であり、各リクエストは実行前にPHPコードをオペコードにコンパイルする必要があります。OPcacheはコンパイル結果をメモリにキャッシュすることで、後続のリクエストが再コンパイルなしでキャッシュされたバージョンを直接使用できるようにし、パフォーマンスを大幅に向上させます。
しかし、そこに問題があるのです。
以前は、adminer.php に「ファイルが見つかりません」というエラーが表示されていました（間違ったファイルをアップロードしたため）。OPcache はその誤ったコンテンツのコンパイル結果をキャッシュしていました。その後、adminer.php を正しいコードに置き換えましたが、OPcache はそれを無視して古いキャッシュをメモリから読み込み続けたため、空白ページが表示されるか、以前のエラーメッセージが表示されました。
ファイル名をadminer1.phpに変更すると、OPcacheにとって全く新しいファイルパスとなり、正しく再読み込みされ、解決されます。
まるで新しい本を手に入れたのに、図書館の索引カードにはまだ古い本の請求記号が残っているようなものです。棚で探しても、もちろん空っぽです。しかし、本のタイトルを変更すれば、図書館は新しい索引カードを作成してくれるので、それを使って本を探すことができるのです。
理由1：OPcacheキャッシュが空白スペースを生成する
どのように対処しますか？
PHP-FPMサービスを再起動し、OPcacheキャッシュをクリアしてください。
# 查看正在运行的PHP版本
php -v
# 重启对应的PHP-FPM（例如PHP 8.5）
sudo systemctl restart php8.5-fpm
# 或者重启所有PHP-FPM服务
sudo systemctl restart php*-fpm再起動後、ファイル名をadminer.phpに戻し、ウェブページを更新してください（ブラウザを強制的に更新するにはCtrl+F5を押すことをお勧めします）。そうすれば問題は解決するはずです。
しかし、物語はまだ終わっていない。
PHP-FPMを再起動した後、adminer.phpファイルを元に戻し、ページを更新しましたが、やはり何も表示されませんでした。全く理解できませんでした。
理由2：Nginxの設定ルールの制限
これが2つ目の可能性のある理由につながる。
Nginxの設定ファイルには、adminer.phpへのアクセスを制限する特別なルールが含まれている場合があります。
以前、HestiaCPパネルでFail2Banを設定し、ブルートフォース攻撃を防ぐためにadminer.phpに対する完全一致ルールを作成しました。このルールではファイル名がadminer.phpとハードコーディングされていたため、ファイル名をadminer1.phpに変更すると、このNginxルールを回避して通常どおりアクセスできてしまいました。
トラブルシューティングの方法は簡単です。Nginxの設定ファイル内でハードコードされているエントリを探してください。
sudo grep -rn "adminer.php" /etc/nginx/`location = /adminer.php { … }` のようなルールを見つけた場合、Nginx はこの特定のファイル名を特別に処理していることを意味します。削除するか、変更してください。
理由3：PHPエラー表示設定
3つ目の理由は、より微妙なものです。
PHPスクリプトがインターセプトされるかエラーをスローしたが、ページがエラー表示を無効にしている（display_errors = Off）。本番環境では、PHPはデフォルトでエラーを非表示にし、空白ページを表示する。エントリファイル（例：index.php）が「./adminer.php」をインクルードしようとした際に何らかの理由でクラッシュした場合、ページは単に空白になる。
このような状況では、エラーログを確認するのが最も確実な方法です。
# 查看Nginx错误日志
sudo tail -n 20 /var/log/nginx/error.log
# 或者查看HestiaCP对应域名的error日志
sudo tail -n 20 /var/log/nginx/domains/adminer.domain.com.error.logログを見れば、画面が白くなる本当の理由がわかります。
正直に言うと、最終的に問題の原因はerror.logを確認することで判明しました。adminer.phpが実際には存在しないPHP拡張機能を呼び出しており、display_errorsが無効になっていたため、ページが空白になっていたのですが、エラーログにはそれがはっきりと記録されていました。
解決策とトラブルシューティングの手順
この出来事は私に深い印象を残しました。
技術的な問題は、表面上に見えるほど単純ではないことがよくあります。adminer.php ファイルが空の場合、一見するとファイルの問題のように見えますが、さらに詳しく調べると、キャッシュの問題である可能性があり、さらに設定の問題である可能性があり、そして最終的にはコード自体の問題である可能性もあります。
プログラマーでない方は、これらのことは自分には関係ないと思うかもしれません。しかし、よく考えてみてください。あなたが使うすべてのアプリ、訪れるすべてのウェブページには、裏で同様のシステムが稼働しています。キャッシュ、設定、エラー処理――これらの概念は、実は至るところに存在しているのです。
私たち人間と同じです。多くの場合、先延ばし、不安、イライラといった「症状」は、表面的には怠惰のように見えるかもしれませんが、さらに深く掘り下げてみると、目標が不明確であったり、さらに深く掘り下げると、失敗への恐怖、そしてさらに深く掘り下げると、幼少期の経験によって形成された考え方が原因となっている可能性があります。
真の原因を突き止めて初めて、適切な薬を処方することができる。
最後に、adminer.phpファイルが空であるという問題に遭遇した場合は、以下の順序で確認してください。
まず、PHP-FPMを再起動してキャッシュをクリアし、次にNginxの設定を確認し、最後にerror.logを確認してください。
ほとんどの場合、最初の2つの手順で問題は解決します。
もちろん、それでも解決しない場合は、error.log を確認してください。
答えを教えてくれますよ。
ここまで読んでいただき、もしこの記事が役に立ったと感じていただけたなら、ぜひ「いいね！」やシェアをお願いします。最新情報をいち早く受け取りたい方は、フォローもお願いします！
私の記事を読んでいただき、ありがとうございました。また次回お会いしましょう。
Chen Weiliang氏のブログ（https://www.chenweiliang.com/ ）に掲載されている記事「Adminer.phpへのアクセスが空白？名前変更は正常に機能する？原因分析と問題解決のための3つのステップ」が、皆様のお役に立てば幸いです。
この記事のリンクはご自由に共有してください：https://www.chenweiliang.com/cwl-34403.html