配 Nginx 时最烦的是记住 location 修饰符优先级、proxy_pass 要不要斜杠、upstream 健康检查怎么写。这个速查表把三种最常用的配置块——location 匹配规则、反向代理转发、上游服务器组——拆成可复用的模板，每个参数旁标注了常见陷阱。纯前端页面，所有内容都在浏览器里展示，不收集任何配置信息。适合部署前抄一段、排查时对照参数格式，或者刚接手旧项目时快速确认写法。
后端团队通知 API 网关地址从 `api.old.com` 迁移到 `api.new.com`，要求在 10 分钟内完成切换，且不能中断现有请求。运维人员需要快速编写一个 `proxy_pass` 指向新地址，并利用 `location` 匹配旧路径 `/v1/order`，同时用 `upstream` 配置新旧两个 server 实现灰度切换。本工具直接提供 `proxy_pass` + `upstream` 的完整模板，替换 IP 即可生效，避免手写时漏掉 `proxy_set_header Host` 导致 502 错误。
前端开发者在本地 `localhost:3000` 调试，后端接口部署在 `10.0.1.5:8080`，浏览器因同源策略拦截请求。需要为 Nginx 配置 `location /api/` 的反代规则，并添加 `add_header Access-Control-Allow-Origin` 头。本工具提供 `proxy_pass` + CORS 头配置的联合模板，只需替换后端地址和允许的域名，省去查阅 MDN 文档拼接 `add_header` 的繁琐过程。
公司上线抢购活动，单台 Java 应用服务器预估扛不住 5000 QPS，运维需要快速搭建一个 Nginx 反向代理集群。需要配置 `upstream` 块包含 3 台应用服务器 IP，并设置 `least_conn` 负载算法，同时为 `/checkout` 路径单独配置 `proxy_pass`。本工具提供 `upstream` 的完整写法模板，直接填入 IP 和端口，避免手写时漏掉 `server` 分号或权重参数导致流量分配不均。
前端发布新版本后，`app.abc123.js` 变成 `app.def456.js`，但 CDN 缓存未刷新，用户仍加载旧 JS 导致页面报错。运维人员需要在 Nginx 配置中为 `/static/` 路径设置 `location` 规则，并添加 `expires -1` 禁用缓存，或在 `proxy_pass` 后追加 `?v=$timestamp` 参数。本工具提供 `location` 块中 `expires` 和 `add_header Cache-Control` 的配置示例，直接复制修改路径即可生效。
安全审计要求所有 HTTP 请求必须 301 跳转到 HTTPS，且不能暴露后端真实 IP。运维需要为 `server` 块配置 `return 301 https://$host$request_uri`，并确保 `proxy_set_header X-Forwarded-Proto` 正确传递协议标识。本工具提供 HTTP 到 HTTPS 的完整 `server` 块模板，包含 `listen 80` 和 `return` 语句，以及后端 `location` 中需要补充的 `proxy_set_header` 头，避免跳转后业务接口返回 400 错误。
| 输入 | 输出 | 说明 |
|---|---|---|
| location /api/ { proxy_pass http://backend; } | location /api/ { proxy_pass http://backend; } | 常规：最常见的反向代理配置，验证工具能正确处理 location 块和 proxy_pass 指令 |
| upstream backend { server 192.168.1.10:8080 weight=3; server 192.168.1.11:8080; } | upstream backend { server 192.168.1.10:8080 weight=3; server 192.168.1.11:8080; } | 常规：upstream 负载均衡配置，验证工具能处理多 server 和 weight 参数 |
| location / { proxy_pass http://backend; } | location / { proxy_pass http://backend; } | 边界：根路径 location（/），验证工具能正确处理空路径和默认匹配 |
| location ~ \.php$ { proxy_pass http://backend; } | location ~ \.php$ { proxy_pass http://backend; } | 边界：正则表达式 location（~），验证工具能保留转义字符和正则语法 |
| location /api/ { proxy_pass http://backend/; } | location /api/ { proxy_pass http://backend/; } | 易错：proxy_pass 末尾带斜杠（/），会导致 URI 替换行为不同，新手常混淆 |
| upstream backend { server 127.0.0.1:3000; server unix:/tmp/app.sock; } | upstream backend { server 127.0.0.1:3000; server unix:/tmp/app.sock; } | 边界：混合 TCP 和 Unix socket 地址，验证工具能识别 unix: 前缀 |
| location /static/ { proxy_pass http://cdn.example.com; proxy_set_header Host $host; } | location /static/ { proxy_pass http://cdn.example.com; proxy_set_header Host $host; } | 常规：带额外指令（proxy_set_header）的配置，验证工具能保留多行指令 |
1.location 末尾缺少斜杠，导致路径匹配异常
location /api { proxy_pass http://backend; }location /api/ { proxy_pass http://backend; }Nginx 中 location 是前缀匹配，不带斜杠时 /api 也会匹配 /api2，加上斜杠明确只匹配 /api/ 路径，避免意外路由到错误后端。
2.proxy_pass 末尾斜杠与 location 冲突，路径被错误拼接
location /api/ { proxy_pass http://backend; }location /api/ { proxy_pass http://backend/; }proxy_pass 末尾无斜杠时，会将 location 匹配的完整 URI 原样转发；有斜杠时，会去掉 location 匹配部分再拼接。两者不一致会导致请求路径多出 /api 前缀。
3.upstream 名称与域名冲突，导致 DNS 解析失败
upstream example.com { server 192.168.1.1; }upstream backend_servers { server 192.168.1.1; }upstream 名称不能与任何域名相同，否则 Nginx 会尝试 DNS 解析该名称，导致配置加载失败或启动报错。
4.server 块内缺少 listen 指令，Nginx 拒绝启动
server { server_name example.com; location / { ... } }server { listen 80; server_name example.com; location / { ... } }Nginx 要求每个 server 块必须显式指定 listen 端口，否则默认不监听任何端口，配置检查（nginx -t）会报错。
5.location 中使用正则但未加 ~ 前缀，被当作前缀匹配
location /api/.*\.php$ { fastcgi_pass ...; }location ~ /api/.*\.php$ { fastcgi_pass ...; }Nginx 区分正则 location（~ 或 ~*）和前缀 location。不加 ~ 时，路径中的正则符号被当作普通字符，不会按正则逻辑匹配。
6.proxy_set_header Host 写死固定值，导致多域名服务异常
proxy_set_header Host $proxy_host;proxy_set_header Host $http_host;$proxy_host 是 upstream 地址中的主机名，多域名场景下会丢失原始请求的 Host 头，导致后端无法正确路由。$http_host 保留原始请求的 Host。
7.upstream 中 server 权重写错位置，语法报错
upstream backend { server 192.168.1.1 weight=3 max_fails=2; }upstream backend { server 192.168.1.1 weight=3 max_fails=2; }此例看似正确，但常见错误是把 weight 写在 server 地址之后且不带等号，如 server 192.168.1.1 3; 或 server 192.168.1.1 weight 3; 均会导致配置解析失败。
8.location 内嵌套 location 时未用正则，匹配顺序混乱
location /images/ { location /images/thumb/ { ... } }location /images/ { location ~ ^/images/thumb/ { ... } }嵌套 location 时，内层 location 默认仍是前缀匹配，且 Nginx 优先匹配外层，导致内层永远无法命中。必须用正则或 @ 命名 location 来明确匹配规则。
location /path { proxy_pass http://upstream_name; }
/path匹配的请求 URI 路径前缀upstream_nameupstream 块定义的服务器组名配置 location /api/ { proxy_pass http://backend; }，upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; }。请求 /api/user 时，Nginx 按加权轮询将请求转发到 backend 组中一台服务器，如 192.168.1.10:8080/user。
大部分可以，但需要根据实际路径和端口调整。模板里 location /api/ 之类的路径是示例，如果后端接口前缀不同（比如 /v1/），要改 location 的匹配。proxy_pass 的 http://backend 也需要换成真实的上游地址（如 http://127.0.0.1:8080）。直接粘贴不修改大概率报 404 或 502，建议对照模板注释里的占位符逐一替换。
常见原因是 upstream 区块必须放在 server 区块外面（同一层级），不能嵌套在 http 或 server 内部。另一个坑是 upstream 名称用了下划线或数字开头（如 upstream 1backend），Nginx 要求名称以字母开头。如果报 'upstream directive is not allowed here'，检查一下缩进和位置。本工具模板里的 upstream 结构是标准的，可以复制后只改 server 地址。
~ 是区分大小写的正则匹配，~* 是不区分大小写的正则匹配。如果后端接口对大小写敏感（比如 /User 和 /user 指向不同资源），用 ~；如果希望统一忽略大小写（比如静态文件 .jpg 和 .JPG 都走同一个规则），用 ~*。本工具模板里两种都提供了示例，建议优先用 ~* 避免踩大小写坑，除非明确需要区分。
502 通常表示 Nginx 无法连接到你指定的上游服务器。先检查 proxy_pass 里的 IP 和端口是否写对，以及上游服务是否在运行。另一个隐蔽原因是 upstream 名称拼写不一致——比如 upstream backend 定义了，但 proxy_pass http://backend 里写成了 backends（多了一个 s）。本工具模板的 upstream 和 proxy_pass 名称是对应的，复制后注意不要改错。
可以用嵌套 location 加否定正则来实现。先写一个 location = /user/admin 返回 403 或 proxy_pass 到别的地址，再写 location /user 处理正常请求。Nginx 的 location 匹配顺序是精确匹配（=）优先于前缀匹配，所以 /user/admin 会先被拦截。本工具模板里没有直接提供这种排除写法，但可以单独复制精确匹配的示例来组合。
完全离线。本工具是纯前端实现（FE），所有模板生成和代码高亮都在浏览器本地完成，没有任何网络请求。输入的路径、upstream 名称等数据不会离开设备，可以放心用于内网或敏感环境。如果对隐私有疑虑，可以打开浏览器开发者工具的网络面板，确认没有 POST 请求发出。
不一样。location / 是前缀匹配，会匹配所有以 / 开头的路径（即所有请求）；location = / 是精确匹配，只匹配根路径 / 本身，不会匹配 /index.html 或 /api。模板里同时提供是为方便不同场景：如果只想拦截根路径做特殊处理（比如重定向到维护页），用 = /；如果想全局走同一套规则，用 /。混用时注意顺序，精确匹配优先级更高。
默认 upstream 使用轮询（round-robin）算法，如果第一台服务器一直正常响应，请求会依次分发，不会全打一台。如果观察到的确是全打第一台，可能是：1) 没配置 backup 或 down 标记导致其他服务器被忽略；2) 使用了 ip_hash 或 least_conn 等调度算法但没写对；3) 其他服务器端口写错导致连接失败被 Nginx 自动摘除。本工具模板默认是轮询，复制后如需其他算法要手动加参数。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。