バケットに存在しないファイルをオリジンサーバーからフェッチするためのリダイレクトの使用 - Object Storage Service

クライアントが OSS にアクセスする際、ファイルが存在しない場合やデータ移行中に 404 エラーが発生し、接続が中断されることがあります。これを防ぐために、リダイレクトルールを構成できます。これらのルールにより、OSS は特定の条件が満たされたときに 3xx リダイレクト応答を返すことができます。この応答は、リクエストをオリジンサーバーまたは別の指定されたページにシームレスに誘導します。これにより、業務継続性と良好なユーザーエクスペリエンスが保証されます。

仕組み

リダイレクト機能のコアは、クライアント側のリダイレクトです。ブラウザなどのクライアントは、アタッチされたカスタムドメイン名を使用してバケットにアクセスします。リクエストが HTTP 404 エラーなどのルールをトリガーすると、OSS サーバーは 302 などの HTTP 3xx 状態コードと、新しいアドレスを含む Location 応答ヘッダーを返します。クライアントがこの応答を受信すると、Location ヘッダーで指定された URL に自動的に新しいリクエストを送信します。OSS はこのプロセス中にオリジンサーバーからコンテンツをプロキシしません。

カスタム 404 ページ

OSS のパスまたはファイルで特定のエラーが発生した場合、リクエストをカスタムエラーページまたはビジネスプロセス用の別のページにリダイレクトできます。たとえば、クライアントがカスタムドメイン名を使用してバケット内の任意のファイルにアクセスする際に 404 Not Found エラーに遭遇した場合、クライアントは自動的に https://yourdomain/404.html の統一されたカスタムエラーページにリダイレクトされます。

ステップ 1: カスタムドメイン名をアタッチする

リダイレクトルールを作成する前に、バケットにカスタムドメイン名をアタッチする必要があります。リダイレクト機能は、バケットにアタッチされたカスタムドメイン名を通じて行われたリクエストに対してのみ機能します。標準の OSS エンドポイント (http(s)://..aliyuncs.com) を通じて行われたリクエストは、リダイレクトルールをトリガーしません。代わりに、400 Bad Request エラーを返します。

[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[バケット設定] > [ドメイン] を選択し、[ドメインをアタッチ] をクリックします。
[ドメインをアタッチ] パネルで、カスタムドメイン名を入力します。たとえば、customdomain.com と入力します。これを実際のドメイン名に置き換えます。バケットが中国本土にある場合、ドメイン名は ICP 登録が必要です。
プロンプトに従って CNAME 解析を構成します。カスタムドメイン名を OSS が提供する CNAME アドレスにポイントします。

ステップ 2: リダイレクトルールを作成する

左側のナビゲーションウィンドウで、[Data Management] > [ミラーリングベースの back-to-origin] を選択します。
[ミラーリングベースの back-to-origin] ページで、[ルールの作成] をクリックします。
[ルール作成] パネルで、次のパラメーターを設定します：
- [Origin Fetch Type]: [リダイレクト] を選択します。
- 条件: [HTTP 状態コード] を [404] に設定します。
- [オリジン URL]: [固定 URL にリダイレクト] を選択します。
  - プロトコル (1 列目): https を選択します。
  - ドメイン名 (2 列目): カスタムエラーページがあるドメイン名を入力します。例: yourdomain.com
  - パス (3 列目): カスタムエラーページのパスを入力します (例: 404.html)。
- [リダイレクトコード]: [302] または [307] を選択します。これはエラーページのリダイレクトであるため、301 恒久的なリダイレクトは使用しないでください。
[OK] をクリックします。

ステップ 3: ルールを検証する

次の curl コマンドで、customdomain をバケットにアタッチしたカスタムドメイン名に置き換えます。次に、存在しないオブジェクトにアクセスします。

curl -I "http://customdomain.com/does-not-exist.html"

期待される応答は、302 状態コードと正しい Location ヘッダーです。

HTTP/1.1 302 Found
Server: AliyunOSS
Date: Wed, 03 Sep 2025 07:25:01 GMT
Content-Length: 0
Connection: keep-alive
x-oss-request-id: 68B7ED4D949F8A38365CC014
Location: https://yourdomain.com/404.html

シームレスなデータ移行

自己管理データセンターなどのオリジンサーバーから OSS にデータを段階的に移行する場合、一部のオブジェクトはまだ同期されていない可能性があります。これらの存在しないオブジェクトに直接アクセスすると、404 Not Found エラーが発生し、業務継続性に影響します。リダイレクトルールを構成することで、404 などの特定の HTTP エラーが発生したときに OSS が 3xx リダイレクト応答を返すようにできます。この応答は、クライアントをオリジンサーバーにシームレスに誘導してコンテンツを取得します。この機能は、スムーズな移行のトランジションフェーズでよく使用されます。たとえば、クライアントがカスタムドメイン名を使用してバケットの examplefolder/ ディレクトリにあるまだ移行されていないファイルにアクセスすると、クライアントは自動的にレガシーオリジンサーバーの https://yourdomain.com/ にある対応するパスにリダイレクトされます。

ステップ 1: カスタムドメイン名をアタッチする

[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[バケット設定] > [ドメイン] を選択し、[ドメインをアタッチ] をクリックします。
[ドメインをアタッチ] パネルで、カスタムドメイン名を入力します。たとえば、customdomain.com と入力します。これを実際のドメイン名に置き換えます。バケットが中国本土にある場合、ドメイン名は ICP 登録が必要です。
プロンプトに従って CNAME 解析を構成します。カスタムドメイン名を OSS が提供する CNAME アドレスにポイントします。

ステップ 2: リダイレクトルールを作成する

左側のナビゲーションウィンドウで、[Data Management] > [ミラーリングベースの back-to-origin] を選択します。
[ミラーリングベースの back-to-origin] ページで、[ルールの作成] をクリックします。
[ルール作成] パネルで、以下のパラメーターを設定します：
- [Origin Fetch Type]: [リダイレクト] を選択します。
- 条件：
  - [HTTP ステータスコード] を 404 に設定します。
  - [ファイルプレフィックス]: これを移行中のディレクトリ (例: examplefolder/) に設定します。ルールをバケット全体に適用する場合は、これを空のままにします。
- オリジン URL: [プレフィックスとサフィックスを追加] を選択します。これは、シームレスなパスマッピングを確保するためのキーです。[固定 URL にリダイレクト] は選択しないでください。
  - プロトコル (1 列目): 従来のオリジンサーバーでサポートされているプロトコル (https など) を選択します。
  - ドメイン名 (2 列目): yourdomain.com など、レガシーオリジンサーバーのドメイン名を入力します。
  - [パス] (3 番目の列): これを空のままにします。[プレフィックスとサフィックスを追加] パターンは、ユーザーがリクエストしたパス (例: examplefolder/file.jpg) をドメイン名に自動的に追加します。
- リダイレクトコード: [302] を選択します。302 は一時的なリダイレクトであり、データ移行などの移行シナリオに最適です。[301] は使用しないでください。301 は恒久的なリダイレクトです。ブラウザと CDN ノードは 301 リダイレクトを積極的にキャッシュします。301 リダイレクトを設定すると、ファイルを OSS に移行した後でも、リクエストがレガシーオリジンサーバーに強制される可能性があります。これにより、本番環境で大きな問題が発生しやすくなります。

[OK] をクリックします。

ステップ 3: ルールを検証する

curl -I "http://customdomain.com/examplefolder/does-not-exist.html"

期待される応答は、302 状態コードと正しい Location ヘッダーです。

HTTP/1.1 302 Found
Server: AliyunOSS
Date: Wed, 03 Sep 2025 08:28:21 GMT
Content-Length: 0
Connection: keep-alive
x-oss-request-id: 68B7FC25107134303531344B
Location: https://yourdomain.com/examplefolder/does-not-exist.html

ステップ 4: データを移行してトラフィックを切り替える

詳細については、「OSS へのデータ移行」をご参照ください。
移行が完了したら、OSS でのデータ整合性を検証します。
リダイレクトルールの範囲を徐々に狭めます。たとえば、まだ移行されていない特定のサブディレクトリのみをターゲットにします。または、ルールを完全に無効にして、すべてのトラフィックを OSS に切り替えることもできます。

クォータと制限

[適用可能なドメイン名]: ルールは、バケットにアタッチされたカスタムドメイン名を介して行われたリクエストにのみ適用されます。標準 OSS エンドポイント (バケットエンドポイント) を介して行われたリクエストには適用されません。
[ルール数]: 各バケットに最大 20 個のルールを構成できます。OSS は、ルール番号 (RuleNumber) の昇順でリクエストをルールと照合します。リクエストがルールに一致すると、後続のルールは実行されません。
[照合ロジック]: ファイルのプレフィックスとサフィックスの照合では大文字と小文字が区別され、ワイルドカードはサポートされていません。複数のルールを構成する場合は、それらを区別するために異なるファイルのプレフィックスまたはサフィックスを設定する必要があります。

よくある質問

ルールを構成しましたが、リダイレクトの代わりに 404/403 エラーが引き続き発生します。なぜですか。

次の項目を順番に確認してください。

[アクセスドメイン名の確認]: バケットにアタッチされたカスタムドメイン名を使用してアクセスしていることを確認してください。標準 OSS エンドポイントは使用しないでください。標準 OSS エンドポイントを使用すると、400 Bad Request エラーが発生します。
[バケットの権限と状態コードの確認]: バケットの権限が非公開の場合、存在しないオブジェクトにアクセスすると、通常は 403 Forbidden エラーが返されます。ルールに 403 状態コードのトリガー条件が含まれていることを確認してください。
[ルールの優先度の確認]: より小さいルール番号を持つ他のルールがリクエストにすでに一致していないことを確認してください。

リダイレクトされた URL に二重スラッシュ (//) が表示されるのはなぜですか。

これは通常、誤ったパスの連結が原因です。[ファイルプレフィックス] と [プレフィックスを置き換え] (使用している場合) の構成を確認してください。たとえば、ファイルプレフィックスが path/ の場合、置換プレフィックスは new-path であり、/new-path ではありません。これにより、ドメイン名の後にある / の重複を避けることができます。

リダイレクトルールを変更しましたが、変更が有効になりません。なぜですか。

以前に 301 (恒久的なリダイレクト) を使用した場合、ブラウザまたは CDN ノードが古いリダイレクトルールを積極的にキャッシュしている可能性があります。ブラウザのキャッシュをクリアするか、CDN キャッシュをパージするか、ブラウザのシークレットモードまたはプライベートモードを使用してテストしてみてください。

無限リダイレクトループに陥るのはなぜですか。

リダイレクト先のターゲットアドレスを確認してください。ターゲットアドレスが、直接的または間接的に OSS リダイレクトルールをトリガーする URL を指していないことを確認してください。これは、リダイレクトをフォローする CDN を使用する場合に特に重要です。CDN の back-to-origin 構成が、誤ってリクエストを OSS バケットのカスタムドメイン名に送り返していないか確認してください。

どのルールが一致したかを確認するにはどうすればよいですか。

現在、OSS アクセスログには、どのリダイレクトルールが一致したかを識別するフィールドは含まれていません。トラブルシューティングを行うには、ルールの範囲を徐々に狭めるか、他の一時的にルールを無効にすることができます。また、クライアント側で 3xx 応答をキャッチし、Location ヘッダーを調べて、リダイレクトが期待どおりに行われているかを確認することもできます。