Explicit proxy firewall connection and timeout-Cloud Firewall(Cloud Firewall)-阿里云帮助中心

This topic describes the default connection behavior of the Explicit Proxy Firewall for client and origin server access. Use this information to plan for workloads that involve HTTP keep-alive, file transfers, and streaming calls.

Connection and timeout

Forward connection: The connection between a client and the Explicit Proxy Firewall.
Origin connection: The connection between the Explicit Proxy Firewall and the target server (origin server).

Future updates will gradually introduce support for customizing these parameters.

Forward connection parameters

Forward connection parameters control the reuse policy for client connections and define wait times during request and response handling.

Parameter	Default	Description
Request idle timeout	300 s	If no bidirectional data transfer occurs for a single request for 300 consecutive seconds, the request is terminated. This timeout applies during the request upload, response waiting, and response reception phases.
Tunnel idle timeout	300 s	After a `CONNECT` tunnel is established, it is closed if no bidirectional data transfer occurs for 300 consecutive seconds. This limit applies as long as the tunnel exists, even if there are no new HTTP requests within it.
HTTP keep-alive idle timeout	3600 s (1 hour)	If a connection has no active requests or tunnels and remains idle for this duration, it is reclaimed. Connections established through a `CONNECT` request are still subject to the 300-second tunnel idle timeout.
Keep-alive maximum lifetime	No limit	A connection is not closed for reaching a specific cumulative lifetime. The request idle timeout and tunnel idle timeout still apply.
Maximum requests per HTTP keep-alive connection	No limit	A connection is not closed for handling a specific number of cumulative HTTP requests. This parameter refers to the total number of requests, not the number of concurrent requests.
Request header receive timeout	30 s	The maximum time for receiving a complete request header is 30 seconds, starting from when reception begins. This applies to `CONNECT` requests, plaintext HTTP requests, and decrypted HTTPS requests. After the header is fully received, this limit no longer applies to request body uploads, waiting for an origin server response, or streaming transfers.
Total request receive duration	No separate limit	There is no separate limit on the total time to receive a full request (including the request body). A continuous upload can exceed 300 seconds, but a long pause in data transmission may still trigger the request idle timeout.
Response tail send timeout	300 s	For connections with flow control, if the full response has been generated but cannot be sent because the client has not freed up a sufficient receive window, the response is terminated after waiting for 300 seconds.

Scope

HTTP request-level parameters: Apply to plaintext HTTP requests processed by the Explicit Proxy Firewall and to requests with HTTPS decryption and inspection enabled.
Undecrypted HTTPS tunnels: The Explicit Proxy Firewall does not count or manage individual HTTP requests within a tunnel. Use the tunnel idle timeout to understand its connection behavior.

Timing rules

The request idle timeout and tunnel idle timeout are calculated independently based on consecutive idle time. You should not add them together to get a 600-second timeout.
Each connection or request is timed independently.

Origin connection parameters

Origin connection parameters control how the Explicit Proxy Firewall establishes, reuses, and retries connections to the origin server.

Parameter	Default	Description
Origin connection timeout	5 s	The maximum time to wait for a single attempt to establish a new origin connection. For HTTPS origin connections, this includes the time for TCP connection setup and the TLS handshake, but excludes the domain name resolution time.
Maximum total origin request duration	No limit	There is no fixed limit on the total duration, allowing an HTTP request to wait for a long time for the origin server to return a complete response. The request idle timeout still applies, and a continuously streaming response is not interrupted solely because it exceeds 300 seconds.
Origin HTTP keep-alive idle timeout	3600 s (1 hour)	If a reusable origin HTTP connection has no active requests and stays idle for this duration, it is reclaimed. Subsequent requests can establish a new connection.
Origin keep-alive maximum lifetime	No limit	The connection can still be terminated due to idle reclamation or closure by the origin server.
Maximum requests per origin HTTP keep-alive connection	No limit	The reuse of an origin HTTP keep-alive connection is not limited by the cumulative number of requests it has handled. Any connection and request limits set by the origin server itself still apply.
Maximum origin retry count	Up to 2 retries	Applies to plaintext HTTP forwarding and HTTPS forwarding with decryption and inspection enabled. When retry conditions are met, a request can be retried up to 2 times in addition to the initial attempt, for a maximum of 3 total HTTP forwarding attempts. Retries are not guaranteed for every failure. This HTTP request retry policy does not apply to undecrypted HTTPS tunnels.

Scope

The parameters for reusing origin HTTP keep-alive connections apply when the Explicit Proxy Firewall actively initiates HTTP requests. They do not apply to HTTP keep-alive connections maintained directly between the client and the origin server within an undecrypted HTTPS tunnel.

HTTP keep-alive and streaming calls

Idle timeout vs. total duration

Idle timeout: Limits the amount of time a connection can remain inactive with no data transmission.
Total duration: Limits the cumulative time elapsed from the start of a request to its end.

The Explicit Proxy Firewall has a default request idle timeout of 300 seconds and does not set a fixed upper limit for the total request duration. The default behavior in various scenarios is as follows:

Scenario	Default behavior
Uploading a file continuously for more than 5 minutes	The request is not terminated solely because the cumulative time exceeds 5 minutes. However, continuous read/write activity is required to keep the request active.
A streaming response lasts for 20 minutes with data returned periodically	The request is not terminated solely because the cumulative time exceeds 5 minutes.
After the request upload is complete, there is no read/write activity for 300 consecutive seconds	The request idle timeout may be triggered.
A streaming response has started, followed by 300 consecutive seconds of no read/write activity	The response is interrupted. The client may experience a read failure or receive an incomplete response.
A `CONNECT` tunnel has no data transmission for 300 consecutive seconds	The tunnel may be closed. Subsequent communication requires a new connection to be established.

Note

For scenarios like long-running inferences or Server-Sent Events (SSE), you can use protocol-level heartbeats or progress messages to maintain request activity. The heartbeat must be sent on the specific request stream. Merely keeping the TCP connection alive or sending connection-level probes is not guaranteed to reset the request idle timer.

Maximum vs. concurrent requests

The maximum number of requests per connection refers to the cumulative number of HTTP requests handled by a single connection over its lifetime. It is different from the number of requests that can be processed concurrently at any given moment.

Example: A connection that sequentially processes 1,000 requests has a cumulative request count of 1,000, but it might only be handling one request at a time.
Note: A 'no limit' setting for the maximum number of requests per connection does not imply that there are no limits on the instance's total connections, concurrency, or throughput.

Separate management of forward and origin connections

Forward connections and origin connections are established, reused, and closed independently. Even if a forward keep-alive connection persists, an idle origin connection may be reclaimed. For subsequent requests, the Explicit Proxy Firewall can select an existing origin connection or create a new one. Do not assume that the connections on both sides are always paired one-to-one or terminate simultaneously.

Additionally, both clients and origin servers can actively close connections. Even if the Explicit Proxy Firewall does not set a maximum lifetime or request limit for a connection, it does not guarantee that a connection will remain available indefinitely.

Client behavior after a timeout

Scenario	Client behavior
Receiving the request header takes longer than 30 seconds, or the request is not fully received and the request idle timeout is triggered	HTTP 408 or connection closed.
The request is fully received, but no response has been sent, and the request idle timeout is triggered	HTTP 504.
A timeout occurs after the response has started sending	The response is interrupted, the connection is closed, or a read fails. The status code received earlier might still be 200.
An origin connection cannot be established, and no more retries are available	HTTP 503 or tunnel establishment failure.
An idle tunnel is closed	The client needs to re-establish the tunnel. Whether it reconnects automatically depends on the client's implementation.

Troubleshooting

Clients, origin servers, and other services in the communication path may have shorter timeout settings. When troubleshooting, analyze the cause by considering the request phase, whether the response was complete, and the timeout settings on all sides. Do not rely solely on a status code to determine which specific timeout was triggered.