Java 项目实战: 外卖平台优化-Nginx目录结构与conf配置文件体系

接入 Nginx: 安装目录结构剖析与 conf 配置文件体系

纲要

「Nginx目录结构」，把安装后/usr/local/nginx下的四个目录拆开讲透：

• 四大目录职责：conf（配置）、html（静态资源）、logs（日志）、sbin（二进制）
• conf/完整清单：nginx.conf是唯一入口，其余fastcgi/uwsgi/scgi/mime.types/koi-*各自的作用
• html/默认页面：index.html与50x.html的触发时机
• logs/三类文件：access.log、error.log、nginx.pid，以及pid文件的生命周期
• 运行后新增的临时目录：client_body_temp等*_temp目录的用途
• tree命令：目录结构可视化的小工具

一、顶层目录结构

安装完成后进入安装目录：

cd/usr/local/nginxls

输出：

conf html logs sbin

只有四个目录，这是Nginx"轻量"的一个直观体现。用tree命令看更清晰：

tree

若提示command not found，先安装：

yuminstalltree

tree的输出大致如下（未启动状态）：

. ├── conf │ ├── fastcgi.conf │ ├── fastcgi.conf.default │ ├── fastcgi_params │ ├── fastcgi_params.default │ ├── koi-utf │ ├── koi-win │ ├── mime.types │ ├── mime.types.default │ ├── nginx.conf │ ├── nginx.conf.default │ ├── scgi_params │ ├── scgi_params.default │ ├── uwsgi_params │ ├── uwsgi_params.default │ └── win-utf ├── html │ ├── 50x.html │ └── index.html ├── logs └── sbin └── nginx

logs为空——因为服务还没启动过。

二、conf目录：配置文件存放处

conf是后续所有工作的主战场。文件虽多，真正需要掌握的只有两个。

nginx.conf—— 核心配置文件

这是Nginx的唯一配置入口，后面所有能力（部署静态资源、反向代理、负载均衡）全部通过修改它实现。

它的完整结构见下一篇，这里先记住三点：

• Nginx启动时默认加载的就是conf/nginx.conf
• 它由若干个"块"组成：main（全局）、events、http（内含server，server内含location）
• include指令可以把其他文件引入进来，这就是mime.types等文件被使用的原因

nginx.conf.default—— 默认配置备份

是源码自带的原始配置副本。当把nginx.conf改坏且无从恢复时，可以直接把它复制回去：

cp/usr/local/nginx/conf/nginx.conf.default /usr/local/nginx/conf/nginx.conf

这也是一个值得养成的习惯：每次大改配置前先备份。

cpnginx.conf nginx.conf.bak.$(date+%Y%m%d%H%M%S)

mime.types——MIME类型映射表

定义了文件扩展名与Content-Type响应头的对应关系。nginx.conf里通常有一行：

http { include mime.types; default_type application/octet-stream; ... }

mime.types内容形如：

types { text/html html htm shtml; text/css css; text/xml xml; image/gif gif; image/jpeg jpeg jpg; application/javascript js; application/atom+xml atom; application/rss+xml rss; text/plain txt; image/png png; image/svg+xml svg svgz; application/json json; application/pdf pdf; ... }

为什么重要：浏览器依据Content-Type决定如何处理响应体。

• 若.css被当成application/octet-stream返回，浏览器会拒绝应用样式，页面变成裸HTML
• 若.js的Content-Type不对，现代浏览器会直接拒绝执行并报MIME type mismatch

所以不要删掉include mime.types;。如果用了mime.types里没有的扩展名（比如.wasm、.m3u8），会回退到default_type（二进制流下载），需要手动补一行types或在location里用add_header覆盖。

fastcgi.conf/fastcgi_params——FastCGI参数

用于把请求转发给PHP-FPM之类的FastCGI程序。二者内容几乎相同，区别仅在于fastcgi.conf多定义了SCRIPT_FILENAME：

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

本项目的Java技术栈完全用不到这两个文件，它们是LNMP（Linux+Nginx+MySQL+PHP）架构的产物。

uwsgi_params/scgi_params

分别用于uWSGI协议（Python应用）和SCGI协议。同样是本项目用不到的历史遗留文件。

koi-utf/koi-win/win-utf—— 字符集转换表

用于KOI8-R（俄文）与Windows-1251之间的编码转换。因为Nginx出自俄罗斯，早期需要照顾西里尔字母用户。中文环境不需要关心，也不需要在配置里include它们。

配置文件小结

三、html目录：静态资源根目录

默认提供两个页面：

lshtml# 50x.html index.html

index.html—— 默认首页

nginx.conf默认配置中有：

location / { root html; index index.html index.htm; }

root html;是相对路径，相对于Nginx安装目录/usr/local/nginx，即实际路径/usr/local/nginx/html。

访问http://192.168.138.100/时：

• location /匹配到请求
• index index.html index.htm;指定默认找index.html
• 返回/usr/local/nginx/html/index.html

页面内容是经典的Welcome to nginx!，其中有Thank you for using nginx.字样——看到这句话就说明Nginx启动成功且能被访问到，这是最快的验证手段。

部署自己的静态资源时，把文件放到这个目录下即可，这就是后面「部署静态资源」一节的做法。

50x.html—— 服务端错误页

配置中通常有：

error_page 500 502 503 504 /50x.html; location = /50x.html { root html; }

当Nginx自身产生5xx错误（典型场景：反向代理的后端全部不可用时返回502 Bad Gateway），会把/50x.html的内容返回给用户，而不是暴露默认的丑陋错误页。

注意区分：

• 50x.html只在Nginx自身出错时显示（后端挂了、网关错误）
• 后端Spring Boot抛异常返回的500不会走这里——Nginx只是把后端的响应原样透传

四、logs目录：日志与进程 ID

启动前与启动后

安装完成未启动时，logs是空目录。启动后：

/usr/local/nginx/sbin/nginxlslogs# access.log error.log nginx.pid

access.log—— 访问日志

记录每一次请求。默认格式（main格式）的一条记录：

192.168.138.1 - - [11/Sep/2026:09:30:15 +0800] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0"

字段含义：

实时跟踪：

tail-f/usr/local/nginx/logs/access.log

error.log—— 错误日志

记录Nginx的错误与警告。排查问题的第一站。

典型场景：配置文件写错时执行nginx -t，错误信息会同时输出到控制台并写入这里：

2026/09/11 09:28:03 [emerg] 12345#0: unknown directive "abc" in /usr/local/nginx/conf/nginx.conf:3

这条日志清晰地指出：未知指令abc，在nginx.conf的第 3 行。

常见的错误日志内容还有：

• connect() failed (111: Connection refused) while connecting to upstream—— 反向代理的后端没起来
• bind() to 0.0.0.0:80 failed (98: Address already in use)—— 端口被占
• No such file or directory—— 静态资源路径配错

nginx.pid—— 进程 ID 文件

这是理解Nginx信号机制的关键文件。

catlogs/nginx.pid# 116947

用ps验证：

ps-ef|grepnginx

root 116947 1 0 09:30 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx nobody 116948 116947 0 09:30 ? 00:00:00 nginx: worker process

nginx.pid里记录的116947正是master进程的PID。

这个文件的作用：nginx -s reload、nginx -s stop这些命令需要知道该给哪个进程发信号。实现方式就是读取nginx.pid拿到master的PID，然后kill相应信号：

nginx.pid的生命周期：服务启动时创建，服务停止时自动删除。所以判断Nginx是否在运行，看这个文件在不在即可（比ps更轻量）：

test-f/usr/local/nginx/logs/nginx.pid&&echo"运行中"||echo"已停止"

也可以手动发信号，效果与-s等价：

kill-HUP$(cat/usr/local/nginx/logs/nginx.pid)# 等价于 nginx -s reloadkill-QUIT$(cat/usr/local/nginx/logs/nginx.pid)# 等价于 nginx -s quit

日志切割

生产环境access.log会无限增长，必须定期切割。Nginx提供USR1信号实现"重新打开日志文件"：

#!/bin/bash# /usr/local/nginx/sbin/cut_logs.shLOG_PATH=/usr/local/nginx/logsYESTERDAY=$(date-dyesterday +%Y%m%d)mv${LOG_PATH}/access.log${LOG_PATH}/access-${YESTERDAY}.logmv${LOG_PATH}/error.log${LOG_PATH}/error-${YESTERDAY}.log# 通知 master 进程重新打开日志文件kill-USR1$(cat${LOG_PATH}/nginx.pid)# 删除 30 天前的日志find${LOG_PATH}-name"*-*.log"-mtime+30-delete

配合crontab每天零点执行：

00* * * /usr/local/nginx/sbin/cut_logs.sh

为什么必须发USR1：mv只是改了文件名，Nginx进程仍持有原文件的inode句柄，还会继续往那个已被改名的文件里写。发USR1让它重新open一次，才会写回新的access.log。

五、sbin目录：二进制可执行文件

ls-lsbin# -rwxr-xr-x. 1 root root 3857424 nginx

整个Nginx只有一个可执行文件，约3.8MB。所有命令都通过它加不同参数完成：

./nginx# 启动./nginx-v# 查看版本./nginx-V# 查看版本 + 编译参数./nginx-t# 检查配置文件语法./nginx-sstop# 停止./nginx-sreload# 重新加载配置

注意相对路径./nginx要求当前目录必须在sbin下。在其他目录下要用绝对路径：

/usr/local/nginx/sbin/nginx-sreload

反复写这么长的路径很麻烦，下一篇会讲如何配置环境变量简化。

六、运行时新增的临时目录

启动后回到安装目录再看：

ls/usr/local/nginx# client_body_temp conf fastcgi_temp html logs proxy_temp scgi_temp sbin uwsgi_temp

多出一批*_temp目录。它们是Nginx的磁盘缓冲区：

这些目录通常不需要手工操作。但有一个生产要点：如果上传大文件或代理大响应，这些目录所在分区必须有足够空间，否则会报No space left on device。

相关配置项（在nginx.conf中）：

http { client_max_body_size 100m; # 允许的最大请求体 client_body_buffer_size 128k; # 请求体内存缓冲区，超出写临时文件 proxy_buffer_size 4k; # 代理响应头缓冲区 proxy_buffers 4 32k; # 代理响应体缓冲区数量与大小 }

client_max_body_size默认是1m。外卖平台有图片上传功能，如果前端直接把图片传给Nginx再代理到后端，超过1m会被直接拒绝并报413 Request Entity Too Large——这是一个高频踩坑点。

七、目录结构速查表

API 速览

官方文档

• Nginx目录与配置说明：https://nginx.org/en/docs/
• Nginx核心模块（pid、user、worker_processes、error_log）：https://nginx.org/en/docs/ngx_core_module.html
• Nginx日志模块（access_log、log_format）：https://nginx.org/en/docs/http/ngx_http_log_module.html
• Nginx控制命令：https://nginx.org/en/docs/control.html
• MIME类型注册机构：https://www.iana.org/assignments/media-types/media-types.xhtml

总结

四个目录，只需盯住两个文件：conf/nginx.conf（所有配置改这里）和sbin/nginx（所有命令用它）。其余文件要么是被include的辅助配置，要么是历史遗留的无关协议支持。

conf目录里 80% 的文件在本项目中用不到。fastcgi_*、uwsgi_params、scgi_params、koi-*都是PHP/Python/俄文场景的产物，Java技术栈直接忽略即可。但mime.types必须保留——它决定响应头Content-Type，丢了会导致CSS/JS加载失败。

logs/nginx.pid是理解Nginx信号机制的钥匙。它记录master进程的PID，nginx -s reload本质是读取这个文件然后发HUP信号。文件随服务启停自动创建/删除，因此"文件是否存在"就是最简单的存活判断。

html/index.html是最快的验证手段。浏览器看到Thank you for using nginx.就说明服务正常、端口可达、防火墙已放行。访问不到时先怀疑防火墙，再看服务是否真的起来了。

运行后出现的*_temp目录不用管，但要留意client_max_body_size默认只有1m。涉及文件上传的场景必须显式调大，否则会得到413。

下一篇讲Nginx的常用命令：查看版本、检查配置、启动停止、重新加载，以及配置环境变量让命令可以在任意目录下执行。