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为准，而非应用层二次解析