HTTPS下Nginx白名单核心逻辑与HTTP一致，基于真实客户端IP生效；需通过set_real_ip_from和real_ip_header还原源IP，再在SSL server块中用allow/deny配置，或结合geo模块实现灵活管理。
HTTPS 环境下配置 Nginx 访问白名单，核心逻辑与 HTTP 完全一致——协议层（HTTPS）不影响 IP 层访问控制，allow/deny 规则仍基于客户端真实 IP 生效。关键在于确认你拿到的是真实源 IP，而非代理或 CDN 的中转 IP。
确保获取到真实客户端 IP
HTTPS 本身不改变 $remote_addr 的取值，但若前端有 CDN、负载均衡或反向代理（如另一层 Nginx），$remote_addr 会变成该中间节点的 IP，导致白名单失效。
- 检查 access_log 中每条请求记录的 $remote_addr 值，对比你预期的客户端 IP 是否一致
- 若使用了 CDN（如 Cloudflare、阿里云 DCDN），需在 server 或 location 块中显式读取
$http_x_forwarded_for或$http_x_real_ip，并配合set_real_ip_from和real_ip_header指令还原真实 IP - 常见配置示例（放在 http 或 server 块顶部）：
set_real_ip_from 192.168.0.0/16;<br> set_real_ip_from 10.0.0.0/8;<br> real_ip_header X-Forwarded-For;
在 HTTPS server 块中配置白名单
直接在启用 SSL 的 server 块内添加 allow/deny，无需额外适配 HTTPS：
- 只允许两个办公网段访问管理后台：
server {<br> listen 443 ssl;<br> server_name admin.example.com;<br> ssl_certificate /path/to/fullchain.pem;<br> ssl_certificate_key /path/to/privkey.pem;<br> location /admin/ {<br> allow 192.168.10.0/24;<br> allow 172.16.5.0/24;<br> deny all;<br> }<br> } - 注意：若本地调试需保留访问权限，务必加上
allow 127.0.0.1;
结合 geo 模块实现更灵活的白名单管理
当白名单 IP 较多或需动态维护时，推荐用 geo 模块预定义变量，再在 location 中判断：
- 在 http 块中定义：
geo $whitelist {<br> default 0;<br> 192.168.1.100 1;<br> 192.168.2.0/24 1;<br> 203.0.113.42 1;<br> } - 在 HTTPS server 的 location 中使用：
location /api/ {<br> if ($whitelist = 0) { return 403; }<br> proxy_pass http://backend;<br> } - 优势：配置集中、支持大网段、reload 即生效，且避免 allow/deny 顺序误配风险
验证与排错要点
配置完成后必须验证是否真正生效，尤其 HTTPS 场景容易因证书或代理链掩盖问题：
- 执行
nginx -t确保语法无误，再nginx -s reload - 从白名单外 IP 尝试访问，确认返回 403 而非 502/503（后者说明是后端或代理问题）
- 查看 error.log，搜索 “client denied by server configuration”，确认拦截日志存在
- 若使用 Let’s Encrypt + certbot 自动续期，确保白名单规则未被覆盖（建议将访问控制单独拆到 conf.d/ 目录下的独立文件）
