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?
@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.
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)