Object Storage Service:HTTP 400 エラー

原因：クロスリージョンレプリケーション (CRR) 構成で指定されたターゲットリージョンが存在しません。

解決策：ターゲットバケットのリージョンが有効であることを確認します。

原因：クロスオリジンリクエストのプリフライトリクエストに Origin リクエストヘッダーがありません。

解決策：クロスオリジンリクエストを送信する前に、ブラウザはプリフライトリクエスト (OPTIONS) を OSS に送信します。このリクエストには、クロスオリジンリクエストのソースドメインを識別するための Origin ヘッダーを含める必要があります。これにより、オリジン間リソース共有 (CORS) ポリシーが正しく照合されるようになります。

原因：クロスオリジンリクエストのプリフライトリクエストに Access-Control-Request-Method リクエストヘッダーがありません。

解決策：クロスオリジンリクエストを送信する前に、ブラウザはプリフライトリクエスト (OPTIONS) を OSS に送信します。このリクエストには、実際のリクエストで使用される HTTP メソッドを識別するための Access-Control-Request-Method ヘッダーを含める必要があります。これにより、OSS はそのメソッドが許可されているかどうかを検証できます。

原因：ソースバケットとターゲットバケットの間には、既に CRR 関係が存在します。

解決策：新しい CRR ルールを構成するには、まず既存の CRR ルールを削除する必要があります。

原因：バケットに構成された CORS ルールの数が制限を超えています。

解決策：1 つのバケットには最大 10 個の CORS ルールを設定できます。この制限を超えると、クロスオリジンアクセスポリシーが複雑になりすぎる可能性があります。類似のクロスオリジン構成をマージするか、不要なルールを削除できます。詳細については、「PutBucketCors」をご参照ください。

原因：バケット内のオブジェクト数が、日次のマニフェストファイルエクスポートの制限を超えています。

解決策：マニフェストファイルを日次でエクスポートする場合、バケット内のオブジェクト数は 100 億未満である必要があります。

バケット内のオブジェクト数が 100 億以上の場合は、代わりにマニフェストファイルを週次でエクスポートしてください。

原因：アップロードされたオブジェクトのサイズが許可される最大サイズを超えています。

解決策: PostObject 操作を使用してファイルをアップロードする場合は、PostPolicy のフォームフィールドに有効な値を設定します。content-length-range 条件を使用して、アップロードするオブジェクトの許容サイズ範囲を指定します。詳細については、「付録: Post Policy」をご参照ください。

原因：アップロードされたオブジェクトのサイズが許可される最小サイズより小さいです。

解決策： PostObject 操作を使用してファイルをアップロードする際は、PostPolicy のフォームフィールドに有効な値を設定します。 content-length-range 条件を使用して、アップロードするオブジェクトの許容サイズ範囲を指定します。

原因：PostObject リクエストのフォームフィールドが大きすぎます。

解決策：file フォームフィールドを除き、他のフォームフィールドのサイズは 4 KB を超えることはできません。詳細については、「PostObject エラーのトラブルシューティング」をご参照ください。

原因：リクエストされたパートは削除されました。

解決策：必要なすべてのパートが正常にアップロードされ、削除されていないことを確認します。アップロードされたパートのステータスは、CompleteMultipartUpload 操作を呼び出すことで確認できます。

原因：画像サイズが制限を超えています。

解決策：ソース画像ファイルが次のサイズ制限を満たしていることを確認してください：

• ソース画像ファイルのサイズは 20 MB を超えることはできません。

• 画像を回転する場合、ソース画像の幅または高さは 4,096 ピクセルを超えることはできません。

• ソース画像の片側の長さは 30,000 ピクセルを超えることはできません。

原因：Content-Length パラメーターで指定されたバイト数が、実際に送信されたバイト数と一致しません。

解決策：Content-Length パラメーターを実際に送信されたバイト数に設定します。

原因: PostObject リクエスト内のファイルの数が不正です。PostObject リクエストには、file フォームフィールドを 1 つしか含めることができません。

解決策: PostObject リクエストに file フォームフィールドが 1 つだけ含まれるようにしてください。

原因：

1. オブジェクトサイズの制限超過：アップロードされたファイルのサイズが、現在のアップロード操作の制限を超えています。

2. ホットリンク保護設定の制限超過：Referer ホワイトリストとブラックリスト設定の合計サイズが 20 KB を超えています。

解決策：

• シナリオ 1：オブジェクトサイズの制限超過

  ファイルサイズに基づいてアップロード方法を調整します：

  • シンプル/フォーム/追加アップロード：最大ファイルサイズは 5 GB です。

  • マルチパートアップロード：最大ファイルサイズは 48.8 TB です。

• シナリオ 2：ホットリンク保護設定の制限超過

  不要なホットリンク保護ルールを削除して、Referer ホワイトリストとブラックリストの合計データサイズが 20 KB を超えないようにします。

原因：Authorization ヘッダーの計算メソッドに AccessKey ID と Signature パラメーターがありません。

解決策：Authorization ヘッダーの計算メソッドに AccessKey ID パラメーターを追加し、次の署名例に示すように署名計算を完了します。

AccessKey ID が LTAI**************** で、AccessKey Secret が yourAccessKeySecret であると仮定します。次の Python コードは、署名を計算する方法の例を示しています：

import hmac
import hashlib
import base64
import os

accessKeySecret = os.getenv('OSS_ACCESS_KEY_SECRET')
h = hmac.new(accessKeySecret.encode('utf-8'),
             "PUT\neB5************==\ntext/html\nWed, 28 Dec 2022 10:27:41 GMT\nx-oss-meta-author:alice\nx-oss-meta-magic:abracadabra\n/examplebucket/nelson".encode('utf-8'), hashlib.sha1)
signature =  base64.encodebytes(h.digest())
print(signature)

計算された署名 77Dv**************** を Authorization ヘッダーの構造と組み合わせたものが、送信するメッセージ本文となります:

PUT /nelson HTTP/1.0
Authorization:OSS qn6q**************:77Dv****************
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Wed, 28 Dec 2022 10:27:41 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com
x-oss-meta-author: alice
x-oss-meta-magic: abracadabra

原因：Authorization ヘッダーの計算メソッドで無効なパラメーターが指定されています。

解決策：次の手順に基づいて Authorization ヘッダーの計算のトラブルシューティングを行います。

• 計算メソッド：

  Authorization = "OSS " + AccessKeyId + ":" + Signature
  Signature = base64(hmac-sha1(AccessKeySecret,
              VERB + "\n"
              + Content-MD5 + "\n" 
              + Content-Type + "\n" 
              + Date + "\n" 
              + CanonicalizedOSSHeaders
              + CanonicalizedResource))

• パラメーターの説明：

  パラメーター	タイプ	必須	例	説明
  AccessKeyId	String	はい	LTAI****************	キーの AccessKey ID。
  AccessKeySecret	String	はい	yourAccessKeySecret	キーの AccessKey Secret。
  VERB	Enumeration	はい	PUT	HTTP リクエストメソッド (PUT、GET、POST、HEAD、DELETE、OPTIONS など)。
  \n	String	いいえ	\n	改行。
  Content-MD5	String	いいえ	eB5eJF1ptWaXm4bijSPyxw==	リクエストコンテンツデータの MD5 ハッシュ。この値を取得するには、メッセージコンテンツ (ヘッダーを除く) の MD5 ハッシュを計算して 128 ビットの数値を取得し、その数値を Base64 エンコードします。詳細については、「RFC2616 Content-MD5」をご参照ください。 このリクエストヘッダーは、メッセージの整合性 (メッセージコンテンツが送信時と同じであるかどうか) を確認するために使用できます。このヘッダーは空にすることができます。 Content-MD5 ハッシュの計算方法については、「Content-MD5 ハッシュの計算」をご参照ください。
  Content-Type	String	いいえ	application/octet-stream	リクエストコンテンツのタイプ。このヘッダーは空にすることができます。
  Date	String	はい	Sun, 22 Nov 2015 08:16:38 GMT	重要 操作の時間。Date パラメーターは GMT 形式である必要があり、空にすることはできません。 リクエストの Date と OSS サーバーの現在時刻との時間差が 15 分を超えると、OSS サーバーはリクエストを拒否し、HTTP 403 エラーを返します。
  CanonicalizedOSSHeaders	String	いいえ	x-oss-meta-a:a\nx-oss-meta-b:b\nx-oss-meta-c:c\n	x-oss- で始まり、辞書式順序でソートされた HTTP ヘッダー。このパラメーターは空にすることができます。 CanonicalizedOSSHeaders を空に設定した場合、末尾に `\n` 区切り文字を追加する必要はありません。 CanonicalizedOSSHeaders が 1 つしかない場合は、末尾に `\n` 区切り文字を追加する必要があります (例：`x-oss-meta-a\n`)。 複数の CanonicalizedOSSHeaders がある場合は、各 CanonicalizedOSSHeaders の後に `\n` 区切り文字を追加する必要があります (例：`x-oss-meta-a:a\nx-oss-meta-b:b\nx-oss-meta-c:c\n`)。 CanonicalizedOSSHeaders の構築方法については、「CanonicalizedOSSHeaders の構築」をご参照ください。
  CanonicalizedResource	String	はい	/examplebucket/	アクセスしたい OSS リソース。このパラメーターは空にすることはできません。 CanonicalizedResource の構築方法については、「CanonicalizedOSSHeaders の構築」をご参照ください。

• 署名の例：

  リクエスト	署名文字列の計算式	署名文字列
  PUT /nelson HTTP/1.0 Content-MD5: eB5eJF1ptWaXm4bijSPyxw== Content-Type: text/html Date: Wed, 28 Dec 2022 10:27:41 GMT Host: examplebucket.oss-cn-hangzhou.aliyuncs.com x-oss-meta-author: alice x-oss-meta-magic: abracadabra	Signature = base64(hmac-sha1(AccessKeySecret,VERB + "\n" + Content-MD5 + "\n"+ Content-Type + "\n" + Date + "\n" + CanonicalizedOSSHeaders+ CanonicalizedResource))	PUT\n eB5eJF1ptWaXm4bijSPyxw==\n text/html\n Wed, 28 Dec 2022 10:27:41 GMT\n x-oss-meta-magic:abracadabra\nx-oss-meta-author:alice\n/examplebucket/nelson

  AccessKey ID が LTAI**************** で、AccessKey Secret が yourAccessKeySecret であると仮定します。次の Python コードは、署名を計算する方法の例を示しています：

  import hmac
  import hashlib
  import base64
  import os
  
  accessKeySecret = os.getenv('OSS_ACCESS_KEY_SECRET')
  h = hmac.new(accessKeySecret.encode('utf-8'),
               "PUT\neB5************==\ntext/html\nWed, 28 Dec 2022 10:27:41 GMT\nx-oss-meta-author:alice\nx-oss-meta-magic:abracadabra\n/examplebucket/nelson".encode('utf-8'), hashlib.sha1)
  signature =  base64.encodebytes(h.digest())
  print(signature)

  計算された署名 77Dv**************** は、Authorization ヘッダーの構造と組み合わされ、送信するメッセージ本文になります:

  PUT /nelson HTTP/1.0
  Authorization:OSS qn6q**************:77Dv****************
  Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
  Content-Type: text/html
  Date: Wed, 28 Dec 2022 10:27:41 GMT
  Host: oss-example.oss-cn-hangzhou.aliyuncs.com
  x-oss-meta-author: alice
  x-oss-meta-magic: abracadabra

原因：Authorization ヘッダーの計算メソッドで不正なパラメーターが指定されています。

解決策：次の表のパラメーター説明に基づいて、Authorization ヘッダーの計算を完了します。

原因：Authorization ヘッダーの計算メソッドで必須パラメーターが空です。

解決策：次の表のパラメーター説明に基づいて、Authorization ヘッダーの計算を完了します。

原因：時間パラメーターが無効です。

解決策：時間の形式は RFC 1123 標準に準拠する必要があります (例：`Sun, 06 Nov 1994 08:49:37 GMT`)。

原因：ホストが無効です。

解決策：ホストはバケットドメイン名または IP アドレスにすることができます。バケットドメイン名の形式は `BucketName.Endpoint` です (例：`examplebucket.oss-cn-hangzhou.aliyuncs.com`)。ホストが IP アドレスの場合は、その IP アドレスが有効であることを確認してください。

原因：ファイルをコピーする際に、ソースバケットとソースオブジェクトが指定されていません。

解決策：ファイルをコピーする際には、x-oss-copy-source パラメーターを `/sourcebucket/sourcekey` 形式で指定する必要があります。たとえば、ソースバケットが examplebucket で、ソースオブジェクトが exampleobject の場合、x-oss-copy-source パラメーターを `/examplebucket/exampleobject` に設定します。

原因：callback パラメーターがリクエスト URL とリクエストヘッダーの両方に含まれています。

解決策：callback パラメーターは、リクエスト URL またはリクエストヘッダーのいずれかに含めることができますが、両方に含めることはできません。

原因：callback-var パラメーターがリクエスト URL とリクエストヘッダーの両方に含まれています。

解決策：callback-var パラメーターは、リクエスト URL またはリクエストヘッダーのいずれかに含めることができますが、両方に含めることはできません。

原因

同じリクエスト内で、署名用の Authorization フィールドがリクエストヘッダーに存在し、かつ署名用の OSSAccessKeyId、Expires、Signature フィールドがリクエスト URI に存在します。例：

PUT /example_file?OSSAccessKeyId=LTAI****************&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv**** HTTP/1.0
Authorization:OSS qn6q**************:77Dv****************
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Tue, 20 Dec 2022 08:48:18 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com

解決策

同じリクエスト内で、ヘッダー署名または URI 署名のいずれかを使用しますが、両方は使用しません。次のコードは、ヘッダー署名のみを使用する例です：

PUT /example_file HTTP/1.0
Authorization:OSS qn6q**************:77Dv****************
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Tue, 20 Dec 2022 08:48:18 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com

次のコードは、URI 署名のみを使用する例です：

PUT /example_file?OSSAccessKeyId=LTAI****************&Expires=1141889120&Signature=vjby******** HTTP/1.0
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Tue, 20 Dec 2022 08:48:18 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com

原因：パラメーターの形式が無効です。

解決策：「API 概要」で対応する API 操作を参照し、パラメーターを正しい形式で指定してください。

原因：時間パラメーターが無効です。UNIX タイムスタンプが現在時刻より後になっています。

解決策：UNIX タイムスタンプは現在時刻より前である必要があります。

原因：時間パラメーターが無効です。UNIX タイムスタンプが 0 未満です。

解決策：UNIX タイムスタンプは 0 より大きい必要があります。

原因：指定されたオブジェクトのバージョン ID が無効です。

解決策：GetBucketVersions (ListObjectVersions) 操作を呼び出して、バケットでバージョン管理が有効になっているか、および指定されたオブジェクトのバージョン ID が正しいかを確認します。

原因：サーバーサイド暗号化 (SSE) アルゴリズムが AES256 に設定されているときに、KMSMasterKeyID パラメーターが指定されています。

解決策：KMSMasterKeyID パラメーターは、SSE アルゴリズムが KMS に設定され、指定されたキーが暗号化に使用される場合にのみ必要です。

原因：ユーザーに必要な権限がありません。

解決策：バケットの暗号化ルールを設定できるのは、バケットのオーナーまたは承認された RAM ユーザーのみです。詳細については、「PutBucketEncryption」をご参照ください。

原因：指定されたバケットストレージクラスが存在しません。

解決策：OSS は、標準、低頻度アクセス (IA)、アーカイブストレージ、コールドアーカイブ、ディープコールドアーカイブのストレージクラスをサポートしています。詳細については、「PutBucket」をご参照ください。

原因：Authorization ヘッダーの Date が無効です。

解決策：Date パラメーターは操作の時刻を示し、GMT 形式である必要があります (例：`Sun, 22 Nov 2015 08:16:38 GMT`)。

原因：PostObject リクエストのボディの合計長が 5 GB を超えています。

解決策：PostObject リクエストのボディの合計長は 5 GB を超えることはできません。詳細については、「PostObject」をご参照ください。

原因：PostObject リクエストヘッダーに OSSAccessKeyId フォームフィールドがありません。

解決策：バケットが公開読み書きでない場合、または Policy (または Signature) フォームフィールドが提供されている場合、OSSAccessKeyId フォームフィールドは必須です。

原因：PostObject リクエストヘッダーに署名情報がありません。

解決策：バケットが公開読み書きでない場合、または OSSAccessKeyId (または Policy) フォームフィールドが提供されている場合、Signature フォームフィールドは必須です。署名を計算する手順は次のとおりです：

1. UTF-8 エンコーディングでポリシーを作成します。

2. ポリシーを Base64 エンコードします。結果は Policy フォームフィールドの値になります。この値を署名対象の文字列として使用します。

3. AccessKey Secret を使用して文字列に署名します。署名メソッドは `Signature = base64(hmac-sha1(base64(policy), AccessKeySecret))` です。

原因：OSS はプライベート IP アドレスにコールバックリクエストを送信できません。

解決策：パブリック IP アドレスを使用してコールバックリクエストを送信してください。

原因: filename フィールドの次の行にカスタムパラメーターが含まれているためです。

解決策: 次の図に示すように、filename フィールドに続く行は、標準の Content-Type パラメーターである必要があります：

原因：PostObject リクエストで key フォームフィールドが指定されていないか、key フォームフィールドの順序が正しくありません。

解決策：PostObject リクエストで key フォームフィールドを指定します。key フォームフィールドは file フォームフィールドの前に置く必要があります。詳細については、「PostObject」をご参照ください。

原因：POST リクエストフォームに無効なパラメーターまたは不正な形式のパラメーターが含まれています。

解決策：パラメーターを標準形式で指定します。詳細については、「PostObject」をご参照ください。

原因：callbackBody パラメーターが指定されていません。

解決策：Callback パラメーターは Base64 エンコードされた JSON 文字列でなければなりません。コールバック用のサーバー URL (callbackUrl) とコールバックのコンテンツ (callbackBody) を指定する必要があります。

原因：callbackBody パラメーターが無効で、JSON として解析できません。

解決策：callbackBody パラメーターは、コールバックが開始されたときのリクエストボディの値を指定します (例：`key=$(object)&etag=$(etag)&my_var=$(x:my_var)`)。トラブルシューティングについては、「コールバック」をご参照ください。

原因：callbackBodyType パラメーターが無効で、JSON として解析できません。

解決策：callbackBodyType パラメーターは、コールバックリクエストの Content-Type を指定します。サポートされている値は `application/x-www-form-urlencoded` と `application/json` です。

原因：Callback パラメーターが Base64 エンコードされていません。

解決策：Callback パラメーターは Base64 エンコードされた JSON 文字列でなければなりません。コールバック用のサーバー URL とコールバックのコンテンツを指定する必要があります。詳細については、「コールバック」をご参照ください。

原因：Callback パラメーターが JSON 形式ではありません。

解決策：Callback パラメーターは Base64 エンコードされた JSON 文字列でなければなりません。例：

{
"callbackUrl":"121.101.XX.XX/test.php",
"callbackHost":"oss-cn-hangzhou.aliyuncs.com",
"callbackBody":"{\"mimeType\":${mimeType},\"size\":${size}}",
"callbackBodyType":"application/json"
}

原因：callbackHost パラメーターが無効で、JSON として解析できません。

解決策：callbackHost パラメーターは、コールバックリクエストの Host ヘッダーを指定します (例：`oss-cn-hangzhou.aliyuncs.com`)。callbackHost が構成されていない場合、callbackUrl の URL が解析され、URL から解析された Host が callbackHost の値として使用されます。

原因：署名バージョンがサポートされていません。

解決策：現在の署名がバージョン 1.0 または 2.0 であることを確認します。

原因：Callback パラメーターでコールバック用のサーバー URL (callbackUrl) が指定されていません。

解決策：Callback パラメーターは Base64 エンコードされた JSON 文字列でなければなりません。コールバック用のサーバー URL とコールバックのコンテンツを指定する必要があります。

原因：callback-var パラメーターが JSON 形式ではありません。

解決策：callback-var パラメーターはカスタムパラメーターを構成するために使用されます。カスタムパラメーターはキーと値のペアとして指定されます。キーは `x:` で始まり、小文字でなければなりません。たとえば、2 つのキー `x:var1` と `x:var2` を、対応する値 value1 と value2 で設定する場合、JSON 形式は次のようになります：

{
"x:var1":"value1",
"x:var2":"value2"
}

原因：カスタムヘッダーの形式が正しくありません。

解決策：カスタムヘッダーの形式は `x-oss-persistent-headers: key1:base64_encode(value1),key2:base64_encode(value2)....` です。この形式では、key1 と key2 はカスタムヘッダーで、value1 と value2 はそれに対応する値です。base64_encode は、カスタムヘッダーの値が Base64 エンコードされていることを示します。たとえば、カスタムヘッダーが myheader1 と myheader2 で、その値が myvalue1 と myvalue2 の場合、カスタムリクエストヘッダーは `x-oss-persistent-headers:myheader1:bXl2YWx1ZTE=,myheader2:bXl2YWx1ZTI=` となります。

原因：タグのキーと値が URL エンコードされておらず、キーが重複しています。

解決策：オブジェクトタグ付けでは、キーと値のペアのセットを使用してオブジェクトをマークします。オブジェクトタグには次のルールが適用されます：

• 1 つのオブジェクトには最大 10 個のタグを付けることができます。キーは一意でなければなりません。

• 各キーは最大 128 文字、各値は最大 256 文字の長さにすることができます。

• キーと値では大文字と小文字が区別されます。

• タグの有効な文字セットには、大文字、小文字、数字、スペース、および次の特殊文字が含まれます：+ - = . _ : / HTTP ヘッダーを使用してタグを設定し、タグにこれらの文字のいずれかが含まれている場合は、タグのキーと値を URL エンコードする必要があります。

原因：カスタムヘッダーに無効な文字が含まれています。

解決策：OSS は RFC 7230 仕様に準拠しており、この仕様に基づいて HTTP ヘッダーに無効な文字が含まれているかどうかを判断します。

原因：カスタムヘッダーが標準の HTTP ヘッダーと競合しています。

解決策：カスタムヘッダーに `Host`、`Content-MD5`、`Origin`、`Range` などの標準 HTTP ヘッダーを指定しないでください。

原因：カスタムヘッダーの値にキャリッジリターン `\r` または改行 `\n` が含まれています。

解決策：カスタムヘッダーの値からキャリッジリターン `\r` と改行 `\n` を削除します。

原因：カスタムヘッダーがリクエストヘッダーと同じ名前を持っていますが、値が異なります。

解決策：カスタムヘッダーがリクエストヘッダーと同じ名前を持つ場合、それらの値は同じでなければなりません。

原因：カスタムヘッダーの値が無効です。

解決策：カスタムヘッダーの値に含まれる中国語文字などの特殊文字を UTF-8 エンコードします。

原因：Base64 エンコードされた callback パラメーターの合計長が 5 KB を超えています。

解決策：Base64 エンコードされた callback パラメーターの合計長は 5 KB を超えることはできません。

原因：Base64 エンコードされた callback-var パラメーターの合計長が 5 KB を超えています。

解決策：Base64 エンコードされた callback-var パラメーターの合計長は 5 KB を超えることはできません。

原因：リクエストされたコールバック URL の数が 5 を超えています。

解決策：OSS では、同時に最大 5 つの URL を構成できます。各 URL はセミコロン (;) で区切ります。

原因：<VersioningConfiguration> フィールドでバケットのバージョン管理ステータスが指定されていません。

解決策：<VersioningConfiguration> フィールドでバケットのバージョン管理ステータスを指定します。例：

PUT /?versioning HTTP/1.1
Host: bucket-versioning.oss-cn-hangzhou.aliyuncs.com
Date: Tue, 09 Apr 2019 02:20:12 GMT
Authorization: OSS qn6q**************:77Dv****************
<?xml version="1.0" encoding="UTF-8"?>
<VersioningConfiguration>
    <Status>Enabled</Status>
<VersioningConfiguration>

原因：Authorization ヘッダーの計算メソッドに不明なパラメーターが存在します。

解決策：次の表のパラメーター説明に基づいて、Authorization ヘッダーの計算を完了します。

原因：VersionId フィールドが指定されていません。

解決策：VersionId フィールドにオブジェクトのバージョン ID を指定します。詳細については、「ListObjectVersions (GetBucketVersions)」をご参照ください。

原因：単一接続の帯域幅制限の値が無効です。

解決策：単一接続の帯域幅制限の値は、819,200 から 838,860,800 の範囲 (100 KB/s から 100 MB/s に相当) でなければなりません。

原因：単一接続の帯域幅制限パラメーター `x-oss-traffic-limit` がリクエスト URL とリクエストヘッダーの両方に含まれています。

解決策：単一接続の帯域幅制限パラメーター `x-oss-traffic-limit` は、リクエスト URL またはリクエストヘッダーのいずれかに含めることができますが、両方に含めることはできません。

原因：バケット名が命名規則に準拠していません。

解決策：バケット名が命名規則に準拠していることを確認してください。バケット名には次のルールが適用されます：

• 小文字、数字、ハイフン (-) のみを含めることができます。

• 小文字または数字で始まる必要があります。

• 長さは 3～63 文字である必要があります。

原因：CRR のソースバケットとターゲットバケットのバージョン管理ステータスが一致していません。

解決策：CRR の場合、ソースバケットとターゲットバケットの両方でバージョン管理を有効または無効にする必要があります。

原因：チャンネル名フィールドがありません。

解決策：命名規則に従ってチャンネル名を指定します。

• UTF-8 エンコーディングを使用します。

• 長さは 1～64 文字である必要があります。

• スラッシュ (/) またはバックスラッシュ (\) を含めることはできません。

原因：チャンネル名にスラッシュが含まれています。

解決策：チャンネル名にスラッシュ (/) またはバックスラッシュ (\) が含まれていないことを確認します。

原因：チャンネル名のエンコーディングが正しくありません。

解決策：チャンネル名は UTF-8 エンコードされている必要があります。

原因：チャンネル名の長さが制限を超えています。

解決策：チャンネル名の長さが 1～64 文字であることを確認します。

原因：ローカルで計算された CRC-64 値が、サーバーから返された CRC-64 値と一致しません。

解決策：トラブルシューティングについては、「CRC-64 を使用したデータ整合性の検証」をご参照ください。

原因：指定されたオブジェクト暗号化アルゴリズムが無効です。

解決策：オブジェクトが KMS を使用して暗号化される場合、SM4 暗号化アルゴリズムのみがサポートされます。詳細については、「サーバーサイド暗号化」をご参照ください。

原因：アップロードの Content-MD5 リクエストヘッダーが、OSS によって計算されたメッセージボディの Content-MD5 ハッシュと一致しません。

解決策：トラブルシューティングについては、「Content-MD5 ハッシュの計算」をご参照ください。

原因: x-oss-server-side-encryption パラメーターに指定された値が無効です。

解決策: x-oss-server-side-encryption の有効な値は AES256、KMS、および SM4 です。サーバ側暗号化メソッドの詳細については、「PutObject」をご参照ください。

原因：クライアントで暗号化されたソースファイルに対して UploadPartCopy 操作を呼び出すことはできません。

解決策：UploadPartCopy 操作は、クライアントで暗号化されていないソースファイルに対してのみ呼び出して、既存のオブジェクトからデータをコピーしてパートをアップロードできます。詳細については、「UploadPartCopy」をご参照ください。

原因：クライアントサイド暗号化に必要なパラメーターがありません。

解決策：次の必須パラメーターがすべて指定されていることを確認してください。

原因：クライアントサイド暗号化メタデータに入力された合計ファイルサイズまたはパートサイズが無効です。

解決策：クライアントサイドのマルチパートアップロードを実行する場合、マルチパートアップロードの初期化中に大きなファイルの合計サイズ (x-oss-meta-client-side-encryption-data-size) とパートサイズ (x-oss-meta-client-side-encryption-part-size) を渡す必要があります。パートサイズは 16 の整数倍でなければなりません。詳細については、「クライアントサイド暗号化 (Java SDK V1)」をご参照ください。

原因：クライアントサイド暗号化用に構成されたパート暗号化情報が、マルチパートアップロードの初期化時に設定された暗号化情報と一致しません。

解決策：クライアント用に構成されたパート暗号化情報が、マルチパートアップロードの初期化時に設定された暗号化情報と一致していることを確認します。詳細については、「クライアントサイド暗号化 (Java SDK V1)」をご参照ください。

原因：実際にアップロードされたパートの数が、マルチパートアップロードの初期化時に指定されたパートの数と一致しません。

解決策：指定されたパートの数が、実際にアップロードされたパートの数と一致していることを確認します。

原因：実際にアップロードされたすべてのパートの合計サイズが、マルチパートアップロードの初期化時に指定された合計パートサイズと一致しません。

解決策：最後のパートをアップロードした後、実際にアップロードされたすべてのパートの合計サイズが、マルチパートアップロードの初期化時に指定された合計パートサイズと一致していることを確認します。詳細については、「CompleteMultipartUpload」をご参照ください。

原因：CopyObject 操作を使用してクライアントサイド暗号化メタデータを変更しようとしています。

解決策：ファイルがクライアントサイド暗号化でアップロードされた後、暗号化メタデータは保護され、CopyObject 操作を使用してオブジェクトメタデータを変更することはできません。詳細については、「CopyObject」をご参照ください。

原因：パート ID がパートの総数 (PartNumber) より大きいです。

解決策：パート ID がパートの総数以下であることを確認します。詳細については、「UploadPart」をご参照ください。

原因：クライアントサイド暗号化メタデータに入力されたパート数が制限を超えています。

解決策：各オブジェクトは最大 10,000 パートに分割できます。

原因：実際にアップロードされた各パートのサイズが、マルチパートアップロードの初期化時に指定された各パートのサイズと一致しません。

解決策：最後のパートを除き、他のすべてのパートのサイズは、マルチパートアップロードの初期化時に指定された各パートのサイズと一致している必要があります。詳細については、「UploadPart」をご参照ください。

原因：Host パラメーターが正しくありません。

解決策：標準のエンドポイントを使用してください。エンドポイントとデータセンターの詳細については、「エンドポイントとデータセンター」をご参照ください。

原因：オブジェクト名の長さが制限を超えています。

解決策：オブジェクト名の長さが 1～1,023 文字であることを確認します。

原因：オブジェクト名が指定されていません。

解決策：オブジェクトの命名規則に従ってオブジェクト名を指定します。

原因：指定されたオブジェクト名が無効です。

解決策：オブジェクト名が命名規則に準拠していることを確認してください。オブジェクト名には次のルールが適用されます：

• UTF-8 エンコーディングを使用します。

• 長さは 1～1,023 文字である必要があります。

• スラッシュ (/) またはバックスラッシュ (\) で始まることはできません。

原因：指定された CMK ID が無効です。

解決策：オブジェクトが KMS を使用して暗号化され、指定されたキーが使用される場合、CMK ID を入力する必要があります。CMK ID の例：`9468da86-3509-4f8d-a61e-6eab1eac****`。

原因：CompleteMultipartUpload によって送信されたパートが、不正な PartNumber または ETag のために無効です。

解決策：サーバーは、CompleteMultipartUpload 操作が呼び出されたときに PartNumber と ETag を検証します。

• PartNumber は 1 から 10,000 までの整数でなければなりません。PartNumber は連続している必要はありませんが、昇順でなければなりません。たとえば、最初のパートの PartNumber は 1、2 番目のパートの PartNumber は 5 にすることができます。

• CompleteMultipartUpload リクエストによって作成されたオブジェクトの場合、ETag 値はそのコンテンツの UUID です。ETag 値は、オブジェクトのコンテンツが変更されたかどうかを確認するために使用できます。

原因：PartNumber が無効です。

解決策：PartNumber が 1 から 10,000 までの整数であることを確認します。詳細については、「CompleteMultipartUpload」をご参照ください。

原因：CompleteMultipartUpload によって送信されたパートが、パート番号の昇順でソートされていません。

解決策：CompleteMultipartUpload によって送信されるパートは、パート番号の昇順でソートする必要があります。たとえば、最初のパートの PartNumber は 1、2 番目のパートの PartNumber は 5 にすることができます。詳細については、「CompleteMultipartUpload」をご参照ください。

原因：リクエストの Policy の形式が正しくありません。

解決策：Policy に `,` または `]` が欠けていないか確認します。

原因：リクエストの Policy の形式が正しくありません。

解決策：Policy の形式を確認します。`"` が欠けていないか、またはエスケープ文字に `\` が欠けていないか確認します。

原因：リクエスト Policy に `conditions` が含まれていません。

解決策：リクエスト Policy には少なくとも 1 つの `conditions` 要素が含まれている必要があります。

原因：バケットタグのキーまたは値が無効です。

ソリューション：バケットタグが次の命名規則に準拠していることを確認してください。

• キーと値は UTF-8 エンコードされている必要があります。

• キーの長さは 64 文字以内で、http://、https://、または Aliyun で始めることはできず、空にすることもできません。

• 値の長さは 128 文字以内で、空にすることもできます。

原因：オブジェクトタグのキーが無効です。

ソリューション：オブジェクトのタグ付けは、キーと値のペアのセットでオブジェクトをマークする仕組みです。オブジェクトタグには、以下のルールが適用されます：

• キーの長さは最大 128 文字、値の長さは最大 256 文字です。

• キーと値は、大文字と小文字が区別されます。

• タグに使用できる有効な文字セットには、大文字、小文字、数字、スペース、および次の特殊文字 (+、-、=、.、_、:、/) が含まれます。これらの特殊文字のいずれかを含むタグを HTTP ヘッダーで設定する場合、タグのキーと値を URL エンコードする必要があります。

原因：指定された宛先バケットはレプリケーションに対して無効です。

ソリューション：GetBucketReplicationLocation 操作を呼び出して、レプリケーション用の有効なターゲットリージョンを取得します。

原因：ログの保存先である宛先バケットが存在しません。

解決策：有効な宛先バケットを指定してください。

原因：バケットがターゲットリージョンに存在しません。

ソリューション：バケットが存在するリージョンを確認してください。

原因：シンボリックリンクが別のシンボリックリンクを指しています。

ソリューション：シンボリックリンクのターゲットが、別のシンボリックリンクになっていないことを確認してください。

原因：保持ポリシーが無効です。

ソリューション：次のコードは、InitiateBucketWorm 操作を使用して保持ポリシーを作成する例を示しています。

POST /?worm HTTP/1.1
Date: Thu, 15 May 2014 11:18:32 GMT
Content-Length: 556
Content-Type: application/xml
Host: BucketName.oss.aliyuncs.com
Authorization: OSS qn6q**************:77Dv****************

<InitiateWormConfiguration>
  <RetentionPeriodInDays>365</RetentionPeriodInDays>
</InitiateWormConfiguration>

原因：リクエストパラメーターが有効な XML フォーマットではありません。

ソリューション：リクエストパラメーターが有効な XML フォーマットであることを確認してください。

原因：1 つのバケットのインベントリルールの数が上限である 1,000 に達しました。

ソリューション：インベントリルール数の上限を増やすには、チケットを送信してください。

原因：KMS サービスを有効化する前に、サーバ側暗号化で KMS を使用しようとしたため。

解決策：KMS サービスを有効化してください。詳細については、「Key Management Service の有効化」をご参照ください。

原因：PostObject リクエストのフォームフィールドが正しくフォーマットされていません。

解決策：フォームフィールドが必要なフォーマットに従っていることを確認してください。フォームフィールドのフォーマットは次のとおりです。

Content-Disposition: form-data;
        name="{key}"\r\n\r\n{value}\r\n--{boundary}

次のコードは、PostObject リクエストの例です。

POST / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.6)
Content-Type: multipart/form-data; boundary=9431149156168
Host: xxxx-hz.oss-cn-hangzhou.aliyuncs.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 5052
--9431149156168
Content-Disposition: form-data; name="key"
test-key
--9431149156168
Content-Disposition: form-data; name="Content-Disposition"
attachment;filename=D:\img\example.png
--9431149156168
Content-Disposition: form-data; name="OSSAccessKeyId"
2NeL********j2Eb

要件は次のとおりです。

• ヘッダーには `Content-Type: multipart/form-data; boundary={boundary}` を含める必要があります。

• ヘッダーと本文は \r\n--{boundary} で区切られます。\r\n 文字は改行を表します。

• フォームフィールド名 (例：policy、key、file、OSSAccessKeyId、OSSAccessKeyId、Content-Disposition) は、大文字と小文字が区別されます。

• file フォームフィールドは、最後のフォームフィールドである必要があります。

• バケットが public-read-write の場合、OSSAccessKeyId、policy、Signature のフォームフィールドを指定する必要はありません。これらのフィールドのいずれかを指定した場合、バケットが public-read-write であるかどうかにかかわらず、他の 2 つのフィールドも指定する必要があります。

詳細については、次のコード例をご参照ください。

• C#

• Java

• JavaScript

原因：リクエスト内の XML フォーマットが無効です。

解決策：このエラーのトラブルシューティングを行うには、関連するリクエストのドキュメントをご参照ください：

• DeleteMultipleObjects

• CompleteMultipartUpload

• PutBucketLogging

• PutBucketWebsite

• PutBucketLifecycle

• PutBucketReferer

• PutBucketCORS

原因：アップロードされたファイルが大きすぎます。 Post メソッドを使用してアップロードされるファイルの最大サイズは 5 GB です。

ソリューション：詳細については、「PostObject エラーのトラブルシューティング」をご参照ください。

原因：AccessKey ID が欠落しています。

解決策：正しい AccessKey ID を指定してください。

原因：API 呼び出しに必須パラメーターが欠落しています。

ソリューション：API の概要にある API ドキュメントを参照し、すべての必須パラメーターを追加してください。

原因：ソースバケットのデータセンターに、CRR のペアとなるデータセンターがないためです。

ソリューション：レプリケーションに利用可能なターゲットリージョンのリストを取得するには、「GetBucketReplicationLocation」をご参照ください。

原因：リクエストされたバケットに CRR ルールが設定されていません。

ソリューション：バケットに CRR ルールを設定してください。 詳細については、「PutBucketReplication」をご参照ください。

原因：API リクエストで、不正な、またはサポートされていないパラメーターが渡されました。

解決策：API の概要にある対応する API ドキュメントを参照し、正しくサポートされているパラメーターフォーマットを使用してください。

原因：ターゲットオブジェクトがシンボリックリンクではありません。

解決策：PutSymlink 操作または GetSymlink 操作がシンボリックリンクに対してのみ実行されるようにしてください。

原因：リクエストされた操作は、指定されたリソースではサポートされていません。 考えられるシナリオは次のとおりです。

• 追加可能オブジェクトまたはシンボリックリンクを、コールドアーカイブまたはディープコールドアーカイブのストレージクラスに変換しようとしています。

• アーカイブストレージ、コールドアーカイブ、またはディープコールドアーカイブのストレージクラスにないオブジェクトを解凍するために、RestoreObject 操作を使用しています。

解決策：

• PutObject 操作を呼び出して同じ名前のオブジェクトをアップロードし、追加可能オブジェクトを標準オブジェクトで上書きします。 その後、オブジェクトをコールドアーカイブまたはディープコールドアーカイブのストレージクラスに変換できます。

• RestoreObject 操作を使用してファイルを解凍する場合、そのファイルがアーカイブストレージ、コールドアーカイブ、またはディープコールドアーカイブのストレージクラスにあることを確認してください。

さまざまなリソースでサポートされている操作の種類の詳細については、「API の概要」をご参照ください。

原因： 指定されたタグキーはすでに存在します。

解決策： GetBucketTags を呼び出してバケットの既存のタグを取得し、次に PutBucketTags を呼び出して新しいタグを設定します。

原因：PostObject 操作で送信されたフォームが multipart/form-data としてエンコードされていません。

ソリューション：PostObject 操作で送信するフォームは、multipart/form-data としてエンコードする必要があります。そのためには、ヘッダーの Content-Type を multipart/form-data;boundary=xxxxxx のフォーマットにする必要があります。このフォーマットにおいて、boundary はバウンダリ文字列を指します。詳細については、「PostObject」をご参照ください。

原因：ネットワーク環境またはネットワーク構成が原因で、ネットワークタイムアウトが発生しました。

解決策：トラブルシューティングについては、ネットワークタイムアウトの処理をご参照ください。

原因：1 つのリージョン内で Alibaba Cloud アカウントが作成したバケット数が、上限である 100 個に達したためです。

解決策：

• バケットには容量制限がありません。バケット内にフォルダを作成してコンテンツを整理できます。フォルダの作成方法の詳細については、「フォルダの作成」をご参照ください。

• 不要になったバケットを削除してください。バケットの削除方法の詳細については、「バケットの削除」をご参照ください。

  重要

  削除したバケットは回復できません。注意して操作してください。

• バケット数の上限を引き上げるには、チケットを送信してください。

原因：バケットにアタッチできるドメイン名の数が上限である 100 に達しました。

解決策：チケットを送信して、バケットのドメイン名の数の上限引き上げを申請できます。

原因：CRR ルールで設定されたオブジェクトタグの数が上限を超えています。

解決策：同期対象のオブジェクトをフィルターにかけるには、CRR ルールに最大 10 個のオブジェクトタグを追加できます。

原因：バケットに関連付けられた CRR ルールの数が 100 に達しました。

解決策：1 つのバケットでサポートされる CRR ルールは 100 個までです。ビジネス要件がこの上限を超える場合は、チケットを送信してください。

原因：バケットに関連付けられている CRR ルールの数が 100 の上限に達しました。

解決策：1 つのバケットでサポートされる CRR ルールは最大 100 個です。ビジネス要件がこの上限を超える場合は、チケットを送信してください。

原因：リクエストに画像操作が多すぎます。

ソリューション：リクエスト内の画像操作の数を減らしてください。

原因：CRR ルールに 10 を超えるプレフィックスが指定されています。

解決策：クロスリージョンレプリケーションでは、最大 10 個のプレフィックスを指定して、一致するオブジェクトのみを宛先バケットに同期できます。

原因：1 つのバケットに対して複数のレプリケーションルールが設定されています。

ソリューション：1 つのバケットには、レプリケーションルールを 1 つしか設定できません。

原因：バケットのタグ数が制限を超えています。

解決策：1 つのバケットには最大 20 個のタグを設定できます。詳細については、「PutBucketTags」をご参照ください。

原因：削除操作でオブジェクト名が指定されていません。

ソリューション：削除するオブジェクトの名前を指定してください。詳細については、「DeleteMultipleObjects」をご参照ください。

原因：バケット内のオブジェクト数が、週次マニフェストファイルのエクスポートの上限を超えています。

ソリューション：週次マニフェストファイルをエクスポートする場合、バケット内のオブジェクト数は 500 億未満である必要があります。

バケットに 500 億以上のオブジェクトが含まれている場合：

• プレフィックスを照合して、オブジェクトをバッチでエクスポートしてください。

• チケットを起票して、オブジェクトのエクスポート上限の引き上げをリクエストしてください。