第02章：AI配置了反向代理，但后端IP被泄露了
第02章：AI配置了反向代理，但后端IP被泄露了
“你用 Nginx 隐藏了后端服务器，但后端返回的响应头里，后端服务器的 IP、框架版本、甚至错误堆栈都暴露出去了。”
ℹ️ 版本说明：本章基于 Nginx 1.30.2 + FastAPI/uvicorn 后端。
2.1 AI默认会生成什么
最常见的 Nginx 反代配置：
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
功能上正确。但你检查一下 API 的响应头：
HTTP/1.1 200 OK
server: uvicorn
x-powered-by: FastAPI
x-process-time: 0.00234
攻击者现在知道了：你用的是 uvicorn + FastAPI，服务器的处理时间，甚至可以通过时序攻击推断某些业务逻辑。
2.2 AI通常遗漏的4个坑
⚠️ 坑1：后端响应头泄露技术栈
Server: uvicorn、X-Powered-By: FastAPI、X-Powered-By: PHP/8.1 这类响应头暴露了你的技术栈，让攻击者可以有针对性地搜索对应版本的 CVE。
修复：在 Nginx 层拦截并替换这些响应头：
proxy_hide_header X-Powered-By;
proxy_hide_header Server;
add_header Server "WebServer" always; # 用通用名称替换
⚠️ 坑2：X-Forwarded-For 头可以被伪造
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
如果攻击者在请求里加一个伪造的 X-Forwarded-For: 1.2.3.4，$proxy_add_x_forwarded_for 会变成 1.2.3.4, 攻击者IP。
如果你的应用通过 X-Forwarded-For 的第一个 IP 做限速或白名单，这就可以被绕过。
修复：
# 先清除客户端传来的值，再设置真实 IP
proxy_set_header X-Forwarded-For $remote_addr;
# 或者用 real_ip_module 直接设置客户端真实 IP
⚠️ 坑3：proxy_pass 后的路径处理容易出错
location /api/ {
proxy_pass http://127.0.0.1:8000; # 注意：没有 /
# 请求 /api/users → 后端收到 /api/users
# vs
proxy_pass http://127.0.0.1:8000/; # 注意：有 /
# 请求 /api/users → 后端收到 /users（去掉了 /api 前缀）
}
这个细节 AI 经常搞错或者没有解释清楚。
⚠️ 坑4：超时配置不合理
AI 生成的配置通常没有超时配置，或者超时时间太长：
# AI 通常不设置，Nginx 默认值：
# proxy_connect_timeout 60s;
# proxy_send_timeout 60s;
# proxy_read_timeout 60s;
如果后端一个接口卡住了（无限等待数据库），这个连接会占用 60 秒才超时，在高并发下会耗尽连接数。
2.3 更好的提示词
提示词 P01：安全的反向代理配置（隐藏技术栈）
使用时机：任何生产环境的 Nginx 反代配置
比默认多了什么：
- 隐藏后端技术栈响应头
- 正确的 X-Forwarded-For 处理
- 合理的超时配置
帮我写一个生产就绪的 Nginx 反向代理配置，代理到 FastAPI/uvicorn 后端。
后端信息：
- 后端地址：127.0.0.1:8000
- 后端框架：FastAPI + uvicorn
- 接口前缀：/api/（前端静态文件在 /，API 在 /api/）
安全要求：
1. 隐藏后端技术栈：proxy_hide_header 隐藏 Server、X-Powered-By
2. 替换 Server 头为通用名称
3. X-Forwarded-For 处理：
- 清除客户端传来的 X-Forwarded-For（防伪造）
- 只设置 $remote_addr 作为真实 IP
- 同时传递 X-Real-IP 给后端
超时配置：
4. proxy_connect_timeout: 5s（连接后端超时）
5. proxy_send_timeout: 30s（发送请求超时）
6. proxy_read_timeout: 30s（等待响应超时）
7. proxy_next_upstream: 后端失败时是否尝试其他上游（配合 upstream 使用）
路径处理（解释清楚）：
8. /api/ → http://127.0.0.1:8000/（去掉 /api 前缀）—— 说明 proxy_pass 带不带结尾斜杠的区别
给我分开的两个 server 块：
- server 80：HTTP，只做 301 跳转到 HTTPS
- server 443：HTTPS + 反代配置
基于 Nginx 1.30.2。
提示词 P02：配置 upstream 后端池（高可用）
使用时机：后端有多个实例（负载均衡场景）
比默认多了什么：
- upstream 健康检查
- 权重配置
- 失败切换策略
帮我配置 Nginx upstream，将请求分发到3个后端实例。
后端实例：
- 127.0.0.1:8001（主）
- 127.0.0.1:8002（副）
- 127.0.0.1:8003（副）
要求：
1. 负载均衡算法：least_conn（最少连接，适合 API 服务）
2. 健康检查：
- Nginx 开源版只有被动健康检查（请求失败才标记下线）
- 配置 max_fails=3 fail_timeout=30s
- 解释被动健康检查的局限性（后端刚启动时的问题）
3. 连接池：keepalive 配置（减少 TCP 握手开销）
4. 主从配置：
- 主节点权重 3，副节点权重 1
- 某个节点下线时，流量自动分到其他节点
同时告诉我：
- Nginx 商业版（nginx plus）的主动健康检查如何工作
- 开源版如何用第三方模块（nginx_upstream_check_module）实现主动健康检查
基于 Nginx 1.30.2 开源版。
提示词 P03：调试反向代理问题
使用时机：反代配置后，请求行为和预期不符
比默认多了什么：
- 添加调试响应头
- 检查请求是否到达后端
- 追踪路径转换
我的 Nginx 反代配置有问题，帮我调试。
问题现象：[描述你的问题，如：前端 /api/users 请求返回 404，但直接访问后端 :8000/api/users 是正常的]
调试方法：
1. 在 Nginx 配置中临时添加调试响应头（显示 Nginx 内部变量）：
- 显示 $uri（Nginx 处理后的 URI）
- 显示 $request_uri（原始请求 URI）
- 显示 $proxy_host（代理到的后端地址）
2. 开启 Nginx 访问日志，显示更多字段：
- 请求到达 Nginx 的 URI
- proxy_pass 处理后发给后端的 URI
3. 用 curl -v 追踪请求全过程
4. 检查 Nginx 错误日志：journalctl -u nginx --since "5 min ago"
帮我解读以下 Nginx 日志/错误信息：
[粘贴日志]
基于 Nginx 1.30.2。
2.4 验收清单
| 检查项 | 验证方法 | AI辅助 |
|---|---|---|
| 后端技术栈不泄露 | curl -I https://example.com 无 uvicorn/FastAPI 响应头 |
让 AI 添加 proxy_hide_header |
| Server 头通用化 | 响应头 Server: WebServer（不含版本） | 让 AI 添加 add_header Server |
| X-Forwarded-For 防伪造 | 发伪造 X-Forwarded-For，后端收到的是真实 IP | 让 AI 修改 XFF 头处理 |
| 超时配置合理 | 后端30s未响应，Nginx 返回 504 | 让 AI 添加 proxy_read_timeout |
| 路径转换正确 | /api/users → 后端收到 /users 或 /api/users（符合预期） | 让 AI 解释并验证 proxy_pass 路径 |
| 配置语法无错误 | nginx -t |
修复任何语法错误 |
2.5 本章小结
如果你只记一件事：在反代配置里加上 proxy_hide_header X-Powered-By 和 proxy_hide_header Server，隐藏后端技术栈。攻击者无法针对性地利用你框架的已知漏洞。
反向代理的三个安全原则：
- 隐藏内部细节：后端的 IP、框架、版本都不应该暴露给外部
- 不信任客户端传来的代理头：
X-Forwarded-For是客户端可以伪造的，清除后重新设置 - 设置超时：没有超时的反代会让一个慢请求耗尽所有并发连接
→ 第3章：AI生成的限速配置，为什么没有生效？