Nginx长连接访问控制本质仍是IP黑白名单，依赖allow/deny指令，需配置在server或location块内，配合real_ip_module还原真实IP，并注意规则顺序与兜底策略。
长连接本身不是Nginx访问控制的直接对象，IP黑白名单控制的是“谁可以建立连接”，而非“连接是否保持”。所谓“长连接白名单/黑名单”实际是指：在启用 HTTP Keep-Alive（长连接）的前提下，对客户端 IP 实施访问控制。核心仍是 allow 和 deny 指令，但需注意配置位置、顺序及真实 IP 获取问题。
白名单：只允许指定 IP 建立并维持长连接
适用于管理后台、API 调试端点等高敏感路径。关键逻辑是“先放行可信来源，再拒绝其余所有”，且必须写在生效范围（server 或 location）内：
- 在
location块中逐条写allow，支持单 IP（如allow 203.0.113.10;）、IPv4 网段（如allow 192.168.100.0/24;）、IPv6（如allow 2001:db8::/32;） -
必须以
deny all;结尾，否则未匹配的请求会默认放行，白名单形同虚设 - Keep-Alive 行为由
keepalive_timeout和客户端请求头共同决定，访问控制不干扰该机制——只要通过白名单，后续复用连接也合法
黑名单：阻止特定 IP 发起任何连接（含长连接）
用于封禁已知攻击源或恶意扫描 IP，逻辑是“先拦截黑名单，再放行其余”。顺序错误会导致规则失效：
- 每条
deny写一行，可叠加多个（如deny 198.51.100.0/24;和deny 203.0.113.66;） -
必须将
allow all;放在所有deny之后作为兜底，否则 Nginx 默认拒绝所有请求 - 被
deny的 IP 连接会被立即终止（返回 403），无法完成 TLS 握手或 HTTP 请求，自然也无法进入长连接流程
按域名或路径隔离，避免全局误锁
同一台 Nginx 托管多个站点时，黑白名单不能写在 http 块顶层，否则影响全部服务：
- 每个
server_name对应独立server块，在其内部配置黑白名单，互不干扰 - 若只需保护后台路径（如
/admin/），把规则放在对应location /admin/ { ... }中即可，不影响首页或静态资源 - 切忌在
http层写allow/deny，除非你明确要全站统一管控
HTTPS 与 CDN 场景下必须还原真实 IP
当使用 Cloudflare、阿里云 SLB 或 Nginx 自身做反向代理时，$remote_addr 变成上游地址（如 127.0.0.1 或内网 IP），导致黑白名单完全失效：
- 启用
real_ip_module，在server块中配置set_real_ip_from指定可信代理网段 - 用
real_ip_header X-Forwarded-For或X-Real-IP提取原始客户端 IP - 验证是否生效：加一条
log_format debug '$remote_addr — $http_x_forwarded_for';查看日志
