http请求时报出网络服务器错误，本质是你的浏览器发出的请求，在服务器那一端没有走通，多数情况下是服务器软件本身出了问题，而不是你的电脑或网络故障。这类错误通常以5xx开头的状态码呈现，搞清楚它出现的位置和原因，就能在几分钟内判断出问题到底出在谁身上。
服务器收到http请求后，到底在做什么
要理解错误,先得知道请求的旅行路线，你的浏览器把网址解析成IP，然后把请求交给对方服务器，服务器上运行着Web软件（常见的有Nginx、Apache、IIS），它像个门卫，负责接收请求；门卫后面是应用程序（比如PHP、Java、Python写的代码），像个办事员，负责处理逻辑；办事员后面还有数据库，像个仓库管理员，负责存取数据。
这个链条上任一环节掉链子,浏览器就会弹出一个错误页。多数情况下，你看到的服务器错误是门卫把请求转交给办事员时，办事员没有给出正常响应。 业内专家指出，这类问题在运维工作中占到相当大的比例。
看清错误码的身份信息
每个http响应码都带着身份信息：
- 4xx开头的错误,问题出在请求端，也就是浏览器或用户这边，比如404是没找到资源，403是没权限访问。
- 5xx开头的错误,问题出在服务器端，是你通过了门卫，但里面的工作人员出了问题。
凡是看到5开头的状态码，都可以直接判定为服务器错误。 这是排查的第一条分界线。
常见的服务器错误有哪些类型
以下是几个高频出现的5xx状态码,你大概率在某个时刻见过它们：
- 500 Internal Server Error：服务器内部错误，最常见的通用错误，代码出了异常，但服务器没有给出更精细的解释。
- 502 Bad Gateway：网关错误，服务器作为代理或网关，从上游服务器收到了无效响应。
- 503 Service Unavailable：服务不可用，服务器暂时无法处理请求，通常是过载或正在维护。
- 504 Gateway Timeout：网关超时，服务器等待上游响应时超时了。
服务器错误500怎么解决，先查日志再动手
500错误是这几个里面最让人摸不着头脑的,因为它太笼统了。这个错误的本质是：服务器收到了请求，也执行了代码，但代码在运行过程中抛出了一个未捕获的异常。
解决它的关键，不是乱猜，而是找到服务器记录下来的具体报错信息。
第一步：找到错误日志的位置
不同环境,日志位置不一样：
- Linux服务器普遍使用Nginx或Apache,日志通常在
/var/log/nginx/error.log或/var/log/apache2/error.log。 - 使用了宝塔面板等可视化工具,可以在面板里直接查看网站日志，路径一般在
/www/wwwlogs/。 - Windows服务器上的IIS,日志在系统目录下的
inetpublogsFailedReqLogFiles。
用 tail -f 命令实时滚动日志，同时刷新一次报错页面，新的报错信息就会滚出来，精确到哪一行代码出了问题。
第二步：按日志线索对症处理
看到日志里具体的报错后,处理方向就清晰了：
- 语法错误或函数不存在：这是代码层面的问题，修复对应文件那行代码即可。
- 内存耗尽：日志常见提示
Allowed memory size of，需要调整php.ini里的memory_limit值，或者优化代码里的循环和缓存。 - 文件权限不足：日志会提示无法写入某个目录，检查目录属主和权限，把拥有者改为运行用户（多数是
www或www-data），权限建议设置为755目录和644文件。
第三步：大动作前先备份
改动任何配置或代码之前,先用 cp 命令备份原文件，这样改坏了能马上还原，绝对不要在没备份的情况下直接修改生产环境配置。
502 bad gateway是什么意思，排查思路完全不同
502这个错误,大家在网上搜索的频率很高，因为它报错时，浏览器页面常常是一张白底黑字的 Bad Gateway。
502的含义是：你的请求先到达了最前面的Nginx或Apache服务器，它试图把请求转发给背后的应用服务器时，应用服务器根本没理它。 换句话说，门卫把文件递进去，里面的办事员没接，这个问题和500的错误定位思路不同，500是代码执行报错，502是请求转发失败。
区分不同场景下的502根源
- Nginx + PHP-FPM 架构：最常见的是 PHP-FPM 进程崩了或满了，处理不过来，使用
systemctl status php-fpm
检查状态，或者
ps -ef | grep php-fpm看进程数是否异常少。 - Nginx + 后端Java服务：后端Java应用如果挂了或者端口没有监听，Nginx转发过去自然得到拒绝，用
telnet 127.0.0.1 8080直接测后端端口是否通。 - 反向代理配置错误：配置文件里
proxy_pass指向的地址不可达，代理模块无法建立连接。
快速恢复与长期措施
遇到502,有时重启一下PHP-FPM或后端服务就能立刻恢复，但这治标不治本。长期措施是给PHP-FPM加上进程监控，用 systemd 的自动重启功能，并调整 pm.max_children 参数适配当前服务器内存。 据行业共识，502在流量突增的时段特别容易出现，平时做好压力测试比什么修复技巧都重要。
503和504错误，处理方式又不一样
503和504这两兄弟,表象相似，但本质不同。
503服务不可用，服务器在忙或拒绝服务
这个状态码是最诚实的,它在明确告诉你：我现在没法处理你的请求，但可能过一会儿就好了。 常见触发点：
- 服务器正在重启服务或部署更新,短暂不可用。
- 用
php artisan down --maintenance之类的维护模式命令时出现的。 - 服务器配置了WAF或防火墙,把请求拦截了。
- 服务器扛不住大量并发请求,主动拒绝新连接。
503通常不需要大动干戈,确认服务进程活着，等几秒再刷新一般就能恢复，如果持续很长时间，检查防火墙规则和流量监控，看看是不是被攻击了。
504网关超时，上游响应太慢
504是网关等得不耐烦了。后端应用还在跑，但超过了Nginx等待的时间极限，Nginx直接就断了这个请求，返回超时错误。
解决方向有两个：
- 后端本身速度慢：数据库查询太慢或接口逻辑阻塞，需要优化代码或SQL语句。
- Nginx等待时间设置过短：调整
proxy_read_timeout和fastcgi_read_timeout参数，把默认的60秒调大。
需要注意的是,相关参数调整后要 nginx -t 检查配置语法，再 nginx -s reload 重载生效。
实战排查手册：网站显示服务器错误时的完整操作路径
当真实业务中遇到报错,按下面的顺序做，不要跳步。
先确认是不是自己的网络问题
不少用户看到的服务器错误,其实是自己家路由器或运营商搞的鬼，先用手机开热点，尝试访问同一个网址。如果手机能正常打开，说明网站没出错，问题出在你的电脑或本地网络环境。
用curl命令查看真实状态码
浏览器显示的错误页面有时会美化,误导判断，用命令行工具直接看原始响应：
curl -I https://yourdomain.com
返回的 HTTP/2 200 代表正常，如果是 HTTP/2 502 之类的，那就是真实错误码，这个操作可以帮助你绕过浏览器缓存，看到服务器真实的返回状态。
尝试重启相关服务
如果服务器是你自己管理的,且有SSH权限，按下面的顺序尝试：
- 用
free -m检查内存是否耗尽，df -h检查磁盘是否写满。 - 重启Web服务：
systemctl restart nginx或systemctl restart httpd。 - 重启应用服务：
systemctl restart php-fpm或systemctl restart mysql。 - 重启后再次用curl验证,看是否恢复。
检查安全组和防火墙
云服务器ECS的网页控制台上,安全组的入方向和出方向规则有时会莫名变动，导致端口不通，确认 80 和 443 端口在安全组规则里是放行的，同时用 iptables -L -n 查看服务器本机的防火墙策略，很多错误不是Web软件问题，而是数据包根本没进来。
Q&A：关于服务器错误的高频疑问
为什么刷新几次自己好了，但过一会又出现服务器错误？
常见原因是服务器资源到达瓶颈,比如内存或CPU使用率在临界值附近波动，流量少时请求能处理，流量稍涨就崩，建议检查监控图，看错误发生时间点对应的系统负载，这种间歇性问题通常是性能问题，而不是逻辑故障。
服务器错误会持续多久？
取决于根因,代码逻辑错误会在修复并发布代码后立即消失；资源不足的问题会持续到负载下降或扩容完成；配置错误的持续时间取决于人工介入速度。如果错误持续超过30分钟，且重启服务也无法恢复，优先检查磁盘空间是否已满，这是运维中较常见的隐形杀手。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/614720.html
