"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.