对于一个Web开发者来说，504和502问题看上去好像很简单，每个人也可能都遇到过，但把问题说清楚并不那么容易，也希望这两篇文章能够帮助您。

两台设备只要通过proxy或fastcgi协议互相通信，都会遇到504问题，比如Nginx+PHP-FPM会遇到;代理服务器连接后端Web服务也会遇到。我本次遇到的场景属于后者，重点讲解代理导致的504问题。

问题分析

为了把问题说清楚，先介绍下我单位服务部署架构，如下图：

很多读者看到https访问，猜测504问题是不是因它而起，实际上完全没有关系，但整个部署架构却因为引入了ssl，导致系统复杂化了。未来ssl肯定是主流，如果你这张图的部署感兴趣，可以看看我的新书《深入浅出HTTPS：从原理到实战》，里面描述的很详细，此处也算作个广告。

在本文引入这张图的根本原因是想让读者能够清晰的了解我遇到的问题，如果没有这张图，读者在理解的时候会很困难。但也不要想的过于复杂，简单理解就是nginx作为代理服务器连接后端的web服务器(apache/mod_php)。

接下来描述具体遇到问题，在浏览器中访问https://mail.sina.net/x.php的时候，该接口上传文件然后存储到阿里云OSS上，如果传输的文件非常大，执行时间将会很长，一旦到20秒到时候，必然会出现出现504错误，具体如下图：

顺带说一下，其他页面和接口没有遇到该问题，在那一刻会怀疑是不是x.php程序处理有问题(大部分人会这么理解)。

那到底上面是504错误呢，看下wiki的引用：

4 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server

它的意思就是一个网关或代理服务器能够连接后端服务器，但在读取服务器响应的时候超时了。遇到504问题一般是后端服务的问题，比如：

• 后端进程无故退出了(可能是代码异常，也可能是apache或nginx进程异常)，导致代理服务器接收不到后端响应。
• 后端响应缓慢，导致代理服务器接收后端响应超时了。

解决问题

按照上述可能的两个情况，逐一分析。

(1)x.php程序在特定的情况下，确实运行缓慢，但apache的access log在25秒左右的时候成功记录了200访问日志(由于php代码执行结束后才记录日志，一开始可能看不到access日志，导致开始误认为是后端程序的问题)。

(2)在x.php程序中记录应用日志，应用日志和access log日志一样，没有任何异常。

这说明代码并没有问题(但程序执行时间过长，有优化的空间)，虽然在20秒产生504错误(由nginx处理)，后端代码进程仍然继续运行，并在25秒成功运行。

排除这个问题后，最有可能是代理服务器觉得后端响应过于缓慢，主动关闭了该连接，是不是代理服务器设置的超时时间过短?由于公司的代理服务器(ssl nginx)是由专人维护的，我看不到具体的配置，邮件询问了同事，得到回复如下：

1. proxy_read_timeout 60
2. proxy_send_timeout 60

首先看下 proxy_read_timeout 的官方介绍：

• Defines a timeout for reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed.

介绍的很详细了，得到这个答复我就很疑惑了，超时时间是60秒，但504在20秒的时候就产生了，大大的问号悬我脑袋上，又仔细看了下官方文档，是不是 proxy_read_timeout 参数的值写的不严谨，官方写的是60s，可即使写错了，nginx 默认的超时时间也是60秒;是不是nginx 版本默认超时时间不一致?官方文档也并没有对该指令有特殊的说明。

最后同事将该值修改为：

1. proxy_read_timeout 300
2. proxy_send_timeout 300

问题最终解决了，肯定是proxy读取超时了，但具体的配置仍然让我疑惑。

进一步测试

由于我看不到公司代理服务器的具体配置，所以我安装了一个代理服务器，感兴趣的同学也可以进一步了解nginx的proxy配置，如果没有特殊的需求，配置非常简单。

1. server {
2. listen 443 ssl;
3. server_name www.simplehttps.com;
5. location / {
6. access_log access.log main;
7. error_log error.log;
9. proxy_pass http://127.0.0.1:8080;
10. proxy_read_timeout 5;
11. }
12. }

proxy_pass 可以是一个host、内部域名、ip地址，不用是一个对外的域名。

如果遇到超时问题，观察error.log日志，会看到以下错误：

1. 2018/09/19 21:01:19 [error] 17034#0: *253 upstream timed out (110: Connection timed out) while reading response header from upstream, client: *.*.*.*, server: www.simplehttps.com, request: "GET /x.php HTTP/1.1", upstream: "http://*.*.*.*:8080/x.php", host: "www.simplehttps.com"

最后我不断调整nginx的proxy_read_timeout指令和后端x.php程序的执行时间，也没有遇到工作中遇到的问题(20秒和60秒之间不对称的问题)，只能后续继续留意了。

总结

1：网关和后端的超时时间(proxy或fastcgi)必须协调一致，在本案例中，apache/mod_php运行最长时间如果是30秒，那么nginx设置的超时时间必须大于30秒，因为必须考虑网络传输延时时间(非网络包总传输时间);而如果是nginx+php-fpm模式，nginx设置的超时时间相对简单，因为大部分情况下，nginx和php-fpm部署在同一台机器上，网络延时相对较短，但必须考虑php最大执行时间和php-fpm最大执行时间，后续我会写一篇关于php-fpm和php之间协调工作的文章。

2：针对5**错误，可认为都是http错误码，都是服务器端的错误(相对于客户端)，在遇到相关错误的时候，我们必须根据错误码判断可能存在的问题，然后再针对性的排查，否则排查时间会增加很多。

原文地址：https://mp.weixin.qq.com/s/d3l1VxDKcxgAuHxs1qOH_g