症状
health check が 500 になる
初学者、運用オンボーディング、API の初動対応に慣れたい人向け
API が 500 を返し、ログに接続エラーが出ているのに、原因がコードではなく設定にあるケースを切り分けるための入口です。
想定検索意図
環境変数 ミス 500 エラー api 起動しない
向いている人
初学者、運用オンボーディング、API の初動対応に慣れたい人向け
おすすめの進め方
症状を読む → 確認ポイントを押さえる → 関連シナリオで実際に手を動かす、の順で進めるのが最短です。
まずは自分の困り方がこのテーマに合っているかを確認します。
health check が 500 になる
ログに DB_HOST や接続先まわりのエラーが出る
アプリ自体は起動しているように見えるが、内部で初期化に失敗している
上から順に見ていくと切り分けが進みます。 途中で原因が分かればそこで止めて構いません。
後ろの大量のスタックトレースではなく、最初に出たエラーを見る。 undefined や missing なら値そのものが読めていない。 getaddrinfo ENOTFOUND ならホスト名の綴りが違う (名前解決に失敗している)。 ECONNREFUSED ならホストには届いていてポートで拒否されているので、 ホスト名ではなくポート番号か起動状態を疑う。 この 3 つで原因の見当がほぼ付く。
ファイルを直したこと と プロセスに反映されたこと は別。 多くのランタイムは起動時に一度だけ環境変数を読むので、 .env を直しても再起動しなければ古い値のまま動き続ける。 まず 「いま動いているプロセスがどの値を持っているか」 を出して確かめる。
DB_HOST と DATABASE_HOST のような別名、 大文字小文字の違い、 末尾の空白が典型。 値をクォートで囲むと、 囲んだ記号ごと値として読まれる環境もある。 コード側が参照している名前と、 設定ファイル側の名前を並べて見るのが確実。
開発では既定値にフォールバックしていて、 本番でその既定値が使えず初めて露見する形が多い。 「開発で動くから設定は正しい」 とは言えない。 環境ごとに どのキーが定義されているかの一覧を比べる。
設定を直した時点では何も直っていない。 再起動して、 health check が 200 を返すところまで見て初めて復旧。 ここを省くと 「直したつもり」 のまま障害が続く。
読んで終わらせず、そのまま手を動かせるシナリオに絞っています。