在典型的反向代理架构中，客户端与Apache建立连接，Apache再与后端应用服务器建立新连接。多数人的第一反应是增加带宽、调大缓冲区，却忽略了TCP协议栈中两个容易被忽视的机制：Nagle算法和延迟确认。当两者叠加时，即使是本地回环链路，也可能出现稳定的几十毫秒延迟。对于实时性要求高的接口、WebSocket或gRPC流式响应，这种延迟会直接反映到用户体验上。本文聚焦Apache作为反向代理时与TCP_NODELAY相关的问题，解释为什么禁用Nagle算法通常是必要的，以及如何确认配置已经生效。
一、Nagle算法与延迟确认如何共同制造延迟
Nagle算法的核心思想是减少网络中微小数据包的数量。它规定，当一个TCP连接上还有未被确认的数据时，后续的小数据段不会被立即发送，而是先缓存在发送缓冲区中，直到收到之前数据的ACK，或者缓冲区中的数据累积到一个最大报文段长度（MSS）再一次性发出。这样做在吞吐量敏感的场景下确实能降低包数量，但代价是增加了单个小包的等待时间。
延迟确认是另一个独立但经常与Nagle算法同时出现的机制。接收方在收到数据后，不会马上回复ACK，而是等待一小段时间（通常为40毫秒），看看是否有数据需要反向发送，以便将ACK与数据合并。如果发送方此时正在等待ACK才能继续发送，而接收方又在等待更多数据才回复ACK，双方就会陷入短暂的相互等待。这个交互过程被很多工程师称为“40毫秒延迟陷阱”。
在Apache反向代理环境中，这种延迟尤其明显。例如，一个典型的HTTP响应可能被拆分为响应头、响应体以及最后的结束标记。如果响应体很小，比如只有一个JSON对象，而Apache与后端之间的TCP连接又复用了Nagle算法的默认设置，那么最后一个小数据块就可能被推迟发送。对于WebSocket或gRPC这类长连接、小帧频繁传输的协议，每一次小帧都可能触发一次等待，最终累计成明显的用户可感知卡顿。
二、Apache mod_proxy中TCP_NODELAY的默认行为
Apache HTTP Server本身没有提供一个名为TCP_NODELAY的显式配置指令，但它在内部通过APR（Apache Portable Runtime）套接字层管理连接。在mod_proxy模块创建后端连接时，会调用APR的套接字选项设置函数。从Apache 2.4系列开始，mod_proxy已经默认对后端连接执行了类似下面的操作：
/* 在后端 socket 创建后立即设置 TCP_NODELAY */ apr_socket_opt_set(newsock, APR_TCP_NODELAY, 1);
这段逻辑在代理模块的连接建立阶段执行，意味着Apache到后端应用服务器的连接默认已经禁用了Nagle算法。因此，很多使用主流Apache 2.4版本的站点，即使没有进行额外配置，其后端代理链路上的小包延迟问题也并不突出。但这里有两个前提：第一，Apache必须使用mod_proxy模块进行反向代理；第二，实际效果还取决于操作系统对APR_TCP_NODELAY的实现是否完整。
需要特别注意的是，Apache与客户端之间的连接也默认启用了TCP_NODELAY，这一点在`Listen`指令创建监听套接字时已经处理。但对于一些旧版本Apache或使用定制编译模块的场景，可能会因为APR版本较旧或编译选项差异，导致TCP_NODELAY没有被正确设置。此时，开发者往往会在日志中看到响应时间异常，但很难直接定位到套接字选项层面，因为没有明确的报错信息。
另外，mod_proxy的缓冲区大小也会影响实际发送行为。即使TCP_NODELAY已经开启，如果代理层设置了较大的`ProxyIOBufferSize`，数据仍可能先被填入缓冲区等待填满。但TCP_NODELAY的作用是保证应用层每次`write`调用都会立即触发网络发送，而不是等待Nagle算法的合并条件。因此，只要应用层正确地将小数据块交给套接字，延迟就能得到控制。
三、检查与调整TCP_NODELAY的几种方式
既然Apache没有直接暴露TCP_NODELAY配置项，那么当怀疑代理延迟与Nagle算法有关时，应该先检查当前系统中的实际状态。可以通过抓包或内核参数来间接判断，而不是盲目修改。首先需要确认Apache的版本以及mod_proxy是否为官方预编译模块。如果是源码编译，检查APR版本是否支持APR_TCP_NODELAY常量。在Linux系统上，几乎所有现代发行版都支持这一选项。
如果确认需要人工干预，最稳妥的方式是在Apache的模块源码中找到后端连接建立的位置，确保`apr_socket_opt_set`被调用。对于不想重新编译Apache的用户，可以考虑在系统层面调整与延迟确认相关的参数，例如降低`net.ipv4.tcp_delack_min`的值。但要注意，这并不能完全替代TCP_NODELAY，只是缩短接收方的ACK等待时间。全局修改内核参数还可能影响其他服务，因此仅建议在测试环境中短期使用。
# 查看当前内核延迟确认相关参数 sysctl net.ipv4.tcp_delack_min # 临时调整为更小的值（以毫秒为单位，需谨慎测试） sysctl -w net.ipv4.tcp_delack_min=5
另一种对比方案是使用nginx作为参考。nginx在代理模块中直接提供了`proxy_tcp_nodelay`指令，让用户可以在配置文件中明确开关这一行为。如果迁移到nginx后延迟明显下降，就说明问题大概率出在Apache代理链路的套接字设置上。但生产环境切换代理软件涉及成本较高，通常作为验证手段而非长期方案。
location / {
proxy_pass http://backend;
proxy_tcp_nodelay on;
}
四、验证代理链路延迟的测试方法
验证TCP_NODELAY是否生效，最直接的方法是测量小响应请求的TTFB（首字节时间）。可以构造一个只返回几十字节的接口，绕过后端应用逻辑，直接由后端静态文件或简单脚本响应。然后在客户端使用curl多次请求，观察时间分布。如果发现响应时间中有稳定的40毫秒级别平台，就强烈暗示延迟确认和Nagle算法在起作用。
# 连续请求小响应接口，输出各阶段耗时
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" http://127.0.0.1:8080/small
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" http://127.0.0.1:8080/small
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" http://127.0.0.1:8080/small
更精确的方法是使用tcpdump抓取Apache与后端之间的网卡流量，观察小数据包的发送时间。如果TCP_NODELAY已经启用，应用层每次写入都会立即产生一个独立的TCP段；如果未启用，则可能在抓包中看到多个小数据被合并成一个稍大的包，且发送时间明显晚于应用层写入时间。抓包时可以使用端口过滤，减少无关流量干扰。
# 抓取本地回环上8080端口的数据包，观察小包是否被合并 tcpdump -i lo -nn -s 0 -A 'tcp port 8080 and (tcp[13] & 2 != 0)'
对于希望从系统调用层面确认的程序员，可以使用strace跟踪Apache工作进程，查找`setsockopt`调用中是否出现了`TCP_NODELAY`。因为APR最终会调用操作系统的`setsockopt`，通过strace可以直观地看到选项名称和值。这个方法适合定位具体进程或线程，但Apache工作进程可能较多，需要先用`server-status`或`ps`确定处理该请求的进程号。
# 跟踪Apache子进程的系统调用，过滤 setsockopt 相关输出 strace -p 12345 -f -e trace=setsockopt 2>&1 | grep TCP_NODELAY
综合来看，Apache作为反向代理时，TCP_NODELAY的默认启用已经覆盖了大多数现代部署场景。真正需要深入排查的，往往是那些使用了旧版APR、定制编译或混合代理架构的环境。通过抓包、TTFB测量以及strace跟踪，可以准确判断是否仍然存在Nagle算法导致的延迟，并有针对性地调整源码或系统参数，而不是盲目修改配置。
Apache代理TCP_NODELAYNagle算法修改时间：2026-10-04 20:18:00