Cloudflare Proxy suddenly breaks our site

[srichter]

We’ve been running a busy SaaS app (hosted on heroku) utilising Cloudflare for DNS for years. Our setup consists of Full (strict) mode for SSL and we were proxying all domains to stop bots and threats. This setting hasn’t been touched in 3 years.

In early November, customers started to report problems. They encountered timeouts and slow page loads. These timeouts are random and often happen only after a few clicks on the site. A page can time out and then immediately load fine a second later.

We have eliminated our app as the source of this issue but haven’t totally eliminated SSL issues. We host our own wildcard certificate on heroku and this had been in place for 11 months when these issues started.

All issues are immediately resolved when we turn DNS proxying off. No timeouts or slow page loads occur without Cloudflare proxying turned on.

I also tested this setup using a Cloudflare Origin CA certificate on our server - same results.

Very often, the connection will stall for exactly 10 seconds, then the page will load. Sometimes it stalls longer and times out.

I’ve had 2 tickets open with Cloudflare and they have so far offered no help. they asked me about HAR files which I have supplied. In honesty, their support has been appalling so I am trying here now.

Attached is a screenshot of a typical stalled connection.
Any tips appreciated.

[srichter]

This example from Chrome is more obvious.

[maxence]

Have the same problem here in San Diego, AT&T.

I tried using Cloudflare WARP on my connection, the issue persists. Using a VPN sometimes fixes my issue.

[eportillo]

I have responded to your ticket # 3149321 with some information when you have a moment could you kindly take a look at the response.

[srichter]

Thanks for the info. I believe I may have seen another post of yours but couldn’t reply because of this stupid ‘we’ll close this topic after 15 days’ policy. Topic after topic remains unresolved as nobody can reply with the solution. It’s infuriating.

[sandro]

Quite the opposite actually, most threads (providing all the required information) are solved within minutes.

There’s a handful of threads which get closed after the default time and that’s mostly when the OP disappeared and did not respond any more. The number of threads which get closed because someone forgot to respond is neglible.

If you have an issue, you should simply open a new thread for that, as you did here. So I am not sure what’s infuriating. You opened this thread less than a day ago and already have a support ticket number.

[srichter]

I’ve received eportillo’s reply, however it suggests that my browser is stalling the connection. Yes it is, but my browser is just one example of where this happens, not the only example.

For the benefit of others, I will post my reply below.

Thanks but this doesn’t help me much and doesn’t make much sense when you think it through. Why would my browser take 10 seconds to issue a DNS lookup? The DNS entry is cached on the OS level. The stalling occurs after I’ve already navigated to that domain. Moreover, the problem occurs for multiple customers in multiple locations, it’s not specific to my machine and only occurs when Cloudflare proxy is enabled.

As soon as we enable Cloudflare proxy for a subdomain, customers all over the UK are reporting the same issue of timeouts and stalled connections.

Connections stall, even for the same page and even when that page worked immediately before. Sometimes they stall after a couple of clicks, sometimes it takes a dozen clicks. But it always stalls, reproducibly. Example screenshots below showing three back to back attempts for the same page.

If I access ANY other subdomain which isn’t proxied then this issue does not occur. How do you explain this, especially as this happens to customers all over the UK?

Lastly, and I do not if this is a clue, but his command to a proxied domain

curl -vI https://sub.domain.com

gives me

*  SSL certificate verify ok.
* using HTTP/2
* h2 [:method: HEAD]
* h2 [:scheme: https]
* h2 [:path: /]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* Using Stream ID: 1 (easy handle 0x7f9d89810000)
> HEAD / HTTP/2
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/2 403 
HTTP/2 403

Accessing another subdomain which isn’t proxied gives me

 SSL certificate verify ok.
* using HTTP/1.x
> HEAD / HTTP/1.1
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK

Note the HTTP/2 403 in the first request. Where does this come from? There is no 403 being issued by our app server. Using curl, I ALWAYS see this 403 when accessing a proxied subdomain.

Regards,

Stefan

(I am only allowed one embed to I will reply with the other two…)

[srichter]

Second request

[srichter]

And the third one

[srichter]

@sandro

If you have an issue, you should simply open a new thread for that, as you did here. So I am not sure what’s infuriating. You opened this thread less than a day ago and already have a support ticket number.

It’s infuriating because this isn’t how 99% of community help forums work. Many posts benefit from further info later on, often months or years later, not least because they show up in search results. Your claim that that there are only a handful of posts that were closed before being resolved it evidently untrue as I’ve found at least half a dozen on this exact topic alone. They were all shut down without a solution.

Maybe you should consider posting relevant, on-topic solutions rather than hijacking other people’s posts with what is objectively useless, off-topic feedback.

[sandro]

Maybe you should consider reading and following the community guidelines before letting out all your anger on people who volunteer their time here to help others.

I presume we can consider this issue resolved → closing

[cloonan]

@srichter

tickets open

Hi @srichter sorry for the issues you’ve encountered. I noticed your ticket 3149321 with the team and have copied myself on it to track progress.