When imgix receives a request for an image that is not cached, we'll first try to retrieve the asset from your Source's origin. Because of this, it's important to ensure that imgix has unrestricted and unobstructed access to your origin files.

Image Availability

The image should be available as soon as it has been completely uploaded to the Origin. If imgix sees that the asset is not available, it will return a 404 and cache the response. By default, the error cached TTL is 5 minutes. imgix will cache error responses according to the error cache TTL set in your Source settings.

Once the image has been served, it can take up to an hour for numbers to update in your Dashboard Analytics. Analytics for any error codes will show up once the image causing the error code has been served successfully.

Identifying requests from imgix

In order to ensure requests succeed from imgix to your origin, you may first need to identify which requests to your origin are actually coming from imgix. You can ID these requests by looking for either our user-agent or IP address range.

Every request made from imgix to your origin will include the user-agent imgix/* in the header of the request.

Additionally, imgix uses these IP ranges for making requests to your origin:


These IP addresses are current as of April 02, 2021, though they are expected to change in the future. Any future changes will be reflected and updated in this document.

If you are using these IP addresses to allow imgix to access your origin assets, you can subscribe using this form to be alerted of any scheduled changes to the IP addresses.

This information can be used in a few different ways, such as putting imgix on an allowlist or setting up different security rules for requests coming from imgix.

Allowlisting imgix

Some customers prefer that their origin servers are not publicly accessible. In the case of S3, Azure and GCS Sources, imgix is able to successfuly retrieve assets from those protected buckets by using valid credentials entered on the Source configuration page. However, in the case of Web Folder and Web Proxy Sources, such security settings can prevent imgix from being able to retrieve images. If the service is unable to retrieve an image from the origin, then we will return a 403 error.

The best method of making sure imgix can pull assets from your origin is by allowlisting our user agent. Since our user-agent is not expected to change anytime in the future, this is the recommended method of allowlisting for future compatibility.

However, allowlisting by user-agent is not as secure as allowlisting by IP address. This is because the user-agent is easy to spoof, while the IP address is not.

Most origins have the ability to put imgix's user-agent or IP address on an allowlist.

Disable Rate Limits

It's common to have some security measures against a large number of synchronous requests to different URLs on your origin. This often manifests as an error being returned from your origin once the number of requests have reached a threshold from the same IP address.

With imgix, there is a low chance of this issue occurring since requests will often hit our cache more often than it will hit your origin. However, in cases where a large number of URLs are added or when a new Source is exposed to a large amount of traffic, it's not uncommon for your origin to impose a rate limit against imgix.

Such issues are often temporary. Regardless, if you have any rate limits in place, you may want look into exempting imgix from those limits.

Foreign Characters and Character Encoding

When file names use foreign characters, imgix will encode the file name and attempt to retrieve it at the encoded path. As a result, if that encoded path returns a 404​, imgix will also return the image as a 404. Ideally, the origin should automatically route the request to the encoded filepath.

Additionally, images that are served using encoded characters instead of the original characters can result in issues with purging. For example, images that are served with /%2f instead of / will be recognized as two different image URLs due to RFC spec 3.2.3 concerning URI comparisons. As a result, purging the image that uses encoded characters may not purge their non-encoded variants depending on whether or not URL unsafe characters are used.

AWS S3 supported regions

Amazon's Storage Service (S3) allows storing data at a specific geographical region. An imgix AWS S3 Source can connect to a bucket in one of the supported regions listed in the table below.

Region Name S3 Region
US East N. Virginia us-east-1
US East Ohio us-east-2
US West N. California us-west-1
US West Oregon us-west-2
Asia Pacific Hong Kong ap-east-1
Asia Pacific Mumbai ap-south-1
Asia Pacific Tokyo ap-northeast-1
Asia Pacific Seoul ap-northeast-2
Asia Pacific Osaka ap-northeast-3
Asia Pacific Singapore ap-southeast-1
Asia Pacific Sydney ap-southeast-2
Canada Central ca-central-1
EU Frankfurt eu-central-1
EU Ireland eu-west-1
EU London eu-west-2
EU Paris eu-west-3
EU Stockholm eu-north-1
South America Sao Paulo sa-east-1
Middle East Bahrain me-south-1