When imgix receives a request for an asset 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.
The asset 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 cache TTL is 5 minutes. imgix will cache error responses according to the error cache TTL set in your Source settings.
Once the asset 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 asset causing the error code has been served successfully.
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 identify 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.
These elastic IP addresses are current as of May 4, 2023, 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.
Some customers prefer that their origin servers are not publicly accessible. In the case of S3, Azure, and GCS Sources, imgix is able to successfully 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 assets. If the service is unable to retrieve an asset from the Origin, then we will return a
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.
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 has 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 they 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 to look into exempting imgix from those limits.
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 asset as a
404. Ideally, the Origin should automatically route the request to the encoded file path.
Additionally, assets that are served using encoded characters instead of the original characters can result in issues with purging. For example, assets that are served with
/%2f instead of
/ will be recognized as two different asset URLs due to RFC spec 3.2.3 concerning URI comparisons. As a result, purging the asset that uses encoded characters may not purge their non-encoded variants depending on whether or not URL unsafe characters are used.
Amazon's Storage Service (S3) allows for storing data in 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.
|US East||N. Virginia||us-east-1|
|US West||N. California||us-west-1|
|Asia Pacific||Hong Kong||ap-east-1|
|South America||Sao Paulo||sa-east-1|
Imperva is a well-known security platform that is commonly used to protect access to online assets.
One of their security features is to block and prevent access to assets by bots. This is done by sending a "garbage" cookie header value which prevents the bot from completing a request.
Unfortunately, this security feature also blocks the imgix rendering service from accessing files from an Imperva-fronted Origin. Unless it is properly configured, requests to an imgix Source using an Imperva Origin can return a
To prevent this issue, we recommend either:
- Bypassing Imperva by connecting your imgix Source directly to the Origin
- Allowlisting imgix so the imgix rendering service can access assets through Imperva
- Contacting Imperva support to turn off the security feature that blocks bot access
IPFS stands for Interplanetary File System and is a decentralized file system that relies on a peer-to-peer hypermedia protocol.
Due to the nature of IPFS, timeout errors can be observed for a small number of Origin fetches to an IPFS Origin, depending on which peer is returning the file. These errors are related to the timing response and availability of a file as we fetch the file from the Origin, and are expected to succeed on subsequent retries as long as the file is available.
Once a file is fetched, it will be cached in the imgix rendering service for some time, reducing the chances of timeout errors and the number of calls to the IPFS Origin.
You can reduce the number of requests to IPFS Origins and therefore increase your deliverability success rate by optimizing your caching settings in your imgix Source. The suggested value for cache TTL is one year.