Troubleshoot policy and rule errors

This page describes how to diagnose and resolve common errors related to Secure Web Proxy policies and rules.

Secure Web Proxy gateway doesn't have an associated policy

If your Secure Web Proxy gateway isn't associated with a policy, then all outbound HTTP and HTTPS traffic is blocked, leading to 403 Forbidden errors or connection resets. This occurs because Secure Web Proxy follows a deny-all posture by default and the gateway doesn't have any associated rules to evaluate or authorize requests. As a result, all outbound traffic is blocked until you create an explicit allow rule.

To resolve this issue, create a security policy with the appropriate rules and associate them with your Secure Web Proxy gateway.

Parallel rule creation failures

Creating Secure Web Proxy rules in parallel (adding multiple rules simultaneously) isn't supported and can result in 409 Conflict or Resource busy errors. To make sure that your Secure Web Proxy instance is successfully deployed, you must create the rules sequentially (one after another).

Connections terminate after five minutes of inactivity

If client applications experience connection resets or unexpected terminations on persistent connections (such as streaming sessions, database connections, or WebSockets) through Secure Web Proxy, then these connections might be exceeding the stream idle timeout.

Secure Web Proxy enforces a default, non-configurable stream idle timeout (stream_idle_timeout) of five minutes (300 seconds). If the client and destination don't exchange data for five minutes, Secure Web Proxy resets or closes the connection.

To prevent connections from closing due to stream inactivity, configure your client or backend application to send keepalive probes or heartbeats (such as TCP keepalives, HTTP ping frames, or periodic health requests) at intervals under five minutes. For example, you can send a probe every one to two minutes.

What's next