Cloudflare Websocket Timeout?

General
#1

Hello! I’m currently testing out passing websocket connections through Cloudflare. They’re working great but I have a problem where they persistently die after exactly 1 minute and 40 seconds, always.

I have my own nginx server set to timeout after 5 minutes, so it’s not a problem on my end. Either this is a Chrome limitation or something on Cloudflare’s end, at least - I think so. Does anyone know the exact timeout limit for websockets passed through Cloudflare, does upgrading to Pro remove this timeout?

Thanks!

#2

100 seconds is the standard timeout setting. Only ENT users have the option to adjust duration.
https://support.cloudflare.com/hc/en-us/articles/200171926-Error-524-A-timeout-occurred

2 Likes
#3

Thanks, we resolved the issue by adding a keepalive healthcheck to our application so the connection is kept active. :slight_smile:

1 Like
#4

The problem of how you solve, is facing the same problem.

thank you.

#5

I am facing similar issue and mentioned solution and details with steps here:

#6

Could you please share how did you solve this issue in your code? Thx. We got same issues using standard plan and prefer to add healthycheck in code.

#7

@user11373 It depends on what WebSocket client you are using, and what kind of endpoint is on your server. (you don’t want to send random junk over the websocket, else your server might get confused and raise an error)

In my case, the client is “apollo-client”, in a JavaScript website, calling to a GraphQL server. First I added a “Ping” resolver to my GraphQL server, then I wrote the code below to call this resolver from my JS frontend:

async function SendPingOverWebSocket() {
	const fetchResult_subscription = apolloClient.subscribe({
		query: gql`
			subscription {
				_Ping {
					pong
				}
			}
		`,
		variables: {},
	});
	const fetchResult = await new Promise<FetchResult<any>>(resolve=>{
		const subscription = fetchResult_subscription.subscribe(data=>{
			subscription.unsubscribe(); // unsubscribe as soon as first (and only) result is received
			resolve(data);
		});
	});
	console.log("Got response to ping:", fetchResult);
	return fetchResult;
}
setTimeout(()=>SendPingOverWebSocket(), 90000);

Naturally, you will have to adjust the graphql query (or even the message-type in general, if your server is not GraphQL) in order for your particular server to be able to understand/not-get-confused-by your sending of heartbeat/ping messages.

#8

Actually, it’s probably best to set the timer interval to 45 seconds rather than 90 seconds.

This will cause it to reliably run within each 60 second timer-interval that hidden/non-focused pages are restricted to after five minutes: Heavy throttling of chained JS timers beginning in Chrome 88 - Chrome Developers

I have tested with timeouts of 90s and 45s in my app, and only the 45s version reliably kept the websocket alive, when the page is put into the background (ie. hidden) for more than 5 minutes. (though note that my testing was fairly short)