Timeouts requesting a cloudflare protected site - Not even headers are returned


#1

I have a plex server hosted in a data center in Atlanta that makes API calls to https://thetvdb.com. In the last few weeks, they have been failing.

I assumed that Cloudflare might be throwing up a CAPTCHA page or maybe the site blocked my machine, but when I curl the URL I don’t get an error page. I don’t even get a response header! This is using both http and https, so I’m pretty sure it’s not a SSL protocol version problem.

If I do the same, but force an IPv6 connection, everything works just fine. The exact same requests from my home machine work fine as well. I’ve verified that I have no applicable firewall rules, I’m not running any sort of proxy, and there are no manually entered addresses in /etc/hosts

All I can think is that there is something wrong with the edge server in the Ashburn datacenter. (which is odd in itself, my server is in Atlanta and Cloudflare has an edge location in Atlanta, but I’m still being routed to Ashburn Virginia.

Some stuff that might help figure out what the issue is…

[email protected] /u/l/p/R/P/T/Contents# wget --user-agent="Plex/Nine" --inet4-only --timeout=10 --tries=1 -S http://thetvdb.com
--2017-08-01 03:23:28--  http://thetvdb.com/
Resolving thetvdb.com (thetvdb.com)... 104.16.231.14, 104.16.230.14, 104.16.227.14, ...
Connecting to thetvdb.com (thetvdb.com)|104.16.231.14|:80... connected.
HTTP request sent, awaiting response... Read error (Connection timed out) in headers.
Giving up.
[email protected] /u/l/p/R/P/T/Contents# wget --user-agent="Plex/Nine" --inet4-only --timeout=10 --tries=1 -S https://thetvdb.com
--2017-08-01 03:23:44--  https://thetvdb.com/
Resolving thetvdb.com (thetvdb.com)... 104.16.231.14, 104.16.230.14, 104.16.227.14, ...
Connecting to thetvdb.com (thetvdb.com)|104.16.231.14|:443... connected.
Unable to establish SSL connection.
[email protected] /u/l/p/R/P/T/Contents# wget --user-agent="Plex/Nine" --inet6-only --timeout=10 --tries=1 -S https://thetvdb.com
--2017-08-01 03:30:57--  https://thetvdb.com/
Resolving thetvdb.com (thetvdb.com)... 2400:cb00:2048:1::6810:e30e, 2400:cb00:2048:1::6810:e70e, 2400:cb00:2048:1::6810:e60e, ...
Connecting to thetvdb.com (thetvdb.com)|2400:cb00:2048:1::6810:e30e|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Tue, 01 Aug 2017 03:30:57 GMT
  Content-Type: text/html
  Transfer-Encoding: chunked
  Connection: keep-alive
  Set-Cookie: __cfduid=d95ada420c74f9d456e63ac5cfcaef3531501558257; expires=Wed, 01-Aug-18 03:30:57 GMT; path=/; domain=.thetvdb.com; HttpOnly
  X-Powered-By: PHP/5.3.10-1ubuntu3.15
  Set-Cookie: PHPSESSID=gt93o8mj59p186dv6l94e0ji57; path=/
  Expires: Thu, 19 Nov 1981 08:52:00 GMT
  Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
  Pragma: no-cache
  Vary: User-Agent,Accept-Encoding
  Server: cloudflare-nginx
  CF-RAY: 3875b8c55f75575f-IAD
Length: unspecified [text/html]
Saving to: ‘index.html’
[email protected] /u/l/p/R/Plug-ins-42bd8c63f# ping thetvdb.com
PING thetvdb.com (104.16.231.14) 56(84) bytes of data.
64 bytes from 104.16.231.14: icmp_seq=1 ttl=58 time=15.9 ms
64 bytes from 104.16.231.14: icmp_seq=2 ttl=58 time=15.9 ms
64 bytes from 104.16.231.14: icmp_seq=3 ttl=58 time=15.9 ms
64 bytes from 104.16.231.14: icmp_seq=4 ttl=58 time=15.9 ms
traceroute to thetvdb.com (104.16.227.14), 64 hops max
  1   10.40.170.254 (10.40.170.254)  0.297ms  0.207ms  0.426ms 
  2   40.135.62.200 (h200.62.135.40.static.ip.windstream.net)  2.148ms  2.130ms  2.102ms 
  3   169.130.170.174 (169.130.170.174)  2.334ms  2.318ms  2.326ms 
  4   169.130.169.14 (169.130.169.14)  2.374ms  2.350ms  2.342ms 
  5   40.132.59.34 (ae10.cr02.asbn01-va.us.windstream.net)  16.658ms  16.161ms  16.135ms 
  6   40.128.10.172 (ae13-0.cr01.asbn01-va.us.windstream.net)  17.006ms  17.019ms  17.006ms 
  7   206.126.237.30 (13335.ash.equinix.com)  15.767ms  15.768ms  15.802ms 
  8   104.16.227.14 (104.16.227.14)  15.793ms  15.786ms  15.780ms 

Any thoughts or help would be great!


#2

We publish BGP information to the telcos/ ISPs to help them determine where that closest DC is since we’re an anycast network. I don’t see any issues listed for the Atlanta DC so I suspect it is potentially a routing issue with the telco provider the datacenter hosting provider is using or an issue with the datacenter provider’s router. Or it could be an issue with the route we published (don’t want to pass the buck entirely).

i don’t see any issues listed with the Atlanta datacenter… https://www.cloudflarestatus.com/ at the moment. But that doesn’t mean it couldn’t be us somehow.

I would recommend opening a ticket with support (this is great troubleshooting information by the way). You might also include a tracert for the iPv6 traffic as that’s the only thing I don’t see above, and it might show a different route for that traffic which could lend support to y WAG that it is a BGP issue.

Short term to work around the issue? You might try a hosts file on your Plex server with the IPv6 address to force it that route. Maybe?

… and now I need to find time to get my Plex server rebuilt. :smiley: