nginx作为微服务网关安全边界，需按api路径前缀（如/api/internal/、/api/partner/）在location块中精确配置白名单，strict遵循allow优先、deny all兜底原则；必须通过real_ip_header或geo模块获取真实ip，避免代理污染；并联动cors、限流、安全头实现纵深防御。
在微服务网关场景中，Nginx 作为最外层反向代理，是定义安全边界的天然位置。它不参与业务逻辑，却能统一拦截、鉴权、限流和访问控制——把安全策略收口到这一层，后端各微服务无需重复实现 IP 白名单、黑名单或路径级防护，架构更清晰、运维更可控。
IP 白名单必须按 location 精确收敛
不能全局写 allow/deny，而要结合微服务的 API 路径前缀做细粒度控制。例如：
-
/api/internal/只允许内网调用：
location /api/internal/ {
allow 10.0.0.0/8;
allow 172.16.0.0/12;
deny all;
proxy_pass http://internal-svc;
} -
/api/partner/仅放行合作方固定公网 IP：
location /api/partner/ {
allow 203.0.113.45;
allow 203.0.113.46;
deny all;
proxy_pass http://partner-svc;
}
每条 allow 独立一行，deny all 必须放在最后且不可省略——否则未匹配请求默认放行，白名单失效。
真实 IP 获取必须可靠，否则控制失准
若 Nginx 前有 CDN、SLB 或云负载均衡，$remote_addr 是代理 IP，直接用于 allow/deny 会完全错误。必须确认上游是否透传 X-Forwarded-For，并在 Nginx 中清洗可信来源：
- 启用
real_ip_header X-Forwarded-For;和set_real_ip_from指定可信代理网段 - 或用
geo模块预提取可信真实 IP 列表：
geo $real_ip_allowed {
default 0;
10.20.0.0/16 1;
192.168.100.0/24 1;
}
location /admin/ {
if ($real_ip_allowed = 0) { return 403; }
proxy_pass http://admin-svc;
}
与跨域、限速、安全头协同配置
IP 控制不是孤立动作，需和其它网关策略联动：
- 对白名单内路径，可放宽
Access-Control-Allow-Origin（如动态回传$http_origin），对外部路径则严格限制 origin 或关闭 CORS - 对高风险接口（如
/api/login），在 IP 允许基础上叠加limit_req：按$binary_remote_addr$uri组合限速，防暴力枚举 - 所有响应统一加安全头：
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "default-src 'self';";
避免常见陷阱
实际部署中最容易踩的坑：
- location 匹配顺序错误：多个
location /api/xxx写错优先级，导致规则未生效 - HTTPS server 块漏配 IP 控制：只在 HTTP 块写了 allow，而生产走 HTTPS，结果控制完全没起作用
- reload 后未验证：改完配置必须用
curl -I -x "" http://domain/path模拟不同 IP 测试返回状态码（200 / 403） - 忽略 OPTIONS 预检：带凭据的跨域请求会先发 OPTIONS，该路径也需同样配置 allow/deny，否则预检失败
