最推荐在upstream块中配置proxy_bind（需Nginx≥1.19.10），可统一指定所有后端连接的物理网卡源IP，避免重复配置与继承冲突；须确保该IP已配置在网卡上、状态UP、路由可达且防火墙放行。
直接在 upstream 块中写 proxy_bind 是最稳妥、最推荐的方式，前提是 Nginx 版本 ≥ 1.19.10。它能确保整个后端集群的所有连接都从你指定的物理网卡 IP 出站，不遗漏、不继承、不冲突。
确认物理网卡 IP 已就绪
proxy_bind 绑定的是“IP 地址”，不是网卡名（如 eth0），也不是别名接口（如 eth0:1）。它必须是已配置在某张物理网卡上、且状态为 UP 的真实 IPv4/IPv6 地址：
- 运行
ip -4 addr show或ip -6 addr show，找到目标网卡（如 eth1）下明确列出的、带scope global的 IP，例如203.0.113.50/24 - 该 IP 必须能主动发包：执行
ping -I 203.0.113.50 8.8.8.8验证连通性 - 若该 IP 是 secondary 地址（非主 IP），需开启内核参数：
sysctl -w net.ipv4.ip_nonlocal_bind=1，并写入/etc/sysctl.conf持久化
在 upstream 中统一绑定出口 IP（推荐）
适用于所有后端节点共用同一物理出口线路的场景（如 BGP 公网、专用回源网段）：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 版本要求：Nginx ≥ 1.19.10（低版本不支持 upstream 级 proxy_bind）
- 配置示例：
upstream api_cluster { proxy_bind 203.0.113.50; # 所有连接从此物理网卡 IP 出站 server 172.16.10.101:443; server 172.16.10.102:443; server 172.16.10.103:443; } - 优势：一处配置，全局生效；避免在多个 location 中重复声明；与负载均衡策略（如 least_conn）完全正交，互不干扰
按业务路径精细分流到不同物理出口
当服务器有多张公网网卡（如电信 eth1、联通 eth2），需按 URL 路径将流量钉到对应物理线路：
- 分别定义多个 upstream，各自绑定不同物理网卡 IP：
upstream telecom_backend { server 10.20.30.40:443; } upstream unicom_backend { server 10.20.30.41:443; } <p>location /pay/ { proxy_pass <a href="https://www.php.cn/link/26099adf9fe6be27c19d1a0fb68d7985">https://www.php.cn/link/26099adf9fe6be27c19d1a0fb68d7985</a>; proxy_bind 203.0.113.50; # 强制走 eth1（电信） } location /report/ { proxy_pass <a href="https://www.php.cn/link/2f0bf07b716733d56ffa0b68cfe3823f">https://www.php.cn/link/2f0bf07b716733d56ffa0b68cfe3823f</a>; proxy_bind 203.0.113.51; # 强制走 eth2（联通） } - 注意：location 级 proxy_bind 优先级高于 upstream 级，可覆盖；每个 location 的绑定互不影响
- 确保后端防火墙白名单包含你写的这两个 IP
验证是否真正从物理网卡发出
配置后不能只看 Nginx 日志——必须抓包确认物理层行为：
- 在目标网卡上抓包：
tcpdump -i eth1 -nn host backend.example.com and port 443 - 发起请求，观察 SYN 包的源 IP 是否为你设置的
203.0.113.50 - 同时检查后端 access log 中的
remote_addr字段，应显示该 IP（而非 Nginx 本机默认路由选的 IP） - 若失败，优先排查：
ip addr是否真有该地址、sysctl net.ipv4.ip_nonlocal_bind是否启用、系统路由表是否支持该 IP 主动发包
