【Nginx講座 付録】現場で役立つトラブルシューティングと裏技レシピ集。502エラー対策から国別制限まで

「動かない」と叫ぶ前に、ログを読むエンジニアになろう。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回の講座、本当にお疲れ様でした。
あなたはもう、自信を持って「Nginx使えます」と言えるレベルに達しています。

しかし、インフラエンジニアの真価が問われるのは、システムが正常に動いている時ではありません。
「障害が起きた時」です。
「502 Bad Gatewayが出た！」「特定の国からのアクセスだけ遮断したい！」「社内からはパスワード無しで見れるようにしたい！」
そんな現場の悲鳴に対して、涼しい顔で対処できるかどうか。それがプロとアマチュアの分かれ道です。

本記事では、頻発するエラー（502/504/403/413）の根本原因と解決策、GeoIPを使った国別アクセス制限、そしてBasic認証とIP制限を組み合わせる高度な認証設定までを徹底解説します。

---

第1章：エラーコード別トラブルシューティング

Nginxが出すエラー画面には、必ず意味があります。
代表的なエラーと、その裏側で起きていることを解説します。

1. 502 Bad Gateway

症状: 画面に「502 Bad Gateway」と表示される。
意味: 「バックエンド（APサーバー）に繋ごうとしたけど、通信できなかったよ」。

チェックポイント:

• バックエンドは起動しているか？
  systemctl status php-fpm や pm2 status でアプリの生死を確認してください。落ちていれば再起動です。
• ポート番号は合っているか？
  nginx.conf の proxy_pass http://localhost:3000; のポート番号と、アプリがリッスンしているポートが一致しているか確認します。
• Firewallでブロックされていないか？
  同じサーバー内なら問題ないことが多いですが、別サーバーの場合、FirewalldやAWSセキュリティグループで許可が必要です。
• Unixソケットの権限
  PHP-FPMなどでUnixソケット（/run/php-fpm/www.sock）を使っている場合、Nginx実行ユーザーがそのファイルに書き込める権限があるか確認してください（ls -l）。

2. 504 Gateway Time-out

症状: 読み込みが続き、最後に「504 Gateway Time-out」が出る。
意味: 「バックエンドに繋がったけど、いつまで待っても返事が来ないから諦めたよ」。

チェックポイント:

• 処理が重すぎないか？
  大量のデータ集計や外部API呼び出しなど、バックエンド側で処理がスタックしていないか確認します。
• タイムアウト設定の延長
  どうしても時間がかかる処理なら、Nginxの「待つ時間」を延ばします。

location / {
    proxy_connect_timeout 600;
    proxy_send_timeout 600;
    proxy_read_timeout 600; # これが重要
    send_timeout 600;
    proxy_pass http://backend;
}

3. 413 Request Entity Too Large

症状: ファイルアップロード時にエラーになる。
意味: 「送られてきたデータがデカすぎて受け取れないよ」。

解決策:
デフォルトの上限は1MBです。client_max_body_size で上限を増やします。

http {
    client_max_body_size 20M; # 20MBまで許可
}

※PHPを使っている場合は、php.ini の upload_max_filesize と post_max_size も変更する必要があります。

---

第2章：403 Forbiddenの深い闇（権限とSELinux）

「403 Forbidden（アクセス権限がありません）」は、初心者が最もハマりやすいエラーです。
chmod 777 にしても直らない時、そこには別の番人がいます。

1. ディレクトリの実行権限

ファイル自体の権限（例: index.html）だけでなく、そこに至るすべての親ディレクトリに実行権限（x）が必要です。
/root/ や /home/user/ 配下にドキュメントルートを置くと、親ディレクトリの権限不足でNginxが入れず、403になります。
Webコンテンツは素直に /var/www/ や /usr/share/nginx/ 配下に置くのが無難です。

2. ラスボス「SELinux」

RHEL/AlmaLinux/Rocky Linuxを使っている場合、大抵の犯人はSELinuxです。
Nginxプロセスが、許可されていないディレクトリを読み取ろうとするとブロックされます。

確認方法:
一時的にSELinuxを無効化（Permissiveモード）にして、アクセスできるようになるか試します。

sudo setenforce 0

これで表示されたなら、原因はSELinuxです。

正しい対処法（無効化せずに許可を与える）:

# Nginx用のコンテキストを付与
sudo chcon -R -t httpd_sys_content_t /var/www/my-site

# リバースプロキシ（ネットワーク接続）を許可
sudo setsebool -P httpd_can_network_connect 1

プロのエンジニアは安易にSELinuxを切らず、適切なラベルを貼って運用します。

---

第3章：【裏技1】国別アクセス制限（GeoIP）

「海外からのスパム攻撃がウザい！日本国内からしか見れないようにしたい！」
そんな要望には、GeoIPモジュールで対応します。

導入手順（概要）

AlmaLinuxなどの場合、nginx-module-geoip を追加インストールし、MaxMind社のGeoIPデータベース（無料版あり）を用意します。

nginx.confの設定:

http {
    # GeoIPデータベースの読み込み
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # マッピング（許可する国を定義）
    map $geoip_country_code $allowed_country {
        default no;
        JP      yes;
    }
}

serverブロックでの適用:

server {
    location / {
        if ($allowed_country = no) {
            return 403; # 日本以外は拒否
        }
        ...
    }
}

これで、物理的に海外からのアクセスをシャットアウトできます。
セキュリティ効果は絶大です。

---

第4章：【裏技2】Basic認証とIP制限のハイブリッド（satisfy any）

「社内（特定のIP）からはパスワード無しで見せたいけど、社外（自宅やスマホ）からはBasic認証をかけて見せたい」。
開発環境などでよくあるこの要件、if 文を駆使しなくても一行で書けます。

魔法の言葉「satisfy any;」

通常、Nginxのアクセス制限は「すべての条件を満たす」必要がありますが、satisfy any; を書くと「どれか一つの条件を満たせばOK」になります。

location /dev/ {
    satisfy any; # ← これが魔法！

    # 条件1: IP制限（社内IP）
    allow 192.168.1.0/24;
    deny all;

    # 条件2: Basic認証
    auth_basic "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

動作:
社内IPからアクセス → 条件1クリア → パスワード入力なしで表示
自宅からアクセス → 条件1失敗 → 条件2へ → Basic認証画面が出る → パスワード正解なら表示

これを知っているだけで、社内ユーザーの利便性が爆上がりします。

---

第5章：【裏技3】レスポンスの書き換え（sub_filter）

「本番環境からデータをコピーしてステージング環境を作ったけど、HTML内のリンクが本番URL（production.com）のままになっていて、クリックすると本番に飛んでしまう…」。
ソースコードを全部置換するのは大変ですよね。

Nginxの sub_filter モジュールを使えば、サーバーがレスポンスを返す瞬間に、HTMLの中身をリアルタイムで書き換えることができます。

location / {
    proxy_pass http://backend;
    
    # 書き換え設定
    sub_filter 'https://production.com' 'https://staging.com';
    sub_filter_once off; # 全ての箇所を書き換える
    
    # 圧縮されていると書き換えられないので、バックエンドには圧縮させない
    proxy_set_header Accept-Encoding "";
}

あくまで応急処置的な機能ですが、移行期間中やテスト環境構築時には神のような力を発揮します。

---

第6章：プロの調査道具「curl -v」

ブラウザで「動かない！」と嘆く前に、プロはターミナルで調査します。
curl -v (verbose) コマンドを使えば、Nginxがどんなヘッダーを返しているかが丸見えになります。

$ curl -v https://example.com

> GET / HTTP/1.1
> Host: example.com
...
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.24.0
< Location: https://www.example.com/
...

「あ、301リダイレクトがループしてる」「キャッシュがHITしてる」「Serverヘッダーが出ててバージョンがバレてる」など、ブラウザでは見落としがちな情報が手に入ります。
トラブルシューティングの第一歩は、curl から始まると言っても過言ではありません。

---

おわりに：Nginxは「インフラの接着剤」

全8回＋付録、ここまでお付き合いいただきありがとうございました。
Nginxは単なるWebサーバーを超えて、ロードバランサー、WAF、キャッシュサーバー、そしてコンテンツ変換機として、Webシステムのあらゆる場所で活躍する「インフラの万能接着剤」です。

今回学んだ知識があれば、あなたはもう「なんとなく動かしている」状態から卒業し、自在にトラフィックをコントロールできるエンジニアになっているはずです。
技術は日々進化します（HTTP/3の次はHTTP/4が来るかもしれません）。
しかし、ログを見て、原因を切り分け、公式ドキュメントを読んで解決する。
この講座で培った「問題解決のプロセス」は、どんな技術になっても通用するあなたの武器です。

あなたの構築したサーバーが、世界中のユーザーに快適な体験を届け続けることを願っています。
Happy Nginx Life!