"Below is the verbose output of the curl command I executed:

❯ curl -v "https://api.themoviedb.org/3/movie/550?api_key=api_key_here"
* Host api.themoviedb.org:443 was resolved.
* IPv6: 2600:9000:269a:1800:c:174a:c400:93a1, 2600:9000:269a:6000:c:174a:c400:93a1, 2600:9000:269a:7200:c:174a:c400:93a1, 2600:9000:269a:7a00:c:174a:c400:93a1, 2600:9000:269a:9600:c:174a:c400:93a1, 2600:9000:269a:9800:c:174a:c400:93a1, 2600:9000:269a:b600:c:174a:c400:93a1, 2600:9000:269a:e600:c:174a:c400:93a1
* IPv4: 3.160.188.33, 3.160.188.44, 3.160.188.49, 3.160.188.68
*   Trying 3.160.188.33:443...
* Connected to api.themoviedb.org (3.160.188.33) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to api.themoviedb.org:443
* closing connection #0
curl: (35) Recv failure: Connection reset by peer

Facing similar, has something changed in API?

I am seeing the same thing on IPv4 and IPv6. Intermittent failures with a TCP reset during TLS handshake. More details

content-type: application/json; charset=utf-8
< date: Sun, 11 May 2025 02:29:07 GMT
< server: openresty
< cache-control: public, max-age=300
< x-cache: Error from cloudfront
< via: 1.1 7f494376132d92ea6c165caa8a824d7a.cloudfront.net (CloudFront)
< x-amz-cf-pop: TLV50-C1
< alt-svc: h3=":443"; ma=86400
< x-amz-cf-id: nTs85Gl7aEnLWj8wRXk3Z1vXbVDwQOa3jWfZbWU8aviowPFmjCtj1A==
< vary: Origin
<

Looks like TMDB is just using cloudfront so it's a bit strange it would fail with tcp conn reset.

This traceroute further highlights the issue. With the amount of evidence and reports shared in this thread, it's clear that the problem is well-documented. Hopefully, we’ll receive a response soon and TMDb will address it on their end.

+----+-----------------------------------------------+--------+------+--------+-------+--------+-------+--------+
| #  | Host                                          | Loss%  | Snt  | Last   | Avg   | Best   | Wrst  | StDev  |
+----+-----------------------------------------------+--------+------+--------+-------+--------+-------+--------+
| 1  | 140.91.204.73                                 | 0.0%   | 102  | 0.2 ms | 0.2   | 0.2    | 0.3   | 0.0    |
| 2  | 125.17.12.178                                 | 0.0%   | 102  | 1.4 ms | 2.3   | 1.4    | 20.7  | 2.7    |
| 3  | 125.17.12.177                                 | 0.0%   | 102  | 1.6 ms | 3.2   | 1.5    | 23.3  | 4.0    |
| 4  | 116.119.119.92                                | 0.0%   | 102  | 99.6ms |101.1  | 99.3   |119.4  | 4.3    |
| 5  | (waiting for reply)                           |        |      |        |       |        |       |        |
| 6  | (waiting for reply)                           |        |      |        |       |        |       |        |
| 7  | (waiting for reply)                           |        |      |        |       |        |       |        |
| 8  | (waiting for reply)                           |        |      |        |       |        |       |        |
| 9  | (waiting for reply)                           |        |      |        |       |        |       |        |
|10  | server-3-160-188-33.mrs52.r.cloudfront.net    | 0.0%   | 101  | 97.3ms | 97.2  | 97.1   | 97.6  | 0.1    |
+----+-----------------------------------------------+--------+------+--------+-------+--------+-------+--------+

I created a RIPE measurement to test this and it's a much more widespread problem. Almost all of them returned tls handshake failure https://atlas.ripe.net/measurements/102768292/results

@Baked2783 You need to make sure to fill out the "hostname" field under the "more options" dropdown on the probe since we use SNI. Once you do, you can see below that everything looks fine:

https://atlas.ripe.net/measurements/102990217/results

With regards to the issue being discussed, it's hard to say what's gong on. One thing I've seen happen on multiple occasions is different blocks and routing issues caused by local ISP's. Take India for example, we've been on and off multiple ISP block lists for years. The forums are full of reports from Indian users regarding this.

One thing that has helped a lot of other users out (in India) is using a custom DNS server. We've seen problems with Cloudflare, so I don't usually recommend them, but I haven't seen many issues with Google (8.8.8.8) or Quad9 (9.9.9.9).

With regards to the issue being discussed, it's hard to say what's gong on. One thing I've seen happen on multiple occasions is different blocks and routing issues caused by local ISP's. Take India for example, we've been on and off multiple ISP block lists for years. The forums are full of reports from Indian users regarding this.

One thing that has helped a lot of other users out (in India) is using a custom DNS server. We've seen problems with Cloudflare, so I don't usually recommend them, but I haven't seen many issues with Google (8.8.8.8) or Quad9 (9.9.9.9).

Thanks for the reply. If it were an ISP-level block, I would expect the requests to consistently fail or not get any response at all. In my case, though, the failures are intermittent - around 7 or 8 times out of 10, which makes it a bit more confusing.

Also, most of the reports I've come across from India seem to be related to the ISP Jio. My IP is based in Mumbai, India as well, but it's routed through the Oracle network (VPS), not Jio. I also tried switching to Google's DNS (8.8.8.8), but unfortunately, that hasn’t made any noticeable difference, the intermittent failures persist.

Ya, it was just something to try as I have seen it help lots of users in the past.

Here's two more measurements (50 probes each) done in India alone (this brings the total up to 150 tests with my other one above):

• IPv4 (2 failed, both on Jio)
• IPv6 (4 failed on Jio, 1 failed on Atria, and 1 failed on Nib)

All of these failures were failures to connect though, not anything to do with TLS and/or the issue described above.

In my case, the isp is airtel and they are blocking access. Jio is working fine. I am trying to get a ticket created with them to get this fixed. It's so annoying. ECH can not come soon enough

Ya, for the hell of it, I did two separate tests:

• Jio (about a 50% failure rate)
• Airtel (actually seems ok)

But truthfully, there aren't that many Jio or Airtel probes, so our testable surface area is small.

@travisbell facing same issue on oracle (Mumbai, India) vps, the same website works fine in netcup nuremberg vps

@travisbell facing same issue on oracle (Mumbai, India) vps, the same website works fine in netcup nuremberg vps

It seems like the issue is specific to the Mumbai-based VPS on Oracle Cloud, as testing from other VPS locations on Oracle Cloud works without any problems. This indicates that access may be blocked or throttled specifically for that region. I'll try reaching out to them to investigate and resolve this issue. However, it might be more effective if more users report similar problems.

In the meantime, does anyone know of an alternative mirror API for The Movie Database that we can use as a workaround?

@xd003 said:

@travisbell facing same issue on oracle (Mumbai, India) vps, the same website works fine in netcup nuremberg vps

It seems like the issue is specific to the Mumbai-based VPS on Oracle Cloud, as testing from other VPS locations on Oracle Cloud works without any problems. This indicates that access may be blocked or throttled specifically for that region. I'll try reaching out to them to investigate and resolve this issue. However, it might be more effective if more users report similar problems.

Yea i tried curl and connection reset by peer on most of them