500 internal server error cloudflare ワードプレスサイトの直し方
WordPressサイトをCloudflare経由で公開しているときに「500 internal server error」が出ると、管理画面にも入れず慌ててしまいがちです。ここでは、2025-12-05 時点で一般的なWordPress＋Cloudflare環境を前提に、よくある原因と復旧までの具体的な手順を整理します。専門用語はなるべく噛み砕き、実際の作業の順番がイメージできるように解説します。
WordPress＋Cloudflareで500エラーが出る主なパターン
WordPress側のエラーがCloudflare経由で見えているケースが多い
WordPressサイトの500 internal server errorは、多くの場合「WordPress/PHP側の問題」がCloudflare経由で見えているだけというパターンです。特に、プラグイン・テーマ・PHPバージョン・.htaccessなど、アプリ寄りの要素が原因になりやすいです。
| 症状のパターン | 起きやすい原因 | 確認の優先度 |
|---|---|---|
| テーマやプラグイン更新直後に500 | 更新したテーマ／プラグインのPHPエラー | 最優先で疑う |
| サーバー移行・PHPバージョン変更後に500 | 新しいPHPバージョンとの非互換、設定差異 | 高い |
| .htaccessを書き換えた直後に500 | リライトルールの記述ミス | 高い |
| アクセス集中時だけ500 | メモリ不足・プロセス不足・PHP-FPM設定 | 状況次第 |
- 要点: WordPressサイトの500は、まず「WordPress側の変更」を思い出す
- 要点: Cloudflareの設定をいじっていないのに突然500になった場合は、サーバー側の負荷やエラーを疑う
- 要点: 直前の更新・移行・設定変更のメモがあると原因特定が早くなる
Step1: Cloudflareを一時停止してWordPress単体で確認
CloudflareかWordPressかを切り分ける
まずはCloudflareの影響を排除し、WordPress単体で正常に動くかを確認します。
| 手順 | やり方 | 結果から分かること |
|---|---|---|
| DNSのオレンジ雲をグレーにする | Cloudflareダッシュボードで対象ドメインのAレコード／CNAMEの雲アイコンをクリックしてグレー（DNS only）に変更 | Cloudflareを経由しなくなるため、オリジンサーバーだけの挙動が分かる |
| Cloudflareを一時停止（Pause） | 高度なトラブルシュート用。ドメイン全体でCloudflareをバイパス | DNSだけを使う形になり、キャッシュやWAFなども無効化される |
| 直接IPでアクセスできるか確認 | hostsファイルや一時的な設定で、サーバーのIPに直接アクセス | IP直アクセスでも500なら、確実にWordPress側の問題といえる |
- 要点: Cloudflareをバイパスしても500なら、WordPress側の問題に集中してよい
- 要点: 逆にバイパスすると直る場合は、Cloudflare設定やWAFが関係している可能性が高まる
- 要点: 作業後は元に戻すことを忘れない（特に本番ドメイン）
Step2: WordPress側の基本的な復旧手順
プラグイン・テーマ・.htaccessを順番に疑う
Cloudflareをバイパスしても500が続く場合は、WordPress本体やPHPのエラーを疑います。管理画面に入れないときでも、FTPやサーバーパネルから次のような作業ができます。
| 対象 | 具体的な操作例 | 復旧の目安 |
|---|---|---|
| プラグイン | /wp-content/plugins/ のフォルダ名を一時的に変更し、全プラグインを無効化してみる | これでサイトが表示される場合は、特定プラグインが原因の可能性が高い |
| テーマ | /wp-content/themes/ の使用中テーマフォルダをリネームし、デフォルトテーマ（twentytwenty系など）に切り替える | テーマ変更で表示されるようなら、テーマ内のPHPエラーが疑われる |
| .htaccess | ルートにある .htaccess をバックアップ後、一旦削除 or 最小構成のWordPress推奨内容だけにする | リライトルールやモジュール指定のミスで500になっていた場合は改善する |
| PHPバージョン | サーバーパネルから一つ前の安定バージョンに戻してみる | 非互換なプラグイン・テーマがあった場合に復旧することがある |
- 要点: 管理画面に入れなくても、FTPやファイルマネージャーからプラグイン・テーマは無効化できる
- 要点: 変更は1つずつ行い、「何をしたら直ったか」を必ずメモする
- 要点: 復旧後は原因となったプラグインやテーマの更新情報・代替案を検討する
Step3: Cloudflare設定が原因のときの対処
キャッシュ・WAF・リダイレクトの確認
WordPress自体は動いているのに、Cloudflare経由だと500が出る場合は、Cloudflareの設定に問題がある可能性があります。
| 項目 | 確認内容 | よくあるトラブル |
|---|---|---|
| ページルール・リダイレクト | 特定URLで無限リダイレクトになっていないか | HTTP⇔HTTPSの設定が二重になり、ループしている |
| キャッシュ設定 | HTMLまで強制キャッシュしていないか | エラー画面がキャッシュされて、直しても500が出続ける |
| WAF・セキュリティレベル | WordPressログインや管理画面へのアクセスがブロックされていないか | ログインページが攻撃と誤認識され、管理画面に入れない |
| SSL/TLSモード | Flexible / Full / Full(strict) の設定がサーバー側と合っているか | オリジン側のSSL証明書設定と噛み合わずエラーになる |
- 要点: Cloudflare側でリダイレクトやキャッシュを強くかけすぎていないかを確認する
- 要点: ログインページなど重要なURLは「除外ルール」を作っておくとトラブルが減る
- 要点: SSLモードはレンタルサーバーのSSL設定とセットで考える
Step4: サーバーリソースとログをチェックする
負荷が高すぎて落ちていないかを確認
プラグインやテーマに問題がなくても、アクセス集中やバッチ処理でサーバーリソースが枯渇すると500エラーが出ることがあります。Cloudflareはアクセス負荷をある程度緩和しますが、オリジンサーバー側が耐えられなければエラーは防げません。
| 見るべきポイント | 確認方法 | 対処の方向性 |
|---|---|---|
| CPU・メモリ使用率 | レンタルサーバーのリソースモニタでピーク時の値を確認 | スケールアップ・プラン変更・プラグインの整理などを検討 |
| エラーログ | error_log にPHP Fatal errorやAllowed memory size系エラーがないか | メモリ制限の引き上げ、問題コードの修正やプラグイン停止 |
| Cron・予約投稿 | WP-Cronや外部Cronで重い処理が同時刻に走っていないか | 処理を分割・時間をずらす・サーバーCronへの移行 |
- 要点: リソース不足が原因の500は、一時的に収まっても再発しやすい
- 要点: 長期的にはサーバースペックの見直しやプラグイン削減が必要になることもある
- 要点: エラーログはWordPressトラブル対応の最重要情報源
再発防止のための運用ポイント
本番前のテストとバックアップがカギ
500 internal server errorは、サイト全体が見えなくなるためユーザーへのインパクトが大きい障害です。次のような運用ルールを決めておくと、トラブルを減らしやすくなります。
- プラグイン・テーマの更新は、できればステージング環境で先に試す
- 自動バックアップの仕組みを用意し、復旧用のポイントを確保しておく
- Cloudflareとサーバー双方の設定変更は「いつ・何を変えたか」を記録する
- 要点: 「テスト環境＋バックアップ＋変更履歴」の3点セットがあると復旧が格段に楽になる
- 要点: トラブル時に慌てないために、普段からログイン情報や接続情報を整理しておく
- 要点: 大きな更新はアクセスの少ない時間帯に行うのが安全
