Posts

エラーの概要 Kubernetes の 403 エラーは「Forbidden」を意味し、リクエストの認証は成功しているものの、そのリソースに対する操作権限（RBAC: Role-Based Access Control）がないことを示します。Pod の実行、リソースの取得・更新・削除など、特定の操作がセキュリティポリシーにより拒否された状態です。API サーバーやマニフェスト適用時、kubectl コマンド実行時に頻繁に発生します。 実際のエラーメッセージ例 Error from server (Forbidden): pods "my-pod" is forbidden: User "system:serviceaccount:default:app" cannot get resource "pods" in API group "" in the namespace "default" { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "deployments.apps \"nginx\" is forbidden: User \"system:serviceaccount:kube-system:default\" cannot create resource \"deployments\" in API group \"apps\" in the namespace \"kube-system\"", "reason": "Forbidden", "details": { "name": "nginx", "group": "apps", "kind": "deployments" }, "code": 403 } よくある原因と解決手順 原因1: ServiceAccount に適切な Role が割り当てられていない ServiceAccount は Kubernetes 内のアカウントであり、Pod がリソースにアクセスする際に使用されます。このアカウントに必要な権限を持つ Role が紐付けられていない場合、403 エラーが発生します。 ...

エラーの概要 Nginx における 400 エラーは、クライアントから送信されたリクエストが HTTP 仕様に違反していることを示します。リクエストヘッダーの形式が不正、サイズ超過、または URI の不正な文字エンコーディングなどが原因となり、サーバー側で処理できない状態を意味します。本エラーはクライアント側の問題であるため、サーバー設定とリクエスト内容の両面から原因特定が必要です。 実際のエラーメッセージ例 Nginx のアクセスログに記録される 400 エラーの典型的な出力は以下の通りです。 192.168.1.100 - - [15/Nov/2024:10:23:45 +0900] "GET /api/v1/users?name=<invalid_char> HTTP/1.1" 400 157 "-" "Mozilla/5.0" また、Nginx のエラーログには以下のように記録されることがあります。 2024/11/15 10:23:45 [info] 12345#12345: *1 client sent invalid request line: "GET /search?q=あああ HTTP/1.1" よくある原因と解決手順 原因1：リクエストヘッダーサイズの超過 なぜ発生するか Nginx は large_client_header_buffers で設定されたサイズ制限を超えるヘッダーを受け取ると、400 エラーを返します。これはメモリ消費やバッファオーバーフロー攻撃を防ぐための保護機構です。特に Cookie やカスタムヘッダーが多い場合に発生しやすくなります。 Before（デフォルト設定での問題） # Nginx デフォルト設定 # large_client_header_buffers 4 8k; # 4個のバッファ、各8KB # このサイズでクライアントが 32KB 以上のヘッダーを送信するとエラー server { listen 80; server_name example.com; location / { proxy_pass http://backend; } } After（ヘッダーバッファサイズの拡大） ...

冒頭まとめ Nginx の 403 Forbidden は、サーバーがリクエストを理解したうえで、アクセスを拒否したときに返されます。原因はほぼ次の6つのいずれかです。ファイル権限の不足、パスの途中の親ディレクトリに実行権限がない、index ファイルがなく autoindex も無効、設定の deny ルール、SELinux/AppArmor、そして upstream(PHP-FPM など)自身が 403 を返すケースです。調査は、設定をいじる前に、まず /var/log/nginx/error.log を読むことから始めます。ログの文言が、どの原因なのかの手がかりになります。 エラーの概要 403 Forbidden は、Nginx がリクエスト自体は正しく受け取り、対象のリソースの場所も分かっているが、アクセスを拒否した状態です。認証情報が足りない 401 Unauthorized とは異なり、再認証しても解決しません。リソースが存在しない 404 Not Found とも異なります。 この違いはエラーログで明確に区別できます。404 はログに No such file or directory と記録され、403 は Permission denied や is forbidden と記録されます。アクセスログは「403 が起きた」ことだけを示し、なぜ起きたかはエラーログが示します。したがって、403 の調査は設定ファイルをいじる前に、まずエラーログを読むことから始めます。 まず最初に：エラーログを読む 原因を切り分ける前に、エラーログの該当行を確認します。 # 直近のエラーを表示 sudo tail -50 /var/log/nginx/error.log # 権限・拒否に関する行だけを抽出 sudo grep -iE "permission denied|forbidden|denied" /var/log/nginx/error.log ログの文言と原因の対応は次のとおりです。 # ファイルまたは親ディレクトリの権限不足 open() "/var/www/html/index.html" failed (13: Permission denied) # index ファイルがなく autoindex も無効 directory index of "/var/www/html/" is forbidden # upstream への接続が拒否された（SELinux でソケット接続が遮られた例） connect() to 127.0.0.1:8080 failed (13: Permission denied) while connecting to upstream この文言で、おおよその原因の見当がつきます。以下、6つの原因を、切り分けるべき順に説明します。 ...

冒頭まとめ Nginx の 404 Not Found は、リクエストされたリソースが見つからないときに返されます。原因はほぼ次の5つのいずれかです。root のパスが実際のファイル配置と合っていない、alias の末尾スラッシュの不一致でパス結合がずれている、try_files の誤設定、意図しない location ブロックがリクエストを処理している、そして proxy_pass 先のアプリケーション自身が 404 を返しているケースです。調査の分かれ道はエラーログです。/var/log/nginx/error.log に No such file or directory の行があれば Nginx 自身のパス解決の問題(原因1〜3)、なければ振り分けか上流の問題(原因4〜5)を疑います。 エラーの概要 404 Not Found は、サーバーがリクエストを受け取ったものの、対応するリソースを見つけられなかった状態です。アクセス自体を拒否された 403 Forbidden とは異なります。この2つはエラーログの文言で区別できます。404 は open() の失敗として (2: No such file or directory) と記録され、403 は (13: Permission denied) や is forbidden と記録されます。ファイルが実在しても読み取り権限がなければ、返るのは 404 ではなく 403 です。 Nginx が自身の既定ページで 404 を返す場合、ブラウザには「404 Not Found」という見出しと nginx の署名だけが表示されます。もし「The requested URL /xxx was not found on this server.」のような説明文が表示されているなら、それは Nginx の既定ページの文言ではありません。上流の別のサーバーやアプリケーションが生成した 404 をそのまま中継している可能性が高く、これ自体が切り分けの手がかりになります(原因5)。 ...

エラーの概要 AWSの409（Conflict）エラーは、リクエストの内容がAWSリソースの現在の状態と競合していることを示します。このエラーはS3、EC2、DynamoDB、CloudFormation、IAMなど複数のAWSサービスで発生し、リソースが完了していない状態遷移中であったり、既に同じ名前のリソースが存在していたりするときに返されます。一時的な問題か永続的な設定ミスかを判別することが解決の第一歩となります。 実際のエラーメッセージ例 S3バケット作成時: { "Error": { "Code": "BucketAlreadyExists", "Message": "The requested bucket name is not available. The bucket namespace is shared by all AWS accounts." }, "ResponseMetadata": { "HTTPStatusCode": 409 } } EC2インスタンス操作時: { "Error": { "Code": "InvalidInstanceID.Transitional", "Message": "The instance ID 'i-1234567890abcdef0' is in a transitional state and cannot be modified at this time." }, "ResponseMetadata": { "HTTPStatusCode": 409 } } DynamoDBテーブル操作時: { "Error": { "Code": "ResourceInUseException", "Message": "Cannot update a table while an update is in progress" }, "ResponseMetadata": { "HTTPStatusCode": 409 } } よくある原因と解決手順 原因1：S3バケット名がグローバルに重複している S3のバケット名はAWS全体で一意である必要があります。既に別のAWSアカウントが使用しているバケット名を指定すると409エラーが発生します。 ...

エラーの概要 AWS における 422 Unprocessable Entity は、HTTP リクエストの形式は正しいが、含まれるデータが処理不可能または検証に失敗したことを示します。CloudFormation、API Gateway、Lambda、EventBridge、DynamoDB など複数のAWSサービスで発生する可能性があります。このエラーが返されるのは、リクエストの構文は valid だが、ビジネスロジックレベルでの矛盾や制約違反があるためです。 実際のエラーメッセージ例 CloudFormation で展開時に発生する 422 エラー: { "message": "Template error: instance of Fn::GetAtt references undefined resource", "code": "ValidationError", "statusCode": 422 } API Gateway を経由した Lambda 呼び出しでのエラーレスポンス: { "message": "Invalid request body: required field 'userId' is missing", "errorType": "UnprocessableEntity", "statusCode": 422 } よくある原因と解決手順 原因1: CloudFormation テンプレートのリソース参照ミス CloudFormation スタックをデプロイする際、テンプレート内で存在しないリソースを参照している場合に 422 が返されます。Fn::GetAtt や Ref を使用してリソース間の依存関係を記述しているとき、参照先のリソース名が誤っていたり、そのリソースが定義されていなかったりすることが原因です。 Before（エラーが発生する例）: Resources: MyLambdaRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole MyLambda: Type: AWS::Lambda::Function Properties: Runtime: python3.11 Handler: index.handler Role: !GetAtt NonExistentRole.Arn Code: ZipFile: | def handler(event, context): return 'Hello' After（修正後）: ...

冒頭まとめ AWS の 504 Gateway Timeout は、リクエストを中継するコンポーネントが、その先からの応答を待ちきれずに打ち切ったことを示します。対処を決めるのは「どの中継役の、どのタイマーで時間切れになったか」です。代表的な発生源は3つです。第一に Application Load Balancer（ALB）で、ターゲットへの接続確立が10秒の接続タイムアウト内に完了しない場合（経路の遮断が典型）と、接続後の応答が idle timeout（既定60秒）内に返らない場合（遅い処理が典型）があります。第二に Classic Load Balancer で、応答が idle timeout を超える場合と、バックエンドの keep-alive が先に切れて接続が閉じられる場合です。第三に API Gateway で、統合タイムアウト（既定29秒）内にバックエンドが応答しない場合に、Endpoint request timed out という504が返ります。 504 は「待った末の時間切れ」であり、接続自体の失敗や不正な応答（502）、ターゲットの未登録（503）とは原因の場所が異なります。まずどのタイマーかを特定し、遅い側を速くするか、待つ側の設定を実態に合わせるかを判断します。 エラーの概要 504 を最初に受け取ったとき、502 との違いを押さえておくと迷いません。502 は「相手から不正な応答を受け取った、または接続に失敗した」、504 は「応答を待ったが時間内に届かなかった」です。同じ「バックエンドの問題」でも、502 は接続や応答の形式、504 は時間が争点になります。 ALB では、504 の記録の形に特徴があります。実際の調査記録に共通するのは、アクセスログで elb_status_code が 504、target_processing_time と response_processing_time が -1、target_status_code が -（空）という形です。これは、ALB がターゲットからの応答を一度も受け取れないままタイムアウトで接続を閉じたことを意味します。API Gateway の場合は、応答本文そのものが手がかりです。 { "message": "Endpoint request timed out" } まず最初に：どのタイマーで時間切れになったかを特定する 発生源ごとに、見るべき記録が決まっています。 ALB 経由なら、CloudWatch の HTTPCode_ELB_504_Count（ALB が生成した504）を確認し、あわせて TargetConnectionErrorCount（接続確立の失敗）と TargetResponseTime（ターゲットの応答時間）を見ます。接続エラーが増えていれば経路の問題（原因1の接続確立側）、応答時間が idle timeout に張り付いていれば処理の遅さ（原因1の応答待ち側）です。 ...

エラーの概要 AWS の HTTP 400 エラーは「Bad Request（不正なリクエスト）」を意味し、AWS API に送信されたリクエストに構文的な誤りや不正なパラメータが含まれている場合に返されます。AWS では API Gateway、S3、DynamoDB、Lambda、IAM など複数のサービスで発生する可能性があり、クライアント側の設定ミスやリクエスト形式の誤りが主な原因となります。 実際のエラーメッセージ例 AWS SDK を使用した場合、以下のようなエラーが出力されます。 { "Error": { "Code": "BadRequest", "Message": "1 validation error detected: Value null at 'instanceIds' failed to satisfy constraint: Member must not be null" } } AWS CLI での例： $ aws s3api put-object --bucket <your-bucket-name> --key test.txt An error occurred (InvalidArgument) when calling the PutObject operation: The authorization header is malformed; the Credential is mal-formed; expecting 'AWS4-HMAC-SHA256 Credential=...' よくある原因と解決手順 原因1：必須パラメータの欠落またはデータ型の誤り なぜ発生するか AWS API は厳密なパラメータ検証を行います。必須パラメータが指定されていない、または文字列型で数値を渡すなどデータ型が異なる場合、400 エラーが返されます。特に DynamoDB や EC2 API では顕著です。 ...

エラーの概要 AWSで401エラーが返される場合、リクエストに含まれる認証情報が無効であることを示しています。AWS API、SDK、CLIのいずれかを使用する際に、アクセスキー、シークレットアクセスキー、セッショントークン、またはIAMロールの認証情報が不正または期限切れの状態で送信されると発生します。このエラーは認証層での問題であり、比較的簡単に解決できるケースがほとんどです。 実際のエラーメッセージ例 AWS CLIを使用した場合： $ aws s3 ls An error occurred (InvalidAccessKeyId.NotFound) when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records. AWS SDK（Python）でのJSONレスポンス例： { "Error": { "Code": "UnrecognizedClientException", "Message": "The security token included in the request is invalid" } } API Gateway経由での呼び出しでのエラー： HTTP/1.1 401 Unauthorized { "message": "Unauthorized" } よくある原因と解決手順 原因1：アクセスキーが無効または存在しない AWS IAMユーザーのアクセスキーが削除されたり、誤入力されたりしている場合に発生します。特に手動で環境変数やConfigファイルに設定した場合は打ち間違いが多いです。 Before（エラーが起きるコマンド）： export AWS_ACCESS_KEY_ID="<your-access-key-id>" export AWS_SECRET_ACCESS_KEY="<your-secret-access-key>" aws ec2 describe-instances After（修正後）： # IAMコンソールで現在のアクセスキーを確認 # または新しいアクセスキーを生成してから設定 export AWS_ACCESS_KEY_ID="<your-access-key-id>" export AWS_SECRET_ACCESS_KEY="<your-secret-access-key>" aws ec2 describe-instances 確認手順は以下の通りです。AWSマネジメントコンソールでIAM→ユーザー→セキュリティ認証情報タブを開き、アクセスキーが有効（Active）な状態であることを確認してください。無効な場合は新しいアクセスキーを生成する必要があります。 ...

エラーの概要 AWS の 403 エラーは、HTTP ステータスコード 403 Forbidden として返されます。これは認証には成功したものの、実行しようとしている操作に対する IAM (Identity and Access Management) 権限が不足していることを意味します。AWS リソースへのアクセス、API 呼び出し、AWS マネジメントコンソール上での操作など、様々な場面で発生する一般的なエラーです。 実際のエラーメッセージ例 AWS CLI でよく見かける 403 エラーレスポンスを示します。 { "Error": { "Code": "AccessDenied", "Message": "User: arn:aws:iam::123456789012:user/john-dev is not authorized to perform: s3:GetObject on resource: arn:aws:s3:::my-bucket/config.json" } } また、AWS マネジメントコンソール上では、より簡潔なエラーが表示されることもあります。 User: arn:aws:iam::123456789012:user/jane-admin is not authorized to perform: ec2:DescribeInstances on resource: * よくある原因と解決手順 原因 1：IAM ポリシーに必要な Action が含まれていない IAM ポリシーに、実行したい操作（Action）が明示的に許可されていない場合、403 エラーが発生します。例えば S3 バケットから読み取りはできるが、アップロード（PutObject）が許可されていない状況が典型的です。 Before（エラーが起きる IAM ポリシー）： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::my-bucket/*" } ] } このポリシーでは GetObject（読み取り）のみが許可されているため、PutObject でアップロードしようとするとアクセス拒否されます。 ...