Ubuntu安装配置与Nginx反向代理部署实战指南

在实际开发和学习中，Ubuntu 往往是从 Windows 或 macOS 转向 Linux 的第一站。它既有完整的桌面环境，也有和服务器上几乎一致的命令行体系，安装完之后既能当日常开发机用，也能当作部署服务的实验环境。真正让人卡住的，往往不是“怎么点下一步”，而是镜像该选哪个版本、U 盘怎么做、分区怎么划、装完之后网络为什么不通、SSH 为什么连不上、服务为什么起不来。这篇教程按一条完整主线走：先讲清楚版本和安装介质的取舍，再完成一次可复现的安装，然后做基础环境配置，最后部署一个能被浏览器访问的 Web 服务，并把常见故障的排查路径整理出来。读者跟着走完，应该能得到一台可以正常联网、可以用 SSH 登录、能跑起一个后端服务并被 Nginx 反向代理的 Ubuntu 机器。

1. 先搞清楚 Ubuntu 版本和安装形态在解决什么问题

安装 Ubuntu 之前，最容易犯的错误不是操作失误，而是选错了版本或装错了形态。装完才发现驱动不认、软件源对不上、或者一台服务器上装了带图形界面的系统，白白吃掉几百 MB 内存。所以在动手之前，先把几个基础概念对齐，后面的步骤才不会反复推倒重来。

1.1 LTS 版本和普通版本的区别

Ubuntu 的版本号用“年份.月份”表示，比如 22.04 是 2022 年 4 月发布，24.04 是 2024 年 4 月发布。带 LTS 后缀的是长期支持版本，桌面版通常提供 3 年支持，服务器版提供 5 年，部分版本可以通过扩展维护进一步延长。普通版本（比如 24.10、25.04）支持周期只有 9 个月左右，适合想尝鲜新内核、新桌面环境的用户。

对绝大多数人来说，选择 LTS 是更稳妥的做法。原因很直接：软件仓库稳定、社区资料多、第三方教程和排错贴基本都围绕 LTS 写、生产环境也普遍使用 LTS。下面这张表可以帮助快速判断：

这里有一个容易误解的点：LTS 不等于“永远不会变”。LTS 仓库里依然会收到安全更新和缺陷修复，只是不会引入大的版本跃迁。所以生产机器不要随意执行跨大版本的 do-release-upgrade，升级前要做快照和回滚预案。

1.2 桌面版和服务器版的差异

桌面版和服务器版共用同一套内核和包管理体系，差异主要在预装内容上。桌面版带 GNOME 图形环境、浏览器、办公软件、NetworkManager 等；服务器版默认只有命令行，网络配置走 netplan，服务管理走 systemd。

在常见项目里，可以按这个顺序判断：

• 需要浏览器、IDE 图形界面、截图工具：装桌面版。
• 只跑服务、做远程开发、资源有限：装服务器版。
• 想两者兼顾：先装服务器版，再按需安装轻量桌面或直接使用 VS Code Remote 远程开发。

需要提醒的是，服务器上装完整 GNOME 会带来额外的内存占用和攻击面。如果只是偶尔需要图形化工具，更推荐用 SSH 端口转发配合本地图形客户端，而不是在服务器上长期跑一个桌面环境。

1.3 引导方式：UEFI 和 Legacy BIOS

安装介质能不能被识别，很大程度上取决于固件引导方式。现代机器基本都使用 UEFI，老机器可能是 Legacy BIOS 或 CSM 兼容模式。两者的关键差异在于分区表：UEFI 通常配合 GPT 分区表，需要一个 EFI 系统分区（ESP）；Legacy BIOS 通常配合 MBR 分区表，引导信息写入磁盘主引导记录。

如果 U 盘做好了却进不去安装界面，先别怀疑镜像，先检查这两点：

1. 固件里是否关闭了 Secure Boot（部分显卡驱动和第三方内核模块在开启状态下会加载失败）。
2. 启动菜单里是否同时出现了 “UEFI: 你的U盘” 和普通 “你的U盘” 两个条目，选错会导致安装器以另一种模式启动，最终装出来的系统引导方式和你预期不一致。

注意：一台机器上如果已经装了 Windows，安装 Ubuntu 时要明确是“共存”还是“整盘覆盖”。整盘覆盖会清空原有数据，操作前必须确认磁盘设备名，避免把数据盘当成系统盘格式化。

理解这三组概念之后，安装就不再是“照着界面点”，而是每一步都知道自己在做什么。接下来的准备阶段，本质上是把这三件事落实到具体的镜像、U 盘和分区方案上。

2. 安装前的准备：镜像校验、启动盘和分区规划

准备阶段做得好，安装过程会非常顺；准备阶段偷懒，问题往往会在装到一半或者首次启动时才暴露出来，排查成本高很多。这一节把镜像下载、校验、启动盘制作、分区规划拆开讲，每一步都给出可执行的命令和检查点。

2.1 下载镜像并做完整性校验

从镜像站下载 ISO 之后，第一步不是急着写 U 盘，而是校验哈希。下载中断、镜像站同步不完整、网络传输错误都会导致 ISO 损坏，表现通常是安装到某个阶段报 “I/O error” 或者直接卡死。

Linux 或 macOS 下可以直接用 sha256sum 或 shasum：

bash复制# 计算 ISO 的 SHA256
sha256sum ubuntu-24.04.3-desktop-amd64.iso

# macOS 使用
shasum -a 256 ubuntu-24.04.3-desktop-amd64.iso

Windows 下可以用 PowerShell：

powershell复制Get-FileHash .\ubuntu-24.04.3-desktop-amd64.iso -Algorithm SHA256

把输出结果和镜像站公布的 SHA256SUMS 文件里的对应行比对，完全一致才算通过。如果镜像站同时提供了 GPG 签名，可以进一步用 gpg --verify 验证签名文件，确认镜像来源没有被篡改。

检查点：哈希一致，且 ISO 文件大小和官网标注一致。两者有任何一项不符，重新下载，不要抱着“也许能装”的心态继续。

2.2 制作启动 U 盘

U 盘容量建议 8GB 以上，制作过程会清空 U 盘内所有数据，提前备份。三种常见做法：

Linux 下用 dd 的完整流程如下。先用 lsblk 确认 U 盘设备名，不要直接照抄示例里的 /dev/sdb：

bash复制lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL

输出里能看到 U 盘的容量和型号，确认无误后执行写入：

bash复制# 如果 U 盘已自动挂载，先卸载
sudo umount /dev/sdb* 2>/dev/null

# 写入镜像，oflag=sync 保证数据落盘
sudo dd if=ubuntu-24.04.3-desktop-amd64.iso of=/dev/sdb bs=4M status=progress oflag=sync
sync

写完后再执行一次 lsblk，能看到 U 盘上出现了一个带 EFI 分区标记的分区，说明写入成功。

注意：dd 的 of= 参数指向的是整块磁盘设备（如 /dev/sdb），不是分区（如 /dev/sdb1）。写错目标设备是这类操作里后果最严重的错误，执行前一定要用容量和型号双重确认。

2.3 分区方案怎么定

安装器提供“自动分区”和“手动分区”两种方式。学习环境用自动分区完全够用，但如果要长期使用，建议手动规划。下面是一套通用方案，适用于单系统、500GB 左右磁盘：

几个取舍说明：

• EFI 分区不要太小。内核更新时旧文件会堆积，512MB 在长期使用中偶尔会紧张，1GB 更稳妥。
• 现代机器内存普遍较大，swap 不必严格按“内存两倍”来。如果不用休眠，8GB 的 swap 文件或分区已经足够应对突发内存压力。
• 把 /home 独立出来，重装系统时可以不格式化它，数据保留下来。这是长期使用中最省事的一个决定。
• 如果磁盘是 NVMe，设备名形如 /dev/nvme0n1，分区是 /dev/nvme0n1p1。这一点和 SATA 盘的 /dev/sda1 不同，手动分区时容易看错。

2.4 固件设置和启动

进入固件设置界面的按键因厂商而异，常见的是 F2、F10、F12、Del、Esc。进去之后需要确认三件事：启动模式（UEFI/Legacy）、Secure Boot 状态、启动顺序。

检查清单：

• 启动模式设为 UEFI（如果要和已装系统共存，必须和原系统的引导方式一致）。
• Secure Boot 可以先关闭，装完系统、确认驱动正常后再决定是否开启。
• 启动顺序把 U 盘调到第一位，或直接用一次性启动菜单选择。
• 如果机器开了 RAID 模式而你要装普通单盘系统，先把存储控制器改成 AHCI，否则安装器可能看不到磁盘。

准备阶段结束的标志是：镜像校验通过、U 盘可引导、分区方案写在纸上、固件设置确认完毕。到这一步再进安装界面，心里就有底了。

3. 安装流程逐步操作与手动分区要点

安装向导本身的交互不复杂，但有几个节点会直接影响后续使用体验：语言和键盘布局、安装类型选择、手动分区、用户创建、以及是否勾选额外驱动。这一节按真实操作顺序走一遍，重点讲清楚每一步背后的影响。

3.1 从启动菜单到安装类型选择

U 盘启动后会看到 GRUB 菜单，默认项是 “Try or Install Ubuntu”。直接回车进入即可，如果显卡较新导致花屏或黑屏，可以在菜单里按 e 编辑启动参数，在 linux 那一行末尾临时加上 nomodeset，进入系统后再安装闭源驱动。

进入桌面后启动安装器，前几步是语言、键盘布局、网络连接、安装类型。这里有两个选择值得展开：

• 正常安装 vs 最小安装：最小安装不预装办公套件和部分多媒体软件，体积小、装得快，适合服务器或只做开发的机器。后期需要什么再用 apt 装回来。
• 是否安装第三方驱动：勾选后会安装显卡、无线网卡等闭源驱动。笔记本和无线上网场景建议勾选，否则可能出现装完没有 Wi-Fi 的情况。

网络这一步建议连上网。安装器会在此期间下载语言包和更新，虽然会让安装变慢，但能减少装完后手动补依赖的次数。如果网络环境不稳，也可以跳过，装完再统一更新。

3.2 手动分区的具体操作

在“安装类型”页面选择“其他选项”进入手动分区。假设磁盘是空的 /dev/nvme0n1，操作顺序如下：

1. 选中磁盘，点击“新建分区表”，选择 GPT。
2. 新建 EFI 分区：大小 1024MB，类型 “EFI System Partition”，文件系统 FAT32，挂载点 /boot/efi。
3. 新建 swap：大小 8192MB，类型 “swap area”。
4. 新建根分区：大小 80GB，类型 ext4，挂载点 /。
5. 剩余空间新建 /home，类型 ext4，挂载点 /home。
6. 确认“安装启动引导器的设备”指向整块磁盘 /dev/nvme0n1，不是某个分区。

分区完成后，安装器会弹窗确认写入磁盘。这一步是不可逆的，确认前再看一遍设备名和分区列表。如果机器上有其他数据盘，务必确认没有误选。

一个常见坑是 EFI 分区类型选错。如果把 EFI 分区建成了 ext4 或者普通 FAT32 而没有标记 esp 标志，安装能走完，但重启后固件找不到引导项，直接进入原系统或黑屏。判断方法是：安装完成后用 Live 环境执行 lsblk -f，看 EFI 分区是否显示 vfat 且挂载点正确。

3.3 用户创建与时区设置

用户创建页面有几个细节：

• 用户名建议全小写，不要含空格和特殊字符，否则某些脚本和容器环境会出问题。
• 密码不要设得太简单，如果这台机器会开放 SSH，弱密码是很现实的风险。
• 主机名同样建议小写短横线风格，比如 dev-box-01。

时区选择会影响日志时间戳、证书有效期判断和定时任务执行时间。选错时区后，日志排查时会出现“明明两点出的问题，日志显示六点”的困惑。装完后可以用 timedatectl 复核：

bash复制timedatectl

正常输出里应包含 Time zone: Asia/Shanghai (CST, +0800) 和 System clock synchronized: yes。

3.4 首次启动后的检查清单

安装完成重启，拔掉 U 盘，进入系统后先做一轮基础检查，确认没有遗留问题：

bash复制# 查看系统版本
lsb_release -a

# 查看磁盘和分区挂载
lsblk -f
df -h

# 查看引导方式，efi 目录存在说明是 UEFI 启动
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "Legacy BIOS"

# 查看网络和 IP
ip addr show
ip route

检查点：

• lsb_release -a 显示的版本和安装的镜像一致。
• df -h 里 / 和 /home 的容量符合分区规划。
• ip route 有默认网关，能 ping 通外网地址。
• 没有出现 “Activation of network connection failed” 之类的报错。

如果这一步发现没有网络，先不要继续往下做，因为后续所有软件安装都依赖网络。网络问题的排查放到后面第 6 节单独讲。

注意：安装完成后第一件事是做一次系统更新，而不是急着装各种软件。更新会修复已知安全问题，也能避免后续装包时因为依赖版本冲突报错。

到这里，一台能启动、能联网的 Ubuntu 已经就绪。接下来的工作是把它变成一个真正可用的开发和服务环境。

4. 首次登录后的基础环境配置

刚装好的系统只是“能用”，离“好用”还有一段距离。基础配置的目标是：软件源可用、常用工具齐全、远程登录安全、防火墙规则明确、时间同步正常。这一节的每一步都会说明为什么这么做，以及做错之后会看到什么现象。

4.1 软件源与系统更新

默认软件源在部分网络环境下速度较慢。换源的本质是把 /etc/apt/sources.list（或新版 deb822 格式的 .sources 文件）里的仓库地址替换为响应更快的镜像站。不同发行版的文件位置不同：

修改前一定先备份：

bash复制# 22.04 及更早
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

# 24.04 及更新
sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak

然后用编辑器替换地址。以 24.04 为例，文件内容大致如下，把 URIs 换成你实际使用的镜像地址即可：

yaml复制Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

修改完成后执行更新：

bash复制sudo apt update
sudo apt upgrade -y

关键点解释：

• apt update 只刷新软件包索引，不升级任何软件。它失败通常意味着源地址不可达或 GPG 密钥不匹配。
• apt upgrade 才会实际升级已安装的包。生产环境不要无脑 -y，先看升级列表里有没有内核、数据库、运行时的大版本变更。
• 如果看到 NO_PUBKEY 报错，说明镜像站用了不同的签名密钥，需要导入对应密钥，或者换回官方源。

4.2 常用工具与开发依赖

按用途分批安装，而不是一次性装一大堆用不上的东西：

bash复制# 基础工具
sudo apt install -y build-essential curl wget git vim htop tree net-tools

# Python 开发环境
sudo apt install -y python3 python3-venv python3-pip python3-dev

# 容器相关（按需）
sudo apt install -y docker.io docker-compose-v2

build-essential 包含 gcc、g++、make 等编译工具，很多 Python 包和源码编译安装都依赖它。python3-venv 常被忽略，导致创建虚拟环境时报 ensurepip is not available。

安装完成后验证：

bash复制gcc --version
python3 --version
git --version

建议顺手配置一下 git 身份，避免提交记录里出现默认主机名：

bash复制git config --global user.name "your-name"
git config --global user.email "your-email@example.com"
git config --global init.defaultBranch main

4.3 SSH 服务与密钥登录

服务器版默认安装了 openssh-server，桌面版默认没有。远程登录前先确认服务状态：

bash复制sudo apt install -y openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh --no-pager

状态里出现 active (running) 才算正常。接着在客户端生成密钥并上传公钥：

bash复制# 本地机器执行
ssh-keygen -t ed25519 -C "dev@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.100

上传后测试免密登录。如果仍然提示输入密码，检查服务端 ~/.ssh 目录权限（应为 700）和 authorized_keys 权限（应为 600），权限过宽时 sshd 会拒绝使用密钥。

确认密钥登录可用之后，再关闭密码登录，修改 /etc/ssh/sshd_config：

ini复制PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

修改后先执行配置检查再重启，避免把自己锁在外面：

bash复制sudo sshd -t
sudo systemctl restart ssh

sshd -t 会做语法校验，如果配置有误会直接报错而不重启。这个顺序很重要：先校验，再重启，最后保持当前会话不要断开，另开一个终端验证新连接是否成功。

4.4 防火墙与时间同步

Ubuntu 自带 ufw 作为 iptables 的前端。启用前先放行 SSH，否则远程连接会立刻断开：

bash复制sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

ufw allow 'Nginx Full' 是另一种写法，等价于同时放行 80 和 443，但需要先装好 Nginx 才有这个应用配置。

时间同步方面，现代 Ubuntu 默认使用 systemd-timesyncd，一般不需要额外配置。检查命令：

bash复制timedatectl status
systemctl status systemd-timesyncd --no-pager

如果 System clock synchronized 是 no，先检查 UDP 123 端口是否被网络策略拦截，再考虑换成内网 NTP 服务器。时间不同步会直接影响 HTTPS 证书校验、JWT 过期判断和日志排序，是那种“平时不出事、出事很难查”的配置项。

5. 实战：部署一个可访问的 Web 服务

配置完基础环境，接下来做一个有实际产出的小项目：用 Python 写一个简单的 HTTP 服务，用 systemd 托管进程，用 Nginx 做反向代理，最终通过浏览器访问。这条链路覆盖了 Linux 上部署服务最核心的几个环节：进程管理、端口监听、反向代理、防火墙放行。

5.1 创建应用目录和虚拟环境

先把目录结构定下来。约定俗成的做法是把应用放在 /opt 下，用独立的系统用户运行：

bash复制sudo mkdir -p /opt/demo-app
sudo useradd --system --no-create-home --shell /usr/sbin/nologin demoapp
sudo chown -R demoapp:demoapp /opt/demo-app

创建虚拟环境并安装依赖：

bash复制sudo -u demoapp python3 -m venv /opt/demo-app/venv
sudo -u demoapp /opt/demo-app/venv/bin/pip install --upgrade pip
sudo -u demoapp /opt/demo-app/venv/bin/pip install flask gunicorn

使用独立用户的意义在于：即使应用被攻破，攻击者拿到的也只是 demoapp 的权限，无法直接修改系统文件。用 --system 和 nologin 是为了让这个账号不能交互登录。

检查点：/opt/demo-app/venv/bin/python -c "import flask" 能正常执行，没有报模块找不到。

5.2 编写应用代码

创建一个最小但能验证链路的服务，返回服务名、主机名、时间和请求路径：

python复制# /opt/demo-app/app.py
import datetime
import os
import socket

from flask import Flask, jsonify, request

app = Flask(__name__)


@app.route("/")
def index():
    return jsonify({
        "service": "demo-app",
        "hostname": socket.gethostname(),
        "time": datetime.datetime.now().isoformat(timespec="seconds"),
        "client": request.headers.get("X-Real-IP", request.remote_addr),
    })


@app.route("/healthz")
def healthz():
    return {"status": "ok"}, 200


if __name__ == "__main__":
    port = int(os.environ.get("PORT", 8000))
    app.run(host="127.0.0.1", port=port)

代码里的几个设计点值得说明：

• host="127.0.0.1" 而不是 0.0.0.0。应用只监听本机，外部流量统一从 Nginx 进来，避免绕过代理直接访问应用端口。
• /healthz 是给负载均衡和监控用的健康检查端点，返回固定结构，不依赖外部资源。
• 返回里带 X-Real-IP，可以验证 Nginx 是否正确传递了真实客户端地址。

在本地先跑一次，确认代码没问题：

bash复制sudo -u demoapp /opt/demo-app/venv/bin/python /opt/demo-app/app.py
curl -s http://127.0.0.1:8000/

能看到 JSON 输出，说明应用本身正常，问题就只可能出在进程托管或代理配置上。这种“分层验证”的思路能大幅缩短排查时间。

5.3 用 systemd 托管进程

直接 nohup python app.py & 启动的进程，遇到终端关闭、机器重启就没了。systemd 负责守护进程、开机自启、异常重启和日志收集。创建单元文件：

ini复制# /etc/systemd/system/demo-app.service
[Unit]
Description=Demo Flask Application
After=network.target

[Service]
Type=simple
User=demoapp
Group=demoapp
WorkingDirectory=/opt/demo-app
Environment="PATH=/opt/demo-app/venv/bin"
Environment="PYTHONUNBUFFERED=1"
ExecStart=/opt/demo-app/venv/bin/gunicorn \
    --workers 3 \
    --bind 127.0.0.1:8000 \
    --access-logfile - \
    --error-logfile - \
    app:app
Restart=always
RestartSec=3

# 基础加固
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

参数含义和影响：

加载并启动：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now demo-app
sudo systemctl status demo-app --no-pager

如果状态是 failed，查看日志是第一步：

bash复制journalctl -u demo-app -n 50 --no-pager

最常见的两类报错是 status=203/EXEC（可执行文件不存在或没有执行权限）和 status=200/CHDIR（工作目录不存在）。前者检查 ExecStart 路径，后者检查 WorkingDirectory 拼写。

5.4 配置 Nginx 反向代理

装好 Nginx 后，在 /etc/nginx/sites-available/ 下新建站点配置：

nginx复制server {
    listen 80;
    server_name _;

    access_log /var/log/nginx/demo-app.access.log;
    error_log  /var/log/nginx/demo-app.error.log;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        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;
        proxy_read_timeout 30s;
    }

    location /healthz {
        proxy_pass http://127.0.0.1:8000/healthz;
        access_log off;
    }
}

启用站点并校验配置：

bash复制sudo ln -s /etc/nginx/sites-available/demo-app /etc/nginx/sites-enabled/demo-app
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

nginx -t 会检查语法和配置引用关系，通过后再 reload。直接 restart 也能生效，但 reload 是平滑加载，不中断现有连接，生产环境更推荐。

代理相关的几个配置项容易配错：

• proxy_set_header Host $host 缺失时，后端拿到的 Host 是 127.0.0.1:8000，某些框架生成跳转链接会出错。
• X-Forwarded-For 需要配合应用层信任配置使用，不要不加判断就直接信任这个头做权限判断。
• proxy_read_timeout 默认 60 秒，如果后端有长任务，要么调大，要么改成异步任务加轮询。

5.5 端到端验证

按从内到外的顺序验证，一层一层排除：

bash复制# 1. 应用进程是否在监听
sudo ss -lntp | grep 8000

# 2. 本机直接访问应用
curl -s http://127.0.0.1:8000/healthz

# 3. 本机通过 Nginx 访问
curl -s -H "Host: demo.local" http://127.0.0.1/

# 4. 从另一台机器访问
curl -s http://192.168.1.100/

浏览器访问 http://你的服务器IP/，应该看到类似下面的 JSON：

json复制{
  "client": "192.168.1.50",
  "hostname": "dev-box-01",
  "service": "demo-app",
  "time": "2025-01-15T10:23:41"
}

client 字段如果显示的是 127.0.0.1 而不是真实客户端 IP，说明 Nginx 的 X-Real-IP 没有正确传下去，或者应用读取头的顺序有问题。这是一个很典型的反向代理配置问题，用这个字段就能快速定位。

至此，一条完整的链路跑通了：浏览器 → 防火墙 → Nginx → gunicorn → Flask 应用。后面再出问题，就可以沿着这条链路逐层排查。

6. 常见故障的排查路径

安装和使用 Ubuntu 的过程中，报错信息往往很简短，比如 “Something went wrong”、“Connection refused”，单看这句话很难定位。有效的做法是先建立链路模型，再按层排查。这一节按安装阶段、网络阶段、服务阶段分组，把典型现象和对应的检查手段列出来。

6.1 安装阶段：进不去安装界面或装完无法引导

现象一：U 盘启动后黑屏、花屏、卡在 Logo。

可能原因和检查方式：

现象二：安装完成重启后直接进入原系统，没有 Ubuntu 选项。

先确认引导模式是否和安装时一致。用 Live U 盘启动，执行：

bash复制sudo apt install -y efibootmgr
sudo efibootmgr -v

如果列表里没有 ubuntu 条目，说明引导记录没写进去。进入 Live 环境挂载根分区，重新安装 GRUB：

bash复制# 假设根分区是 /dev/nvme0n1p3，EFI 分区是 /dev/nvme0n1p1
sudo mount /dev/nvme0n1p3 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done
sudo chroot /mnt
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub
exit

这段操作有一定风险，执行前确认分区号和文件系统类型。如果机器上还有 Windows，update-grub 通常能自动探测到并加入启动菜单。

6.2 网络阶段：能连 Wi-Fi 但打不开网页

现象：浏览器提示无法访问，但 ping 8.8.8.8 通，ping www.baidu.com 不通。这说明链路层和 IP 层正常，问题出在 DNS 解析。

排查顺序：

bash复制# 1. 看默认路由是否存在
ip route

# 2. 看 DNS 配置
resolvectl status

# 3. 直接测试 DNS 解析
nslookup example.com
dig example.com +short

# 4. 临时指定 DNS 测试
resolvectl query example.com

如果是 DNS 问题，检查 /etc/resolv.conf 是否被正确管理。Ubuntu 桌面版由 NetworkManager 管理，服务器版由 netplan 或 systemd-resolved 管理。手动修改 /etc/resolv.conf 在重启后可能被覆盖，正确做法是改 netplan 配置：

yaml复制# /etc/netplan/50-cloud-init.yaml
network:
  version: 2
  ethernets:
    ens33:
      dhcp4: true
      nameservers:
        addresses: [223.5.5.5, 119.29.29.29]

修改后执行：

bash复制sudo netplan try
sudo netplan apply

netplan try 会在 120 秒内等待确认，如果配置导致网络断开，超时后自动回滚。这是一个很实用的安全机制，尤其在远程操作时，能避免改错配置后彻底失联。

另一类常见现象是有线网卡没被识别。先用 lspci | grep -i ethernet 确认硬件存在，再用 ip link 看接口是否处于 DOWN 状态。如果是 DOWN，尝试 sudo ip link set ens33 up，然后检查是否获取到 IP。

6.3 服务阶段：Nginx 返回 502 或连接被拒

现象一：浏览器访问显示 502 Bad Gateway。

502 的含义是 Nginx 作为代理连不上后端。排查顺序：

bash复制# 1. 后端进程是否存活
sudo systemctl status demo-app --no-pager

# 2. 端口是否在监听
sudo ss -lntp | grep 8000

# 3. 本机能否直连后端
curl -v http://127.0.0.1:8000/healthz

# 4. 看 Nginx 错误日志
sudo tail -n 50 /var/log/nginx/demo-app.error.log

错误日志里如果出现 connect() failed (111: Connection refused)，说明后端没起来或者端口不对。如果出现 Permission denied，通常是 SELinux/AppArmor 策略或者代理目标写成了外部地址被防火墙拦截。

现象二：浏览器访问超时，没有任何响应。

这类问题优先查防火墙和监听地址：

bash复制sudo ufw status verbose
sudo ss -lntp | grep nginx

如果 Nginx 只监听在 127.0.0.1:80，外部自然访问不到。检查 /etc/nginx/sites-enabled/ 下的 listen 指令，应该是 listen 80; 或 listen 0.0.0.0:80;。

现象三：服务启动几秒后反复重启。

用 journalctl -u demo-app -f 实时看日志。常见原因是端口被占用（Address already in use）或者依赖文件缺失。端口占用可以用下面的命令定位：

bash复制sudo ss -lntp | grep 8000
sudo lsof -i :8000

6.4 一份可复用的排错清单

遇到问题按下面的顺序走，能覆盖大部分场景：

1. 确认输入：命令、路径、IP、端口有没有写错。
2. 确认文件存在：ls -l 看路径和权限。
3. 确认依赖版本：apt list --installed | grep 包名。
4. 确认配置生效：改完配置是否 reload 或重启过。
5. 确认监听状态：ss -lntp 看端口和绑定地址。
6. 确认防火墙：ufw status 和云厂商安全组。
7. 确认日志：journalctl、/var/log/nginx/、应用自身日志。
8. 确认时间：timedatectl，证书和令牌问题常和它有关。

注意：排查时不要一次改多个地方。每次只改一个变量，验证一次，否则问题解决了也不知道是哪个改动生效的。

7. 生产环境差异、安全加固与后续练习方向

学习环境里跑通和能在生产环境稳定运行，中间隔着不少工作。这一节把两者的差异讲清楚，给出一份可执行的加固清单，最后给出几条继续深入的方向。

7.1 学习环境和生产环境的关键差异

一个很现实的区别是：学习环境出问题大不了重装，生产环境重装的代价可能是几小时停机。所以在学习阶段就养成“改配置先备份、操作前先确认设备名、变更后验证”的习惯，比记住多少命令更有价值。

7.2 安全加固清单

下面这些项按优先级排列，前几项属于必做：

• 禁止 root 通过 SSH 登录，使用普通账号加 sudo。
• 关闭 SSH 密码登录，只允许密钥认证。
• 启用 ufw，默认拒绝入站，只放行必要端口。
• 定期执行 apt update && apt upgrade，安全更新不要拖。
• 应用使用专用低权限账号运行，不要用 root 启动服务。
• 数据库、缓存等内部服务不要监听 0.0.0.0，只监听 127.0.0.1。
• 对外提供 HTTPS，证书到期时间纳入监控。
• 开启 unattended-upgrades 自动安装安全补丁：

bash复制sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

验证自动更新配置是否生效：

bash复制systemctl status unattended-upgrades --no-pager
cat /etc/apt/apt.conf.d/20auto-upgrades

输出里应包含 APT::Periodic::Update-Package-Lists "1"; 和 APT::Periodic::Unattended-Upgrade "1";。

7.3 备份、快照与回滚

在虚拟机或云主机上，最省事的备份方式是快照。做任何有风险的操作前（升级内核、改网络配置、迁移数据库），先打一个快照。快照恢复通常几分钟内完成，比现场排查快得多。

物理机或没有快照能力的环境，至少要备份这几样：

用 rsync 做增量备份的示例：

bash复制rsync -avz --delete --exclude='.cache' /home/user/ /backup/home/user/

--delete 会让目标目录和源目录保持一致，但也会删除目标端多余的文件。第一次使用建议先加 --dry-run 看输出，确认没有误删再实际执行。

7.4 可以继续深入的练习方向

把上面这套流程走通之后，有几个方向可以继续练：

1. 容器化部署：把 Flask 应用打成 Docker 镜像，用 docker compose 管理应用和 Nginx，体会环境一致性的价值。
2. HTTPS 配置：申请证书，配置 Nginx 的 TLS，理解证书链、SNI 和自动续期。
3. 日志与监控：接入 prometheus 和 node_exporter，观察 CPU、内存、磁盘和请求延迟。
4. 自动化配置：用 Ansible 写一个 playbook，把本文的手动步骤变成可重复执行的脚本。
5. 多用户与权限：练习 chmod、chown、setfacl 和 sudoers 配置，理解最小权限原则的落地方式。

每个方向都建议用一个独立的小项目去练，而不是只看文档。比如容器化这一项，完整目标是：本地改一行代码，重新构建镜像，docker compose up -d 之后新版本生效，旧容器被替换，服务不中断。这个目标达成，才算真的理解了容器化部署。

对刚接触 Ubuntu 的读者，最有价值的练习其实是把本文第 3 节到第 5 节完整做两遍：第一遍照着做，第二遍不看文章自己做，遇到卡住的地方再回来查。第二遍能独立完成，说明环境配置、服务托管、反向代理这条链路已经真正掌握了。之后再遇到 “服务起不来”、“502”、“SSH 连不上” 这类问题，就能按照日志和链路一层层定位，而不是靠猜。