Nginx 中 if 仅限 location 块内使用，仅支持 return、rewrite（last/permanent）、set 三类操作；禁止 proxy_pass 等指令；应优先用 map、location、try_files 替代。
在 Nginx 配置中写 if 语句，不是“能不能用”的问题，而是“在哪用、怎么用、用什么替代”的问题。它本身不提供编程式逻辑，而是一个受严格限制的重写阶段指令——用错位置或目的，轻则 404/502，重则请求静默失败、worker 崩溃。
只允许在 location 块内使用
if 必须嵌套在 location 块里，不能放在 server 块顶层，更不能出现在 http 块或 upstream 中。原因很直接：
- server 块顶层的 if 会干扰请求路由，导致 location 匹配失效或跳过关键处理流程
- 变量如
$host、$http_referer在早期阶段可能为空、被篡改或未标准化，判断结果不可靠 - 官方明确标注 “if is evil”，尤其指这类全局滥用场景
只能做三类安全操作
即使在 location 内，if 也仅支持以下三种行为，其他一律禁止：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 用
return立即终止请求（如return 403、return 301） - 用
rewrite ... last或rewrite ... permanent做路径重写（注意不能混用break和proxy_pass） - 用
set设置变量（但该变量在 if 外部不一定可用，尤其不能用于后续proxy_pass的动态拼接）
常见错误包括：if 块里写 proxy_pass、add_header、try_files 或 -f 文件判断——这些指令会被忽略或引发未定义行为。
避免依赖不可靠的来源变量
用 if 判断来源时，很多变量天生不安全：
-
$http_referer和$http_user_agent可被客户端任意伪造，精确匹配（如= "curl"）几乎无效，应改用正则模糊识别（如~* "curl|wget"）并配合return 403 -
$remote_addr在有 CDN 或反向代理时默认是上一跳 IP，必须先配置set_real_ip_from和real_ip_header修复，否则判断对象本身就是错的 -
$host在 Host 头缺失、含端口或非法字符时可能为空，直接if ($host = "xxx")易漏判或误判
优先用 map、location、try_files 替代 if
绝大多数条件需求都有比 if 更稳定、高效、可维护的方案：
- 按域名分流 → 拆成多个
server { server_name example.com; }块，语义清晰、零风险 - 多条件映射（如识别 bot / mobile / admin）→ 在
http块用map预计算变量，再在 location 中简单判断，性能高且可复用 - 静态资源兜底 → 用
try_files $uri $uri/ /index.html，而不是if (-f $request_filename) - 路径特征转发 → 用
location ~ ^/api/v2/或location ^~ /static/，比靠$host或$arg_xxx更贴近业务意图
