为什么反向代理配置容易出问题#
常见故障不是 Nginx “不能转发”，而是真实 IP、WebSocket、上传大小、超时和 HTTPS 跳转只配置了一半。下面的配置以单个 Next.js 服务为例，并保留明确的验证路径。
上游与代理头#
nginx
upstream blog_app {
server blog-app:3000;
keepalive 32;
}
server {
listen 80;
server_name blog.example.com;
location / {
proxy_pass http://blog_app;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_connect_timeout 5s;
proxy_read_timeout 60s;
}
}
如果 Nginx 前面还有 CDN 或 Caddy，只有在明确知道代理出口网段时才使用 set_real_ip_from，否则客户端可以伪造 X-Forwarded-For。
TLS 与安全响应头#
| 项目 | 建议 | 原因 |
|---|---|---|
| TLS | 仅 TLS 1.2 / 1.3 | 淘汰旧协议 |
| HSTS | 确认全站 HTTPS 后再开启 | 配错会长期阻断 HTTP |
| X-Content-Type-Options | nosniff | 避免 MIME 猜测 |
| Referrer-Policy | strict-origin-when-cross-origin | 减少敏感路径外泄 |
nginx
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
client_max_body_size 20m;
上线前验证#
bash
nginx -t
curl -I http://blog.example.com
curl -I https://blog.example.com
curl -fsS https://blog.example.com/api/health
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null
检查 HTTP 是否只跳转一次、证书域名是否匹配、应用收到的协议是否为 HTTPS。若出现 502，先从 Nginx 容器内部访问上游，区分网络问题和应用问题。
讨论区 27
分享你的经验、补充或不同观点。支持 Markdown 基础语法。