CentOS 服务器安装完成后，默认配置虽然可以直接使用，但对于长期运行在公网的 VPS、独立服务器或 Web 服务器来说，通常还需要进行一些基础优化和安全检查。

这次我们使用一台真实安装 CentOS Stream 9 的服务器进行测试，从 CPU、内存、磁盘、端口、防火墙、SELinux 到 BBR 网络配置逐项检查，并给出后续安全加固方法。

本文不是简单复制几十条所谓“Linux 一键优化参数”，而是按照：

检查当前状态 → 找出问题 → 再决定是否修改

的方式进行。

一、测试服务器配置

首先查看操作系统：

cat /etc/os-release

实际返回：

NAME="CentOS Stream"
VERSION="9"
ID="centos"
VERSION_ID="9"
PLATFORM_ID="platform:el9"
PRETTY_NAME="CentOS Stream 9"

可以确认本次测试服务器使用：

CentOS Stream 9

这也是本文后续命令的主要测试环境。

【插入截图：cat /etc/os-release】

二、查看 Linux 内核版本

执行：

uname -r

本次服务器返回：

5.14.0-578.el9.x86_64

说明当前运行的是 EL9 系列 5.14 内核。

查看内核版本非常重要，因为 BBR、网络参数、驱动以及部分安全功能都和 Linux 内核有关。

【插入截图：uname -r】

三、检查 CPU 配置

执行：

lscpu

本次服务器识别到的 CPU 为：

Intel(R) Xeon(R) CPU E3-1230 v6 @ 3.50GHz

主要参数：

项目	实测结果
CPU	Intel Xeon E3-1230 v6
核心	4 Core
线程	8 Thread
基础频率	3.50 GHz
最大频率	3.90 GHz
架构	x86_64
虚拟化	VT-x
L3 Cache	8 MiB

从：

CPU(s): 8
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1

可以判断这是：

1 颗 CPU、4 个物理核心、8 个逻辑线程。

【插入截图：lscpu CPU 信息】

四、不要忽略 CPU 漏洞缓解状态

lscpu 下方还会显示：

Vulnerabilities:

本次服务器可以看到 Meltdown、Spectre、MDS 等项目多数已经显示：

Mitigation

例如：

Meltdown:
Mitigation; PTI

Spectre v2:
Mitigation; IBRS

这代表系统针对相关 CPU 漏洞启用了对应缓解措施。

这里不建议为了追求跑分而随意关闭 CPU 漏洞缓解。

对于生产服务器：

安全性通常比那一点理论性能提升更重要。

【插入截图：lscpu Vulnerabilities】

五、检查服务器内存和 Swap

执行：

free -h

本次测试结果：

              total   used   free
Mem:           15Gi   603Mi  14Gi
Swap:          15Gi     0B   15Gi

服务器拥有大约：

15 GiB 内存 + 15 GiB Swap

当前只使用了约 603 MiB 内存，Swap 使用：

0B

说明测试时系统负载非常低。

【插入截图：free -h】

六、15GB Swap 需要删除吗？

不需要因为“服务器内存大”就直接删除 Swap。

Swap 可以在极端内存压力下提供一定缓冲，但需要关注 Linux 使用 Swap 的积极程度。

查看：

sysctl vm.swappiness

如果服务器主要用于：

Nginx
PHP
WordPress
普通 Web 服务

可以根据实际业务考虑适当降低 swappiness。

例如：

cat >/etc/sysctl.d/90-memory.conf <<'EOF'
vm.swappiness = 10
EOF

应用：

sysctl --system

验证：

sysctl vm.swappiness

注意：

vm.swappiness=10 并不是所有服务器的“最佳值”。

数据库、大内存应用以及内存紧张的小 VPS 都应该根据实际情况调整。

七、检查服务器磁盘

执行：

df -hT

本次服务器磁盘结构：

挂载点	文件系统	容量	已用	可用
`/`	ext4	94G	2.0G	87G
`/boot`	ext4	1.9G	283M	1.5G
`/home`	ext4	1.8T	28K	1.7T

可以看到服务器总磁盘接近：

2TB

但并没有把全部容量都分给根目录 /。

其中 / 大约 94GB，绝大部分空间分配给 /home。

【插入截图：df -hT】

八、进一步检查 LVM 分区

执行：

lsblk

本次实际结构为：

sda
├─sda1
├─sda2          /boot
└─sda3
  ├─vg-rootlv   /
  ├─vg-swaplv   [SWAP]
  └─vg-home     /home

说明系统使用：

LVM + ext4

其中大致分配：

/       → 95.4G
Swap    → 15.3G
/home   → 1.8T

这种结构对于后续磁盘管理比较方便。

【插入截图：lsblk】

九、为什么一定要检查根目录容量？

这台服务器虽然有接近 2TB 磁盘，但：

只有约：

94GB

如果以后把：

网站文件
Docker
数据库
日志
缓存

全部放在根目录相关路径，仍然可能出现：

服务器明明还有 1TB 多空间，但 / 已经满了。

因此服务器上线后建议经常执行：

df -h

同时检查 inode：

df -ih

寻找占用最大的一级目录：

du -xhd1 / 2>/dev/null | sort -h

十、检查服务器公网监听端口

接下来是安全检查中非常重要的一步。

执行：

ss -lntup

本次服务器主要看到：

tcp LISTEN 0 128 0.0.0.0:22
tcp LISTEN 0 128 [::]:22

对应进程：

sshd

说明 SSH 同时监听：

IPv4
0.0.0.0:22

以及：

IPv6
[::]:22

除此之外，chronyd 的 UDP 323 绑定在：

127.0.0.1
::1

并不是直接面向公网监听。

【插入截图：ss -lntup】

十一、为什么 `ss -lntup` 非常重要？

拿到一台新服务器以后，我建议第一批执行的命令就包括：

ss -lntup

因为它可以帮助发现：

MySQL 3306
Redis 6379
PostgreSQL 5432
MongoDB 27017
各种管理后台端口

是否意外监听公网。

例如如果看到：

0.0.0.0:3306

就应该检查：

MySQL 是否真的有必要允许整个互联网直接访问？

很多服务器安全问题并不是 Linux 本身不安全，而是：

把不应该公开的服务直接暴露到了公网。

十二、检查 SELinux

执行：

getenforce

这台测试服务器实际返回：

Disabled

也就是说：

SELinux 当前已经被关闭。

【插入截图：getenforce】

这里需要特别说明：

不要看到：

Disabled

就直接执行：

setenforce 1

因为 SELinux 已经完全 Disabled 时，并不能简单依靠 setenforce 恢复为 Enforcing。

如果准备重新启用 SELinux，需要检查：

cat /etc/selinux/config

并考虑文件标签重新标记以及重启后的兼容性。

对于已经运行生产业务的服务器，更不能在不了解现有服务兼容性的情况下直接强制开启。

十三、CentOS 服务器应该关闭 SELinux 吗？

很多旧教程都会直接执行：

SELINUX=disabled

然后告诉用户：

为了避免软件报错，关闭 SELinux。

这种做法并不适合作为现代 CentOS/RHEL 服务器的通用安全建议。

对于新部署服务器，更推荐：

SELINUX=enforcing

如果应用因为 SELinux 出现权限问题，应先检查：

ausearch -m AVC -ts recent

再针对具体服务调整 Context 或 Policy。

而不是：

软件运行失败
      ↓
直接关闭 SELinux

对于本文这台已经处于 Disabled 状态的服务器，则应该把“重新启用 SELinux”作为单独的维护任务处理。

十四、检查 Firewalld

执行：

firewall-cmd --list-all

本次服务器返回的 public zone 已经处于：

public (active)

说明 Firewalld 已经运行。

接口：

eno1

当前允许的 services：

cockpit
dhcpv6-client
ssh

同时还存在：

ports: 22/tcp

【插入截图：firewall-cmd –list-all】

十五、发现 SSH 22 端口重复放行

这里有一个值得优化的地方。

Firewalld 已经存在：

services: ssh

同时又存在：

ports: 22/tcp

而默认 ssh service 本身就会允许对应 SSH 端口，因此当前属于重复配置。

可以保留：

ssh

然后删除额外的：

22/tcp

执行：

firewall-cmd --permanent --remove-port=22/tcp

重新加载：

firewall-cmd --reload

检查：

firewall-cmd --list-all

注意：

当前服务器仍然通过 SSH 登录，所以不要误删 ssh service。

十六、不使用 Cockpit 可以关闭

当前 Firewalld 还允许：

cockpit

如果服务器实际上没有使用 CentOS Cockpit Web 管理后台，可以先检查：

systemctl status cockpit.socket

确认不需要后：

systemctl disable --now cockpit.socket

从 Firewalld 删除：

firewall-cmd --permanent --remove-service=cockpit

然后：

firewall-cmd --reload

再次检查：

firewall-cmd --list-all

安全加固有一个很重要的原则：

没有使用的服务，不要长期暴露在公网。

十七、检查 BBR 是否开启

接下来检查服务器网络拥塞控制算法：

sysctl net.ipv4.tcp_congestion_control

本次服务器实际返回：

net.ipv4.tcp_congestion_control = bbr

说明：

这台 CentOS Stream 9 服务器已经开启 BBR。

【插入截图：sysctl net.ipv4.tcp_congestion_control】

因此没有必要再重复执行所谓“一键开启 BBR”脚本。

十八、进一步检查 BBR

可以继续执行：

sysctl net.ipv4.tcp_available_congestion_control

查看系统支持的 TCP 拥塞控制算法。

检查队列算法：

sysctl net.core.default_qdisc

检查 BBR 模块：

lsmod | grep bbr

如果系统已经正确运行 BBR，就不需要为了“优化”反复修改。

同时需要注意：

BBR 并不会凭空增加服务器物理带宽。

它属于 TCP 拥塞控制算法。

例如服务器端口本身只有：

100Mbps

开启 BBR 不会把物理端口直接变成：

1Gbps

十九、更新 CentOS Stream 9

完成基础检查以后，首先应该更新系统：

dnf clean all

重新生成缓存：

dnf makecache

更新：

dnf update -y

检查：

dnf check-update

如果更新过程中安装了新内核，建议安排维护窗口重启：

reboot

重启后：

uname -r

确认正在运行的新内核版本。

二十、安装常用服务器工具

可以安装一批日常排查工具：

dnf install -y vim wget curl git unzip zip tar rsync lsof bind-utils traceroute net-tools chrony sysstat smartmontools

这些工具后续可以用于：

网络诊断
DNS 查询
磁盘检查
IO 监控
文件同步
系统时间同步

二十一、配置 Chrony 时间同步

检查：

systemctl status chronyd

设置开机启动：

systemctl enable --now chronyd

查看同步状态：

chronyc tracking

查看时间：

timedatectl

如果需要设置中国时区：

timedatectl set-timezone Asia/Shanghai

再次：

timedatectl

二十二、SSH 安全加固

目前服务器 SSH 直接监听：

0.0.0.0:22
[::]:22

仅仅修改 SSH 端口并不能真正解决 SSH 安全问题。

更值得做的是：

创建管理员账户
       ↓
配置 SSH Key
       ↓
测试密钥登录
       ↓
禁止密码认证
       ↓
禁止 root 远程 SSH

这里一定要严格按照顺序。

二十三、创建管理员用户

例如：

useradd admin

设置密码：

passwd admin

加入 wheel：

usermod -aG wheel admin

检查：

id admin

切换：

su - admin

测试 sudo：

sudo whoami

正常返回：

root

二十四、配置 SSH Key

在自己的电脑生成：

ssh-keygen -t ed25519

然后：

ssh-copy-id admin@服务器IP

服务器检查：

ls -la /home/admin/.ssh/

调整权限：

chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_keys
chown -R admin:admin /home/admin/.ssh

然后重新打开一个终端：

ssh admin@服务器IP

确认 SSH Key 可以正常登录。

二十五、关闭 SSH 密码登录

只有确认密钥登录成功以后才能执行。

创建：

vim /etc/ssh/sshd_config.d/10-hardening.conf

加入：

PasswordAuthentication no
PermitEmptyPasswords no
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 30

保存以后：

sshd -t

如果没有错误，再查看：

sshd -T | grep -E 'passwordauthentication|permitrootlogin|maxauthtries|logingracetime'

确认无误后：

systemctl reload sshd

不要关闭原来的 SSH 窗口。

新开一个终端重新连接。

确认成功以后，再退出旧的 root SSH 会话。

二十六、要不要修改 SSH 端口？

修改 SSH 22 到其他端口可以减少大量自动扫描日志，但它并不是核心安全措施。

真正重要的是：

SSH Key
+
禁止密码登录
+
禁止 root 直接登录
+
Firewalld
+
系统安全更新

如果已经做好这些，即使继续使用 22 端口，也不能简单认为服务器“不安全”。

二十七、调整文件描述符

查看：

ulimit -n

对于运行 Nginx、API、代理等高并发服务的服务器，可以根据业务提高限制。

创建：

vim /etc/security/limits.d/99-server.conf

例如：

* soft nofile 65535
* hard nofile 65535

重新登录：

ulimit -n

不过 systemd 管理的服务可能还需要针对具体服务单独设置 LimitNOFILE。

所以不要认为：

修改 limits.conf 后所有服务都会自动变成 65535。

二十八、基础网络安全参数

普通公网 Web Server 可以考虑一些比较保守的内核安全设置。

创建：

vim /etc/sysctl.d/99-security.conf

加入：

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.tcp_syncookies = 1

应用：

sysctl --system

检查：

sysctl net.ipv4.tcp_syncookies

注意：

VPN、Docker、Kubernetes、软路由、NAT 网关等特殊用途服务器不要机械套用所有网络参数。

二十九、不要一次复制几十条 TCP 优化参数

网上经常可以看到：

net.core.rmem_max = ...
net.core.wmem_max = ...
net.ipv4.tcp_rmem = ...
net.ipv4.tcp_wmem = ...
net.ipv4.tcp_fin_timeout = ...

然后号称：

Linux 网络性能提升 300%。

这种优化方式不建议直接用于生产服务器。

不同服务器的：

内存
带宽
RTT
并发量
业务类型
Linux 内核

都不一样。

对于本文这台服务器来说：

BBR 已经开启，没有必要为了“看起来优化很多”再强行修改几十项 TCP 参数。

三十、检查系统日志和磁盘

查看 journal 占用：

journalctl --disk-usage

如果日志异常庞大，可以按照实际情况清理，例如：

journalctl --vacuum-size=500M

查看大目录：

du -xhd1 / 2>/dev/null | sort -h

查看 /var：

du -xhd1 /var 2>/dev/null | sort -h

检查 inode：

df -ih

不要使用：

rm -rf /var/log/*

这种粗暴方式清理服务器日志。

三十一、检查磁盘 IO

安装：

dnf install -y sysstat

然后：

iostat -xz 1

可以观察：

读写速度
IO 等待
设备利用率
队列

对于网站打开慢、数据库卡顿、服务器 Load 高等问题，磁盘 IO 是一个非常值得检查的指标。

三十二、检查硬盘 SMART

本文测试机器拥有接近 2TB 磁盘。

如果这是可以访问真实硬盘设备的服务器，可以安装：

dnf install -y smartmontools

然后：

smartctl -a /dev/sda

重点关注硬盘：

SMART Health
坏扇区
重映射
错误日志
温度
运行时间

如果是普通 VPS，虚拟化平台可能不会向虚拟机暴露底层 SMART 信息。

这种情况下 smartctl 无法读取并不代表硬盘一定存在故障。

三十三、检查 CPU 和内存占用

CPU：

top

或者：

dnf install -y htop

然后：

htop

查看内存：

free -h

查看 CPU 占用最高的进程：

ps aux --sort=-%cpu | head

查看内存占用最高的进程：

ps aux --sort=-%mem | head

服务器出现：

网站卡顿
SSH卡顿
Load升高

时，这几条命令非常实用。

三十四、优化后建议重新检查

完成所有配置后，可以统一检查：

echo "===== SYSTEM ====="
cat /etc/os-release
uname -r

echo "===== CPU ====="
lscpu | grep -E '^CPU(s)|Model name|Core|Thread'

echo "===== MEMORY ====="
free -h

echo "===== DISK ====="
df -hT

echo "===== PORTS ====="
ss -lntup

echo "===== FIREWALL ====="
firewall-cmd --list-all

echo "===== SELINUX ====="
getenforce

echo "===== SSH ====="
sshd -T | grep -E 'passwordauthentication|permitrootlogin|maxauthtries'

echo "===== BBR ====="
sysctl net.ipv4.tcp_congestion_control

echo "===== SWAP ====="
sysctl vm.swappiness

这样可以非常直观地得到优化后的服务器状态。

三十五、本次实测发现了什么？

通过这次 CentOS Stream 9 服务器检查，我们实际发现：

已经做得比较好的地方

服务器当前：

✓ CentOS Stream 9
✓ Firewalld 已运行
✓ BBR 已开启
✓ 公网监听端口较少
✓ 内存非常充足
✓ 磁盘空间充足
✓ chronyd 仅监听本地地址

可以继续优化的地方

主要包括：

△ SELinux 当前 Disabled
△ Firewalld SSH 22 存在重复放行
△ Cockpit 如果不用可以关闭
△ SSH 可以进一步配置 Key
△ 可以禁止 SSH 密码认证
△ 可以禁止 root 直接远程登录
△ 根据实际业务调整系统资源限制

这也是为什么服务器优化之前应该先检查。

如果直接运行所谓“一键优化脚本”，很可能：

把已经正确的配置重新修改一遍，同时引入新的问题。

总结

CentOS 系统优化并不是：

复制 100 行 sysctl
+
开启 BBR
+
关闭 SELinux
+
修改 SSH 端口

真正适合生产服务器的优化思路应该是：

检查系统
   ↓
更新补丁
   ↓
检查监听端口
   ↓
配置 Firewalld
   ↓
SSH Key
   ↓
减少公网攻击面
   ↓
检查 SELinux
   ↓
检查 CPU / 内存 / 磁盘
   ↓
检查 TCP / BBR
   ↓
根据实际业务优化

特别是本文这台真实服务器，在检查之前 BBR 就已经处于：

net.ipv4.tcp_congestion_control = bbr

如果不先检查，继续运行各种 BBR“一键脚本”没有太大意义。

服务器优化最重要的原则是：

先知道为什么改，再执行修改；能够保持默认值的参数，不要为了“优化”而优化。

FAQ

CentOS Stream 9 需要开启 BBR 吗？

可以根据服务器网络用途考虑，但应该首先执行：

sysctl net.ipv4.tcp_congestion_control

检查当前状态。本文测试服务器已经使用 BBR，因此无需重复开启。

CentOS Stream 9 要关闭 SELinux 吗？

不建议把关闭 SELinux 当作通用优化步骤。新服务器更推荐保持 SELinux 正常工作；如果已经 Disabled，则应规划维护窗口评估重新启用，而不是直接强制切换。

Firewalld 开启以后会影响服务器性能吗？

普通 Web/VPS 场景下，没有必要为了所谓性能直接关闭 Firewalld。相比这点开销，控制公网攻击面通常更加重要。

CentOS 修改 SSH 端口安全吗？

修改端口主要减少自动扫描噪音，不能替代 SSH Key、禁止密码登录、防火墙和系统更新。

BBR 开启以后网速一定更快吗？

不一定。BBR 是 TCP 拥塞控制算法，实际效果受到带宽、线路质量、延迟、丢包、对端网络和业务类型影响。