Hi everyone. I'm trying to access our internal financial reporting app through Cloudflare One. Recently, I keep getting gateway timeout errors after a few minutes of use. It happens consistently when generating larger reports.
I've checked our basic Zero Trust policies, and the app is listed and accessible. Are there specific settings for longer-lived connections or data-heavy internal apps? Any known fixes or timeouts I should adjust? Still learning...
Trying to figure it out.
Your basic policies probably aren't the issue. You're hitting a default idle timeout, likely 30 minutes on the WARP session, but that's not your real problem.
The gateway timeout after a few minutes of generating a large report points to a TCP or HTTP idle timeout on the specific tunnel or application policy. It's waiting for a response from your app server and giving up. Check your Cloudflare Tunnel configuration for the app; the default timeouts are aggressive for legacy systems. You'll need to adjust them on the tunnel side, not just the Zero Trust access policy.
It's also worth asking if your internal app is actually built for WAN latency. Financial reporting apps often assume a LAN and hold connections open for ages.
Your mileage will vary
Exactly. The tunnel's idle timeouts are often the culprit. The default HTTP idle timeout for a Cloudflare Tunnel is only 90 seconds. For a long-running report generation, that's a blink.
You mentioned adjusting them on the tunnel side. For anyone reading, that's in your `cloudflared` config under the `ingress` rule for that service, using `originRequest` settings. You'll want to increase `httpOriginTimeout` and likely `connectTimeout` too.
But the WAN latency point is critical. Even with longer timeouts, if the app server isn't sending periodic keep-alive data, the connection can still be seen as idle and be cut. You might need to tune the app or the origin web server's keep-alive settings as well.
ms matters
Right on the money. I had this same headache with a legacy CRM system. Tweaking the `httpOriginTimeout` in the tunnel config was the fix, but the WAN latency point is what really sticks with you.
We found that even with a generous timeout, the app's own session handling would sometimes create a new, separate connection for a background process, which could then get blocked. It's not just about keeping the main connection alive. You might need to check if the app is spawning any secondary requests during that report generation.
You're looking at the right place. The first thing to check is the idle timeout on your WARP session, but like others said, that's probably not the real fix for a process that's actively running.
For a data-heavy report, you need to adjust the tunnel's origin timeouts. The default HTTP idle timeout is only 90 seconds, which is nothing for a financial report. You'll find those settings in the `originRequest` part of your tunnel config.
But here's the caveat: if your internal app was designed for the office LAN, it might not send any data back to the client until the entire report is done. To the tunnel, that looks like an idle connection, even though the server is busy. You might need to tweak the app or its web server to send periodic keep-alives.
—JW