500 Internal Server Errorとは？原因と対処法（nginx・Apache）

HTTPエラー500とは？

HTTPエラー500（Internal Server Error）は、Webサーバーがリクエストを処理している途中で何かが壊れ、しかもサーバーがその原因を示さなかったことを意味します。 最も汎用的なサーバーエラーです。

HTTPの標準規格は、500を一文で定義しています。"The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request"（RFC 9110 §15.6.1）。サーバーがリクエストの処理を妨げる予期しない状態に遭遇した、という意味です。503と違い、500は問題が一時的なものかどうかについて何も示しません。

原因はほぼ常に、サーバー側のコードのバグ、設定ミス、クラッシュであり、訪問者の操作によるものではありません。修正はサイトの所有者または管理者が行う必要があります。

500エラーの表示例

表示される文言は、サーバーとアプリによって異なります。

• 500 Internal Server Error — 標準のステータス行
• 500 Internal Server Errorの下に「nginx」と表示 — nginx自体のエラーページ
• The server encountered an internal error or misconfiguration and was unable to complete your request. — Apacheのデフォルトページ
• There has been a critical error on this website.（日本語のサイトでは「このサイトで重大なエラーが発生しました。」）— WordPressの致命的エラー画面
• HTTP Error 500.19 - Internal Server Error — IIS。ドットの後の数字が理由を表します（500.19：構成データが無効）
• This page isn't working · HTTP ERROR 500（日本語版Chromeでは「このページは動作していません」）— 500レスポンスに独自のページがないときにChromeが表示する画面
• Request failed with status code 500 — APIを呼び出すAxiosなどのJavaScriptコード
• 500. That's an error.（日本語では「500. エラーが発生しました。」）— Google自身のエラーページ

nginxで500 Internal Server Errorが出る場合

ほとんどの場合、nginxは背後のアプリ（PHP-FPM、Node.js、Python）が返した500をそのまま中継しているだけです。PHP-FPMの場合、PHP自身のエラーメッセージはnginxのログに記録されます。nginxが自分で500を返すケースもいくつかあります。エラーログで探すべき行は次のとおりです。

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

（出典：nginxのソースコード。バックエンドがクラッシュまたは過負荷の場合は、500ではなく502や504になります。）

HTTPエラー500の主な原因

500エラーは、数十種類のサーバー側の問題から発生します。よくある原因は次のとおりです。

• .htaccessファイルの不具合 — 無効なディレクティブや誤ったRewriteRuleが1つあるだけで、Apacheはそのディレクトリ以下のすべてに500を返します。
• PHPの致命的エラー（Fatal error） — 構文エラー、キャッチされない例外、未定義の関数の呼び出しでスクリプトが停止します。
• PHPのメモリ・時間制限 — memory_limit（デフォルト128M）やmax_execution_time（30秒）を超えたスクリプトは停止されます。
• PHP-FPMサーバー上のphp_value行 — この行はApacheのmod_phpでしか動作しません。PHP-FPMでは、Apacheがこの行を拒否して500を返します。
• ファイル権限の誤り — PHPがincludeするファイルを読み取れない場合や、suPHP/suEXECのホストが全員に書き込み可能なファイル（777）を拒否する場合です（Webサーバー自体が読み取れないファイルは403になります）。
• プラグインやテーマ — 新しく入れた、または更新したWordPress、Joomla、Drupalの拡張機能がサイト全体をクラッシュさせます。
• データベース接続の失敗 — 認証情報の誤り、停止したデータベースサーバー、接続数の上限超過が原因です。
• コアファイルの破損 — アップデートの失敗やアップロードの中断の後に起こります。
• ディスクの空き容量不足 — サーバーがログ、セッション、一時ファイルを書き込めなくなります。
• nginx自身の原因 — rewriteのループ、読み取れないパスワードファイル、一時ファイルの書き込み失敗（多くはディスク容量不足）です。上のnginxのセクションを参照してください。

訪問者向けの対処法

他の人のウェブサイトで500エラーが表示された場合、問題はサーバー側にあります。あなたの側の問題ではありません。ただし、諦める前にいくつか試せることがあります。

• 1分ほど待ってから一度だけ再読み込みする（F5、MacではCmd+R）。500の多くは、デプロイや再起動の間だけ発生します。
• 全員に対してダウンしているか確認する — サーバーダウンチェックは11か所からページを開き、HTTPヘッダーチェッカーは当サーバーが受け取る正確なステータスコードを表示します。
• そのサイトのCookieを削除する、またはシークレット ウィンドウで試す。壊れたセッションCookieのせいで、一部のアプリがあなたにだけ全ページでエラーを出すことがあります。
• 時間をおいて再度アクセスする — 修正はサーバー側で行う必要があるので、管理者に時間を与えましょう。
• ウェブサイトの管理者に連絡する — 何時間も続く場合は、ページのアドレスと発生時刻を添えて知らせてください。

対処法1：サーバーのエラーログを確認する

エラーログは500エラーをデバッグするための最も重要なツールです。何が問題だったか、ファイルパス、行番号、エラーメッセージを正確に教えてくれます。他の対処法を試す前に、必ずまずログを確認してください。

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

対処法2：.htaccessをテスト・修復する

壊れた.htaccessファイルは、Apacheで500エラーが出る典型的な原因です。タイプミス1つ、サーバーがサポートしていないディレクティブ1つ、誤ったRewriteRule 1つで、そのディレクトリ全体が動かなくなります。Apacheのエラーログには、.htaccessファイルと問題のディレクティブが記録されます。例：Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration。

最も簡単なテスト方法は、ファイルを一時的にリネームすることです。リネーム後にサイトが表示されれば、.htaccessが原因です。

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

対処法3：ファイル権限を修正する

ファイル権限が500の原因になるのは、PHPがincludeするファイルを読み取れない場合と、全員に書き込み可能なファイルを拒否するsuPHP/suEXECのホストの場合です。一般的な設定はファイルが644、ディレクトリが755です。777は絶対に使わないでください。セキュリティ上のリスクであるうえ、suEXEC/suPHPのホストではそれ自体が500の原因になります。

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

対処法4：PHPのメモリと実行時間の制限を引き上げる

PHPは、メモリ制限や最大実行時間を超えたスクリプトを停止し、訪問者には500が表示されます。デフォルトのメモリ128Mと30秒は、重いページには足りないことがよくあります。

サーバーが実際に読み込む場所で値を引き上げてください。PHP-FPMの場合は、FPM用のphp.ini（例：/etc/php/8.3/fpm/php.ini）を編集してphp-fpmをリロードします。.user.iniの変更は、反映されるまで最大5分かかることがあります。

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

対処法5：プラグインとテーマを無効化する（CMS）

WordPressやJoomlaなどのCMSを使用している場合、不具合のあるプラグインやテーマが500エラーの最も一般的な原因の一つです。最も素早いテスト方法は、すべてのプラグインを一括で無効化し、一つずつ再有効化することです。

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

対処法6：データベース接続を確認・修復する

アプリケーションがデータベースに接続できない場合、500エラーが発生します。認証情報の間違い、データベースサーバーのダウン、テーブルの破損などが原因です。

まず設定ファイル（WordPressならwp-config.php、Laravelなら.env）でデータベースの認証情報を確認してください。次に接続をテストし、必要に応じて破損したテーブルを修復しましょう。

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

対処法7：PHPバージョンの互換性を確認する

古いPHPバージョン向けに書かれたコードは、新しいバージョンで致命的エラーになることがあります（その逆もあります）。PHPのアップグレード後は、削除された関数や変更された動作がよくある原因です。非推奨（deprecated）の関数は通知（notice）が出るだけです。

サイトが実際に使っているPHPのバージョンを確認してください。コマンドラインのphp -vは、サイトが使うものとは別のPHPを表示することがあるので、ホスティングのコントロールパネルや一時的なphpinfo()ページでも確認しましょう。

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

対処法8：ディスク容量を確認する

サーバーのディスク容量（またはinode）が尽きると、ログ、一時ファイル、セッションデータを書き込めなくなり、リクエストが500で失敗し始めます。

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 vs 502 vs 503 vs 504：それぞれの違い

最も重要な違い：500 = サーバーが内部で壊れた。 502 = プロキシがバックエンドから不正な応答を受け取った。503 = サーバーは動いているが手が回らない。504 = プロキシが待ちきれずにあきらめた。サーバーが返す正確なステータスコードは、DNS RobotのHTTPヘッダーチェッカーで確認できます。

502が出ている場合は、アプリケーション自体は正常で、問題はプロキシとアプリの間にあるかもしれません。このケースは502 Bad Gatewayのガイドで解説しています。

500エラーがSEOに与える影響

Googleのドキュメントでは、次のように説明されています（Googleのクローラーに関するドキュメント）。

• クロールが遅くなります。 5xxエラーが返されると、Googleはエラーを返すURLの数に比例して、そのサイトのクロール頻度を下げます。
• インデックス済みのページは当初は残ります。 すでにインデックスされたURLはしばらく保持されますが、サーバーエラーを返し続けるURLは削除されます。
• 回復は段階的です。 サーバーが再び2xxで応答するようになると、Googleはクロールを徐々に増やします。
• 計画的な停止には503を使いましょう。 1〜2日程度の停止なら、Retry-Afterヘッダー付きの503を返すことで（Google）、一時的な停止として扱われます（503のガイド）。

500エラーを予防する方法

予防はデバッグよりも効果的です。ウェブサイトで500エラーのリスクを最小限に抑えるためのベストプラクティスを紹介します。

• 稼働監視を設定する — UptimeRobotやPingdomなどのツールで1〜5分ごとにサイトを監視しましょう。500エラーが発生したら即座にアラートを受け取れます。
• 変更は必ずステージング環境でテストする — 本番環境に直接デプロイしないでください。プラグインの更新、PHPのアップグレード、設定変更は、まずステージング環境でテストしましょう。
• バージョン管理（Git）を使用する — すべての変更をコミットし、問題のあるデプロイを1つのコマンドで即座にロールバックできるようにしましょう。
• 適切なエラーハンドリングを実装する — データベースクエリやAPI呼び出しをtry-catchブロックで囲みましょう。すべてのエラーの完全なスタックトレースをサーバー側にログ記録してください。
• ディスク容量とサーバーリソースを監視する — ディスク使用率80%超、高CPU、メモリ圧迫時のアラートを設定しましょう。
• ソフトウェアを最新に保つ — 古いCMSバージョン、プラグイン、サーバーソフトウェアには、クラッシュの原因となる既知のバグが含まれています。
• 自動バックアップを維持する — 復元手順を定期的にテストしましょう。テストしたことのないバックアップはバックアップではありません。
• PHPの制限値を適切に設定する — memory_limitとmax_execution_timeは、デフォルト値ではなく、実際のワークロードに基づいて設定しましょう。
• CI/CDパイプラインを使用する — デプロイ前にテストを自動化しましょう。テストが失敗した場合、デプロイを実行すべきではありません。