502 Bad Gateway完全ガイド - Nginx/Apache環境別解決法

502エラーでサイトが表示されない問題を、Nginx/Apache環境別に実践的な対処法と診断フローで完全解決します。

こんな悩みありませんか？

Webサイトにアクセスしようとしたら「502 Bad Gateway」というエラーが表示されて、サイトが見られない。お客様からも「サイトが見れない」と連絡が来て、一刻も早く復旧させたい。でも、どこから手をつければいいのか分からない…

神奈川のWeb制作会社「Fivenine Design」として20年以上、数多くのサーバートラブルを解決してきた経験から、502 Bad Gatewayエラーの完全な対処法をお伝えします。

先日も、あるクライアント様のWordPressサイトで突然502エラーが発生。アクセス数が多い時間帯だったため、機会損失が心配でしたが、体系的なトラブルシューティングで15分以内に復旧させることができました。

502 Bad Gatewayとは何か

502 Bad Gatewayエラーは、Webサーバー（NginxやApache）がアプリケーションサーバー（PHP-FPMやNode.jsなど）からの応答を正常に受け取れない時に発生します。つまり、サーバー間の通信で問題が起きている状態です。

flowchart LR
    A[ユーザー] --> B[Webサーバー<br/>Nginx/Apache]
    B --> C[アプリケーション<br/>PHP/Node.js]
    B -.-> D[502エラー<br/>通信失敗]
    C -.-> E[応答なし/遅延]

このエラーが発生すると、サイトが完全にアクセス不能になり、ビジネスに直接影響します。実際に弊社のクライアントでは、502エラーが1時間続いた結果、ECサイトの売上が通常日の30%減少したケースもありました。

環境別の主な原因と対処法

Nginx環境での502エラー対処法

Nginx環境で最も多いのは、PHP-FPMとの通信問題です。

1. PHP-FPMの状態確認

# PHP-FPMの状態確認
sudo systemctl status php-fpm
# または
sudo systemctl status php8.1-fpm

# プロセス確認
ps aux | grep php-fpm

2. ソケット通信の確認

# ソケットファイルの存在確認
ls -la /var/run/php/php8.1-fpm.sock

# 権限確認
ls -la /var/run/php/

3. Nginx設定の修正

# /etc/nginx/sites-available/default
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_read_timeout 300;
    fastcgi_connect_timeout 300;
}

Node.jsアプリケーションとの連携での問題です。

1. Node.jsプロセス確認

# Node.jsアプリの状態確認
pm2 status
# または
sudo systemctl status your-app

# ポート確認
netstat -tlnp | grep :3000

2. Nginx設定例

location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_cache_bypass $http_upgrade;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
}

Apache環境での502エラー対処法

Apache環境では、mod_proxy_fcgiやmod_proxyの設定が原因となることが多いです。

1. Apacheモジュールの確認

# 必要なモジュールが有効か確認
sudo apache2ctl -M | grep proxy
sudo apache2ctl -M | grep fcgi

# モジュール有効化
sudo a2enmod proxy_fcgi
sudo a2enmod setenvif

2. バーチャルホスト設定

# /etc/apache2/sites-available/your-site.conf
<VirtualHost *:80>
    ServerName your-domain.com
    DocumentRoot /var/www/html
    
    # PHP-FPM設定
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/var/run/php/php8.1-fpm.sock|fcgi://localhost"
    </FilesMatch>
    
    # タイムアウト設定
    ProxyTimeout 300
</VirtualHost>

よくある設定ミス5選

1. PHP-FPMプール設定の不備

; /etc/php/8.1/fpm/pool.d/www.conf
[www]
user = www-data
group = www-data
listen = /var/run/php/php8.1-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

よくあるミス： listen.ownerやlisten.groupがWebサーバーのユーザーと一致していない。

2. タイムアウト設定の不適切な値

多くの場合、デフォルトのタイムアウト値（30秒）では不十分です。特にWordPressサイトで重いプラグインを使用している場合は要注意。

3. メモリ不足

# メモリ使用量確認
free -h
# プロセス別メモリ使用量
top -o %MEM

4. ファイルディスクリプタ制限

# 現在の制限値確認
ulimit -n
# システム全体の制限確認
cat /proc/sys/fs/file-max

5. ログファイルの権限問題

# ログディレクトリの権限確認
ls -la /var/log/nginx/
ls -la /var/log/php/

診断フローチャート

flowchart TD
    A[502エラー発生] --> B[Webサーバー確認]
    B --> C{Nginx or Apache?}
    C -->|Nginx| D[PHP-FPM状態確認]
    C -->|Apache| E[mod_proxy確認]
    D --> F{PHP-FPM動作中?}
    F -->|No| G[PHP-FPM再起動]
    F -->|Yes| H[ソケット/ポート確認]
    E --> I{モジュール有効?}
    I -->|No| J[モジュール有効化]
    I -->|Yes| K[設定ファイル確認]
    G --> L[問題解決]
    H --> M{通信可能?}
    M -->|No| N[設定修正]
    M -->|Yes| O[ログ確認]
    J --> L
    K --> N
    N --> L
    O --> P[根本原因特定]
    P --> L

パフォーマンス改善効果

適切な設定を行うことで、以下のような改善効果が期待できます。

トラブルシューティングで注意すべきポイント

実際のトラブルシューティングでは、焦って複数の設定を同時に変更してしまいがちです。しかし、これは問題を複雑化させる原因となります。

ある製造業のクライアント様では、502エラーが発生した際に担当者が複数の設定を一度に変更した結果、何が原因で何が解決策だったのか分からなくなってしまいました。結果的に、弊社で一つずつ設定を戻しながら原因を特定し、最終的にPHP-FPMのプロセス数が不足していることが判明しました。

重要な原則：

変更は一つずつ行う
変更前に必ずバックアップを取る
各変更後に動作確認を行う
ログを継続的に監視する

予防策と監視体制

502エラーを未然に防ぐには、継続的な監視とメンテナンスが重要です。

監視すべき項目

CPU使用率70%

メモリ使用率80%

ディスク使用率65%

応答時間90%

定期メンテナンス項目

# 週次実行スクリプト例
#!/bin/bash

# ログローテーション確認
sudo logrotate -f /etc/logrotate.d/nginx
sudo logrotate -f /etc/logrotate.d/php8.1-fpm

# プロセス数確認
echo "PHP-FPM processes: $(ps aux | grep php-fpm | wc -l)"
echo "Nginx processes: $(ps aux | grep nginx | wc -l)"

# ディスク容量確認
df -h

# メモリ使用量確認
free -h

緊急時の連絡体制

502エラーが発生した場合の連絡フローも事前に整備しておくことが重要です。

flowchart TD
    A[502エラー検知] --> B[担当者への自動通知]
    B --> C[一次対応開始]
    C --> D{15分で復旧?}
    D -->|Yes| E[監視継続]
    D -->|No| F[エスカレーション]
    F --> G[専門チームによる対応]
    G --> H[根本原因分析]
    H --> I[再発防止策実装]

解決できない場合は

エラーが解決しない場合、無料でご相談ください

詳しく見る

まとめと次のステップ

502 Bad Gatewayエラーは、適切な知識と体系的なアプローチがあれば必ず解決できる問題です。重要なのは、パニックにならず冷静に診断フローに従って対応することです。

実際に弊社では、このような体系的なトラブルシューティングにより、クライアントのサイト可用性を99.9%以上に維持しています。また、問題発生時の平均復旧時間も10分以内を実現しています。

今すぐできること

現在の環境を把握する - Webサーバーとアプリケーションサーバーの構成を確認
監視体制を整える - 最低限、死活監視は導入する
バックアップ体制を確立 - 設定ファイルのバックアップを自動化
緊急時の手順書を作成 - 今回の内容を元に自社用の手順書を作成

トラブルシューティング・チェックリスト

神奈川でWeb制作・運用を行う弊社「Fivenine Design」では、こうしたサーバートラブルの予防から緊急対応まで、20年以上の経験を活かしてサポートしています。自社での対応が難しい場合や、より安定した運用体制を構築したい場合は、お気軽にご相談ください。技術的な課題を解決し、本来のビジネスに集中できる環境づくりをお手伝いします。