Apache mod_proxy_fcgi Connection Reuse: Configuring enablereuse, Worker Pools, and flushpackets in Apache 2.4

In Apache HTTP Server 2.4, the mod_proxy_fcgi module provides FastCGI protocol support. By default, mod_proxy_fcgi disables connection reuse: after a request is completed, the connection is not held open by that httpd child process and will not be reused. Administrators can opt in to connection reuse when the FastCGI backend can handle concurrent connections from httpd. When enabling persistent connections, worker pool sizing must be evaluated to prevent worker starvation. Additionally, response streaming settings can be configured to manage how output is dispatched to the client.

How Connection Reuse Works with enablereuse in Apache 2.4

The documentation for mod_proxy_fcgi states that connection reuse requires the FastCGI application to handle concurrent connections from httpd. Because mod_proxy_fcgi disables reuse by default, administrators opt in using the enablereuse=on parameter, available in Apache 2.4.11 and later. This parameter is the inverse of disablereuse and is provided as a convenience for scheme handlers that require opt-in connection reuse.

A basic reverse proxy configuration enabling persistent connections to a standalone FastCGI application instance is defined as follows:

ProxyPass "/myapp/" "fcgi://localhost:4000/" enablereuse=on

When requests are routed through a handler pass-through using SetHandler and a Unix domain socket, defining a matching worker allows Apache to map URIs to filenames while managing pooled connections:

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/"
</FilesMatch>

<Proxy "fcgi://localhost/" enablereuse=on max=10>
</Proxy>

When connection reuse is enabled, each backend domain is resolved with a DNS query only once per child process. That DNS resolution is cached for all further connections until the child process is recycled.

Worker Connection Pooling Across MPMs

As documented in mod_proxy, connection pools are maintained per web server child process. Settings such as max are not coordinated among all child processes, unless only a single child process is allowed by configuration or Multi-Processing Module (MPM) design.

The active MPM dictates how connection pooling operates:

• Prefork MPM: Connections to backends are not pooled because each child process handles only one connection at a time. The max parameter is always 1. Sizing and acquisition parameters such as min, smax, hmax, and acquire have no effect or are ignored.
• Threaded MPMs (such as worker or event): With enablereuse=on, mod_proxy maintains a connection pool per child process. The default limit for max is governed by the ThreadsPerChild directive.

Documented Concurrency Behavior with PHP-FPM

The mod_proxy_fcgi documentation highlights specific capacity interactions when using threaded MPMs alongside PHP-FPM. PHP-FPM uses a prefork model where each worker process handles one connection at a time. Under HTTP/1.1 load, threaded MPMs can create up to MaxRequestWorkers connections to the FastCGI backend. Under HTTP/2 load, mod_http2 introduces additional h2 worker threads, which can raise the overall connection count across pools beyond MaxRequestWorkers.

If the maximum number of PHP-FPM worker processes is not configured with adequate capacity, PHP-FPM workers can become occupied servicing idle persistent connections. If all backend workers are busy handling idle persistent connections, no capacity remains for new connections, resulting in HTTP request timeouts.

Controlling Response Streaming: flushpackets and flushwait

For protocols supported by flushpackets (documented as currently in effect only for mod_proxy_fcgi and mod_proxy_ajp), mod_proxy controls how the output brigade is dispatched to the client:

• off (default): Flushes the output brigade only when needed.
• on: Automatically flushes the output brigade after each chunk of data is sent.
• auto: Polls or waits for a period of time and flushes the output brigade if no input has been received for the duration specified by flushwait.

When flushpackets=auto is configured, the flushwait parameter determines how long Apache waits for additional input in milliseconds before flushing. The default value is 10 milliseconds.

The following example configures a worker with persistent connections and chunk flushing enabled:

ProxyPass "/stream/" "fcgi://localhost:4000/" enablereuse=on flushpackets=on

ProxyPassMatch and Regular Expression Behavior

When proxying via ProxyPassMatch using a URL with backreferences, specific rules govern connection reuse. Beginning in Apache HTTP Server 2.4.47, key-value parameters are no longer ignored in ProxyPassMatch directives using URLs with backreferences. However, to preserve existing behavior regarding connection reuse for those URLs, enablereuse defaults to off (and disablereuse defaults to on).

In the general mod_proxy architecture, to enable connection pooling for regular expression matching, the documentation notes that defining an explicit worker for the backend URL separately ensures the pool is available for matching requests. The general mod_proxy documentation illustrates this mechanism using an HTTP origin worker:

ProxyPass "/notused" "http://backend.example.com/" connectiontimeout=5 timeout=30
ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com/$1"

Alternatively, in mod_proxy_fcgi configurations using ProxyPassMatch without backreferences in the backend target URL, parameters such as enablereuse=on can be set directly on the directive:

ProxyPassMatch "^/myapp/.*\.php(/.*)?$" "fcgi://localhost:9000/var/www/" enablereuse=on

Research Method and Limitations

This technical answer was prepared directly from visible public documentation excerpts for Apache HTTP Server 2.4 modules mod_proxy and mod_proxy_fcgi. No external laboratory tests, production benchmarks, or hands-on measurements were conducted. Competing coverage was unavailable in the source data, and passages containing ellipses or excerpt boundaries were evaluated strictly within their visible text without inferring unseen content. Configuration deployment should be validated against the specific target Apache HTTP Server version.

Source references

• httpd.apache.org documentation
• httpd.apache.org documentation