オリジンからの配信を確保にする

imgixがキャッシュされていないアセットのリクエストを受け取ると、まずSourceのOriginからアセットを取得しようとします。そのため、imgixがオリジンファイルに無制限かつ妨げられていないアクセス権を持っていることを確認することが重要です。

アセットの利用可能性

アセットは、オリジンに完全にアップロードされた後すぐに利用可能にする必要があります。imgixがアセットが利用できないと判断した場合、404を返し、応答をキャッシュします。デフォルトでは、エラーキャッシュTTLは5分です。imgixは、Source設定で設定されたエラーキャッシュTTLに従ってエラー応答をキャッシュします。

アセットが提供された後、ダッシュボードアナリティクスで数字が更新されるまで最大1時間かかる場合があります。エラーコードのアナリティクスは、エラーコードを引き起こしたアセットが正常に提供された後に表示されます。

imgixからのリクエストの識別

imgixからのリクエストは、時間の経過とともに変化する動的なIPアドレスセットを使用します。さらに、imgixからのリクエストには常に imgix/ のバージョンが含まれます（例: imgix/3.0）。

この情報は、imgixを許可リストに入れるか、imgixからのリクエストに対して異なるセキュリティルールを設定するなど、いくつかの異なる方法で使用できます。

imgixの許可リストへの追加

一部の顧客は、オリジンサーバーに一般公開されていないことを好む場合があります。S3、Azure、およびGCSソースの場合、imgixはソース構成ページに入力された有効な資格情報を使用して、それらの保護されたバケットからアセットを正常に取得できます。ただし、WebフォルダーおよびWebプロキシソースの場合、そのようなセキュリティ設定により、imgixがアセットを取得できなくなる場合があります。サービスがオリジンからアセットを取得できない場合、403エラーが返されます。

imgixがオリジンからアセットを取得できるようにする最善の方法は、ユーザーエージェントを許可リストに追加することです。将来的な互換性のために、imgixのユーザーエージェントは今後変更されることはないため、これが推奨される許可リスト方法です。

WebフォルダーまたはWebプロキシを使用している場合、追加のセキュリティヘッダーを定義してリクエストを認証できます。詳細については、次のセクションを参照してください。

WebフォルダーおよびWebプロキシオリジンへのリクエストの認証

[Webフォルダー]およびWebプロキシソースは、リクエストでOriginに追加の認証ヘッダーを送信するように構成できます。認証を有効にしたWebフォルダーオリジンに送信されたリクエストの例を次に示します。

{
  "headers": {
  ....
  "Authorization": "Basic {base_64_encoded_username_password}",
  "X-Imgix-Signature": {your_signature},
  "X-Imgix-Signature-Host": {origin_host},
  "X-Imgix-Signature-Request-Id": {request_id},
  "X-Imgix-Signature-Timestamp": {timestamp}
  }
}

WebフォルダーまたはWebプロキシソースの認証ヘッダーの構成に関する詳細については、ドキュメントをご覧ください：

• Webフォルダー認証
• Webプロキシ認証

レート制限の無効化

異なるURLへの大量の同期リクエストに対するいくつかのセキュリティ対策が一般的です。これは、同じIPアドレスからのリクエスト数が閾値に達した場合、オリジンからエラーが返されることがよくあります。

imgixでは、リクエストがオリジンではなくキャッシュによく当たるため、この問題が発生する可能性は低いです。ただし、大量のURLが追加された場合や、新しいソースが大量のトラフィックにさらされた場合、オリジンがimgixに対してレート制限を課すことがあります。

このような問題は一時的なものであることが多いです。それでも、レート制限がある場合は、imgixをその制限から除外することを検討する必要があります。

外国語文字と文字エンコード

ファイル名に外国語文字が含まれている場合、imgixはファイル名をエンコードし、エンコードされたパスでアセットを取得しようとします。その結果、エンコードされたパスが404を返す場合、imgixもアセットを404として返します。理想的には、オリジンがリクエストを自動的にエンコードされたファイルパスにルーティングする必要があります。

また、元の文字ではなくエンコードされた文字を使用して提供されるアセットは、パージングに関する問題を引き起こす可能性があります。たとえば、/の代わりに/%2fで提供されるアセットは、RFC仕様3.2.3に関するURIの比較により、2つの異なるアセットURLとして認識される可能性があります。その結果、エンコードされた文字を使用するアセットをパージングしても、URLに安全でない文字が使用されているかどうかに応じて、エンコードされていないバリアントをパージングしない場合があります。

AWS S3のサポートされるリージョン

Amazonのストレージサービス（S3）では、データを特定の地理的リージョンに保存できます。imgix AWS S3ソースは、以下の表に示すサポートされるリージョンのバケットに接続できます。

特定のオリジンに関する既知の問題

特定のWebフォルダーまたはWebプロキシオリジンからの取得時に、いくつかの既知の互換性の問題があります。以下に文書化されています。

Imperva

Impervaは、オンラインアセットへのアクセスを保護するために一般的に使用されるよく知られたセキュリティプラットフォームです。

彼らのセキュリティ機能の1つは、ボットによるアクセスをブロックし、防止することです。これは、ボットがリクエストを完了できないようにするために、“garbage”クッキーヘッダー値を送信することによって行われます。

残念ながら、このセキュリティ機能は、Imperva-fronted Originからのファイルへのimgixレンダリングサービスのアクセスもブロックします。適切に構成されていない場合、Imperva Originを使用するimgixソースへのリクエストは503エラーを返す可能性があります。

この問題を防ぐために、次のいずれかをお勧めします：

• imgixソースを直接オリジンに接続してImpervaをバイパスする
• imgixを許可リストに登録し、imgixレンダリングサービスがImperva経由でアセットにアクセスできるようにする
• ボットアクセスをブロックするセキュリティ機能を無効にするようImpervaサポートに問い合わせる

IPFS

IPFSは、地球間ファイルシステムを意味し、ピアツーピアのハイパーメディアプロトコルに依存する分散ファイルシステムです。

IPFSの性質により、ファイルを返すピアによってオリジンからの一部のフェッチでタイムアウトエラーが観察されることがあります。これらのエラーは、ファイルをオリジンからフェッチする際のタイミングレスポンスとファイルの可用性に関連しており、ファイルが利用可能であれば後続のリトライで成功することが期待されています。

ファイルを取得すると、imgixレンダリングサービスにキャッシュされ、タイムアウトエラーの発生率とIPFSオリジンへの呼び出しの数が減少します。

imgixソースのcaching settingsを最適化することで、IPFSオリジンへのリクエストの数を減らし、その結果、配信可能性の成功率を向上させることができます。キャッシュTTLの推奨値は1年です。