Debian 使用避坑指南｜生产环境实测

Debian 一直以稳定、安全、社区成熟著称，是很多生产环境服务器的首选发行版之一。相比 Ubuntu、CentOS Stream、Rocky Linux 等系统，Debian 的软件包策略更保守，系统更新节奏更克制，长期运行稳定性非常好。但也正因为它“稳”，很多初次在生产环境使用 Debian 的用户，容易踩到一些看似不起眼、实际影响很大的坑。

本文结合生产环境中的实际使用经验，从系统版本选择、安装部署、软件源配置、网络设置、权限管理、安全加固、服务运维、内核与驱动、日志排查、备份恢复等方面，整理一份 Debian 使用避坑指南。文章偏实战，适合准备用 Debian 部署 Web 服务、数据库、中间件、容器平台或内网基础服务的运维人员、开发人员参考。

一、不要盲目追新：生产环境优先选择 Stable 版本

Debian 有多个分支，常见的是：

• Stable：稳定版，适合生产环境；
• Testing：测试版，软件较新，但稳定性不如 Stable；
• Unstable / Sid：滚动开发版，不建议生产使用；
• Oldstable：旧稳定版，仍有安全维护一段时间；
• Experimental：实验性仓库，不适合普通用户。

生产环境强烈建议选择 Debian Stable。例如 Debian 12 Bookworm 是当前常见的稳定版本，适合服务器长期运行。

很多人会因为某些软件版本较老，直接切换 Testing 或 Sid，这在生产环境中风险非常大。Testing 中的软件包虽然看起来更新，但包依赖可能变化频繁，某次升级后服务启动失败、依赖冲突、内核模块不兼容等问题都可能出现。

建议

生产环境优先使用：

cat /etc/debian_version

确认系统版本。如果需要新版本软件，不要轻易升级整个系统分支，而应优先考虑：

• 使用官方 backports；
• 使用容器运行新版本应用；
• 使用软件官方仓库；
• 自行编译并隔离部署；
• 使用专门的运行时管理工具，如 pyenv、nvm、sdkman 等。

二、软件源配置不要混用版本

Debian 最常见的坑之一，就是混用不同版本的软件源。例如系统是 Debian 12，却在 /etc/apt/sources.list 中添加了 Debian 11、Ubuntu 或第三方来源不明的软件源。

这会导致严重后果：

• 依赖关系混乱；
• 系统库被错误升级或降级；
• apt upgrade 时出现大量冲突；
• 服务异常崩溃；
• 后续无法正常安全更新。

正确的软件源示例

以 Debian 12 Bookworm 为例，常见配置如下：

deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

如果服务器在国内，可以使用镜像站，例如清华、阿里云、中科大等。但要注意镜像同步延迟，安全更新源建议确认稳定可用。

修改源后执行：

apt update
apt upgrade

避坑建议

不要随便复制网上的源配置，尤其是包含以下字样的源：

sid
testing
bullseye
buster
ubuntu
jammy
focal

除非你非常清楚自己在做什么，否则不要混用。

三、安装系统时不要忽略 SSH 和基础工具

很多服务器最小化安装 Debian 后，会发现系统非常“干净”，甚至没有 sudo、curl、vim、net-tools、ifconfig 等常用工具。这不是系统异常，而是 Debian 的默认策略偏精简。

建议安装基础工具

apt update
apt install -y sudo vim curl wget git net-tools iproute2 lsof htop tree unzip zip ca-certificates gnupg

如果要远程管理，确认 SSH 已安装并运行：

apt install -y openssh-server
systemctl enable ssh
systemctl start ssh
systemctl status ssh

查看监听端口：

ss -lntp | grep ssh

注意

Debian 中 SSH 服务名通常是 ssh，不是 sshd：

systemctl restart ssh

很多从 CentOS/RHEL 迁移过来的用户会习惯执行：

systemctl restart sshd

在 Debian 上可能会找不到服务。

四、root 登录与 sudo 权限要提前规划

Debian 安装过程中，如果设置了 root 密码，普通用户可能默认不会被加入 sudo 组；如果没有设置 root 密码，安装器可能会让首个用户拥有 sudo 权限。不同安装方式可能存在差异。

生产环境建议：

• 禁止 root 远程密码登录；
• 使用普通用户登录；
• 通过 sudo 执行管理命令；
• 使用 SSH key 登录；
• 管理员账号单独创建，不与业务账号混用。

添加用户到 sudo 组

usermod -aG sudo username

然后重新登录生效。

检查 sudo 权限

groups username
sudo -l

如果没有安装 sudo：

apt install -y sudo

SSH 安全配置建议

编辑：

vim /etc/ssh/sshd_config

建议配置：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

然后重启 SSH：

systemctl restart ssh

注意：修改 SSH 配置前，一定要保留一个已登录的会话窗口，不要贸然断开。最好先新开窗口测试能否登录，确认无误后再关闭旧连接。

五、网络配置：不要把 Debian 当 CentOS 配

Debian 的网络配置方式和 CentOS/RHEL 有明显区别。不同安装环境中，Debian 可能使用：

• /etc/network/interfaces
• NetworkManager
• systemd-networkd
• cloud-init
• ifupdown

服务器环境中常见的是 /etc/network/interfaces 或 cloud-init 管理。

查看网卡名称

ip addr

Debian 现代版本中网卡通常不是 eth0，而是类似：

ens18
ens33
enp1s0

传统静态 IP 配置示例

编辑：

vim /etc/network/interfaces

示例：

auto ens18
iface ens18 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 223.5.5.5 8.8.8.8

重启网络：

systemctl restart networking

或者：

ifdown ens18 && ifup ens18

云服务器注意 cloud-init

很多云服务器上的网络配置由 cloud-init 接管，直接修改 /etc/network/interfaces 可能不会永久生效。应检查：

ls /etc/cloud/

如果存在 cloud-init 配置，应优先查看云厂商文档，或修改：

/etc/cloud/cloud.cfg
/etc/cloud/cloud.cfg.d/

不要在不了解机制的情况下直接禁用 cloud-init，否则可能影响主机名、SSH key、磁盘扩容、网络初始化等。

六、DNS 配置可能被自动覆盖

生产中经常遇到一个问题：修改 /etc/resolv.conf 后，重启系统或网络服务，DNS 又变回去了。

这是因为 /etc/resolv.conf 可能由以下组件自动生成：

• systemd-resolved；
• resolvconf；
• NetworkManager；
• cloud-init；
• DHCP 客户端。

检查 resolv.conf

ls -l /etc/resolv.conf

如果它是软链接，可能指向：

/run/systemd/resolve/stub-resolv.conf
/run/resolvconf/resolv.conf

避坑建议

不要简单粗暴地：

chattr +i /etc/resolv.conf

虽然这样可以防止覆盖，但可能导致系统网络管理组件异常。更好的做法是找到实际管理 DNS 的组件，在对应配置中修改。

例如使用 systemd-resolved 时：

vim /etc/systemd/resolved.conf

配置：

[Resolve]
DNS=223.5.5.5 8.8.8.8
FallbackDNS=1.1.1.1

然后：

systemctl restart systemd-resolved

七、apt 升级不要无脑执行 dist-upgrade

Debian 的包管理非常强大，但也需要谨慎使用。常见命令包括：

apt update
apt upgrade
apt full-upgrade

其中：

• apt update：更新软件包索引；
• apt upgrade：升级已安装软件包，但通常不会删除包；
• apt full-upgrade：可能会安装新依赖或删除冲突包。

生产环境建议日常使用：

apt update
apt upgrade

在大版本升级或处理复杂依赖时，才考虑：

apt full-upgrade

执行前一定要仔细查看 apt 提示，尤其关注：

The following packages will be REMOVED

如果看到系统关键包、数据库包、Web 服务包即将被删除，不要直接确认。

建议流程

apt update
apt list --upgradable
apt upgrade --dry-run

确认无误后再执行正式升级。

八、生产环境更新前必须有快照或备份

Debian 稳定不代表不会出问题。生产环境中，即使是安全更新，也可能带来服务重启、配置文件冲突、依赖变化等问题。

更新前建议至少满足以下条件之一：

• 云服务器创建快照；
• 虚拟机创建快照；
• 重要配置文件已备份；
• 数据库已有可恢复备份；
• 服务具备高可用或回滚方案。

备份常见目录

/etc
/var/www
/var/lib/mysql
/var/lib/postgresql
/var/lib/docker
/home

可以简单使用 tar：

tar czf etc-backup-$(date +%F).tar.gz /etc

数据库不要只备份数据目录，最好使用官方工具导出。例如 MySQL：

mysqldump -uroot -p --all-databases > all.sql

PostgreSQL：

pg_dumpall > all.sql

九、防火墙默认可能没有启用

Debian 默认安装后通常不会像某些发行版一样强制启用防火墙。生产环境中，如果云安全组和本机防火墙都没有限制，服务端口可能直接暴露在公网。

Debian 可使用：

• nftables；
• iptables；
• ufw；
• firewalld。

Debian 12 推荐底层使用 nftables。对于普通用户，ufw 更简单。

安装并启用 ufw

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

避坑提醒

启用防火墙前一定要放行 SSH 端口，否则远程服务器可能直接失联。

如果 SSH 使用自定义端口，例如 2222：

ufw allow 2222/tcp

确认无误后再启用：

ufw enable

十、时间同步不要忽略

服务器时间不准会引发很多问题：

• HTTPS 证书校验失败；
• 日志时间混乱；
• 数据库主从复制异常；
• 定时任务执行异常；
• 分布式系统鉴权失败；
• 容器镜像拉取或签名校验异常。

Debian 通常可以使用 systemd-timesyncd 或 chrony。

查看时间状态

timedatectl

设置时区

timedatectl set-timezone Asia/Shanghai

启用时间同步

timedatectl set-ntp true

如果生产环境对时间精度要求较高，建议使用 chrony：

apt install -y chrony
systemctl enable chrony
systemctl start chrony
chronyc sources -v

十一、不要随意安装第三方一键脚本

生产环境最危险的行为之一，就是直接执行网上的一键安装脚本：

curl xxx.sh | bash
wget xxx.sh -O - | sh

这类脚本可能会：

• 修改系统源；
• 关闭防火墙；
• 修改 SSH 配置；
• 安装未知后门；
• 覆盖系统服务；
• 删除已有配置；
• 安装不受信任的软件包。

即使脚本本身没有恶意，也可能不适配当前 Debian 版本，导致系统环境混乱。

建议

如果必须使用脚本：

1. 先下载到本地；
2. 用编辑器逐行检查；
3. 在测试环境运行；
4. 记录脚本修改了哪些文件；
5. 确认有回滚方案；
6. 不要在核心生产机上直接执行。

十二、Debian 的软件版本偏旧，要理解“稳定”的含义

很多用户安装 Debian 后会觉得：

nginx -v
python3 --version
php -v
node -v

显示的版本不够新，于是认为 Debian “落后”。实际上 Debian Stable 的策略是：版本不追新，但会持续回补安全补丁。也就是说，软件版本号可能没有变化，但安全漏洞已经通过补丁修复。

如何确认安全更新

可以查看 Debian 安全公告：

• Debian Security Tracker；
• /usr/share/doc/包名/changelog.Debian.gz；
• apt changelog 包名。

例如：

apt changelog openssl

新版本软件的推荐方式

以 Node.js、Python、Go、Java 等为例，建议通过以下方式安装新版本：

• 使用官方二进制包；
• 使用语言版本管理工具；
• 使用 Docker；
• 使用 backports；
• 使用官方 apt 仓库。

不要为了一个新版本运行时，把整个系统切到 Testing。

十三、backports 可以用，但不要全量滥用

Debian backports 提供了从 Testing 回移到 Stable 的较新版本软件包。它适合在稳定系统上安装部分较新的软件。

添加 backports 示例，以 Debian 12 为例：

echo "deb http://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware" > /etc/apt/sources.list.d/backports.list
apt update

安装 backports 中的软件：

apt install -t bookworm-backports 包名

避坑建议

不要把 backports 设置成默认高优先级，也不要全量升级：

apt upgrade -t bookworm-backports

这样容易把大量包升级到 backports 版本，增加生产风险。正确做法是按需安装指定软件包。

十四、配置文件升级冲突要谨慎处理

apt 升级过程中，如果某个配置文件被本地修改过，系统可能提示：

Configuration file '/etc/xxx/xxx.conf'
 ==> Modified since installation.
 ==> Package distributor has shipped an updated version.

通常会让你选择：

• 保留当前版本；
• 使用维护者的新版本；
• 查看差异；
• 合并修改。

生产环境不要盲目选择覆盖。很多服务配置都是业务运行的关键，直接覆盖可能导致服务无法启动或安全策略失效。

建议

遇到配置冲突时：

1. 先查看 diff；
2. 记录当前配置；
3. 优先保留本地配置；
4. 手动合并新版配置中的必要变更；
5. 重启服务前先执行配置检查。

例如 Nginx：

nginx -t
systemctl reload nginx

PostgreSQL、MySQL、Redis 等服务也应先检查配置，再重启。

十五、服务管理使用 systemd，别再依赖老命令

Debian 现代版本使用 systemd 管理服务。常用命令：

systemctl status nginx
systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl reload nginx
systemctl enable nginx
systemctl disable nginx

查看服务日志：

journalctl -u nginx
journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"

查看开机启动失败的服务：

systemctl --failed

查看系统启动耗时：

systemd-analyze
systemd-analyze blame

避坑建议

如果服务启动失败，不要只看：

systemctl status 服务名

它显示的日志有限，应结合：

journalctl -xe
journalctl -u 服务名

这样才能看到更完整的错误信息。

十六、日志管理要防止磁盘被写满

生产环境中，磁盘写满是非常常见的问题。Debian 的日志通常位于：

/var/log

systemd journal 日志可能位于：

/var/log/journal
/run/log/journal

查看磁盘使用：

df -h
du -sh /var/log/*

查看 journal 占用：

journalctl --disk-usage

清理 journal：

journalctl --vacuum-time=7d
journalctl --vacuum-size=1G

限制 journal 大小

编辑：

vim /etc/systemd/journald.conf

配置：

SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=7day

重启：

systemctl restart systemd-journald

同时要关注业务日志，例如 Nginx、应用服务、Docker 容器日志。尤其 Docker 默认 json 日志如果不限制，很容易把磁盘写满。

十七、Docker 部署时要限制日志和资源

Debian 上运行 Docker 很常见，但容易忽略日志限制。建议配置 Docker daemon：

vim /etc/docker/daemon.json

示例：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

重启 Docker：

systemctl restart docker

容器数据目录注意事项

Docker 默认数据目录：

/var/lib/docker

生产环境建议：

• 确认磁盘容量充足；
• 避免根分区过小；
• 数据库容器使用 volume；
• 重要数据不要只存在容器可写层；
• 定期清理无用镜像和容器。

清理命令：

docker system df
docker image prune
docker container prune

谨慎使用：

docker system prune -a

它可能删除未使用镜像，导致后续回滚困难。

十八、内核和驱动：稳定优先，不要随便换

Debian Stable 的内核版本通常经过充分测试，适合长期运行。生产环境中不要为了“版本新”随意升级主线内核，除非遇到明确的硬件兼容、性能或安全需求。

什么时候考虑新内核

• 新硬件网卡、磁盘控制器不支持；
• 需要更好的虚拟化支持；
• 需要特定内核功能；
• 存在严重内核漏洞；
• 容器或 Kubernetes 对内核能力有要求。

可以考虑通过 backports 安装较新内核：

apt install -t bookworm-backports linux-image-amd64

升级内核后建议保留旧内核，不要立即清理。若新内核启动异常，可在 GRUB 中选择旧内核回退。

十九、磁盘分区不要过于随意

生产环境安装 Debian 时，磁盘分区要提前规划。常见问题包括：

• / 根分区太小；
• /var 没有单独分区，日志或 Docker 写满根分区；
• 数据库目录与系统目录混用；
• 没有预留扩容空间；
• 未使用 LVM，扩容困难。

推荐思路

根据业务类型规划：

• Web 服务器：关注 /var/www、日志目录；
• 数据库服务器：重点规划 /var/lib/mysql 或 /var/lib/postgresql；
• Docker 主机：重点规划 /var/lib/docker；
• 日志服务器：重点规划 /var/log；
• 通用服务器：根分区不要太小，至少 30G 起步，生产建议更大。

如果条件允许，建议使用 LVM，后续扩容更灵活。

二十、定时任务要注意环境变量

Debian 中 cron 执行任务时，环境变量与交互式 shell 不一样。很多脚本手动执行正常，但放到 crontab 中失败，常见原因是：

• PATH 不完整；
• 工作目录不同；
• 使用了相对路径；
• 没有加载环境变量；
• 输出没有重定向；
• 权限不足。

建议写法

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

脚本中尽量使用绝对路径，例如：

/usr/bin/mysqldump
/usr/bin/tar
/usr/bin/find

查看 cron 日志时，Debian 可能需要查看：

grep CRON /var/log/syslog

二十一、安全加固：不要只依赖默认配置

Debian 默认比较干净，但生产安全仍需主动加固。

基础安全建议

1. 使用 SSH key 登录；
2. 禁止 root 远程登录；
3. 禁止密码登录；
4. 开启防火墙；
5. 只开放必要端口；
6. 定期安全更新；
7. 使用 fail2ban 防暴力破解；
8. 最小化安装软件；
9. 给业务服务使用独立用户；
10. 不要让应用以 root 身份运行。

安装 fail2ban：

apt install -y fail2ban
systemctl enable fail2ban
systemctl start fail2ban

查看状态：

fail2ban-client status

针对 SSH：

fail2ban-client status sshd

虽然 Debian 服务名是 ssh，但 fail2ban 的 jail 名通常仍可能叫 sshd，具体以配置为准。

二十二、AppArmor 可能影响服务访问

Debian 可能启用 AppArmor。它是一种强制访问控制机制，可以限制程序访问文件、网络等资源。某些服务配置正确，但仍无法访问文件时，可能与 AppArmor 策略有关。

查看状态：

aa-status

如果没有命令：

apt install -y apparmor-utils

查看相关日志：

journalctl | grep apparmor

避坑建议

不要一遇到问题就直接关闭 AppArmor。更好的做法是确认被拦截的规则，并为服务调整策略。对于生产环境，安全机制应尽量保留。

二十三、数据库服务不要直接暴露公网

无论是 MySQL、PostgreSQL、Redis、MongoDB，还是 Elasticsearch，都不建议直接暴露公网。即使设置了密码，也可能遭遇爆破、漏洞利用或误配置攻击。

建议

• 数据库只监听内网地址或 localhost；
• 使用防火墙限制访问源 IP；
• 业务访问通过内网；
• 管理访问通过 VPN、堡垒机或 SSH 隧道；
• Redis 必须设置密码和绑定地址；
• Elasticsearch、MongoDB 不要裸奔公网。

以 MySQL 为例，检查监听：

ss -lntp | grep 3306

配置绑定地址：

bind-address = 127.0.0.1

或绑定内网 IP：

bind-address = 10.0.0.10

二十四、大版本升级要走完整流程

Debian 支持从旧稳定版升级到新稳定版，但生产环境不要直接修改 sources.list 后无脑升级。

推荐流程

1. 阅读官方 Release Notes；
2. 完整备份；
3. 在测试环境演练；
4. 确认第三方源兼容；
5. 停止或迁移关键业务；
6. 执行最小升级；
7. 执行完整升级；
8. 检查配置文件变更；
9. 检查服务状态；
10. 保留回滚方案。

简化命令流程通常类似：

apt update
apt upgrade
apt full-upgrade

然后修改源到新版本，再执行：

apt update
apt upgrade --without-new-pkgs
apt full-upgrade

但具体步骤必须以官方文档为准。

二十五、常用排障命令清单

生产环境出现问题时，以下命令非常实用。

系统状态

uptime
top
htop
free -h
df -h
lsblk

网络排查

ip addr
ip route
ss -lntup
ping 8.8.8.8
ping deb.debian.org
curl -I https://www.debian.org

服务排查

systemctl status 服务名
journalctl -u 服务名 -f
systemctl --failed

软件包排查

apt update
apt list --upgradable
dpkg -l | grep 包名
apt-cache policy 包名

日志排查

tail -f /var/log/syslog
journalctl -xe
journalctl --since "30 min ago"

总结：Debian 很稳，但前提是你按它的规则使用

Debian 是非常适合生产环境的 Linux 发行版，但它并不是“装好就万事大吉”。真正稳定的生产环境，依赖的不只是发行版本身，还包括合理的软件源管理、谨慎的升级策略、规范的权限配置、可靠的备份方案、清晰的网络规划以及持续的安全维护。

如果只记住几个核心原则，可以概括为：

1. 生产环境使用 Stable，不要盲目追新；
2. 不要混用软件源，尤其不要混 Ubuntu、Testing、Sid；
3. 升级前先备份，先看 apt 将要做什么；
4. SSH、防火墙、sudo、时间同步要优先配置；
5. 日志、Docker、数据库数据目录要防止写满磁盘；
6. 新版本软件优先用 backports、容器或官方仓库解决；
7. 不要直接执行来源不明的一键脚本；
8. 任何重大变更都应先在测试环境演练。

Debian 的优势在于稳定、可预测、长期维护。只要避开上述常见坑，它完全可以支撑高负载、高可靠的生产业务，并且在长期运维中体现出非常低的维护成本。