简介：面向Linux运维与Nginx学习者，这份资料包系统梳理了从基础指令到集群架构的完整知识体系，适合初学者进阶以及运维工程师随用随查。内容按基础篇、进阶篇、架构篇、模块篇划分，每个阶段侧重点不同，涵盖nginx指令配置、服务集成、负载均衡、反向代理及Lua扩展等核心主题，并结合多个动手案例与启动流程、HTTP配置块解析图例辅助理解。资源共17个文件，压缩包大小19.88MB，以PDF和MD笔记为主，搭配war包、js样例、xmind思维导图及png图解；其中MD/PDF双格式学习笔记按主题分册，详细记录了每个指令的作用、参数、作用域、注释、使用场景与示例，既可作为系统教程也可作为工作手册。已有184人浏览学习，适合正在从事或准备从事Linux服务管理的开发者快速构建Nginx实战能力。
1. 先看穿这个标题：Nginx 学习资料里真正值钱的是「服务」二字
Nginx 是 Linux 服务器上最常被提起的 Web 服务软件，高并发、反向代理、负载均衡是它身上最显眼的三张标签。很多人拿到一份资料就开始抄配置，看到server { listen 80; }就跑，访问出 Welcome 页就以为会了。但这个标题真正该让你停下思考的是「服务」这两个字：安装、启动、配置、排障、保活，每一个环节背后都是 Linux 系统工程思维在托底。它能帮你解决的是单机静态站、前后端分离联调、多后端负载均衡、给内网多个服务做统一入口这类生产问题；适合刚接手服务器、要在公司内网搭服务的开发者，也适合准备把个人项目部署到云主机的前端同学。一个反直觉的结论是：Nginx 跑得稳不稳，和你会不会写花哨配置关系不大，关键在两条——理不理解 master/worker 的进程模型，知不知道请求进来之后会经过哪几个环节再回来。把这两条串起来看，后面所有配置都只是填参数。
2. 先让 Nginx 装起来并跑通第一个站点：安装验证与配置骨架
2.1 从 Linux 服务视角学 Nginx 先要分清在装什么
先泼一盆冷水：Nginx 不是装完就完事的普通软件，它是一个由 master 进程、worker 进程组成的服务体系。master 负责读配置、管理工作进程、接收 reload 信号；worker 才真正去 accept 连接、处理请求。每多一个 worker，就多一套独立的 epoll 事件循环。单 worker 在普通云主机上扛住上千并发是常态，多 worker 是为了吃满 CPU 多核，而不是「进程越多越快」。
常见做法是用发行版包管理器安装，而不是一上来就源码编译。多数业务场景用系统包足够，优点是开机自启、升级方便、依赖干净；缺点是默认模块组合未必合你胃口。我一般先apt或dnf装一个稳定版，再通过nginx -V看编译参数，确认需要的模块（比如http_ssl_module、http_v2_module）都在不在。缺模块时再考虑从源码加模块重编，但那是少数情况。
这一层还要留意版本认知：当前主流发行版自带的 Nginx 大版本多数在 1.24 到 1.26 之间，语法和核心行为差异不大。只是别把旧资料里过时的习惯带进来，比如 HTTP/2 需要单独确认模块支持、upstream keepalive的配置位置在新版本里有更明确的语义。配置语法这些年变化很小，把一套骨架学会，换到哪个发行版都能很快上手。
2.2 用包管理器安装并用最少命令验证服务状态
以 Debian/Ubuntu 系为例，一条链路装完并确认状态：
sudo apt update sudo apt install -y nginx systemctl enable --now nginx systemctl status nginx --no-pager nginx -v ss -lntp | grep :80前两条完成安装；enable --now同时完成开机自启和立即启动，避免重启后服务没拉起来；systemctl status看主进程状态；nginx -v看版本号；ss -lntp | grep :80确认 80 端口确实有进程在监听，这一步能避免出现「服务起来了但根本没在听」的错觉。CentOS/RHEL 系把apt换成dnf或yum即可，其余命令通用。
ss输出里看到nginx: master监听在*:80，说明安装成功。此时访问http://服务器IP能看到默认欢迎页。这一步很多人卡在云主机安全组没放行 80 端口——服务器内部正常和外部网络可达是两件事。排查时先curl 127.0.0.1，通了再去查防火墙和安全组。
日常维护命令值得形成肌肉记忆：nginx -t检查语法；nginx -s reload平滑重载；nginx -s stop强制停；systemctl restart nginx是完整重启。区别在于 reload 不断存量连接，restart 全断。所以变更配置时首选nginx -t && nginx -s reload，不要轻易 restart。
还要提一下配置文件的组织习惯。主配置/etc/nginx/nginx.conf里通常用include把conf.d/*.conf或sites-enabled/下的站点配置加载进来。我自己的习惯是把每个站点拆成一个独立文件放在/etc/nginx/sites-available/，再软链到sites-enabled/。删除站点时只删软链，保留原文件，这也算给自己留后悔药。
2.3 写第一个可用站点配置：从 server 块到 location 的请求路径
最小可用配置不复杂，但每一行都要知道为什么。以下是我在模拟项目X里常用的骨架：
user www-data; worker_processes auto; error_log /var/log/nginx/error.log warn; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server { listen 80; server_name test.example.com; root /var/www/demo; index index.html; location / { try_files $uri $uri/ =404; } } }user决定 worker 以哪个系统用户去读静态文件，权限不够会直接返回 403；worker_processes auto让 Nginx 按 CPU 核数自动拉起对应数量的 worker；worker_connections是每个 worker 能同时保持的最大连接数，默认 1024 在低并发验证阶段够用。server_name决定用哪个 Host 头匹配这个站点；root是站点根目录；try_files按$uri、目录、最终 404 的顺序查找资源，这是现代前端路由场景最常见的入口写法。
参数边界要清楚：worker_processes不要超过物理核数，调多反而因为上下文切换变慢；worker_connections调高到 4096 很容易，但要同步看系统ulimit -n和内核net.core.somaxconn，否则配置只是心理安慰。改完配置必须跑nginx -t，通过后nginx -s reload。
验证时不要只看页面能不能开，要看请求是否确实落进预期配置：
curl -I http://127.0.0.1/ curl -H "Host: test.example.com" -I http://127.0.0.1/第一条不带 Host，走默认 server；第二条显式带 Host，验证server_name匹配是否正确。如果两条结果不同，大概率是server_name没写对，或默认 server 被其他配置抢占了。这个姿势就是后面所有反向代理调试的基本功：先确认请求落在哪个 server、哪个 location，再去看转发规则。
到这一步，「装好并跑通」已经完成。下一章进入生产价值的核心：把静态之外的流量正确转给后端，以及让多台后端分担压力。
3. 生产最常用的三种配置：反向代理、负载均衡与静态缓存
3.1 反向代理：proxy_pass 是前后端分离联调的核心
反向代理就是让 Nginx 在 80/443 端口接客，再把请求转发给内网后端。后端也许是某个端口上的 Java、Node、Go 服务，也许是 Unix Socket。对前端开发者来说，最直观的价值是同源策略消失：页面在 80 端口，接口也在 80 路径下，浏览器不再出现跨域报错。
先看一段最标准的配置：
server { listen 80; server_name test.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; } location / { root /var/www/frontend; index index.html; try_files $uri $uri/ /index.html; } }location /api/把以/api开头的请求转到本机 8080 端口；proxy_pass http://127.0.0.1:8080;后面没有路径，表示保持原始 URI 透传。proxy_set_header三行属于基本功：Host保持域名，X-Real-IP让后端拿到真实客户端 IP，X-Forwarded-For给后端记录完整代理链。少了Host，很多按域名做路由的后端会返回 400 或直接拒绝。
这一节有个经典坑：proxy_pass末尾带不带/，行为完全不同。http://127.0.0.1:8080;是原始 URI 原样转发；http://127.0.0.1:8080/;则会把 location 前缀去掉再拼接。也就是说，请求/api/orders，前者到后端仍是/api/orders，后者变成/orders。后端接口路径按哪种方式设计，就用哪种方式转发。前后端约定不一致时，第一晚联调就翻车，这是我在某跨平台系统里实际踩过的坑。
如果后端接口还要走 WebSocket，需要在 location 里加两行升级头：
location /ws/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; }Upgrade和Connection "upgrade"是 WebSocket 握手的关键，proxy_read_timeout要调到足够长，否则长连接会被 Nginx 默认 60 秒掐断。这是反向代理里最容易忽略的隐藏参数。
3.2 负载均衡：upstream 的轮询、权重与节点摘除
后端不止一台时，用upstream定义一组后端，再在proxy_pass里指向这个组：
upstream backend_api { server 10.0.0.11:8080 weight=3 max_fails=2 fail_timeout=30s; server 10.0.0.12:8080 weight=1 max_fails=2 fail_timeout=30s; server 10.0.0.13:8080 backup; keepalive 32; } server { listen 80; server_name test.example.com; location /api/ { proxy_pass http://backend_api; proxy_set_header Host $host; proxy_http_version 1.1; proxy_set_header Connection ""; } }参数含义：weight控制流量比例，3:1 就是把三倍请求分到 10.0.0.11；max_fails与fail_timeout组成最朴素的被动健康检查——30 秒内失败 2 次就临时摘除该节点 30 秒；backup表示备用节点，平时不参与，其余节点不可用才顶上；keepalive 32是每个 worker 与后端之间保留的空闲长连接数量，能明显降低 TCP 握手开销。proxy_http_version 1.1和Connection ""必须配合出现，否则长连接根本建不起来，等于keepalive白写。
默认负载均衡算法是轮询。需要会话保持时换成ip_hash，同一来源 IP 固定打到同一后端；需要按后端压力动态分配时用least_conn。选型没有绝对好坏：ip_hash在客户端都走固定出口 IP 时容易打偏；least_conn依赖后端能反映真实负载，否则效果和轮询差不多。
节点摘除的常见做法是注释掉对应server行，但每次都 reload 不够优雅。我一般临时把权重改成 0，让流量自然排空后再处理后端，避免 reload 瞬间中断存量长连接。任何变更都放低峰期做，这是服务稳定性的一条底线。
3.3 静态资源缓存：expires、Cache-Control 与命中率观察
静态资源是 Nginx 性价比最高的处理对象：图片、CSS、JS 交给它直接响应，动态请求回源后端，前后端各干各的。常见配置：
location ~* \.(png|jpg|jpeg|gif|css|js|woff2)$ { root /var/www/frontend; expires 30d; add_header Cache-Control "public, max-age=2592000"; access_log off; }expires 30d让 Nginx 自动在响应头里带Expires和Cache-Control，浏览器在 30 天内重新访问直接使用本地缓存；add_header是显式加固一遍Cache-Control；access_log off给静态文件关掉访问日志，减少磁盘 IO。这里有个反直觉的坑：部署新版本时，如果前端文件名不带 hash 后缀，客户端会继续用旧缓存，改了半天界面还是老样子。所以静态资源要么文件名带内容 hash，要么发布时主动更新版本路径。
验证缓存是否生效不用上监控平台。第一次访问响应 200，响应头里有Cache-Control: max-age=2592000；第二次刷新在浏览器开发者工具里看到from disk cache，说明浏览器缓存已经接管。服务器端想确认请求没有打到后端，可以开启stub_status模块，在配置里加一个/nginx_status的 location，然后看Active connections、accepts、handled、requests这几个核心计数器。如果accepts和handled长期不一致，说明连接层有堆积，需要回头查 worker 连接数和内核队列长度。
到这里，反向代理、负载均衡、静态缓存三大场景都落地了。可以再补一个细节：开启 gzip 能显著压缩文本类响应体积，代价是 CPU 开销。我一般只在文本类 MIME 上开启：
gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_types text/plain text/css application/json application/javascript;gzip_comp_level 5是压缩率和 CPU 消耗的平衡点，再往上压，收益递减明显；gzip_min_length 1k避免对过小的响应做无谓压缩，因为压缩头本身就有开销。
4. Nginx 翻车排查：五个高频报错与对应的解决路径
4.1 502 Bad Gateway：后端明明在，Nginx 却拿不到响应
现象：页面 502，error.log里出现connect() failed (111: Connection refused) while connecting to upstream，或者upstream prematurely closed connection while reading response header from upstream。
原因分两类。如果错误是 Connection refused，多半是后端进程没启动，或监听端口和proxy_pass不一致；如果是prematurely closed connection，则可能是后端处理超时、响应体过大被中间层掐断，或后端自己崩了。
解决顺序：先ss -lntp | grep 8080确认后端端口在听；不在，就直接去查后端服务日志。再确认 Nginx 配置文件里的地址端口与后端实际监听一致，很多 502 只是这里写错一个数字。还解不掉时，临时加proxy_buffering off;关掉缓冲试一次。关掉立刻恢复，说明是缓冲空间不够，再按需调proxy_buffer_size和proxy_buffers。如果是慢接口超时，调大proxy_read_timeout，默认 60 秒对耗时操作确实太短。
这类问题的排查路径应该是：后端进程 → 端口 → Nginx 转发地址 → 超时与缓冲 → 后端自身日志。绝大多数 502 停在前两层，别一上来就动超时参数。
4.2 403 Forbidden：目录权限和启动用户之间的隐形矛盾
现象：静态页面能开，但某个目录下的资源全部 403。错误日志里出现Permission denied或open() "/var/www/..." failed (13: Permission denied)。
原因：Nginx 默认user www-data;，但业务把文件放在 root 用户目录下，worker 进程没有读权限。另一个常见来源是开启了 SELinux 的发行版，Nginx 进程域与文件标签不匹配，权限看似对，实际被内核拦下。
解决：先确认文件权限是 644/755，而不是 600/700。然后别只看最后一级目录，用namei -l /var/www/demo/index.html检查路径上每一层目录的权限，因为 Nginx 访问文件要求每一层都有x权限。SELinux 环境里可以先临时执行setsebool -P httpd_read_user_content 1验证是否和 SELinux 有关，长期方案是给目录打正确标签：chcon -Rt httpd_sys_content_t /var/www。
顺带提醒：排查 403 时不要因为省事就把整个目录 chmod 777。这确实能立刻解决，但也等于把安全边界拆了。正确姿势是让站点文件归属到 Nginx 的运行用户组，目录 750、文件 640 就足够。
4.3 配置改了不生效：nginx -t 通过，行为却还是旧的
现象：改了配置文件，nginx -t提示 syntax ok，reload 也执行了，但行为没有变化，响应头或转发目标还是旧配置。
原因：最常见的是改错了文件。Nginx 主配置通过include把conf.d/*.conf和sites-enabled/下的软链都加载进来，实际生效的可能是另一个文件里的同名server块。还有一种情况是nginx -s reload时 Shell 的 PATH 指向了另一个二进制，和 systemd 里跑的不是同一个。
解决：用nginx -T把最终生效的完整配置一次性打出来，搜索server_name和listen，你改的内容在不在里面一目了然。再执行which nginx和systemctl show nginx -p ExecStart对比二进制路径。改完以后curl -I看响应头里的 Server 字段，判断是否还是旧进程。养成nginx -t && nginx -s reload连着跑的习惯，这一条能省掉大量玄学排查时间。
4.4 listen 端口冲突：address already in use 的另一层原因
现象：启动或 reload 时报bind() to 0.0.0.0:80 failed (98: Address already in use)。
原因：80/443 被占用。可能是另一个 Web 服务先启动了，也可能上一次 Nginx 没有正确退出，还有一种是配置里写了两个相同的listen 80 default_server;，语法检查不报，启动时才暴露。
解决：先ss -lntp | grep :80看占用进程的 PID，再用ps -p PID -o comm=确认身份。如果是旧 Nginx，用kill -QUIT 主进程PID优雅退出，再重新启动；如果是其他服务，要么停掉，要么让 Nginx 换端口。同一份配置里重复listen的情况，搜索配置文件里的listen行就能发现。不要一冲突就kill -9，先给进程几秒时间处理完存量请求。
4.5 日志时间不对：排查问题先看 error.log 的时区与级别
现象：出问题后翻日志，发现时间全是昨天，或者日志里根本没有报错，但服务确实在异常。
原因：Nginx 默认错误日志走系统本地时间和 warn 级别。服务器时区如果是 UTC，你按北京时间对表自然对不上；日志级别默认是 warn，info和debug级别的信息被过滤了，很多线索根本没被记录。
解决：主配置里显式写error_log /var/log/nginx/error.log warn;，确认级别符合预期。需要深挖时临时降到debug，复现问题后立刻改回warn，否则 debug 日志会以极快速度写满磁盘。服务器时区用timedatectl set-timezone Asia/Shanghai（按实际需要）统一，或者直接接受 UTC 并在查日志时做时间换算。
访问日志和错误日志要分开看。定位慢请求用 access log 里的$request_time字段；定位失败原因用 error log。两个文件配合，才能把「什么时候慢」「为什么慢」拼成完整链条。下面这张定位表可以作为快速参考：
| 报错关键词 | 大概率原因 | 第一步动作 |
|---|---|---|
| Connection refused | 后端没起或端口不对 | ss -lntp确认端口 |
| Permission denied | 文件权限或 SELinux | namei -l查路径 |
| Address already in use | 端口被占或配置重复 | ss -lntp找 PID |
| upstream timed out | 后端处理超过超时时间 | 调proxy_read_timeout |
| no resolver defined | 转发域名无法解析 | 配置resolver |
5. 从能跑到跑稳：压测验证与四个值得先调的稳定性参数
调优最忌讳改完参数直接上生产。我习惯先在测试环境用ab打一轮基线。ab来自 apache2-utils 包，Debian 系安装命令是sudo apt install -y apache2-utils。压测命令本身不复杂：
ab -n 10000 -c 200 http://127.0.0.1/test.html-n是总请求数，-c是并发数。结果里只看三个指标：Requests per second、Time per request、Failed requests。基线数据留档，改完参数再打一轮，对比才有说服力。没留基线的调优都是心理安慰。
四个值得先调的参数，按优先级排序：
第一是连接数。worker_connections 4096;配合worker_processes auto;，让单机并发能力先上去。但必须同步确认ulimit -n大于worker_processes × worker_connections，否则内核直接卡在 accept 队列。第二是超时。proxy_connect_timeout 5s; proxy_read_timeout 60s;给上游设一个合理闭环，避免一个慢接口拖住整个 worker。第三是长连接。keepalive_timeout 65;和keepalive_requests 100;控制客户端到 Nginx 的保持时间，过短增加握手，过长占用连接。第四是压缩。gzip on; gzip_comp_level 5;对文本类响应收益明显，但压测时多留意 CPU 是否被打满。
这些参数不是越大越好。超时调太大，坏节点迟迟不被发现，用户直接卡死；连接数调太大，内存占用上升，云主机小规格时反而先把自己压垮。每改一个参数，跑一轮压测对比基线，两轮峰值稳定后才可以固化配置。
跑稳之后，再补一个最小闭环：日志按天切割、配置变更自动检查、上游失败快速转移到备用节点。日志切割用 logrotate 的 daily 规则，配合nginx -s reopen重开日志文件；变更发布脚本里强制跑nginx -t，不过检不允许 reload；上游节点挂了时，backup节点自动接盘。这套组合看似简单，但能把「半夜被叫起来处理 502」变成「第二天看日志有一条告警记录」。
我自己在模拟项目X里经历过一次印象深刻的事故：压测数据很好看，上线第二天下午高峰突然大面积超时。最后发现是worker_connections调大了，但系统ulimit -n没改，所有连接被内核卡死在 accept 队列里。从那以后我的习惯变成：任何调参都同时查系统资源限制，压测数据留档，改动至少观察两轮峰值再固化。希望你调参时也能少走这条弯路，希望帮到你。
本文还有配套的精品资源，点击获取
