nginx常见错误集中在配置逻辑、语法细节和环境适配三方面：rewrite位置错误导致https透传；301重定向循环因server_name重叠或条件不全；proxy_pass协议丢失需设x-forwarded-proto；rewrite末尾缺break或斜杠引发路径错误；rewrite模块缺失则需检查pcre依赖。
常见错误主要集中在配置逻辑、语法细节和环境适配三方面，不难排查，但容易因惯性思维忽略关键点。
rewrite 写在了错的 server 块里
HTTPS 请求进的是 listen 443 ssl 的 server 块，但如果所有 rewrite 都只写在 listen 80 块里，443 块又没做任何处理，就会导致 HTTPS 请求原样透传，后端可能返回 HTTP 地址，浏览器拒绝加载。
- 检查每个 server 块是否覆盖了对应协议：80 块负责 HTTP→HTTPS 跳转，443 块负责正常服务或内部路径重写
- 避免在 443 块里写
return 301 http://...这类反向降级规则 - 若用 if 判断 scheme，确保条件完整：
if ($scheme = http) { return 301 https://$host$request_uri; }
永久重定向引发循环跳转
典型表现是浏览器提示“重定向次数过多”，本质是请求 URL 经 rewrite 后又匹配到同一条规则，反复触发。
- server_name 中不能同时包含跳转源和目标域名（如
shidongyun.com www.shidongyun.com），否则访问 www 也会触发 rewrite - rewrite 目标地址必须与当前 server_name 不重叠，跳转目标应单独用另一个 server 块承接
- 用
curl -I https://domain/path验证，比浏览器更可靠——它不缓存 301，能看清真实跳转链
proxy_pass 前 rewrite 导致协议丢失
前端 HTTPS 请求经 rewrite 改写路径后 proxy_pass 到 HTTP 后端，若后端生成的 Location 头仍是 HTTP 地址，用户就会被降级。
- 必须设置
proxy_set_header X-Forwarded-Proto $scheme;，让后端知道原始协议 - rewrite 用于路径改写时（如
rewrite ^/api/(.*)$ /$1 break;），末尾加break，防止继续匹配 location 或触发 redirect - proxy_pass 目标地址结尾带斜杠（
http://backend/），否则路径拼接易出错
rewrite 指令本身不可用或语法报错
运行 nginx -t 提示 “unknown directive ‘rewrite’”，通常不是配置问题，而是编译缺失模块。
- 默认编译即含 rewrite 模块；若手动 configure 时用了
--without-http_rewrite_module，就会禁用它 - 确认依赖已装：
pcre和pcre-devel（或libpcre3-dev）是正则支持基础 - rewrite 规则中正则部分不要漏掉引号，尤其含空格或特殊字符时：
rewrite "^/old/(.*)$" /new/$1 permanent;
