nginx Runbook

症状 nginxでWebページにアクセスすると「403 Forbidden」が表示される。 結論：まずこれを確認 ドキュメントルートのパーミッションが755以上か ファイルの所有者がnginxユーザーで読めるか indexファイル（index.html等）が存在するか トラブルシューティングフロー flowchart TD A[403 Forbidden 発生] --> B{エラーログを確認} B -->|Permission denied| C[パーミッション/所有者を確認] B -->|directory index is forbidden| D[index設定を確認] B -->|SELinux関連| E[SELinuxコンテキストを確認] C --> F[chmod/chownで修正] D --> G[indexファイル配置 or autoindex設定] E --> H[restorecon実行] F --> I[nginx再起動して確認] G --> I H --> I よくある原因 ディレクトリのパーミッション不足 - nginxユーザーがディレクトリを読めない（755未満） ファイルのパーミッション不足 - nginxユーザーがファイルを読めない（644未満） indexファイルが存在しない - index.htmlやindex.phpがなく、autoindexも無効 親ディレクトリの実行権限がない - 途中のディレクトリに+xがない SELinuxによるブロック - CentOS/RHELでSELinuxがアクセスを拒否している nginx.confのallow/deny設定 - IPベースのアクセス制限に引っかかっている ファイル所有者の問題 - ファイルがrootのみ読める状態になっている 確認手順 ステップ1: エラーログを確認する sudo tail -50 /var/log/nginx/error.log 🔍 チェックポイント: Permission denied、directory index is forbidden、SELinux などのキーワードを探す ...

症状 nginxで静的ファイル（CSS、JavaScript、画像など）にアクセスすると404 Not Foundが返される 結論：まずこれを確認 nginx -T で実際に読み込まれている設定を確認 root または alias のパスが実際のファイルパスと一致しているか確認 ファイルとディレクトリのパーミッションを確認（nginxユーザーが読めるか） トラブルシューティングフロー flowchart TD A[静的ファイルが404] --> B{error.logを確認} B -->|No such file or directory| C[パス設定を確認] B -->|Permission denied| D[パーミッション確認] B -->|エラーなし| E[access.logを確認] C --> F{root/aliasの設定} F -->|rootを使用| G[rootセクションへ] F -->|aliasを使用| H[aliasセクションへ] D --> I[パーミッションセクションへ] E --> J[リクエストが届いているか確認] よくある原因 rootパスの誤り - rootディレクティブのパスがファイルの実際の場所と異なる aliasの末尾スラッシュ - aliasディレクティブで末尾スラッシュの有無が不一致 パーミッション不足 - nginxの実行ユーザーがファイルを読み取れない SELinuxの制限 - SELinuxがファイルアクセスをブロックしている（RHEL/CentOS系） locationブロックの優先順位 - 別のlocationブロックが先にマッチしている シンボリックリンクの設定 - disable_symlinks が有効になっている try_filesの設定ミス - 静的ファイルの前にバックエンドへ転送している 確認手順 ステップ1: エラーログを確認する # 最新のエラーログを確認 sudo tail -50 /var/log/nginx/error.log # 特定のファイル名でフィルタ sudo grep "ファイル名" /var/log/nginx/error.log 🔍 チェックポイント: No such file or directory または Permission denied のメッセージを探す ...

症状 nginxにアクセスすると「502 Bad Gateway」エラーが表示される。 結論：まずこれを確認 バックエンド（upstream）のプロセスが起動しているか確認 sudo tail -f /var/log/nginx/error.log でエラー内容を特定 バックエンドのポート・ソケットパスが設定と一致しているか確認 トラブルシューティングフロー flowchart TD A[502 Bad Gateway 発生] --> B{error.log を確認} B -->|connect refused| C[バックエンドプロセス確認] B -->|upstream timed out| D[タイムアウト設定確認] B -->|no live upstreams| E[upstream設定確認] B -->|Permission denied| F[ソケット権限確認] C --> G{プロセス起動中?} G -->|No| H[バックエンドを起動] G -->|Yes| I[ポート/ソケット設定確認] D --> J[proxy_read_timeout 調整] E --> K[upstream ブロック確認] F --> L[ソケットファイル権限確認] よくある原因 バックエンドプロセスが停止している - PHP-FPM、Node.js、Gunicornなどが起動していない ポート番号の不一致 - nginxの設定とバックエンドのリッスンポートが異なる Unixソケットのパス間違い - .sock ファイルのパスが設定と異なる ソケットファイルの権限不足 - nginxユーザーがソケットにアクセスできない バックエンドのタイムアウト - 処理に時間がかかりすぎてnginxが切断 upstreamサーバーの過負荷 - バックエンドがリクエストを処理しきれない SELinux/AppArmorによるブロック - セキュリティモジュールが通信を遮断 確認手順 ステップ1: nginxエラーログを確認する sudo tail -50 /var/log/nginx/error.log 🔍 チェックポイント: connect() failed、upstream timed out、no live upstreams などのメッセージを探す ...

症状 nginxでファイルアップロード時に「413 Request Entity Too Large」エラーが表示される。 結論：まずこれを確認 client_max_body_size の現在値を確認する アップロードしようとしているファイルサイズと比較する 設定値を適切な値に変更し、nginx を reload する トラブルシューティングフロー flowchart TD A[413エラー発生] --> B{エラーログを確認} B --> C[client intended to send too large body] C --> D{client_max_body_size の設定場所を特定} D --> E[http/server/location ブロックを確認] E --> F{設定値は適切か?} F -->|小さすぎる| G[値を増やして reload] F -->|設定なし| H[デフォルト1MBが適用されている] H --> G G --> I[動作確認] よくある原因 client_max_body_size 未設定 - デフォルト値 1MB が適用されている 設定場所が間違っている - location ブロックに設定すべきところを http ブロックにのみ設定している 設定の優先順位の誤解 - より内側のブロックで上書きされている 複数の nginx.conf が存在 - include で読み込まれた別ファイルの設定が優先されている reload 忘れ - 設定変更後に nginx を再読み込みしていない リバースプロキシ先の制限 - nginx の後段（PHP-FPM、アプリケーション）にも制限がある 一時ファイル領域の容量不足 - client_body_temp_path のディスク容量が不足している 確認手順 ステップ1: エラーログを確認する # エラーログの場所を確認（環境により異なる） sudo tail -20 /var/log/nginx/error.log 🔍 チェックポイント: client intended to send too large body というメッセージがあれば、このRunbookの対象 ...

症状 nginxのエラーログに connect() failed (111: Connection refused) while connecting to upstream が出力される。 クライアントには 502 Bad Gateway または 504 Gateway Timeout が返される。 結論：まずこれを確認 バックエンドサーバー（upstream）のプロセスが起動しているか nginx設定の proxy_pass で指定したポートが正しいか バックエンドが指定アドレス（127.0.0.1 or 0.0.0.0）でリッスンしているか トラブルシューティングフロー flowchart TD A[エラーログを確認] --> B{upstreamのホスト:ポートを特定} B --> C{バックエンドプロセスは起動している?} C -->|No| D[バックエンドを起動する] C -->|Yes| E{リッスンポートは正しい?} E -->|No| F[ポート設定を修正] E -->|Yes| G{リッスンアドレスは正しい?} G -->|No| H[bind addressを修正] G -->|Yes| I{ファイアウォールは許可?} I -->|No| J[ファイアウォール設定を修正] I -->|Yes| K[バックエンドのログを確認] よくある原因 バックエンドプロセスが停止している — デプロイ後やサーバー再起動後に起動していない ポート番号の不一致 — nginx設定とバックエンドの実際のリッスンポートが異なる リッスンアドレスの問題 — バックエンドが 127.0.0.1 のみでリッスンし、nginxが別IPでアクセスしている ソケットファイルの問題 — UNIXソケット使用時にパーミッションまたはパスが間違っている ファイアウォールによるブロック — iptables/firewalld/ufw がローカル通信をブロックしている SELinuxによるブロック — SELinux が httpd_can_network_connect を拒否している バックエンドの起動遅延 — nginx起動時にバックエンドがまだ準備できていない 確認手順 ステップ1: エラーログからupstream情報を確認する sudo tail -50 /var/log/nginx/error.log | grep "upstream" 🔍 チェックポイント: upstream: "http://127.0.0.1:3000/..." のようにホストとポートが表示される ...

症状 nginxのエラーログに Permission denied が記録される、または403 Forbiddenが表示される。 結論：まずこれを確認 エラーログで具体的なファイルパスを特定する そのファイル・ディレクトリのパーミッションを確認する nginxの実行ユーザーを確認する トラブルシューティングフロー flowchart TD A[Permission denied発生] --> B{エラーログを確認} B --> C[対象ファイルパスを特定] C --> D{ファイルは存在する?} D -->|No| E[パス設定を見直す] D -->|Yes| F{パーミッションを確認} F --> G{読み取り権限あり?} G -->|No| H[chmod/chownで修正] G -->|Yes| I{親ディレクトリの権限は?} I -->|問題あり| J[ディレクトリ権限を修正] I -->|問題なし| K{SELinuxは有効?} K -->|Yes| L[SELinuxコンテキストを確認] K -->|No| M[nginx実行ユーザーを確認] よくある原因 ファイルのパーミッション不足 - nginxユーザーに読み取り権限がない 親ディレクトリの実行権限不足 - ディレクトリに x 権限がない ファイル所有者の不一致 - rootや別ユーザーが所有している SELinux/AppArmorによる制限 - セキュリティモジュールがブロックしている シンボリックリンクの権限問題 - リンク先のファイルに権限がない nginx実行ユーザーの設定ミス - 設定ファイルのuserディレクティブが誤っている ホームディレクトリ配下への配置 - /home/user/ 配下はデフォルトで制限される 確認手順 ステップ1: エラーログを確認する sudo tail -50 /var/log/nginx/error.log | grep -i "permission denied" 🔍 チェックポイント: open() "/path/to/file" failed (13: Permission denied) の形式でパスが表示される ...

症状 nginx で proxy_pass を設定したが、バックエンドに転送されない、または 502 Bad Gateway が表示される。 結論：まずこれを確認 バックエンドのプロセスが起動しているか確認する proxy_pass の URL 末尾のスラッシュ有無を確認する nginx のエラーログ /var/log/nginx/error.log を確認する トラブルシューティングフロー flowchart TD A[proxy_pass が動かない] --> B{バックエンドは起動している?} B -->|No| C[バックエンドを起動する] B -->|Yes| D{nginx error.log にエラーあり?} D -->|Connection refused| E[ポート番号を確認] D -->|Permission denied| F[SELinux/権限を確認] D -->|Timeout| G[バックエンドの応答を確認] D -->|No error| H{ブラウザで直接アクセスできる?} H -->|Yes| I[location ブロックの設定を確認] H -->|No| J[ファイアウォールを確認] よくある原因 バックエンドが起動していない - プロセスが落ちている、ポートが Listen されていない proxy_pass の URL 末尾スラッシュ問題 - スラッシュの有無でパスの扱いが変わる ポート番号の間違い - バックエンドの Listen ポートと proxy_pass の指定が一致していない SELinux が接続をブロック - httpd_can_network_connect が無効 upstream の名前解決失敗 - DNS や /etc/hosts の問題 タイムアウト設定が短すぎる - バックエンドの応答より前に nginx が切断 location ブロックのマッチ優先度 - 別の location が先にマッチしている 確認手順 ステップ1: バックエンドの起動状態を確認する # バックエンドのポートが Listen されているか確認 ss -tlnp | grep :3000 # または netstat -tlnp | grep :3000 🔍 チェックポイント: LISTEN 状態で対象ポートが表示されれば正常 ...

症状 nginxでHTTPS接続時に「この接続ではプライバシーが保護されません」「NET::ERR_CERT_AUTHORITY_INVALID」「SSL_ERROR_RX_RECORD_TOO_LONG」などのSSL証明書関連エラーが表示される。 結論：まずこれを確認 証明書の有効期限を確認する：echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -dates nginxの設定で ssl_certificate と ssl_certificate_key のパスが正しいか確認する 証明書ファイルのパーミッションを確認する（nginxユーザーが読めるか） トラブルシューティングフロー flowchart TD A[SSL証明書エラー発生] --> B{ブラウザのエラー種別は?} B -->|期限切れ系| C[証明書の有効期限を確認] B -->|信頼できない系| D[中間証明書を確認] B -->|接続エラー系| E[nginx設定を確認] C --> F{期限切れ?} F -->|Yes| G[証明書を更新] F -->|No| H[システム時刻を確認] D --> I{中間証明書あり?} I -->|No| J[中間証明書を結合] I -->|Yes| K[証明書チェーンを確認] E --> L{設定ファイルにエラー?} L -->|Yes| M[パス・構文を修正] L -->|No| N[パーミッションを確認] よくある原因 証明書の有効期限切れ - Let’s Encryptは90日、更新忘れが多い 中間証明書の未設定 - サーバー証明書のみで中間証明書が結合されていない 証明書ファイルパスの誤り - nginx設定内のパスが実際のファイル位置と異なる 秘密鍵と証明書の不一致 - 異なる鍵ペアの証明書と秘密鍵を指定している パーミッション不足 - nginxのワーカープロセスが証明書ファイルを読めない ポート443でHTTP設定 - HTTPSサーバーブロックにSSL設定がない サーバー名の不一致 - 証明書のCN/SANとアクセス先ドメインが異なる 確認手順 ステップ1: 証明書の有効期限を確認する # リモートから確認 echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates # ローカルファイルを直接確認 openssl x509 -in /etc/nginx/ssl/server.crt -noout -dates 🔍 チェックポイント: notAfter が現在日時より未来であれば有効期限内 ...

症状 nginxのエラーログに too many open files が記録され、接続エラーやレスポンス遅延が発生する。 結論：まずこれを確認 cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files" でnginxプロセスの上限を確認 上限が低い場合（1024など）は worker_rlimit_nofile と OS の設定を引き上げる 設定変更後は systemctl restart nginx で反映 トラブルシューティングフロー flowchart TD A[too many open files 発生] --> B{エラーログを確認} B --> C[nginx プロセスの上限を確認] C --> D{上限が低い?} D -->|Yes| E[nginx.conf を確認] D -->|No| F[接続数が異常に多い可能性] E --> G{worker_rlimit_nofile 設定あり?} G -->|No| H[worker_rlimit_nofile を追加] G -->|Yes| I[OS の ulimit を確認] I --> J{OS 上限が低い?} J -->|Yes| K[/etc/security/limits.conf を編集] J -->|No| L[systemd の LimitNOFILE を確認] F --> M[アクセスログ・接続元を調査] H --> N[nginx を再起動] K --> N L --> N よくある原因 nginx.conf に worker_rlimit_nofile が未設定 - デフォルトでは OS の soft limit を継承する OS の ulimit が低い - 多くのディストリビューションでデフォルト 1024 systemd の LimitNOFILE が制限 - systemd 経由で起動すると別の上限が適用される worker_connections が高すぎる - 接続数 × 2（クライアント＋upstream）のファイルディスクリプタが必要 keepalive_timeout が長すぎる - 接続が長時間保持されファイルディスクリプタを消費 DDoS やクローラーによる大量接続 - 想定外のアクセス集中 upstream への接続が滞留 - バックエンドの応答遅延で接続が解放されない 確認手順 ステップ1: エラーログを確認する tail -100 /var/log/nginx/error.log | grep "open files" 🔍 チェックポイント: [alert] ... open() ... failed (24: Too many open files) のようなメッセージが出力される ...

症状 nginxのエラーログに upstream timed out (110: Connection timed out) が記録され、502 Bad Gateway または 504 Gateway Timeout が発生する。 結論：まずこれを確認 バックエンド（upstream）サーバーが起動しているか確認 バックエンドの応答時間がnginxのタイムアウト設定を超えていないか確認 ネットワーク経路に問題がないか確認 トラブルシューティングフロー flowchart TD A[upstream timed out 発生] --> B{バックエンドは起動している?} B -->|No| C[バックエンドを起動] B -->|Yes| D{バックエンドに直接アクセス可能?} D -->|No| E[ネットワーク/ファイアウォール確認] D -->|Yes| F{応答時間は正常?} F -->|遅い| G[バックエンドの処理を改善<br>またはタイムアウト延長] F -->|正常| H{nginx設定は正しい?} H -->|No| I[proxy_pass設定を確認] H -->|Yes| J[負荷状況を確認] よくある原因 バックエンドサーバーの停止 - upstream先のプロセスが落ちている バックエンドの処理遅延 - 重いクエリやAPIで応答が遅れている タイムアウト設定が短すぎる - デフォルト60秒では足りない処理がある ネットワーク到達性の問題 - ファイアウォールやセキュリティグループでブロック バックエンドのコネクション枯渇 - 同時接続数の上限に達している DNSの名前解決失敗 - upstream指定のホスト名が解決できない ソケットファイルのパーミッション - Unix socketを使う場合の権限問題 確認手順 ステップ1: エラーログの詳細を確認する # エラーログの最新エントリを確認 sudo tail -50 /var/log/nginx/error.log | grep -i "upstream" # 特定の時間帯のエラーを抽出 sudo grep "upstream timed out" /var/log/nginx/error.log | tail -20 🔍 チェックポイント: upstream timed out の後に続くIPアドレスとポートを確認。これがタイムアウトしているバックエンド。 ...

症状 nginx の worker process が予期せず終了する、または繰り返しクラッシュする。 結論：まずこれを確認 sudo journalctl -u nginx --since "1 hour ago" でエラーログを確認 dmesg | grep -i nginx でカーネルログ（OOM Killer、segfault）を確認 nginx -t で設定ファイルの構文エラーを確認 トラブルシューティングフロー flowchart TD A[worker processが異常終了] --> B{エラーログを確認} B -->|signal 11 SIGSEGV| C[セグメンテーション違反] B -->|signal 9 SIGKILL| D[OOM Killerの可能性] B -->|設定エラー| E[nginx -t で確認] B -->|ログなし| F[dmesg を確認] C --> G[モジュール/バージョン確認] D --> H[メモリ使用量確認] E --> I[設定ファイル修正] F --> J{dmesgに記録あり?} J -->|OOM| H J -->|segfault| G J -->|なし| K[リソース上限確認] よくある原因 OOM Killer による強制終了 - メモリ不足でカーネルがプロセスを kill セグメンテーション違反（SIGSEGV） - バグのあるモジュールや破損したバイナリ 設定ファイルの構文エラー - reload 時に worker が異常終了 worker_connections の上限超過 - 同時接続数がシステム制限を超過 サードパーティモジュールの不具合 - lua-nginx-module など外部モジュールのバグ ファイルディスクリプタ上限 - ulimit -n の設定不足 共有メモリゾーンの枯渇 - proxy_cache や limit_req_zone のサイズ不足 確認手順 ステップ1: nginx エラーログを確認する # デフォルトのエラーログ sudo tail -100 /var/log/nginx/error.log # systemd 経由のログ sudo journalctl -u nginx --since "1 hour ago" --no-pager 🔍 チェックポイント: worker process XXX exited on signal XX の記載を探す ...

症状 ブラウザで「ERR_TOO_MANY_REDIRECTS」「このページは正しくリダイレクトされていません」と表示される 結論：まずこれを確認 curl -I -L URL でリダイレクト先を追跡し、ループしているか確認する nginx設定で同じURLへのrewrite/returnが連鎖していないか確認する SSL終端がnginxより前（ロードバランサー等）にある場合、X-Forwarded-Protoの処理を確認する トラブルシューティングフロー flowchart TD A[リダイレクトループ発生] --> B{curlでループ確認} B -->|ループあり| C{HTTPSリダイレクト関連?} B -->|ループなし| D[ブラウザキャッシュクリア] C -->|Yes| E[SSL終端位置を確認] C -->|No| F{rewrite/returnルール} E --> G[X-Forwarded-Proto確認] F -->|ルールあり| H[条件式を確認] F -->|ルールなし| I[upstreamの設定確認] G --> J[プロキシヘッダー設定を修正] H --> K[重複・矛盾するルールを修正] I --> L[バックエンドのリダイレクトを確認] よくある原因 HTTPからHTTPSへのリダイレクト設定の重複 - nginx側とアプリ側の両方でリダイレクト設定があり、互いに転送し合う ロードバランサー配下でのHTTPSリダイレクト - SSL終端がLB側にあり、nginx側では常にHTTPに見えるため無限ループする rewriteルールの条件不備 - リダイレクト後のURLも同じルールにマッチしてしまう trailing slashの処理 - /pathと/path/を相互にリダイレクトし続ける www有無のリダイレクト設定の矛盾 - www付きと無しで互いにリダイレクトする設定になっている locationブロックの優先順位問題 - 意図しないlocationブロックにマッチしている proxyヘッダーの未設定 - バックエンドが自身のURLを正しく認識できていない 確認手順 ステップ1: リダイレクトチェーンを確認する curl -I -L --max-redirs 10 https://example.com/path 🔍 チェックポイント: Locationヘッダーの遷移を確認し、同じURLが繰り返されていればループ確定 ...

症状 nginxのログファイルが肥大化し続け、ディスク容量が圧迫される。または df -h で /var/log が100%近くになっている。 結論：まずこれを確認 ls -lh /var/log/nginx/ でログファイルのサイズを確認 cat /etc/logrotate.d/nginx でlogrotate設定の存在を確認 systemctl status logrotate または /var/lib/logrotate/status で最終実行日時を確認 トラブルシューティングフロー flowchart TD A[ディスク容量が逼迫] --> B{nginxログが原因?} B -->|No| Z[他のログを確認] B -->|Yes| C{logrotate設定あり?} C -->|No| D[logrotate設定を作成] C -->|Yes| E{logrotateは実行されている?} E -->|No| F[cronまたはtimerを確認] E -->|Yes| G{ログは圧縮・削除されている?} G -->|No| H[postrotateを確認] G -->|Yes| I[rotateの世代数を確認] H --> J[nginx再読み込みを確認] よくある原因 logrotate設定ファイルがない - パッケージインストール時に作成されないケースがある postrotateでnginx再読み込みが失敗 - nginxがログファイルを掴み続け、新しいファイルに書き込まれない logrotateのcron/timerが無効 - systemdのlogrotate.timerが停止している copytruncateとpostrotateの混在 - 設定の矛盾でローテーションが中途半端になる 権限の問題 - ローテーション後のファイルにnginxが書き込めない sharedscriptsの指定漏れ - 複数ログファイルで毎回postrotateが実行されエラーになる ディスクIOが高くローテーション処理がタイムアウト - 大容量ログで処理が完了しない 確認手順 ステップ1: ログファイルのサイズを確認する ls -lh /var/log/nginx/ du -sh /var/log/nginx/ 🔍 チェックポイント: access.logやerror.logが数GB以上ある場合は異常 ...

title: “nginxでindexが効かない・index.htmlが表示されない” date: 2026-01-17 draft: true description: “nginxでindexディレクティブが効かず、ディレクトリアクセスでindex.htmlが表示されない場合の確認手順と対処法” categories: [“runbook”] tags: [“runbook”, “nginx”, “index”, “設定”, “403”, “404”, “ディレクトリ”] 症状 nginxでディレクトリにアクセスしてもindex.htmlが自動で表示されず、403 Forbiddenや404 Not Found、またはディレクトリ一覧が表示される。 結論：まずこれを確認 indexディレクティブが正しいコンテキスト（server/location）に書かれているか 指定したファイル（index.html等）が実際に存在するか nginxがそのファイルを読み取る権限があるか トラブルシューティングフロー flowchart TD A[ディレクトリアクセスで<br>indexが表示されない] --> B{エラーコードは?} B -->|403 Forbidden| C[パーミッション確認へ] B -->|404 Not Found| D[ファイル存在確認へ] B -->|ディレクトリ一覧表示| E[autoindex確認へ] B -->|別ファイルが表示| F[index順序確認へ] C --> G[ステップ3へ] D --> H[ステップ2へ] E --> I[ステップ4へ] F --> J[ステップ1へ] よくある原因 indexディレクティブの記述位置が不適切 - httpコンテキストのみに書いてlocationで上書きされている indexファイルが存在しない - ファイル名のtypoや配置ミス パーミッション不足 - nginxワーカーがファイルを読めない locationブロックでindexが上書きされている - 別のlocationで異なるindex設定がある try_filesとの競合 - try_filesが先にマッチして別の処理になる rootパスの設定ミス - 想定と異なるディレクトリを参照している シンボリックリンクの問題 - リンク先にアクセスできない 確認手順 ステップ1: 現在のindex設定を確認する # nginx設定ファイルでindexディレクティブを検索 grep -rn "index" /etc/nginx/ # 設定の構文チェックと有効な設定を表示 nginx -T 2>/dev/null | grep -A5 "index" 🔍 チェックポイント: index index.html index.htm;のような行が、対象のserver/locationブロック内にあるか確認する ...