访问时好时坏，刷新几次有时跳502，有时跳504，隔一会儿又自己好了，日志里两类错误交替出现。很多人把它当成一个问题在查，改完超时改进程数，改完进程数换机器，最后哪一头都没解决。
这两类错误在nginx的error.log里留下的关键词完全不同，一个指向连接，一个指向时间，先分清是哪一类能省掉大半盲目操作。分辨的办法不是看页面提示，而是翻日志的最后几行。
502指的是网关从上游拿不到有效响应，要么连接根本没建起来，要么连上了但对方返回的东西不合法，不满足HTTP的基本格式。上游就是真正处理请求的那个进程，多数情况下是php-fpm，也可能是另一台应用服务器。
504指的是nginx等到规定时间还没拿到响应：可能连接建起来了、请求也发出去了，上游迟迟不回，也可能连都没连上、一直等到超时。区别在于，502是对方不在或者答非所问，504是对方在但迟迟不说话，两者的成因和改法差得很远。
502先看进程在不在，php-fpm没启动、重启失败、监听路径和nginx配置里写的不一致，都会出现连接被拒，error.log里对应的整句是connect() failed (111: Connection refused) while connecting to upstream。再看进程池有没有被打满，max_children占满之后新请求连不进去，表现同样是502，跟超时没有关系。504要往慢的方向查，数据库慢查询、外部接口卡住、循环里跑了太多查询，都会让上游超过fastcgi_read_timeout设定的时间，这个值默认是六十秒。另外，php-fpm的request_terminate_timeout会把跑太久的子进程直接杀掉，nginx等到的就是一个断掉的连接，这一类同样算502，常被误判成进程没起来。
最容易混淆的是进程池满这一种，它明明和资源有关，报出来的却是502，于是有人去改超时，改完照旧。判断办法是看php-fpm自己的状态页或者系统日志，进程数是不是长期贴着上限。
验证不必等用户报错，直接对后端发一次请求，看它多久返回、返回什么内容。后端自己能秒回而前端报504，问题在中间的转发配置或者某一段链路；后端直接拒绝连接，问题就在后端进程本身。
把超时从六十秒调到三百秒，报错只会晚四分钟出现，页面依然打不开，用户等得更久。超时值只是容忍度，不是解决手段，真正要压的是上游的耗时。
先翻日志拿关键词，再决定是查进程还是查耗时，两步就能把方向定下来，剩下的才是具体改哪一个参数。方向定了再动手，比来回试配置快得多。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
