iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Apache has several timeout controls, and the right one depends on where the delay occurs. Use TimeOut for general Apache I/O, ProxyTimeout when Apache is waiting for a proxied application server, and RequestReadTimeout for slow TLS handshakes, request headers, or upload bodies.
TimeOut 120
ProxyTimeout 120
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500Put the directive in the active server configuration or the relevant <VirtualHost>, test the configuration, then reload Apache. Do not raise every timeout by default: a longer limit can let legitimate slow work finish, but it can also keep connections and worker capacity occupied for longer.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall
Which Apache timeout do you need?
Apache timeout errors are often blamed on one setting even though different parts of a request are controlled independently. First identify which side is slow and what Apache is waiting to do.
| Observed delay | Directive | What it controls | Typical result when it expires |
|---|---|---|---|
| Apache is waiting for client data, a client acknowledgment, CGI output, or an external filter | TimeOut |
General Apache I/O operations | The current operation fails; the exact client-facing error depends on the request stage |
| Apache is waiting for a reverse-proxy application server | ProxyTimeout |
Network waiting time for proxied requests | Often a gateway or proxy timeout such as HTTP 504 |
| A client sends a TLS handshake, headers, or an upload body too slowly | RequestReadTimeout |
Receive stages and optional minimum data rates | Apache can return HTTP 408 Request Time-out |
These directives are not interchangeable. Increasing TimeOut does not automatically make a slow upload acceptable when mod_reqtimeout is terminating the receive stage. Conversely, increasing RequestReadTimeout does not extend the time Apache will wait for a backend application to produce a response.
#1 Best Overall
What TimeOut controls
Apache HTTP Server 2.4 documents TimeOut as the length of time httpd waits for I/O in several circumstances. Its syntax is TimeOut seconds, the documented default is 60 seconds, and it can be set in server configuration or virtual-host context.
The core timeout covers waiting for a client TCP packet while the read buffer is empty, waiting for a client acknowledgment when the send buffer is full, individual output blocks from CGI or mod_cgid, and output from an external filter. Use it when logs or the symptom show that one of these general Apache operations is exceeding the current limit and no more specific module directive applies.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsA value such as TimeOut 120 changes the limit to 120 seconds in the scope where it is declared. It does not mean every request always lasts 120 seconds; it is a maximum wait for the covered I/O operation. Raising it can help a slow CGI report or a high-latency client, but idle or stalled connections can retain processes, threads, or event-loop resources longer.
Global versus virtual-host scope
Place TimeOut 120 in the main server configuration when all hosted sites should use the same policy. Put it inside one <VirtualHost> when only that site needs a different value:
<VirtualHost *:443>
ServerName reports.example.test
TimeOut 120
# Other directives for this virtual host
</VirtualHost>The effective value is determined by the configuration Apache actually loads. An included file, a later directive, or a virtual-host-specific setting can make an earlier edit appear to have no effect. Check the complete loaded configuration rather than assuming the first matching line wins.
What ProxyTimeout controls
ProxyTimeout seconds is the mod_proxy setting for a proxied request. Apache documents its default as the current TimeOut value, and its context is server configuration or virtual host. It is intended for cases where an application server is slow or temporarily unable to answer and Apache should wait for a defined period before failing.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
- Used Book in Good Condition
For example, a reverse-proxy virtual host can use:
<VirtualHost *:443>
ServerName app.example.test
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyTimeout 120
</VirtualHost>This controls Apache’s network wait for the proxied request. It does not change the upstream application’s own request, database, queue, or worker timeout. If the application terminates its job after 30 seconds, setting ProxyTimeout 120 cannot make that application run for two minutes. Likewise, a load balancer or client in front of Apache may have a shorter limit and still close the connection first.
Why a 504 can remain after changing Apache
A 504 Gateway Timeout generally means a gateway or proxy did not receive a timely response from an upstream service, but the component producing the 504 must be identified. Check Apache’s error log and the upstream application’s log at the same timestamp. If Apache logs an upstream timeout, adjust ProxyTimeout only after confirming that the backend is expected to take longer. If the backend itself reports a request timeout, fix that application’s setting or workload instead.
What RequestReadTimeout controls
The mod_reqtimeout module provides timeouts and minimum data rates for receiving requests. Its syntax is RequestReadTimeout handshake=... header=... body=..., and it can be set globally or inside a virtual host.
For Apache 2.4, the documented default is:
RequestReadTimeout handshake=0 header=20-40,MinRate=500 body=20,MinRate=500The stages have different purposes:
- handshake limits the TLS handshake receive stage. Handshake-stage support was added in HTTPD 2.4.39.
- header limits the time spent receiving HTTP request headers.
- body limits the request body, which includes an upload.
The module exists in HTTPD 2.2.15 and later. A stage value of 0 removes that stage’s limit. A fixed value such as header=10 gives the entire header stage a 10-second limit. A range such as header=10-30,MinRate=500 starts with 10 seconds, allows the permitted time to grow as data arrives at the stated minimum rate, and caps the stage at 30 seconds. When a stage expires, Apache sends HTTP 408 Request Time-out.
Minimum-rate controls are useful because they distinguish a slow but progressing client from a connection that has stopped sending. They should still be selected carefully: a very low rate or a very long cap can make it easier for abandoned connections to consume resources.
How to change an Apache timeout safely
- Confirm the Apache installation and version. Run the version command provided by your package, such as
apachectl -v,apache2ctl -v, orhttpd -v. This confirms whether the documented 2.4 defaults and handshake-stage behavior apply. - Locate the active configuration. Common layouts include a main file under
/etc/apache2/on Debian-family systems and under/etc/httpd/on Red Hat-family systems, but packages and administrators can change these paths. Use Apache’s own startup information rather than editing a similarly named inactive file. - Inspect virtual hosts and includes.
apachectl -Sor the equivalent control script displays parsed virtual hosts and their configuration files. Review included files and determine whether the request uses HTTP or HTTPS and which virtual host receives it. - Choose the narrowest directive that matches the delay. Use
TimeOutfor core I/O,ProxyTimeoutfor an upstream proxy wait, andRequestReadTimeoutfor request-receive stages. - Back up the file and edit the correct scope. Keep a copy of the original file. Set a global value only when all sites need it; otherwise put the directive in the affected virtual host.
- Check for another effective setting. Search the loaded configuration for the same directive and review include order. A later or more specific declaration may be the value Apache uses.
- Run the configuration test. Do this before reloading. A syntax error can prevent Apache from accepting the new configuration.
- Reload gracefully and reproduce the request. A reload applies configuration to new work while allowing existing requests to finish according to the service manager’s behavior. Restart only when your deployment requires a full restart.
- Read both Apache and upstream logs. Confirm that the same stage and virtual host now have the expected behavior. Do not judge success solely by a changed browser message.
Examples for common timeout problems
Increasing the general Apache I/O limit
If a CGI program or external filter legitimately needs more than the 60-second default, add this in the server configuration or affected virtual host:
TimeOut 120Use the smallest measured value that accommodates the operation. If only one reporting site needs the change, put it inside that site’s <VirtualHost> instead of increasing the limit for unrelated sites.
Allowing a slow reverse-proxy response
For a backend that normally takes up to two minutes, set:
ProxyTimeout 120Keep the backend’s own timeout, the front-end load balancer timeout, and the browser or API client’s timeout in the same design conversation. The longest Apache setting does not override a shorter limit elsewhere.
Allowing a large but slow upload
If clients are being rejected while sending request bodies, inspect whether RequestReadTimeout is expiring the body stage. A policy with an explicit cap and minimum rate might look like:
RequestReadTimeout header=20-40,MinRate=500 body=60,MinRate=500This leaves the header policy at a 20-to-40-second range and gives the body stage a fixed 60-second limit with a 500-byte-per-second minimum rate. The appropriate values depend on the slowest supported connection and the largest expected request. If the client is not sending data at the required rate, simply increasing TimeOut will not solve the rejection.
Allowing a slow TLS handshake
On versions that support the handshake parameter, configure that stage explicitly, for example:
RequestReadTimeout handshake=10 header=20-40,MinRate=500 body=20,MinRate=500Handshake support starts with HTTPD 2.4.39. Older installations may reject the parameter or require a module/version upgrade; test the configuration on the actual server before deployment.
Testing and reloading by operating system
The directive syntax is Apache’s, but the service commands depend on the package and operating system. Use the command that exists on your host:
| Environment | Configuration test | Typical reload |
|---|---|---|
| Debian or Ubuntu packages | apache2ctl configtest or apachectl -t |
sudo systemctl reload apache2 |
| RHEL, Fedora, CentOS, or similar packages | httpd -t |
sudo systemctl reload httpd |
| Custom or source installation | The installed apachectl -t or equivalent control script |
The service manager or init script used by that installation |
A successful test normally prints a syntax confirmation and exits successfully. If it reports an unknown directive, check that the relevant module is installed and loaded, that the directive is spelled with its documented capitalization, and that you are testing the same configuration file used by the running service.
How to verify that the new value is active
After reloading, send a request through the same hostname, port, and protocol that failed originally. A request sent to a different virtual host can make a correct change appear ineffective.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Check the Apache error log for timeout messages, upstream connection details, and the selected virtual host.
- Check the application server log for the same request ID or timestamp. This reveals whether Apache waited, the application failed first, or another proxy ended the request.
- For uploads, test with a deliberately throttled client in a controlled environment and watch whether the request reaches the body stage or is rejected with 408.
- For proxied requests, measure backend response time independently. If the backend takes 90 seconds and
ProxyTimeoutis 60, a 120-second setting should remove that particular Apache limit, but it will not fix an application crash or a 60-second timeout in another proxy. - Confirm the running process was actually reloaded. A configuration file edit without a successful reload does not change existing workers.
Troubleshooting when the change has no effect
The configuration test fails
Read the first syntax error, correct it, and test again. Common causes include placing a directive inside a block where its context is not allowed, misspelling TimeOut as Timeout, or using handshake on a version that predates HTTPD 2.4.39. Do not reload a configuration that fails its test.
The request still returns 504
Verify that the request is handled by the virtual host where ProxyTimeout was set. Then inspect Apache’s error log and the upstream log. A 504 can originate from Apache, a load balancer, a service mesh, or another gateway. Raise the limit only when the backend’s longer response is expected and its resource usage is understood.
Best Value
- Used Book in Good Condition
An upload still returns 408
Inspect the active RequestReadTimeout values, including inherited global settings. Check whether the client is meeting MinRate and whether the header or body stage is expiring. Also check application-level upload limits and any front-end proxy that may enforce a shorter receive timeout.
A CGI request still stops at the same time
Confirm that the delay is CGI output covered by TimeOut, not an application-level execution limit. CGI process managers, scripting runtimes, databases, and front-end proxies can each impose their own limits. The Apache setting cannot extend a component that has already terminated the request.
Recommended Free Tools
Connections or workers are exhausted after raising the value
Longer limits allow more slow connections to remain active. Review concurrent connection counts, worker utilization, memory, and upstream capacity. Prefer a per-virtual-host change, a bounded receive rate, asynchronous job processing, or a faster backend over an extremely large global timeout.
Configuration scope, precedence, and interactions
All three directives support server configuration and virtual-host context, but they govern different phases. A global TimeOut provides the baseline. ProxyTimeout normally inherits that baseline until explicitly set. RequestReadTimeout applies its own receive-stage policy and is not a synonym for either of the other directives.
Keep related settings together in the file that owns the application or virtual host, and document why a non-default value exists. When troubleshooting, record the effective hostname, protocol, module, directive, value, and log message. This prevents changing a global setting when the real issue belongs to one site or one request phase.
Choosing a value without creating a new problem
Apache’s documentation supplies defaults and mechanisms, not one universal best timeout. Select a value from measured requirements:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- Measure normal and worst-case backend response times, including database and queue delays.
- Add a safety margin, but keep the limit below the point where users and upstream systems will give up.
- For uploads, calculate the slowest supported transfer rate and expected request size, then set a bounded body policy rather than disabling limits globally.
- Use a virtual-host scope when only one application needs extra time.
- Watch resource consumption after deployment; a timeout that prevents errors but saturates workers is not a successful fix.
Security matters as well as performance. Receive-stage limits help reduce exposure to clients that open connections and send headers or bodies extremely slowly. Removing those limits or setting very large values may increase the number of connections an attacker or unreliable network can hold open.
Quick reference
| Directive | Default documented value | Use it for | Important limitation |
|---|---|---|---|
TimeOut |
60 seconds in current Apache 2.4 core documentation | General client I/O, send acknowledgments, CGI or external-filter output | Does not replace receive-stage policies or application timeouts |
ProxyTimeout |
Inherits TimeOut |
Waiting for a proxied application server | Does not change the upstream application’s own timeout |
RequestReadTimeout |
handshake=0 header=20-40,MinRate=500 body=20,MinRate=500 in Apache 2.4 documentation |
TLS handshake, request headers, and request-body receive stages | Can return 408; minimum-rate and cap behavior must match the client workload |
The practical sequence is simple: identify the slow side, change the matching directive in the correct scope, test the loaded configuration, reload Apache, and verify the same request in the logs. Avoid treating every timeout as a reason to increase the global TimeOut.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
