Ubuntu 24.04部署MySQL/Redis/Nginx与自动备份全记录-育师

最近给一台全新的 Ubuntu 24.04 LTS 做了一次完整的环境部署，从裸系统一路装到 MySQL、Redis、Nginx 三件套全部跑通业务服务，再把自动备份补上。这套流程我前前后后走过很多遍，每次都能踩出一两个新坑，这次索性把所有操作和踩坑记录整理出来。如果你正准备在 Ubuntu 上装数据库、缓存和 Web 服务，或者想要一套能真正落到自动备份的部署方案，这篇文章可以直接当操作手册参考。

我会按真实部署的顺序走：环境准备、MySQL、Redis、Nginx、备份、排错，每一步尽量说清楚为什么这么做，而不只是贴命令。中间会穿插一些我在生产环境里常用的参数和容易出错的地方。跟那些一句句抄官方文档的教程不一样，这篇更接近我自己的实操笔记，适合有一定 Linux 基础、想少走弯路的读者。

1. 部署前必做的三步：系统更新、SSH 保障、目录规划

很多教程上来就让你apt install mysql-server，装完再说。但实际上，部署前有几步准备工作，能帮你省掉后面一大半麻烦。

1.1 选对 Ubuntu 版本

这里说的就是长期支持版本。我这次用的是 Ubuntu 24.04 LTS，目前 apt 源里带的 MySQL 是 8.0 系列、Redis 是 7.x、Nginx 是 1.24 左右，都是比较顺手且稳定的版本。如果你还在用 20.04 或更老的版本，建议别折腾升级路线了，趁着重装直接上 24.04。

我的建议只有一条：生产环境无脑选当前最新的 LTS，普通项目里用开发版意义不大。另外，安装时我选了最小安装（Minimal），不带图形界面、不带 LibreOffice 这些吃资源的组件，后面所有东西都是命令行操作。

1.2 换源、更新、安装基础工具

国内服务器普遍会做一步换源操作，这里就不展开具体源地址了，网上搜"Ubuntu 换源"能找到一堆，原理是把/etc/apt/sources.list.d/ubuntu.sources里的下载地址改成离自己近的镜像站。换完源以后执行：

sudo apt update && sudo apt upgrade -y

这一步必须做。我见过太多人新系统没更新直接装 MySQL，结果装出来版本老，或者依赖缺胳膊少腿，后面排查起来极其痛苦。

顺手把常用工具装了：

sudo apt install -y curl wget git vim net-tools lsof unzip

这几个工具在排查问题时基本都会用到。尤其是lsof和net-tools，后面查端口、查连接状态都靠它们。

1.3 目录规划：一切备份的基础

强烈建议从第一天就规划好目录，而不是让文件散落在各处。我习惯用这套结构：

/opt/backup ├── mysql ├── redis └── nginx

备份脚本里的路径全部引用这几个目录，后续配合 cron 做定时任务也清晰。顺便说一句，很多人重装系统后数据全没了，根源不是没装备份工具，而是从第一天就没想过数据是落在哪个目录里。把备份目录当成应用的一部分来规划，比任何备份工具都有效。

网络热词里有“ubuntu系统重装”，我多提一句：如果你经历过一次系统重装，就知道上面这几句话有多重要了。

2. MySQL 8.0：从 apt 安装到 root 认证方式调整

MySQL 这一块坑比较多，尤其是 Ubuntu 上默认的 root 认证方式跟很多人的习惯完全不同。我会从安装开始，把整个过程拆开讲。

2.1 安装与首次登录的 auth_socket 机制

Ubuntu 24.04 上装 MySQL 特别简单：

sudo apt install -y mysql-server

装完以后系统会自动把 MySQL 8.0 启动起来，并且注册为 systemd 服务。然后问题来了：你执行mysql -u root -p想登录，发现密码怎么都是错的。这是因为 Ubuntu 仓库里 MySQL 的 root 默认走的是auth_socket插件，不使用密码认证，而是校验当前 Linux 系统用户。

所以正确的首次登录方式是：

sudo mysql

直接以 root 权限登录，不需要密码。进去以后第一件事就是查一下当前认证方式：

SELECT user, host, plugin FROM mysql.user WHERE user='root';

看到 root 的 plugin 是auth_socket，就理解了为什么密码登录进不去。

如果你想改成常规的密码登录——大多数场景都建议改掉，因为后面的自动化脚本、备份脚本都不太好处理 socket 认证——需要执行：

ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '一个足够强的密码'; FLUSH PRIVILEGES;

之后再用mysql -u root -p就能进去了。

2.2 安全加固与业务账号创建的标准流程

MySQL 安装完默认是"能用就行"的状态，端口暴露、空密码、测试库都还在。我建议跑一遍官方自带的安全脚本：

sudo mysql_secure_installation

按提示设置密码安全等级、删除匿名用户、禁用 root 远程登录、删除 test 库。这些选项全部选 yes 就行。

然后是创建业务账号。这里有个原则：业务代码里用的账号，权限最小化，不要用 root。我一般这么做：

CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'AppUser@2024'; CREATE DATABASE IF NOT EXISTS appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost'; FLUSH PRIVILEGES;

注意几个细节：

字符集显式指定utf8mb4，MySQL 8.0 默认就是这个，但建库时写清楚不会出错。
账号 host 用localhost表示只允许本机连接。如果应用也在这台机器上，localhost 就够了，不需要开网络端口。
如果你非要让 MySQL 监听在 0.0.0.0 上让别的机器连，记得去改/etc/mysql/mysql.conf.d/mysqld.cnf里的bind-address，同时确认防火墙放行 3306 端口。但我的态度是：能不开远程就不开，实在要开会加上防火墙白名单。

2.3 内存与连接数的第一轮调优

MySQL 装完以后，配置文件在/etc/mysql/mysql.conf.d/mysqld.cnf。这一步不是说让你盲目追参数，而是根据自己的机器配置给一个合理的起点。

我常用的一套基础调优：

[mysqld] innodb_buffer_pool_size = 2G max_connections = 300 log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 7 max_binlog_size = 100M character_set_server = utf8mb4 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2

innodb_buffer_pool_size是 InnoDB 的缓存池，经验值是物理内存的 50%~70%。机器内存 8G 的话，设置为 4G~5G。设置太大导致系统 SWAP 频繁反而得不偿失。
max_connections不要一味加大，300~500 对绝大多数中小项目足够。如果应用经常报连接数超限，优先排查代码里的连接池配置，而不是调大 MySQL 数字。
慢查询日志我在开发环境就会打开，long_query_time设置为 2 秒，方便尽早发现索引失效的 SQL。

改完配置记得重启：

sudo systemctl restart mysql

2.4 MySQL 排错的日志入口

MySQL 的日志目录是/var/log/mysql/，错误日志默认在/var/log/mysql/error.log。服务起不来、密码校验失败这类问题，先看这里的报错：

sudo tail -100 /var/log/mysql/error.log

很多人在这一项上踩坑：改完配置重启 MySQL 失败，结果不去看日志，反复试配置文件里的参数，错过了错误日志里明明白白写着的错误原因。这一步是我在排错链路里最先走的一步。

3. Redis 7.x：缓存服务落地配置与分布式锁常识

Redis 安装也简单，但真正要让它安全稳定地跑在生产环境，有几个配置不是默认值就能用的，必须自己调。这一节我按"安装-配置-进阶认知"的顺序来。

3.1 apt 装 Redis 和源码编译到底选哪个

Ubuntu 24.04 上直接apt install redis-server装出来就是 Redis 7.x，质量没问题，也自动带了 systemd 服务单元。这个方式对绝大多数场景足够，我不太建议一上来就源码编译。

源码编译适合什么情况呢？你需要特定版本特性，或者你要魔改 Redis 源码的时候。日常使用，apt 版本的构建参数和你自己编译的差别不大，省时省力。别忘了手动启动服务：

sudo systemctl enable --now redis-server

3.2 必须动的那几行 redis.conf

Redis 的配置文件在/etc/redis/redis.conf。强烈建议打开文件，逐项确认下面这些：

bind 127.0.0.1 protected-mode yes port 6379 requirepass 你的强密码 maxmemory 512mb maxmemory-policy allkeys-lru appendonly yes appendfsync everysec

bind 和 protected-mode：如果 Redis 只给本机应用用，bind 127.0.0.1就够了，别暴露到公网。这是云上服务器被挖矿木马盯上的重灾区。
requirepass：生产环境必须设置。设置后客户端连接都要带密码，redis-cli -a '密码' ping可以快速验证。
maxmemory + maxmemory-policy：这是缓存最重要的两个参数。maxmemory限制 Redis 最多用多少内存，maxmemory-policy决定内存满了以后怎么淘汰。allkeys-lru是全局 LRU 淘汰，适合大多数缓存场景；如果是做"只淘汰设置了过期时间的 key"这种业务，可以用volatile-lru。
appendonly yes：开启 AOF 持久化，配合appendfsync everysec每秒刷盘一次，这是性能和持久化之间的平衡点。只做缓存、丢了也无所谓的场景，可以只保留默认的 RDB 快照。

改完重启：

sudo systemctl restart redis-server

3.3 分布式锁最小实现与单点局限

很多项目用 Redis 做分布式锁。热词里也有“redis 分布式锁”，我展开讲一下最小实现。

获取锁的正确姿势是 SET 命令加上 NX 和 PX：

SET lock:order:10001 uuid-xxxx NX PX 30000

NX：只在 key 不存在时才设置成功。
PX 30000：锁的自动过期时间 30 秒，防止持有锁的进程挂掉导致死锁。
value 用唯一标识（比如 UUID），释放锁时比对，防止误删别人的锁。

释放锁的推荐写法是用 Lua 脚本保证原子性：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

必须明确一点：这种单实例分布式锁存在主从切换时锁丢失的问题，极端情况下会破坏互斥性。严格来说可以用 Redisson 的实现，或者权衡后换成 etcd 这类强一致组件。但对大多数内部系统，上面的最小实现已经能挡住 99% 的并发问题了。你要清楚它的边界，别把它当万能方案。

3.4 缓存治理与内存淘汰策略的经验参数

热词里有"redis缓存治理"，我说两个最常见场景的经验参数。

一个是缓存穿透。查询一个不存在的 key，每次都会打到数据库。最简单的方案是在代码里把空值也缓存起来，TTL 短一些（比如 60 秒）。另一个是被频繁暴力访问的 key，可以考虑用布隆过滤器提前拦截不存在的数据，但这个工程量就大了，做之前先评估值不值。

另一个是缓存雪崩。大量 key 在同一时间过期，请求集体落到数据库。解决办法挺无脑：过期时间加一个随机偏移量，比如TTL = 基准时间 + random(0, 300)秒，把过期时间打散。

Redis 这个环节我强烈建议你两个都做：一是把慢日志调低阈值，二是开启监控。Redis 自带SLOWLOG GET可以看慢命令，INFO命令可以看内存、客户端连接数，别等告警响了你还没头绪。

4. Nginx：多站点、反向代理与 location 匹配优先级

Nginx 是这套环境里配置最灵活、也最容易让人懵的部分。我会从配置文件结构讲起，再到实际站点怎么配，最后把 location 匹配规则彻底说清楚。

4.1 配置文件结构梳理：sites-available 与 sites-enabled

Nginx 安装：

sudo apt install -y nginx

Ubuntu 的 Nginx 配置结构和 CentOS 不太一样，它用 sites-available 存站点配置、sites-enabled 存启用配置，本质是软链接。我从来不动/etc/nginx/nginx.conf里的主配置，只在 sites-available 下新建文件，然后ln -s到 sites-enabled。

创建一个站点：

sudo vim /etc/nginx/sites-available/mysite sudo ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx

每次改完配置，nginx -t检查语法是肌肉记忆。这个命令会告诉你是少了分号还是路径写错了，省掉很多无谓的 restart。

4.2 开发机多端口多站点的配置方式

热词里有“本地+虚拟机多端口nginx 开发环境多站点自定义域名配置”，这个场景很常见。你在一台 Ubuntu 上要同时跑好几个项目，又不想给每个项目配一个域名，就可以让不同项目监听不同端口。

server { listen 8081; server_name project1.local; root /var/www/project1; index index.html; } server { listen 8082; server_name project2.local; root /var/www/project2; index index.html; }

然后配合/etc/hosts做自定义域名解析：

127.0.0.1 project1.local 127.0.0.1 project2.local

这样浏览器里访问http://project1.local:8081就能命中第一个项目。端口和域名分开理解就行：端口决定请求进哪个 server 块，server_name决定匹配哪个域名。开发环境用这种方式，比在 nginx.conf 里堆一堆 if 判断干净太多了。

4.3 反向代理环境的搭建：Host 头与超时参数

Nginx 做反向代理，是后端接口服务和外部访问之间的"接线员"。最基本的代理配置长这样：

server { listen 80; server_name api.example.com; location /api/ { proxy_pass http://127.0.0.1:8080; 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 Host $host。如果不设置这一行，后端的 Web 应用拿到的 Host 头可能变成127.0.0.1:8080，很多框架在做 URL 跳转、CSRF 校验时会直接出错。

另外一个隐蔽的坑是超时。默认情况下 Nginx 的proxy_read_timeout是 60 秒，如果你的后端接口有长任务（比如导出报表），客户端会看到 504。根据业务情况调大一点：

proxy_connect_timeout 10s; proxy_read_timeout 120s; proxy_send_timeout 120s;

4.4 location 匹配优先级的实际验证

location 是 Nginx 最常出问题的地方，我干脆把匹配规则在这里说透。

Nginx 的 location 匹配优先级从高到低大致是这样：

类型	写法	优先级
精确匹配	`location = /image`	最高
前缀匹配（带 ^~）	`location ^~ /static/`	其次
正则匹配	`location ~ \.php$`	再次
普通前缀匹配	`location /static/`	最低

规则理解起来很简单：

先看有没有精确匹配，有就直接用。
再看有没有带^~的前缀匹配，有且匹配到就停下来。
然后按顺序扫描正则，第一个匹配到的正则生效。
如果正则都没有匹配到，才使用最长普通前缀匹配。

举一个实际例子。你配了这两个：

location /api/ { proxy_pass http://backend1; } location ~* ^/api/v2/ { proxy_pass http://backend2; }

请求/api/v2/users时，普通前缀/api/能匹配，但因为是正则先命中^/api/v2/，实际会转发到 backend2。如果你没预期到这个行为，就会看到后端地址"莫名其妙"跟配置对不上。想验证 location 规则对不对，可以在error.log里开启 debug 级别查看匹配过程，也可以直接访问后再对照后端日志。

4.5 给代理服务注入 API Key 与 HTTPS 证书错误

热词里有“nginx 代理 ollama 设置apikey”，这个场景大概是有一台本地的 AI 推理服务，希望统一通过 Nginx 入口访问，并在代理层注入鉴权信息。

最简单的实现是：

location /v1/ { proxy_pass http://127.0.0.1:11434; proxy_set_header Authorization "Bearer sk-换成你自己的key"; }

这样客户端跟 Nginx 通信时不用关心下游服务需要什么鉴权，Nginx 统一把 Authorization 头塞进去。但是要提醒一句：把 key 写死在 nginx 配置文件里不够安全，尤其是配置目录被开发机同步到代码仓库时，key 就等于直接泄露了。更稳妥的做法是作为环境变量注入，或者用 Lua 模块从外部读取。

另外，热词里还有一个很典型的 HTTPS 报错：net::ERR_CERT_COMMON_NAME_INVALID。这通常是证书里的域名和实际访问域名不一致导致的。排查思路就三步：

确认server_name写的是不是访问时的域名。
确认证书的 CN 或 SAN 包含这个域名。
如果用了自签名证书，浏览器会继续报警告，那就要在客户端手动信任 CA，或者换正规 CA 签发的证书。

5. 自动备份：脚本、定时任务与恢复演练

自动备份是全套部署流程里最容易被忽略、出事时最要命的一环。我的原则是：宁可服务少装一个，备份也必须先跑通。

5.1 备份清单与备份脚本的整体结构

我需要备份的东西有哪些？MySQL 全量数据、Redis 的持久化文件、Nginx 配置和站点文件。第一版备份脚本我放在/usr/local/bin/backup_all.sh，结构大致这样：

#!/bin/bash set -e BACKUP_BASE="/opt/backup" DATE=$(date +%F_%H%M%S) LOG="/var/log/backup.log" # MySQL 备份 mkdir -p "$BACKUP_BASE/mysql" mysqldump --single-transaction --quick --routines --triggers \ -u root -p'密码' appdb | gzip > "$BACKUP_BASE/mysql/appdb_$DATE.sql.gz" # Redis 备份 mkdir -p "$BACKUP_BASE/redis" redis-cli -a '密码' BGSAVE sleep 2 cp /var/lib/redis/dump.rdb "$BACKUP_BASE/redis/dump_$DATE.rdb" # Nginx 配置备份 mkdir -p "$BACKUP_BASE/nginx" tar czf "$BACKUP_BASE/nginx/nginx_conf_$DATE.tar.gz" /etc/nginx

几点说明：

mysqldump的--single-transaction参数很关键，它利用 InnoDB 的一致性快照在备份时不锁表，可以在生产环境在线备份。注意前提是你所有表都是 InnoDB，如果混用了 MyISAM，这部分还是要锁表的。
Redis 备份前先执行BGSAVE，能让 RDB 文件落到 disk 上再复制，比直接复制当前内存状态更干净。
脚本里set -e表示任一环节出错就停止，避免" MySQL 备份失败了，后面的 Redis 还继续执行"这种半吊子状态。

首次运行前先chmod +x并手动执行一次，确认没有报错再挂 cron。

5.2 mysqldump 与 Redis RDB 的备份细节

MySQL 备份时有两个额外建议：

第一个是备份账号别用 root。可以新建一个只读账号：

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'BackupP@ss'; GRANT SELECT, SHOW VIEW, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup'@'localhost';

其中PROCESS权限是 mysqldump 执行一致性快照时需要的，REPLICATION CLIENT用于查看 binlog 位置信息。缺了会报权限错误。

第二个是如果数据库体量超过 5GB，mysqldump逻辑备份的速度和恢复速度都会很慢，这时候建议上物理备份方案，比如 Percona XtraBackup 或直接对数据目录做 LVM 快照。逻辑备份适合中小库，物理备份适合大库，这个分界线你要心里有数。

Redis 的小细节是：备份dump.rdb前要确认 Redis 的持久化目录实际在哪。默认是/var/lib/redis/dump.rdb，但如果你改过dir配置，以实际路径为准。

5.3 cron 定时任务与保留策略

定时任务没什么花哨的，直接写进 root 的 crontab：

sudo crontab -e

加一行：

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

表示每天凌晨三点执行一次。选凌晨是因为这个时间业务访问量最低，MySQL 备份和 Redis BGSAVE 对性能的影响最小。如果你的业务 24 小时都有流量，也可以选凌晨 4 点，自己权衡。

保留策略也很重要：只留最近 30 天的备份。在脚本末尾加一句：

find "$BACKUP_BASE/mysql" -name "*.sql.gz" -mtime +30 -delete find "$BACKUP_BASE/redis" -name "*.rdb" -mtime +30 -delete find "$BACKUP_BASE/nginx" -name "*.tar.gz" -mtime +30 -delete

这一步是防止备份文件无限积累把磁盘塞满。备份本身占空间，不清理的话总有一天会反过来把系统搞崩。

5.4 恢复演练：备份没验证过等于没有备份

这一节是全文我最想强调的内容。很多人的备份流程是"脚本能跑、文件能生成"，但等到真出事要恢复时，发现 SQL 文件是坏的，或者导入时报编码错误。所以一定要做恢复演练。

我自己的习惯是每周选一台开发机，把最新备份还原一次：

gunzip < /opt/backup/mysql/appdb_最新.sql.gz | mysql -u root -p'密码' -D test_restore

Redis 的恢复更简单：停掉 Redis，把备份的 dump.rdb 复制到数据目录，启动服务，然后redis-cli DBSIZE看数据量对不对。

恢复演练这块钱省不了。你至少得知道"从备份到恢复"这条链路是通的，否则备份只是给你一个心理安慰。

另外，如果条件允许，可以把备份增量同步到另一台机器或外部存储上，防止整台服务器物理损坏后所有数据一起消失。rsync就能干这个事，这里不展开，但方向是对的。

6. 部署过程中的高频报错与排查链路

最后给你梳理一下我从这套部署流程里实际遇到过的、以及在各种社区里高频出现的报错。排查思路比直接给答案重要。

6.1 服务起不来：journalctl 是第一步

拿到"服务起不来"这个话题，我第一反应永远是看日志。注意 systemd 管理下的 MySQL、Redis、Nginx 都统一用 journal 收集日志：

sudo journalctl -u mysql --since "10 minutes ago" sudo journalctl -u redis-server --since "10 minutes ago" sudo journalctl -u nginx --since "10 minutes ago"

常见故障举例：

MySQL 启动失败，日志提示Can't open file，大概率是数据目录权限被改坏了，执行chown -R mysql:mysql /var/lib/mysql。
Redis 启动失败，日志提示Can't open the log file，说明日志目录不存在，mkdir -p /var/log/redis并改所属用户。
Nginx 启动失败，nginx -t会直接告诉你哪个文件第几行有问题，照着改就行。

6.2 端口冲突与防火墙的排查顺序

端口被占用这种问题，别去猜，直接用命令查：

sudo lsof -i :6379 sudo netstat -tlnp | grep 3306

常见的场景是：你自己手动装了一个 MySQL，之后用 apt 又装了一个，结果两个进程抢同一个端口。查出来以后，要么停掉多余的服务，要么改其中一个端口。

防火墙这块，Ubuntu 默认用的 ufw。先看状态：

sudo ufw status

如果 ufw 是开启的，记得放行你需要的端口：

sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow from 你的内网网段 to any port 3306

云服务器的话，还要额外去安全组放行端口。本地虚拟机环境就没有这一步，很多人忘了"外部安全组"这个概念，导致本机一切正常、外部访问死活不通。

6.3 误改环境变量后如何紧急恢复

热词里有"ubuntu环境变量配置错误"，这个我在自己机器上也发生过。改错了~/.bashrc里的PATH，结果所有命令都提示command not found。

紧急自救的方法是：不要慌，直接用绝对路径执行命令。

/bin/echo $PATH /usr/bin/export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

恢复以后再去修~/.bashrc，把写错的那行改回来。别在 PATH 配置里留空格，也别写不存在的目录。如果是改坏了/etc/environment，同理用sudo /usr/bin/vim /etc/environment去修。

6.4 我踩过的几个隐蔽坑

最后说几个不容易搜到答案的坑，都是这次部署时的血泪经验。

第一个是 MySQL 的caching_sha2_password认证方式。MySQL 8.0 默认是这个认证插件，但老版本的客户端驱动可能不支持。现象是应用连 MySQL 报Authentication plugin 'caching_sha2_password' cannot be loaded。解决办法有两个：升级客户端驱动，或者把账号认证方式改成mysql_native_password。我建议优先升级驱动，因为mysql_native_password在 MySQL 8.4 里已经标记为废弃了。

第二个是 Redis 的tcp-backlog。高并发环境下如果客户端连接大量失败，日志里可能会看到Tcp backlog threshold相关提示，需要同时调整 Redis 的tcp-backlog参数（默认 511）和系统内核的somaxconn参数。先把系统参数调大，再改配置：

sudo sysctl -w net.core.somaxconn=1024

不过这是压测到一定量级才会遇到的事，小项目不用管。

第三个是 Nginx 的proxy_pass结尾斜杠问题。proxy_pass http://127.0.0.1:8080和proxy_pass http://127.0.0.1:8080/差别很大：带斜杠时，location 匹配到的前缀会被替换掉，不带斜杠时会把完整原始 URI 透传过去。举个例子，location /api/匹配/api/user，不带斜杠会转发/api/user，带斜杠则会在转发时把/api前缀去掉，只转发/user。这个行为如果不测试，上线后简直是灾难。每次配完代理，建议用一个真实请求跑一遍，确认 URI 是符合预期的。

整套流程走完，MySQL 在跑、Redis 在跑、Nginx 在跑，备份也在每天凌晨稳定执行。从零到一部署这套环境，真正花时间的不是那几条安装命令，而是理解每个服务为什么这么配、出了问题去哪查。希望这篇记录能帮你在 Ubuntu 部署路上少踩几个我踩过的坑。

Ubuntu 24.04部署MySQL/Redis/Nginx与自动备份全记录