Php 调试504网关超时及其实际原因和解决方案

我们在RHEL6.6上的web服务器Varnish+Nginx+FastCGI（PHPFPM）上运行以下堆栈

它是一个动态的网站，每次都有不同的结果集，有大约200万个url被Google索引

• 它运行在nginx/1.5.12和php5.3.3上（很快将升级到最新的nginx和PHP）
• Nginx连接到端口9000上同一台服务器上本地运行的php fpm

我们在一些无法解决的页面上间歇性地出现504网关超时。给出504的URL在一段时间后工作正常。 我们从我们的日志中了解到了504，但我们无法复制它，因为它在任何URL上随机发生，过了一段时间后就会起作用

我已经和开发人员进行了几次讨论，但据他说，底层php脚本几乎没有任何作用，它不应该花费这么长的时间（120秒），但仍然会给出504网关超时

需要确定问题发生的确切位置：

• 这是Nginx的问题吗
• 这是php fpm的问题吗
• 底层php脚本有问题吗
• nginx是否可能无法连接到php fpm
• 如果我们使用Unix套接字而不是TCP/IP连接，它会解决问题吗

URL在使用504的120秒后超时

下面是看到的错误： 2016/01/04 17:29:20[错误]1070#0:*196333149连接到上游时上游超时（110：连接超时），客户端：66.249.74.95，服务器：x.x.x.x，请求：“GET/Some/url HTTP/1.1”，上游：fastcgi://127.0.0.1:9000，主机：“example.com”

早些时候，fastcgi_connect_超时时间为150秒-它用于在RHEL 6.6上默认net.ipv4.tcp_syn_retries=5的情况下，在63秒后给出at 502状态代码；之后，我们将net.ipv4.tcp_syn_retries设置为6，然后在127秒后开始给出502

一旦我设置fastcgi\u connect\u timeout=120，它就开始给出504状态码。我知道fastcgi\u connect\u超时值这么高并不好

需要找出我们得到504的确切原因（我知道它超时了，但原因不明）。需要找到根本原因来永久修复它

我如何确认问题的确切位置

以下是一些已经定义的超时：

在服务器范围的nginx.conf下：

• 保持激活超时5
• 发送超时150

在特定vhost.conf下：

• 代理发送超时100
• 代理读取超时100
• 代理连接超时100
• fastcgi\u连接\u超时120
• fastcgi\u发送\u超时300
• fastcgi\u读取\u超时300

使用了不同的超时值，因此我可以计算出确切触发了哪个超时

下面是sysctl.conf中的一些设置：

• net.ipv4.ip_本地_端口_范围=1024 65500
• net.ipv4.tcp\u fin\u超时=10
• net.ipv4.tcp_tw_重用=1
• net.ipv4.tcp_syn_重试次数=6
• net.core.netdev_max_backlog=8192
• net.ipv4.tcp_max_tw_bucket=2000000
• net.core.somaxconn=4096
• net.ipv4.tcp\无\度量值\保存=1
• vm.max\u map\u count=256000

如果它的代码写得很糟糕，那么我需要通知开发人员，504的出现是由于php代码中的问题，而不是由于nginx或php fpm，如果它是由于nginx或php fpm，那么需要修复它

提前谢谢

======

进一步更新：

有两种情况：

504@120秒，出现以下错误：

2016/01/05 03:50:54[错误]1070#0:*201650845连接到上游时上游超时（110：连接超时），客户端：66.249.74.99，服务器：x.x.x.x，请求：“GET/some/url HTTP/1.1”，上游：fastcgi://127.0.0.1:9000，主机：“example.com”

504@300秒，出现以下错误：

2016/01/05 00:51:43[错误]1067#0:*200656359从上游读取响应头时上游超时（110：连接超时），客户端：115.112.161.9，服务器：192.168.12.101，请求：“GET/some/url HTTP/1.1”，上游：fastcgi://127.0.0.1:9000，主机：“example.com”

• 在php fpm日志中未发现错误
• php fpm进程的数量也正常。后端看起来并没有过载，因为其他请求在同一时间得到了很好的处理

• 只使用了一个php fpm池。一个php fpm主（父）进程和其他从（子）进程通常只有在观察到5xx时才处于正常范围。php fpm进程的数量并没有显著增长，即使增长了，服务器也有足够的容量来派生新的进程并为请求提供服务

---

必须假设您正在重写URL或通过网关/防火墙重定向，这通常是504错误产生的原因

504表示后端服务（即网关/防火墙的另一端-内部）已关闭或无法寻址（错误的内部URL）。它也可能是由后端崩溃引起的，但这应该显示在日志中（如果调试日志已打开）

检查以下各项： （a） 通过访问内部网络来检查应用程序。可以解决吗？参数正确吗？它是否按预期工作？ （b） 检查网关。如何重定向（重写）URL？是否安装了允许重定向/重写所需的模块？结果地址在内部是否正确？重定向是否正确写入（正确的类型、参数等）？检查网关上的访问日志可能很有用

然而，这个问题还有很多其他的发生方式，但这是你应该调查的领域。504是路由错误