Linux服务器基础维护里，最容易被忽略的往往不是高深的内核调优，而是系统时间漂移、日志文件无声膨胀、SSH密钥权限错乱这些日常细节，它们才是真正把服务器拖垮的隐形杀手。
系统时间同步：一个漂移五分钟的服务器有多危险
很多运维把时间同步当成装完系统就完事的工作，实际上NTP服务在长期运行后会悄悄失效，当你排查线上故障时，打开日志发现应用报错时间和你操作的时间对不上，数据库主从复制因为时间差产生脑裂,这才是最棘手的情况。
为什么服务器时间会越走越偏
物理机的CMOS电池老化、云主机的Hypervisor时钟跳动、NTP服务被防火墙拦截后静默退出，这三类原因占据了时间漂移问题的绝大多数场景，刚重装完系统或者从虚拟机模板克隆出来的机器,时间偏差往往高达几十秒甚至数分钟。
时间同步的正确维护姿势
行业共识认为，单纯使用ntpdate强制同步不适合生产环境，因为它会造成时间跳变，影响依赖时间戳的应用程序,正确做法是：
- 安装
chrony作为NTP客户端，配置/etc/chrony.conf指向稳定的时间源，比如ntp.aliyun.com或ntp.tencent.com - 将
chronyd服务设为开机自启，并加入定时任务（例如每小时执行一次chronyc makestep）以防长时间失联后的大幅偏差 - 在监控系统中加入时间偏移量检查项，阈值设偏移超过500毫秒即告警
- 对于内网机器，搭建一台内网NTP服务器，让所有机器指向内网源，避免出网波动
磁盘空间与日志清理：别等df -h报警才动手
磁盘满导致服务宕机，是Linux服务器基础维护中最常见的事故类型之一，更隐蔽的是，df显示的是文件系统整体使用率，而inode耗尽同样会造成“No space left on device”错误，但df -h看到的磁盘空间却还有余量。
日志文件不重启不释放的陷阱
这是最典型的盲区，当你用rm -rf /var/log/nginx/access.log删除日志后，df -h显示空间没有释放，因为nginx进程仍然持有该文件的句柄，正确流程是先执行/usr/sbin/nginx -s reopen让进程重新打开日志文件，或者使用logrotate的copytruncate选项在复制日志后清空原文件。
排查磁盘空间的实操顺序
- 先用
df -h和df -i分别查看块使用率和inode使用率 - 再用
du -sh / 2>/dev/null | sort -hr | head -10逐层定位大目录 - 重点检查
/var/log、/tmp、/var/spool/mail以及Docker的/var/lib/docker/containers目录 - 对于Docker环境，容器内应用持续向stdout写日志会导致
json.log文件无限增长，务必在daemon.json中配置log-opts的max-size和max-file
SSH安全与账户权限：从密钥文件权限到暴力破解
SSH是服务器的大门，使用密码登录在2026年已经属于高风险操作，但即便启用了密钥登录，私钥文件权限过宽（比如644）会让SSH客户端直接拒绝使用该密钥，而公钥写到authorized_keys时若目录或文件属主不对,服务端同样会静默跳过该密钥。
全面加固SSH登录的清单
- 修改
/etc/ssh/sshd_config：PasswordAuthentication no、PermitRootLogin prohibit-password、MaxAuthTries 3 - 使用
ssh-keygen -t ed25519生成密钥，Ed25519算法比RSA 2048更安全且性能更好 - 配置
fail2ban针对暴力破解做IP封禁，这是当前百度搜索中用户高频查询的“linux服务器防暴力破解”场景的通用解法 - 定期查看
/var/log/secure日志中的Accepted publickey记录，检查是否有异常IP登录成功
定期巡检的必要性
不要以为配置好了就一劳永逸，删除离职员工的公钥、更换已泄露的密钥对、核对/etc/passwd中是否有新增的带shell账户，这些动作建议纳入每月例行巡检，另一个细节是/root/.ssh/authorized_keys和.ssh目录的权限，目录必须是700，文件必须是600,否则SSH服务端出于安全策略会拒绝读取。
内核参数与TCP连接状态：性能瓶颈的隐形根源
当业务出现卡顿，很多人第一时间考虑加配置，但实际上很多问题出在Linux内核的默认参数上，比如高并发短连接场景下，TIME_WAIT状态连接堆积会耗尽端口资源。
这组参数你要了解的
net.ipv4.tcp_tw_reuse设置为1，允许将TIME_WAIT连接复用，但注意tcp_tw_recycle在NAT环境下会引发丢包问题，不要盲目开启tcp_tw_recycle，这是Linux服务器基础维护中容易踩坑的地方net.core.somaxconn默认128，高并发下容易导致accept队列溢出，应加大到1024或更高，并同步调整应用层（如nginx的backlog参数）vm.swappiness默认60，对于数据库服务器建议调低到10左右，减少swap交换带来的性能抖动
排查TCP连接状态的常用命令
用ss -s快速查看当前TCP套接字统计，用ss -ant state time-wait统计TIME_WAIT数量，若发现大量SYN_RECV状态，多半是遭受了SYN Flood攻击，调整内核参数前先备份/etc/sysctl.conf，执行sysctl -p生效后观察一周,不要一次性改动过多参数导致无法定位问题。
监控与巡检：别让服务器变成黑盒
很多管理员只在出问题时才登录服务器，平时对运行状态一无所知，一套基础但不简陋的监控体系,能帮你把大多数隐患扼杀在摇篮里。
最容易被遗漏的监控项
- CPU上下文切换次数
：
vmstat输出中的cs列，过高可能意味着线程竞争激烈 - 负载均衡与核心数的比值：负载达到核心数的一倍以上时需警惕，单看“负载”数值不看核心数没有意义
- 磁盘I/O等待时间：
iostat中的%util长期超过80%说明磁盘已经繁忙 - 内存中的Cache与Buffer：Linux会尽量利用空闲内存做缓存，不要看到内存用满就惊慌，关键看
available值
巡检脚本的落地思路
不需要复杂工具，一个crontab定时执行的Shell脚本脚本就能实现基础巡检：检查磁盘使用率超过90%报警、检查NTP同步状态、检查SSH登录失败次数、检查关键进程存活情况、输出结果到日志并配合mailx发送通知，脚本存放于/usr/local/bin/check_server.sh，路径和逻辑越简单越好,方便接手的人一眼看懂。
Linux服务器基础维护常见问题
怎么确认NTP时间同步真的生效了？
执行chronyc tracking查看系统时间与时间源的偏差值，关键的输出字段是System time，它表示当前系统时间相对时间源的偏移量，若值为正且持续增长，说明时钟走快，需要检查时间源是否稳定，同时执行timedatectl确认NTP synchronized: yes，如果显示no，即使chronyd在运行,同步也存在问题。
服务器宕机后重启，如何快速确认是否被人入侵过？
重点检查/var/log/secure和/var/log/messages中的重启时间点日志，执行last命令查看最近登录记录，检查是否有重启前后的异常登录，再比对/etc/passwd文件的修改时间和内容，查看UID为0的非root账户，用find / -mtime -3 -name ".so" -o -name ".ko"排查可疑的恶意动态库，最后使用rpm -Va验证系统关键二进制文件是否被篡改,这是最直接的入侵痕迹检测手段。