清理废弃IP规则需遵循“先识别、再隔离、后验证”：识别三类废弃特征（设备下线、临时白名单超期、重复冲突），注释而非删除规则，聚合为全局/业务/临时三层结构，并通过curl和日志验证。
清理和重构废弃的IP访问规则，核心是“先识别、再隔离、后验证”，避免误删导致服务不可用或安全缺口。Nginx本身不提供自动规则生命周期管理，必须靠人工+结构化配置来保障可维护性。
识别哪些规则已废弃
废弃规则通常有三类特征：
- 对应设备/人员已离职、下线或迁移（如旧办公网段10.1.5.0/24被新VPC替代）
- 临时测试白名单超期未清理（例如上线前加的 allow 192.168.99.23，上线后未移除）
- 重复或冲突规则（同一IP在不同层级被多次 allow/deny，或 deny 后又 allow，逻辑失效）
建议定期检查 access.log 中长期无访问记录的 IP 段，结合运维台账比对；也可用 nginx -T | grep -E "(allow|deny)" 提取全站规则，导出后按 server_name 和 location 分组分析。
安全清理：不直接删，先注释+标记
禁止直接删除行——可能因 reload 失败或顺序错乱引发拒绝服务。正确做法是：
- 将待清理规则前加 # [OBSOLETE 2026-09] 注释，并说明废弃原因（例：# [OBSOLETE 2026-09] 测试环境已迁至K8s，原内网IP不再使用）
- 若该规则属于 include 文件（如 ip-whitelist.conf），在文件头添加 # DEPRECATED — DO NOT EDIT，并重命名为 ip-whitelist.conf.deprecated
- 执行 nginx -t 验证语法，确认注释不影响加载
重构规则：从硬编码转向可维护结构
把散落在各处的 allow/deny 聚合为三层管理：
- 全局可信网段：在 http 块用 geo 定义变量（如 $is_internal），只放生产必需的 CIDR（如公司办公网、云厂商健康检查段）
- 业务级白名单：为 /admin/、/api/internal/ 等路径单独建 include 文件（如 admin-allow.conf），按功能归属而非IP来源组织
- 临时策略区：新增规则统一写入 temp-rules.conf，加生效截止注释（# EXPIRES: 2026-10-15），配合 cron 自动提醒清理
重构后，所有 location/server 中的 allow/deny 全部替换为 if ($is_internal = 0) { return 403; } 或 include /etc/nginx/conf.d/admin-allow.conf;，提升一致性与审计效率。
验证与回滚机制
每次清理或重构后必须验证：
- 用 curl -I --header "Host: example.com" http://your-nginx-ip/path 模拟不同源IP请求，确认预期放行/拦截
- 检查 error.log 是否出现 access forbidden by rule 误报
- 保留上一版完整 conf.d 目录快照（如 conf.d.bak-20261001），确保 5 秒内可回退
不复杂但容易忽略：规则清理不是一次性任务，而是配置治理的常态化环节。
