在Linux环境里跑web服务器，不管是Nginx、Apache还是基于Node、Python的后端应用，时间久了总会碰到各种突发故障。这些问题轻则让部分页面打不开，重则整站不可用。理解常见故障的成因并准备好修复手段，是运维和开发都该具备的能力。
一、端口被占用导致服务无法启动
最典型的启动失败就是绑定端口时报错。比如Nginx默认监听80和443，如果机器上已经有别的程序占用了这些端口，主进程就会退出。很多初学者会反复重启服务却看不到明显原因，其实日志里已经写了address already in use。
我们可以用系统工具快速定位是谁占用了端口。以下命令列出所有监听中的TCP端口及对应进程：
# 查看80端口被谁占用 ss -ltnp | grep ':80' # 或者使用老牌工具netstat netstat -ltnp | grep ':80'
找到PID之后，若是无关紧要的测试程序，可直接结束它；若是必须共存的服务，就修改web服务器的监听端口或改用不同IP。Nginx修改监听配置示例如下：
server {
listen 8080;
server_name example.ipipp.com;
root /var/www/html;
}
修改后先执行nginx -t检查配置语法，再重载服务。这样既能避开冲突，也不影响原有占用端口的程序运行。需要注意，公网环境改非标准端口后，用户访问要带端口号，或者前面用反向代理统一入口。
二、目录权限与属主错误引发403
服务起来了，但浏览器访问却是403 Forbidden，这种情况多半出在文件权限或SELinux限制上。web进程通常以特定用户运行，例如Nginx在多数发行版里是nginx用户，它需要对网站根目录有读取和执行权限。
假设我们把代码传到了/home/dev/site，但目录属主是dev，而Nginx无权进入，就会拒绝访问。修复方式是调整属主或权限：
# 将目录属主改为nginx
chown -R nginx:nginx /home/dev/site
# 保证目录有755，文件有644
find /home/dev/site -type d -exec chmod 755 {} ;
find /home/dev/site -type f -exec chmod 644 {} ;
如果系统开启了SELinux，还要检查安全上下文。可以用ls -Z查看，若上下文不对，用semanage fcontext与restorecon修正。此外，Nginx配置里的user指令也要和实际情况匹配，否则即使用root启动子进程，仍可能因降权后无权限而报错。
权限问题看似简单，但往往夹杂着软链接指向越权路径、父目录缺少执行位等隐蔽情况。排障时建议从根目录一层层往里查，确认每一级都有正确的x权限，才能彻底解决403。
三、文件描述符耗尽造成连接雪崩
高并发场景下，linux默认的单进程打开文件数限制（通常是1024）很容易触及。web服务器每接受一个TCP连接、每读一个静态文件都消耗一个fd，一旦耗尽，新连接直接失败，现象类似雪崩，监控上看到吞吐量陡降。
通过如下命令可以观察当前限制与使用量：
# 查看某nginx worker的limits cat /proc/$(pgrep -o nginx)/limits | grep 'Max open files' # 实时统计已用fd ls /proc/$(pgrep -o nginx)/fd | wc -l
永久调整需要改系统配置。在/etc/security/limits.conf增加：
nginx soft nofile 65535 nginx hard nofile 65535
同时Nginx自身也要放开：
worker_rlimit_nofile 65535;
events {
worker_connections 10240;
}
改完重启服务生效。除了调大限制，还应检查代码里是否有连接未关闭、后端keepalive配置过长等导致fd空耗的问题。单纯调参数只是缓解，根治要靠连接池与超时控制。
四、后端应用挂掉导致网关502
当Nginx作为反向代理，后端Java、Node或Python服务崩溃时，用户看到的就是502 Bad Gateway。此时网关本身健康，但 upstream 无响应。盲目重启Nginx没用，必须先看后端。
用代理配置举例，Nginx把请求转到本地3000端口：
location /api/ {
proxy_pass http://127.0.0.1:3000/;
proxy_set_header Host $host;
}
发现502后，先确认后端进程是否存在：
ps aux | grep node curl -v http://127.0.0.1:3000/health </p> <pre class=brush:bash;toolbar:false> # 若进程不在，查日志重启 journalctl -u mynode.service --since '10 min ago' systemctl restart mynode
为减少单点故障，可在Nginx配置多个后端并加健康检查，某台挂掉自动剔除：
upstream backend {
server 127.0.0.1:3000 max_fails=3 fail_timeout=30s;
server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
}
这样即便一个实例崩溃，流量也能切到备用节点。配合进程守护工具如systemd或supervisor，能在后端意外退出时自动拉起，从架构层降低502出现频率。
五、小结与排障顺序建议
面对web服务器故障，推荐固定排查顺序：先看服务进程在不在，再查端口与配置，接着看权限和fd，最后确认上下游依赖。把上述四类问题对应的命令写成脚本，平时巡检时跑一遍，能提前发现隐患。
Linux的日志系统非常完善，/var/log/nginx/error.log、journalctl和dmesg常藏着关键线索。养成遇错先读日志的习惯，比盲目搜索更高效。随着经验积累，你也能逐步形成自己的故障对照表，把平均修复时间压到最低。
Linuxweb_servertroubleshooting修改时间：2026-08-01 08:03:35