1. 先给结论Ubuntu 上最省事的 Nginx 安装路径在搜索引擎里找“Ubuntu 安装 Nginx”你会看到劝你编译源码的、让你加第三方 PPA 的、还有直接拉 Docker 镜像的。我的态度很明确绝大多数情况下最简便且最稳的方案只有一个——直接用 apt 装系统仓库里的 nginx。不是源码编译不好而是在 Ubuntu 上apt 装出来的版本经过了发行版团队打包和适配配置文件的位置、systemd 服务的启动脚本、日志轮转都已经替你处理好了出错概率最低。这篇内容主要适合两类人一是刚接触 Linux 的运维新手想知道装完 Nginx 之后到底还要做哪些事二是在 Ubuntu 24.04 LTS 环境下快速搭建 Web 服务的开发者需要一套干净、可复现的步骤。我会把从环境检查、安装启动、静态站点、反向代理到多端口多域名配置全部串起来顺带把常见问题排查方法也整理了。1.1 为什么 apt 版本是默认答案Linux 上的软件安装方式很多但对 Nginx 来说apt 装的是 Ubuntu 官方源里的二进制包。它有几个非常实际的好处。第一依赖不用管。Nginx 运行依赖的 libpcre3、zlib1g、openssl 等库apt 会一并处理好。你不需要自己去解决“编译时报找不到 PCRE”这类问题。第二服务集成度很高。apt 安装完成后系统会自动创建 nginx 用户、生成 /etc/nginx 目录、注册 systemd 服务单元甚至连 logrotate 日志轮转都配置好了开机自启只需要 systemctl enable。第三安全更新可以直接跟随系统源。每次 apt update apt upgrade 就能把 Nginx 的补丁一起打上这对生产环境很重要。很多人觉得“自己编译的才是最新的”但其实 Ubuntu LTS 仓库里的 Nginx 版本虽然不算激进却足够稳定。如果你不是非要使用某个月新发布的特性、不是要在 Nginx 里编译第三方 C 模块完全没必要为了版本号去折腾源码。像 Nginx 这种基础组件稳定性比新鲜度值钱得多。1.2 什么情况下才需要放弃 apt 走其他方案先说源码编译。只有当你需要编译自定义模块、或者必须使用某一指定版本且仓库不提供时才值得做。源码编译意味着你要自己处理依赖、自己写 systemd service、自己维护升级光是前期的 configure 参数就够查半天。这在“最简便方法”这个话题下属于备用方案不是首选。另一个常见选择是 Docker。如果你已经有容器化体系跑一个 nginx 容器确实很干净一条 docker run 就能出服务。但容器方案要求你有 Docker 环境、要理解端口映射和卷挂载对于本机快速搭建一个站点来说反而多了一层概念负担。虚拟机里的 Ubuntu 开发环境通常也更适合直接用 systemd 服务而不是非要套一层容器。所以我的判断很直接没有特别需求就别绕路。2. 安装前的环境准备先花两分钟做检查很多人装 Nginx 失败不是安装命令的问题而是系统环境没准备好。我习惯在敲安装命令之前先检查三样东西系统版本、CPU 架构、软件源是否可用。这三项都正常后面的安装就是一条命令的事。2.1 确认 Ubuntu 版本和架构先看系统版本。打开终端执行lsb_release -a如果lsb_release没安装可以看这个文件cat /etc/os-release看到Ubuntu 22.04.3 LTS或Ubuntu 24.04 LTS这样的字样就说明是你的系统信息。Ubuntu 20.04 和 24.04 的 Nginx 配置路径基本一致所以下面这些步骤在两个版本上都能用。接着看架构现代机器基本都是 x86_64 或 arm64uname -m输出x86_64表示是 64 位 Intel/AMD 架构输出aarch64表示是 64 位 ARM 架构。这个信息主要用来判断后面如果下载扩展模块应该选哪个版本的包。对标准安装来说apt 会自动匹配所以这里只是确认环境没有太大意外。2.2 更新索引和基础工具安装之前先刷新软件源。这一步很多人会跳过结果装到的索引是旧的可能解析不到包。执行sudo apt update它会把软件源里的包列表拉到本地。如果是刚装好的 Ubuntu 系统还是建议顺手把基础工具装上后面下载文件、排查网络都方便sudo apt install -y curl wget ca-certificates这几个包体积不大但对后续操作很友好。比如curl可以用来测试本地 Nginx 是否正常响应wget可以在服务器上下载静态资源。ca-certificates 是 CA 证书库后面配置 HTTPS 反向代理时系统不会因为证书链不完整而报错。做完这些检查就可以正式安装了。3. 最简便的安装实操从 apt install 到浏览器看到欢迎页现在进入正题。我可以负责任地说只要环境正常整个安装过程不会超过五分钟。关键是把安装、启动、验证这三步做完整不要装完就跑。3.1 执行安装命令并验证版本在终端执行sudo apt install -y nginx-y参数表示自动确认不需要再手动输入 Y。apt 会把 Nginx 及其依赖包下载并安装安装结束时一般会自动注册 systemd 服务。你可以用下面这行命令确认版本nginx -v输出类似nginx version: nginx/1.24.0 (Ubuntu)就说明安装成功。注意有些教程会让你用/usr/sbin/nginx -v那是因为当前用户的 PATH 里没有 nginx 命令。如果你直接敲nginx -v提示找不到命令就改敲完整路径或者先把/usr/sbin加进 PATH。安装完成后Nginx 通常会启动但为了保险还是要手动确认一下服务状态。3.2 启动服务、设置开机自启和放行防火墙执行下面的命令让 Nginx 立即启动并加入开机自启sudo systemctl enable --now nginxenable负责开机自启--now表示立即启动。接着看服务状态sudo systemctl status nginx --no-pager如果看到active (running)说明 Nginx 已经跑起来了。如果你的 Ubuntu 开了 ufw 防火墙还要放行 HTTP 和 HTTPS 端口否则外部浏览器打不开sudo ufw allow Nginx FullNginx Full是 ufw 里预置的规则同时放行 80 和 443 端口。做完这一步在浏览器地址栏输入服务器的 IP 地址比如http://192.168.1.10就应该能看到 Nginx 的默认欢迎页。看到那个大大的 “Welcome to nginx!” 页面说明安装完全正常。3.3 认识 Nginx 默认目录结构Nginx 装好后目录布局有固定的一套。我建议你装完先花两分钟转一圈后面配置时会省很多时间。ls -l /etc/nginx/重点关注几个文件和目录/etc/nginx/nginx.conf是主配置文件全局配置都写在这里。/etc/nginx/sites-available/存放站点配置相当于“草稿区”。/etc/nginx/sites-enabled/存放启用的站点配置通常是指向 sites-available 的软链接。/var/www/html/是默认站点的网页根目录。/var/log/nginx/里放着 access.log 和 error.log 两个日志文件。这个结构是 Ubuntu/Debian 系特有的。它鼓励我们遵循“一个站点一个配置、放在 sites-available 里、再软链接到 sites-enabled 启用”的方式。不要一上来就全塞进 nginx.conf那样维护起来会非常痛苦。4. 装完之后必做的 4 类配置到这一步Nginx 只是“能跑”。真正让 Nginx 干活还需要做配置。下面这几类配置是我日常用得最多的静态站点、反向代理、多端口多域名、日志检查。我把每个都拆开讲配置模板直接抄就行。4.1 静态站点部署与权限踩坑假设我要在/var/www/mysite放一个静态站点。先创建目录并写入测试页面sudo mkdir -p /var/www/mysite sudo tee /var/www/mysite/index.html /dev/null EOF !DOCTYPE html html headtitlemysite/title/head bodyh1Hello from mysite/h1/body /html EOF接着在 sites-available 里新建配置sudo tee /etc/nginx/sites-available/mysite /dev/null EOF server { listen 80; server_name mysite.local; root /var/www/mysite; index index.html; } EOF然后建立软链接启用站点sudo ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/这里有个容易踩的坑默认的/etc/nginx/sites-enabled/default依然占用着 80 端口。如果你新站点也用 80会遇到监听冲突。稳妥做法是删掉默认站点的软链接sudo rm /etc/nginx/sites-enabled/default然后测试配置并重载sudo nginx -t sudo systemctl reload nginxnginx -t会返回syntax is ok和test is successful。看到这两条再 reload基本不会出问题。关于权限我记得第一次配置时把站点目录放在自己 home 目录下面结果 Nginx 报 403。原因很简单Nginx 的 worker 进程以www-data用户运行而 home 目录默认权限是 750www-data 根本没有权限走进去。解决方案有两个一是把站点目录放在/var/www下二是给 home 目录加执行权限。我建议直接用系统约定俗成的/var/www省得后面为了权限折腾。4.2 反向代理与 location 工作流Nginx 最常见的场景是反向代理。比如我有个 Node 服务跑在127.0.0.1:3000想让外部通过 80 端口访问配置如下server { listen 80; server_name api.example.com; location /api/ { proxy_pass http://127.0.0.1:3000/api/; 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; } }这一段不理解 location 工作机制的人最容易搞错。Nginx 对 location 的选择并不是按配置文件里的书写顺序从上到下匹配这么简单它有自己的一套优先级规则精确匹配location /path优先级最高其次是^~前缀匹配再接下来是正则匹配按书写顺序依次测试最后才是不带符号的前缀匹配。一旦命中一个 location后面的其他 location 不会继续参与决策。这是“nginx 中 location 工作流”最关键的一点。另一个高频坑是proxy_pass后面到底带不带路径。如果 location 是/api/而 proxy_pass 写成http://127.0.0.1:3000不带尾部的/api/则用户的/api/user请求会被完整传给后端即后端收到/api/user。如果 proxy_pass 写的是http://127.0.0.1:3000/那么/api/这段前缀会被剥掉后端收到的是/user。我因为这两者混淆吃过不少亏现在的习惯是后端路由本身就带/api前缀时proxy_pass 就不重复加后端不带前缀时proxy_pass 就要按需保留或去掉路径。改完配置后一定用 curl 测一下实际转发的路径是否和预期一致。4.3 多站点、多端口与自定义域名开发环境配置开发环境里经常需要一台虚拟机同时跑多个站点。比如我本地的 Ubuntu 虚拟机 IP 是192.168.1.10想在该虚拟机上同时托管 site1 和 site2。常见做法有两种同一端口用不同server_name或者不同端口各开一个 server。先说同一端口加域名区分。修改宿主机的 hosts 文件把自定义域名指向虚拟机 IP。Windows 在C:\Windows\System32\drivers\etc\hostsLinux/macOS 在/etc/hosts写入192.168.1.10 site1.local 192.168.1.10 site2.local然后在虚拟机 Nginx 里为两个站点分别建配置。第一个站点server { listen 80; server_name site1.local; root /var/www/site1; }第二个站点server { listen 80; server_name site2.local; root /var/www/site2; }浏览器里打开http://site1.localNginx 会根据 HTTP 请求里的 Host 字段自动选择对应 server 块。这里有个前提网站根目录都要建好并且文件能让 www-data 用户读取。另一种场景是不同的服务监听不同端口比如 site1 走 8081site2 走 8082。配置就改成server { listen 8081; server_name site1.local; root /var/www/site1; }这种方式适合后端开发时多个框架服务各自占用端口的情况。配合反向代理可以做到外部访问http://site1.local时Nginx 反代到本机的 8081访问http://site2.local时反代到 8082。结构清晰互不干扰。我在本地开发多端口环境时就是这么玩的等上线时再把 hosts 改成真实的 DNS 解析配置文件完全不用动。4.4 日志与状态检查要养成习惯Nginx 的问题排查很大程度上依赖日志。默认情况下访问日志在/var/log/nginx/access.log错误日志在/var/log/nginx/error.log。排查问题时实时看日志很有用sudo tail -f /var/log/nginx/error.logerror.log 里出现 403、404、connect() failed 等信息时基本能定位是权限问题、路径问题还是后端服务没启动。access.log 主要看请求的状态码和来源例如出现大量 499 说明客户端提前断开此时要检查后端处理速度。状态检查除了systemctl status nginx还可以用curl看响应头curl -I http://127.0.0.1返回 HTTP/1.1 200 OK 说明 Nginx 正常。如果你想看当前生效的完整配置用sudo nginx -T这个命令会把 include 进来的所有配置文件合并输出。当你怀疑“改的文件到底有没有生效”时它是排查利器。5. 常见问题与排查技巧实录我把实际使用中遇到的典型问题整理成速查表每一条都是真实踩过坑后的经验。5.1 80 端口被占用导致启动失败如果安装后服务启动失败systemctl status nginx显示bind() to 0.0.0.0:80 failed说明有其他程序占了 80 端口。最常见的是 Apache也可能是其他 Web 服务。先找到占用进程sudo lsof -i :80看到进程名和 PID 后如果是 Apache 且你不需要它直接停掉并禁用开机自启sudo systemctl stop apache2 sudo systemctl disable apache2然后再启动 Nginx。如果你其他服务必须用 80那么可以把 Nginx 的默认站点监听改到其他端口但这属于应急方案不推荐长期使用。5.2 静态文件总是 403 Forbidden403 通常是权限问题。Nginx 进程以www-data用户运行它需要对你配置的 root 目录有读和执行权限。排查步骤很简单sudo ls -ld /var/www/mysite如果目录所有者是 root 且权限是 755一般没问题。如果站点文件放在了/home/ubuntu/project这种地方home 目录可能是 750www-data 无法进入。我建议把项目文件复制到/var/www或者给上层目录加ox执行权限。千万不要图省事把整个根目录都chmod 777那会引入安全风险。5.3 改了配置但访问页面没变化这种情况通常不是 Nginx 的锅。改完配置文件后要先nginx -t确认语法没问题再systemctl reload nginx平滑重载。reload 不会中断已有连接正在处理的长连接会继续完成但新请求会使用新配置。我见过有人改完配置直接systemctl restart nginx这本身没错但对生产环境来说不是最佳做法。另一个容易忽略的是浏览器缓存。静态页面改完后浏览器还保留旧内容强制刷新CtrlShiftR或开无痕窗口就能看到新效果。先排除浏览器缓存再去怀疑 Nginx 配置没生效。5.4 并发连接数不够用Nginx 报 “worker_connections are not enough” 或者系统出现 too many open files 时需要优化连接数。修改/etc/nginx/nginx.confworker_processes auto; events { worker_connections 10240; }worker_processes auto让 Nginx 按 CPU 核数生成 worker 进程。worker_connections表示每个 worker 进程能同时打开的最大连接数这个值不是越大越好还要受系统文件描述符限制。查看当前限制ulimit -n如果默认是 1024那么就算 worker_connections 配成 20000 也没用。对 systemd 管理的 Nginx在/etc/systemd/system/nginx.service.d/override.conf里加[Service] LimitNOFILE65535然后sudo systemctl daemon-reload sudo systemctl restart nginx。别忘了调高系统级文件描述符限制否则重启后仍然会撞墙。这个组合拳是应对“最大并发连接数经常超”问题最直接的方法。6. 最后说点我自己的维护习惯关于 Ubuntu 上装 Nginx我最想强调的是“稳定、可重复、少折腾”。所以安装阶段用 apt业务配置阶段遵循 sites-available 与 sites-enabled 的分离结构排查阶段先看日志再动手改配置。我自己有个小习惯就是给 shell 加一个常用别名alias ng.reloadsudo nginx -t sudo systemctl reload nginx每次改完配置只敲三个字母先检查语法通过后立刻平滑重载。这套流程用了很久基本没因为改动配置把服务弄挂过。另外还有一个小建议第一次配置好后立刻做一次/etc/nginx目录的备份。复制出来的文件不一定要用但哪天你手误把整个目录删了有一个备份就能迅速恢复现场sudo cp -a /etc/nginx /etc/nginx.bak以后每次调优前也照这个思路来改文件前先备份改完测试通过再 reload。Nginx 本身是个很皮实的软件绝大多数故障都是配置细节和权限引起的。把这些基础习惯养好你在 Ubuntu 上用它自然就顺手了。