500 エラーの記事一覧

冒頭まとめ OpenAI API の 500 は、公式のエラー一覧で提供側の問題と明記されています。文言は要求の処理中にサーバー側で問題が起きた、という趣旨で、示されている対処は「短い待機のうえで再試行し、続く場合は問い合わせる」ことです。あわせて稼働状況の確認も案内されています。 つまり、送った内容を直しても直りません。400 番台とは調べる方向が正反対です。 そのうえで、実務的に最初に確認すべきことがあります。何回送られたかです。公式のソフトウェア開発キットは、接続の問題、408、409、429、そして 500 番台を既定で2回自動的に再試行します。したがって、手元のログに1回しか記録されていなくても、実際には3回送られたうえで諦めた状態です。 この前提を知らないと、対処を二重に積むことになります。自作の再試行を足せば、待ち時間も送信回数も掛け算で増えます。 なお、code が null で type が server_error の形が典型ですが、応答が JSON ですらない場合もあります。その場合は API の層が返したものではありません。 エラーの概要 典型的な応答です。 { "error": { "message": "The server had an error while processing your request. Sorry about that!", "type": "server_error", "param": null, "code": null } } param も code も null です。指し示せる場所が無いということで、これ自体が「利用者側の問題ではない」ことの表れです。400 番台では param や code に手がかりが入るのと対照的です。 開発キットからは InternalServerError として現れます。公式の対応表では、状態コードが 500 以上のものがこの区分にまとめられています。 一方、サーバーから応答が返る前に失敗した場合は、区分自体が変わります。接続できなかった場合と時間切れの場合は、状態コードを持たない別の区分です。500 が返っているなら、少なくとも要求は届いています。 まず最初に：本当に 500 か、何回送られたかを確定する 第一に、本文が JSON かを見ます。HTML が返っていれば API の層ではなく前段の仕組みが返しています。 ...

エラーの概要 GitLabの500エラーは、GitLabサーバー側で予期しない内部エラーが発生したことを示します。クライアント側の問題ではなく、GitLabのインフラストラクチャまたはアプリケーションレイヤーで何らかの処理に失敗した状態です。このエラーが発生すると、リポジトリーへのアクセス、プッシュ、マージリクエストの操作など、あらゆるGitLab機能が一時的に利用できなくなります。 実際のエラーメッセージ例 ブラウザでGitLabにアクセスした際の表示： 500 Internal Server Error An internal server error occurred. GitLab APIを呼び出した際のレスポンス： { "message": "500 Internal Server Error", "status": 500 } ターミナルからgit操作を実行した際のエラー： $ git push origin main fatal: unable to access 'https://gitlab.example.com/project.git/': The requested URL returned error: 500 よくある原因と解決手順 原因1：GitLabインフラの一時的な障害 GitLabのサーバーインフラストラクチャ側で一時的な障害が発生している場合、リクエストを処理できず500エラーが返却されます。これはデータベース接続の喪失、メモリ不足、ディスク容量の枯渇、または主要サービス（Sidekiq、Puma等）のクラッシュなど、複数の要因が考えられます。 解決手順： # まずstatus.gitlab.comで障害状況を確認する curl -s https://status.gitlab.com/api/v2/status.json | jq '.status' # WebUIで直接確認することもできる # https://status.gitlab.com にアクセスして「All Systems Operational」を確認 # 数分待機してから再試行する sleep 300 git push origin main GitLabの障害情報は status.gitlab.com で公開されています。ここで「All Systems Operational」と表示されていれば、インフラレベルの障害ではなく、個別リポジトリーやアカウント固有の問題である可能性が高くなります。 原因2：リポジトリのGitオブジェクト破損 GitLab内のリポジトリーが保存されているディスク上のGitオブジェクトが破損した場合、リポジトリーの読み書き処理で500エラーが発生します。これはハードウェア障害、不正なシャットダウン、ファイルシステムエラーなどに起因することがあります。 解決手順： ...

エラーの概要 Docker Compose の 500 エラーは、Docker Compose 自体またはそれが管理するコンテナー内で内部エラーが発生したことを示します。このエラーは通常、コンテナー起動時のアプリケーションクラッシュ、エントリポイント実行の失敗、またはヘルスチェック機構の不具合によって引き起こされます。対象のサービスが正常に起動・稼働できない状態を意味しており、迅速な原因特定と対応が必要です。 実際のエラーメッセージ例 Docker Compose でコンテナーが起動に失敗した際の典型的なエラー出力は以下の通りです。 ERROR: for <service-name> Cannot start service <service-name>: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "<command>": executable file not found in $PATH: unknown または、ヘルスチェック失敗時は以下のように表示されます。 <service-name> | ERROR: Health check failed. Retrying... <service-name> | (Exit status: 1) アプリケーション実行時のエラーログは以下のようなパターンです。 docker-compose logs <service-name> <service-name> | Traceback (most recent call last): <service-name> | File "/app/main.py", line 15, in <module> <service-name> | raise Exception("Database connection failed") <service-name> | Exception: Database connection failed よくある原因と解決手順 原因1：サービスのコンテナー内部でアプリケーションがクラッシュしている コンテナー起動後、アプリケーションが異常終了またはランタイムエラーで落ちてしまう状況です。これは依存関係の欠落、設定ファイルの不在、メモリ不足、または不正な初期化処理によって発生します。 ...

冒頭まとめ GCP の 500 Internal Server Error は、1つの意味を持つエラーではありません。エラー区分の定義ファイルを見ると、500 に対応する区分は3つあります。 1つ目は内部のエラーです。定義には、下層の系が前提としていた不変の条件が破られたことを意味し、この区分は深刻なエラーのために予約されている、と書かれています。 2つ目は不明なエラーです。定義では、別の空間から受け取った状態がこちらでは未知のエラーに属する場合や、十分なエラー情報を返さない窓口からのエラーが、この区分に変換されることがある、と説明されています。つまり「原因が分からない」ではなく「原因を伝える経路で情報が落ちた」という意味です。 3つ目は回復不能なデータの損失または破損です。説明はこの一文だけですが、意味は重大です。 この3つで、次にやることが変わります。3つ目が返っているなら、再試行してはいけません。同じ操作を繰り返すより、何が失われたかを確認するのが先です。 残る2つについては、再試行が公式に認められています。運用側の公式文書は、指数的に間隔を伸ばしランダム性を加える再試行を勧めており、500 や 503 のサーバー側のエラーでは最初の間隔を最短1秒としています。503 との違いは、定義の側にあります。503 の定義には、一時的な状態である可能性が高く再試行で解消できると書かれているのに対し、500 の定義にはそうした見込みが書かれていません。直る保証の有無が違うだけで、再試行が禁じられているわけではない、と押さえてください（GCP の 503 の記事）。 エラーの概要 応答の形は他のエラーと共通で、status に区分名が入ります。 { "error": { "code": 500, "message": "Internal error encountered.", "status": "INTERNAL" } } status の値が INTERNAL、UNKNOWN、DATA_LOSS のいずれかで、意味が変わります。message は多くの場合、内部でエラーが起きたという趣旨の短い文言だけで、それ以上の手がかりはありません。 details に識別子が入っていれば、そこから判断できる場合があります。設計の指針では、すべてのエラー応答が機械が読める識別子を含むべきとされています。ただし 500 の場合、内部の事情を外に出さない方針から、詳細が乏しいことが実際には多くあります。 そのため、このエラーは他と違って、応答だけで原因に辿り着けないのが普通です。調査は記録の側に移ります。 まず最初に：status を読み、再現するかを見る 第一に、status の値を読みます。DATA_LOSS であれば、再試行の前にデータの状態を確認します。他の2つであれば、次に進みます。 第二に、同じ操作が再現するかを確かめます。1回だけであれば一時的なものです。繰り返し同じ場所で起きるなら、要求の内容に何か引き金があります。 第三に、他の操作でも起きているかを見ます。特定の操作だけなら要求側、幅広い操作で起きているなら提供側の問題である可能性が高くなります。 第四に、稼働状況の表示を確認します。ただし、表示が正常でも特定の機能だけが不調なことはあるので、表示だけを根拠に自分側の問題と決めつけないでください。 よくある原因と解決手順 原因1：一時的なもので、再試行で通る 最も多い形です。同じ要求が2回目には通ります。公式の指針では、間隔を指数的に伸ばしてランダム性を加え、最初の間隔は最短1秒です（429 の最短30秒とは扱いが違います。GCP の 429 の記事）。 ただし、再試行してよいかどうかは操作の種類によります。区分の定義には、503 について、同じ結果になるとは限らない操作の再試行が常に安全とは限らない、という注意が添えられています。同じ注意が 500 にも当てはまります。 Before（結果が変わりうる操作を無条件で再送する）： for i in range(3): r = create_resource() # 作成の操作 if r.ok: break time.sleep(2 ** i) # → 1回目が内部で成功していた場合、二重に作られる After（作成の操作は、実物を確認してから判断する）： ...

エラーの概要 Kubernetes環境で500エラーが発生した場合、APIサーバーまたはコントロールプレーンコンポーネントで予期しない内部エラーが生じています。このエラーはクラスタ全体の管理機能に影響を与える可能性があり、迅速な対応が必要です。500エラーが返される場合、リソースの作成・更新・削除やクラスタ情報の取得が失敗することになります。 実際のエラーメッセージ例 $ kubectl apply -f deployment.yaml Error from server (InternalError): error when creating "deployment.yaml": Internal error occurred: <unknown> { "apiVersion": "v1", "kind": "Status", "metadata": {}, "status": "Failure", "message": "Internal error occurred: etcd server failed", "reason": "InternalError", "code": 500 } よくある原因と解決手順 1. etcdデータベースの障害 なぜ発生するか：etcdはKubernetesクラスタの状態を保持する分散キー・バリューストアです。etcdが応答しない、ディスク満杯、または不整合が発生するとAPIサーバーは500エラーを返します。 Before（エラーが起きる状態）： $ kubectl get nodes Error from server (InternalError): Internal error occurred: etcd server failed After（解決手順）： # 1. etcdのヘルスチェック実行 kubectl exec -it etcd-<master-node-name> -n kube-system -- etcdctl endpoint health # 2. etcdメンバーの状態確認 kubectl exec -it etcd-<master-node-name> -n kube-system -- etcdctl member list # 3. etcdポッドを再起動（自動復旧を待つ） kubectl delete pod etcd-<master-node-name> -n kube-system # 4. APIサーバーのログを確認 kubectl logs -n kube-system -l component=kube-apiserver --tail=100 2. APIサーバーのメモリ不足またはクラッシュ なぜ発生するか：APIサーバーはクラスタのすべてのリソース定義をメモリに保持しています。大規模クラスタやメモリ制限が厳しい環境では、メモリ不足（OOM）によりプロセスがクラッシュし500エラーが多発します。 ...

エラーの概要 AWS における 500 Internal Server Error は、クライアント側のリクエストに問題はないにもかかわらず、AWS サービス側で予期しない障害が発生したことを示します。Lambda 関数の未処理例外やタイムアウト、API Gateway の統合エラー、CloudFormation のスタック操作失敗など、複数のサービスにまたがって発生しうるサーバーサイドの障害です。一時的な AWS 基盤の不具合である場合もありますが、大半はアプリケーションコードや設定の問題に起因します。 実際のエラーメッセージ例 API Gateway 経由での呼び出し時： { "message": "Internal server error", "statusCode": 500 } Lambda の CloudWatch Logs に出力されるスタックトレース： [ERROR] Runtime.UnhandledPromiseRejection: Error: connect ETIMEDOUT 10.0.1.5:5432 Traceback (most recent call last): File "/var/task/handler.py", line 14, in handler result = db.query(sql) TimeoutError: Connection timed out after 3000ms CloudFormation スタック操作失敗時： Resource handler returned message: "Internal Server Error" (RequestToken: ..., HandlerErrorCode: InternalFailure) よくある原因と解決手順 原因1：Lambda 関数の未処理例外 Lambda がエラーをキャッチせずに例外をスローすると、API Gateway は 500 を返します。エラーハンドリングを実装して例外を適切に処理します。 ...

冒頭まとめ Azure の 500 Internal Server Error は、まず「どの URL が返したか」で2系統に分けると迷いません。第一に、Azure の管理 API（management.azure.com への操作）や各サービスの API が返す500で、エラー応答の code は InternalServerError などになります。これは Azure 側の予期しない内部エラーで、手元のリクエストを直して消えるものではありません。Azure の公式 SDK は、408・429・500・502・503・504 を既定の再試行対象とし、既定で合計10回まで再試行する設計になっており（Python 版 SDK の共通基盤 azure-core のソースコードで確認できます）、SDK 経由で500がエラーとして見えた時点で、この再試行はすでに尽きています。第二に、自分がデプロイしたアプリ（App Service）の URL が返す500です。こちらは Azure 側の障害ではなくアプリの調査で、ASP.NET Core の場合は 500.30 のようなサブステータスが失敗の種類まで教えてくれます。 500だと思い込みやすいのに500ではないエラーも先に押さえます。リソースプロバイダーの未登録は、公式トラブルシューティング文書のある MissingSubscriptionRegistration で、実際の応答は 409 Conflict です。クォータやスロットリングは 429 系、テンプレートやパラメータの不正は 400 系の検証エラー、権限不足は 403 の AuthorizationFailed です。「プロバイダー未登録で500」「クォータ超過で500」という説明は Azure の実際の応答と一致しません。 エラーの概要 Azure の管理 API のエラーは、error オブジェクト（code と message）を持つ JSON で返ります。500の場合の code は InternalServerError などで、message は一時的なエラーである旨と再試行の案内になっているのが典型です。切り分けでまず読むべきは HTTP のコードではなく、この code フィールドです。MissingSubscriptionRegistration や AuthorizationFailed のような具体的な code が入っているなら、それは500の調査ではありません。 もう1つ、Azure の応答には必ず控えるべきヘッダーがあります。x-ms-request-id と x-ms-correlation-request-id です（実際のエラー応答の記録でも、この2つのヘッダーが含まれていることが確認できます）。この値は Azure 側のログでリクエストを特定する参照 ID で、500が再現・継続する場合にサポートへ渡す情報の中核になります。 ...

冒頭まとめ Docker で 500 Internal Server Error が出たときは、どこが500を返したかを最初に見極めます。原因はほぼ次の3系統のいずれかです。第一に、Windows の Docker Desktop でエンジンが起動していない状態です。この場合「request returned Internal Server Error for API route and version …」という形式のメッセージになります。第二に、docker pull や docker push の相手であるレジストリ（イメージの配布サーバー）側の障害です。この場合「received unexpected HTTP status: 500 Internal Server Error」という形式になります。第三に、Docker デーモン自身の内部エラーで、この場合はメッセージに具体的な原因（ディスク不足など）が含まれるのが普通です。 なお、デーモンが停止しているだけなら500にはなりません。その場合は「Cannot connect to the Docker daemon … Is the docker daemon running?」という接続エラーになります。500は「相手まで届いたうえで、相手が内部エラーを返した」ことを示すコードです。 エラーの概要 Docker のコマンド（docker ps、docker run など）は、裏側で Docker デーモンの API に HTTP リクエストを送って動いています。500 Internal Server Error は、その応答としてサーバー側（デーモン、その手前の中継役、またはレジストリ）が「内部でエラーが起きた」と返してきたことを意味します。 このため、500が出たという事実は「相手までリクエストが届いた」ことの証拠でもあります。デーモンのプロセスが停止している、ソケットファイルにアクセスできない、といった場合は HTTP の応答自体を受け取れないので、500ではなく Cannot connect to the Docker daemon という別のエラーになります。500の調査でデーモンの死活だけを疑うと原因を取り違えるので、まずエラーメッセージの文言全体を読みます。 まず最初に：エラーメッセージの全体を読む 500エラーの文言は、発生源ごとに形式が決まっています。手元のメッセージと突き合わせてください。 「request returned Internal Server Error for API route and version http:////./pipe/docker_engine/…」という形式で、経路に docker_engine という文字が見えるなら、Windows の Docker Desktop の経路で発生しています（原因1）。 ...

冒頭まとめ GitHub API の 500 Internal Server Error は、リクエストの綴りや認証の問題ではなく、GitHub 側の内部で予期しないエラーが起きたことを示すコードです。クライアント側に起因する問題には別のコードが割り当てられており（トークンの不備は 401、レート制限は 403 または 429、不存在や権限不足は 404、入力の検証エラーは 422）、これらが500として返ることはありません。原因は2系統に整理できます。第一に、GitHub 側の一時的な障害や内部エラーで、散発的に発生し、同じリクエストをやり直すと通ります。大半はこちらです。第二に、特定のリクエストが GitHub 側の不具合を毎回踏んでいるケースで、同じ呼び出しだけが何度でも500になります。 対処もこの2系統で決まります。散発なら、稼働状況の確認と、間隔を空けた再試行です。再現するなら、リクエストを最小化して引き金を特定し、応答に必ず含まれる x-github-request-id を添えて報告します。手元のコードの修正で500が直るのは、この引き金を特定して回避できた場合に限られます。500の調査は「散発か、再現か」の見極めから始めます。 エラーの概要 GitHub の API は、クライアント側で対処すべき問題を 4xx 系の各コードに割り当てる設計です。500 は、その割り当てのどれにも該当しない「GitHub 内部の予期しない失敗」を意味します。応答から得られる手がかりは多くありませんが、1つだけ確実なものがあります。GitHub API のすべての応答には x-github-request-id ヘッダーが含まれます（実測で確認できます）。 $ curl -sI https://api.github.com/repos/<owner>/<repo> | grep -i x-github-request-id x-github-request-id: C005:2D15D8:A1B83BD:2375C5CD:6A57385F この値は、GitHub 側のログでそのリクエストを一意に特定するための参照 ID です。500が続く場合の報告と調査の起点になるため、失敗した応答のこのヘッダーを控えておきます。GraphQL API では、参照 ID がエラーメッセージの本文中に埋め込まれて返ることがあり、その扱いは GitHub API の 502 の記事で説明したものと同じです。 まず最初に：散発か再現かを見極める 500を受け取ったら、コードを変更する前に次の3点を確認します。 第一に、GitHub の稼働状況ページ（https://www.githubstatus.com）を確認します。API のインシデントが進行中なら、原因は自分のリクエストではありません（原因1）。掲載が遅れることもあるため、掲載がないことは障害でないことの証明にはなりません。 第二に、同じリクエストを1回だけ再実行します。通れば散発（原因1）、また500なら再現（原因2）の疑いです。ただし作成・更新・削除の操作は、応答が届かなかっただけで処理自体は完了している可能性を排除できないため、再実行の前に対象（Issue やコメントなど）が実際に作られていないかを確認し、二重実行を避けてください。 第三に、失敗した応答の x-github-request-id と発生時刻を控えます。 よくある原因と解決手順 原因1：GitHub 側の一時的な障害・内部エラー GitHub 側のインフラに問題が起きている間は、正しいリクエストでも500が返ります。稼働状況ページに該当のインシデントが掲載されていれば、手元での対処はなく、復旧を待って再試行します。短時間に散発的な500が集中する場合も、まずこの系統を疑います。 再試行の設計には、GitHub 公式の Octokit の retry プラグインの線引きがそのまま使えます。公式の説明のとおり、このプラグインは500を含むサーバー側エラーを再試行の対象とし（500応答なら最大3回）、400・401・403・404・410・422・451 は再試行しません。つまり GitHub 公式のツールにおいても、500は「待ってやり直す価値があるコード」、上記の 4xx は「やり直しても結果が変わらないコード」という扱いです。自前で再試行を書く場合もこの線引きに従います。 ...

冒頭まとめ Nginx が返す 500 Internal Server Error には、出どころが2つあります。Nginx 自身が処理を続けられずに生成したものと、上流のアプリケーションが返した 500 をそのまま中継しただけのものです。この2つは対処が完全に別なので、最初に切り分ける必要があります。 見分け方は単純です。Nginx 自身が生成した場合、error.log に必ず理由を書いた行が出ます。中継しただけの場合、access.log には 500 が記録されますが、error.log に Nginx 発の行は出ません。つまり、ログを2つ並べて、同じ時刻に対応する行があるかどうかを見れば、責任の所在はその場で決まります。 先に否定しておくべき筋が1つあります。上流への接続が失敗した場合や、上流の応答が遅れて打ち切られた場合は 500 になりません。Nginx のソースでは、接続の失敗は 502 Bad Gateway、時間切れは 504 Gateway Timeout として確定されます。connect() failed (111: Connection refused) の行を見て 500 の原因だと考えるのは、この分岐と食い違います。502 と 504 の調べ方はそれぞれ別記事にあります（Nginx の 502 の記事、504 の記事）。 Nginx 自身が 500 を生成する場面で最も多いのは、内部リダイレクトの循環です。Nginx は1つのリクエストの中で内部的に転送できる回数を10回と定めており、これを使い切ると循環とみなして 500 を返します。この上限は NGX_HTTP_MAX_URI_CHANGES として定義されています。 エラーの概要 利用者側に表示されるのは、次の定型の応答です。この画面だけでは、Nginx 発かアプリケーション発かは判別できません。 <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>nginx/1.28.0</center> </body> </html> 判別の材料は error.log です。内部リダイレクトの循環なら、次のいずれかの形で記録されます。 ...