web服务器不直接处理网络层acl，子网级访问授权必须在基础设施层（如云平台网络acl、nginx反向代理、路由器或防火墙）配置，禁止在应用代码中校验ip段。
Web应用本身不处理网络层ACL，所谓“对特定局域网段开放服务端口”，实际是把访问控制落在流量抵达Web应用之前的位置——必须由基础设施层完成，而不是在PHP、Node.js或Java代码里写IP判断逻辑。
应在边界设备上配置子网级端口放行
真正起效的ACL配置发生在网络边界，例如：
- 云平台网络ACL：绑定到对应子网，设置入方向规则允许源IP为192.168.10.0/24、目的端口为80/443的TCP流量；出方向需额外放行1024–65535临时端口，否则HTTP响应无法返回
- 路由器或防火墙ACL：如华为设备上使用高级ACL，明确匹配源网段+协议+目的端口，再应用到WAN口或内网接口的inbound方向
- Nginx反向代理：用allow/deny指令配合satisfy any;实现子网白名单，但前提是它位于真实用户和后端Web服务之间
禁止在Web应用代码中做子网校验
以下做法不可取且存在严重风险：
- 在Spring Boot的Controller里解析X-Forwarded-For并比对IP段——该头可被伪造，且绕过CDN或反向代理后失效
- 用PHP的$_SERVER['REMOTE_ADDR']做子网判断——该地址通常是反向代理或负载均衡器的IP，不是真实客户端
- 在Docker容器内配置iptables限制子网——容器网络模型复杂，易与宿主机规则冲突，且无法覆盖所有入口路径
关键配置要点
无论选择哪种基础设施层方案，都需注意：
- 规则顺序决定匹配结果：先写permit再写deny any，否则允许规则永远不会生效
- ACL是无状态的：入方向放行80端口，不等于出方向自动放行响应；必须单独配置出方向规则，允许返回到客户端随机高端口
- 避免端口硬编码陷阱：FTP需同时放行20（数据）和21（控制），HTTPS不能只开443而忽略ALPN协商可能触发的其他端口行为
- 验证是否真正生效：用局域网外设备telnet目标IP 80应超时；用授权子网内设备curl -v应能建立连接并收到响应头
与Web层权限模型保持分离
子网放行只是第一道门禁，不代表用户拥有业务权限：
- 即使192.168.5.0/24能访问https://app.local/admin，仍需Web应用自身完成登录认证、RBAC鉴权、CSRF防护等
- ACL不替代身份验证：它解决“谁可以从哪里连上来”，不解决“连上来之后能做什么”
- 日志中记录的客户端IP，应以ACL执行点（如NLB、NGINX）获取的真实源IP为准，而非应用层二次解析
