张鹏的博客

用 Nginx 部署站点时，目录访问绕不开两个问题：用户访问一个目录时先返回哪个文件？目录里没有默认文件时，是给 403、404 还是一份文件列表？前一个问题归 index 模块管，后一个问题归 autoindex 模块管。这两个问题没配好，最常见的结果是访问首页莫名收到 403。这篇把两个模块的指令写法放在一起讲，并用容器实测展示顺序命中、403 现场和列表效果。 实验环境nginx/1.31.5 容器（docker 镜像 nginx:alpine，一次性容器，用完即删），站点根目录用镜像自带的 /usr/share/nginx/html，配置写在 conf.d/default.conf，每轮改动后 nginx -s reload，用容器内 curl 验证。 两个模块各答一个问题核心机制一句话：index 模块决定”目录 → 默认文件”的映射，autoindex 模块决定”没有默认文件时，目录本身要不要列出内容”。 两个模块常被一起提，但职责完全不同：index 是映射规则，回答”访问 / 时实际读哪个文件”；autoindex 是兜底开关，只在”目录请求、又找不到 ...

想让线上流量在真实环境下回放，又不能影响用户？Nginx 的 mirror 模块干的就是这件事：每个传入的请求除了发往主后端，还会被复制一份发到一个或多个镜像后端，镜像请求的响应直接丢弃，客户端完全无感。本文整理 mirror 模块的用途、配置写法和常见的坑。 mirror 模块的用途mirror 模块把客户请求镜像到一组后端服务器：请求不仅传递到主要后端，还会复制并发送到额外的后端。典型需求有三类： 测试和调试：把生产流量镜像到测试环境，用真实流量做调试和性能测试。 数据分析：镜像流量到专门的分析后端做实时收集和分析，不影响主服务性能。 迁移和更新：迁移新系统或升级现有系统时，验证新系统能扛住相同的流量和负载。 使用场景 安全测试：在不影响生产系统的情况下做安全测试和漏洞分析。 流量监控：实时监控和分析生产流量。 性能优化：在测试环境对不同配置做性能对比。 实验环境 nginx/1.31.5（nginx:alpine 容器） 主后端 127.0.0.1:8081、镜像后端 127.0.0.1:8082（均为容器内 nginx 直接 return，access_l...

把一个用 Vue 或 React 写的前端项目部署到 Nginx，访问首页一切正常，点进 /orders/42 也正常——然后用户在这个页面按了 F5，一个 404 砸在脸上。原因是：/orders/42 是前端路由虚拟出来的路径，磁盘上并不存在，Nginx 找不到文件只能报 404。 结论先行：try_files 一条指令就能解决这类问题——前几个参数按序检查文件是否存在，最后一个参数决定”全部落空时怎么办”。 本文按 how-to 组织：先交代实验环境，再给三组可直接复制的配置与真实输出（SPA 回退、严格 404、转发后端），最后用两个事故实验说清这条指令的边界。所有输出均为实跑结果，未跑过的结论会明确标注。 实验环境可复现是前提，先交代条件： nginx/1.31.5（docker 镜像 nginx:alpine）； 站点目录挂载到 /usr/share/nginx/html，配置挂载到 /etc/nginx/conf.d/； 宿主机 8080 端口映射到容器 80，下文所有 curl 均从宿主机发起； 每轮改动配置后 docker exec 容器名 ngi...

同一个 location 上同时挂了 IP 白名单和密码验证时，请求要过几道关卡？satisfy 指令就是回答这个问题的：any 表示任意一道关卡放行即可，all 表示每道都得过。做”内网免密、外网要密码”这类策略，全靠它。但它和 allow/deny 的书写顺序、和 return 指令的先后关系，藏着几个实测才能看清的坑。 本文按配置实战组织：先交代实验环境，再用四组配置加真实输出验证 any/all 两种组合语义、顺序陷阱和 return 的优先级。所有输出均为 nginx/1.31.5 实跑结果。 实验环境所有实例在容器里可复现： nginx/1.31.5（docker 镜像 nginx:alpine）； 密码文件用 openssl passwd -apr1 生成 apr1 哈希写入 /etc/nginx/.htpasswd，账号 user 密码 password1； 容器内 curl 的来源 IP 是 127.0.0.1，实验里用它扮演”白名单内网 IP”； 受保护内容用真实静态文件，每轮改动后 reload 再验证（reload...

给某个路径加访问控制，又不想把认证逻辑复制进每个后端服务，Nginx 的 auth_request 模块就是为这个场景准备的：Nginx 先把请求转给一个认证端点，拿到状态码再决定放行还是拒绝。这篇在 nginx:1.28 容器里把整条链路实跑一遍——放行、两种拒绝、端点保护，外加两个让 auth_request 悄悄失效的配置坑。 实验环境 Docker 容器 nginx:1.28-alpine（nginx/1.28.3，2026-09 实测，下文全部输出来自这次实验）。 auth_request 是可选模块：自编译 Nginx 需加 --with-http_auth_request_module；官方 Docker 镜像已内置，nginx -V 可确认。 结构：同一个 Nginx 里跑两个 server——8080 端口扮演”外部认证服务”（按请求头判断），80 端口是受保护的主站。生产环境里把 8080 换成真实认证服务即可。 核心机制一句话auth_request /_auth; 让 Nginx 在 access 阶段向 /_auth 发一个内部子请求，按子请...

内部管理页、监控面板这类地址不想裸露在公网，又还没到要上 OAuth 的程度，Nginx 自带的 auth_basic 模块正好补这个位置——两行配置加一个密码文件，就能把所有匿名请求挡在门外。这篇文章讲清楚它的基础配置、常用加固组合和两种典型的错误写法，最后带上 OpenResty 下的进阶用法。所有配置在 nginx/1.31.5（docker 镜像 nginx:alpine）容器内实测，状态码均来自实跑输出。 auth_basic 是什么，什么时候用auth_basic 做的事很简单：对访问指定资源的客户端要求用户名密码，对不上就拒绝。认证机制直观，适合不涉密的数据或内部管理环境——开发测试环境、运维后台和监控页、还没准备好完全公开的临时资源，都是它的典型位置。 实验环境nginx/1.31.5 容器（nginx:alpine），htpasswd 来自 apk add apache2-utils；生产环境把 example.com 换成自己的域名，并确认套在 HTTPS 之后。 基础配置第一步：创建用户密码文件用 htpasswd 生成，Nginx 完全...

Nginx 的所有能力——静态站点、反向代理、负载均衡、缓存、限流——全部通过一份配置文件组织起来。把常用配置项的用途和坑摸清楚，是玩转 Nginx 的前提。这篇按”文件结构 → 高频配置项 → 典型场景”的顺序过一遍，关键行为配了容器实测。 按目标跳转：改整体行为看”全局块”，调并发看 worker_connections，上反代看”反向代理”，上 HTTPS 看”SSL/TLS”，多机分发看”负载均衡”，提速看”缓存”，做加固看”安全配置”。 配置文件结构主配置文件通常位于 /etc/nginx/nginx.conf 或 /usr/local/nginx/conf/nginx.conf，结构上分为全局块、events 块和 http 块： 12345678910111213141516171819202122232425262728293031# 全局块user www;worker_processes 1;error_log /var/log/nginx/error.log;pid /run/nginx.pid;# events 块events { w...

第一次看服务器报价单的人多半会疑惑：同样是 CPU 加内存加硬盘，为什么服务器比高配 PC 贵出好几倍？差价不在算力上，而在三个约束里——不能停机、不能出错、出了问题没人能马上到机房。这篇把服务器的 12 个核心硬件部件过一遍，每个部件都回答同一个问题：企业级设计比 PC 级多做了什么、为什么值得多花钱。 先立一个类比：私家车和长途货运卡车服务器和 PC 的关系，就像长途货运卡车和私家车。私家车的设计目标是便宜、好开、坐着舒服，坏在路上叫救援就行；卡车的设计目标是满载跑几十万公里不出事，所以它有大梁、有双油箱、有发动机预热、驾驶室里的仪表盘比私家车多一排——每一项配置都对着”路上不能趴窝”这个约束。 服务器硬件同理。ECC 内存、冗余电源、RAID、热插拔、IPMI，这些 PC 上见不到或很少见的东西，全部对着”机房里的机器不能停机、不能算错、没人守在旁边”来设计。下面逐个部件看这套设计怎么落地的。 1. 中央处理器（CPU）CPU 是服务器的”大脑”，负责执行所有计算任务。服务器 CPU 常见品牌是 Intel 和 AMD，普遍具备多核和多线程特性，以支撑并行处理。 Inte...

把应用从开发机搬到测试机，缺个库；从测试机搬到生产机，glibc 版本对不上——“在我这儿是好的”这类扯皮，开发和运维都熟。容器就是为终结这种扯皮而生的打包方式：把应用和它依赖的整个环境一起装箱，搬到哪儿都按同一套环境跑。这篇讲清三件事：容器到底是什么、它凭什么比虚拟机轻、以及什么时候你不该用它。 先把类比摆上桌：标准集装箱container 这个词直译就是集装箱，Docker 的 logo 也是一只驮着集装箱的鲸鱼，这个类比不是巧合。 集装箱出现之前，散货装卸靠码头工人一件件搬：桶装的、袋装的、形状不规则的，每换一种运输方式（船 → 火车 → 卡车）就得重新装卸一遍，破损和丢失是常态。标准集装箱推广开之后事情变了：箱子尺寸统一，里面的货不用管，船、火车、卡车用同一套吊具装卸。 容器对软件做的是同一件事。镜像就是那个标准箱子，里面装着应用代码、运行时、库和配置；宿主机、CI 流水线、云厂商的容器服务就是船和卡车——只要这台机器能跑容器，箱子里的应用行为就一致，不用为每个环境重新”装卸”一遍依赖。 第二个类比：别墅与公寓这个类比解释的是”轻”从哪来。 虚拟机是独栋别墅。每户自带地基...

运维场景里经常要限制某些 IP 才能访问：后台入口只对公司网段开放、接口目录只留给监控机。Nginx 为此提供了 allow 和 deny 两个指令，规则本身只有两句话，但匹配顺序、作用范围、网段写法这三处一不留神就会”配了不生效”或”把自己也锁在外面”。这篇把三种典型写法各配一组容器实测，再用一个错误顺序的对照说明规则为什么必须”先 allow 后 deny”。 实验环境结论要能复现，先交代条件： nginx/1.31.5（docker 镜像 nginx:alpine，一次性容器，用完即删）； 站点根目录 /var/www/html，curl 验证状态码，改动后 nginx -s reload 生效； 容器里可用的来源 IP 有两个：环回 127.0.0.1 和容器网卡 172.17.0.3，正好用来做”名单内/名单外”的对照。 匹配规则：顺序命中即停核心机制一句话：Nginx 把 allow/deny 规则按书写顺序逐条比对来源 IP，命中任何一条立即停止，全都没命中才拒绝——所以先写放行名单，最后用 deny all 兜底。 两个指令各一句...