We are seeing the same recurring issue with t3.storage.dev again.
Symptoms:
- requests to
https://t3.storage.devfail from some residential / ISP networks - browsers show
ERR_SSL_PROTOCOL_ERROR - botocore / SDKs fail with TLS / SSL validation errors
- switching the exact same workload to
https://fly.storage.tigris.devmakes it work immediately
This does not look like an app bug. It looks like t3.storage.dev is intermittently getting blocked / intercepted on some network paths.
Related threads:
- Using fly statics with Tigris serving static assets really slow - #5 by gangadhar
- Tigris is moving to virtual host style URLs for new buckets
- TLS certificate verification error when connecting to tigris (t3.storage)?
From the outside this seems to be a known recurring issue, not an isolated report.
Questions:
2. If t3.storage.dev is still recommended, what is the mitigation when ISPs / security vendors block or intercept it?
3. Should users proactively migrate away from t3.storage.dev for end-user traffic?
4. Can Fly/Tigris update the docs with a clear decision table:
- Fly app to Tigris
- public browser downloads
- presigned URLs
- custom domains
- non-Fly backends
Right now the safest operational move seems to be “use fly.storage.tigris.dev or a custom domain when t3.storage.dev is blocked”, but it would help to have an official long-term recommendation.