Connection timed out :(

[Phobia]

Hi everyone! In the last few days I have noticed that my API requests to twitch started to return empty due to timeout.

Previously I was using php-function file_get_contents, then I tried PHP cURL with 15/20/30 seconds timeout, but the result is the same - I am still often getting timeout error. I have contacted support of my hosting provider to check if issues are on his side, but I was told that they don’t have any restrictions towards such connections.

I am using this code:

$twitch_url = "https://api.twitch.tv/kraken/streams?channel=podox";

$curl = curl_init();

curl_setopt_array($curl, array(
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_TIMEOUT => 20,
CURLOPT_URL => $twitch_url,
CURLOPT_HTTPHEADER, array('Accept: application/vnd.twitchtv.v3+json', 'Client-ID: pl836qnipah4g727hbvmgcyyunsnpe9')));

$data = curl_exec($curl);
var_dump($data);

if ($data === false)
print_r(curl_error($curl));

curl_close($curl);

curl_error often says “connect() timed out!”. So I am wondering what can be the cause of these timeouts and is there any way to get rid of them? Thanks in advance.

[BarryCarlyon]

Sounds like the host/box you are using is having a SSL Negotiation issue issue of some description.

Turn on CURLOPT_VERBOSE and see if you are getting a SSL issue.

[Maeglin]

I’ve been seeing the same thing, and can even give an exact time when it started. I have a bot that uses the Perl POE framework for IRC and Twitch API connections, and since 10:45 PM EST on January 21st nearly every (there have been a few that succeeded) request to the /streams/:channel endpoint has failed with an empty response as the OP is describing. I haven’t seen any evidence of a timeout, just a connection error and empty response. There have been 503 (service unavailable, most recently with “Backend server is at capacity”) and 500 (internal server error) responses as well.

I call /streams/:channel (detection of my own streaming) and /channels/:channel/follows (new follower detection) once a minute, and (when I’m offline, as it’s part of my auto-host system) /streams at most once every 3 minutes. The latter 2 sometimes fail for similar reasons, but they don’t get anywhere close to the “nearly every request” failure rate that I’m seeing with the first one. With that calling frequency, it’s hard to believe I’m being rate limited, and even then I’d expect to get a non-empty response.

Unfortunately, with Perl POE, I’m not sure how to check for any SSL issues. There is a debug switch in its HTTP client, but that doesn’t report anything at all about SSL, success or failure.

[BarryCarlyon]

Sounds like SSL.

First thing to check is that your server time is set right, but without SSL debug I can’t be sure.

If you are getting 50x response that’s Twitch tripping up.

But my responses have generally been good. Very little fail in the frame you report

[Maeglin]

I forced a time sync and it was about 5 minutes fast. I’ll give it 24 hours, which should be more than enough time for something to fail if it’s going to.

[Maeglin]

It does indeed look like an SSL problem, but on the server side.

It seems like I’ve gotten the error rate down to zero by hacking the HTTP library my bot uses and forcing it to send only one request per connection, instead of trying to re-use connections. Persistent connections were working perfectly well for 2.5 months (since the bot first came online), and then 10:45pm EST last Thursday happened. I don’t know what changed, but it wasn’t on my end.

That said, persistent HTTPS connections should work. To not allow them has been considered bad practice for at least the last 5 years.

[Maeglin]

A suggestion to @Phobia:
Among the cURL options you’re setting, try setting CURLOPT_FORBID_REUSE to TRUE. If that works, the problem is the same one I’m having.

[Maeglin]

Almost 31 hours since that last change, and the only failure was a 503 error on /streams/:channel around an hour ago.

[twoscomplement]

I’ve made some adjustments to the config on the edge to address this. My own tests have shown that the response rate has improved. Can you retry your test with persistent connections?

[Phobia]

Ok, so I simply tried the same code on other hosting and everything was working well there, so I just switched hosting Thanks for advice guys.

[BarryCarlyon]

In your case @Phobia your host appears to be missing some SSL Certs in it’s cert bundle. There are a variety of reasons for this. The usual work around is get a “better” host or apply the cert yourself (it’s lying around on Github somewhere), and add it as a curl opt.