Linux服务器配置踩坑实录：SSH连不上、Nginx报502、磁盘满了？这几个高频故障站长帮你排明白了

刚入手一台云服务器，兴致勃勃准备大干一场，结果连 SSH 都登不上去；好不容易把网站跑起来，Nginx 又时不时给你甩个 502 脸色看；更别提某天凌晨收到监控告警，磁盘使用率 100%，数据库直接躺平……这些场景，做过运维的站长们应该都不陌生。

笔者自己从折腾虚拟主机到管理几十台 Linux 服务器的这些年，踩过的坑可以说能写一本小册子。今天不聊虚的，直接把这几个最高频、最让人抓狂的报错拎出来，从根因到解决步骤，再到预防建议，一次性讲透。如果你正准备买服务器或者刚入手不久，这篇内容建议先收藏。

一、SSH 连接超时或被拒绝，到底哪里出了问题？

💡 推荐阅读：深入Docker源代码：从镜像构建到容器运行的底层架构与性能调优实战

Q1：新买的服务器，用 SSH 工具连接一直提示“Connection timed out”，是服务器坏了吗？

先别急着找客服退款，这种情况十有八九不是硬件问题。SSH 连不上，通常按下面这个顺序排查，基本能定位到原因：

• 安全组/防火墙没放行 22 端口：这是新手最容易忽略的一点。云服务器厂商（比如阿里云、腾讯云、华为云）都有“安全组”这个概念，相当于一层虚拟防火墙。默认情况下，很多安全组只开放了 ICMP（能 ping 通），但 22 端口是关闭的。去控制台的安全组规则里，添加入站规则，允许 TCP 协议的 22 端口，来源填 0.0.0.0/0（如果只是自己用，填你自己的 IP 更安全）。
• 服务器内部防火墙拦截：如果安全组没问题，那就要看系统自带的防火墙了。CentOS 7 以上默认用的是 firewalld，Ubuntu 通常用 ufw。检查一下规则里有没有放行 SSH。
• SSH 服务没启动或配置错误：这种情况多见于自己重装系统或者改了配置之后。如果你还能通过 VNC 控制台登录，执行 systemctl status sshd 看一眼服务状态。如果是配置文件改错了导致起不来，大概率是 /etc/ssh/sshd_config 里某个参数写呲了。

对应的解决命令如下：

# 查看 firewalld 状态和已开放端口
systemctl status firewalld
firewall-cmd --list-all

# 放行 SSH 端口（永久生效）
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

# 如果是 ufw（Ubuntu）
ufw status
ufw allow 22/tcp

预防建议：买服务器的时候，尽量选大厂，安全组配置界面清晰，文档也全。别贪便宜选那种连控制台都卡顿的小厂，出问题了工单几天没人回，那才叫绝望。另外，强烈建议把 SSH 默认端口从 22 改成其他高位端口，比如 22222，能过滤掉一大波自动化扫描脚本。

二、Nginx 反向代理频繁 502 Bad Gateway，怎么破？

💡 延伸阅读：选云服务器别再只看价格了！资深站长私藏的选型指南与避坑实操手册

Q2：网站平时好好的，一到大流量或者跑一段时间就报 502，重启 Nginx 能好一阵，过会儿又不行，是什么鬼？

502 的本质是 Nginx 作为反向代理，无法从上游应用服务器（比如 PHP-FPM、Tomcat、Node.js）拿到有效的响应。重启 Nginx 能好，说明 Nginx 本身没大问题，问题出在它和后端应用的“沟通”上。常见根因有这么几个：

• 后端进程崩溃或假死：比如 PHP-FPM 的进程数不够用，请求排队排到超时，Nginx 等不及就直接返回 502 了。
• 连接超时设置太短：Nginx 默认的 proxy_read_timeout 是 60 秒，如果你的应用处理某个请求需要 70 秒，那必然 502。
• Socket 文件权限或路径不对：Nginx 和 PHP-FPM 之间如果用 Unix Socket 通信，Socket 文件的权限、所有者配置错了，Nginx 没权限读写，也会 502。
• 服务器资源耗尽：内存爆了，OOM Killer 把后端进程杀了，Nginx 自然找不到人干活。

排查的时候，别只盯着 Nginx 的日志看，一定要同时看后端应用的错误日志。Nginx 的 error.log 会告诉你“connect() failed”或者“upstream timed out”，而 PHP-FPM 的慢日志或者 Tomcat 的 catalina.out 才能告诉你后端到底卡在哪。

一个比较通用的优化配置参考：

location ~ \.php$ {
    fastcgi_pass unix:/run/php-fpm/www.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;

    # 适当调大超时时间
    fastcgi_read_timeout 300s;
    fastcgi_connect_timeout 60s;
    fastcgi_send_timeout 300s;
}

预防建议：给服务器装个监控，比如 Prometheus + Grafana，或者简单点用 netdata，实时看 CPU、内存、连接数。另外，Nginx 的 worker_connections 和 PHP-FPM 的 pm.max_children 要根据服务器内存合理设置，别一股脑照搬网上的“万能配置”。

三、磁盘空间莫名其妙满了，怎么快速定位大文件？

💡 深度技术指南：Docker容器配置实战：从踩坑到精通，三种常用方案深度横评与选型指南

Q3：收到告警说磁盘 / 分区使用率 100%，网站后台都进不去了，怎么快速找到是哪个文件在搞鬼？

这是运维生涯里一定会遇到的经典问题。日志文件、数据库 binlog、临时文件、用户上传的垃圾附件，都是嫌疑对象。别慌，按下面这套组合拳来：

# 1. 先看哪个分区满了
df -h

# 2. 从根目录开始，逐层找出大目录（按大小排序）
du -h --max-depth=1 / | sort -rh

# 3. 假设发现 /var 占了 80%，继续往下钻
du -h --max-depth=1 /var | sort -rh

# 4. 最终定位到具体的大文件
find /var/log -type f -size +100M -exec ls -lh {} \;

常见的大文件来源和处理方式：

文件类型	典型路径	处理方式
系统日志	/var/log/messages、/var/log/syslog	配置 logrotate 自动切割，或手动清空：> /var/log/messages
Nginx 访问日志	/var/log/nginx/access.log	切割后压缩归档，或直接删除旧归档
MySQL binlog	/var/lib/mysql/	设置 expire_logs_days=7 自动清理，或手动 PURGE BINARY LOGS
Docker 日志	/var/lib/docker/containers/	在 daemon.json 里限制日志大小

预防建议：部署任何服务之前，先把日志切割和清理策略配好。logrotate 是个好东西，Nginx、MySQL 的日志都能管。另外，数据库的 binlog 如果不是做实时同步，保留 3-7 天足够了，没必要留几个月。如果你的业务增长快，磁盘最好一开始就买大点，云盘扩容虽然方便，但有些厂商扩容后还需要手动扩文件系统，半夜操作容易出错。

四、写在最后：别等出事了才想起基础配置

Linux 服务器的配置与管理，说到底是个“养兵千日”的活儿。很多故障看似突发，其实根因早就埋下了——安全组没配好、日志没切割、超时参数没调、监控没装。笔者自己的习惯是，每上一台新服务器，先花半小时把这几件事做了：改 SSH 端口、配好防火墙、装好监控 agent、设置日志轮转、把关键服务的超时参数根据业务特点调一遍。

如果你正在挑选服务器，记住一点：稳定性和售后响应速度远比那几十块钱的差价重要。正规云厂商的服务器，配合合理的配置，才能让你的业务跑得踏实。域名也一样，选个靠谱的注册商，别因为 DNS 解析不稳定导致网站三天两头打不开，那才是真的因小失大。

希望这篇踩坑记录能帮你少走点弯路。遇到问题别慌，按着日志和排查思路一步步来，大部分故障都能自己搞定。

相关技术专题与延伸阅读

• 深入Docker源代码：从镜像构建到容器运行的底层架构与性能调优实战
• 选云服务器别再只看价格了！资深站长私藏的选型指南与避坑实操手册
• Docker容器配置实战：从踩坑到精通，三种常用方案深度横评与选型指南
• Linux 服务器总被“爆破”或挂马？这份安全加固排查指南，帮你少走弯路