迁移OVH后Apache 503异常排查：高流量服务故障咨询

AI 小北

2026-5-27

这确实让人头疼——明明硬件配置拉满，静态压测也能扛4000并发，结果在远低于预期的600次/秒连接下就触发503，而且环境架构的变化是核心变量，咱们一步步拆解来看：

一、Docker + Nginx反向代理带来的隐藏瓶颈

之前是纯LAMP架构，现在多了Nginx反向代理+Docker容器两层，这两层很可能藏着你没注意到的限制：

Nginx反向代理的连接配置遗漏：
检查Nginx的核心参数：worker_connections默认可能只有1024，如果worker进程数不多，总可用连接数会直接卡壳；另外别忘了开启proxy_http_version 1.1和proxy_set_header Connection ""，否则每次请求都会新建TCP连接，会快速耗尽资源，远达不到静态测试的效率。
Docker容器的资源与网络限制：
别光看宿主机配置，得确认Apache容器有没有拿到足够资源——比如是不是用--memory/--cpus限制了容器的内存和CPU？还有网络模式，如果用的是默认的bridge模式，网络转发性能比host模式差很多，高并发下会成为明显瓶颈。另外，容器的文件描述符限制很容易被忽略：进入容器执行ulimit -n，如果数值低于10000，会直接限制Apache的并发连接数，运行容器时要加--ulimit nofile=65535:65535来放宽。

你提到MySQL有0.5秒响应延迟，静态压测没有数据库请求，所以进程/线程能快速释放，但真实场景下这个延迟会直接拖垮Apache的连接池：

连接模式选错了：
如果现在Apache用的是prefork模式，每个连接对应一个独立进程，MySQL的0.5秒延迟会让进程长时间被占用，进程池很快就会耗尽触发503。对比之前AWS的LAMP环境，是不是用了event或worker模式？这两种模式用线程处理请求，资源占用更低，能扛住更多带数据库请求的并发。
进程/线程池参数没调整：
检查MaxRequestWorkers、MinSpareThreads这些核心参数，静态测试时无数据库等待，进程/线程周转快，但真实场景下每个请求要等MySQL响应，就算MaxRequestWorkers设了4000，实际能同时处理的请求数会因为延迟大幅下降——比如每个请求占1秒（含数据库延迟），那每秒只能处理4000/1=4000？不对，还要考虑进程启动/回收的开销，实际可能连600都达不到。
数据库连接未复用：
如果Apache/PHP是每个请求新建MySQL连接，0.5秒的延迟加上连接建立的开销，会让Apache进程一直卡在等待数据库连接的状态，直接耗尽进程池。要确认有没有用连接池（比如PHP的PDO持久化连接、Apache的mod_dbd），同时检查MySQL的max_connections，避免因为数据库连接不够导致Apache请求失败。

虽然官方说带宽超1GB/s才拦截，但还有其他隐性限制可能影响：

TCP层的队列限制：
宿主机的net.ipv4.tcp_max_syn_backlog、net.core.somaxconn默认值很低（比如somaxconn默认128），高并发下SYN队列会快速占满，导致新连接被拒绝，表现为503。可以用ss -s查看TCP连接状态，如果有大量SYN_RECV状态的连接，就说明是这个问题，执行sysctl -w net.core.somaxconn=1024临时调整，再写入/etc/sysctl.conf永久生效。
防火墙的隐性连接限制：
OVH自带的防火墙（比如IP Failover的防火墙）可能有未公开的每秒新连接数限制，而不是总连接数。可以临时关闭防火墙做测试，如果问题消失，就需要联系OVH调整防火墙规则。

先绕开反向代理和Docker：直接访问Apache容器的IP（绕过Nginx）做压测，如果能扛到600+连接，问题就出在Nginx；把容器改成host网络模式再测，排除bridge网络的转发瓶颈。
盯紧Apache的运行状态：用apache2ctl status或mod_status看实时进程/线程使用情况，出现503时是不是MaxRequestWorkers已经耗尽？同时看Apache的error.log，里面会明确给出503的触发原因（比如“server reached MaxRequestWorkers setting”）。
排查MySQL的真实负载：出现503时执行show processlist，看有没有大量Sleep或等待锁的连接；用慢查询日志确认0.5秒延迟是不是普遍情况，哪怕不能优化，至少要确认延迟来源。

内容的提问来源于stack exchange，提问作者Bastian Jakobsen