1. 安装前的环境准备与思路拆解先把话说在前面这篇博文写的是“有网”环境下的安装部署流程也就是说你的 Ubuntu 服务器或虚拟机可以正常访问软件源不需要离线包、不需要手动搬运各种依赖。这个前提很重要因为在线安装和离线安装完全是两套思路在线走的是一键拉取依赖的省心路线离线才需要你手动解决依赖地狱。我下面的操作在 Ubuntu 22.04 LTS 上完整跑过20.04、24.04 这些主流版本也都适用。如果你用的是 Ubuntu Server 版本操作逻辑一模一样。老规矩先交代清楚“为什么”再上命令这样你后面遇到问题才知道往哪个方向查。1.1 为什么优先选择 apt 源安装而不是源码编译很多刚接触 Linux 的朋友一搜 Nginx 安装教程看到的第一条往往就是“源码编译安装”先去官网下载 tar.gz 压缩包然后 ./configure、make、make install 三连击。我不否认编译安装能让你自定义模块但如果你不是有特殊需求比如要集成某个第三方模块、要定制编译参数在 Ubuntu 上用 apt 安装才是效率最高的方案。这个选择背后的逻辑很简单apt 安装会由软件包管理器自动处理依赖关系你只需要敲一行命令剩下的依赖下载、安装、目录规划全部自动完成。而且 apt 源的 Nginx 版本会跟随 Ubuntu 官方仓库的维护节奏更新一旦有安全补丁一条 apt upgrade 就能升上去。源码编译安装后期升级要自己重新下载源码重新编译配置文件和二进制文件散落各处卸载也不干净维护成本高不少。用生活化的话说apt 安装就像你在应用商店里装软件点一下安装按钮商店帮你处理所有依赖和兼容性问题。源码编译像是去官网下载安装包手动装虽然自由度大但每一步都可能踩坑。1.2 安装前先检查系统和网络状态在敲安装命令之前我建议你先花两分钟确认三件事系统版本、CPU架构、网络连通性。别觉得多余我见过太多人在这上面栽跟头——系统版本太老导致软件源不可用或者网络不通导致 apt update 卡半天。# 查看系统版本 lsb_release -a # 查看 CPU 架构 uname -m # 检查网络连通性如果能返回IP地址说明DNS解析正常 ping -c 4 baidu.com # 或者直接用 apt 的源更新测试网络推荐这条命令后面本来就要执行 sudo apt update关于 lsb_release -a 的输出重点看 Description 这一行比如 Ubuntu 22.04.4 LTS。uname -m 如果输出 x86_64 代表 64 位 x86 架构aarch64 代表 ARM 架构这两种架构在 Ubuntu 下都直接支持 apt 安装 Nginx无需额外处理。一个小经验如果 ping 域名能通但 ping IP 不通多半是 DNS 配置问题如果 ping 域名和 IP 都不通那就是网络物理链路的问题。ubuntu 环境变量配置错误导致 apt 命令都执行不了的情况我也遇到过但那是另一个话题本篇不展开。1.3 保持 sudo 权限干净不要用 root 裸奔Ubuntu 默认情况下 root 用户是被禁用的日常操作通过 sudo 提权完成。虽然你可以用 sudo su 切换到 root 再执行命令但我个人不建议这样做——因为很多配置错误在 root 下会被掩盖而且万一你的操作有误root 下没有“权限不足”这层保护伞风险更大。整篇博文里的安装和配置命令我都以 sudo 开头这样最稳妥。如果你发现执行 sudo apt update 时报错“ubuntuhostname is not in the sudoers file”说明当前用户没有 sudo 权限需要先在系统安装阶段把用户加入 sudo 组或者用有权限的管理员账户操作。注意这里说的“不要用 root 裸奔”是指不要在终端里全程切到 root 用户去操作而不是说某些命令不能用 sudo。Nginx 的 master 进程本身是 root 启动的worker 进程会降权到 www-data这是 Nginx 自己的设计和操作习惯无关。2. 在线安装 Nginx 并验证版本新手也能抄的完整命令环境确认没问题之后正式进入安装环节。整个在线安装过程实际上就两条命令apt update 和 apt install nginx。但这两条命令背后涉及到的细节、安装后的验证方法以及目录结构的理解才是你真正需要掌握的东西。2.1 执行安装命令以及安装过程中发生了什么先执行软件源更新再执行安装这是我每次装软件都不会跳过的固定动作sudo apt update sudo apt install -y nginx第一条指令的效果是拉取软件源里最新的软件包列表让系统知道哪个包有什么版本、依赖什么。如果你跳过这一步直接安装有可能会装到过时的版本甚至因为软件源同步状态不一致出现依赖解析错误。第二条命令里我加了 -y 参数意思是遇到确认提示自动选“yes”免去手动回车。如果你不加 -y安装过程中系统会问你是否继续输入 y 再回车也行。安装过程中终端会滚动显示正在下载和安装的软件包除了 nginx 本体之外还会带上几个依赖包通常包括 libnginx-mod-http-* 系列模块和 nginx-common 等。官方 apt 源里 Nginx 的版本可能不是最新的比如 22.04 源里可能是 1.18.024.04 源里可能是 1.24.0但这不是缺陷——Ubuntu 官方源为了稳定性和安全补丁会对版本做固定的追踪。像我之前遇到有人非要装 1.30 以上的新版那就得走 PPA 或源码编译路线日常使用真的没必要。2.2 安装成功的三重验证别看到“done”就以为完事了很多教程到这里就结束了告诉你“安装完成”。但实际上 apt install 成功只是第一步Nginx 是否真的能跑起来、能不能正常响应 HTTP 请求才是部署成功的关键。我习惯用三个命令做验证。第一重验证查看服务的运行状态sudo systemctl status nginx如果输出里有绿色的 active (running)说明服务已经起来了。如果没有 active 而是显示 inactive (dead)说明 Nginx 进程没在运行需要用 systemctl start nginx 手动启动。这里有个 Ubuntu 特有的细节Nginx 在 apt 安装之后会自动注册为 systemd 服务并且安装完会自动启动所以正常情况下你看到的都是 running。第二重验证查看版本信息nginx -v nginx -V注意小写 -v 和大写 -V 的区别这是新手最容易看漏的地方。nginx -v 只会输出一行版本号比如 nginx version: nginx/1.18.0 (Ubuntu)。nginx -V 会输出详细编译参数包括 configure arguments 里面有哪些模块被编译进去了比如 --with-http_ssl_module 表示 SSL 模块已经内置--with-stream 表示四层代理模块可用。后面配置 HTTPS 或者 TCP 代理时先查一下 -V 输出里的模块列表能少走很多弯路。第三重验证在本地直接发一个 HTTP 请求curl -I 127.0.0.1正常情况下你会看到 HTTP/1.1 200 OKServer: nginx/1.18.0 (Ubuntu)这就证明 Nginx 不仅进程在跑而且已经能正常响应 HTTP 请求了。看到 200 OK 的那一刻Nginx 的安装部署就算真正落地了。2.3 摸清 Nginx 安装后的目录结构配置不再迷路安装成功后Nginx 会把自己拆散放到系统各个目录里。搞清楚这些目录各管什么是你后续配置的底气。我整理了一份最常用的目录清单以 apt 安装的 Ubuntu 环境为例目录/文件作用/etc/nginx/配置文件的主目录所有配置都在这里/etc/nginx/nginx.conf主配置文件全局配置和 http 块入口/etc/nginx/sites-available/站点配置的“草稿区”存放所有站点的配置/etc/nginx/sites-enabled/站点配置的“生效区”被软链接进来的配置才生效/etc/nginx/modules-enabled/动态模块的加载配置/usr/share/nginx/html/默认网页根目录刚装完访问 IP 看到的欢迎页在这里/var/log/nginx/日志目录access.log 和 error.log 都在这里/var/www/实际站点文件常用的存放目录这个不是 Nginx 创建的但约定俗成这个目录设计是你以后理解 Ubuntu 下 Nginx 配置的灵魂。Debian 系Ubuntu 也是 Debian 系的 Nginx 有个特有习惯每个站点一个 conf 文件放在 sites-available 里然后用软链接 ln -s 把它“启用”到 sites-enabled 里。这和 CentOS 系把站点配置直接丢在 /etc/nginx/conf.d/ 下的思路不一样你如果用 CentOS 的习惯去改 Ubuntu 的配置很容易蒙圈。重点理解一下 nginx.conf 的层次结构全局块worker 进程数、日志路径、pid 路径→ events 块连接处理模型、连接数上限→ http 块server 配置、upstream 配置、gzip 配置。http 块是整个配置的核心容器server 块是虚拟主机的定义location 块是对 URI 路径的匹配规则。我也是踩过几次坑才彻底搞懂这套结构的比如一开始我以为直接改 sites-enabled 里的 default 文件就行后来发现 sites-available 才是真正的源文件sites-enabled 只是软链接改哪个其实都对因为是同一个文件但理解了这个结构后创建新站点时就知道该往哪个目录放文件了。3. 服务管理、开机自启与防火墙放行一次配到位装好并确认能访问之后接下来要处理的是三件“收尾但绝不能省”的事让 Nginx 开机自动启动、把防火墙端口放行、把日志和进程管理弄得明明白白。这几步不做好你可能第二天开机发现网站打不开了或者在云服务器上怎么都访问不了其实只是防火墙没放行。3.1 systemd 管理 Nginx 服务的几个核心操作安装完 Nginx 后systemd 会自动注册一个 nginx.service 单元。以后你对 Nginx 做的所有启停操作都推荐通过 systemctl 命令完成而不是直接去 kill 进程。# 启动服务 sudo systemctl start nginx # 停止服务 sudo systemctl stop nginx # 重启服务先停再启会有短暂中断 sudo systemctl restart nginx # 重新加载配置平滑重载不断服务 sudo systemctl reload nginx # 设置开机自启 sudo systemctl enable nginx # 查看服务状态 sudo systemctl status nginx这里我要重点强调 restart 和 reload 的区别这是新手最容易混淆的概念。restart 是先把进程停掉再启动期间 Nginx 会短暂不可用对于一个正在跑的线上服务来说这零点几秒的中断也可能造成请求失败。reload 则优雅得多master 进程会重新读取配置文件然后用新的配置启动新的 worker 进程再逐步关闭旧的 worker 进程整个过程用户无感知。我现在的习惯是改完配置先用 nginx -t 检查配置语法确认没问题后一律用 systemctl reload nginx 而不是 restart。只有真正改动了端口、改了 worker 进程数这类必须重启才能生效的配置时才用 restart。关于开机自启apt 安装的 Nginx 在安装时会自动 enable但你还是手动执行一次 sudo systemctl enable nginx 比较稳妥防止有些精简系统里服务默认不自启。判断是否已设置自启可以用 systemctl is-enabled nginx输出 enabled 就代表没问题。3.2 防火墙放行这才是外部访问不到的大多数原因这个坑我踩得最深。有一次我帮朋友部署一个内部工具Nginx 配置完美本机 curl 200 OK但局域网里其他电脑就是访问不了。排查了两小时最后发现是 ufw 防火墙默认策略把 80 端口拦了。Ubuntu 的防火墙默认是 ufw 管理的安装 Nginx 之后防火墙并不会自动放行 80 端口。如果你启用了 ufw必须手动添加规则# 查看 ufw 当前状态inactive 表示未启用 sudo ufw status # 如果状态是 active放行 Nginx 相关的端口 sudo ufw allow Nginx Full # 或者更精确地只放行 80 端口 sudo ufw allow 80/tcp关于 allow Nginx Full 和 allow 80/tcp 的区别Nginx Full 是 ufw 预置的应用规则会同时放行 80 和 443 端口适合你已经打算配置 HTTPS 的场景如果暂时只做 HTTP80/tcp 就够了。如果你是云服务器AWS、阿里云、腾讯云这些光配服务器内部的 ufw 还不够还要在云控制台的安全组/防火墙规则里放行对应端口。云服务器普遍是两层防火墙云平台安全组是外层系统内部 ufw 是内层两层都得通才能访问。3.3 从本机验证到外部验证的完整链路服务配好了、防火墙放行了最后一步做一次端到端的访问验证确保从外部真的能访问到 Nginx。# 第一步本机验证证明 Nginx 正常工作 curl -I 127.0.0.1 # 第二步查看本机 IP ip addr show # 第三步从局域网内另一台电脑或手机浏览器访问 # 格式http://服务器IP地址如果在浏览器里能看到 Nginx 的欢迎页说明部署链路完全打通了。如果本机 curl 正常但外部访问不了按这两个方向排查先看 ufw status 是否放行了 80 端口再看云安全组是否放行了 80 端口。这两个问题解决了外部访问基本就通了。注意我用的是“局域网内另一台设备”做外部验证。如果你是用公网服务器那直接访问服务器公网 IP 即可。如果是虚拟机要确保虚拟网络模式是桥接或 NAT 端口转发否则宿主机外部也访问不到。4. 核心配置解析从默认站点到反向代理把 Nginx 用起来安装部署只是万里长征的第一步真正让 Nginx 为你干活的是后面的配置环节。这一节我会先带你看懂默认配置文件然后逐步实现两个最常见的需求部署一个静态网站、配置一个反向代理。这两个场景覆盖了 Nginx 90% 的日常工作。4.1 nginx.conf 主配置的关键参数解读打开 /etc/nginx/nginx.conf你会看到一大段配置很多人第一次看就头大。不用慌你只需要重点关注这几个参数其他的保持默认就好。user www-data; worker_processes auto; pid /run/nginx.pid; events { worker_connections 768; } http { sendfile on; keepalive_timeout 65; include /etc/nginx/mime.types; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }逐个解释关键项user www-dataworker 进程运行时的用户身份。Nginx 的 master 进程是 root 启动的但真正的 worker 进程会用 www-data 用户来跑这是安全设计。如果你在站点配置里设置了 root 指向某个目录而这个目录 www-data 用户没权限读就会报 403。worker_processes autoworker 进程数auto 表示自动按 CPU 核心数设置通常会是和核数一致。worker_connections 768单个 worker 进程能同时保持的最大连接数默认 768 够用了。计算公式是最大并发连接数 ≈ worker_processes × worker_connections。include /etc/nginx/sites-enabled/*把 sites-enabled 下所有配置加载进来这就是为什么你的站点配置放在 sites-available 然后软链到 sites-enabled 就能生效的原因。每次改完 nginx.conf我用 nginx -t 检查语法通过后 reload。这一步是铁律。4.2 配置一个静态站点把默认欢迎页替换成自己的页面假设我要部署一个个人博客站点文件放在 /var/www/myblog/ 下。步骤如下。第一步创建站点目录并写入一个测试页面sudo mkdir -p /var/www/myblog echo h1Hello, Nginx!/h1 | sudo tee /var/www/myblog/index.html第二步在 sites-available 下创建一个站点配置文件sudo vim /etc/nginx/sites-available/myblog写入以下内容server { listen 80; listen [::]:80; server_name myblog.example.com; root /var/www/myblog; index index.html; location / { try_files $uri $uri/ 404; } }配置项逐行说明listen 80监听 IPv4 的 80 端口listen [::]:80 是监听 IPv6 的 80 端口。写上双行能同时覆盖 IPv4 和 IPv6 访问。server_name虚拟主机名。当用户请求的域名是 myblog.example.com 时Nginx 会用这个 server 块来处理。注意我这里写的是示例域名你实际用的时候要换成自己的域名或 IP。root网页文件的根目录Nginx 会从这里找文件。index默认首页文件名。请求到达根路径时Nginx 会尝试找 index.html。try_files $uri $uri/ 404这个配置稍微有点绕。$uri 是请求的路径Nginx 会先尝试把它当文件找找不到再把它当目录找会匹配到目录下的 index再找不到就返回 404。第三步启用站点并重载sudo ln -s /etc/nginx/sites-available/myblog /etc/nginx/sites-enabled/myblog sudo nginx -t sudo systemctl reload nginx软链接创建成功后你用浏览器访问 http:// 服务器IP/ 时看到的就不再是默认欢迎页而是你写的 Hello, Nginx!。如果你有两个域名比如 myblog.example.com 和 mywork.example.com就再创建第二个 server 块配置文件同样软链进去Nginx 会根据请求的 Host 头自动路由这就是“一台服务器部署多个网站”的核心原理。nginx配置里的 server_name 会按照精确匹配、通配符匹配、正则匹配、默认 server 的顺序去匹配多个站点同时存在时不会冲突。4.3 反向代理配置把后端服务安全地暴露出去反向代理是 Nginx 最强大的功能之一。举个实际场景你的后端 API 服务跑在 8080 端口比如 Java 的 Spring Boot、Python 的 Flask但你不希望用户直接访问 8080 端口而是访问标准的 80 端口。这时候 Nginx 就充当了“前台接待”的角色。server { listen 80; server_name api.example.com; location / { 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 X-Forwarded-Proto $scheme; } }这里最核心的是 proxy_pass 指令它把所有匹配到这个 server 的请求转发给 http://127.0.0.1:8080。后面几行 proxy_set_header 是请求头改写它们的作用是让后端服务知道“用户真实请求的是哪个域名”“用户的真实 IP 是多少”“用户的请求协议是 HTTP 还是 HTTPS”。为什么这些头部信息重要因为 Nginx 做了转发之后后端服务看到的连接来源默认是 Nginx 的 IP127.0.0.1用户直接访问后端时才能拿到用户 IP。如果不把 X-Real-IP 和 X-Forwarded-For 传过去后端的日志里全部是 127.0.0.1排查问题的时候根本分不清请求来自谁。反向代理还附带几个实用能力负载均衡用 upstream 指向多个后端节点Nginx 自动分发请求、缓存前端页面由 Nginx 直接返回减少后端压力、SSL 终止HTTPS 解密交给 Nginx 处理后端用 HTTP 即可。这些后面可以单独写一篇详细展开这里先把基础的反向代理跑通。4.4 常用优化参数gzip 压缩与请求体大小上限部署完基础功能后建议顺手把两个高频优化项也配了。一个是 gzip 压缩另一个是 client_max_body_size。在 http 块或 server 块里加 gzip 配置gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss image/svgxml; gzip_min_length 1024;这些配置开启后Nginx 会在返回静态资源JS、CSS、JSON时用 gzip 压缩浏览器自动解压传输体积能小 60%~80%页面加载速度提升明显。client_max_body_size 是控制请求体上限的。默认是 1m也就是说上传超过 1MB 的文件会被 Nginx 拒绝并返回 413。如果你部署了一个带文件上传功能的应用一定要把这个值调大client_max_body_size 20m;这个参数要放在 http、server 或 location 块里具体放哪取决于你要影响的范围。全局生效放 http单个站点生效放 server单个路径生效放 location。5. 常见问题与排查实录快速定位 Nginx 故障这部分是我最想写给你们的。我这些年跟 Nginx 打交道自己踩过坑也帮别人救过火Nginx 的报错和故障就那么几类。我把最常见的几种列成速查表并附上排查思路你照着一步步走比盲目试效率高得多。5.1 常见错误速查表现象可能原因排查命令 / 解决思路访问 IP 提示无法连接Nginx 未启动 / 防火墙拦截 / 云安全组未放行systemctl status nginxufw status检查云控制台本机 curl 正常外部访问不了防火墙或安全组放行问题重点排查 ufw allow 80/tcp 和安全组入站规则访问页面返回 403 Forbidden站点目录权限不足 / index 文件缺失ls -ld 查看目录权限检查 index 配置访问页面返回 502 Bad Gateway反向代理的后端服务未启动systemctl status 后端服务检查 proxy_pass 地址端口配置改了但访问没变化没有 reload / 软链接未创建sudo nginx -t sudo systemctl reload nginx访问返回 404站点路径不对 / this server 块没匹配上ls 查看文件实际路径检查 server_name 和 root80 端口被占用其他 Web 服务占用了端口sudo ss -lntp | grep :80 查看占用进程上传文件报 413 错误client_max_body_size 默认 1m 太小调到 20m 并 reload5.2 端口冲突的排查方法80 端口被别的服务占了怎么办Nginx 默认监听 80 端口但服务器上可能已经跑了 Apache、Tomcat 或者其他 Web 服务。这时启动 Nginx 会报 bind() to 0.0.0.0:80 failed (98: Address already in use) 的错误。定位过程如下# 查看 80 端口被谁占用了 sudo ss -lntp | grep :80 # 会看到类似输出LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:((apache2,pid1234,fd4))看到占用进程的 PID 后根据你的实际需求做选择如果那个服务不用了就用 systemctl stop 停掉它并禁用开机自启如果想保留两个服务可以把其中一个的监听端口改掉让 Nginx 独享 80另一个改到 8080 或其他端口。改端口后记得同步调整防火墙和安全组规则。5.3 403 权限问题的本质不是配置错了就是权限不够403 Forbidden 出现频率很高我自己第一次上线站点时也遇到过。常见的两个原因目录权限不对或者目录里没有可用的 index 文件。# 检查目录权限 ls -ld /var/www/myblog # 如果权限显示 drwxr-xr-x属主是 root那 www-data 用户有 r-x 权限可以正常读取 # 如果权限是 drwx------那 www-data 用户进都进不去就会 403 # 检查 index 文件是否存在 ls -l /var/www/myblog/index.html推荐的修复方式是把站点目录的属主改成 www-data或者把权限改成 755sudo chown -R www-data:www-data /var/www/myblog sudo chmod -R 755 /var/www/myblog有人喜欢直接把权限改成 777我不推荐——这是给权限问题开了个危险的“后门”生产环境千万不要这样用。改成 755 才是安全且够用的。5.4 配置不生效90% 是没做语法检查和 reload很多新手改了配置文件打开浏览器一看还是旧页面第一反应是“我这配置是不是写错了”。其实大部分情况就是改了配置没让 Nginx 重新加载。我在前面反复强调的操作习惯再说一次# 第一步检查配置语法 sudo nginx -t # 正常会输出 syntax is ok 和 test is successful # 第二步平滑重载配置 sudo systemctl reload nginxnginx -t 会检查所有被加载的配置文件如果哪一行写错了它会明确告诉你错误行号和原因比如 unknown directive 或者 duplicate listen照着提示改就行。reload 之后可以再看一眼 systemctl status nginx确认配置文件加载成功、服务状态正常。另外一个新手容易忽略的坑是你在 sites-enabled 里直接编辑了软链接目标文件这没问题但如果你在 sites-available 里新建了一个文件却忘记做软链接那 Nginx 根本不会加载这份配置自然不生效。所以每次新增站点都要记得 ln -s 软链接然后 nginx -t reload 一套走完。提示日志是定位 Nginx 问题的第一线索。访问问题查 /var/log/nginx/access.log配置或运行时报错查 /var/log/nginx/error.log。有些信息浏览器里根本不显示但日志里写得清清楚楚。用 sudo tail -f /var/log/nginx/error.log 实时盯着日志再去做操作排错效率能翻倍。6. 我常用的 Nginx 运维小技巧踩过坑之后的经验沉淀最后这部分不是配置命令的堆砌是我自己真实踩坑之后沉淀下来的几个习惯。不一定写在官方文档里但确实省了很多事。第一个习惯是配置备份。改任何文件之前先把原文件复制一份带时间戳的备份sudo cp /etc/nginx/sites-available/myblog /etc/nginx/sites-available/myblog.bak.20250101。这样就算改得一团糟也能一键还原不用靠记忆重写配置。第二个习惯是用 curl 而不是浏览器做快速验证。改完配置先 curl -I 看一下响应头比打开浏览器输入网址快得多。curl 还能带上 Host 头模拟域名访问curl -H Host: myblog.example.com http://127.0.0.1在没配 DNS 的情况下也能验证虚拟主机是否正确路由。第三个习惯是理解 server_name 的匹配顺序。Nginx 对多个 server 块的匹配规则是先精确匹配 server_name再匹配通配符开头的.example.com再匹配通配符结尾的www.example.最后匹配正则表达式。全都不匹配时走默认 server通常是 sites-enabled 下第一个或者是 listen 80 default_server 指定的那个。这个顺序搞明白了多站点配置时才不会出现“访问 A 域名却打开了 B 站点”的怪事。第四个经验是关于改配置的操作顺序先 nginx -t 检查语法确认无误再 systemctl reload。这两个动作永远连着做别图省事跳过第一步。reload 只会在配置有语法错误时报错而语法检查能提前拦截写错的指令帮你把风险降到最低。我个人在实际使用中还有一个体会Nginx 的日志配置值得花点心思。访问日志默认格式已经够用但如果将来你要做数据分析或流量统计可以提前加上 $request_time 和 $upstream_response_time 这些字段省得以后改格式。具体做法是在 http 块里自定义一个 log_formatlog_format main_ext $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for $request_time $upstream_response_time; access_log /var/log/nginx/access.log main_ext;这套格式除了记录常规信息还额外记录了请求总耗时和上游响应耗时排查慢接口时非常有用。不过这是进阶玩法刚上手的时候先把默认配置吃透以后再逐步按需扩展。Nginx 这东西就是这样安装部署半小时能搞定但真正玩明白它的配置、性能调优和故障排查需要你在实战中一点点积累。希望这篇博文能让你少走一些我走过的弯路。