Linux服务器初始化到运维排查：从SSH加固到Nginx搭建与备份-代码聚汇网

前几天一个朋友买了一台云服务器，登录上去之后盯着终端发呆，来问我第一件事该做什么。这个问题我见过不下几十次了。很多人手里突然有了一台带公网IP的Linux机器，第一反应是装宝塔、装桌面环境、或者直接跑一个不知道哪来的脚本，然后过几天发现服务器被爆破、磁盘满了、站点打不开，最后到处查教程。真正懂服务器的人并不是知道某个冷门命令，而是脑子里有一套“先做什么、后做什么、出问题往哪查”的完整顺序。

这篇备忘录就是我这些年折腾服务器、帮人救火之后的经验沉淀。它涵盖了一个人从拿到服务器到上线业务，再到日常运维和故障排查的完整链路。不管你手里的是一台阿里云、腾讯云、AWS的云主机，还是公司机房里的物理服务器，或者家里一台退役的Intel小主机，只要跑的是Linux，这套思路基本都通用。文章会涉及系统初始化、远程连接、常见服务搭建（比如RTMP推流、Web应用、文件下载）、备份巡检、安全加固，以及一批高频故障的具体排查方法。

文章很长，建议收藏后按需查阅，不用一口气背完。

1. 先把"服务器"这三个字搞清楚：它可能根本不是你想的那台铁箱子

1.1 物理机、虚拟机、云主机和容器，到底哪个才是"服务器"

很多人一听到“服务器”就联想到机房里的机架式铁箱子、闪烁的硬盘指示灯。但实际上在日常工作中，"服务器"这个词指代的范围宽得多。云服务器（ECS、轻量应用服务器、AWS EC2）本质上是跑在物理机上的虚拟机，宿主机把CPU、内存、磁盘通过网络虚拟化切分给多台虚机共用。你ssh登录进去看到的，就是一台完整的Linux系统，底层是什么对它完全透明。

你在自己电脑上用VMware、VirtualBox或KVM开出来的虚拟机，同样也是一台“服务器”。很多人在本机开了一台CentOS虚拟机做实验，结果一模一样。

还有一个容易被忽略的形态：容器（Docker）。容器不是虚拟机，它跟宿主机共享内核，只是通过命名空间做了资源隔离。跑一个nginx容器，它对外提供服务，行为和一台服务器没有区别，但你不能在容器里单独改内核参数。这里有一个关键判断标准——你是用systemd来管理服务的，还是在容器里单跑进程的？前者更像传统服务器，后者更接近“进程隔离环境”。

在我实际帮人排查问题的过程中，遇到过不少这样的乌龙：有人报“服务器连不上了”，结果发现是容器被重启了；有人在容器里改/etc/sysctl.conf，重启后全丢；还有人对着云服务器控制台的“远程连接（VNC）”一脸懵，以为那就是全部。搞清楚你手里的东西属于哪种形态，直接决定了后续操作方式。

1.2 选型决策树：什么场景用什么方案最省钱又省心

选服务器方案，核心是三个约束：预算、性能需求、维护意愿。我见过太多人一上来就买高配，结果CPU常年1%占用；也有人为了省钱买了1核1G的机器，跑个数据库就内存告急。

下面是我这几年用下来比较稳妥的选型参考，按场景分类：

场景	推荐方案	理由
个人博客、轻量API、静态站点	云厂商轻量应用服务器（2核2G起步）	自带镜像市场，防火墙和安全组操作简单，价格便宜
企业Web应用、数据库	云服务器ECS规格（4核8G以上）	存储可选SSD云盘，支持快照备份，适合长期运行
学习Linux、跑实验环境	本机虚拟机（VirtualBox/KVM）	零成本，快照回滚方便，适合乱折腾
家庭影音、NAS、智能家居	Intel NUC/退役台式机 + Linux	功耗低，性能远超同价位云主机，数据在自己手里
临时项目、CI构建	按量付费云主机	用完释放，不浪费
高并发对外服务	服务器集群 + 负载均衡	单机再强也有极限，横向扩展才是正路

关于“免费服务器”和“亚马逊免费服务器”，很多人冲着免费去薅。AWS的免费套餐确实存在（新账号12个月内每月750小时t2.micro/t3.micro），但要注意两个坑：一是超量以后会直接产生账单；二是免费实例性能很弱，装个面板都卡。类似地，国内一些厂商的“免费试用”往往伴有续费要求。如果你只是想练手，我的建议是别把精力花在验证手机号、抢免费名额上，不如用虚拟机或者买一台几十块钱一年的轻量服务器，省下来的时间远超过那点钱。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 新服务器到手，先做这几件事，不然以后天天踩坑

2.1 操作系统与架构选型：Linux发行版不是越新越好

新服务器第一道选择题就是操作系统。国内云厂商默认镜像五花八门：Ubuntu、Debian、CentOS Stream、Rocky Linux、Alibaba Cloud Linux、openEuler……如果你没有特殊理由，我建议Debian系（Ubuntu LTS或Debian stable）优先。

原因很简单：软件源里的包新、依赖好解决、社区资料多。CentOS 7已经全面停止维护，CentOS Stream变成了滚动发行版，不适合追求稳定的生产环境。Rocky Linux和AlmaLinux是RHEL的下游替代，适合那些必须兼容RHEL系的企业场景，或者你之前习惯了yum。但新人的话，别纠结，直接Ubuntu 22.04 LTS或24.04 LTS。LTS版本有五年维护期，后面升级软件不会遇到“源失效”的尴尬。

还有一个容易忽略的点：CPU架构。现在很多云厂商推出了ARM架构实例（比如阿里云倚天、AWS Graviton），同样的配置价格更便宜。如果你的业务是Nginx、Java、Go这类跨架构良好的应用，ARM完全没问题。但如果你要跑一些只有x86二进制包的旧软件，或者依赖某个不开源的.so库，那就老老实实选x86_64。选错架构意味着后面所有软件都得重新找安装方式，甚至装不上。判断架构用一条命令：

bash复制uname -m
# x86_64 表示 Intel/AMD 64位
# aarch64 表示 ARM 64位

2.2 时区、时间同步和主机名：三个"新手必调项"

很多从Windows转过来的人最容易忽略的就是时区。新装系统的默认时区往往是UTC，日志时间比北京时间慢8小时。排查问题的时候你盯着日志，发现时间对不上，还以为服务没反应。

调整时区和时间同步的标准操作：

bash复制# 查看当前时区
timedatectl

# 设置为上海时区（国内服务器统一用这个）
timedatectl set-timezone Asia/Shanghai

# 开启NTP时间同步
timedatectl set-ntp true

# 确认状态
timedatectl

生产环境我强烈建议装chrony做时间同步，而不是依赖系统自带的ntpdate。原因是chrony在虚拟机环境里同步速度更快，而且对网络抖动容忍度更高：

bash复制apt install chrony -y
systemctl enable --now chrony
chronyc sources -v

时间不同步带来的问题非常多。数据库主从复制报错、日志时间错乱、HTTPS证书校验失败、定时任务在奇怪的时间触发——我都遇到过。处理完时区再改主机名：

bash复制hostnamectl set-hostname web-01

改完记得把/etc/hosts里对应的行也改掉，不然有些程序（比如sudo、Java应用）解析主机名会变慢。

2.3 系统盘和数据盘：千万别把所有东西都塞在根分区

云服务器通常会有两块盘：系统盘（40G左右）和数据盘（你额外购买的数据盘）。很多新人拿到机器后根本不管数据盘，所有东西往/目录下写，直到系统盘满了，数据库直接宕掉。

正确的做法是：格式化数据盘、挂载到特定目录，然后把需要持久化的数据都放那里。比如：

bash复制# 查看磁盘
lsblk

# 假设数据盘是 /dev/vdb，格式化并挂载到 /data
mkfs.ext4 /dev/vdb
mkdir -p /data
mount /dev/vdb /data

# 写入fstab实现开机自动挂载
echo '/dev/vdb /data ext4 defaults 0 0' >> /etc/fstab

如果你用的是云厂商的“按量付费数据盘”，这一步尤其重要。因为系统盘通常不支持扩容，数据盘可以随时扩容。把数据放到独立分区，后面扩容只需要在控制台操作，不用迁移数据。

我见过最典型的事故是：有人在系统盘里装了数据库，跑了半年磁盘空间告警，然后试图用软链接把/var/lib/mysql迁到数据盘。结果忘记停服务，直接cp过去导致文件损坏。正确流程永远先停服务再迁移。

另外，磁盘阵列（RAID）也是很多人问到的问题。家用或者单机场景，没必要做RAID；云服务器有云盘三副本机制，做了也是白做。物理机场景可以看后面第5章。

3. 远程连接与日常开发：SSH、VSCode和那些让你抓狂的报错

3.1 VSCode连接远程服务器的完整路径和踩坑点

现在很多开发者习惯用VSCode的Remote-SSH插件直接把服务器当开发机用。局域网、云服务器都行，配置好后就像在本机写代码。

流程不复杂：

本机安装SSH客户端（Windows 10以上自带OpenSSH）。
VSCode装Remote-SSH插件。
配置~/.ssh/config文件：

sshconfig复制Host myserver
    HostName 1.2.3.4
    User root
    Port 22
    IdentityFile ~/.ssh/id_rsa

建议先做SSH密钥免密登录，别用密码。

bash复制ssh-keygen -t ed25519 -C "your_email"
ssh-copy-id root@1.2.3.4

这里有个容易踩的坑：如果服务器sshd_config里设置了PasswordAuthentication no，而你还没把公钥加进去，你就被自己锁在外面了。处理方式是用云厂商控制台的VNC登录进去，把公钥追加到/root/.ssh/authorized_keys，再改回配置。

VSCode远程开发最常遇到的问题有几个：

连接后很久不出界面：多半是服务器上要下载VSCode Server组件，网络慢。可以先手动在服务器上配置镜像源，或者等它慢慢下。
Remote-SSH一直让输入密码：检查本机是否有多个密钥，当前连接的key有没有被agent加载。可以ssh -v看详细输出。
出现了“试图连接到本地网络上的设备被阻止”：这是新版浏览器（Chrome/Edge）的私有网络访问（PNA）拦截，VSCode Web版、Jupyter等Web IDE尤其容易碰到。解决办法是在浏览器设置里允许“不安全内容”，或者直接改用本机VSCode客户端而不是浏览器访问。

3.2 WSL安装时"与服务器的连接被重置"到底怎么破

Windows下装WSL的时候，有人会遇到这样一个报错：

code复制wsl --install 与服务器的连接被重置

这个报错在网上非常高频。它本质是WSL从微软服务器拉取分发版镜像时，网络连接被中断。原因通常是网络不通、代理干扰、或者DNS解析失败。

排查思路按顺序来：

检查网络是否正常：ping microsoft.com。
如果开了系统代理，确认代理是否支持WSL的下载流量。WSL命令走的是WinHTTP而不是IE代理，所以代理设置有时不生效。
检查DNS：nslookup aka.ms，看解析是否正常。如果不正常，临时改用公共DNS（223.5.5.5）再试。
试试用wsl --install -d Ubuntu明确指定发行版，避免默认下载超时。
还可以直接下载安装包手动装：搜“Ubuntu WSL”从官网下载appx安装包，然后Add-AppxPackage。

这个问题的核心是：WSL安装过程依赖网络下载，任何网络层面的阻断都会表现为“连接被重置”。不用急着重装系统，优先排查网络出口。

3.3 防火墙、公网IP和本地网络限制的排查顺序

服务器连不上，百分之八九十不是服务器挂了，而是网络链路某处被挡住了。我的排查顺序固定是：

先ping：如果ping不通，可能是防火墙禁ICMP或IP不对；如果ping通但ssh不通，说明22端口被挡。
再用telnet或nc测端口：nc -vz 1.2.3.4 22。
确认服务器本机服务在监听：ss -lntp | grep 22。
检查云安全组：这个坑出现率极高。云服务器即使本机防火墙关了，安全组不放行端口照样不通。登录控制台，看安全组入方向规则。
检查本地网络：有些公司内网会封禁出站22端口，用手机热点对比一下就知道。

关于“此连接已被阻止,因为它是公共页面发起的,旨在连接到您本地网络上的设备或服务器”，这实际上是Chrome的一个安全特性，面向“公网网页尝试访问局域网IP”的场景。如果你在云服务器上开了一个Web服务，然后从办公网的浏览器直接访问，有些代理环境就会拦。解决办法是：不要在公网页面里嵌入局域网地址；如果是自己调试，用Edge的“允许不安全内容”或者直接访问IP加端口，而不是通过一个公网页面跳转。

3.4 文件传输与下载链接：把服务器文件变成可访问的URL

“服务器文件怎么弄成下载链接”是个高频需求。很多人把文件扔到/root目录，然后问为什么浏览器打不开。因为Web服务器默认根目录在/var/www或/usr/share/nginx/html，不会去读你的home目录。

正确做法是：先装Nginx，然后把文件放到Web目录，或者配置一个alias指向文件所在目录：

nginx复制location /download/ {
    alias /data/files/;
    autoindex on;
}

配置里autoindex on是让目录可以列出文件列表，相当于一个简陋的网盘。这样别人访问http://你的IP/download/文件名就能下载了。

如果你只是临时传文件给别人，更简单的方式是用python3 -m http.server：

bash复制cd /data/files
python3 -m http.server 8080

这个命令会在8080端口起一个静态文件服务，局域网内直接访问IP加端口就能下载。注意这个服务没有鉴权，谁都能下载，用完就关。

生产环境给下载文件加权限，建议用Nginx的X-Sendfile配合后端判断，或者用nginx的auth_basic做最基础的账号密码保护。

4. 服务器上最常搭的几类服务：从推流、录播到Web应用

4.1 RTMP推流服务器：用Nginx搭建一个可用的直播转发节点

RTMP推流服务器在热搜里出现频率很高，主要是做直播、视频会议、摄像头监控回传。很多人一听到“RTMP服务器”就以为要装什么重型软件，实际上用Nginx加一个模块就能搞定。

标准的做法是编译安装Nginx并带nginx-rtmp-module，或者直接用官方带RTMP的镜像。这里给一个最稳妥的编译安装方案：

bash复制apt update && apt install -y build-essential libpcre3-dev libssl-dev zlib1g-dev

wget http://nginx.org/download/nginx-1.24.0.tar.gz
wget https://github.com/arut/nginx-rtmp-module/archive/refs/heads/master.zip

tar zxf nginx-1.24.0.tar.gz
unzip master.zip

cd nginx-1.24.0
./configure --add-module=../nginx-rtmp-module-master
make -j$(nproc)
make install

配置RTMP推流和播放：

nginx复制rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;
            # 允许推流密钥
            on_publish http://127.0.0.1:8080/auth;
        }
    }
}

推流地址形如rtmp://服务器IP/live/房间名，拉流播放也用同样的地址，用VLC或ffplay拉。

实测中的几个关键点：

为什么推流总是断：多半是带宽不足或者RTMP的chunk_size设置问题。
为什么别人播放卡：很多人忽略推流上行带宽，1080p推流至少需要3-4Mbps上行带宽，家用宽带往往不够。
公网推荐用SRT或WebRTC替代RTMP：RTMP对弱网容忍度差，延迟还高。新项目我一般建议直接上SRT，或者用SRS（Simple Realtime Server）而不是裸Nginx，SRS的集群、鉴权、转封装都更完善。

4.2 Node.js启动本地服务与反向代理的配合

Node.js本地启动服务很简单：

bash复制node app.js

但这只是开发模式。生产环境你不能让node直接监听80端口，更不能把它裸奔暴露在公网。原因有三：一是Node进程崩溃后没人自动拉起；二是80/443端口的证书处理、HTTP/2、静态文件压缩这些交给Nginx更成熟；三是Node监听在高权限端口需要root，不符合最小化权限原则。

标准架构是：Node监听127.0.0.1:3000，Nginx反向代理到该端口：

nginx复制server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

进程守护用PM2：

bash复制npm install -g pm2
pm2 start app.js --name myapp
pm2 save
pm2 startup

pm2 startup会生成一条开机自启命令，别漏了。不然服务器重启后你的Node服务不会自动启动。

这个架构还有一个隐藏好处：以后想在同一台服务器上跑多个Node服务、Python服务，只需要新增Nginx的server块就能按域名区分，完全不用管端口冲突。

4.3 高清录播服务器的定位与存储规划

高清录播服务器（在线录播）在教育和政企场景很常见。它通常负责把摄像头采集到的画面编码、录制、存储、并支持在线点播。

很多人以为它是纯软件，其实不然。录播服务器对硬件的需求集中在三块：CPU编码能力、磁盘写入速度、存储空间。

编码：如果不做硬件编码，纯软件x264编码1080p60会吃掉大量CPU。预算充足就上带Intel QuickSync的CPU，或者用NVIDIA NVENC显卡，一台小主机能扛几路1080p编码。
存储：录播的码率和存储公式：每小时文件大小 = 码率(bps) ÷ 8 × 3600秒。比如8Mbps码率，每小时约3.6GB。一天录8小时就是约29GB，一个月就要1TB左右。这个计算在规划磁盘阵列或云盘容量时非常重要。
文件管理：录播文件通常需要按日期和课程ID归档，建议在文件系统里建好以“日期/课程名”命名的目录结构，别让所有文件堆在一个目录里。文件数量到几万之后，单目录索引会拖慢访问。

如果你只是做一个个人用途的低成本“录播”，用FFmpeg就能顶上去：

bash复制ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -b:v 4M -f flv rtmp://server/live/record

再加定时任务自动分段保存，就能实现基础的定时录播。

4.4 小主机、旧电脑当服务器的玩法：Intel小主机做家用服务器

“Intel小主机当服务器”在热搜里很火。确实，NUC、各种迷你主机（比如零刻、铭凡）用来当家庭服务器是性价比极高的选择。功耗只有十几瓦，跑Linux安静稳定，性能跑几个Docker轻松。

我的建议配置是：

CPU：N100或i5+NUC级别足够
内存：16GB起步（跑虚拟机就32GB）
硬盘：一块NVMe SSD做系统，一块机械盘或NAS做数据
系统：Debian或Ubuntu Server，Minimal安装不装桌面

装好系统后，日常玩法的优先级是：Docker跑各类服务（比如Jellyfin、Nextcloud、Home Assistant）、Samba或NFS做文件共享、再配一套定时备份。这些服务用docker-compose编排，比直接装软件省心得多。

家用服务器的核心风险是“宕机没人知道”。如果是我，至少会配一个远程唤醒（Wake-on-LAN）和一条智能插座控制回路，再挂一个cron任务把运行状态上报到一个免费健康检查服务。

5. 运维必须养成的习惯：巡检、备份与灾难恢复

5.1 写一个简单的服务器巡检脚本：别再用眼睛盯了

服务器运维最枯燥的就是巡检。我建议写一个脚本，每天自动跑，只输出异常项。脚本逻辑不复杂：检查CPU负载、内存、磁盘、服务状态、最近登录IP。

一个可以直接改的巡检脚本：

bash复制#!/bin/bash

alert=0

# 1. 磁盘空间
df -h | awk 'NR>1 {if ($5+0 > 80) print "磁盘告警: "$6" 使用率 "$5}'

# 2. 内存
total=$(free -m | awk '/Mem:/{print $2}')
used=$(free -m | awk '/Mem:/{print $3}')
rate=$((used * 100 / total))
if [ $rate -gt 90 ]; then
  echo "内存告警: 使用率 ${rate}%"
  alert=1
fi

# 3. CPU负载（1分钟负载除以核数大于4告警）
load=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1)
cores=$(nproc)
if [ $(echo "$load > $cores" | bc) -eq 1 ]; then
  echo "负载告警: load=$load cores=$cores"
  alert=1
fi

# 4. 关键服务状态
for svc in nginx mysql docker; do
  systemctl is-active $svc >/dev/null 2>&1 || echo "服务告警: $svc 未运行"
done

# 5. SSH失败登录次数
fail_count=$(grep "Failed password" /var/log/auth.log 2>/dev/null | wc -l)
echo "最近SSH失败登录次数: $fail_count"

配合cron每天跑一次：

code复制0 8 * * * /root/scripts/check_server.sh >> /var/log/server_check.log 2>&1

如果你愿意折腾，用Grafana+Prometheus做监控是专业方向，但对绝大多数场景，一个简单的脚本加邮件告警完全够用。关键是先跑起来，后面再慢慢加指标。

5.2 磁盘阵列怎么做：不是所有场景都需要RAID

“服务器磁盘阵列怎么做”是物理机用户的高频问题。先说结论：八成场景不需要RAID，尤其是云服务器。云盘的持久性靠的是底层的三副本机制，本地RAID属于多此一举。只有当你用的是物理机、SATA盘/SSD直插，才有必要考虑。

RAID级别选择，我的建议很直接：

RAID级别	最少磁盘数	作用	适用场景
RAID 0	2	条带化，性能翻倍	临时数据、缓存服务（不要求可靠性）
RAID 1	2	完全镜像，坏一块盘不丢数据	系统盘、数据库日志盘
RAID 5	3	奇偶校验，允许坏一块盘	视频监控录像、文件存储
RAID 10	4	镜像+条带，兼顾性能和可靠性	数据库、虚拟化存储

硬件RAID和软件RAID的选择：如果是家用/小企业，强烈建议直接用主板自带的软RAID（实际上是Linux的mdadm），别买杂牌阵列卡。硬件卡的电池掉电、缓存策略对新手不友好，阵列卡一旦损坏，数据反而更难恢复。mdadm的好处是源码级透明，用mdadm --detail可以看到盘的状态，灾难恢复也更可控。

创建软RAID1的示例：

bash复制mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 /dev/md0
mkdir /data
mount /dev/md0 /data
mdadm --detail /dev/md0

# 保存配置
mdadm --detail -sc >> /etc/mdadm/mdadm.conf

实测中最容易忽略的是掉盘预警。很多人配了RAID但不知道哪块盘坏了，直到坏第二块盘才整体崩溃。建议监控/proc/mdstat，有U（unused）状态就要立刻替换盘：

bash复制cat /proc/mdstat

5.3 用群晖NAS给Linux服务器做备份，以及从NAS还原服务器

群晖NAS在热搜里和“服务器备份”绑定在一起，因为它的Synology Drive、Hyper Backup和rsync服务非常适合做异地备份。

最省事的方案是让Linux服务器通过rsync推送到群晖。群晖开启rsync服务（控制面板-文件服务-rsync），然后在Linux服务器上：

bash复制rsync -avz --delete /data/ rsync://backupuser@nas_ip/backup/data

如果觉得rsync太原始，可以用群晖的Hyper Backup套件从Linux服务器拉数据，它会处理增量、版本、去重。我个人更推荐“服务器主动推”的方案，因为源码在服务器上，更容易加脚本、打包、加密。

“怎么通过NAS还原服务器”的步骤：

在NAS备份目录里找到对应时间点的文件。
恢复到服务器之前，先验证文件完整性：rsync -avz --dry-run空跑一遍，确认文件数量、大小一致。
正式恢复时建议把服务停掉，再rsync，避免文件写入导致状态不一致。

一个常见的备份误区是：备份脚本执行成功就算备份完成。我见过有人备份了半年，恢复时才发现rsync目标目录权限不对，文件全是0字节。正确做法是备份脚本里加校验，比如备份后对比文件数量和总大小，或者对关键目录做tar归档后校验md5。

5.4 用KVM给服务器做系统：机房物理机的标准操作

“通过KVM给服务器做系统”里的KVM有三个含义：一个是Linux虚拟化模块（Kernel-based Virtual Machine），另一个是机房里的KVM切换器（Keyboard-Video-Mouse），这里主要讲后者——通过IPMI/KVM远程安装系统。

在机房物理机上装系统，你不能像云主机那样在控制台点“重装”。标准流程是：

服务器接入IPMI管理口，获取IPMI IP。
浏览器打开IPMI的Web控制台，用Java/HTML5启动KVM会话。
加载系统ISO镜像（可以挂载到虚拟光驱）。
从虚拟光驱引导，正常安装。

实际操作中容易卡住的点：

ISO镜像挂载后无法引导：检查启动顺序，在BIOS里把虚拟光驱（Virtual CD/DVD）设为第一启动项。有些服务器要按F11/F12选一次性引导设备。
Java控制台打不开：新版IPMI固件一般提供HTML5控制台，如果只有Java版，需要装java webstart并配置例外站点，很多老服务器被卡在这一步。
装完系统无法上网：检查网卡命名，新系统默认网卡名可能从eth0变成了enp3s0，需要重新配置/etc/network/interfaces或NetworkManager链接。

如果你在云上用的是KVM虚拟机而不是物理KVM，那么“通过KVM给服务器做系统”更多指libvirt命令行创建虚拟机：

bash复制virt-install \
  --name test-vm \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/test-vm.qcow2,size=10 \
  --os-type linux \
  --network bridge=br0 \
  --cdrom /path/to/ubuntu.iso

6. 故障排查手册：数据库、权限、时区和各种连接失败

6.1 pgAdmin4无法连接服务器：先怀疑这五个地方

pgAdmin4无法连服务器是热搜常客。大多数是第一次装PostgreSQL的新手，连接报错或者连上后超时。排查顺序非常重要，否则你会浪费时间改错地方。

按概率排序，这五个地方逐个查：

PostgreSQL服务没监听外网或没监听端口。默认安装只监听127.0.0.1。改/opt/pgdata/postgresql.conf里的listen_addresses = '*'。

pg_hba.conf没有允许对应来源IP。默认只允许local。常见配置：

code复制# PostgreSQL 15+ 默认在 /etc/postgresql/15/main/pg_hba.conf
host  all  all  0.0.0.0/0  scram-sha-256

防火墙拦截。检查ufw或cloud安全组是否放行5432端口。
密码认证方式不对。pgAdmin连接时，如果数据库用户用了md5旧认证，而pg_hba配置的是scram-sha-256，就会报“password authentication failed”。
PG版本问题。pgAdmin对低版本PG（9.x以下）支持不完整，建议直接装新版。

另外一个隐蔽坑：云厂商的RDS（云数据库）连接时，很多厂商默认只允许VPC内网访问，你在本地用pgAdmin连不上。解决办法是开公网访问（注意安全）或者用跳板机ssh隧道：

bash复制ssh -L 5432:your-rds-endpoint:5432 root@your-ecs

然后pgAdmin连localhost:5432即可。

6.2 "没有权限下载此文件"：Web权限配置的经典坑

报错“服务器响应显示您没有权限下载此文件”通常来自Nginx或Apache。绝大多数情况下不是真的安全拦截，而是权限位不对。

Nginx的权限判定逻辑是：Nginx worker进程（通常以www-data或nginx用户运行）需要对文件有读权限，且对路径上的所有目录有执行权限。

比如你的下载目录是/data/download，但目录权限是：

bash复制drwx------ 3 root root 4096 /data
drwxr-xr-x 2 root root 4096 /data/download

Nginx用户无法进入/data目录，就会报403。正确做法是确保路径上每层目录都有o+x权限：

bash复制chmod o+x /data
chmod -R o+r /data/download/

如果用了autoindex on目录列表，还需要目录有o+r权限。如果依然403，看Nginx配置里是不是特意返回了403：

nginx复制# 有人会在location里写
# return 403;  # 检查是否有这种配置

还有一种情况：文件本身没问题，但Nginx对.zip、.rar这类文件没有配置MIME类型，导致浏览器直接下载时被当成二进制显示。加上这个配置：

nginx复制types {
    application/zip zip;
}

实测下来，90%的“没权限下载”问题就是权限这行命令没执行对，先把权限搞定再怀疑后端逻辑。

6.3 游戏无法连接服务器、浏览器阻止本地设备访问：别急着怪服务器

“搭建虚拟机后游戏无法连接服务器”、“率土之滨显示未选择服务器”——这些游戏联机问题，不完全是服务器故障，更多是网络路径和协议匹配问题。

排查这类问题，我总结了几个先看的东西：

服务端监听地址：游戏服务端默认很可能只监听127.0.0.1，外部永远连不上。改监听地址为0.0.0.0。
服务器端口是否被安全组放行：很多游戏需要TCP+UDP双通道，HTTP/HTTPS端口放开了但游戏端口没放。
本地网络NAT/PAT：如果你是在虚拟机里跑服务器，宿主机要访问虚拟机里的服务，需要设置端口转发（VirtualBox的NAT端口转发或VMware的自定义NAT）。
“未选择服务器”的情况：通常在游戏登录器里，游戏服务器列表是请求一个文本接口拿到的。如果这个接口返回的不是公网可达地址（比如返回了局域网IP），客户端就会找不到服务器。这是非常经典的坑——服务端配置里写错了“服务器IP”。

“虚拟机游戏无法连接服务器”的另一个常见原因是：游戏服务端绑定在虚拟机的网卡上，而虚拟机网络模式是NAT。NAT模式下，宿主机访问虚拟机需要转发，外部访问更麻烦。直接改成桥接模式，让虚拟机获取局域网IP，问题马上就解决了。

浏览器端“此连接已被阻止”前面提过，它不是服务器挂了，而是浏览器安全策略拦截。遇到这类提示，先看浏览器地址栏左侧的锁标，一般会告诉你具体是哪条安全策略。不要一看到“被阻止”就反编译服务器配置，方向就错了。

6.4 域服务器修复和Windows服务器常见维护

“域服务器修复”属于Windows Server维护范畴，主要出现在企业内网。域控（DC）一旦出问题，全公司电脑登录、组策略、DNS都会瘫痪。

我处理过的域控故障里，出现频率最高的是这几种：

活动目录数据库损坏：表现为dcdiag报DSSERVICE或NTDS错误。先做非授权还原：重启进目录服务还原模式（DSRM），用ntdsutil检查数据库完整性，再做快照还原。
DNS服务挂了：域控本身兼任DNS服务器，DNS一挂所有域客户端找不到域控。检查DNS服务状态，确认SRV记录还在。nslookup -type=SRV _ldap._tcp.dc._msdcs.域名能查到说明正常。
域控间复制失败：repadmin /replsummary查看复制状态，通常由证书过期或DNS解析问题导致。

不过说句实在话，现在企业新项目我建议别硬撑单域控。域控至少搞两台，重要业务数据用云上托管AD或者用Entra ID（以前叫Azure AD）做轻量替代。单点域控修复的过程非常痛苦，恢复期间全公司都没法登录系统，这种事故影响面太大了。

如果你只是维护一台Windows Server（比如给金蝶数据库升级到SQL2005，或者给泛微OA更新授权），核心思路是先备份，再操作。Windows Server上安装SQL Server、更新授权这类操作，绝对不要在生产环境直接点“下一步”，建议先在低峰期操作，并且一定要做系统状态备份和快照。

7. 安全加固：服务器暴露到公网之前的最后一道门

7.1 最小化权限与SSH安全基线

服务器上线前如果只做一件事，请先做SSH安全加固。公网机器人扫描是最多的，root+弱口令几乎一小时内就会被爆破。

我的SSH基线建议：

禁止root直接登录，新建一个普通用户并用sudo提权：

bash复制useradd deploy
passwd deploy
usermod -aG sudo deploy

禁用密码登录，只允许密钥登录：

bash复制# 编辑/etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

修改SSH端口（可选，能有效降低扫描噪音）：

bash复制Port 2222

配置Fail2Ban自动封禁暴力IP：

bash复制apt install fail2ban
systemctl enable --now fail2ban

防火墙只放行必要端口，用UFW：

bash复制ufw default deny incoming
ufw allow 2222/tcp
ufw allow 80,443/tcp
ufw enable

这里要说一个核心逻辑：安全不是把门锁死，而是要缩小暴露面。禁用密码登录比安装任何杀毒软件都有效，因为密钥爆破的复杂度远高于密码。同时，建议设置一个登录后的邮件/钉钉告警，server登录后能收到提示，这样即使有人进来了也能第一时间知道。

7.2 Web服务器安全的基础配置

Web服务器加固，我按重要性排序：

自动HTTPS：用Let's Encrypt或云厂商免费证书，nginx配置证书并启用HTTP/2。证书到期前自动续期：
```
bash复制certbot --nginx -d example.com
```
隐藏服务器版本信息：nginx.conf里加server_tokens off;
限制文件上传大小和请求体大小，防止恶意上传：
```
nginx复制client_max_body_size 20m;
```

禁止危险HTTP方法：

nginx复制if ($request_method !~ ^(GET|HEAD|POST)$) {
    return 405;
}

配置访问日志切割：access.log长期不切会占满磁盘。用logrotate，按天切，保留30天。

有一个易被忽略的点：反向代理场景，要处理X-Forwarded-For伪造问题。Nginx在作为反代时不建议无条件信任X-Forwarded-For头，否则攻击者可以伪造IP绕过IP白名单。正确做法是在Nginx里用real_ip模块配合云厂商的header（比如X-Real-IP）来获取真实IP。

7.3 免费云服务器的安全组和快照意识

说到免费/便宜云服务器，尤其是AWS免费套餐，我多说几句。很多人薅了一台免费机器，却忽视了它的安全配置，导致账号被盗、流量跑光、产生巨额账单。AWS的安全组默认最宽松，实例一开就有公网访问。

使用免费服务器的三条底线：

安全组默认拒绝所有入站，只放行你需要的端口。
绑定密钥对登录，不要用密码。
开启账单预警，设置一个预算额度，快超时提醒。

快照意识也很重要。云服务器的快照就是你最便宜的后悔药。我给自己定的规矩：任何配置变更前，先打一个快照。升级内核、改数据库配置、调大磁盘、迁移数据前都打。快照的RPO（恢复点目标）是分钟级，而重建一台机器加恢复数据可能需要几小时。快照永远比补丁便宜。

我自己手里挂过一台长期跑批处理的机器，就是忘记打快照后，一个错误的rm -rf命令清理了半年数据，最后靠云厂商的回收站和历史版本才捡回一部分。那次之后，我把“先快照再变更”写成了所有服务器操作的第一条铁律。

文章写到这里，最后再分享一个小习惯：每次给服务器做操作，尤其是涉及系统配置、数据库、安全策略的变更，我都会先写下“改动前状态”和“改动后预期”，然后操作完再验证。这个习惯帮我省了无数回滚的时间。服务器这个东西，真正值钱的不在配置有多高、技术有多炫，而在它稳定、安全、可恢复。希望这份备忘录能让你少走一些我走过的弯路。

Linux服务器初始化到运维排查：从SSH加固到Nginx搭建与备份