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命令目录结构可视化的小工具/usr/local/nginxconf/html/logs/sbin/nginx.conf ★核心配置nginx.conf.default 备份mime.types MIME映射fastcgi.conf / fastcgi_paramsuwsgi_params / scgi_paramskoi-utf / koi-win / win-utf 编码转换index.html 默认首页50x.html 错误页access.log 访问日志error.log 错误日志nginx.pid master进程ID仅运行时存在nginx 二进制可执行文件一、顶层目录结构安装完成后进入安装目录cd/usr/local/nginxls输出conf html logs sbin只有四个目录这是Nginx轻量的一个直观体现。用tree命令看更清晰tree若提示command not found先安装yuminstalltreetree的输出大致如下未启动状态. ├── 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 └── nginxlogs为空——因为服务还没启动过。二、conf目录配置文件存放处conf是后续所有工作的主战场。文件虽多真正需要掌握的只有两个。nginx.conf—— 核心配置文件这是Nginx的唯一配置入口后面所有能力部署静态资源、反向代理、负载均衡全部通过修改它实现。它的完整结构见下一篇这里先记住三点Nginx启动时默认加载的就是conf/nginx.conf它由若干个块组成main全局、events、http内含serverserver内含locationinclude指令可以把其他文件引入进来这就是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/atomxml atom; application/rssxml rss; text/plain txt; image/png png; image/svgxml 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_FILENAMEfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;本项目的Java技术栈完全用不到这两个文件它们是LNMPLinuxNginxMySQLPHP架构的产物。uwsgi_params/scgi_params分别用于uWSGI协议Python应用和SCGI协议。同样是本项目用不到的历史遗留文件。koi-utf/koi-win/win-utf—— 字符集转换表用于KOI8-R俄文与Windows-1251之间的编码转换。因为Nginx出自俄罗斯早期需要照顾西里尔字母用户。中文环境不需要关心也不需要在配置里include它们。配置文件小结文件是否常用说明nginx.conf★★★核心配置唯一必改文件nginx.conf.default★★原始备份改崩时用于恢复mime.types★★MIME映射被include引入fastcgi.conf/fastcgi_params—PHP场景Java项目不用uwsgi_params/scgi_params—Python/SCGI场景本项目不用koi-utf/koi-win/win-utf—俄文编码转换中文环境不用三、html目录静态资源根目录默认提供两个页面lshtml# 50x.html index.htmlindex.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.pidaccess.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字段含义字段示例说明客户端IP192.168.138.1发起请求的来源IP远程用户-未开启认证时为空时间[11/Sep/2026:09:30:15 0800]请求时间请求行GET / HTTP/1.1方法、URI、协议状态码200响应状态响应大小612响应体字节数Referer-来源页User-AgentMozilla/5.0 ...客户端标识实时跟踪tail-f/usr/local/nginx/logs/access.logerror.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|grepnginxroot 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 processnginx.pid里记录的116947正是master进程的PID。这个文件的作用nginx -s reload、nginx -s stop这些命令需要知道该给哪个进程发信号。实现方式就是读取nginx.pid拿到master的PID然后kill相应信号命令实际发送的信号nginx -s stopTERM立即终止nginx -s quitQUIT优雅退出处理完当前请求nginx -s reloadHUP重新加载配置nginx -s reopenUSR1重新打开日志文件nginx.pid的生命周期服务启动时创建服务停止时自动删除。所以判断Nginx是否在运行看这个文件在不在即可比ps更轻量test-f/usr/local/nginx/logs/nginx.pidecho运行中||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-mtime30-delete配合crontab每天零点执行00* * * /usr/local/nginx/sbin/cut_logs.sh为什么必须发USR1mv只是改了文件名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的磁盘缓冲区目录用途client_body_temp请求体超过client_body_buffer_size时暂存到磁盘proxy_temp反向代理时后端响应超过proxy_buffer_size时暂存fastcgi_tempFastCGI响应缓冲区uwsgi_tempuWSGI响应缓冲区scgi_tempSCGI响应缓冲区这些目录通常不需要手工操作。但有一个生产要点如果上传大文件或代理大响应这些目录所在分区必须有足够空间否则会报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——这是一个高频踩坑点。七、目录结构速查表目录 / 文件说明备注conf配置文件存放目录conf/nginx.confNginx核心配置文件后续所有配置都改这里conf/nginx.conf.default原始配置备份改崩时用于恢复conf/mime.typesMIME类型映射被nginx.conf的include引入html静态资源存放目录部署前端页面就放这里html/index.html默认首页看到Thank you for using nginx.即启动成功html/50x.html5xx错误页后端不可用时展示logs日志目录logs/access.log访问日志每次请求一条logs/error.log错误日志排查问题第一站logs/nginx.pidmaster进程ID仅运行时存在停止时自动删除sbin/nginx二进制可执行文件启动、停止、重载都靠它client_body_temp等磁盘缓冲区运行时生成一般不需干预API 速览命令作用yum install tree安装tree命令tree以树形结构展示当前目录tree -L 2只展示两层tree -d只显示目录不显示文件ls -l sbin查看sbin目录内容cat logs/nginx.pid查看master进程IDps -ef | grep nginx查看Nginx进程masterworkertail -f logs/access.log实时跟踪访问日志tail -f logs/error.log实时跟踪错误日志cp conf/nginx.conf.default conf/nginx.conf用默认配置覆盖恢复kill -HUP $(cat logs/nginx.pid)发HUP信号重新加载配置kill -QUIT $(cat logs/nginx.pid)发QUIT信号优雅停止kill -USR1 $(cat logs/nginx.pid)发USR1信号重新打开日志文件官方文档Nginx目录与配置说明https://nginx.org/en/docs/Nginx核心模块pid、user、worker_processes、error_loghttps://nginx.org/en/docs/ngx_core_module.htmlNginx日志模块access_log、log_formathttps://nginx.org/en/docs/http/ngx_http_log_module.htmlNginx控制命令https://nginx.org/en/docs/control.htmlMIME类型注册机构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进程的PIDnginx -s reload本质是读取这个文件然后发HUP信号。文件随服务启停自动创建/删除因此文件是否存在就是最简单的存活判断。html/index.html是最快的验证手段。浏览器看到Thank you for using nginx.就说明服务正常、端口可达、防火墙已放行。访问不到时先怀疑防火墙再看服务是否真的起来了。运行后出现的*_temp目录不用管但要留意client_max_body_size默认只有1m。涉及文件上传的场景必须显式调大否则会得到413。下一篇讲Nginx的常用命令查看版本、检查配置、启动停止、重新加载以及配置环境变量让命令可以在任意目录下执行。